Professional Documents
Culture Documents
There should be no invalid objects in Oracle supplied user schemas especially one owned by SYS or SYSTEM
SQL> select unique OBJECT_NAME, OBJECT_TYPE, OWNER from DBA_OBJECTS where STATUS='INVALID' order by
OWNER;
no rows selected
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> @/u01/app/oracle/product/12.1.0.2/dbhome_1/rdbms/admin/preupgrd.sql
Loading Pre-Upgrade Package...
***************************************************************************
Executing Pre-Upgrade Checks in DPA...
***************************************************************************
====>> ERRORS FOUND for DPA <<====
The following are *** ERROR LEVEL CONDITIONS *** that must be addressed
prior to attempting your upgrade.
Failure to do so will result in a failed upgrade.
You MUST resolve the above errors prior to upgrade
************************************************************
************************************************************
====>> PRE-UPGRADE RESULTS for DPA <<====
ACTIONS REQUIRED:
1. Review results of the pre-upgrade checks:
/u01/app/oracle/cfgtoollogs/DPA/preupgrade/preupgrade.log
WARNING: --> Enterprise Manager Database Control repository found in the database
go to your Oracle_home/bin directory.
IF (upper('&LOGGING') = 'VERBOSE')
new 69:
IF (upper('VERBOSE') = 'VERBOSE')
RUNNING DBUA
Once everything has been corrected after reviewing the preupgrade.log, we can start the Database Upgrade
Assistant (DBUA). To start the DBUA, we need to go to the Oracle Database 12c home and run dbua:
#> cd /u01/app/oracle/product/12.1.0.2/dbhome_1/bin
#>./dbua &
This will start the GUI to begin the upgrade. You will notice that I did not change anything in my environment. Im still
pointing to the 11g environment.
ORACLE_SID=DPA
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1
Once the DBUA starts, you will notice that we are at step 1 of 11. The number of steps will change depending on the
options that are selected. Step 1, we have two options:
Upgrade an Oracle Database
Move an existing 12c database to a new 12c oracle home
For the purpose of the update, we can just click next and move on.
Part of the upgrade process we need to identify which Oracle home we want to upgrade. Since we started the DBUA
with the Oracle home set to the 11g home, the DBUA will give us all databases associated with that Oracle home.
Select the database to be upgraded, then click next.
In step 3 we see results that look similar to what we looked at in the preupgrade.log. As you can tell, the DBUA is
actually running the same preupgrd.sql script and returning the results back to the GUI. Additionally, Oracle has
made the DBUA more intelligent by allowing us to select whether we can fix, ignore or revalidate the issues found by
the preupgrd.sql. Make the selections you want and continue.
Step 4 is one of the most interesting screens in the DBUA. Oracle has made a fundamental change to how upgrades
are handled. Upgrades can now be done in parallel! This is accomplished by using a new perl script,catctl.pl. The
number of parallelism is calculated based on the number of CPUs in the server. Additionally, we can recompile object
now in parallel and have DBUA perform the upgrade of time zones, gather statistics and make tablespaces read only
during the upgrade. Click next to continue.
Step 5 allows us to select how we want to manage our Oracle Database 12c environment. We can either select to use
EM Express, the new web interface for Oracle Database 12c that replaces the database console in previous versions
or we can register that database with Oracle Enterprise Manager 12c (OEM).
Note: If the OEM12c agents are already installed on the server where the upgrade is being done, the DBUA will pick
up the need information automatically.
Step 6 allows us to specify where we want to move our data files and setup our Fast Recovery Area (FRA). We can
also configure if we want to use Oracle Managed Files (OMF) at this point.
Step 7 gives us the option to migrate the listener for 11g over to 12c (if not already up). In the image below the 12c
binaries are already installed and have a listener running from it. Whats important on this screen is the Migrate
column. This column will tell you whether or not the listener is going to be migrated.
In step 8 we have the option to create a new backup of our database before upgrading. If we are confident in our
backup strategies, we can tell the DBUA not to make a backup by selecting the radio button: I have my own backup
Finally, we reach the summary screen (Step 9). This screen will show us what the DBUA thinks it will be doing. One
should always review this screen and make sure everything appears to be in order before clicking Finish. Once we
click finish, the upgrade will begin and we can monitor it via the progress screen.
Once the upgrade is complete, the Stop button will change its wording and say Upgrade Results. When you click
this button, the interface will change and provide you with the results of the upgrade. At this point, the upgrade is done
and the DBUA can be closed. Click the Close button to exit the GUI.
**********************************************************************
[Post-Upgrade Recommendations]
**********************************************************************
*****************************************
******** Fixed Object Statistics ********
*****************************************
Please create stats on fixed objects two weeks after the upgrade using the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
After your database is upgraded and open in normal mode you must run
rdbms/admin/catuppst.sql which executes several required tasks and completes
the upgrade process.
You should follow that with the execution of rdbms/admin/utlrp.sql, and a
comparison of invalid objects before and after the upgrade using
rdbms/admin/utluiobj.sql
Follow the general instructions in section 'Upgrading an existing Statspack schema to a newer release' above.
To upgrade:
ensure you have sufficient free space in the tablespace
disable any programs which use Statspack
backup the Statspack schema (e.g. using export)
run the upgrade by connecting as a user with SYSDBA privilege:
connect perfstat
create table STATS$IOSTAT_FUNCTION_DETAIL
(snap_id number not null
,dbid number not null
,instance_number number not null
,func_id number
,func_name varchar2(20)
,filetyp_id number
,filetyp_name varchar2(30)
,smallrd_MB number
,smallwt_MB number
,largerd_MB number
,largewt_MB number
,num_waits number
,wait_time number
,constraint STATS$IOSTAT_FUNC_PK primary key (snap_id, dbid, instance_number, func_id, filetyp_id) using index
tablespace SYSAUX storage (initial 1m next 1m pctincrease 0));
cd $ORACLE12_HOME/rdbms/admin
sqlplus / as sysdba
grant select on v_$iostat_function_detail to perfstat;
@spup112.sql
connect / as sysdba
@spup12102.sql
Once the upgrade script completes, check the log files (spup112a.lis and spup112b.lis) for errors.
If errors are evident, determine and rectify the cause.
If no errors are evident, re-enable any Statspack data collection or reporting scripts which were previously disabled.
3. Connect RMAN to the base recovery catalog, upgrade the base recovery catalog, and then exit RMAN.
4. Assume that the database user who owns the base recovery catalog is rco. The following command upgrades
the base recovery catalog. The UPGRADE CATALOG command must be entered twice to confirm the upgrade.
$ rman CATALOG rco@catdb
recovery catalog database Password:
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;
5. Use SQL*Plus to connect to the recovery catalog database as the SYS user with SYSDBA privilege.
6. Run the dbmsmanvpc.sql script to upgrade virtual private catalog schemas to the VPD model.
The base recovery catalog schema name must be provided as an input parameter to this script. You can specify
a maximum of 10 schema names. Alternately, you can use the -all option to automatically detect base catalog
schemas and upgrade all associated virtual private catalog schemas.
7. The following command upgrades the virtual private catalog schemas of the base recovery catalog owned by
rco:
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql rco
Share
No comments:
Post a Comment
Home