1 Copyright © 2011, Oracle and/or its affiliates. All rights ... Database...7 Copyright © 2011,...

1 Copyright © 2011, Oracle and/or its affiliates. All rights

reserved.


reserved.

Best Practices for Upgrading Oracle

Database to 11g Release 2

Agrim Pandit & Anil Chanda

Global Customer Support, Oracle


reserved.


reserved.

The following is intended to outline our general product direction.

It is intended for information purposes only, and may not be

incorporated into any contract. It is not a commitment to deliver

any material, code, or functionality, and should not be relied upon

in making purchasing decisions. The development, release, and

timing of any features or functionality described for Oracle’s

products remains at the sole discretion of Oracle.


reserved.

Agenda

• Why Upgrade? ROI

• What is Upgrade?

• 10 Best Practices

• Common Issues

• Real World Examples

• Q&A


reserved.

Why Upgrade? • Oracle Database 11g R2 is fully proven

– In production for 2+ years

– Thousands of customers have already upgraded

• New features of Oracle Database 11gR2

– Useful and desirable for your environment . Potential cost saver

• Oracle support period will be for long time

– 11gR2 will be supported till Jan 2015 on Premier Support and

– Jan 2018 on Extended Support (Oracle Lifetime Support)

• Extended Support fee can be avoided

– No bug fixes unless you pay extra support fee to get extended support for critical Issues for another year- "Wake

Up Call"

• Patchset, CPU, PSUs and other bug fixes

– It is essential to have the most current security fixes. And you'll get them only during the premier support period

unless you pay extra for extended support.


reserved.

Why Upgrade Continued… 11gR2 gives you 6+ years of premier support


reserved.

What is Upgrade?

• Upgrade is the process of changing the data dictionary contents of a database to reflect a particular release of the

server.

• For each version of the database we support upgrades and downgrades from a specific set of versions.

• Upgrading from 10.2 to 11.2 is a major release upgrade.

• Upgrading from 11.1.0.6 to 11.1.0.7 is a patch set upgrade.

Choose an Upgrade Method

• Manual Upgrade: A manual upgrade consists of directly using SQLplus to perform any necessary actions to prepare

for the upgrade, run the upgrade script, and analyze the upgrade results

• Database Upgrade Assistant (DBUA) :The DBUA is a graphical user interface (GUI) tool that interactively steps you

through the upgrade process and configures the database to run with the new Oracle Database release.


reserved.


reserved.

10 Best Practices


reserved.

Best Practice #1

• Read the FRIENDLY manuals!


reserved.

Documentation

• Note 250.1 Upgrade Advisors


reserved.

Documentation

• Note:251.1 Database Upgrades from 10.2 to 11.2


reserved.

Documentation

• Note:785351.1 Upgrade Companion 11g Release 2


reserved.

More useful references for upgrade • Note:264.1 Database Upgrades from 9.2 to 11.2

• Note:785351.1 Upgrade Companion 11g Release 2

• Note:837570.1 Complete Checklist for Manual Upgrades to 11g Release 2

• Note: 421191.1 Complete checklist for manual upgrades from X to Y

• Upgrade Guides: http://download.oracle.com/docs/cd/E11882_01/server.112/e10819/toc.htm

• OTN Upgrade Page: http://www.oracle.com/technetwork/database/upgrade/index.html

• Upgrade Blog: www.blogs.oracle.com/UPGRADE

http://download.oracle.com/docs/cd/E11882_01/server.112/e10819/toc.htm

http://www.oracle.com/technetwork/database/upgrade/index.html

http://www.blogs.oracle.com/UPGRADE


reserved.

Best Practice #2

• Always upgrade Grid Infrastructure (Clusterware and ASM) First!


reserved.

Best Practice #3 • Use the Upgrade Planner in My Oracle Support


reserved.

Best Practice #4

• Pre-upgrade Sanity operations


reserved. © 2010 Oracle Corporation 18

Sanity Operations: Database Components

• Resolve invalid database components before you upgrade:

• Make sure the software linked correctly.

• Remove components manually which are not in use.

• Fix components manually which are in use but invalid.

Reference:

Note:472937.1 Information On Installed Database Components/Schemas

Note.300056.1 Debug and Validate Invalid Objects

Note:753041.1 How to diagnose Components with NON VALID status

Note.733667.1 How to Determine if XDB is Being Used in the Database?


reserved.

Sanity Operations: Invalid Objects

• Always check for INVALID objects

•

– Fix all INVALID objects BEFORE the upgrade/migration

• There should be no invalid objects in SYS and SYSTEM user schema

– Recompile invalid objects with utlrp.sql before the upgrade

SQL> select unique OBJECT_NAME, OBJECT_TYPE, OWNER

from DBA_OBJECTS where STATUS='INVALID';


reserved.

Sanity Operations: Duplicate Objects

• Always check for DUPLICATE objects in SYS/SYSTEM

•

– Fix DUPLICATE objects in SYS/SYSTEM BEFORE upgrade

– Note:1030426.6 How to Clean Up Duplicate Objects Owned by SYS and SYSTEM Schema

SQL> select OBJECT_NAME, OBJECT_TYPE from DBA_OBJECTS

where OBJECT_NAME||OBJECT_TYPE in (select

OBJECT_NAME||OBJECT_TYPE from DBA_OBJECTS where

OWNER='SYS') and OWNER='SYSTEM' and OBJECT_NAME not in

('AQ$_SCHEDULES_PRIMARY', 'AQ$_SCHEDULES',

'DBMS_REPCAT_AUTH');

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1030426.6


reserved.

Sanity Operations: Gather Schema Stats.

• Create dictionary statistics in Oracle 9i:

• Create dictionary statistics in Oracle 10g/11g:

SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS

('SYS', options => 'GATHER',estimate_percent =>

DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR

ALL COLUMNS SIZE AUTO', cascade => TRUE);

SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS;


reserved.

Sanity operations : • Pre-Process AUD$ record or Truncate SYS.AUD$ (if not required)

How to Pre-Process SYS.AUD$ Records Pre-Upgrade From 10.1 or later to 11gR1

or later. (Doc ID 1329590.1) OR

SQL> truncate SYS.AUD$;

SQL> purge DBA_RECYCLEBIN;

_always_semi_join=off

_unnest_subquery=false

optimizer_features_enable=9.0.1

event = "10061 trace name context forever, level 10"

• Purge the recyclebin

• Remove old & hidden parameters


reserved.

Best Practice #5

• Always run the pre-upgrade script:

• Download and run dbupgdiag.sql script before & after upgrade

Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) [ID 556610.1]


reserved.

Pre-Upgrade Checks

Upgrade information script: utlu112i.sql

Stored in: $OH_11g/rdbms/admin OR Download the newest version of the pre-upgrade check script utlu112i.sql:

Note:884522.1

Run in the environment of the source database

Spool the output into a file:

Checks all init parameters and displays warnings for obsolete and deprecated parameters

Does checks for:

• Components status

• Tablespace SYSAUX

• Character set

• Time zone file version

• Cluster


reserved.

Preparation: Database Vault • Switch off DATABASE VAULT (if used/installed)

– Oracle® Database Vault Administrator's Guide: Appendix B

– Unix: (simplified)

• Relinking without Database Vault [$ make -f ins_rdbms.mk dv_off ioracle]

•

– Windows:

• Rename oradv11.dll in ORACLE_HOME\bin

• Upon restart:

– After upgrading relink with dv_on or rename the DLL and enable Database Vault

again:

– Note: This will just work under the assumption that DVSYS and the DV owning user have identical

passwords

$ chopt disable dv

$ chopt disable dv

$ chopt enable dv


reserved.

Preparation: Time zone Patches - 11g Release 2

• Upgrade to Oracle Database 11g Release 2:

• New 11.2-$OH has timezone V11

• No need to patch the source $OH if TZ version < Target $OH

