Patch set on sun cluster

Hi,
I have to upgrade 9.2.0.6 to 9.2.08 on sun cluster.Can you tell me in what sequence I need to install patch set? Is there any pre-requisite which I need to take care in advance?If anybody will provide me exact doc then It will be very helpful.I have seen one doc in metalink but it is not sufficient.
Thanks,
Mk

Have you checked the 9.2.0.8 patch README ? There are several references on how to patch clustered instances - if the information is insufficient or lacking, pl open an SR with Support.
http://updates.oracle.com/ARULink/Readme/process_form?aru=8690150
HTH
Srini

Similar Messages

Wrong hostname setting after Sun Cluster failover

Hi Gurus,
our PI system has been setup to fail over in a sun cluster with a virtual hostname s280m (primary host s280 secondary host s281)
The basis team set up the system profiles to use the virtual hostname, and I did all the steps in SAP Note 1052984 "Process Integration 7.1 High Availability" (my PI is 7.11)
Now I believe to have substituted "s280m" in every spot where previously "s280" existed, but when I start the system on the DR box (s281), the java stack throws erros when starting. Both SCS01 and DVEBMGS00 work directories contain a file called dev_sldregs with the following error:
Mon Apr 04 11:55:22 2011 Parsing XML document.
Mon Apr 04 11:55:22 2011 Supplier Name: BCControlInstance
Mon Apr 04 11:55:22 2011 Supplier Version: 1.0
Mon Apr 04 11:55:22 2011 Supplier Vendor:
Mon Apr 04 11:55:22 2011 CIM Model Version: 1.5.29
Mon Apr 04 11:55:22 2011 Using destination file '/usr/sap/XP1/SYS/global/slddest.cfg'.
Mon Apr 04 11:55:22 2011 Use binary key file '/usr/sap/XP1/SYS/global/slddest.cfg.key' for data decryption
Mon Apr 04 11:55:22 2011 Use encryted destination file '/usr/sap/XP1/SYS/global/slddest.cfg' as data source
Mon Apr 04 11:55:22 2011 HTTP trace: false
Mon Apr 04 11:55:22 2011 Data trace: false
Mon Apr 04 11:55:22 2011 Using destination file '/usr/sap/XP1/SYS/global/slddest.cfg'.
Mon Apr 04 11:55:22 2011 Use binary key file '/usr/sap/XP1/SYS/global/slddest.cfg.key' for data decryption
Mon Apr 04 11:55:22 2011 Use encryted destination file '/usr/sap/XP1/SYS/global/slddest.cfg' as data source
Mon Apr 04 11:55:22 2011 ******************************
Mon Apr 04 11:55:22 2011 *** Start SLD Registration ***
Mon Apr 04 11:55:22 2011 ******************************
Mon Apr 04 11:55:22 2011 HTTP open timeout = 420 sec
Mon Apr 04 11:55:22 2011 HTTP send timeout = 420 sec
Mon Apr 04 11:55:22 2011 HTTP response timeout = 420 sec
Mon Apr 04 11:55:22 2011 Used URL: http://s280:50000/sld/ds
Mon Apr 04 11:55:22 2011 HTTP open status: false - NI RC=0
Mon Apr 04 11:55:22 2011 Failed to open HTTP connection!
Mon Apr 04 11:55:22 2011 ****************************
Mon Apr 04 11:55:22 2011 *** End SLD Registration ***
Mon Apr 04 11:55:22 2011 ****************************
notice it is using the wrong hostname (s280 instead of s280m). Where did I forget to change the hostname? Any ideas?
thanks in advance,
Peter

Please note that the PI system is transparent about the Failover system used.
When you configure the parameters against the mentioned note, this means that in case one of the nodes is down, the load will be sent to another system under the same Web Dispatcher/Load Balancer.
When using the Solaris failover solution, it covers the whole environment, including the web dispatcher, database and all nodes.
Therefore, please check the configuration as per the page below, which talks specifically about the Solaris failover solution for SAP usage:
http://wikis.sun.com/display/SunCluster/InstallingandConfiguringSunClusterHAfor+SAP

Apply one non-kernel Solaris10 patch at Sun Cluster ***Beginner Question***

Dear Sir/Madam,
Our two Solaris 10 servers are running Sun Cluster 3.3. One server "cluster-1" has one online running zone "classical". Another server
"cluster-2" has two online running zones, namely "romantic" and "modern". We are tying to install a regular non-kernel patch #145200-03 at cluster-1 LIVE which doesn't have prerequisite and no need to reboot afterwards. Our goal is to install this patch at the global zone,
three local zones, i.e., classical, romantic and modern at both cluster servers, cluster-1 and cluster02.
Unfortunately, when we began our patching at cluster-1, it could patch the running zone "classical" but we were getting the following errors which prevent it from continuing with patching at zones, i.e., "romantic" and "modern" which are running on cluster-2. And when we try to patch cluster-2, we are getting similiar patching error about failing to boot non-global zone "classical" which is in cluster-1.
Any idea how I could resolve this ? Do we have to shut down the cluster in order to apply this patch ? I would prefer to apply this
patch with the Sun Cluster running. If not, what's the preferred way to apply simple non-reboot patch at all the zones at both nodes in the Sun Cluster ?
Like to hear from folks who have experience in dealing with patching in Sun Cluster.
Thanks, Mr. Channey
p.s. Below are output form the patch #145200-03 run, zoneadm and clrg
outputs at cluster-1
root@cluster-1# patchadd 145200-03
Validating patches...
Loading patches installed on the system...
Done!
Loading patches requested to install.
Done!
Checking patches that you specified for installation.
Done!
Approved patches will be installed in this order:
145200-03
Preparing checklist for non-global zone check...
Checking non-global zones...
Failed to boot non-global zone romantic
exiting
root@cluster-1# zoneadm list -iv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
15 classical running /zone-classical native shared
- romantic installed /zone-romantic native shared
- modern installed /zone-modern native shared
root@cluster-1# clrg status
=== Cluster Resource Groups ===
Group Name Node Name Suspended Status
classical cluster-1 No Online
cluster-2 No Offline
romantic cluster-1 No Offline
cluster-2 No Online
modern cluster-1 No Offline
cluster-2 No Online

