Академический Документы
Профессиональный Документы
Культура Документы
Our goal for this hands-on lab is to familiarize you with upgrade best practices.
You’ll have two options – to either upgrade to Oracle Database 11.1.0.7 or 11.2.0.1
Note: if you are really quick and don’t mind to forgo the break, then you should have
enough time to try an upgrade from 10.2.0.3 to 11.1.0.7 followed by an upgrade from
11.1.0.7 to 11.2.0.1. And you may even be able to try a downgrade…
Overview:
In this lab you’ll have the possibility to run several upgrade scenarios. For your planning
please note the following approximate durations:
• Upgrade from 10.2.0.3 to 11.1.0.7: ~22 minutes
• Upgrade from 10.2.0.3 to 11.2.0.1: ~32 minutes
• Upgrade from 11.1.0.7 to 11.2.0.1: ~20 minutes
• Downgrade from 11.2.0.1 to 10.2.0.3: ~38 minutes
• Creation of the EM Repository: ~30 minutes
10.2.0.3
database
Upgrade to Upgrade to
11.1.0.7 11.2.0.1
Comman DBUA
d Line
Environment:
We are using an Oracle Unbreakable Linux 4 installation.
Passwords:
OS user: oracle pw: oracle
OS user: root pw: oracle
DB user: SYS pw: oracle
DB user: SYSTEM pw: oracle
Oracle Installations:
There are 3 Oracle Home directories:
10.2.0.3: /oracle/u01/app/oracle/product/10.2
11.1.0.7: /oracle/u01/app/oracle/product/11.1.0
11.2.0.1: /oracle/u01/app/oracle/product/11.2.0
In case you need to edit the environmental files they are located in /usr/local/bin –
if necessary, edit them as root user.
Documentation:
You’ll find the most important documentation, such as the Database Upgrade Guide,
Upgrade Companion and Complete Checklist for Manual Upgrades on your VMware’s
desktop.
START HERE ==> Preparation steps for all scenarios:
1. Set your environment to your 11.2 installation and start the listener:
. db112
lsnrctl start
2. Set your environment to point to the 10.2 installation and start the ORCL
database:
. db102
sqlplus / as sysdba
SQL> startup
If you encounter orphan rows in KOTTD$ then you should delete them:
4. Check for invalid objects – if there are invalid objects in SYS and/or SYSTEM
user schema, please recompile with SQL> @?/rdbms/admin/utlrp.sql
cd /tmp/PATCH
. db102
opatch apply 5632264
opatch apply 5746875
sqlplus / as sysdba
Run the utltzuv2.sql script to check for any existing TIMEZONE WITH
TIMESTAMP datatypes in your database.
SQL> @?/rdbms/admin/utltzuv2.sql
Normally the output should say: No need to validate TIMEZONE data. If the
output asks you to validate your TIMEZONE data, you should check the
Database Upgrade Guide for further actions.
2. Run the new pre-upgrade check script from within your current SQL*Plus
session and spool the output to a file for later reference:
Now fix any invalid objects found in the following views – these views will be
present after utlu111i.sql has been run.
3. Create dictionary statistics for all admin (SYS, SYSTEM, XDB etc.) users
mentioned by the utlu111i.sql script output – gather_dictionary_stats
does this for all owners of registered components (DBA_REGISTRY):
If you don’t drop them prior to upgrading to 10.2.0.4, 11.1.0.6 or 11.1.0.7 then
the Oracle Server component may become invalid and the database could
generate a core dump during the upgrade. This error happens because of a
non-existing reference in the new SQL Performance Analyzer package
DBMS_SQLPA.
Note: If you already hit the error listed above (because you didn’t drop the
above table and synonym) then you could solve the problem by following
these steps:
5. Start the upgrade – follow either the DBUA (a) or the manual upgrade (b)
path.
a. DBUA
sqlplus / as sysdba
SQL> shutdown immediate
. db111
iv. Start the DBUA and follow all steps – make sure you
explicitly DESELECT the Enterprise Manager Database
Control configuration::
dbua
vi. Please note that the DBUA does not change COMPATIBLE –
to allow you the possibility to downgrade back to 10.2.0.3.
b. Manual upgrade
. db102
sqlplus / as sysdba
SQL> create pfile=’<your_location>’ from
spfile;
SQL> shutdown immediate
iii. Implement all recommendation from the preupgrade check
script utlu111i.sql you’d run in the preparation steps part
to your 10.2 init.ora which should be located now in your
<your_location> directory.
The default setting for the diagnistic_dest is your
$ORACLE_BASE - /oracle/u01/app/oracle – there’ll be
a diag subdirectory.
iv. Check your init.ora/spfile for any “old” parameters and events.
Remove all underscore or unnecessary parameters such
as _always_anti_join=off or
optimizer_features_enable=9.1.0 if they are present.
You should always have just a minumum init.ora for the
upgrade. You’ll be able to add any “tuning” parameters later
on.
. db111
sqlplus / as sysdba
vii. Now run the upgrade script – it’ll do the complete upgrade for
all components. This run will take approximately 20 minutes to
complete.
SQL> @?/rdbms/admin/catuppst.sql
SQL> @?/rdbms/admin/utluiobj.sql
SQL> @?/rdbms/admin/utlu111s.sql
6. Post-upgrade steps:
a. Create a writable copy of your spfile in case you’d like to edit it:
b. Create fixed object stats – in the “real world” you’d do this step a few
days after the upgrade to generate valid stats for X$ tables. Do this
once a month.
Compare detailed IO statistics from before and after. You could easily
revert to the default values with:
If you’d been taken several snapshots before and after the upgrade
you could create AWR Diff reports in HTML or TEXT output by
executing the following steps:
i. Find out the snapshots from before and after the upgrade:
SQL> select snap_id, end_interval_time
from dba_hist_snapshot
where end_interval_time > trunc(sysdate-1)
order by snap_id;
iii. Now you might create diff reports comparing over a period of
time from before and after the upgrade:
1. Run the new pre-upgrade check script from within your current SQL*Plus
session and spool the output to a file for later reference:
You might check now any invalid objects in the new views:
After the upgrade has finished you’ll be able to compare before and after
invalid objects with a new script ?/rdbms/admin/utluiobj.sql.
2. Create statistics for all admin (SYS, SYSTEM, XDB etc.) users mentioned by
the utlu112i.sql script output:
3. Start the upgrade – follow either the DBUA (a) or the manual upgrade (b)
path. If you did upgrade from 10.2.0.3 to 11.1.0.7 before with DBUA then you
should take the manual path now – and vice versa.
a. DBUA
sqlplus / as sysdba
SQL> shutdown immediate
. db112
iv. Start the DBUA and follow all steps – make sure you
explicitly DESELECT the Enterprise Manager Database
Control configuration:
dbua
vi. Please note that the DBUA didn’t change COMPATIBLE – this
would allow you to downgrade back to either 10.2.0.3. or
11.1.0.7 – but you can only downgrade to the release you’ve
recently upgraded from.
b. Manual upgrade
. db102
sqlplus / as sysdba
SQL> create pfile=’<your_location>’ from
spfile;
SQL> shutdown immediate
or:
. db111
sqlplus / as sysdba
SQL> create pfile=’<your_location>’ from
spfile;
SQL> shutdown immediate
. db112
sqlplus / as sysdba
xiii. Now run the upgrade script to upgrade all the components.
This run will take approximately 22-32 minutes to complete.
SQL> @?/rdbms/admin/catuppst.sql
xvi. Compare invalid objects from before and after the upgrade
with the new script utluiobj.sql:
SQL> @?/rdbms/admin/utluiobj.sql
SQL> @?/rdbms/admin/utlu112s.sql
4. Post-upgrade steps:
a. Create a writable copy of your spfile in case you’d like to edit it:
Now datafile headers and redologs (upon first access) will be adjusted
and new features will be enabled.
startup upgrade
exec dbms_dst.begin_upgrade(new_version => 11);
shutdown immediate;
startup;
set serveroutput on;
declare
num_of_failures number;
begin
dbms_dst.upgrade_database(num_of_failures);
dbms_output.put_line(num_of_failures);
dbms_dst.end_upgrade(num_of_failures);
dbms_output.put_line(num_of_failures);
end;
/
d. Create fixed object stats – in the “real world” you would do this step a
few days after the upgrade to generate valid stats for X$ tables. Do
this once a month.
e. You could now generate also System stats to give the optimizer a
good knowledge about your IO system and its capabilities and power.
Before doing this check the aud_stats$
Compare detailed IO statistics from before and after. You could easily
revert to the default values with:
f. You might update now your /etc/oratab file to match with your
current database home.
Downgrade
Downgrading your database could be a valid fallback strategy, in case you hit a scenario
requiring you to go back to the release you upgraded from. Therefore the COMPATIBLE
parameter must not be changed during the upgrade process.
If you created the Enterprise Manager repository then you should drop the users
SYSMAN and DBSNMP before downgrading:
In your current 11.2 environment (in 11.1 it would work the same way):
. db112
SQL> SHUTDOWN IMMEDIATE
SQL> SPOOL /tmp/downgrade.log
SQL> STARTUP DOWNGRADE
SQL> @?/rdbms/admin/catdwgrd.sql
SQL> SPOOL OFF
SQL> SHUTDOWN IMMEDIATE
You need to switch back now to the lower version environment prior to doing the
downgrade reload.
If you had upgraded from 11.1 to 11.2 then do this in your 11.1 environment.
If you had upgraded from 10.2 to 11.2 then do this in your 10.2 environment.
Either:
. db111
or:
. db102
The complete downgrade will complete in approximately ~40 minutes (running the
downgrade script will take approximately 5 minutes, reloading will take approximately 33
minutes).
Enterprise Manager Repository
You could either create the Enterprise Manager repository with Database Configuration
Assistant (DBCA) or manually with Enterprise Manager Configuration Assistant (emca)
on the command line. Please note that this action will take approximately 30 minutes to
complete.
ii. Answer all questions for passwords etc. interactively – note that
the creation will take approximately 30 minutes to complete.
Known errors:
FINISHED!!!
You’re done!!!
Thanks a lot for participating in our Oracle Database Upgrade Hands-On Lab. We hope
you had a successful upgrade experience :-)
Kind regards
Roy Swonger
Development Director Database Upgrades and Utilities
Carol Tagliaferri
Senior Manager Database Upgrades
Cindy Lim
Principal Member Tech Staff Database Upgrade
Mike Dietrich
Principal Member Tech Staff Database Upgrades
Brian McCarthy
Principal Member Tech Staff Database Upgrades
Carol Palmer
Principal Product Manager Database Upgrades