Upgrading Manually

Lets step through the manual database upgrade process in this section so you understand
whathappens during a database upgrade. Recall that the DBUA does a lot of the following
steps for you.
The steps for a manual upgrade to the Oracle Database 10g database version are briefly listed
here, and they are discussed in more detail in the following sections:
1) Create a spool file.
2) Log in as a user with the SYSDBA privilege, and run the Pre-Upgrade Information
Tool.
3) Make any changes it recommends.
4) Back up the database youre going to upgrade.
5) Copy the current init.ora file to the new Oracle Database 10g init.ora file location.
6) Shut down the database and restart it under the new Oracle 10g home in the
STARTUP
7) UPGRADE mode.
8) Create the required Sysaux tablespace.
9) Run the catupgrd.sql upgrade script.
10) Check to see if any objects became invalidated during the database upgrade.
11) Run the utlrp.sql script to recompile any objects that became invalid during the
database
12) upgrade.
13) Run the Post-Upgrade Status Tool.
14) End the spool file.
Creating a Spool File
Create a spool file to record the upgrade process so that you can easily review it later.
SQL> SPOOL upgrade.log
Starting the Pre-Upgrade Information Tool
To start the Pre-Upgrade Information Tool, run the following:
SQL> @$ORACLE_HOME\rdbms\admin\utlu102i.sql
To see the results of the pre-upgrade check, turn spooling off with the following command:
SQL> spool off
Check the upgrade.log spool file to see if you meet all upgrade requirements. Listing 8-1
shows part of the output from a sample run. Note that I was upgrading an Oracle 8.17
database to Oracle
Database 10g.
Listing 8-1. Partial Output of the Pre-Upgrade Information Tool
*************************************************************************
Database:
--> name: FINANCE
--> version: 8.1.7.0.0
--> compatibility: 8.1.0

WARNING: Database compatibility must be set to 9.2.0 prior to upgrade.

***********************************************************************
Update Parameters: [Update Oracle Database 10.2 init.ora or spfile]
WARNING: --> "shared_pool_size" needs to be increased to at least "150944944"
*************************************************************************
Obsolete Parameters: [Update Oracle Database 10.2 init.ora or spfile]
--> "job_queue_interval"
--> "max_enabled_roles"
*************************************************************************
Components: [The following database components will be upgraded or installed]
--> Oracle Catalog Views [upgrade]
--> Oracle Packages and Types [upgrade]
...
*************************************************************************
SYSAUX Tablespace: [Create tablespace in Oracle Database 10.2 environment]
--> New "SYSAUX" tablespace
.... minimum required size for database upgrade: 500 MB
Please create the new SYSAUX Tablespace AFTER the Oracle Database 10.2 server is
started and BEFORE you invoke the upgrade script. Make all the changes pointed out by the
Pre-Upgrade Information Tool before proceeding with the upgrade.
Backing Up Your Database
Backup the database you are upgrading, either by using RMAN or by using your own backup
techniques.
Tip At this point, make sure youve set your ORACLE_HOME variable to the new Oracle
home using the format
ORACLE_BASE/product/10.2.0/db_name.
Copying Your init.ora File
Copy your current init.ora file to its default location in the new Oracle Database 10g Release
2 home ($ORACLE_HOME/dbs). You should also make the changes that the Pre-Upgrade
Information Tool recommended. Remove all obsolete and deprecated parameters and add the
new parameters, such as SGA_TARGET, which automates shared memory management.
Starting Up the New Database
Shut down the current database if its running, and start it up again with the updated init.ora
parameter file under the new Oracle Database 10g home. You must use the new STARTUP
UPGRADE command to start up your database under the Oracle 10.2 version, which tells
Oracle to modify those initialization parameters that would otherwise cause errors during the
upgrade (for example, the new startup mode will set the JOB_QUE_PROCESSES parameter
to 0). The startup upgrade mode starts a restricted session and prepares the environment for
the upgrade.
Listing 8-2 shows how to start the database using the STARTUP UPGRADE command. Note
that if youre storing your initialization parameter in the default location
($ORACLE_HOME/dbs), you dont need to specify its path when you use the STARTUP
UPGRADE command.

