Got an application requirement to stay on the current cluster version but to upgrade the DB which requires OS upgrade. The current OS release is Solaris 10 SPARC 64 (Solaris 10 3/05 s10_74L2a SPARC ) Generic_118822-30. The upgrade is going to be to (Solaris 10 10/09 s10s_u8wos_08a SPARC ) Generic_144488-08.
The database is sitting at :
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options.
Getting upgraded to:
Oracle Database 11g Enterprise Edition Release 188.8.131.52.0 - 64bit Production
PL/SQL Release 184.108.40.206.0 - Production
CORE 220.127.116.11.0 Production
TNS for Solaris: Version 18.104.22.168.0 - Production
NLSRTL Version 22.214.171.124.0 - Production
We have tested the switchover among the 2 nodes (PRODprod1 and PRODprod2 ) which work fine at the moment.
We are planning to do a LU to upgrade to OS to the given solaris release. What I need to know is how the resources would behave onece the upgrade is done in terms of the OS and the DB. We are planning to apply the two patches 120514-04 and 120500-26. The other major concern is the oracle agents ( DB server and listener). Should there be any changes for them to cater to ORACLE 11.2.02 in terms of resource configuration? Any info/thoughts are appreciated.
Actually, there is no reason, in practice, why we should not support 126.96.36.199 on SC3.1 through 3.3. That decision would be taken once any QA work was completed.
It is often the case that users want to minimize the amount of change when performing an upgrade, although I would agree that going to the latest release would have significant benefits in terms of patches incorporated and new features added.
The plan now is to upgrade the cluster version 3.2 or 3.3 in order to have a compatible environment for 188.8.131.52. This is non RAC solution. What is the best aproach to follow ?.
1) upgrade oracle and then upgrade the cluster software
2) upgrade the cluster software and then upgrade to 11.20.2 ?
I would upgrade the cluster s/w first and then once you've run that for a week or so and you are happy that the upgrade is stable, I'd then do the Oracle upgrade. BTW - If I recall correctly, we announced support (on Solaris Cluster) for 184.108.40.206 yesterday, but it currently excludes 220.127.116.11 RAC in zone clusters.
Does Oracle have a defined EOL date for SC 3.1 ?.
After the upgrade can i use the scrgadm -c -j to alter the current oracle resource to point to new 11gr2 ORA_HOME and the listner ? Is this the only parameter setting i should do in order to point it to the new 11gR2 instance ?
I would like to have your thoughts about the database server resource. ( http://pastie.org/private/ah6jfwil6qbfjrdo6bbfw )
One speciific concern i have is the "Parameter_file:", As per my understanding this is picked up automatically when i give the SID and the ORA_HOME. It's the pfile it's pointing to and is there a possibility for me to do a resource re-configuration to do get it to point to the spfile. I'm aware that the spfile could be the only parameter in the pfile which makes the resource call the spfile indirectly. Is this the best aproach in this case.
In general, I don't use the parameter file property. I simply ensure that the ORACLE_HOME, ORACLE_SID, ALERT_LOG_FILE and CONNECT_STRING are set correctly. I doubt the parameter_file property is needed unless you have a non-standard installation of Oracle.
I have the Solaris patch Generic_144488-09 sun4v sparc SUNW,SPARC-Enterprise-T5220 on my server( Sun OS 5.10).
I have some scripts which has "mget" command in it and it stopped working after the patch i believe.
Can someone please help me confirm that the above patch would not allow the "mget" command to work on the server.
Fy! Using just the "get" command works on this server.