Hi Hartmut,
I kind of got the idea. Just want to make sure. The zones 'romantic' and 'modern' show "installed" as the current status at cluster-1. These 2 zones are in fact running and online at cluster-2. So I will issue your commands below at cluster-2 to detach these zones to "configured" status :
cluster-2 # zoneadm -z romantic detach
cluster-2 # zoneadm -z modern detach
Afterwards, I apply the Solaris patch at cluster-2. Then, I go to cluster-1 and apply the same Solaris patch. Once I am done patching both cluster-1 and cluster-2, I will
go back to cluster-2 and run the following commands to force these zones back to "installed" status :
cluster-2 # zoneadm -z romantic attach -f
cluster-2 # zoneadm -z modern attach -f
CORRECT ?? Please let me know if I am wrong or if there's any step missing. Thanks much, Humphrey
root@cluster-1# zoneadm list -iv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
15 classical running /zone-classical native shared
- romantic installed /zone-romantic native shared
- modern installed /zone-modern native shared

Sun cluster/metaset

I have two E450's connected to a D1000, have install Solaris 9 with patches and installed Sun cluster 3.2.
Both 450's are in the cluster and can see the D1000.
With the drives on the D1000, setup area for meta database on slice 7 starting from block 0 around 200MB and rest of disk on slice 0.
Create the database metadb -a -f ... on the disks from both hosts, and can reboot and can see the databases metadb -i, okay from both hosts
The problem which is occuring is that after I create them in disk sets and reboot both the hosts, the database become unknown showing,
metaset ... there are no existing databases, and when I do a metadb -i
M p unknown unknown /dev/dsk/c5t0d0s7
M p unknown unknown /dev/dsk/c5t1d0s7
I create the metaset doing
# metaset -s data1 -ah host1 host2
# metaset -s data1 -a /dev/did/rdsk/d4 /dev/did/rdsk/d5
This is all I need to to for the meta databases to become unknown after a reboot
Can't workout what I am doing wrong

