THEORY - UPGRADING

Start the instance by issuing the following command:
SQL> STARTUP UPGRADE
Note:
The UPGRADE keyword enables you to open a database based on an earlier Oracle Database release. It also restricts logons to AS SYSDBAsessions, disables system triggers, and performs additional operations that prepare the environment for the upgrade.
You might be required to use the PFILE option to specify the location of your initialization parameter file.
Once the database is started in upgrade mode, only queries on fixed views execute without errors until after the catupgrd.sql script is run. Before running catupgrd.sql, queries on any other view or the use of PL/SQL returns an error.

What is the difference between startup Upgrade and Migrate ?

startup migrate:
---------------
Used to upgrade a database till 9i.

Startup Upgrade
---------------
From 10G  we are using startup upgrade to upgrade database.

What happens internally when you use startup upgrade/migrate?
It will adjust few database (init) parameters (irrespective of what you have defined) automatically to certain values in order to run upgrade scripts smoothely.
in other way..it will issue few alter statements to set certain parameters which are required to complete the upgrade scripts without any issues.

REFERENCE:

Oracle® Database Upgrade Guide 11g Release 2 (11.2)
http://docs.oracle.com/cd/E11882_01/server.112/e23633/upgrade.htm

STEPS - UPGRADING

UPGRADING

Manual upgrade which involves the following steps:

1.Backup the database.
2.In UNIX/Linux environments, set the $ORACLE_HOME and $PATH variables to point to the new 11g Oracle home.
3.Analyze the existing instance using the "$ORACLE_HOME/rdbms/admin/utlu111i.sql" script.
4.Start the original database using the STARTUP UPGRADE command and proceed with the upgrade by running the "$ORACLE_HOME/rdbms/admin/catupgrd.sql" script.
5.Recompile invalid objects.
6.Restart the database.
7.Run the "$ORACLE_HOME/rdbms/admin/utlu111s.sql" script and check the result of the upgrade.
8.Troubleshoot any issues or abort the upgrade.

Database Upgrade Errors & Solution

Database Upgrade Problem & Solution List

http://indiandba.blogspot.in/2012/01/error-is-related-to-timezone-file.html

1.Error is related to timezone filePosted On Tuesday, January 31, 2012 at at 2:00 AM by Anup Kumar Srivastav I started database in upgrade mode and fired catupgrd.sql :SQL> startup upgradeORACLE instance started.Total System Global Area 6413680640 bytesFixed Size                  2160112 bytesVariable Size            1946159632 bytesDatabase Buffers         4429185024 bytesRedo Buffers               36175872 bytesDatabase mounted.Database opened.SQL> @catupgrd.sqlDOC>#######################################################################DOC>#######################################################################DOC>DOC>   The first time this script is run, there should be no error messagesDOC>   generated; all normal upgrade error messages are suppressed.DOC>DOC>   If this script is being re-run after correcting some problem, thenDOC>   expect the following error which is not automatically suppressed:DOC>DOC>   ORA-00001: unique constraint () violatedDOC>#   FROM registry$database        *ERROR at line 2:ORA-00942: table or view does not existThis  error is related to timezone file  which must be version 4 for Oracle version 11g.If timezone is not version 4 than patch needs to be applied.Query to check timezone file  is:SQL> select * from v$timezone_file;FILENAME        VERSION———— ———-timezlrg.dat          4SQL> select * from v$timezone_file;FILENAME        VERSION———— ———-timezlrg.dat          4So I had correct version.I remember applying patch before upgrade.I got lucky because patch existed for version 10.2.0.3.If there is no patch for your Oracle versions than patch can be download for similar version and  applied manually.Instructions are below:1. Download the identified patch.2. Unzip the patch, and locate the 2 files timezone.dat and timezlrg.dat in the “files/oracore/zoneinfo” directory of the uncompressed patch (or from the relevant .jar file of a   patchset). If there is also a readme.txt in this location then make a note of this as well.3. Backup your existing files in $ORACLE_HOME/oracore/zoneinfo – THIS CAN BE VITAL, DO NOT SKIP.

note:Before going on with step 4, make sure the current files are not in use.On Windows the files will simply refuse to be removed when the are in use.On Unix replacing the files whilst they are in use can cause the files to become corrupt. Use the fuser command before replacing the files to make sure they are not in use.4. Copy the 2 .dat files and possibly the readme.txt file that were found in step 2 into the $ORACLE_HOME/oracore/zoneinfo directory.5. Restart the database (in case of installation on a database), or restart the client applications (in case of client install). Note that the database did not need to be down before the time zone files were applied, but it does need to be restarted afterwards.

"Hope for the best, prepare for the worst"
-Dharmendra