转 DG switchover
I. Pre-Switchover Checks
These steps should be completed before the switchover planned maintenance window begins. Our recommendation is that these are done a couple days in advance.
Verify Managed Recovery is running on the standby
The following query at the standby verifies that managed recovery is running:
The following query at the Primary verifies that recovery is running with “REAL TIME APPLY” option. In the example below, LOG_ARCHIVE_DEST_2 is established to ship redo to the target standby (dest_id=2):
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
If managed standby recovery is not running or not started with real-time apply, restart managed recovery with real-time apply enabled:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Note: If you previously defined a delay for this standby the delay is ignored when you start real time apply
For more information see Section 3.2.7 Verify the Physical Standby Database Is Performing Properly
Verify Sufficient Number of Archiver Processes
Ensure Online Redo Log Files on the Target Physical Standby have been cleared
Online redo logs on the target physical standby need to be cleared before that standby database can become a primary database. Although this will automatically happen as part of the SWITCHOVER TO PRIMARY command, it is recommended that the logs are cleared prior to the switchover.
Setting the LOG_FILE_NAME_CONVERT parameter at the physical standby will cause the online redo logs to be automatically cleared when managed recovery is started on the standby.
If your databases are using Oracle Managed Files (OMF) or you have already set the parameter LOG_FILE_NAME_CONVERT you can skip this step as the online log files will always be cleared automatically.
Clearing online redo logs as part of the SWITCHOVER TO PRIMARY command can make the switchover command susceptible to termination by another process that is waiting on access to the CONTROLFILE. The CONTROLFILE waiter will attempt to kill the switchover after a timeout is 15 minutes.
Oracle recommends setting LOG_FILE_NAME_CONVERT to automatically clear online redo logs on the physical standby database. In the event the primary database and the physical standby database have the exact same directory path to the online redo logs, it is acceptable to set LOG_FILE_NAME_CONVERT such that the entry pairs have the same value.
As an example, if the online redo logs are stored in /oradata/order_db/redo for both the primary and physical standby databases on their respective servers, you can set the parameter value as
LOG_FILE_NAME_CONVERT=’/oradata/order_db/redo/’,’/oradata/order_db/redo/’
This will initiate automatic clearing of the online redo logs on the physical standby database when managed recovery is started.
Since the LOG_FILE_NAME_CONVERT parameter is not dynamic you must restart the standby database for the property change to take affect.
If you have not set your environment to automatically clear the online redo logs and you do not want to restart the standby database, you should manually clear them at some point prior to the switchover. This can be done at any time.
On the target physical standby run the following query to determine if the online redo logs have not been cleared:
WHERE L.GROUP# = LF.GROUP#
AND L.STATUS NOT IN (‘UNUSED’, ‘CLEARING’,’CLEARING_CURRENT’);
If the above query returns rows, on the target physical standby stop Redo Apply, issue the following statement for each GROUP# returned and restart Redo Apply:
Please note that later when you do the actual switchover if it is terminated by a CONTROLFILE waiter timeout, just re-issue the SWITCHOVER TO PRIMARY command until it completes successfully.
You should monitor your alert log to ensure your online redo logs are being cleared and you are not experiencing some other issue.
Verify there are no large Gaps
Identify the current sequence number for each thread on the primary database
Verify the target physical standby database has applied up to, but not including the logs from the primary query. On the standby the following query should be within 1 or 2 of the primary query result.
WHERE APPLIED = 'YES'
AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION WHERE STATUS = ‘CURRENT’)
GROUP BY THREAD#;
If large gaps exist (more than 3 logs) then see Section 6.4.3 Redo Gap Detection and Resolution.
Verify Primary and Standby tempfiles match and all datafiles are ONLINE
FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;
If the queries do not match then you can correct the mismatch now or immediately after the open of the new primary database.
Prior to switchover, on the target standby, verify that all datafiles necessary for updates after role transition to primary are ONLINE.
On the target standby:
If there are any OFFLINE datafiles, and these are needed after switchover, bring them ONLINE:
III. Switchover
These steps are completed as part of the switchover process on the day of the planned outage.
Cancel any apply delay for the target standby
Remove any delay in applying redo that may be in effect on the standby database that will become the new primary database. If there is a delay then on the target standby database execute the following command.
Clear Potential Blocking Parameters & Jobs
Capture current job state on the primary:
Depending on what the running job is, be ready to terminate the job if necessary.
SQL> SHOW PARAMETER job_queue_processes
Note: Job candidates to be disabled among others: oracle text sync and optimizer, RMAN backups, application garbage collectors, application background agents.
Block further job submission
Disable any jobs that may interfere.
Shutdown all mid-tiers (optional)
This can be done in parallel to the switchover.
Turn on Data Guard tracing on primary and standby
Tracing is turned on to have diagnostic information available in case any issues arise. Turning on tracing does not have any noticeable impact on switchover time but does require space for the trace output.
Capture the current value on both the primary and the target physical standby databases
Set Data Guard trace level to 8191 on both the primary and the target physical standby databases
Trace output will appear under the destination pointed to by the database parameter BACKGROUND_DUMP_DEST with “mrp” in the file name.
Tail Alert Logs (optional) on all instances
Locate alert logs by showing database parameter background_dump_dest
Tail the alert logs
> tail –f <background_dump_dest location>/alert*
Create Guaranteed Restore Points (optional)
The standard switchover fallback options should suffice for successfully backing out of a switchover. However, if you want an additional fallback option then you can create a guaranteed restore point on the primary and standby database participating in the switchover.
On the standby
Stop the apply process
Create a guaranteed restore point
Start the apply process
USING CURRENT LOGFILE DISCONNECT;
On the primary
Create a guaranteed restore point
Note: If a guaranteed restore points are created, make sure they are dropped post-switchover!
Verify that the primary database can be switched to the standby role
Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database:
SWITCHOVER_STATUS
-----------------
TO STANDBY
A value of TO STANDBY or SESSIONS ACTIVE (which requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role. If neither of these values is returned, a switchover is not possible because redo transport is either mis-configured or is not functioning properly. See Appendix A.4 Problems Switching Over to a Physical Standby Database
If The Primary is a RAC, then shutdown all secondary primary instances
A normal or immediate shutdown can be done, but to expedite the shutdown issue a SHUTDOWN ABORT on secondary RAC instances on the primary cluster only leaving one Primary instance up. Wait until the remaining Primary instance has completed cluster reconfiguration (and performed recovery if you chose to abort the secondary instances) before continuing.
Switchover the primary to a standby database
If an ORA-16139 error is encountered, as long as V$DATABASE.DATABASE_ROLE=’PHYSICAL STANDBY’, then you can proceed. A common case where this can occur is when there are a large number of data files. Once managed recovery is started on the new standby, the database will recover.
If the role was not changed then you need to cancel the switchover and review the alert logs and trace files further.
Verify the standby has received the end-of-redo (EOR) log(s)
In the primary alert log you will see messages like these:
Tue Mar 15 16:12:15 2011
MRP0 started with pid=17, OS id=2717
MRP0: Background Managed Standby Recovery process started (SFO)
Serial Media Recovery started
Managed Standby Recovery not using Real Time Apply
Online logfile pre-clearing operation disabled by switchover
Media Recovery Log /u01/app/flash_recovery_area/SFO/archivelog/2011_03_15/o1_mf_1_133_6qzl0yvd_.arc
Identified End-Of-Redo for thread 1 sequence 133
Resetting standby activation ID 0 (0x0)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Applied until change 4314801
MRP0: Media Recovery Complete: End-Of-REDO (SFO)
MRP0: Background Media Recovery process shutdown (SFO)
Tue Mar 15 16:12:21 2011
Switchover: Complete - Database shutdown required (SFO)
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
And correspondingly in the standby alert log file you should see messages like these:
RFS[8]: Assigned to RFS process 2715
RFS[8]: Identified database type as 'physical standby': Client is Foreground pid 2568
Media Recovery Log /u01/app/flash_recovery_area/NYC/archivelog/2011_03_15/o1_mf_1_133_6qzl0yjp_.arc
Identified End-Of-Redo for thread 1 sequence 133
Resetting standby activation ID 2680651518 (0x9fc77efe)
Media Recovery End-Of-Redo indicator encountered
Media Recovery Continuing
Resetting standby activation ID 2680651518 (0x9fc77efe)
Media Recovery Waiting for thread 1 sequence 134
In versions prior to Oracle Database 11g Release 2, the MRP (Redo Apply coordinator) would stop automatically after processing the End-of-Redo marker. With Oracle Database 11g Release 2, it no longer stops leaving all bystander standby databases still ready to apply redo from the new primary database without having to be restarted. The MRP process will be shut down automatically by the switchover command when executed at the target standby database.
Verify that the standby database can be switched to the primary role
Query the SWITCHOVER_STATUS column of the V$DATABASE view on the standby database:
SWITCHOVER_STATUS
-----------------
TO PRIMARY
A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.
Switchover the standby database to a primary
In the standby alert log file you should see messages like these:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
ALTER DATABASE SWITCHOVER TO PRIMARY (NYC)
Maximum wait for role transition is 15 minutes.
Switchover: Media recovery is still active
Role Change: Canceling MRP - no more redo to apply
Tue Mar 15 16:16:45 2011
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /u01/app/diag/rdbms/nyc/NYC/trace/NYC_pr00_2467.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Waiting for MRP0 pid 2460 to terminate
Errors in file /u01/app/diag/rdbms/nyc/NYC/trace/NYC_pr00_2467.trc:
ORA-16037: user requested cancel of managed recovery operation
Tue Mar 15 16:16:45 2011
MRP0: Background Media Recovery process shutdown (NYC)
Role Change: Canceled MRP
Open the new primary database
Note: There will be an increase in I/O activity while the new primary’s standby redo logs are cleared.
Correct any tempfile mismatch
If there was a tempfile that was not corrected during the pre-switchover check, then correct it now on the new primary.
Restart the new standby
If the new standby database (former primary database) was not shutdown since switching it to standby, bring it to the mount state and start managed recovery. This can be done in parallel to the new primary open.
Note: If you use IMMEDIATE, an ABORT will be performed anyway as of 11.2.0.2 and you would see the following in the alert log:
Performing implicit shutdown abort due to switchover to physical standby
Shutting down instance (abort)
License high water mark = 15
USER (ospid: 14665): terminating the instance
Instance terminated by USER, pid = 14665
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
Note: If you were using a delay for your standby then you would restart the apply without real time apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Finally, if the database is a RAC, then start all secondary instances on the new standby.
Contingency or Fallback
See Appendix A.4.5 Roll Back After Unsuccessful Switchover and Start Over in the Data Guard Concepts and Administration manual.
IV. Post-Switchover Steps
Set Trace to Prior Value
For each instance on the Primary and Standby:
Reset Jobs
Set the job queue processes to its original value on the new standby.
Enable any jobs that were disabled.
Drop any Switchover Guaranteed Restore Points
On all databases where a Guaranteed Restore point was created
####sample 1:
屏蔽相关告警信息
"目标主机：
SELECT PROCESS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';
源主机：
SELECT DEST_ID,RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS
"
"每个源主机：
SELECT THREAD#, SEQUENCE# FROM V$THREAD;
目标主机：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG
WHERE APPLIED = 'YES'
AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION WHERE STATUS = 'CURRENT')
GROUP BY THREAD#;
"
"
目标主机
1.show parameter LOG_FILE_NAME_CONVERT
2.
SELECT DISTINCT L.GROUP# FROM V$LOG L, V$LOGFILE LF
WHERE L.GROUP# = LF.GROUP#
AND L.STATUS NOT IN ('UNUSED', 'CLEARING','CLEARING_CURRENT');
如果上面查询有结果，需要手工运行下面命令做清理
If the above query returns rows, on the target physical standby stop Redo Apply, issue the following statement for each GROUP# returned and restart Redo Apply:
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <ORL GROUP# from the query above>;
"
"1.目标主机：
SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;
源主机：
SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;
确认以上查询结果匹配。
2.目标主机：
SELECT NAME FROM V$DATAFILE WHERE STATUS=’OFFLINE’;
"
"1.源主机：
SELECT * FROM DBA_JOBS_RUNNING;
SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED FROM
DBA_SCHEDULER_JOBS WHERE ENABLED='TRUE' AND OWNER <> 'SYS';
SHOW PARAMETER job_queue_processes
2.
ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID='*';
EXECUTE DBMS_SCHEDULER.DISABLE( <job_name> );
"
"
create pfile='$HOME/pfile_$ORACLE_SID.bak' from spfile;
alter database backup controlfile to '$HOME/$ORACLE_SID_ctl.bak'; --替换为具体变量值"
"create pfile='$HOME/pfile_$ORACLE_SID.bak' from spfile;
alter database backup controlfile to '$HOME/$ORACLE_SID_ctl.bak'; --替换为具体变量值"
"select xidusn,s.sid,s.last_call_et, s.username, used_ublk,USED_UREC,space,
RECURSIVE, NOUNDO, START_UBAFIL,start_ubablk, start_uext
from v$transaction t, v$session s
where t.ses_addr=s.saddr;
以上查询查出的session，请反馈应用处理，请应用自行确认commit或者可以kill的session，请先kill。
select 'alter system kill session '''||SID||','||serial#||''';' from v$session where username not like 'SYS%';
--执行生成脚本 kill session"
"alter system switch logfile ;
alter system switch logfile ;
alter system switch logfile ;
alter system archive log current;
alter system checkpoint；"
"If The Primary is a RAC, then shutdown all secondary primary instances
for RAC: running in two nodes
shutdown immediately；
startup;
in node 1:
startup"
"su - opcore
sqlplus '/as sysdba'
SQL>select switchover_status from v$database;"
"sqlplus '/as sysdba'
#switchover_status的值如果是To standby:
SQL> alter database commit to switchover to physical standby;
#switchover_status的值如果是sessions active:
SQL> alter database commit to switchover to physical standby with session shutdown;"
"
sqlplus '/as sysdba'
SQL> select switchover_status from v$database"
"
sqlplus '/as sysdba'
#switchover_status的值如果是To primary：
SQL> alter database commit to switchover to primary;
#switchover_status的值如果是sessions active:
SQL> alter database commit to switchover to primary with session shutdown;"
"
sqlplus '/as sysdba'
SQL> startup;"
"通过在原有临时表空间的基础上添加数据文件resize的方式：
select * from v$tempfile;
alter tablespace TEMP add tempfile '/u01/xxx/tempxxx.dbf' size 10G autoextend off;
alter database tempfile '/u01/xxx/tempxxx.dbf' resize 20G;
select * from v$tempfile;"
"crs_stat -t
--若有其余节点实例未启动，请手工启动剩余所有节点：
sqlplus / as sysdba
startup;"
"sqlplus '/as sysdba'
SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> alter system switch logfile;"
"rman target /
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PA18MAIL are:
......
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
......
1分钟
如果备份策略不符合规范，修改归档日志删除策略
目标主机
如果备份在dg库进行，修改归档日志删除策略如下：
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
如果备份在主库，修改归档日志删除策略：
--无dg库：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
--有dg库：
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY BACKED UP 1 TIMES TO 'SBT_TAPE';"
登陆到NBU控制台，手动执行一次全备操作
"
sqlplus '/as sysdba'
SQL> SHUTDOWN ABORT;
SQL> STARTUP MOUNT;
SQL> alter database recover managed standby database using current logfile disconnect;
SQL> exit;"
"
cd $ORACLE_BASE/admin/nods/bdump
find ./ -name ""*.trc"" -mtime +7 -exec rm -rf {} \;
rman target / nocatalog
rman> delete archivelog until time 'sysdate-1';
rman> exit;"
"1.su - opcore
. ./profile
crontab -l
# 恢复原生产环境的CRONTAB任务
2.Reset Jobs
Set the job queue processes to its original value on the new standby.
SQL> ALTER SYSTEM SET job_queue_processes=<value saved> scope=both sid=’*’"
前端应用验证
#####sample 2 (use dbmgrl to switch-over)
SHOW CONFIGURATION
DGMGRL> SHOW CONFIGURATION
Configuration - DGTEST
Protection Mode: MaxPerformance
Databases:
testdg - Primary database
stestdg - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> show database testdg
Database - testdg
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
testdg
Database Status:
SUCCESS
DGMGRL> show database stestdg
Database - stestdg
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Apply Rate: 1.20 MByte/s
Real Time Query: OFF
Instance(s):
testdg
Database Status:
SUCCESS
DGMGRL>
DGMGRL> show database verbose stestdg
Database - stestdg
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Apply Rate: 1.20 MByte/s
Real Time Query: OFF
Instance(s):
testdg
Properties:
DGConnectIdentifier = 'stestdg'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'MANUAL'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
ApplyLagThreshold = '0'
TransportLagThreshold = '0'
TransportDisconnectedThreshold = '0'
SidName = 'testdg'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=rac2)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stestdg_DGMGRL)(INSTANCE_NAME=testdg)(SERVER=DEDICATED)))'
StandbyArchiveLocation = '/u02/app/oracle/fast_recovery_area'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
TopWaitEvents = '(monitor)'
Database Status:
SUCCESS
EDIT DATABASE 'stestdg' SET PROPERTY 'LogXptMode'='SYNC';
switchover to 'stestdg'
DGMGRL> switchover to 'stestdg';
Performing switchover NOW, please wait...
Operation requires a connection to instance "testdg" on database "stestdg"
Connecting to instance "testdg"...
Connected.
New primary database "stestdg" is opening...
Operation requires startup of instance "testdg" on database "testdg"
Starting instance "testdg"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "stestdg"
DGMGRL> show database stestdg
Database - stestdg
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
testdg
Database Status:
SUCCESS
DGMGRL> show database testdg ;
Database - testdg
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Apply Rate: 0 Byte/s
Real Time Query: OFF
Instance(s):
testdg
Database Status:
SUCCESS
###########sample 3 (use sqlplus to switch-over and re-create dbmgrl)
"su - op$ORACLE_SID
sqlplus '/as sysdba'
SQL>select switchover_status from v$database;"
"sqlplus '/as sysdba'
#switchover_status的值如果是To standby:
SQL> alter database commit to switchover to physical standby;
#switchover_status的值如果是sessions active:
SQL> alter database commit to switchover to physical standby with session shutdown;"
"
sqlplus '/as sysdba'
SQL> select switchover_status from v$database;"
"
sqlplus '/as sysdba'
#switchover_status的值如果是To primary：
SQL> alter database commit to switchover to primary;
#switchover_status的值如果是sessions active:
SQL> alter database commit to switchover to primary with session shutdown;"
"
sqlplus '/as sysdba'
SQL> startup;"
"根据第9步的查询结果，为临时表空间添加tempfile，并resize到对应大小：
select * from v$tempfile;
alter tablespace TEMP add tempfile '/db/xxx/tempxxx.dbf' size 100M autoextend off;
alter database tempfile '/db/xxx/tempxxx.dbf' resize 10G;
select * from v$tempfile;"
#new primary
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 922750112 bytes
Database Buffers 671088640 bytes
Redo Buffers 7319552 bytes
Database mounted.
Database opened.
SQL>
##new standby
SQL> select status from v$instance;
STATUS
------------
MOUNTED
SQL> shutdown immediate
ORA-01109: database not open
###new primary
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup
ORACLE instance started.
Total System Global Area 1603411968 bytes
Fixed Size 2253664 bytes
Variable Size 922750112 bytes
Database Buffers 671088640 bytes
Redo Buffers 7319552 bytes
Database mounted.
Database opened.
SQL>
###re-create dbmgl
DGMGRL> show configuration;
Configuration - DGTEST
Protection Mode: MaxPerformance
Databases:
stestdg - Primary database
Error: ORA-16810: multiple errors or warnings detected for the database
testdg - Physical standby database
Error: ORA-16810: multiple errors or warnings detected for the database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
DGMGRL> disable CONFIGURATION
Disabled
DGMGRL>remove CONFIGURATION
DGMGRL>
CREATE CONFIGURATION 'DGTEST'
AS
PRIMARY DATABASE IS 'testdg'
CONNECT IDENTIFIER IS 'testdg'
DGMGRL>
ADD DATABASE
'stestdg'
AS
CONNECT IDENTIFIER IS 'stestdg';
DGMGRL> SHOW CONFIGURATION
Configuration - DGTEST
Protection Mode: MaxPerformance
Databases:
testdg - Primary database
stestdg - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
DGMGRL>ENABLE CONFIGURATION
DGMGRL>show database testdg;
DGMGRL>show database stestdg;
###########sample 3 (dg swithover 如果没有提前停下job ,同时停下主库的监听，当2者同时满足时候，可以会有如下问题)
总结如下：
1.fal_client /fal_server 一定要设置对，解决gap 使用，fal_client 代表着本机是备库角色时候启用， fal_server 代表着远端是主库角色时候启用。
2.swithover 阶段之前，尽量停下job 任务
3.监听尽量不要停，特别是在when standby -》primary 阶段(alter database commit to switchover to primary with session shutdown)，
问题描述如下：
###primary server when pri ->standby: 因为job_process 参数没关闭，导致switchover to standby 可以正常完成，但是job 启动造成的最后一点的redlog 无法传递到远端，只能通过归档日志，
##只能通过fal_client,fal_server 传递，这个时间，该库的监听关闭，导致对端的库连接不上本端，最后一点的日志没有被备端接收。
Sun May 22 01:34:55 2022
Sun May 22 01:35:33 2022
alter database commit to switchover to physical standby with session shutdown
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 16909422] (dbe2)
Waiting for all non-current ORLs to be archived...
Waiting for the ORL for thread 1 sequence 97033 to be archived...
Sun May 22 01:35:33 2022
ARC4: LGWR is actively archiving destination LOG_ARCHIVE_DEST_3
ARC4: Standby redo logfile selected for thread 1 sequence 97033 for destination LOG_ARCHIVE_DEST_3
Archived Log entry 429609 added for thread 1 sequence 97033 ID 0x403e1492 dest 1:
ORL for thread 1 sequence 97033 has been archived...
All non-current ORLs have been archived.
Waiting for all FAL entries to be archived...
All FAL entries have been archived.
Waiting for potential Physical Standby switchover target to become synchronized...
Active, synchronized Physical Standby switchover target has been identified
Sun May 22 01:35:36 2022
Errors in file /db/dbe/app/db/diag/rdbms/rdbe/dbe2/trace/dbe2_j000_31392240.trc: <-job 参数没停，导致job 启动
ORA-12012: è^Ǫå^ʨæ^ɧè¡^Ìä½^Üä¸^Ú "SYMBOLS"."PRO_PRINT_JOB" å^Ǻé^Ô^Ù
ORA-16456: å^È^Çæ^Í¢å^È°å¤^Çç^Ô¨æ^Õ°æ^Í®åº^Óæ£å^ܨè¿^Ûè¡^Ìæ^È^Öå·²å®^Ìæ^È^Ð
ORA-16456: å^È^Çæ^Í¢å^È°å¤^Çç^Ô¨æ^Õ°æ^Í®åº^Óæ£å^ܨè¿^Ûè¡^Ìæ^È^Öå·²å®^Ìæ^È^Ð
Switchover End-Of-Redo Log thread 1 sequence 97034 has been fixed <- job 产生的最后的日志
Switchover End-Of-Redo Log thread 2 sequence 96436 has been fixed <- job 产生的最后的日志
Switchover: Primary highest seen SCN set to 0x27.0xeae77ac0
ARCH: Noswitch archival of thread 2, sequence 96436
ARCH: End-Of-Redo Branch archival of thread 2 sequence 96436
ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_3
ARCH: Standby redo logfile selected for thread 2 sequence 96436 for destination LOG_ARCHIVE_DEST_3
Archived Log entry 429611 added for thread 2 sequence 96436 ID 0x403e1492 dest 1:
ARCH: Standby redo logfile selected for thread 1 sequence 97034 for destination LOG_ARCHIVE_DEST_3
Archived Log entry 429613 added for thread 1 sequence 97034 ID 0x403e1492 dest 1:
ARCH: Archiving is disabled due to current logfile archival
Primary will check for some target standby to have received alls redo 《-
Final check for a synchronized target standby. Check will be made once.
LOG_ARCHIVE_DEST_3 is a potential Physical Standby switchover target
Active, synchronized target has been identified
Target has also received all redo
Switchover: Primary controlfile converted to standby controlfile succesfully.
###standby server, when standby -》primary
Sun May 22 01:35:33 2022
Media Recovery Waiting for thread 1 sequence 97034 <-等待远端传递最后一点的归档，这个时候由于远端的监听停了，oci连接不上，
<-fal client 开始报错,无法转换角色到primary, 这个时候相当于存在2个standby
***********************************************************************
Fatal NI connect error 12514, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=50.0.101.3)(PORT=1520))(ADDRESS=(PROTOCOL=TCP)(HOST=50.0.101.4)(P
FAL[client, USER]: Error 12541 connecting to RdbE for fetching gap sequence <- FAL[client, USER]:
Identified End-Of-Redo (switchover) for thread 1 sequence 97034 at SCN 0x27.eae77ac8
RFS[10]: Possible network disconnect with primary database
RFS[13]: Possible network disconnect with primary database
ALTER DATABASE SWITCHOVER TO PRIMARY (dbe2)
ORA-449 signalled during: alter database commit to switchover to primary with session shutdown... <-swith_to_primary 开始报错
Error 12514 received logging on to the standby
##fal_client 配置如下
NAME
------------------------------------
TYPE VALUE
-------------------------------------------- ------------------------------
fal_client
string dbE
fal_server
string RdbE
SQL> exit
最后解决办法：
重启远端的监听，srvctl 启动，在本地手工调用alter database commit to switchover to primary with session shutdown,触发数据库 自动到备端使用fal 抓取缺失的归档日志
SwitchOver after complete recovery through change 171444763336 <-正常阶段
Standby became primary SCN: 171444763334
Switchover: Complete - Database mounted as primary
总结如下：
1.fal_client /fal_server 一定要设置对，解决gap 使用，fal_client 代表着本机是备库角色时候启用， fal_server 代表着远端是主库角色时候启用。
2.swithover 阶段之前，尽量停下job 任务
3.监听尽量不要停，特别是在when standby -》primary 阶段(alter database commit to switchover to primary with session shutdown)，
####################
2023-06-12T01:02:44.662181+08:00
Stopping background process MMON
2023-06-12T01:02:45.662118+08:00
Stopping Emon pool
alter pluggable database all close immediate
OIVS(3):Pluggable database OIVS closing
OIVS(3):JIT: pid 22377 requesting stop
2023-06-12T01:02:45.679109+08:00
OIVS(3):Process termination requested for pid 28434 [source = rdbms], [info = 2] [request issued by pid: 22377, uid: 1001]
2023-06-12T01:02:45.726149+08:00
OIVS(3):KILL SESSION for sid=(591, 40170):
OIVS(3): Reason = PDB close immediate
OIVS(3): Mode = KILL HARD FORCE -/-/-
OIVS(3): Requestor = USER (orapid = 45, ospid = 22377, inst = 1)
OIVS(3): Owner = Process: USER (orapid = 83, ospid = 28434) 《————————强制 kill该进程 失败，应该是个rman 任务在跑
OIVS(3): Result = ORA-0
##解决办法
找到rman 进程，强制kill
###sample 1
New Alert Log Entries In 12.2 Related To Session Kill: KILL SESSION for sid= (Doc ID 2438653.1) To BottomTo Bottom
In this Document
Symptoms
Changes
Cause
Solution
APPLIES TO:
Oracle Database - Enterprise Edition - Version 12.2.0.1 and later
Information in this document applies to any platform.
SYMPTOMS
After upgrade to 12.2 database shows the below in alert log file.
2018-08-10T11:27:20.711173-04:00
KILL SESSION for sid=(291, 41855):
Reason = alter system kill session
Mode = KILL HARD SAFE -/-/-
Requestor = USER (orapid = 419, ospid = 6236, inst = 1)
Owner = N/A
Result = ORA-27
2018-08-10T11:28:23.410778-04:00
KILL SESSION for sid=(382, 30780):
Reason = profile limit idle_time
Mode = KILL SOFT -/-/-
Requestor = PMON (orapid = 2, ospid = 2961, inst = 1)
Owner = Process: USER (orapid = 164, ospid = 26147)
Result = ORA-0
CHANGES
Upgrade to 12.2
CAUSE
When sessions are killed manually or by PMON due to idle timeout will be dumped the information in alert log
These are informal messages in alert log related to the sessions.
SOLUTION
We can safely ignore these messages . Please find the below test case
SQL> conn / as sysdba
Connected.
SQL> alter system kill session '45,48410';
alter system kill session '45,48410'
*
ERROR at line 1:
ORA-00030: User session ID does not exist.
SQL> select
sys_context('USERENV','SID')
from dual; 2 3
SYS_CONTEXT('USERENV','SID')
--------------------------------------------------------------------------------
45
SQL> alter system kill session '45,58610';
alter system kill session '45,58610'
*
ERROR at line 1:
ORA-00027: cannot kill current session
2018-08-13T13:50:06.971193+00:00
KILL SESSION for sid=(45, 48410):
Reason = alter system kill session
Mode = KILL SOFT -/-/-
Requestor = USER (orapid = 24, ospid = 18655, inst = 1)
Owner = N/A
Result = ORA-30
2018-08-13T13:51:47.858998+00:00
KILL SESSION for sid=(45, 58610):
Reason = alter system kill session
Mode = KILL SOFT -/-/-
Requestor = USER (orapid = 24, ospid = 18655, inst = 1)
Owner = N/A
Result = ORA-27
There are 2 kinds of information being dumped to the alert log .
1) These messages are appearing in 12.2 version instead of the messages in "Immediate Kill Session#: 291, Serial#: 41855" .
2018-08-10T11:27:20.711173-04:00
KILL SESSION for sid=(291, 41855):
Reason = alter system kill session
Mode = KILL HARD SAFE -/-/-
Requestor = USER (orapid = 419, ospid = 6236, inst = 1)
Owner = N/A
Result = ORA-27
2018-08-10T11:28:23.410778-04:00
2) These are Idle sessions are being soft killed by PMON due to the profile IDLE_TIME has been reached .
KILL SESSION for sid=(382, 30780):
Reason = profile limit idle_time
Mode = KILL SOFT -/-/-
Requestor = PMON (orapid = 2, ospid = 2961, inst = 1)
Owner = Process: USER (orapid = 164, ospid = 26147)
Result = ORA-0
Overall these messages are information messages .
##########sample 2
Oracle Processes terminated with message "Process termination requested for pid xxxx [source = unknown] " in alert log (Doc ID 2808503.1) To BottomTo Bottom
Modified: Sep 21, 2021 Type: PROBLEM
Language:
English
Rate this document Email link to this document Open document in new window Printable Page
In this Document
Symptoms
Changes
Cause
Solution
APPLIES TO:
Oracle Database - Standard Edition - Version 12.2.0.1 and later
Oracle Database - Enterprise Edition - Version 12.2.0.1 and later
Information in this document applies to any platform.
SYMPTOMS
An oracle process (foreground or background) terminated suddenly, with following message in the alert log:
Process termination requested for pid xxxx [source = unknown], [info = nnnn...] [request issued by pid: 1, uid: 0]
CHANGES
CAUSE
The message "Process termination requested for pid ..." indicates that this process has received SIGTERM signal and is going to exit.
Generally, the cause of this message is because the database server or the clusterware decided to terminate the process, in which case the message will show "source = rdbms" or "source = clusterware".
When the message shows "source = unknown" it indicates that the signal is from an unexpected external source, for example, "kill" command from the shell or a monitoring tool which may throw SIGTERM signal to oracle processes.
SOLUTION
If database processes are being killed with messages like the above in the alert log, it is being killed by external command or tools.
##########DG 搭建
https://blog.csdn.net/shiyu1157758655/article/details/55253132
DG 环境搭建
1.设置归档模式
DG环境的搭建必须要把数据库启动到归档模式，并且为了避免开发人员使用nologging语句，我们还要把数据库设置为force logging。
查看数据库是否运行在归档模式：
#su - oracle
$sqlplus / as sysdba
SQL>archive log list;
如图所示，数据库运行在非归档模式，下面我们开始操作，把数据库修改为归档模式：首先关闭数据库
SQL>shutdown immediate;
启动数据库到mount状态下
SQL>startup mount;
SQL>select open_mode from v$database;
（查询结果必须是MOUNTED哦，如果输出的是其它方式，证明操作有误，请重新关闭数据库进行操作）
把数据库修改为归档模式并打开数据库：
SQL>alter database archivelog;
SQL>alter database open;
SQL>archive log list;
图中可以看到我们数据库已经运行在归档模式了，其中Archive destination就是归档日志存放的路径，稍后我们会修改下存放路径。
数据库打开后，我们需要把数据库设为force logging：
SQL>alter database force logging;
SQL> select name,log_mode,force_logging from v$database;
2.添加standby 日志
standby logfile的数量和大小均要与redo logfile相同
查询主库当前redo logfile的数量
SQL> select thread#,group#,members,bytes/1024/1024 from v$log;
从图中可以看到我们主库有三组大小为50M的redo logfile，故我们也需要创建同样数量和大小的standby logfile：
SQL>alter database add standby logfile group 11('/data/oradata/ocrl/redo/redo11_stb01.log') size 50M;
SQL>alter database add standby logfile group 12('/data/oradata/ocrl/redo/redo12_stb01.log') size 50M;
SQL>alter database add standby logfile group 13 ('/data/oradata/ocrl/redo/redo13_stb01.log')size 50M;
SQL>select group#,thread#,sequence#,archived,status from v$standby_log;
3.设置数据库口令文件的使用模式
执行以下命令查看remote_login_passwordfile的值是否EXCLUSIVE
SQL>show parameter remote_login_passwordfile
如果不是，执行以下命令进行设置，并且重启数据库，使其生效：
SQL>alter system set remote_login_passwordfile=EXCLUSIVE scope=spfile;
SQL>shutdown immediate;
SQL>startup;
4.参数设置
DG的搭建需要修改许多数据库的参数，并且部分参数主备库之间有点区别，这需要各位在配置过程细心一点。
a)主库参数设置
SQL>show parameter db_unique_name
SQL>alter system set log_archive_config='dg_config=(ocrl,ocrls)' scope=spfile;
其中dg_config填写的是主备库的db_unique_name。
设置归档日志的存放位置：
SQL>alter system set log_archive_dest_1='LOCATION=/data/oradata/ocrl/archivelogvalid_for=(all_logfiles,all_roles) db_unique_name=ocrl' scope=spfile;
SQL> alter system set log_archive_dest_2='SERVICE=ocrls ASYNCVALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ocrls' scope=spfile;
注：第一个ocrls是tnsname.ora的连接名，第二个ocrls是DB_UNIQUE_NAME
启用设置的日志路径：
SQL>alter system set log_archive_dest_state_1=enable scope=spfile;
SQL>alter system set log_archive_dest_state_2=enable scope=spfile;
设置归档日志进程的最大数量（视实际情况调整）：
SQL>alter system set log_archive_max_processes=30 scope=both;
设置standby库从哪个数据库获取归档日志（只对standby库有效，在主库上设置是为了在故障切换后，主库可以成为备库使用）：
SQL>alter system set fal_server=ocrlsscope=both;
设置文件管理模式，此项设置为自动，不然在主库创建数据文件后，备库不会自动创建：
SQL>alter system set standby_file_management=auto scope=spfile;
启用OMF功能：
SQL> alter system set db_create_file_dest='/data/oradata/ocrl/datafile' scope=spfile;
如果主备库文件的存放路径不同，还需要设置以下两个参数（需要重启数据库生效）：
SQL> alter system set db_file_name_convert='/data/oradata/ocrls/datafile','/data/oradata/ocrl/datafile','/data/oradata/ocrls/tempfile','/data/oradata/ocrl/tempfile' scope=spfile;
SQL> alter system set log_file_name_convert='/data/oradata/ocrls/redo','/data/oradata/ocrl/redo' scope=spfile;
这步路径的先后顺序在主备库上的设置是不一样的，大家要注意！
b)备库参数设置
完成了以上步骤后，通过以下命令生成一个pfile文件给备库使用：
SQL>create pfile from spfile;
打开生成的文件,修改部分参数，具体如下：
*.audit_file_dest='/u01/app/oracle/admin/ocrls/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.control_files='/data/oradata/ocrls/control/control01.ctl','/data/oradata/ocrls/control/control02.ctl'#Restore Controlfile
*.db_block_size=8192
*.db_create_file_dest='/data/oradata/ocrls/datafile'
*.db_domain=''
*.db_file_name_convert='/data/oradata/ocrl/datafile','/data/oradata/ocrls/datafile','/data/oradata/ocrl/tempfile','/data/oradata/ocrls/tempfile'
*.db_name='ocrl'//（这个保持跟主库一样，不能修改）
*.db_unique_name='ocrls' //（设置备库的名字）
*. fal_server=ocrl
*.db_recovery_file_dest_size=10737418240
*.db_recovery_file_dest='/data/oradata/ocrls/flashback'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP)(SERVICE=ocrlsXDB)'
*.log_archive_config='dg_config=(ocrl,ocrls)'
*.log_archive_dest_1='LOCATION=/data/oradata/ocrls/archivelog valid_for=(all_logfiles,all_roles) db_unique_name=ocrls'
*.log_archive_dest_2='SERVICE=ocrl ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ocrl'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=30
*.log_file_name_convert='/data/oradata/ocrl/redo','/data/oradata/ocrls/redo'
*.memory_target=718m
*.open_cursors=300
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'
（配置参数的时候要注意，有些地方跟主库的不一样哦）
c)密码文件配置
密码文件是创建DG不可缺少的一部分，主库的密码文件一般在$ORACLE_HOME/dbs，命名格式是：orapw+db_unique_name
上图是主库的密码文件，如果不存在此文件，我们可以通过以下命令生成一个：
#su - oracle
$cd $ORACLE_HOME/dbs
$orapwdfile=orapwocrl password=oracle
我们将密码文件和刚才修改好的pfile一起拷贝到备库的$ORACLE_HOME/dbs目录下，并重命名密码文件的名字：
主库上copy到备库的方法
备库上修改密码文件名和参数文件
5.listener.ora与tnsnames.ora配置
这两个文件均在$ORACLE_HOME/network/admin目录下，如果没有，可以自行创建一下
a)备库配置
listener.ora内容如下：
LISTENER=
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =192.168.180.44)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY =EXTPROC1521))
)
)
SID_LIST_LISTENER=
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ocrls)
(ORACLE_HOME =/u01/app/oracle/product/12.1.0/db_1)
(SID_NAME = ocrls)
)
)
tnsname.ora内容如下：
ocrls =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL= TCP)(HOST = 192.168.180.44)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME =ocrls)
)
)
重启一下监听：
$lsnrctl stop
$lsnrctl start
b)主库配置
listener.ora内容如下：
LISTENER=
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =192.168.180.44)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY =EXTPROC1521))
)
)
SID_LIST_LISTENER=
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ocrls)
(ORACLE_HOME =/u01/app/oracle/product/12.1.0/db_1)
(SID_NAME = ocrls)
)
)
tnsname.ora内容如下：
ocrl =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL= TCP)(HOST = 192.168.180.43)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME =ocrl)
)
)
ocrls =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL= TCP)(HOST = 192.168.180.44)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME =ocrls)
)
)
执行以下命令重启监听，使配置生效：
$lsnrctl stop
$lsnrctl start
做完以上配置后，在主备库上执行以下命令，确保两个主机之间网络相通：
$tnsping ocrl
$tnsping ocrls
主库上执行：
备库上执行
参数和网络配置好后，我们需要为备库dump文件创建相应的目录（对照主库$ORACLE_BASE/admin）：
ocrls:/home/oracle@standby>mkdir -p $ORACLE_BASE/admin/ocrls/adump
ocrls:/home/oracle@standby>mkdir -p $ORACLE_BASE/admin/ocrls/dpdump
为数据库文件创建目录（就是之前db_file_name_convert和log_file_name_convert的目录）
ocrls:/data/oradata/ocrls@standby>mkdir -p/data/oradata/ocrls/redo/
ocrls:/data/oradata/ocrls@standby>mkdir -p/data/oradata/ocrls/datafile/
ocrls:/data/oradata/ocrls@standby>mkdir -p /data/oradata/ocrls/control/
7.RMAN复制创建standby库准备工作都完成了，那我们可以开始standby库的创建了。
注：以下操作在备库完成
a)文件复制先，我们使用之前修改的pfile把备库启动到nomount状态，生成spfile：
$echo $ORACLE_SID （确认SID是否我们设置的）
SQL> startup nomount pfile='/u01/app/oracle/product/12.1.0/db_1/dbs/initocrls.ora'
SQL> create spfile from pfile;
SQL>shutdown immediate;
SQL>exit;
从spfile启动
复制数据文件，在备库上操作
ocrls:/home/oracle@standby>rman target sys/oracle@ocrl auxiliary sys/oracle@ocrls
确认我们已经连接上主库和备库后，执行以下命令：
RMAN> duplicate target database for standby from active database nofilenamecheck;
命令执行完后，可以看到主库在开始复制文件到备库中
耐心等待任务的完成，如果中间有错误导致异常退出，需要根据错误信息进行分析。
以下表示执行成功：
复制完成后，打开数据库开启实时同步：
SQL> alter data
SQL> alter database recover managed standby database using current logfile
disconnect from session;
查看数据库状态
登陆到主库
$sqlplus / as sysdba
SQL>select database_rolefrom v$database;
登录到备库：
$sqlplus / as sysdba
SQL>select database_rolefrom v$database;
检查归档日志是否能正常传输（日志的序号必须是一样的）：
主库
SQL> selectSEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG;
备库
SQL> selectSEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG;
主库
SQL>alter system switch logfile;
SQL>select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG;
备库
SQL> select max(sequence#)from v$archived_log;
这样，我们的DG已经配置成功了！