Listing 8-2. Starting the Database with the STARTUP UPGRADE Command
[oracle@localhost admin]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.0.0 - Beta on Mon Feb21 16:43:14 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
SQL> CONNECT sys/sammyy1 AS SYSDBA
Connected to an idle instance.
SQL> STARTUP UPGRADE
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1236756 bytes
Variable Size 99164396 bytes
Database Buffers 213909504 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.
SQL>
Creating the Sysaux Tablespace
Once you have brought up the database instance, you can create the Sysaux tablespace:
SQL> CREATE TABLESPACE sysaux DATAFILE '/u10/oradata/prod/sysaux01.dbf'
SIZE 500M REUSE EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
The database is now technically converted into an Oracle Database 10g version, as shown by
the following query:
SQL> SELECT * FROM V$VERSION
BANNER
---------------------------------------------------------------Oracle Database 10g Enterprise Edition Release 10.2.0.0.0 - Beta
PL/SQL Release 10.2.0.0.0 - Beta
CORE 10.2.0.0.0 Beta
TNS for Linux: Version 10.2.0.0.0 - Beta
NLSRTL Version 10.2.0.0.0 - Beta
SQL>
In the next step, you actually upgrade the current database to the 10.2 version.
Note As of this writing, the Oracle Database 10g Release 2 (10.2) production version hasnt
been officially released. The output from the previous SQL query notes that I used the 10.2
Beta version. While there could be changes in the final production version of the software,
such changes will be focused on fixing bugs encountered during the Beta testing phase and
wont introduce substantive functional modifications.

Running the Upgrade Script

Although the database is opened and a query to V$VERSION reveals that your database is
now an Oracle Database 10g database, you will have to run the upgrade script, which is your
next task. Previously, each version of the Oracle server had a separate upgrade script. For
Oracle 10.2, you need to use the same script to upgrade a database, no matter what its
version, as long as it is in the upgrade-eligible list of database versions. This brand-new
upgrade script is called catupgrd.sql, and it can be found in $ORACLE_HOME/rdbms/admin.
This script automatically runs the appropriate upgrade script for the database version youre
upgrading and uses procedures from the DBMS_REGISTRY package to execute various
component upgrades.
Make sure youre logged in as a user with SYSDBA privileges, and run the upgrade script
from the new environment:
SQL> @$ORACLE_HOME/rdbms/admin/catupgrd.sql
Checking for Invalid Objects
Oracle will create, drop, and alter some database objects as the upgrade process progresses,
thus invalidating some internal Oracle packages and procedures. After the upgrade script has
finished, you need to check for invalid objects:
SQL> SELECT count(*) FROM DBA_OBJECTS WHERE status = 'INVALID';
Recompiling and Validating Invalidated Objects
By running the Oracle-provided utlrp.sql script, you can do a recompilation and validation of
all the objects invalidated during the upgrade process. During this process, utlrp.sql calls
utlprp.sql (a wrapper based on the UTL_RECOMP package). Note that Oracle will
dynamically compile each of the invalidated objects when they are accessed if you dont do it
now. However, this runtime compilation of invalidated objects could slow down your
databases performance.
You can recompile all invalidated Oracle database objects using the utlrp.sql script:
SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql
...
PL/SQL procedure successfully completed.
TIMESTAMP
----------------------------------------------------------COMP_TIMESTAMP UTLRP_END 2005-2-21 15:20:49
PL/SQL procedure successfully completed.
SQL>
To check that there arent any invalid objects left, you should run the check again:
SQL> SELECT count(*) FROM dba_objects WHERE status = 'INVALID';
COUNT(*)
--------------0
1 row selected.
SQL>
Once it has validated all the invalid objects, the utlrp.sql script validates each individual
component in the database and updates the DBMS_SERVER_REGISTRY view.