I can't see anything in /var/adm/messages to give clue to the fault,
cldevice status gives all devices okay
there are no "Warning: rpc.metamedd on host not responding errors"
This is a list of patches
Patch: 112233-12 Obsoletes: 114400-03 114408-01 113361-08 112653-04 112687-02 112701-02 112902-12 112903-03 114760-02 114977-01 112736-03 115243-01 112737-03 113150-03 113156-01 113158-01 113159-01 113163-01 113714-01 113740-04 113963-01 113218-09 114382-01 114384-02 113578-01 112840-03 112841-10 113219-01 113325-01 113445-04 113489-05 113571-03 114226-01 114360-01 114390-01 114391-01 114392-01 114418-03 114466-04 114863-01 115245-01 115246-01 115499-01 115496-01 112904-12 112967-05 113449-04 113453-06 116233-01 116433-01 112961-01 113024-09 113030-02 113223-02 113275-02 113454-14 113538-11 113577-01 114118-02 115244-01 114359-02 114385-03 114393-03 114394-02 114474-01 114487-01 115169-01 115242-01 115251-02 116057-04 116074-01 Requires: Incompatibles: Packages: FJSVhea SUNWarc SUNWarcx SUNWcar SUNWcarx SUNWcpc SUNWcpcx SUNWcpr SUNWcprx SUNWcsl SUNWcslx SUNWcsr SUNWcstl SUNWcstlx SUNWcsu SUNWcsxu SUNWdrcrx SUNWdrr SUNWdrrx SUNWefclx SUNWefcux SUNWefcx SUNWfss SUNWfssx SUNWged SUNWgedu SUNWgedx SUNWhea SUNWidn SUNWidnx SUNWkvm SUNWmdb SUNWmdbx SUNWncar SUNWncarx SUNWncau SUNWncaux SUNWnfscr SUNWnfscx SUNWnisu SUNWpd SUNWpdx SUNWpiclu SUNWpmu SUNWpmux SUNWusx SUNWwrsax SUNWwrsdx SUNWwrsmx SUNWwrsux
Patch: 112839-07 Obsoletes: 112962-01 Requires: 112874-13 Incompatibles: Packages: SUNWcsl SUNWcslx SUNWmdb SUNWmdbx
Patch: 112920-02 Obsoletes: 112712-02 Requires: Incompatibles: Packages: SUNWarc SUNWarcx SUNWcsl SUNWcslx SUNWcsr SUNWcstl SUNWcstlx SUNWhea SUNWmdb SUNWmdbx
Patch: 112963-25 Obsoletes: 112833-01 Requires: Incompatibles: Packages: SUNWarc SUNWbtool SUNWbtoox SUNWcsl SUNWcslx SUNWcsr SUNWcsu SUNWcsxu SUNWhea SUNWmdb SUNWmdbx SUNWosdem SUNWtoo SUNWtoox SUNWxcu4
Patch: 113073-13 Obsoletes: 113005-02 115026-01 113492-04 113006-01 113026-22 113069-04 113282-01 113333-02 113491-01 113276-04 115506-01 116128-02 116446-02 113464-07 116130-01 116448-01 116550-01 117248-02 117069-01 113456-01 113457-05 113993-06 115510-01 Requires: 114127-03 112233-12 Incompatibles: Packages: SUNWcarx SUNWcsl SUNWcslx SUNWcsr SUNWcsu SUNWcsxu SUNWhea SUNWmdau SUNWmdr SUNWmdu SUNWmdx
Patch: 113073-14 Obsoletes: 113005-02 115026-01 113492-04 113006-01 113026-22 113069-04 113282-01 113333-02 113491-01 113276-04 115506-01 116128-02 116446-02 113464-07 116130-01 116448-01 116550-01 117248-02 117069-01 113456-01 113457-05 113993-06 115510-01 Requires: 114127-03 112233-12 Incompatibles: Packages: SUNWcarx SUNWcsl SUNWcslx SUNWcsr SUNWcsu SUNWcsxu SUNWhea SUNWmdau SUNWmdr SUNWmdu SUNWmdx
Patch: 113332-07 Obsoletes: 113539-01 113540-01 114464-01 114376-03 Requires: Incompatibles: Packages: SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWpstl SUNWpstlx
Patch: 113447-21 Obsoletes: 113025-01 113221-03 113574-08 114375-09 114381-06 114465-01 114752-02 114753-02 114765-01 114379-03 114770-03 114930-01 116072-02 116077-01 116416-01 114258-01 114347-01 115526-03 115527-03 114261-04 113488-01 117285-01 117296-01 113573-05 114325-01 114864-02 Requires: 112233-09 114385-01 Incompatibles: Packages: FJSVpiclu SUNWcarx SUNWcsr SUNWefcr SUNWfruip SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWpiclu SUNWpstl SUNWpstlx SUNWsfdr SUNWsfdrr
Patch: 113471-07 Obsoletes: 115484-01 Requires: Incompatibles: Packages: SUNWcpcu SUNWcsu SUNWcsxu SUNWesu SUNWesxu SUNWmdb SUNWrcapu SUNWrmwbu SUNWscpu SUNWtnfc SUNWtoo SUNWtoox
Patch: 113493-02 Obsoletes: Requires: 112874-18 Incompatibles: Packages: SUNWcsl SUNWcslx SUNWmdb SUNWmdbx
Patch: 114371-01 Obsoletes: Requires: Incompatibles: Packages: SUNWmdb SUNWmdbx
Patch: 115010-01 Obsoletes: Requires: Incompatibles: Packages: SUNWhea SUNWkvm SUNWmdb SUNWpstl SUNWpstlx
Patch: 115553-11 Obsoletes: 112836-02 112836-02 115338-01 115557-01 116065-03 115338-01 115557-01 116065-03 117198-02 117382-01 Requires: 112233-12 112954-05 113277-18 114128-02 115004-02 117418-01 Incompatibles: Packages: SUNWcar SUNWcarx SUNWcpr SUNWcprx SUNWcsl SUNWcslx SUNWcstl SUNWcstlx SUNWcsu SUNWcsxu SUNWhea SUNWmdb SUNWmdbx SUNWusb SUNWusbu SUNWusbx
Patch: 115553-20 Obsoletes: 112836-02 115338-01 115557-01 116065-03 117198-02 117382-01 115004-02 117196-01 Requires: 114128-02 113277-18 118558-18 114332-04 112954-05 112233-12 117418-01 Incompatibles: Packages: SUNWcar SUNWcarx SUNWcpr SUNWcprx SUNWcsl SUNWcslx SUNWcstl SUNWcstlx SUNWcsu SUNWcsxu SUNWhea SUNWmdb SUNWmdbx SUNWusb SUNWusbu SUNWusbx
Patch: 115559-01 Obsoletes: Requires: Incompatibles: Packages: SUNWmddr
Patch: 116092-04 Obsoletes: Requires: Incompatibles: Packages: SUNW1394x SUNWcsr SUNWmdr SUNWusb SUNWusx
Patch: 116478-01 Obsoletes: 116075-01 Requires: Incompatibles: Packages: SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWpstl SUNWpstlx
Patch: 116534-01 Obsoletes: Requires: Incompatibles: Packages: SUNWmdau
Patch: 116561-02 Obsoletes: 114388-05 116439-01 116492-01 117297-01 117425-01 Requires: 112233-12 Incompatibles: Packages: SUNWcarx SUNWcsr SUNWdmfex SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWpstl SUNWpstlx
Patch: 116561-13 Obsoletes: 114388-05 116439-01 116492-01 117297-01 117425-01 Requires: 112233-12 Incompatibles: Packages: SUNWcarx SUNWcsr SUNWdmfex SUNWfruip SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWpstl SUNWpstlx
Patch: 116669-18 Obsoletes: 115559-01 119432-01 Requires: 113073-14 Incompatibles: Packages: SUNWhea SUNWmddr SUNWmdr SUNWmdu SUNWmdx
Patch: 116669-32 Obsoletes: 115559-01 119432-01 Requires: 113073-14 Incompatibles: Packages: SUNWhea SUNWmddr SUNWmdr SUNWmdu SUNWmdx
Patch: 117134-01 Obsoletes: Requires: Incompatibles: Packages: SUNWmdr
Patch: 117280-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcsr SUNWmdr
Patch: 117282-03 Obsoletes: Requires: Incompatibles: Packages: SUNWcsr SUNWcti2x SUNWmdr SUNWmdu SUNWusb
Patch: 117420-02 Obsoletes: 117250-01 Requires: Incompatibles: Packages: SUNWmdb SUNWmdbx
Patch: 118558-28 Obsoletes: 112987-01 113543-02 114126-03 114338-01 114378-02 114386-03 114395-03 115994-01 113025-01 113221-03 113574-08 114375-09 114381-06 114465-01 114752-02 114753-02 114765-01 114379-03 114770-03 114930-01 116072-02 116077-01 116416-01 114258-01 114347-01 115526-03 115527-03 114261-04 113488-01 117285-01 117296-01 113573-05 114325-01 114864-02 113447-25 114755-01 114756-01 115663-03 115665-10 117427-08 114721-07 116051-02 119936-01 Requires: 112233-12 113073-14 116532-01 117171-17 Incompatibles: Packages: FJSVhea FJSVpiclu SUNWcar SUNWcarx SUNWcsl SUNWcslx SUNWcsr SUNWcsu SUNWcsxu SUNWefcr SUNWfruip SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWmdbx SUNWpd SUNWpdu SUNWpdx SUNWpiclu SUNWpstl SUNWpstlx SUNWsfdr SUNWsfdrr
Patch: 118558-39 Obsoletes: 112987-01 113543-02 114126-03 114338-01 114378-02 114386-03 114395-03 115994-01 113025-01 113221-03 113574-08 114375-09 114381-06 114465-01 114752-02 114753-02 114765-01 114379-03 114770-03 114930-01 116072-02 116077-01 116416-01 114258-01 114347-01 115526-03 115527-03 114261-04 113488-01 117285-01 117296-01 113573-05 114325-01 114864-02 113447-25 114755-01 114756-01 115663-03 115665-10 117427-08 114721-07 116051-02 119936-01 114757-02 115667-05 117125-03 Requires: 112233-12 113073-14 116532-01 117171-17 Incompatibles: Packages: FJSVhea FJSVpiclu SUNWcar SUNWcarx SUNWcsl SUNWcslx SUNWcsr SUNWcsu SUNWcsxu SUNWefcr SUNWfruip SUNWhea SUNWkvm SUNWkvmx SUNWmdb SUNWmdbx SUNWpd SUNWpdu SUNWpdx SUNWpiclu SUNWpstl SUNWpstlx SUNWsfdr SUNWsfdrr

