ORACLE 11gR2 Dataguard DGMGRL
|
110619 |
1.0 |
|
|
|
|
|
|
|
|
|
1.
DGMGRL
Data Guard 를 관리하기 위한 CLI (command line interface) 이다.
2.
Pre-requisitions for Configuring Data Guard
DGMGRL 의 Configuration 에 사용되는 User 는 반드시 sysdba 권한을 가지고 있어야 한다. 그 이유는 DGMGRL 에서 수행되는 명령중에는 DB Restart 가 필요한 Operation 도 있기 때문이다.
또 Guard 를 구성하고 있는 모든 데이터베이스는 spflie 을 사용해야 한다.
3.
Type of Commands of DGMGRL
l 여기서 모든 명령어를 소개하진 않았다. 기본적인 테스트에 필요한
파라미터만 소개하겠다.
A.
(add |
disable | remove | show) database
데이터베이스에 대한 셋팅이다.
B.
connect
DGMGRL 을 Data Guard 구성 상 어느 데이터베이스에 접속할지 기술하고 수행한다.
C.
(create
| disable | enable | remove | show) configuration
Data Guard Configuration 을 수정한다. Create Configuration 은 최초
수행되며 추후 Standby Database 를 추가할 때는 add
database 를 사용한다.
D.
edit (configuration
| database | instance)
보통 Database 의
Parameter 를 수정할 때 사용한다.
E.
shutdown
/ startup
가드를 구성하고 있는 Database 에 대해 shutdown / startup 을 수행한다. 이는 connect 에 기술한 사용자가 sysdba 를 가지고 있는 (있어야만 하는) 유저이기 때문에 가능하다.
F.
(start |
stop) observer
Observer 의 시작/정지 명령을 내린다.
G.
switchover
/ failover
Switchover / Failover 를 수행한다.
H.
EXIT
DGMGRL 을 종료한다.
4. PRACTICE (Test Environment)
-
DGMGRL 셋팅을 제외하고 가드 구성은 완료되어 있다.
-
테스트 장비에는 세개의 데이터베이스가
구성되어 있다.
-
DB Name 은 세 개 공통적으로 orcl 이다.
-
DB
Unique Name 는 각기 orcl,
stby, stby2 를 사용한다.
-
Primay
Database 는 orcl 이고 Standby Database 로 stby, stby2 를 가진다.
-
Standby
Database 는 모두 Physical
Standby Database 이다.
-
세 개의 데이터베이스 모두 spfile 을 사용한다.
-
세 개의 데이터베이스 모두 dg_broker_start 가 false 상태이다.
5.
Scenario (Outline)
A.
Configuration
생성
B.
Standby
Database 추가
C.
Configuration
의 Enable |Disable | Remove
| Show
D.
Protection
Mode 의 변경
E.
Switchover
F.
Failover
G.
Reinstating
a Faild Primary Database
H.
Snapshot
Standby
I.
Monitoring
Dataguard configuration
6.
Scenario (Outline)
l Scenario 을 진행하기에 앞서 각 데이터베이스의 system 에
sysdba 권한을 할당했다.
A.
Configuration
생성
|
orcl@/home/oracle>dgmgrl DGMGRL for Linux:
Version 11.2.0.1.0 - 64bit Production Copyright (c)
2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL,
type "help" for information. DGMGRL> connect
system/oracle@orcl Connected. DGMGRL> create
configuration 'guard_DG' as > primary
database is 'orcl' > connect
identifier is 'orcl'; Error: ORA-16525: the Data Guard broker is not yet
available ORA-06512: at
"SYS.DBMS_DRS", line 157 ORA-06512: at line
1 |
DGMGRL 구성에
앞서 DG Broker 를 Start 해야 한다.
orcl 에 dg_broker_start 를 true 로 수정하였다.
|
DGMGRL> create
configuration 'guard_DG' as > primary
database is 'orcl' > connect
identifier is 'orcl'; Configuration
"guard_DG" created with primary database "orcl" |
구성을 완료한 후 정보를 확인해 보았다.
|
DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxPerformance Databases: orcl - Primary database Fast-Start
Failover: DISABLED Configuration
Status: DISABLED |
Configuration 이름을 확인했을 때 대/소문자 구분을 함을 알 수 있다.
Protection mode 는 MaxPerformance (기본) 으로 지정되어 있으며
데이터베이스 구성으로는 현재 Primary Database Role 을
가진 orcl 하나뿐이다.
Fast-Start Failover 는 현재 구성되어 있지 않으며 Configuration 은 disabled 상태이다.
B.
Standby
Database 추가
n 아래의 예제는 ‘A’ 에서 사용했던 커넥션, tnsnames orcl 의 system 연결을 그대로 사용한다.
|
DGMGRL> add
database 'stby' as > connect
identifier is 'stby'; Database
"stby" added DGMGRL> add
database 'stby2' as > connect
identifier is stby2; Database
"stby2" added DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxPerformance Databases: orcl
- Primary database stby
- Physical standby database stby2 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: DISABLED |
standby database stby, stby2 를 추가한 결과이다.
C.
Configuration
의 Enable |Disable | Remove
| Show
show configuration 은
위에서 이미 보였기에 생략하겠다.
아래의 예제는 configuration 의 enable, show 예제이다.
|
DGMGRL> enable
configuration; Enabled. DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxPerformance Databases: orcl
- Primary database stby
- Physical standby database Error: ORA-16525: the Data Guard broker
is not yet available stby2 - Physical standby database Error: ORA-16525: the Data Guard broker
is not yet available Fast-Start
Failover: DISABLED Configuration
Status: ERROR |
앞서 진행했을
때 Primary 에 대해서는 dg_broker_start 를 true 로 수정했으나 stby, stby2 는 false 상태이다.
stby, stby2 의 dg_broker_start parameter 를 수정하여 다시한번
configuration 을 확인해 보았다.
|
DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxPerformance Databases: orcl
- Primary database stby
- Physical standby database Error: ORA-16532: Data Guard broker
configuration does not exist stby2 - Physical standby database Error: ORA-16525: the Data Guard broker
is not yet available Fast-Start
Failover: DISABLED Configuration
Status: ERROR DGMGRL> disable
configuration; Disabled. DGMGRL> enable
configuration; Enabled. DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxPerformance Databases: orcl
- Primary database stby
- Physical standby database stby2 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
위 내용을
보면 알 수 있겠지만 dg_broker_start 를 true 로
변경했다고 disable configuration 상태의 내용이 바로 변경되진 않는다. 다시 enable 한 후
configuration 을 조회해야 변경된 내용을 확인할 수 있다.
참고로 Listener 의 host 정보에
IP 정보를 사용하면 enable configuration 과정에 에러가 발생한다.
/*+ listener 의 host 정보에 alias 를 넣은 것과 IP 정보를 넣은 것의 차이… */
아래의 예제는 configuration 의 remove 예제이다.
|
DGMGRL> remove
configuration; Removed configuration DGMGRL> show
configuration; ORA-16532: Data
Guard broker configuration does not exist Configuration details cannot
be determined by DGMGRL |
remove 를 수행하면 configuration 정보가 모두 삭제된다. 이는 다시 복구할
수 없기에 주의해서 사용해야 한다.
D.
Protection
Mode 의 변경
아래의 예시는 Protection Mode 를 Maximum Performance 에서 Maximum Availability 로 변경한 예제이다.
|
DGMGRL> EDIT
CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Error: ORA-16627: operation disallowed since
no standby databases would remain to support protection mode Failed. DGMGRL> show
database verbose 'stby'; Database - stby Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds Apply Lag: 29 minutes 1 second Real Time Query: ON Instance(s): stby Properties: DGConnectIdentifier = 'stby' 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 = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '4' LogArchiveMinSucceedDest = '1' DbFileNameConvert =
'/u01/app/oracle/oradata/orcl, /u01/app/oracle/oradata/stby' LogFileNameConvert =
'/u01/app/oracle/oradata/orcl, /u01/app/oracle/oradata/stby' FastStartFailoverTarget = '' StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'oracle64.test.com' SidName = 'stby' StaticConnectIdentifier =
'(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oracle64.test.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=stby_DGMGRL.test.com)(INSTANCE_NAME=stby)(SERVER=DEDICATED)))' StandbyArchiveLocation =
'/u01/app/oracle/oradata/stby/arc' AlternateLocation = '' LogArchiveTrace = '0' LogArchiveFormat = '%t_%s_%r.dbf' TopWaitEvents = '(monitor)' Database Status: SUCCESS |
위에서 Protection Mode 를 변경할 때 에러가 난 이유는 Maximum
Availability 를 사용하기 위해서는 최소한 하나이상의 Standby database 에
대해 log_archive_dest_n 이 sync 로 설정되어
있어야 하기 때문이다.
이의 확인은 show database verbose ‘db_unique_name’ 명령을 사용해 조회했다.
결과중에 LogXptMode 가 있는데 이에 대한 Value 가 Async 이다.
Standby Database 는 stby , stby2 둘다 Async 모드를 사용하고 있다.
|
DGMGRL> EDIT
DATABASE 'stby' SET PROPERTY LOGXPTMODE='SYNC'; Property
"logxptmode" updated DGMGRL> EDIT
CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded. DGMGRL> show
configuration; Configuration -
guard_DG Protection Mode: MaxAvailability Databases: orcl
- Primary database stby
- Physical standby database stby2 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
Maximum Availability Protection Mode 를 사용하기 위해 edit database 명령을 사용했다. 이를 통해 LogXptMode 의
Value 를 Async 에서 Sync 로 변경하였고, Protection Mode 변경이 정상적으로 수행됨을 볼 수 있다.
참고로 Maximum Availability 상태에서 Sync 로 동작중인 Standby Database 를 Data Guard 구성에서 제외하려고
시도하면 에러가 발생한다.
|
DGMGRL> remove
database 'stby'; Error: ORA-16627:
operation disallowed since no standby databases would remain to support
protection mode Failed. |
stby 구성을 제외하기 위해서는 stby2 를 sync 모드로 변경 후 재시도하거나 Protection Mode 를 Maximum Performance 로
다운시킨 후 변경하는 방법이 있다.
아래의 예시는 Protection Mode 를 Maximum Availability 에서 Maximum Protection 으로
변경한 예제이다.
|
DGMGRL> EDIT
CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Succeeded. |
아래의 예시는 Protection Mode 를 Maximum Performance 에서 Maximum Protection 로
변경한 예제이다.
|
DGMGRL> EDIT
CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Operation requires
shutdown of instance "orcl" on database "orcl" Shutting down
instance "orcl"... Database closed. Database
dismounted. ORACLE instance
shut down. Operation requires
startup of instance "orcl" on database "orcl" Starting instance
"orcl"... Unable to connect
to database ORA-12514:
TNS:listener does not currently know of service requested in connect
descriptor Failed. Warning: You are
no longer connected to ORACLE. Please complete
the following steps to finish the operation: start up instance "orcl" of
database "orcl" DGMGRL> show
configuration; Error: ORA-03114: not
connected to ORACLE Configuration
details cannot be determined by DGMGRL DGMGRL> connect
system/oracle@orcl Connected. DGMGRL> show
configuration; Error: ORA-01034: ORACLE
not available Process ID: 0 Session ID: 41
Serial number: 40 Configuration
details cannot be determined by DGMGRL |
Protection Mode 를 Maximum Performance 에서 Maximum Protection 으로
변경하면 Primay Database 가 Shutdown 된다.
다시 Startup 하여 Guard 구성을 체크하였다.
|
DGMGRL> startup ORACLE instance
started. Database mounted. Database opened. DGMGRL> show
configuration Configuration -
guard_DG Protection Mode: MaxProtection Databases: orcl
- Primary database stby
- Physical standby database stby2 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: |
마지막으로 MaxProtection 에서 MaxPerformance 로 수정해보겠다.
|
DGMGRL> EDIT
CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded. |
E.
Switchover
l Switchover 는 Primary / Standby Database 간에
Role 을 변경하는 명령이다. Switchover 와
Failover 의 차이는 계획되었느냐 되지 않았느냐란 부분이 있으며 failover 의
경우 re-instate 작업이 필요하다.
*환경이 변화된 관계로 다시 부연설명을
하겠다.
*아래 테스트는 dg1(Primary), dg2(Standby) 로 진행했고 기본적인
DGMGRL Configuration 을 만든 상태이다.
*Database 이름은 DG1 이다.
*추가로 Protection Mode 는 셋팅하지 않았다.
|
DGMGRL> switch
over to dg2; Unrecognized
command "switch", try "help" DGMGRL>
switchover to dg2; Performing
switchover NOW, please wait... New primary database "dg2" is
opening... Operation requires shutdown of instance
"DG1" on database "dg1" Shutting down
instance "DG1"... ORA-01109:
database not open Database
dismounted. ORACLE instance
shut down. Operation requires
startup of instance "DG1" on database "dg1" Starting instance
"DG1"... Unable to connect
to database ORA-12514:
TNS:listener does not currently know of service requested in connect
descriptor Failed. Warning: You are
no longer connected to ORACLE. Please complete
the following steps to finish switchover: start up instance "DG1" of
database "dg1" |
<dg1 의 alert log>
|
Switchover: Primary controlfile converted to
standby controlfile succesfully. Fri Jul 08
10:59:14 2011 MRP0 started with
pid=19, OS id=8691 MRP0: Background
Managed Standby Recovery process started (DG1) 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/oracle/oradata/DG1/arc/1_112_753475573.dbf Identified
End-Of-Redo for thread 1 sequence 112 Resetting standby
activation ID 0 (0x0) Media Recovery
End-Of-Redo indicator encountered Media Recovery
Applied until change 1805972 MRP0: Media
Recovery Complete: End-Of-REDO (DG1) MRP0: Background
Media Recovery process shutdown (DG1) Fri Jul 08
10:59:20 2011 Switchover: Complete - Database shutdown
required (DG1) Completed: ALTER DATABASE COMMIT TO
SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN Using STANDBY_ARCHIVE_DEST
parameter default value as /u01/app/oracle/oradata/DG1/arc ALTER SYSTEM SET
log_archive_dest_2='' SCOPE=BOTH; Using
STANDBY_ARCHIVE_DEST parameter default value as
/u01/app/oracle/oradata/DG1/arc ALTER SYSTEM SET
log_archive_dest_state_2='ENABLE' SCOPE=BOTH; Fri Jul 08
10:59:25 2011 RFS[1]: Assigned
to RFS process 8697 RFS[1]: Identified
database type as 'physical standby': Client is ARCH pid 6231 Fri Jul 08
10:59:25 2011 Shutting down
instance (immediate) Shutting down
instance: further logons disabled Stopping
background process MMNL Stopping
background process MMON License high water
mark = 7 All dispatchers
and shared servers shutdown alter database
CLOSE NORMAL ORA-1109 signalled
during: alter database CLOSE NORMAL... alter database DISMOUNT Completed: alter
database DISMOUNT ARCH: Archival
disabled due to shutdown: 1089 Shutting down
archive processes Archiving is
disabled Archive process
shutdown avoided: 0 active Shutting down Data
Guard Broker processes Fri Jul 08
10:59:32 2011 Completed: Data
Guard Broker shutdown ARCH: Archival
disabled due to shutdown: 1089 Shutting down
archive processes Archiving is
disabled Archive process
shutdown avoided: 0 active Fri Jul 08
10:59:33 2011 Stopping
background process VKTM: Fri Jul 08 10:59:36
2011 Instance shutdown
complete |
위 Alertlog 에서 얻어진 흐름을 단순히 열거하자면 Controlfile 을 Standby 용으로 Convert 한 후 Media Recovery 작업을 거치고 Shutdown 을 한다.
<dg2 의 alert log>
놀랍게도 Switchover 가 진행된 시간에 대해 아무런
정보가 없다. (글자 하나 없다.)
|
SQL> select
name, database_role, open_mode from v$database; NAME DATABASE_ROLE OPEN_MODE ---------
---------------- -------------------- DG1 PRIMARY READ WRITE SQL> select
instance_name from v$instance; INSTANCE_NAME ---------------- DG2 |
정보를 조회한 결과 dg2 가 정상적으로 switchover 되었음을 알 수 있다. (Primary Database,
Read Write 로 변경되었음을 알 수 있다.)
이 상황에서 앞서 dg1 에서 switchover 의 결과에 대해 수행해 보겠다.
|
Please complete
the following steps to finish switchover: start up instance "DG1" of
database "dg1" |
dg1 은 현재 shutdown 중인 관계로 startup 후 확인하겠다.
/*+ dgmgrl 에서 DB 를 Startup 하는 방법이 있나? */
|
SQL> startup ORACLE instance
started. Total System
Global Area 1653518336 bytes Fixed Size 2213896 bytes Variable
Size 1124075512 bytes Database
Buffers 520093696 bytes Redo Buffers 7135232 bytes Database mounted. Database opened. SQL> select
instance_name from v$instance; INSTANCE_NAME ---------------- DG1 SQL> select
name, database_role, open_mode from v$database; NAME DATABASE_ROLE OPEN_MODE ---------
---------------- -------------------- DG1 PHYSICAL STANDBY READ ONLY WITH APPLY SQL> select
process,status from v$managed_standby; PROCESS STATUS ---------
------------ ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED ARCH CLOSING MRP0 APPLYING_LOG RFS IDLE RFS IDLE RFS IDLE RFS IDLE 9 rows selected. SQL> !ps -ef |
grep mrp oracle 13772
1 14 13:29 ? 00:00:05
ora_mrp0_DG1 oracle 13799 13625 0 13:30 pts/0 00:00:00 /bin/bash -c ps -ef | grep mrp |
DB 를 Startup 하니 Read Only 로 Open 되었고 MRP Process 도 자동으로 기동되었다.
Configuration 을 조회했을 때도 별다른 에러가 없었다.
|
DGMGRL>
connect system/oracle Connected. DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
F.
Failover
Dataguard 의 Failover 시에는 그에 따른 reinstate 작업이 뒤따른다. 이는 새롭게 Primary 가 된
Standby Database 와 데이터가 동기화 되어야 하기 때문이다.
이는 Flashback 사용 여부에 따라 작업량이 매우 달라진다. Flashback
을 사용하는 경우엔 Flashback database 를 사용한 것과 동일하다. 하지만 사용하지 않는 경우에는 Standby Database 를
말그대로 재구성 해야 한다.
현재 사용한 dg1, dg2 는 Flashback Setting 이 되어 있지
않은 관계로 이를 먼저 설정하도록 하겠다.
<dg2 : Primary database>
|
SQL> shutdown
immediate; Database closed. Database
dismounted. ORACLE instance
shut down. SQL> startup
mount; ORACLE instance
started. Total System
Global Area 1653518336 bytes Fixed Size 2213896 bytes Variable
Size 956303352 bytes Database
Buffers 687865856 bytes Redo Buffers 7135232 bytes Database mounted. SQL> show
parameter recovery NAME TYPE VALUE ------------------------------------
----------- ------------------------------ db_recovery_file_dest string /u01/app/oracle/flash_recovery
_area db_recovery_file_dest_size big integer 4977M recovery_parallelism integer 0 SQL> alter
database flashback on; Database altered. SQL> alter
database open; Database altered. SQL> select
flashback_on from v$database; FLASHBACK_ON ------------------ YES |
<dg1 : Primary database>
|
SQL> recover
managed standby database cancel; Media recovery
complete. SQL> shutdown
immediate; Database closed. Database
dismounted. ORACLE instance
shut down. SQL> startup
mount; ORACLE instance
started. Total System
Global Area 1653518336 bytes Fixed Size 2213896 bytes Variable Size 1124075512 bytes Database Buffers 520093696 bytes Redo Buffers 7135232 bytes Database mounted. SQL> select
flashback_on from v$database; FLASHBACK_ON ------------------ NO SQL> alter
database flashback on; alter database
flashback on * ERROR at line 1: ORA-01153: an
incompatible media recovery is active SQL> select
flashback_on from v$database; FLASHBACK_ON ------------------ NO SQL> alter
database flashback on; alter database
flashback on * ERROR at line 1: ORA-01153: an
incompatible media recovery is active SQL> startup ORA-01081: cannot
start already-running ORACLE - shut it down first SQL> alter
database open; Database altered. SQL> recover
managed standby database using current logfile disconnect from session; Media recovery
complete. |
Primary Database 는 이상없이 Flashback 활성화가 되나 Standby Database 는
그렇지 않다. 양측 다 변경 후 진행하고자 Switchover 를
다시 실시한 후 Flashback 을 적용했다.
위 작업을
완료한 후 failover 을 실행하였다.
|
DGMGRL> connect
system/oracle@dg1 Connected. DGMGRL>
failover to dg2; Performing
failover NOW, please wait... Error: ORA-16600: not connected to target
standby database for failover Failed. Unable to failover DGMGRL> connect
system/oracle@dg2 Connected. DGMGRL>
failover to dg2; Performing
failover NOW, please wait... Failover
succeeded, new primary is "dg2" DGMGRL> show
configuration; Configuration - dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database
(disabled)
ORA-16661: the standby database needs to be reinstated Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
failover 명령을 실시하기 전에
주의할 점은 새롭게 Primary Database 가 될
Standby Database 에 Connect 해 실행해야 한다는 것이다.
<dg1 : Old Primary Database>
별다른 로그가
남아있지 않았다.
|
SQL> select
name, open_mode, database_role from v$database; NAME OPEN_MODE DATABASE_ROLE ---------
-------------------- ---------------- DG1 READ WRITE PRIMARY SQL> select
instance_name from v$instance; INSTANCE_NAME ---------------- DG1 |
기존의 Primary Database 상태 그대로 임을 알 수 있다.
<dg2 : Primary Database ?>
|
Standby became primary SCN: 1827392 Fri Jul 08
15:14:37 2011 Setting recovery
target incarnation to 2 Switchover:
Complete - Database mounted as primary Completed: ALTER
DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN Fri Jul 08
15:14:37 2011 ARC1: Becoming the
'no SRL' ARCH ALTER DATABASE
OPEN Data Guard Broker
initializing... Fri Jul 08
15:14:37 2011 Assigning
activation ID 1737338232 (0x678dad78) Thread 1 opened at
log sequence 1 Current log# 1 seq# 1 mem# 0: /u01/app/oracle/oradata/DG2/redo01.log Successful open of
redo thread 1 MTTR advisory is
disabled because FAST_START_MTTR_TARGET is not set Archiver process
freed from errors. No longer stopped SMON: enabling
cache recovery Successfully
onlined Undo Tablespace 2. Dictionary check
beginning Dictionary check
complete Verifying file
header compatibility for 11g tablespace encryption.. Verifying 11g file
header compatibility for tablespace encryption completed SMON: enabling tx
recovery Starting
background process SMCO Fri Jul 08
15:14:37 2011 SMCO started with
pid=18, OS id=16307 Database
Characterset is WE8MSWIN1252 Fri Jul 08
15:14:38 2011 idle dispatcher
'D000' terminated, pid = (17, 1) No Resource
Manager plan active Starting
background process QMNC LOGSTDBY: Validating
controlfile with logical metadata Fri Jul 08
15:14:38 2011 QMNC started with
pid=29, OS id=16311 LOGSTDBY:
Validation complete Completed: ALTER
DATABASE OPEN ALTER SYSTEM SET
log_archive_trace=0 SCOPE=BOTH SID='DG2'; ALTER SYSTEM SET
log_archive_format='%t_%s_%r.dbf' SCOPE=SPFILE SID='DG2'; ALTER SYSTEM SET
standby_file_management='AUTO' SCOPE=BOTH SID='*'; ALTER SYSTEM SET
archive_lag_target=0 SCOPE=BOTH SID='*'; ALTER SYSTEM SET
log_archive_max_processes=4 SCOPE=BOTH SID='*'; ALTER SYSTEM SET
log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*'; ALTER SYSTEM SET
db_file_name_convert='/u01/app/oracle/oradata/DG1','/u01/app/oracle/oradata/DG2'
SCOPE=SPFILE; ALTER SYSTEM SET
log_file_name_convert='/u01/app/oracle/oradata/DG1','/u01/app/oracle/oradata/DG2'
SCOPE=SPFILE; Failover
succeeded. Primary database is now dg2. Starting
background process CJQ0 Fri Jul 08
15:14:39 2011 CJQ0 started with
pid=30, OS id=16325 Fri Jul 08
15:14:41 2011 ARC2: STARTING
ARCH PROCESSES Fri Jul 08
15:14:41 2011 ARC4 started with
pid=33, OS id=16329 ARC4: Archival
started ARC2: STARTING
ARCH PROCESSES COMPLETE krsk_srl_archive_int:
Enabling archival of deferred physical standby SRLs Identified
End-Of-Redo for thread 1 sequence 143 Archived Log entry
80 added for thread 1 sequence 143 ID 0x678da61c dest 1: Fri Jul 08
15:15:42 2011 Shutting down
archive processes Fri Jul 08
15:15:42 2011 ARCH shutting down ARC4: Archival
stopped |
위 로그를
보면 Standby Database 가 Primary Database
가 된 시점 정보 (SCN) 를 찍은 이래 DB 가
내려가지 않고 그대로 Read Write 상태로 변경되었음을 알 수 있다.
|
SQL> select
name, open_mode, database_role 2
from v$database; NAME OPEN_MODE DATABASE_ROLE ---------
-------------------- ---------------- DG1 READ WRITE PRIMARY SQL> select
instance_name from v$instance; INSTANCE_NAME ---------------- DG2 |
신 Primary Database 를 확인한 결과 Read Write 에 Primary Database Role 을 가지고 있음을 알 수 있다.
Failover 의 결과로 Primary – Standby 관계에서 Primary / Primary 로
바뀌었고 Configuration 에는 Reinstating 이
필요한 것으로 보인다.
G.
Reinstating
a Faild Primary Database
|
DGMGRL> connect system/oracle@dg2 Connected. DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database
(disabled)
ORA-16661: the standby database needs to be reinstated Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS DGMGRL>
reinstate database dg1; Reinstating
database "dg1", please wait... Reinstatement of
database "dg1" succeeded DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
dg1 을 reinstate 하기 위해서는 dg2 (새로운 Primary Database) 에 접속해 진행한다. 이에 앞서 dg1 을 mount 상태로 만들어야 한다. 그 이유는 flashback database 를 db 의 어떤 open mode 에서 진행할 수 있는지 생각해 보면
명료하다.
reinstate 가 종료되면 show configuration 이나 show database 구문등을
사용해 구성정보에 에러가 없는지 확인해 본다.
H.
Snapshot
Standby
snapshot standby 는 말
그대로 데이터베이스의 특정 시각의 스냅샷을 보존하는 기능이다. 이 기능을 사용하면 적용한 시각부터 Archived Log 는 전송받지만 실제 Apply 는 하지 않는
상태가 된다. 이 상태는 Snapshot Standby
Database 가 Physical Standby Database 로 다시 convert 될 때까지 유지된다.
|
DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS DGMGRL>
convert database dg1 to snapshot standby; Converting
database "dg1" to a Snapshot Standby database, please wait... Database
"dg1" converted successfully DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Snapshot standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
dg1 을 snapshot database 로 변경하였다.
이 과정중에
발생한 alert log 는 다음과 같다.
|
Fri Jul 08
17:24:58 2011 ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL Fri Jul 08
17:24:58 2011 MRP0: Background
Media Recovery cancelled with status 16037 Errors in file
/u01/app/oracle/diag/rdbms/dg1/DG1/trace/DG1_mrp0_19578.trc: ORA-16037: user
requested cancel of managed recovery operation Managed Standby
Recovery not using Real Time Apply Recovery
interrupted! Recovered data
files to a consistent state at change 1836052 Errors in file
/u01/app/oracle/diag/rdbms/dg1/DG1/trace/DG1_mrp0_19578.trc: ORA-16037: user
requested cancel of managed recovery operation MRP0: Background Media Recovery process
shutdown (DG1) Managed Standby
Recovery Canceled (DG1) Completed: ALTER
DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL alter database
convert to snapshot standby Created guaranteed restore point
SNAPSHOT_STANDBY_REQUIRED_07/08/2011 17:24:58 krsv_proc_kill:
Killing 3 processes (all RFS) All dispatchers
and shared servers shutdown CLOSE: killing
server sessions. CLOSE: all
sessions shutdown successfully. Fri Jul 08
17:24:59 2011 SMON: disabling
cache recovery Begin: Standby
Redo Logfile archival End: Standby Redo
Logfile archival RESETLOGS after
complete recovery through change 1836052 Resetting
resetlogs activation ID 1737338232 (0x678dad78) Online log
/u01/app/oracle/oradata/DG1/redo01.log: Thread 1 Group 1 was previously
cleared Online log
/u01/app/oracle/oradata/DG1/redo02.log: Thread 1 Group 2 was previously
cleared Online log
/u01/app/oracle/oradata/DG1/redo03.log: Thread 1 Group 3 was previously
cleared Standby became primary SCN: 1836050 Fri Jul 08
17:24:59 2011 Setting recovery
target incarnation to 3 CONVERT TO SNAPSHOT STANDBY: Complete -
Database mounted as snapshot standby Completed: alter
database convert to snapshot standby Fri Jul 08
17:25:05 2011 idle dispatcher
'D000' terminated, pid = (17, 1) |
위에 표시한
내용을 가지고 이야기를 하면 다음과 같다.
I.
convert 명령을 실행
II.
cancel
recover
III.
shutdown
mrp process
IV.
create
restore point
V.
standby
became primary
위에 언급한 5번째 내용의 경우 switchover 에서도 관측되었던 부분이다. 저 구문이 의미하는 바가 switchover 때와 동일하다면 v$database 의 open_mode 는 Read Write 일 것이다.
|
SQL> select
name, open_mode, database_role 2
from v$database; NAME OPEN_MODE DATABASE_ROLE ---------
-------------------- ---------------- DG1 READ WRITE SNAPSHOT STANDBY |
Open Mode 가 Read Write 상태라는 것은 말 그대로 읽기/쓰기가 가능하다는
것이다. 그렇다면 추후 Convert 를 사용해 Physical Standby Database 로 돌아간다는 것은 무엇을 의미하는 것인가 생각해 볼 필요가 있다. Physical Standby Database 는 Block Level 로 Primary Database 와 동일한 복제본이다. 이를 생각해
보면 변경내역을 만들더라도 snapshot 을 만든 시점으로
rollback 될 것이다.
다음은 위
내용을 확인하기 위해 테스트용으로 테이블과 테이블 스페이스를 만든 내용이다.
|
SQL> create
table check_snapshot 2 as
select * from dba_objects; Table created. SQL> commit; Commit complete. SQL> select
count(*) from check_snapshot; COUNT(*) ---------- 72171 SQL> create
tablespace check_snapshot 2
datafile '/home/oracle/check_snapshot.dbf' size 10m; Tablespace
created. SQL> !ls
/home/oracle/check_snapshot.dbf /home/oracle/check_snapshot.dbf |
그럼 snapshot standby 를 Physical standby
database 로 원복시켜보겠다.
먼저 원복대상인 dg1 을 mount 상태로 변경한 상황에서 진행한다. (flashback database 를 생각하라)
|
DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Snapshot standby database Warning: ORA-16782: instance not open
for read and write access Fast-Start
Failover: DISABLED Configuration
Status: WARNING DGMGRL>
convert database dg1 to physical standby; Converting
database "dg1" to a Physical Standby database, please wait... Operation
requires shutdown of instance "DG1" on database "dg1" Shutting down
instance "DG1"... ORA-01109:
database not open Database
dismounted. ORACLE instance
shut down. Operation
requires startup of instance "DG1" on database "dg1" Starting instance
"DG1"... Unable to connect
to database ORA-12514:
TNS:listener does not currently know of service requested in connect
descriptor Failed. Warning: You are
no longer connected to ORACLE. Please complete
the following steps to finish the convert command: start up and mount instance
"DG1" of database "dg1" == dg1 을 mount 함...== Disconnected from
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the
Partitioning, OLAP, Data Mining and Real Application Testing options dg1@/u01/app/oracle/diag/rdbms/dg1/DG1/trace>dgmgrl DGMGRL for Linux:
Version 11.2.0.1.0 - 64bit Production Copyright (c)
2000, 2009, Oracle. All rights reserved. Welcome to
DGMGRL, type "help" for information. DGMGRL>
connect system/oracle@dg1 Connected. DGMGRL> show
configuration; Configuration -
dg Protection Mode: MaxPerformance Databases: dg2 - Primary database dg1 - Physical standby database Fast-Start
Failover: DISABLED Configuration
Status: SUCCESS |
Configuration 상에서 원복을
확인하였다. 이 상황에서 dg1 에 테스트용으로 만들었던
파일들이 어떻게 되었는지 확인해보겠다.
|
SQL> desc
check_snapshot; ERROR: ORA-04043: object
check_snapshot does not exist SQL> select
file_name from dba_data_files; FILE_NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/DG1/system01.dbf /u01/app/oracle/oradata/DG1/sysaux01.dbf /u01/app/oracle/oradata/DG1/undotbs01.dbf /u01/app/oracle/oradata/DG1/users01.dbf /u01/app/oracle/oradata/DG1/samp_tbs01.dbf SQL> !ls
/home/oracle/check_snapshot.dbf ls:
/home/oracle/check_snapshot.dbf: No such file or directory |
위 내용을
보면 snapshot 을 만든 이후에 발생한 모든 변경사항이 사라졌음을 알 수 있다. 그렇다면 alert log 에는 어떤 내용이 남아있는지 한번 볼
필요가 있다.
|
alter database convert to physical standby ALTER DATABASE
CONVERT TO PHYSICAL STANDBY (DG1) krsv_proc_kill:
Killing 2 processes (all RFS) Flashback Restore
Start Deleted file /home/oracle/check_snapshot.dbf
Flashback: deleted
datafile #6 in tablespace #6 from control file. Flashback: dropped
tablespace #6: 'CHECK_SNAPSHOT' from the control file. Flashback Restore
Complete Guaranteed restore point dropped Clearing standby
activation ID 1737386316 (0x678e694c) The primary
database controlfile was created using the 'MAXLOGFILES 16'
clause. There is space for
up to 13 standby redo logfiles Use the following SQL commands on the
standby database to create standby redo logfiles that match the primary
database: ALTER DATABASE ADD
STANDBY LOGFILE 'srl1.f' SIZE 52428800; ALTER DATABASE ADD
STANDBY LOGFILE 'srl2.f' SIZE 52428800; ALTER DATABASE ADD
STANDBY LOGFILE 'srl3.f' SIZE 52428800; ALTER DATABASE ADD
STANDBY LOGFILE 'srl4.f' SIZE 52428800; Completed: alter
database convert to physical standby |
먼저 명령을
수행한 기록이 남아있으며 테스트용으로 추가했던 테이블 스페이스가 drop 되었고 Flashback Restore 가 끝난 다음에는 restore point 를
삭제하였다.
특이사항으로 Stnadby Database 를 만들라는 구문이 있는데 정확한 이유는 알 수 없었다. Alert log 를 뒤져보았을 때 Standby Database
Logfile 을 자동으로 삭제한 부분은 없었다.
I.
Monitoring
Dataguard configuration
*아래의 목차는 7.B Reference 에서 그대로 가지고 왔다.
step 1. Check the configuration status
step 2. Check the database status
step 3. Check the LogXptStatus monitorable database
property.
step 4. Check the InconsistentProperties monitorable
database property
step 5. Check the InconsistentLogXptProps monitorable
database property
step 1 은 show configuration 명령에 대해 하단에 특이사항이 있냐 없냐를 말함이다. 특이사항이 없는 경우 success 라는 메시지가 나온다.
step 2 는 show database db_name 이나 show database
verbose db_name 명령을 통해 에러가 있는지 확인하라는 이야기이다. step2 가 step1 과 다른점은 1에서는 말그대로 요약 수준의 내용을 보여주는
반면 step2 에서는 에러내용을 다 보여준다.
step 3 는 show database database_name property_name 을 통해 내용을 확인하란 이야기이다. 근데 이 내용은 show database verbose 를 통해
전 Property 조회가 가능하기 때문에 별 의미는 없다.
step4 는 가드와 DB 간의 불일치하는 database property 를 찾아라라는
이야기다.
간단한 예는
다음과 같고 리턴되는 값이 없다면 불일치 파라미터가 없다는 뜻이다.
|
DGMGRL> show
database dg1 inconsistentproperties; INCONSISTENT
PROPERTIES INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE |
step 5 는 Log Transport 와 연관된 Property 에 불일치 파라미터를
찾아라란 이야기다.
이야기가
길어졌지만 결과적으로 show configuration 결과가 success
나오면 문제 없는것이고 문제가 있다면 show database verbose 를 통해 문제의
상세를 얻어 해결하면 끝난다.
7.
Refrerences
A.
7 Data
Guard Command-Line Interface Reference |
http://download.oracle.com/docs/cd/E11882_01/server.112/e17023/dgmgrl.htm
B.
6 Scenarios Using the DGMGRL
Command-Line Interface |
http://download.oracle.com/docs/cd/E11882_01/server.112/e17023/cli.htm#DGBKR495