• Database only needs to be adjusted if you are using the

datatype TIMESTAMP WITH TIMEZONE

• Conversion done after the upgrade

• See Note 944122.1

• Package DBMS_DST

• DBMS_DST.FIND_AFFECTED_TABLES

• DBMS_DST.BEGIN_UPGRADE

• DBMS_DST.UPGRADE_DATABASE

• DBMS_DST.END_UPGRADE


reserved.

Prepration :Preserve performance statistics

• Collecting sufficient performance data prior to the upgrade is of vital importance,

Sufficient means:

• Starting at least 4 weeks before the upgrade

• Gather accurate performance statistics

• In Oracle 8i/9i: Use STATSPACK

Export the PERFSTAT user right before the upgrade

Note:466350.1 STATSPACK before/after upgrade

• In Oracle 10g/11g: Use AWR

Take snapshots every 30-60 minutes – retention: >30 days

Export the AWR with DBMS_SWRF_INTERNAL.AWR_EXTRACT

Use AWR DIFF reports to compare before & after upgrade performance:

DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML


reserved.

Best Practice #6 • Leave COMPATIBLE at the original value for a week before changing to 11.2.

• COMPATIBLE has to be at least 10.1.0 for an 11g database

– No way back once >= 11.1.0 has been enabled

– Supported release downgrade to 10.1.0.5, >=10.2.0.2, >=11.1.0.6

– Flashback database to >= 10.2.0.2

– No ALTER DATABASE RESET COMPATIBILITY command anymore


reserved.

Best Practice #7 : Test fallback strategy

• In any case: Take a backup!!!

• Always:

• Create a valid and complete online backup with RMAN

• Test the restore and the recovery at least once!!!

• Make sure your fallback strategy covers both cases:

– Problems encountered during the upgrade

– Problems found days, weeks after the upgrade

• If anything unforeseen happens and you'll have to step back, will you be allowed to lose

data (i.e. changes done to the data in the system after the upgrade): YES or NO?

– If YES: restore a backup, flashback (since 10g)

– If NO: export/import, downgrade, Oracle Streams, Oracle Golden Gate


reserved.

Fallback strategy: Issues during upgrade


reserved.

Fallback strategy: Issues After upgrade

• Assumption: No data loss allowed


reserved.

Best Practice #8 :Choose Upgrade PATH


reserved.

Upgrade alternatives: Minimal Downtime


reserved.

Upgrading database – Step-by-Step


reserved.

Best Practice #9: Verify upgrade • The DBUA has "spool" and "echo" on by default, Find the logs at:

• For DBUA $ORACLE_HOME/cfgtoollogs/dbua/<dbname>/upgrade<n>/

• For manual method logs can be found at spooled location.

• Recompiling invalid objects

• Post-upgrade tool/utility

• Check if all components are valid: utlu112s.sql

• Dbupgdiag.sql output (run and check script to collect DB Upgrade/Migrate Diagnostic Information Note 556610.1)

• Check alert<sid>.log

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


reserved.

Best Practice #10: Post Upgrade • Create system statistics during a regular workload period - otherwise non-appropriate

values for the CBO will be used:

• Always create an editable init.ora from the current SPFILE after the upgrade has been

finished

– Prevents rewrite in case of setting wrong parameters or forced edit

– Keep in mind:

• The SPFILE is binary file!!! Don't edit it!! Default since Oracle 9.0

• It simply will exist after using DBUA or DBCA

• Parameter can be changed by:

SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS('start');

... – gather statistics while running a typical workload

SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS('stop');

SQL> create pfile='/tmp/initDB.ora' from spfile;

SQL> startup force pfile=/tmp/initDB.ora

SQL> create spfile from pfile;

SQL> alter system set PARAMETER=VALUE scope=both;


reserved.

Common issues

Cause : If the registry$database table already exist in the database but does not have the TZ_VERSION column OR Time zone

file version was not updated in registry$database.

Solution :The error can be occurred if you have not executed the ultu112i.sql script on the source database prior to

