Вы находитесь на странице: 1из 18

Welcome to the Upgrade Development Group’s Hands-On-Lab

Upgrade to Oracle Database 11g


Organizational things:
The lab will happen in two parts: (Part 1) noon to 1pm and (Part 2) 1:30pm to 2:30pm.
The 30 minute break is optional and up to your discretion.

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…

Let’s get started :-)

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

DBUA Command DBUA Command


Line Line

Upgrade Upgrade Create Down- Create EM Down-


to to EM Repo grade Repo grade
11.2.0.1 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

Switch Oracle environments/homes:


Issue the following commands on the command line, when logged in as user oracle.
This will allow you to switch easily between the three Oracle environments on your
system.
Please note: there’s a <SPACE> between the <dot> and environment alias:

For 10.2.0.3 type in a xterm: . db102


For 11.1.0.7 type in a xterm: . db111
For 11.2.0.1 type in a xterm: . db112

In case you need to edit the environmental files they are located in /usr/local/bin –
if necessary, edit them as root user.

Database and listener:


Information for pre-created 10.2.0.3 database:
SID: ORCL
Location: /oracle/u02/oradata/ORCL

Information for pre-created 11.2.0.1 listener:


Listener: LISTENER
Location: /oracle/u01/app/oracle/product/11.2.0.1/network/admin

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

3. Because of bug:6770913 (see Note:579523.1) make sure you have no orphan


rows in KOTTD$:

SQL> select sys_nc_oid$ from kottd$


