Oracle Database Upgrade has always been a complex project. DBAs need to spend a lot of time and effort on preparation for Product Database Upgrade because of its high complexity, therefore, even if you are fully prepared, unexpected problems may still occur during the upgrade process. In order to complete the upgrade task more efficiently and reduce the downtime, we need to create a "comfortable" defensive Database "atmosphere for the upgrade ":
1. To ensure the performance of the upgraded database, it is necessary to effectively collect the database performance statistics before the upgrade so that we can compare the performance problems after the upgrade:
- To ensure real and effective performance statistics, it is necessary to collect data one month before the Database Upgrade.
- The collected performance statistics should be as accurate and authentic as possible
- Use the Statspack performance report in Oracle 8i/9i, set the snapshot level to 6 or higher, set the snapshot interval to 30 minutes, and export the perfstat user using the exp tool before the specific upgrade, refer to Metalink Document Note: 466350.1 to introduce how to compare the Statspack snapshots before and after the upgrade.
- Use AWR auto load repository performance reports in Oracle 10g/11g to ensure that snapshots are collected for about 30 days. The interval between snapshots should be 30-60 minutes; then, you can use the dbms_swrf_internal.awr_extract stored procedure to export awr to the dumpfile file, load the AWR information after the upgrade, and use the DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML function to compare the performance
2. defensive measures before the formal upgrade:
- Excessive audit information may lead to a decrease in the update speed. You can export audit data before the upgrade and clear the audit dictionary base table:
- Truncation SYS. AUD $ base table:
- SQL>Truncate table sys. AUD $;
- It is also necessary to clear the recycle bin after 10 GB:
- Clear DBA recycle bin:
- SQL>Purge DBA_RECYCLEBIN;
- Remove some "expired" parameters. The reason for setting these parameters is probably to correct some problems in the original version, such as setting the event parameter; however, in the new version, it is worth discussing whether to set these parameters. Of course, you can submit an SR for this matter:
- These "expired" parameters may include: old ones suchOptimizer_features_enable=8. 1.7.4,_ Always_semi_join=Off,_ Unnest_subquery=False
- OrEvent="10061 trace name context forever, level 10"And so on.
- Collect statistics for data dictionaries in the database:
- In Oracle 9i, you can perform the following process to collect data dictionary statistics,
- SQL>Exec DBMS_STATS.GATHER_SCHEMA_STATS
- ('Sys ',Options=>'Gather ',Estimate_percent=>
- DBMS_STATS.AUTO_SAMPLE_SIZE,Method_opt=>'
- All columns size auto ',Cascade=>TRUE );
- Collecting dictionary statistics in Oracle10g/11g can be completed by the GATHER_DICTIONARY_STATS stored procedure:
- SQL>Exec DBMS_STATS.GATHER_DICTIONARY_STATS;
- We need to prepare for the rollback Database Upgrade task. We can only restore the database by backing up the database before 10 Gb. After 10 Gb, we can use the Restore Point Feature of the flash back database to roll back the database, note the following:
- Restore the source to archive the database and enable flashback database
- Available only after Version 10.2
- Ensure that the flashback recovery area has sufficient disk space.
- Do not modify the compatible parameter immediately after the upgrade. The restore point cannot work across compatible.
- /* First, create an effective recovery point to ensure the flash back to the database before the official upgrade */
- SQL>Select * from global_name;
- GLOBAL_NAME
- --------------------------------------------------------------------------------
- Http://www.oracledatabase12g.com/archives/oracle%E6%95%B0%E6%8D% AE %E5%BA%93%E5%8D%87%E7%BA%A7%E5%89%8D%E5%BF%85%E8%A6%81%E7%9A%84%E5%87%86%E5%A4%87%E5%B7%A5%E4%BD%9C.html
- SQL>Create restore point pre11gupgrd guarantee flashback database;
- Restore point created.
- /* After confirming the above four notes, we can implement the upgrade with confidence */
- SQL>Shutdown immediate;
- ..............
- SQL>@? /Rdbms/admin/catupgrd. SQL
- .............
- Upgrade failed
- /* When an error that cannot be bypassed occurs during the upgrade, we may have to roll back the database to the Restore point, that is, before the upgrade */
- /* Restore the environment to 10 Gb after the instance is closed */
- SQL>Startup mount;
- /* Return to restore origin pre11gupgrd */
- SQL>Flashback database to restore point pre11gupgrd;
- Flashback complete.
- SQL>Alter database open;
- Alter database open
- *
- ERROR at line 1:
- The ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
- SQL>Alter database open resetlogs;
- /* Use resetlogs to open the database */
- /* It is necessary to delete this restore point */
- SQL>Select * from v $ restore_point;
- SCN DATABASE_INCARNATION # GUA STORAGE_SIZE
- ----------------------------------------------
- TIME
- ---------------------------------------------------------------------------
- NAME
- --------------------------------------------------------------------------------
- 5081633 3 YES 15941632
- 08-FEB-11 08.20.33.000000000 PM
- PRE11GUPGRD
- SQL>Drop restore point pre11gupgrd;
- Restore point dropped.
- Download the latest version of the pre-upgrade check script, as shown in figureUtlu102i. SQL/utlu111i. SQL/utlu112i. SQLMetalink Document Note: 884522.1 <How to Download and Run Oracle's Database Pre-Upgrade Utility> indicates
- /* Upload the update information spool to the log file */
- SQL>SPOOL/tmp/UPGRADE/utluw. I. log
- SQL>@/Tmp/UPGRADE/utluw. I. SQL
- You need to pay attention to the invalidation objects in SYS and SYSTEM User Mode. It is necessary to repair all the invalidation objects before the upgrade:
- Select unique object_name, object_type, owner
- FROM dba_objects
- WHEREStatus='Invalid';
- After the upgrade is complete, we recommend that you run the utlrp. SQL script to re-compile (Recompile) objects. The invalid objects before and after the upgrade from 11.1.0.7 will be automatically compared and executed? The/rdbms/admin/utluiobj. SQL script can list the comparison information. The base table registry $ sys_inv_objs and registry $ nonsys_inv_objs respectively list the database's invalid sys or non-sys objects:
- SQL>Select * from v $ version;
- BANNER
- --------------------------------------------------------------------------------
- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0-64bit Production
- PL/SQL Release 11.2.0.1.0-Production
- CORE 11.2.0.1.0 Production
- TNS for Linux: Version 11.2.0.1.0-Production
- NLSRTL Version 11.2.0.1.0-Production
- SQL>@? /Rdbms/admin/utluiobj. SQL
- .
- Oracle Database 11.1 Post-Upgrade Invalid Objects Tool 22:23:22
- .
- This tool lists post-upgrade invalid objects that were not invalid
- Prior to upgrade (it ignores pre-existing pre-upgrade invalid objects ).
- .
- Owner Object Name Object Type
- .
- SH FWEEK_PSCAT_SALES_MV MATERIALIZED VIEW
- PL/SQL procedure successfully completed.
3. Fixed invalid components during the upgrade process (component)
- Make sure that these components are linked to the current Oracle software 2-in-hexadecimal executable file or library file.
- If you confirm that some components (component) are not used and want to manually remove them completely (or you want to reinstall them again), refer to the following documents: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.7300007.1 How to Determine if XDB is Being Used in the Database?
- Component upgrade failed instance 1: the Database has been upgraded from 10.2 to 11.2. In a 10g environment, the Database Vault component has been installed,
- The Database Vault component is turned off before the relink is upgraded. The XDB component fails to be upgraded to 11.2;
- The reason is that the installation or switching of Database Vault will invalidate the XDB component, or the cause is Bug 8942758.
- The solution is to execute the utlrp. SQL script to re-compile the invalid objects and components before the upgrade. In this example, execute utlrp. SQL to enable the XDB component valid.
- Component upgrade failed instance 2: the database is upgraded from 10.2.0.4 to 11.1.0.7, and the "oracle server" component is invalid during the upgrade;
- The reason is that the DMBS_SQLPA package references a column that does not exist. For this problem, see metalink documentation 782735.1 and Notes: 605317.1/736353.1.
- An effective solution is as follows:
- 1. drop sys. PLAN_TABLE $ base table or synonym PUBLIC. PLAN_TABLE before the upgrade.
- 2. If you have performed the upgrade operation and encountered the problem, you can use the following methods to fix the problem:
- @ 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;
4. run commands such as slibclean on AIX to clean up the operating system environment. If shared library files are not cleaned and loaded on a few proprietary platforms, the upgrade may fail.
5. Open the echo output of sqlplus before executing the catupgrd. SQL script to dump all the output information during the upgrade to the log file:
- SQL>Set echo on
- SQL>SPOOL/tmp/upgrade. log
- SQL>@ Catupgrd. SQL
- SQL>Spool off
By default, the DBUA graphical upgrade tool outputs spool and "echo". These logs can be found in the $ ORACLE_HOME/export toollogs/dbua // upgrade/directory.