Platform Migration (Solaris to Linux) and DB Upgrade from Oracle 9i to 11g using GG

PLATFORM MIGRATION AND DATABASE UPGRADE FROM ORACLE 9I TO ORACLE 11G USING GOLDENGATE

• 11G, 12c, 9i, afterscn, extract, GoldenGate, migration, platform, replicat, upgrade, zero downtime

Let us look at an example of using Oracle Golden Gate to achieve a near zero (not zero!) downtime for performing an upgrade from Oracle 9i (9.2.0.5) to Oracle 11g (11.2.0.4) as well as a platform migration from Solaris SPARC to Linux X86-64.
With no downtime for the application we have performed the following tasks:

•  Installed Oracle GoldenGate on both source and target servers. (On source for the Oracle 9i environment we are using OGG 11.1.1.1.4 and on the target Oracle 11g environment we are using OGG 11.2.1.0.3)

• Supplemental logging has been turned on at the database level for the source database

• Supplemental logging has been enabled at the table level using the ADD TRANDATA or ADD SCHEMATRANDATA GoldenGate commands

• Extract DDL capture has been enabled on the source

• Configured the Manager process on both source and target

• Created the Extract process on source

• Created the Replicat process on target

• Installed the 11.2.0.4 Oracle software and created the target 11g database with the required tablespaces and database parameters as the source database.Remember some parameters in Oracle 9i have been deprecated in 11g and certain new parameters have been added.

We need to be able to capture all changes in the database while the Oracle 9i database export is in progress. So we will start the capture Extract process or processes BEFORE we start the full database export.
We also then use the DBMS_FLASHBACK package to obtain the reference SCN number on which the consistent database export will be based. Changes which occur in the database post this SCN will not be captured in the export dump file but will be captured by the Golden Gate Extract process on source and applied by the Replicat process on the target.
Let us look at an example.
We have created a user called MIG_TEST and created some objects in this schema.

SQL> create user mig_test
  2  identified by mig_test
  3  default tablespace users
  4  temporary tablespace temp;

User created.

SQL> grant dba to mig_test;

Grant succeeded.

SQL> conn  mig_test/mig_test
Connected.
SQL> create table mytables as select * from all_tables;

Table created.

SQL> create table myindexes as select * from all_indexes;

Table created.




SQL> alter table mytables
  2  add constraint pk_mytables primary key (owner,table_name);

Table altered.

SQL> alter table myindexes
  2  add constraint pk_myindexes primary key (owner,index_name);

Table altered.


SQL> create table myobjects as select * from all_objects;

Table created.


SQL>  alter table myobjects
  2   add constraint pk_myobjects primary key (owner,object_name,object_type);

Table altered.

Obtain the current SCN on the source database and perform the full database export

SQL> SELECT dbms_flashback.get_system_change_number as current_scn
     from dual;

CURRENT_SCN
-----------
      63844


$ exp file=/app/oracle/oradump/testdb/exp/exp_mig.dmp full=y flashback_scn=63844 log= exp_mig.log

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Username: system
Password:

Connected to: Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set

About to export the entire database ...
. exporting tablespace definitions
. exporting profiles
. exporting user definitions
. exporting roles
. exporting resource costs
. exporting rollback segment definitions
. exporting database links
. exporting sequence numbers
. exporting directory aliases
. exporting context namespaces
. exporting foreign function library names
. exporting PUBLIC type synonyms
. exporting private type synonyms

....

............

While the export is in progress, we make some changes to the objects in the MIG_TEST schema

SQL> update myobjects set object_type ='INDEX' where owner='MIG_TEST';

6 rows updated.

SQL> commit;

Commit complete.


SQL> delete mytables;

465 rows deleted.

SQL> commit;

Commit complete.

We can see that the MIG_TEST tables have been exported. But note that the last changes we made will not be part of the export as they were occurring in the database after the SCN 64844 which is the SCN the consistent export was based on.
So the MYTABLES table still has the 465 rows included in the export dump file even though we just deleted all the rows from the table.

 about to export MIG_TEST's tables via Conventional Path ...
. . exporting table                      MYINDEXES        474 rows exported
. . exporting table                      MYOBJECTS       5741 rows exported
. . exporting table                       MYTABLES        465 rows exported

On the 11.2.0.4 target database we perform the full database import.
Note the MYTABLES table still has 465 rows as we issued the DELETE statement after the export was started in the source database

. importing MIG_TEST's objects into MIG_TEST
. . importing table                    "MYINDEXES"        474 rows imported
. . importing table                    "MYOBJECTS"       5742 rows imported
. . importing table                     "MYTABLES"        465 rows imported

After the import has completed we now start the Replicat process on the target
Note we are using the AFTERSCN clause to tell the replicat to only apply all thos changes on the target which were generated on the source database after the SCN 63844

GGSCI (LINT0004) 4>  start replicat repmig aftercsn  63844

Sending START request to MANAGER ...
REPLICAT REPMIG starting


GGSCI (LINT0004) 5> info replicat repmig

REPLICAT   REPMIG    Last Started 2014-12-17 14:07   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:04 ago)
Log Read Checkpoint  File ./dirdat/cc000000
                     2014-12-17 13:54:40.150229  RBA 2586343

We can see that the replicat process has applied the required UPDATE and DELETE statements which were captured in the OGG trail file

GGSCI (LINT0004) 6> stats replicat repmig latest

Sending STATS request to REPLICAT REPMIG ...

Start of Statistics at 2014-12-17 14:08:09.

Replicating from MIG_TEST.MYOBJECTS to MIG_TEST.MYOBJECTS:

*** Latest statistics since 2014-12-17 14:07:33 ***
        Total inserts                                      0.00
        Total updates                                      6.00
        Total deletes                                      0.00
        Total discards                                     0.00
        Total operations                                   6.00

Replicating from MIG_TEST.MYTABLES to MIG_TEST.MYTABLES:

*** Latest statistics since 2014-12-17 14:07:33 ***
        Total inserts                                      0.00
        Total updates                                      0.00
        Total deletes                                    465.00
        Total discards                                     0.00
        Total operations                                 465.00

We will now verify that there is no lag in the Replicat process and the source and target databases are in sync.
At this stage the outage will commence for the application.
We stop the extract and replicat processes and will need to disconnect application users who were connected to the original 9i database and point the application now to connect to the new Oracle 11g database.
The duration of the application outage will depend on how fast we can perform the disconnection of the users and reconfiguration of the application to connect to the upgraded database.