Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Oracle 10.2.0. Install

Status
Not open for further replies.

tekpr00

IS-IT--Management
Jan 22, 2008
186
0
0
CA
Hi All,

All my production database is currently using Oracle 10.1.0 we have decided to go to 10.2.0.

Now I am installing the 10.2.0 software on a separate home so that I can point the listenres, oratab, tnsnames to use the 10.2.0 after installation and patching.

I have several questions for any one who has done something similar.

1) what would I do to get other tools to point to this new home 10.2.0. I mean tools like OEM, dbconsole and grid control.

Here are my steps in Summary, please go through it and let me know if I have left something out.

1. install the following:
- Oracle 10.2.0.1 base install software (10gr2_db_sol.cpio.gz)
- Current opatch software (10gr2_db_sol.cpio.gz)
- Oracle 10.2.0.4 patch software (p6810189_10204_Solaris-64.zip)
2. CPUJAN2010 critical patch software (p9119226_10204_Solaris-64.zip) (should plan to install same on the development Cores/Vistas instances)
3. request to have sudo setup so oracle UNIX account can execute the root.sh under the /appl/oracle/10.2.0/ and the orainst.Root.sh under /appl/oracle/oraInventory
4. create /10.2.0 directory under /appl/oracle
5. install Oracle 10.2.0.1 base software as per Oracle instructions into /appl/oracle/10.2.0 directory
6. install opatch software as per Oracle instructions
7. apply 10.2.0.4 patch as per Oracle instructions
8. apply CPUJAN2010 critical patch (i.e. most recent quarterly security patch) as per Oracle instructions
9. Note my server contain two differenct instances hence create two directories under /appl/oracle/10.2.0/admin for the two instances on the machine and create the required empty sub-directories (i.e. bdump, etc.)
10. execute upgrade information tool (stay on /export/home/oracle) to ensure each instance is ready and to determine changes required to init parameters
set ORACLE_SID to XXXXX (where XXXXX = target instance)
in SQLPLUS
> spool upgrade_XXXXX_upgrade_tool.log
> @/appl/oracle/10.2.0.4/rdbms/admin/utlu102i.sql
> spool off
review output and ensure required changes are included at upgrade time
11. The next steps are to switch first instance to the new home.
12. run script to save database links and save output (required for a rollback which we won’t be doing but it doesn’t hurt to have it) - can be done ahead of time
13. run the scripts to generate SQL to rectify CONNECT role deprecation required for step 17 – can be done ahead of time
14. shutdown necessary application components and shutdown first (1_inst) instance and place any scheduled jobs against training database on hold.
15. do a cold backup of 1_inst instance to temporary space previously allocated by SA
16. startup the instance
17. fix users having the CONNECT role with script from step 13
18. shutdown the instance
19. update the 1_inst instance row in oratab file to from /appl/oracle/10.1.0 to /appl/oracle/10.2.0, same in tnsnames and oratab
20. execute . oraenv and enter the ORACLE_SID of the training instance to set the Oracle environment variables (uses entry in oratab file updated in step 13) and execute “env |grep ORA” to verify parameters (i.e. $ORACLE_HOME, etc.) are set correctly


Again I am not sure what to do with OEM, dbconsole and grid control.

Also do I need to set the compability in the inifile? what about all references to 10.1.0 in the init file. Do I need to change them to 10.2.0
 
One issue that occurs to me is that you should verify that you really can install the latest version of opatch in step 6 before applying the 10.2.0.4 patch set in step 7. The patch set no doubt comes with its own version of opatch, and I would expect that it would overwrite whatever was there before the patch set installation. The net result would be that you might end up with a version of opatch that isn't as current as you expect. If so, that might be an issue when applying the January, 2010 CPU in step 8 - CPUs tend to have fairly rigorous requirements about which version of opatch is needed for installation.

So, to be safe, I would either switch the order of steps 6 and 7, or at least run an "opatch version" command after each step to make sure the release level hasn't changed.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top