where sys_nc_oid$ not in
(select oid$ from obj$ where type#=13);

If you encounter orphan rows in KOTTD$ then you should delete them:

SQL> delete from kottd$ where sys_nc_oid$ not in


(select oid$ from obj$ where type#=13);
commit;

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

SQL> SELECT UNIQUE object_name, object_type, owner


FROM dba_objects WHERE status='INVALID';

5. Don’t forget to purge the recyclebin:

SQL> purge DBA_RECYCLEBIN;

6. Create AWR snapshots before the upgrade:

SQL> EXEC dbms_workload_repository.create_snapshot();

You can check $ORACLE_HOME/dbms/admin/awrinfo.sql and


$ORACLE_HOME/rdbms/admin/awrrpt.sql for existing snapshots and AWR
contents.
Upgrade to 11.1.0.7

1. DST timezone patching to at least TZ V4 is something you’ll have to do for all


database releases <10.2.0.4 to be able to upgrade directly to 11.1.0.6/7. In
this demo we’ve already downloaded the patches 5632264 (containing the
timezlrg.dat and timezone.dat files) and 5746875 (containing utltzuv2.sql) to
your /tmp/PATCH directory.
You’ll have to apply timezone V4 patches prior to upgrade to 11.1.0.7.

cd /tmp/PATCH

Check the readme files.

. db102
opatch apply 5632264
opatch apply 5746875
sqlplus / as sysdba

Restart your database to make sure the patches take effect.

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:

SQL> spool /tmp/utlout.txt


SQL> @<your_11.1_home>/rdbms/admin/utlu111i.sql
SQL> spool off

Timezone should now show V4.


Please ignore the warning saying statistics will have to be gathered for user
SYS – this is a know issue which will be fixed in 11.2.0.2.

Now fix any invalid objects found in the following views – these views will be
present after utlu111i.sql has been run.

SQL> select owner, object_type, substr(object_name,1,40)


from registry$sys_inv_objs;
SQL> select owner, object_type, substr(object_name,1,40)
from registry$nonsys_inv_objs;
After the upgrade has finished you’ll be able to compare before and after
invalid objects with a new script ?/rdbms/admin/utluiobj.sql.

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):

SQL> EXECUTE dbms_stats.gather_dictionary_stats;

4. Drop a possibly existing table SYS.PLAN_TABLE$ and the public synonym


PUBLIC.PLAN_TABLE

See Alert-Note:782735.1 and Notes: 605317.1 and 736353.1 for more


information after the lab.

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:

@catplan.sql -- recreate the plan table


@dbmsxpln.sql -- reload dbms_xplan spec
@prvtxpln.plb -- reload dbms_xplan implementation
@prvtspao.plb -- reload dbms_sqlpa
alter package SYS.DBMS_SUMADVISOR compile ;
alter package SYS.DBMS_SUMADVISOR compile body;

5. Start the upgrade – follow either the DBUA (a) or the manual upgrade (b)
path.

a. DBUA

i. Normally we’d ask you to do an online backup with RMAN


prior to the upgrade – due to time restrictions we’ll skip this
step now. In a real upgrade scenario, it is extremely important
to do a backup in your real environment before the upgrade.
Even though the DBUA allows you to take an offline backup for
later automatic restoration in case of a failure, you should this
step.
ii. It’s a best practice to shutdown your database in your current
environment before switching to the new environment to
upgrade the database with DBUA:

sqlplus / as sysdba
SQL> shutdown immediate

iii. Change your Oracle environment to point to your 11.1.0.7


$ORACLE_HOME:

. db111

iv. Start the DBUA and follow all steps – make sure you
explicitly DESELECT the Enterprise Manager Database
Control configuration::

dbua

v. If you get several ORA-4043 errors during the upgrade please


hit IGNORE multiple times and refer to the KNOWN ERRORS
section on the last page of the lab instructions for further
information.

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

i. Normally we would recommend an online backup with RMAN


prior to the upgrade – but due to time restrictions, we’ll skip
this step now. But never ever forget to do a backup now in
your real environment. Even though the DBUA allows you to
take an offline backup for later automatic restoration in case of
a failure you should skip this here.

ii. Create a writable copy of your spfile and shutdown your


database in the 10.2 environment:

. 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.

v. Change your Oracle environment to point to your 11.1.0.7 $OH


and connect with SQL*Plus:

. db111
sqlplus / as sysdba

vi. Do a startup upgrade – check the NEW alert.log in your


diagnostic_dest located under
$ORACLE_BASE/diag/rdbms/orcl/ORCL/trace for things
happening now in the background. At this stage we supress
also useless errors such as ORA-942 from the upgrade
scripts.

SQL> startup upgrade pfile=’<your_location>’


SQL> create spfile from
pfile=’<your_location>’;
tail –f <path>/alert_ORCL.log

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> spool /tmp/utl_111_out.txt


SQL> set echo on
SQL> set termout on
SQL> @?/rdbms/admin/catupgrd.sql
SQL> spool off
viii. Once the script has finished it’ll shutdown the database.
Restart it and run the recompilation script utlrp.sql. You might
check from a 2nd SQL*Plus session the progress –
utlrp.sql will display the queries. As a best practice it
might be a good idea at this stage to create fixed objects (X$
tables) stats – this will speed up the job generation for the
parallel recompilation:

SQL> exec dbms_stats.gather_fixed_objects_stats;


SQL> @?/rdbms/admin/utlrp.sql

ix. At the same time – or afterwards – you should run catuppst.sql


for some sanity operations to AWR and ADDM:

SQL> @?/rdbms/admin/catuppst.sql

x. Compare invalid objects from before and after the upgrade


with the new script utluiobj.sql:

SQL> @?/rdbms/admin/utluiobj.sql

xi. Check the upgrade success with utlu111s.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:

SQL> create pfile=’initORCL_new.ora’ from spfile

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.

SQL> exec dbms_stats.gather_fixed_objects_stats;


c. You could now generate also System stats t give the optimizer a good
knowledge about your IO system and its capabilities and power.
Before doing this check the aud_stats$

SQL> select * from aux_stats$;


SQL> exec dbms_stats.gather_system_stats(‘START’);

Now issue a few queries and statements generating IO (such as


CREATE TABLE test123 AS SELECT * FROM OBJ$; etc.

SQL> exec dbms_stats.gather_system_stats(‘STOP’);


SQL> select * from aux_stats$;

Compare detailed IO statistics from before and after. You could easily
revert to the default values with:

SQL> exec dbms_stats.delete_system_stats;

d. Create AWR snapshots after the upgrade:

SQL> EXEC dbms_workload_repository.create_snapshot();

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;

ii. Find out your DBID:

SQL> select dbid from v$database;

iii. Now you might create diff reports comparing over a period of
time from before and after the upgrade:

SQL> select * from


TABLE(DBMS_WORKLOAD_REPOSITORY.
awr_diff_report_html
(<dbid>,1,<beg_snap_bef>,<end_snap_bef>,
<dbid>,1,<beg_snap_aft>,<end_snap_aft>));

SQL> select * from


TABLE(DBMS_WORKLOAD_REPOSITORY.
awr_diff_report_text
(<dbid>,1,<beg_snap_bef>,<end_snap_bef>,
<dbid>,1,<beg_snap_aft>,<end_snap_aft>));
Upgrade to 11.2.0.1

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:

SQL> spool /tmp/utlout.txt


SQL> @<your_11.2_home>/rdbms/admin/utlu112i.sql
SQL> spool off

A timezone version change is not necessarily needed for an upgrade to 11.2.


You’ll use the DBMS_DST package afterwards to check and change any
timezone data in the database.
Please ignore the warning saying statistics will have to be gathered for user
SYS – this is a know issue which will be fixed in 11.2.0.2.

You might check now any invalid objects in the new views:

SQL> select owner, object_type, substr(object_name,1,40)


from registry$sys_inv_objs;
SQL> select owner, object_type, substr(object_name,1,40)
from registry$nonsys_inv_objs;

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:

SQL> EXECUTE dbms_stats.gather_dictionary_stats;


SQL> EXECUTE dbms_stats.gather_schema_stats(‘...’);

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

i. Normally we’d ask you to do an online backup with RMAN


prior to the upgrade – due to time restrictions we’ll skip this
step now. But never ever forget to do a backup now in your
real environment. Even though the DBUA allows you to take
an offline backup for later automatic restoration in case of a
failure you should skip this here.
ii. It’s a best practice to shutdown your database in your current
environment before switching to the new environment to
upgrade the database with DBUA:

sqlplus / as sysdba
SQL> shutdown immediate

iii. Change your Oracle environment to point to your 11.2.0.1


$ORACLE_HOME:

. db112

iv. Start the DBUA and follow all steps – make sure you
explicitly DESELECT the Enterprise Manager Database
Control configuration:

dbua

v. If you get several ORA-4043 errors during the upgrade please


hit IGNORE multiple times and refer to the KNOWN ERRORS
section on the last page of this lab instructions for further
information.

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

vii. Normally you would do an online backup with RMAN prior to


the upgrade but due to time restrictions we’ll skip this step
now. But never ever forget to do a backup at this point in your
real environment.

viii. Create a writable copy of your spfile and shutdown your


database in the 10.2 or 11.1 environment.
Either:

. 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

ix. Implement all recommendations from the pre-upgrade check


script utlu112i.sql that you would run in the preparation
steps part of your 10.2 or 11.1 init.ora (located in
<your_location> ).

The default setting for the diagnistic_dest is your


$ORACLE_BASE - /oracle/u01/app/oracle – there’ll be
a diag subdirectory.

x. 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.

xi. Change your Oracle environment to point to your 11.2.0.1 $OH


and connect with SQL*Plus:

. db112
sqlplus / as sysdba

xii. Do a startup upgrade – check the NEW alert.log in your


diagnostic_dest located under
$ORACLE_BASE/diag/rdbms/orcl/ORCL/trace for things
happening now in the background. At this stage we supress
also useless errors such as ORA-942 from the upgrade
scripts.

SQL> startup upgrade pfile=’<your_location>’


SQL> create spfile from
pfile=’<your_location>’;
tail –f <path>/alert_ORCL.log

xiii. Now run the upgrade script to upgrade all the components.
This run will take approximately 22-32 minutes to complete.

SQL> spool /tmp/utl_112_out.txt


SQL> set echo on
SQL> set termout on
SQL> @?/rdbms/admin/catupgrd.sql
SQL> spool off
xiv. Once the script has finished, it will shutdown the database.
Restart the database in normal mode and run the
recompilation script utlrp.sql. You might check the progress of
this command from a 2nd SQL*Plus session – utlrp.sql
will display the queries. As a best practice, we suggest
creating fixed objects (X$ tables) stats – this will speed up the
job generation for the parallel recompilation:

SQL> exec dbms_stats.gather_fixed_objects_stats;


SQL> @?/rdbms/admin/utlrp.sql

xv. At the same time – or afterwards – you should run catuppst.sql


for some sanity operations to AWR and ADDM:

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

xvii. Check the upgrade success with utlu112s.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:

SQL> create pfile=’initORCL_new.ora’ from spfile

b. If you don’t plan to downgrade you could change the COMPATIBLE


parameter now to have all 11.2 features enabled. Normally we advise
customers to take a complete online backup with RMAN prior to this
action, but to save time in this lab, you can do it without a backup:

SQL> alter system set compatible=’11.2.0’


scope=spfile;
SQL> shutdown immediate
SQL> startup

Now datafile headers and redologs (upon first access) will be adjusted
and new features will be enabled.

c. If you have received a timezone hint during the pre-upgrade check or


within DBUA you should now convert any existing TIMESTAMP WITH
TIMEZONE data in your database with the new Oracle Database 11.2
package DBMS_DST:

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;
/

You’ll find more information about the use of DBMS_DST package in


the Oracle Globalization Guide – a link from the Upgrade Guide leads
you there, too.

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.

SQL> exec dbms_stats.gather_fixed_objects_stats;

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$

SQL> select * from aux_stats$;


SQL> exec dbms_stats.gather_system_stats(‘START’);

Now issue a few queries and statements generating IO (such as


CREATE TABLE test123 AS SELECT * FROM OBJ$; etc.

SQL> exec dbms_stats.gather_system_stats(‘STOP’);


SQL> select * from aux_stats$;

Compare detailed IO statistics from before and after. You could easily
revert to the default values with:

SQL> exec dbms_stats.delete_system_stats;

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:

SQL> drop user SYSMAN cascade;


SQL> drop user DBSNMP cascade;

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

SQL> STARTUP UPGRADE


SQL> SPOOL /tmp/reload.log
SQL> @?/rdbms/admin/catrelod.sql
-- The catrelod.sql script reloads the appropriate version of
-- all of the database components in the downgraded database.
SQL> SPOOL OFF

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.

1. EM Repository creation with DBCA

i. Choose configure options:

ii. Create the EM Repository:

2. Creation with emca on the command line:

i. emca –config dbcontrol –repos create

ii. Answer all questions for passwords etc. interactively – note that
the creation will take approximately 30 minutes to complete.
Known errors:

Upgrade from 10.2.0.3 to 11.1.0.7

• ORA-4043: object XDB_DATASTORE_PROC does not exist.


You’ll IGNORE this error – Oracle Text is not installed to speed up the upgrade
time – this is a known behaviour described in Note: 360907.1

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

Вам также может понравиться