Oracle 9.2.0.3.0 patch set for windows - questions

Hi!
I have for that some questions. I have oracle 9.2.0.1.0 on a windows 2003 server running with one local database - no real apllication cluster.
I don't understand which instructions I have to make for oracle upgrade?
Must I also make the 3. instruction? Connect to databse prior and drop?
Must I also make the post install action for my database?
(startup migrate ...)
what means at post install actions the following:
'execute these post install actions only if you have one or more databases associated to the upgraded $oracle_homee.
My database path is e:\oracle\oradata\database my oracle path is e:\oracle\ora92 have I in my case make the post install actions?
Thanks for help!
1. When applying this patchset on Windows NT, XP or Windows 2000, you must log onto the system as a user with Administrative privileges
(e.g. as a user which is a member of the local Administrators group).
2. Unzip the downloaded patch set file into a new directory.
3. Drop the xmlconcat function by running the following commands:
drop public synonym xmlconcat;
drop function xmlconcat;
4. Shut down any existing Oracle Server instances in the ORACLE_HOME to be patched with normal or immediate priority. i.e.: Shutdown all instances (cleanly). Stop the database services, and stop all listener, agent and other Oracle processes running in or against the ORACLE_HOME to be installed into.
5. Perform the following pre-install steps for Real Application Clusters (RAC) enviroments only:
IN ADDITION TO STOPPING ALL ORACLE SERVICES IN THE ORACLE_HOME TO BE UPGRADED:
If you are running in a RAC enviroment, stop the following Windows service(s)/devices(s) using the Net Stop command:
Stop the Windows service named "OracleGSDService"
Stop the Windows service named "OracleCMService9i".
Stop the Windows device named "OraFenceService" (This Device does NOT show up as a Service in the Control Panel).
For Example:
C:\>net stop OracleGSDService
C:\>net stop OracleCMService9i
C:\>net stop OraFenceService
Once the above steps have been performed on all the nodes of the cluster, you should then be able to upgrade the OSD components to the 9.2.0.3 versions. This can be accomplished by...
xcopy all the files in the \Disk1\preinstall_rac\osd\*.* directory to the directory in which the OSD components were originally installed on all nodes(typically %SystemRoot%\system32\osd9i).
Note: You may also be able to look in HKEY_LOCAL_MACHINE\Software\Oracle\OSD9i registry key to determine the directory in which the original OSD components were installed. Now the OSD components can be restarted on all the nodes in the cluster.
C:\>net start OraFenceService
C:\>net start OracleCMService9i
C:\>net start OracleGSDService
After all of the above steps have been completed on all the nodes of the cluster, you are now ready to proceed with the Oracle 9.2.0.3.0 patchset installation.
6. Start the installer:
If the current Installer version is less than 2.2.0.18.0 then download the Installer 2.2.0.18.0 from Oracle Metalink where it can be accessed with the bug number 2878462 and choosing the MS Windows NT/2000 Server platform, then run the setup.exe 2.2.0.18.0 from the C:\Program Files\Oracle\oui\install directory .
7. You may install the Patch Set through either an interactive or a silent installation.
To perform an interactive installation using the Oracle Universal Installer graphical interface:
1. Start the installer from the newly installed OUI 2.2.0.18.0 by running the version of setup.exe located at C:\Program Files\Oracle\oui\install and verify
that the version of the OUI GUI is 2.2.0.18.0 before proceeding.
2. Follow the steps given below within the installer:
1. On the Welcome screen, click the Next button. This will display the File Locations screen.
2. Click the Browse button for the Source... entry field and navigate to the stage directory where you unpacked
the Patch Set tar file.
3. Select the products.jar file. Click the Next button
The products file will be read and the installer will load the product definitions.
The products to be loaded will be displayed (verify ORACLE_HOME setting for this first).
4. Verify the products listed and then click on the Install button.
5. Once the installation has completed successfully, it will display End of Installation. Click on Exit and confirm
to exit the installer.
To perform a silent installation requiring no user intervention:
1. Copy the response file template provided in the response directory where you unpacked the Patch
Set tar file.
2. Edit the values for all fields labeled as "<Value Required>" according to the comments and examples
in the template.
3. From the unzipped patchset installation area, start the installer by running the setup executable passing
as the last argument the full path of the response file template you have edited locally with your own
value of ORACLE_HOME and FROM_LOCATION:
setup.exe -silent -responseFile <full_path_to_your_response_file>
Post Install Actions
Execute these "Post Install Actions" only if you have one or more databases associated to the upgraded $ORACLE_HOME.
Important Notes
1: Java VM and XML DB Requirements
Users who have JVM (Java enabled) or JVM and XDB installed on their 9.2.0.1 databases should make sure that the init.ora parameters shared_pool_size and java_pool_size are each 150 MB or more before running the catpatch.sql upgrade script. Failure to do so could result in an unrecoverable memory failure during running of the script. Please note that JVM and XML DB was shipped as part of the default 9.2.0.1 seed database and will be present unless the user explicitly installed a 9.2.0.1 instance without them.
2: SYSTEM table space
If you have JServer installed in the database, you should check to be sure there is at least 10M of free space in the SYSTEM table space before running these actions.
3: Installing on Cluster Databases
If you are applying this patch set to a cluster database, then set the CLUSTER_DATABASE initialization parameter to false. After the post-install actions are completed, you must set this initialization parameter back to true.
To complete the installation of this patch set, you need to start up each database associated with the upgraded $ORACLE_HOME, start the database listener (e.g., lsnrctl start), login using SQL*Plus (e.g., sqlplus "/ as sysdba"), and run the following commands/scripts in order from $ORACLE_HOME within a MIGRATE session. If you are using the OLAP option, make sure that the database listener is up.
startup migrate
spool patch.log
@rdbms/admin/catpatch.sql
spool off
Review the patch.log file for errors and re-run the catpatch script after correcting any problems
shutdown
startup
This step is optional - it will recompile all invalid PL/SQL packages now rather than when accessed for the first time - you can also use utlrcmp.sql to parallelize this in multiprocessor machines:
@rdbms/admin/utlrp.sql
Execute the following if you use Oracle OLAP option:
alter user olapsys identified by <password> account unlock
connect olapsys/<password>
@cwmlite/admin/cwm2awmd.sql
exit
Execute the following script only if you have version 9.2.0.1.0 of Oracle Internet Directory installed in your ORACLE_HOME. Make sure that the database and database listener are running and that all parameters are specified prior to running the script:
$ORACLE_HOME/bin/oidpatchca.bat
-connect <Connect String>
-lsnrport <Listener Port>
-systempwd <SYSTEM Password>
-odspwd <ODS Password>
-sudn <Super-User DN>
-supwd <Super-User Password>
-dippwd <Password to register DIP Server>
Where:
connect - Database connect string
lsnrport - Database Listener port
systempwd - Password of the database 'SYSTEM' user
odspwd - Password of the database 'ODS' user
sudn - Super-user DN
supwd - Super-user Password
dippwd - New password to register Directory Integration Server. This password must conform to the password policy in the OID server
Execute the following steps only is you are using the RMAN catalog.:
rman catalog <user/passwd@alias>
upgrade catalog;
upgrade catalog;