upgrade ,it creates adds a TZ_VERSION column if does not exist and populate the column with TZ_VERSION value in

registry$database .So make sure that you have execute the utlu112i.sql on the source database .

ORA-00904: "TZ_VERSION": invalid identifier

ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE

Cause: It is a RAC database and was mounted for SHARED cluster access.

Solution: Set the CLUSTER_DATABASE initialization parameter to FALSE in spfile/pfile and restart the server with the

UPGRADE or DOWNGRADE option.


reserved.

Common issues continued …

TimeZone Patch Cause: If the source database is using timezone files higher than default TZ version shipped with the target Oracle 11gR2

Oracle home and target Oracle home is NOT patched with the same version timezone before upgrade.

Solution: Apply the TZ version patch on the target database to match the TZ version at source database then run the per-

upgrade script to populate the TZ_VERSION with new TZ version in the registry$database .

Oracle Database Vault Cause: If the Oracle Database Vault option is TRUE. Upgrades cannot be run with the Oracle Database Vault option set to

TRUE since AS SYSDBA connections are restricted.

Solution: Perform a "SHUTDOWN ABORT", relink the server without the Database Vault option (but with the OLS option), and

restart the server using UPGRADE.

Oracle Label Security Cause: If Database Vault is installed in the database but the Oracle Label Security option is FALSE.

Solution: relink the server with the OLS option (but without the Oracle Database Vault option) and restart the server using

UPGRADE.

ORA-01722: invalid number


reserved.

Common issues continued …

Cause: You have set the compatible to the higher release and now try to open or downgrade the database with lower release .

Solution: It is highly recommended to keep the compatible parameter to the least values .Oracle recommends increasing the

COMPATIBLE parameter only after complete testing of the upgraded database has been performed .

Setting the compatible parameter to the highest value enables to use all of the features of the new release, but prevents from

downgrading back to previous release.

NOTE: If you are upgrading from 9.2.0.x, the COMPATIBLE initialization parameter must be set to at least 10.0.0, which is the

lowest possible setting for Oracle Database11g Release 2 (11.2) prior to the upgrade.

ORA-00201 control file version <num> incompatible with Oracle version <num>


reserved.

Real world examples…

• From support experience few interesting cases,

• Very small shared pool size when upgrading from 8i to 10g:

• Database upgrade run 48 hours instead of 1 hour

• Too small shared pool size when upgrade to 11g:

• ORA-4031 – this leads to invalid objects

• Millions of audit records in SYS.AUD$

• Upgrade took 24 hours – once truncated upgrade completed in under 1 hour

• Objects of SYS users in user tablespace, upgrade fails with ora-0600

• Customers forgot to analyze Dictionary Database

• Especially in huge dictionary database (like GSI or SAP) a big problem as we create stats while the upgrade runs


reserved. © 2010 Oracle Corporation 41

Summary: Upgrade Best Practice • Planning is a key to successful upgrade. A successful upgrade,

• requires minimal downtime,

• requires minimized, predictable efforts to upgrade,

• It produces a stable upgraded environment without any surprises.

• It identifies issues proactively and addresses them during the planning and testing phase.

• Drive upgrade as a project which should have Evaluate, Plan, Configure, Test, Implement stages. Upgrade

Advisor Note 251.1

• Take consistent backup which is useful when its needed for recovery.

• Test upgrade in test environment, Optimize steps of upgrade to minimize upgrade window.

• Leverage tools of PreUpgrade, PostUpgrade even though DBUA is used.

• Don’t underestimate test efforts, reserve enough time and resource for testing. Always use real world data for

testing

• Create and test fallback strategy ( Does it really works ?)

• Document all changes detailed and clearly in change log.


reserved.

Q&A

1 Copyright © 2011, Oracle and/or its affiliates. All rights ... Database...7 Copyright © 2011,...

Documents

Transcript of 1 Copyright © 2011, Oracle and/or its affiliates. All rights ... Database...7 Copyright © 2011,...