Note You can revert to the older database as long as you have a backup of the database
made before starting the upgrade process. Its vital to have a backup, since the upgrade
process may fail before its completed, leaving you with a database that wont be functional
under the pre- or post-upgrade version of Oracle.
Running the Post-Upgrade Status Tool
After the upgrade process completes, you must run the Post-Upgrade Status Tool, using the
following script:.
SQL> @utlu102s.sql
The Post-Upgrade Status Tool summarizes the upgrade process, which should look similar to
Listing 8-3, if everything went okay during the database upgrade.
Listing 8-3. Partial Output from the Post-Upgrade Status Tool
Oracle Database 10.2 Upgrade Status Utility 5-02-2005 11:26:50
...
Component Status Version HH:MM:SS
Oracle Database Server
VALID 10.2.0.0.0 00:35:54
JServer JAVA Virtual Machine
VALID 10.2.0.0.0 00:12:01
Oracle XDK
VALID 10.2.0.0.0 00:03:56
Oracle Database Java Packages
VALID 10.2.0.0.0 00:01:27
Oracle XML Database
VALID 10.2.0.0.0 00:04:05
Oracle Workspace Manager
VALID 10.2.0.0.0 00:03:18
Oracle Data Mining
VALID 10.2.0.0.0 00:00:24
Messaging Gateway
VALID 10.2.0.0.0 00:00:20
OLAP Analytic Workspace
VALID 10.2.0.0.0 00:00:43
OLAP Catalog
VALID 10.2.0.0.0 00:02:54
Oracle OLAP API
VALID 10.2.0.0.0 00:00:50
Oracle interMedia
VALID 10.2.0.0.0 00:05:10
Spatial
VALID 10.2.0.0.0 00:07:02
Oracle Text
VALID 10.2.0.0.0 00:01:51
Oracle Ultra Search
VALID 10.2.0.0.0 00:02:04
Oracle Label Security
VALID 10.2.0.0.0 00:00:37
...
Total Upgrade Time: 01:27:32
The Post-Upgrade Status Tool determines the upgrade status of each database component by
querying the DBA_SERVER_REGISTRY view. You can also query the
DBA_SERVER_REGISTRY view, as shown in Listing 8-4.
Listing 8-4. Querying the DBA_SERVER_REGISTRY View for Post-Upgrade Information
SQL> SELECT comp_id, comp_name, version, status FROM DBA_SERVER_REGISTRY;
COMP_ID COMP_NAME- VERSION STATUS
------------------------------ -------------------------------------------CATALOG Oracle Database Catalog Views 10.2.0.0.0 VALID
CATPROC Oracle Database Packages and Types 10.2.0.0.0 VALID
JAVAVM JServer JAVA Virtual Machine 10.2.0.0.0 VALID

CATJAVA Oracle Database Java Packages 10.2.0.0.0 VALID

CONTEXT Oracle Text 10.2.0.0.0 VALID
SQL>
The Post-Upgrade Status Tool will tell you how the upgrade went. If you didnt cleanly
upgrade a component, the Post-Upgrade Status Tool will tell you what you have to do to fix
the problem, as the bold section in Listing 8-5 illustrates.
Listing 8-5. Output from the Post-Upgrade Status Tool Pointing Out a Problem with a
Component
Oracle Database 10.2 Upgrade Status Tool 14-APR-2005 04:59:46
--> Oracle Database Catalog Views Normal successful completion
--> Oracle Database Packages and Types Problem(s) detected
WARNING:
----> component status is not valid
----> version is correct
----> check upgrade log file for errors
----> script="re-run base update "u" script"
--> JServer JAVA Virtual Machine Normal successful completion
--> Oracle XDK Normal successful completion
--> Oracle Database Java Packages Normal successful completion
--> Oracle interMedia Normal successful completion
--> Spatial Normal successful completion
--> Oracle Text Normal successful completion
PL/SQL procedure successfully completed.
SQL>
Caution Dont start the newly upgraded database under the old Oracle homethis corrupts
your database.
Ending the Spool File
After the upgrade script had finished, you can turn off the spooling of the upgrade process:
SQL> SPOOL OFF
Shutting Down and Starting Up the New Database
You can now shut down and restart the instance so youre ready for normal database
operations:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP
After the Upgrade
After the upgrade, you have a brand-new Oracle Database 10g (10.2.0.0.0) instance. Of
course, at this point, all your old application code continues to remain at the Oracle8i,
Oracle9i, or Oracle 10.1 version level. You may want to test the new database features as well
as your old applications, to see that they run in the upgraded database without problems.
Its a good idea to promptly back up the new database. You must also change the passwords
for the Oracle-supplied user accounts if you manually upgraded the database. You may also
need to modify the listener.ora file, as well as migrate to the SPFILE from your init.ora file.

Several of Oracle Database 10gs new features expect you to use locally managed
tablespaces. You may, at this point, choose to migrate all your dictionary-managed
tablespaces to locally managed tablespaces by using the DBMS_SPACE_ADMIN package.
Chapter 5 shows you how to convert dictionary-managed tablespaces to locally managed
tablespaces. You can also start migrating database jobs to the new Oracle Scheduler and
check out the Automatic Jobs feature, the Automatic Database Diagnostic Monitor, and many
other goodies you have available in your new Oracle Database 10g Release 2 database.