I don't understand which instructions I have to make for oracle upgrade?
-- You have to follow all the instructions mentioned
(Just check for few if's for Cluster enabled, OID and OLAP databases. Perform these steps only if they apply)
Must I also make the 3. instruction? Connect to databse prior and drop?
-- Yes you should do
Must I also make the post install action for my database?
(startup migrate ...)
-- Yes. Do run catpatch.sql .
what means at post install actions the following:
'execute these post install actions only if you have one or more databases associated to the upgraded $oracle_homee.
-- In this step make sure you do step 1
1: Java VM and XML DB Requirements
Otherwise catpatch.sql will fail.
Do 2 and 3 only if applicable
Chandar
My database path is e:\oracle\oradata\database my oracle path is e:\oracle\ora92 have I in my case make the post install actions?

Sun cluster patch for solaris 10 x86

I have Solaris 10 6/06 installed on x4100 box with 2 node clustering using Sun Cluster 3.1 8/05. I just want to know is there any latest patches available for the OS to prevent cluster related bugs. what are they? My kernel patch is 118855-19.
any inputs needed. let me know.

Well, I would run S10 updatemanager and get the latest patches that way.
Tim
---

Sun Cluster + meta set shared disks -

Guys, I am looking for some instructions that most sun administrators would mostly know i believe.
I am trying to create some cluster resource groups and resources etc., but before that i am creating the file systems that is going to be used by two nodes in the sun cluster 3.2. we use SVM.
I have some drives that i plan to use for this specific cluster resource group that is yet to be created.
i know i have to create a metaset since thats how other resource groups in my environment are setup already so i will go with the same concept.
# metaset -s TESTNAME
Set name = TESTNAME, Set number = 5
Host Owner
server1
server2
Mediator Host(s) Aliases
server1
server2
# metaset -s TESTNAME -a /dev/did/dsk/d15
metaset: server1: TESTNAME: drive d15 is not common with host server2
# scdidadm -L | grep d6
6 server1:/dev/rdsk/c10t6005076307FFC4520000000000004133d0 /dev/did/rdsk/d6
6 server2:/dev/rdsk/c10t6005076307FFC4520000000000004133d0 /dev/did/rdsk/d6
# scdidadm -L | grep d15
15 server1:/dev/rdsk/c10t6005076307FFC4520000000000004121d0 /dev/did/rdsk/d15
Do you see what i am trying to say ? If i want to add d6 in the metaset it will go through fine, but not for d15 since it shows only against one node as you see from the scdidadm output above.
Please Let me know how i share the drive d15 same as d6 with the other node too. thanks much for your help.
-Param
Edited by: paramkrish on Feb 18, 2010 11:01 PM

Hi, Thanks for your reply. You got me wrong. I am not asking you to be liable for the changes you recommend since i know thats not reasonable while asking for help. I am aware this is not a support site but a forum to exchange information that people already are aware of.
We have a support contract but that is only for the sun hardware and those support folks are somewhat ok when it comes to the Solaris and setup but not that experts. I will certainly seek their help when needed and thats my last option. Since i thought this problem that i see is possibly something trivial i quickly posted a question in this forum.
We do have a test environment but that do not have two nodes but a 1 node with zone clusters. hence i dont get to see this similar problem in the test environment and also the "cldev populate" would be of no use as well to me if i try it in the test environment i think since we dont have two nodes.
I will check the logs as you suggested and will get back if i find something. If you have any other thoughts feel free to let me know ( dont bother about the risks since i know i can take care of that ).
-Param

Sun cluster upgrade

Any one did an upgrade from Sun cluster 3.0 07/01 release to 12/01 release
was there any problem in the upgrade and what was the approach
any suggestion

This upgrade is delivered as a patch set and some
additional packages. The upgrade procedure is
basically the same as a normal patch procedure.
You might consider getting the latest core Sun Cluster
patch as well, just to be sure you are at the latest rev.
The additional packages provide new features. The
most popular is the Generic Data Service which can
really save development time for simple agents.
-- richard

Tmboot fails started by a Sun Cluster Agent (Data Service)

Hi,
we are using TUXEDO 6.5 in conjunction with ADC's Singl.eView.
Starting TUXEDO by calling tmboot -y works fine in the command prompt.
Starting TUXEDO within a Sun Cluster Agent, which internaly calls tmboot -y as
well, fails with the foolowing error messages:
004859.lbgas1!GWTDOMAIN.5762: 08022002: TUXEDO Version 6.5 SunOS 5.5.1 Generic_103640-29
sun4u sparc SUNW,Ultra-1.
004859.lbgas1!GWTDOMAIN.5762: LIBTUX_CAT:262: INFO: Standard main starting
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1223: WARN: Reach system open max(0)
limit
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1122: ERROR: Unable to allocate free
fd structure
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1124: ERROR: Unable to open listening
endpoint
004901.lbgas1!GWTDOMAIN.5762: LIBTUX_CAT:250: ERROR: tpsvrinit() failed
ubbconfig entries for GWTDOMAIN:
GWTDOMAIN SRVGRP="GWADMGROUP" SRVID=2
REPLYQ = N
RESTART = Y
GRACE = 0
MAXGEN = 5
CLOPT = ""
RQADDR = "GWADMGROUP"
What configuration do I have to change, a TUXEDO one or Sun ?
Can I drop an application server in ubbconfig ?
Lutz

Patch #232, CR041488 seems to address this:
GWTDOMAIN connection problem when maxfiles kernel parm set > 32K
Perhaps the Cluster Agent sets a higher ulimit when it runs.
See if you are running the latest patch.
Scott Orshan
Lutz wrote:
>
Hi,
we are using TUXEDO 6.5 in conjunction with ADC's Singl.eView.
Starting TUXEDO by calling tmboot -y works fine in the command prompt.
Starting TUXEDO within a Sun Cluster Agent, which internaly calls tmboot -y as
well, fails with the foolowing error messages:
004859.lbgas1!GWTDOMAIN.5762: 08022002: TUXEDO Version 6.5 SunOS 5.5.1 Generic_103640-29
sun4u sparc SUNW,Ultra-1.
004859.lbgas1!GWTDOMAIN.5762: LIBTUX_CAT:262: INFO: Standard main starting
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1223: WARN: Reach system open max(0)
limit
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1122: ERROR: Unable to allocate free
fd structure
004901.lbgas1!GWTDOMAIN.5762: LIBGWT_CAT:1124: ERROR: Unable to open listening
endpoint
004901.lbgas1!GWTDOMAIN.5762: LIBTUX_CAT:250: ERROR: tpsvrinit() failed
ubbconfig entries for GWTDOMAIN:
GWTDOMAIN SRVGRP="GWADMGROUP" SRVID=2
REPLYQ = N
RESTART = Y
GRACE = 0
MAXGEN = 5
CLOPT = ""
RQADDR = "GWADMGROUP"
What configuration do I have to change, a TUXEDO one or Sun ?
Can I drop an application server in ubbconfig ?
Lutz

Sun Cluster 3.0 update 1 on Solaris 8 - panics!

I am building a test system in our lab on admittedly unsupported hardware configurations but the failure wasn't expected to be so dramatic. Setup as follows:
2x E250 (single processor, 512 MB RAM)
dual connected to D1000 fully populated 18 Gb HDD
Solaris 8 6/00 with all latest recommended patches
Sun Cluster 3.0 update 1 installed with latest patches.
On first reboot (on either node), the kernel panics with the following:
panic[cpu0]/thread=3000132c320: segkp_fault: accessing redzone
This happens straight after the system sets up the network and happens like that everytime and is easily reproduceable. My question is, has anyone successfully used SC3.0 update 1 on Solaris 8 6/00? Any information would be most appreciated.
-chris.

We have the same problem with 2 SUN E420 and a D1000 storage array.
The problem is releted to the settings on the file :
/etc/system
added by the cluster installation :
set rpcmod:svc_default_stksize=0x4000
set ge:ge_intr_mode=0x833
the second one line try to set a Gigabit Ethernet Interface that does not exist.
We comment out the two line and every things work fine.
I'm interesting to know what you think about Sun Cluster 3.0. and your experience.
email : [email protected]
Stefano

Does sun Cluster 3.0/3.1 HA Oracle agent support to use Oracle spfile?

When defining the resource, the 'parameter_file' properties is usually sets to the Oracle pfile. Is it possible to use Oracle spfile?
It is said if leaving 'parameter_file' NULL, it will be default to Oracle default. Suppose leaving it NULL and with Oracle spfile created in default location, will it use the spfile?

You did not specify which Sun Cluster version and Oracle version you are running.
Within SC 3.1 my understanding is that beginning with Oracle 9i it is possible to use the spfile.
If you leave the "parameter_file" property empty (NULL) then the default behaviour for 9i should work:
search under $ORACLE_HOME/dbs in the order:
1. spfile$(ORACLE_SID}.ora
2. spfile.ora
3. init${ORACLE_SID}.ora
Greets
Thorsten

Error when installing 9.0.1.4.0 patch set for the Oracle Database Server.

Hi to all.
Currently, i am trying to install patches for portal server.
The server OS is Sun Solaris 8.
We are using Oracle9iAS.
Now, we are installing 9.0.1.4.0 patch set for the Oracle Database Server.
We managed to install the patch, but have problem with the Post Install Action.
We managed to run
-ALTER SYSTEM ENABLE RESTRICTED SESSION;
-@rdbms/admin/catpatch.sql
-ALTER SYSTEM DISABLE RESTRICTED SESSION;
-CONNECT / AS SYSDBA
-update obj$ set status=5 where type#=29 and owner#!=0;
-commit;
But, when we come to the next command, which is to shutdown, it gives us like
this..
SQL> update obj$ set status=5 where type#=29 and owner#!=0;
1402 rows updated.
SQL> commit;
Commit complete.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed tables/views only
We tried to startup the database..it gives us this error..
SQL> startup
ORA-01081: cannot start already-running ORACLE - shut it down first
So, we tried to shutdown again..
SQL> shutdown immediate
ORA-01089: immediate shutdown in progress - no operations are permitted
I been informed that this is maybe a Database problem related. Any ideas?
Best Wishes,
Rushdan Md Saad.

Patchsets could be obtained (only) from http://metalink.oracle.com
You need to have valid CSI for access.
P.S: Sorry Werner, I didn't see you post.
Message was edited by:
Ivan Kartik

Encountered ora-29701 during Sun Cluster for Oracle RAC 9.2.0.7 startup (UR

Hi all,
Need some help from all out there
In our Sun Cluster 3.1 Data Service for Oracle RAC 9.2.0.7 (Solaris 9) configuration, my team had encountered
ora-29701 *Unable to connect to Cluster Manager*
during the startup of the Oracle RAC database instances on the Oracle RAC Server resources.
We tried the attached workaround by Oracle. This workaround works well for the 1^st time but it doesnt work anymore when the server is rebooted.
Kindly help me to check whether anyone encounter the same problem as the above and able to resolve. Thanks.
Bug No. 4262155
Filed 25-MAR-2005 Updated 11-APR-2005
Product Oracle Server - Enterprise Edition Product Version 9.2.0.6.0
Platform Linux x86
Platform Version 2.4.21-9.0.1
Database Version 9.2.0.6.0
Affects Platforms Port-Specific
Severity Severe Loss of Service
Status Not a Bug. To Filer
Base Bug N/A
Fixed in Product Version No Data
Problem statement:
ORA-29701 DURING DATABASE CREATION AFTER APPLYING 9.2.0.6 PATCHSET
*** 03/25/05 07:32 am ***
TAR:
PROBLEM:
Customer applied 9.2.0.6 patchset over 9.2.0.4 patchset.
While creating the database, customer receives following error:
ORA-29701: unable to connect to Cluster Manager
However, if customer goes from 9.2.0.4 -> 9.2.0.5 -> 9.2.0.6, the problem does not occur.
DIAGNOSTIC ANALYSIS:
It seems that the problem is with libskgxn9.so shared library.
For 9.2.0.4 -> 9.2.0.5 -> 9.2.0.6, the install log shows the following:
installActions2005-03-22_03-44-42PM.log:,
[libskgxn9.so->%ORACLE_HOME%/lib/libskgxn9.so 7933 plats=1=>[46]langs=1=> en,fr,ar,bn,pt_BR,bg,fr_CA,ca,hr,cs,da,nl,ar_EG,en_GB,et,fi,de,el,iw,hu,is,in, it,ja,ko,es,lv,lt,ms,es_MX,no,pl,pt,ro,ru,zh_CN,sk,sl,es_ES,sv,th,zh_TW, tr,uk,vi]]
installActions2005-03-22_04-13-03PM.log:, [libcmdll.so ->%ORACLE_HOME%/lib/libskgxn9.so 64274 plats=1=>[46] langs=-554696704=>[en]]
For 9.2.0.4 -> 9.2.0.6, install log shows:
installActions2005-03-22_04-13-03PM.log:, [libcmdll.so ->%ORACLE_HOME%/lib/libskgxn9.so 64274 plats=1=>[46] langs=-554696704=>[en]] does not exist.
This means that while patching from 9.2.0.4 -> 9.2.0.5, Installer copies the libcmdll.so library into libskgxn9.so, while patching from 9.2.0.4 -> 9.2.0.6 does not.
ORACM is located in /app/oracle/ORACM which is different than ORACLE_HOME in customer's environment.
WORKAROUND:
Customer is using the following workaround:
cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk rac_on ioracle ipc_udp
RELATED BUGS:
Bug 4169291

Check if following MOS note helps.
Series of ORA-7445 Errors After Applying 9.2.0.7.0 Patchset to 9.2.0.6.0 Database (Doc ID 373375.1)

File System Sharing using Sun Cluster 3.1

Hi,
I need help on how to setup and configure the system to share a remote file system that is created on a SAN disk (SAN LUN ) between two Sun Solaris 10 servers.
The files in the remote system should be read/writabe from both the solaris servers concurrently.
As a security policy NFS mount is not allowed. Some one suggested it can be done by using Sun Cluster 3.1 agents on both servers. Any details on how I can do this using Sun Cluster 3.1 is really appreciated.
thanks
Suresh

You could do this by installing Sun Cluster on both systems and then creating a global file system on the shared LUN. However, if there was significant write activity on both nodes, then the performance will not necessarily what you need.
What is wrong with the security of NFS? If it is set up properly I don't think this should be a problem.
The other option would be to use shared QFS, but without Sun Cluster.
Regards,
Tim
---

Is forms 10g Patch set 3 (10.1.2.3) released?

Hi All,
I checked metalink for information regarding Patch set 3 (10.1.2.3) and could see none.
Is this released yet?
Thanks
Rajesh ALex

Regarding the size:
There are almost 1200 fixes in the code line and this means that a lot of the code is being touched by fixes, making the patch set large. Since we don't patch individual components any longer we have this situation. It would be good to have a smaller footprint but in the mean time I recommend a download manager to handle the case of an interrupted download.<br>
I tried a download manager the other day called Free Download Manager. It worked really well and it is free as the name implies. I pulled out the network cable to simulate a break and it happily continued from where it left off when the network went down. Until Oracle does what Sun does: incorporate a download manager into the downloads this is a good solution to the problem of interrupted downloads that you have to start from the beginning with.

Patch set on sun cluster

Similar Messages

Maybe you are looking for