Converting from Physical Standby to Logical Standby.
Creating a Logical Standby Database by Converting from Physical to Logical Standby
You can now easily convert a physical standby database to a logical one. Here are the steps:
1. On the standby database, stop the managed recovery process:
SQL> alter database recover managed standby database cancel;
Database altered.
Or
DGMGRL> edit database stdy set state='APPLY-OFF';
2. The standby database will need to get the data dictionary information from somewhere. The dictionary information should be put in the redo stream that comes from the primary. So, on the primary database, issue the following to build the LogMiner tables for dictionary:
SQL> begin
dbms_logstdby.build;
end;
/
PL/SQL procedure successfully completed.
Alert log.
Logminer Bld: Build started
ALTER SYSTEM SWITCH ALL LOGFILE start (orcl)
2012-03-05 13:49:50.416000 +05:30
ALTER SYSTEM SWITCH ALL LOGFILE complete (orcl)
Thread 1 advanced to log sequence 41 (LGWR switch)
Current log# 2 seq# 41 mem# 0: +DATA/orcl/onlinelog/group_2.264.719142951
Current log# 2 seq# 41 mem# 1: +DATA/orcl/onlinelog/group_2.265.719142957
Mon Mar 05 13:49:50 2012
Logminer Bld: Lockdown Complete. DB_TXN_SCN is 0 1013551 LockdownSCN is 1013568
2012-03-05 13:49:55.952000 +05:30
Archived Log entry 44 added for thread 1 sequence 40 ID 0x4a53118e dest 1:
2012-03-05 13:49:59.315000 +05:30
ARC3: Standby redo logfile selected for thread 1 sequence 40 for destination LOG_ARCHIVE_DEST_2
2012-03-05 13:50:38.821000 +05:30
ALTER SYSTEM ARCHIVE LOG
2012-03-05 13:50:40.303000 +05:30
Thread 1 advanced to log sequence 42 (LGWR switch)
Current log# 3 seq# 42 mem# 0: +DATA/orcl/onlinelog/group_3.266.719142961
Current log# 3 seq# 42 mem# 1: +DATA/orcl/onlinelog/group_3.267.719142965
2012-03-05 13:50:45.058000 +05:30
Archived Log entry 46 added for thread 1 sequence 41 ID 0x4a53118e dest 1:
Mon Mar 05 13:50:45 2012
Logminer Bld: Done
SQL> select SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI from v$database ;
SUPPLEME SUP SUP
-------- --- ---
IMPLICIT YES YES
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES' and STANDBY_DEST='NO';
NAME
---------------------------------------------------------------------------------
+FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
3. Now, issue the command in standby side to convert it to logical:
SQL> alter database recover to logical standby lstdy;
Database altered.
If you didn't execute Step 2, the above command will wait since the dictionary information is not found. Don't worry; just execute the Step 2 at this point. If you have enabled RTA, the information will immediately appear on the standby database.
4. Issue a few log switches on primary to make sure the archived logs are created and sent over to the standby:
SQL> alter system switch logfile;
System altered.
5. On the standby side, you can see that the alter database command has completed, after some time. Now the standby is a logical one.
Alert log
alter database recover to logical standby lstdy
Media Recovery Start: Managed Standby Recovery (stdy)
2012-03-05 13:53:35.624000 +05:30
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
2012-03-05 13:53:36.677000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_40.276.777131407
2012-03-05 13:53:53.679000 +05:30
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
2012-03-05 13:54:02.997000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
2012-03-05 13:54:21.718000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_42.278.777131463
Incomplete Recovery applied until change 1014941 time 03/05/2012 13:50:46
Media Recovery Complete (stdy)
krsv_proc_kill: Killing 4 processes (all RFS)
2012-03-05 13:54:24.439000 +05:30
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 1014941
Resetting resetlogs activation ID 1246957966 (0x4a53118e)
Online log +DATA/stdy/onlinelog/group_1.262.776967645: Thread 1 Group 1 was previously cleared
Online log +FRA/stdy/onlinelog/group_1.256.776967651: Thread 1 Group 1 was previously cleared
Online log +DATA/stdy/onlinelog/group_2.263.776967657: Thread 1 Group 2 was previously cleared
Online log +FRA/stdy/onlinelog/group_2.257.776967663: Thread 1 Group 2 was previously cleared
Online log +DATA/stdy/onlinelog/group_3.264.776967673: Thread 1 Group 3 was previously cleared
Online log +FRA/stdy/onlinelog/group_3.258.776967677: Thread 1 Group 3 was previously cleared
2012-03-05 13:54:26.926000 +05:30
Standby became primary SCN: 1014939
Setting recovery target incarnation to 4
RECOVER TO LOGICAL STANDBY: Complete - Database shutdown required after NID finishes
*** DBNEWID utility started ***
DBID will be changed from 1246923666 to new DBID of 2386946899 for database ORCL
DBNAME will be changed from ORCL to new DBNAME of LSTDY
Starting datafile conversion
Datafile conversion complete
Database name changed to LSTDY.
Modify parameter file and generate a new password file before restarting.
Database ID for database LSTDY changed to 2386946899.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
2012-03-05 13:54:28.351000 +05:30
Completed: alter database recover to logical standby lstdy
2012-03-05 13:54:34.755000 +05:30
destination database instance is 'started' not 'mounted'
6. Bounce the database:
SQL> shutdown
SQL> startup mount
SQL> alter database open resetlogs;
SQL> select open_mode from v$database;
OPEN_MODE
----------
READ WRITE
SQL> select name from v$database;
NAME
---------
LSTDY
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
LOGICAL STANDBY
SQL> select guard_status from v$database;
GUARD_S
-------
ALL
7. Now that this is a logical standby database, you should start the SQL Apply process.
SQL> alter database start logical standby apply immediate;
The logical standby database is now fully operational! Once you convert the physical standby to a logical one, you can't convert it back to a physical one unless you use the special clause ("keep identity"), described in the section below.
Output from Alert logs
Verify That the Logical Standby Database Is Performing Properly
a. Verify that the archived redo log files were registered on logical standby:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- ---
40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
SQL>
b. Begin sending redo data to the standby database:
Connect to the primary database and issue the following command to begin sending redo data to the standby database
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Query the DBA_LOGSTDBY_LOG view to verify that the archived redo log files were registered. Connect to the logical standby database and re-query the DBA_LOGSTDBY_LOG view as shown in step a. This enables you to verify that the new archived redo log files were
registered.
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- ---
40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
43 05-MAR-12 05-MAR-12 NO NO
44 05-MAR-12 05-MAR-12 NO NO
SQL>
d. Verify that redo data is being applied correctly:
On the logical standby database, query the V$LOGSTDBY_STATS view to verify that redo data is being applied correctly:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME = 'coordinator state';
NAME VALUE
------------------------------ ----------------------------------------------------------------
coordinator state INITIALIZING
SQL>
e. View the V$LOGSTDBY view to see current Query the V$LOGSTDBY view on the logical standby database to see a current snapshot of SQL Apply activity. A text message describing the current activity of each process that is involved in reading and applying changes is displayed.
SQL> SELECT TYPE, HIGH_SCN, STATUS
FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
------------------------------ ---------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COORDINATOR 1014941 ORA-16116: no work available
ANALYZER 1013570 ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
READER 1014928 ORA-16127: stalled waiting for additional transactions to be applied
BUILDER 1014166 ORA-16117: processing
PREPARER 1014168 ORA-16117: processing
10 rows selected.
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
------------------------------ ---------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COORDINATOR ORA-16117: processing
READER 624900 ORA-16117: processing
BUILDER ORA-16117: processing
PREPARER ORA-16117: processing
f. Check the overall progress of SQL Apply:
Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check the overall progress of SQL Apply:
SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS;
SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ----------
1015278 1015278
Add theLogical Standby to the Broker Configuration
DGMGRL> remove database stdy;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> ADD DATABASE STDY AS CONNECT IDENTIFIER IS STDY MAINTAINED AS logical;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> enable database stdy;
DGMGRL> SHOW CONFIGURATION;
Creating a Logical Standby Database by Converting from Physical to Logical Standby
You can now easily convert a physical standby database to a logical one. Here are the steps:
1. On the standby database, stop the managed recovery process:
SQL> alter database recover managed standby database cancel;
Database altered.
Or
DGMGRL> edit database stdy set state='APPLY-OFF';
2. The standby database will need to get the data dictionary information from somewhere. The dictionary information should be put in the redo stream that comes from the primary. So, on the primary database, issue the following to build the LogMiner tables for dictionary:
SQL> begin
dbms_logstdby.build;
end;
/
PL/SQL procedure successfully completed.
Alert log.
Logminer Bld: Build started
ALTER SYSTEM SWITCH ALL LOGFILE start (orcl)
2012-03-05 13:49:50.416000 +05:30
ALTER SYSTEM SWITCH ALL LOGFILE complete (orcl)
Thread 1 advanced to log sequence 41 (LGWR switch)
Current log# 2 seq# 41 mem# 0: +DATA/orcl/onlinelog/group_2.264.719142951
Current log# 2 seq# 41 mem# 1: +DATA/orcl/onlinelog/group_2.265.719142957
Mon Mar 05 13:49:50 2012
Logminer Bld: Lockdown Complete. DB_TXN_SCN is 0 1013551 LockdownSCN is 1013568
2012-03-05 13:49:55.952000 +05:30
Archived Log entry 44 added for thread 1 sequence 40 ID 0x4a53118e dest 1:
2012-03-05 13:49:59.315000 +05:30
ARC3: Standby redo logfile selected for thread 1 sequence 40 for destination LOG_ARCHIVE_DEST_2
2012-03-05 13:50:38.821000 +05:30
ALTER SYSTEM ARCHIVE LOG
2012-03-05 13:50:40.303000 +05:30
Thread 1 advanced to log sequence 42 (LGWR switch)
Current log# 3 seq# 42 mem# 0: +DATA/orcl/onlinelog/group_3.266.719142961
Current log# 3 seq# 42 mem# 1: +DATA/orcl/onlinelog/group_3.267.719142965
2012-03-05 13:50:45.058000 +05:30
Archived Log entry 46 added for thread 1 sequence 41 ID 0x4a53118e dest 1:
Mon Mar 05 13:50:45 2012
Logminer Bld: Done
SQL> select SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI from v$database ;
SUPPLEME SUP SUP
-------- --- ---
IMPLICIT YES YES
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES' and STANDBY_DEST='NO';
NAME
---------------------------------------------------------------------------------
+FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
3. Now, issue the command in standby side to convert it to logical:
SQL> alter database recover to logical standby lstdy;
Database altered.
If you didn't execute Step 2, the above command will wait since the dictionary information is not found. Don't worry; just execute the Step 2 at this point. If you have enabled RTA, the information will immediately appear on the standby database.
4. Issue a few log switches on primary to make sure the archived logs are created and sent over to the standby:
SQL> alter system switch logfile;
System altered.
5. On the standby side, you can see that the alter database command has completed, after some time. Now the standby is a logical one.
Alert log
alter database recover to logical standby lstdy
Media Recovery Start: Managed Standby Recovery (stdy)
2012-03-05 13:53:35.624000 +05:30
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 2 slaves
2012-03-05 13:53:36.677000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_40.276.777131407
2012-03-05 13:53:53.679000 +05:30
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
2012-03-05 13:54:02.997000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_41.277.777131459
2012-03-05 13:54:21.718000 +05:30
Media Recovery Log +FRA/stdy/archivelog/2012_03_05/thread_1_seq_42.278.777131463
Incomplete Recovery applied until change 1014941 time 03/05/2012 13:50:46
Media Recovery Complete (stdy)
krsv_proc_kill: Killing 4 processes (all RFS)
2012-03-05 13:54:24.439000 +05:30
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 1014941
Resetting resetlogs activation ID 1246957966 (0x4a53118e)
Online log +DATA/stdy/onlinelog/group_1.262.776967645: Thread 1 Group 1 was previously cleared
Online log +FRA/stdy/onlinelog/group_1.256.776967651: Thread 1 Group 1 was previously cleared
Online log +DATA/stdy/onlinelog/group_2.263.776967657: Thread 1 Group 2 was previously cleared
Online log +FRA/stdy/onlinelog/group_2.257.776967663: Thread 1 Group 2 was previously cleared
Online log +DATA/stdy/onlinelog/group_3.264.776967673: Thread 1 Group 3 was previously cleared
Online log +FRA/stdy/onlinelog/group_3.258.776967677: Thread 1 Group 3 was previously cleared
2012-03-05 13:54:26.926000 +05:30
Standby became primary SCN: 1014939
Setting recovery target incarnation to 4
RECOVER TO LOGICAL STANDBY: Complete - Database shutdown required after NID finishes
*** DBNEWID utility started ***
DBID will be changed from 1246923666 to new DBID of 2386946899 for database ORCL
DBNAME will be changed from ORCL to new DBNAME of LSTDY
Starting datafile conversion
Datafile conversion complete
Database name changed to LSTDY.
Modify parameter file and generate a new password file before restarting.
Database ID for database LSTDY changed to 2386946899.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
2012-03-05 13:54:28.351000 +05:30
Completed: alter database recover to logical standby lstdy
2012-03-05 13:54:34.755000 +05:30
destination database instance is 'started' not 'mounted'
6. Bounce the database:
SQL> shutdown
SQL> startup mount
SQL> alter database open resetlogs;
SQL> select open_mode from v$database;
OPEN_MODE
----------
READ WRITE
SQL> select name from v$database;
NAME
---------
LSTDY
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
LOGICAL STANDBY
SQL> select guard_status from v$database;
GUARD_S
-------
ALL
7. Now that this is a logical standby database, you should start the SQL Apply process.
SQL> alter database start logical standby apply immediate;
The logical standby database is now fully operational! Once you convert the physical standby to a logical one, you can't convert it back to a physical one unless you use the special clause ("keep identity"), described in the section below.
Output from Alert logs
Verify That the Logical Standby Database Is Performing Properly
a. Verify that the archived redo log files were registered on logical standby:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- ---
40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
SQL>
b. Begin sending redo data to the standby database:
Connect to the primary database and issue the following command to begin sending redo data to the standby database
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
c. Query the DBA_LOGSTDBY_LOG view to verify that the archived redo log files were registered. Connect to the logical standby database and re-query the DBA_LOGSTDBY_LOG view as shown in step a. This enables you to verify that the new archived redo log files were
registered.
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN,DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
---------- --------- --------- --- ---
40 03-MAR-12 05-MAR-12 NO NO
41 05-MAR-12 05-MAR-12 YES YES
42 05-MAR-12 05-MAR-12 NO NO
43 05-MAR-12 05-MAR-12 NO NO
44 05-MAR-12 05-MAR-12 NO NO
SQL>
d. Verify that redo data is being applied correctly:
On the logical standby database, query the V$LOGSTDBY_STATS view to verify that redo data is being applied correctly:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME = 'coordinator state';
NAME VALUE
------------------------------ ----------------------------------------------------------------
coordinator state INITIALIZING
SQL>
e. View the V$LOGSTDBY view to see current Query the V$LOGSTDBY view on the logical standby database to see a current snapshot of SQL Apply activity. A text message describing the current activity of each process that is involved in reading and applying changes is displayed.
SQL> SELECT TYPE, HIGH_SCN, STATUS
FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
------------------------------ ---------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COORDINATOR 1014941 ORA-16116: no work available
ANALYZER 1013570 ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
READER 1014928 ORA-16127: stalled waiting for additional transactions to be applied
BUILDER 1014166 ORA-16117: processing
PREPARER 1014168 ORA-16117: processing
10 rows selected.
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
------------------------------ ---------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
COORDINATOR ORA-16117: processing
READER 624900 ORA-16117: processing
BUILDER ORA-16117: processing
PREPARER ORA-16117: processing
f. Check the overall progress of SQL Apply:
Query the V$LOGSTDBY_PROGRESS view on the logical standby database to check the overall progress of SQL Apply:
SQL> SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS;
SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN LATEST_SCN
----------- ----------
1015278 1015278
Add theLogical Standby to the Broker Configuration
DGMGRL> remove database stdy;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> ADD DATABASE STDY AS CONNECT IDENTIFIER IS STDY MAINTAINED AS logical;
DGMGRL> SHOW CONFIGURATION;
DGMGRL> enable database stdy;
DGMGRL> SHOW CONFIGURATION;