[ORACLE] ADG 관련

출처 : http://soff.tistory.com/133

Data Guard

Active Data Guard가 어떻게 실시간 쿼리를 통해 스탠바이 환경에 대한 투자를 가치 있게 만들면서, 물리적 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환해, 아카이브 로그 및 많은 새로운 향상된 기능을 인프라에 적용하는지 자세한 정보를 알아 보겠습니다. Oracle Database 11g 다운로드

Oracle Database 11g에는 책 한 권을 채울 수 있을 만큼 많은 Data Guard의 향상된 기능이 있습니다. 따라서 모든 향상된 기능을 자세히 밝히기는 불가능합니다. 대신 가장 흥미롭다고 생각되는 것을 중심으로 설명하도록 하겠습니다.

보다 간편하진 스탠바이 데이터베이스 생성

이제 시작합니다. 먼저 물리적 스탠바이 데이터베이스의 생성입니다. Oracle Database 11g에서, 이 프로세스는 RMAN 커맨드 하나면 족할 정도로 무척 간편해졌습니다. 이전에는, 2대의 머신 사이에 Data Guard를 설정하려면, Grid Control 마법사 인터페이스를 사용했습니다. 이 글을 작성하고 있는 시점 에서는, Oracle Enterprise Manager Grid Control 11g는 아직 사용할 수 없고, Database Control도 Data Guard를 위한 마법사를 가지고 있지 않습니다. 그러나 SQL 커맨드 사용 경험의 유무에 상관없이, Oracle Database 11g에, Data Guard 환경을 설정하는 것은 어렵지 않습니다. 이는 너무 단순해 여기서 모든 단계를 설명할 수 있습니다.

prolin11로 명명된 기본 데이터베이스가 prolin1이라는 서버에서 운영되고 있다고 가정합니다. 스탠바이 데이터베이스는 prolin2라는 서버에 설정하려고 합니다. 스탠바이 데이터베이스 인스턴스의 명칭은 pro11sb입니다. 단계는 다음과 같습니다:

이미 가지고 있는 경우가 아니라면, 우선, prolin1에 spfile을 생성합니다.

SQL> create spfile from pfile;

이 단계는 필수적인 것은 아니지만, 프로세스를 쉽게 해주는 이점이 있습니다. 데이터베이스 생성 후, spfile을 사용하기 위하여 prolin11 데이터베이스를 다시 시작합니다

스탠바이 재실행 로그 생성은 필수적인 것은 아니지만, 그렇게 하는 것이 좋습니다. 스탠바이 재실행 로그는 기본 데이터베이스에 발생하는 변화를 거의 실시간으로 스탠바이에 반영되도록 하는데, 이것이 Real Time Apply (RTA)라는 개념입니다. 따라서, 우리는 여기서 기본 데이터베이스에 스탠바이 재실행 로그를 생성할 것입니다 (스탠바이 재실행 로그는 기본 데이터베이스에 생성된다는 것을 잊지 마십시오. RMAN이 이 일을 할 것입니다):

SQL> alter database add standby redo logfile group 4

  2> (‘+DG1/sby_redo01.rdo') size 50M;

SQL> alter database add standby redo logfile group 5

  2> (‘+DG1/sby_redo02.rdo') size 50M;

SQL> alter database add standby redo logfile group 6

  2> (‘+DG1/sby_redo03.rdo') size 50M;

SQL> alter database add standby redo logfile group 7

  2> (‘+DG1/sby_redo04.rdo') size 50M;

이를 통해 4개의 스탠바이 재실행 로그 그룹이 생성됩니다.

prolin2 서버의 listener.ora 파일에 pro11sb를 위한 입력을 합니다:

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = pro11sb)

      (ORACLE_HOME = /opt/oracle/product/11g/db1)

      (SID_NAME = pro11sb)

    )

  )

 

LISTENER =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))

  )

리스너를 실행하려면 재로딩합니다

prolin1에서, $ORACLE_HOME/network/admin: 하부의 tnsnames.ora 파일에 pro11sb 데이터베이스를 위한 입력을 합니다 :

PRO11SB =

  (DESCRIPTION =

    (ADDRESS_LIST =

      (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))

    )

    (CONNECT_DATA =

      (SID = pro11sb)

    )

  )

prolin2에서, Oracle Home/dbs 디렉토리에 1 라인을 포함하는 initodba11sb.ora 파일을 생성합니다:

db_name=prolin11

이는 스탠바이 인스턴스를 위한 초기화 파일로 기능할 것입니다; 파라미터의 나머지는 우리가 나중에 보게 될 RMAN 커맨드에 의해 자동 입력됩니다.

prolin2에서, $ORACLE_BASE/admin 디렉토리 갑니다. 여기에 pro11sb라는 이름의 디렉토리를 생성한 다음, 스탠바이 인스턴스에 대한 감사 파일을 보유하기 위하여 pro11sb 내에 adump라는 이름의 디렉토리를 생성합니다.

prolin1의 $ORACLE_HOME/dbs 디렉토리 하부에서, 흔히 orapworadba11로 명명되는 인스턴스 패스워드 파일을 볼 수 있습니다. 이 파일을 볼 수 없다면 (가능성은 희박하지만), 이를 생성합니다. 다음 그 파일을 prolin2의 $ORACLE_HOME/윤 하부로 복사합니다. 이를 orapwodba11sb 파일로 복사합니다. 이렇게 하면 기본 데이터베이스의 sysdba 연결 패스워드를 스탠바이에도 적용할 수 있습니다.

prolin2에서, NOMOUNT 상태의 인스턴스 pro11sb를 실행합니다:

$ sqlplus / as sysdba

SQL> startup nomount

이는 인스턴스를 실행하지만 아무것도 마운팅하지 않습니다.

이제 모든 초기화 준비가 완료되었으므로, 스탠바이 데이터베이스를 생성할 강력한 RMAN 스크립트를 호출합니다. prolin1에서, RMAN을 가동해 다음 스크립트를 실행합니다. 이를 파일에 저장하고 RMAN 프롬프트에서 스크립트를 실행하는 것은 매우 쉽습니다.

connect target sys/oracle123@prolin11

connect auxiliary sys/oracle123@pro11sb

 

run {

   allocate channel c1 type disk;

   allocate auxiliary channel s1 type disk;

 

   duplicate target database

        for standby

        from active database

        dorecover

        spfile

        parameter_value_convert 'prolin11','pro11sb'

        set db_unique_name='pro11sb'

        set db_file_name_convert='/prolin11/','/pro11sb/'

        set log_file_name_convert='/prolin11/','/pro11sb/'

        set control_files='/oradata/pro11sb/control01.ctl'

        set fal_client='pro11sb'

        set fal_server='prolin11'

        set standby_file_management='AUTO'

        set log_archive_config='dg_config=(prolin11,pro11sb)'

        set log_archive_dest_2='service=prolin11 LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb'

        set log_archive_dest_state_2='enable'

        set log_archive_format='pro11sb_%t_%s_%r.arc'

   ;

  sql channel c1 "alter system archive log current";

  sql channel s1 "alter database recover managed standby database using current logfile disconnect";

}

이 스크립트는 스탠바이 데이터베이스를 생성하고, 적절한 파라미터를 스탠바이 데이터베이스를 위한 spfile에 배치하고, 스탠바이 데이터베이스를 위한 진단 데스티네이션을 생성하고, 스탠바이를 다시 시작합니다. 이 작업의 정확한 구조를 이해하려면, 여기서 RMAN 커맨드의 아웃풋을 볼 필요가 있습니다.

아래의 2 라인은 기본 및 스탠바이 인스턴스에 연결됩니다:

connect target sys/oracle123@prolin11;

connect auxiliary sys/oracle123@pro11sb;

패스워드 파일을 스탠바이 호스트에 복사했기 때문에, SYS 패스워드는 동일하게 남아 있으며 따라서 스탠바이 인스턴스에 연결은 (마운팅 데이터베이스가 없지만) 성공적입니다. 다음으로, 다음과 같은 라인들이 실행됩니다:

duplicate target database for standby from active database

     spfile

        parameter_value_convert 'prolin11','pro11sb'

        set 'db_unique_name'='pro11sb'

        set 'db_file_name_convert'='/prolin11/','/pro11sb/'

        ... and so on ...

duplicate target database 커맨드는 우선 원격 서버에 있는 SQL*Net를 통해 기본 데이터베이스의 이미지를 복사함으로써 기본 데이터베이스로부터 스탠바이를 생성합니다. 복사가 완료되면, 내부적으로 커맨드를 발령하여 (switch clone datafile all;), 스탠바이 데이터베이스를 클론으로 만듭니다. 스크립트의 세트 커맨드가 스탠바이 인스턴스를 위한 SPFILE의 파라미터를 설정하며, 이 데이터베이스가 스탠바이 데이터베이스가 됩니다. 다시 말하지만, RMAN 아웃풋은 배후 활동에 대한 모든 정보를 제공합니다.

물리적 스탠바이 데이터베이스를 구축하는 것이 매우 쉽다는 것을 알아 두십시오. 이는 스크립트를 실행하는 것만큼이나 간단합니다!

Active Data Guard

물리적 스탠바이 데이터베이스를 사용하여 Data Guard 환경을 구현할 때 오랫동안 장애로 남아 있던 것 중의 하나는 스탠바이 데이터베이스의 수동성이었습니다. Oracle Database 10g 및 그 이전에는, 물리적 스탠바이 데이터베이스를 복구 프로세스를 멈춘 후에만, 읽기 전용 (말하자면, 리포팅 부담을 줄이기 위해)으로 개방했습니다. 이들 제품에서, Data Guard가 DR 솔루션의 일부이었다면, 뒤처지는 것이 두려워 오랫동안 복구 프로세스를 멈출 수 없었을 것이며, 따라서 물리적 스탠바이 데이터베이스는 읽기 전용을 위한 것이 아니라면, 당연히 무용지물이었을 것입니다

Oracle Database 11g로, 이제 상황이 변했습니다: 물리적 스탠바이 데이터베이스를 읽기 전용 모드로 개방하고 복구 프로세스를 다시 시작할 수 있습니다. 이는 기본 데이터베이스를 지속적으로 사용하면서 리포팅을 위해 스탠바이를 사용할 수 있다는 것을 의미합니다. (이전 버전의 경우와 마찬가지로, 스탠바이에서 백업도 할 수 있습니다.) 이것이 어떻게 이루어지는지 살펴 보겠습니다.

우선, 스탠바이 복구 관리를 취소합니다:

SQL> alter database recover managed standby database cancel;

Database altered.

다음, 데이터베이스를 읽기 전용으로 개방합니다:

SQL> alter database open read only;

 

Database altered.

여기까지는, 프로세스가 11g 이전 버전과 동일합니다. 이제, 11g의 정점을 살펴 보도록 하겠습니다: 스탠바이 데이터베이스가 읽기 전용으로 개방되어 있는 동안, 복구 프로세스 관리를 다시 시작할 수 있습니다.

SQL> alter database recover managed standby database disconnect;

 

Database altered.

이제 스탠바이 데이터베이스는 복구 관리 모드로 배치되어, 개방되어 있는 동안, 로그 파일을 적용합니다. 어떻게 이를 확인할 수 있을까요? 간단합니다; 단지 기본 데이터베이스의 최장 시퀀스 번호를 스탠바이의 그 것과 비교하면 됩니다. 기본 데이터베이스에서, 로그 변환을 하여 최장 시퀀스 번호를 확인합니다:

SQL> alter system switch logfile;

 

System altered.

SQL> select max(Sequence#) from v$log;

 

MAX(SEQUENCE#)

--------------

            79

로그 변환은 스탠바이가 읽기 전용 모드로 개방되어 있는 동안 진행됩니다. 스탠바이의 최장 시퀀스를 확인합니다:

SQL> select max(Sequence#) from v$log;

 

MAX(SEQUENCE#)

--------------

            79

이것 역시 79로 기본과 같습니다. 이는 로그 애플리케이션이 여전히 작업 중이라는 것을 보여줍니다. 여기서 이는 단순히 로그가 적용되고 있다는 것만을 보여주는 것이 아니냐는 의문이 생길 수 있습니다. 기본에서 진행되는 변화가 이 모드에서 보일까요? 확인해 보겠습니다. 기본에서, 테이블을 생성합니다:

SQL> create table test2 (col1 number);

 

Table created.

...그리고 나서 몇 개의 로그 변환을 하고 이들 로그가 스탠바이에 적용될 때까지 기다립니다. 다음으로 스탠바이 데이터베이스를 확인합니다:

SQL> desc test2

 Name                                      Null?    Type

 ----------------------------------------- -------- ---------------------------

 COL1                                               NUMBER

Presto! 테이블이 스탠바이에 생성되고, 쿼리가 가능해졌습니다.

이 경우, 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? RTA는 ADG에 필수적인 것은 아니지만, 기본에 생긴 최근의 변화를 보고자 할 때, ADG가 보다 유용한 것이 되도록 해줍니다

보안과 관련해선, 걱정할 것이 없습니다. 데이터베이스는 읽기 전용 모드에 있기 때문에, 아무것도 여기에 쓸 수 없습니다. 만약 audit_trail 파라미터가 기본에서 DB로 설정되어 있다면 (Oracle Database 11g에서의 디폴트), 스탠바이에서도 동일하지만, 일기 전용이기 때문에, 감사 추적을 쓸 수는 없습니다

알림 로그에 나타난 라인을 보십시오:

AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access

아하! 감사 추적은 멈추지 않습니다; 오히려, 데이터베이스가 개방되었을 때, OS 파일로 자동 전환됩니다. 스탠바이 데이터베이스를 활성화하면, audit_trail은 DB로 자동 재설정됩니다.

스냅샷 스탠바이

일반적 시나리오를 생각해 보겠습니다: 새로운 애플리케이션을 데이터베이스에 배치 중이고, 데이터베이스 성능의 영향에 대해 알고 싶다고 합시다. Oracle Database 11g에는, SQL 구문을 캡처하고 이를 재생하는 완벽한 툴이 있지만 (Database Replay), 그 영향력을 직접 실행해 보고 확인해 볼 필요가 있습니다. 테스트 시스템을 캡처하더라도, 프로덕션 시스템에서 재생하는 것은 불가능합니다. 우선, 배치가 되지 않습니다, 또한, 배치된다고 하더라도, 애플리케이션으로 다른 테이블을 변경할 수 없습니다. 그러면 애플리케이션의 영향력을 확인하려면 어떻게 해야 할까요?

완벽한 답은 물리적 스탠바이 데이터베이스를 업데이트가 가능한 스냅샷 스탠바이 데이터베이스로 임시 변환할 수 있는 Oracle Database 11g입니다. 이 모드에서, 애플리케이션을 운영할 수 있고—많은 테이블 변경 가능—그 영향력을 평가할 수 있습니다. 영향력을 평가한 후, 데이터베이스를 정상적 복구가 진행되고 있는 스탠바이로 변환할 수 있습니다. 이는 정해진 지점으로 플래시백하여 모든 변화를 원상 복구하는 플래시백 데이터베이스 기능을 사용하여 데이터베이스 복구 지점을 생성함으로써 가능합니다. 이 작업이 어떻게 진행되는지 알아보겠습니다:

우선, 이미 진행되고 있는 경우가 아니라면, 스탠바이에서 복구를 시작합니다:

SQL> alter database recover managed standby database disconnect;

Database altered.

복구가 몇 개의 로그 파일을 선정할 때까지 기다립니다. 그리고 복구를 중단합니다.

SQL> alter database recover managed standby database cancel;

 

Database altered.

여기서, 스냅샷 스탠바이 데이터베이스를 생성할 수 있습니다. 이것은 플래시백 로깅을 가능하게 하기 때문에, 플래시 복구 영역을 구성하지 않으면, 다음과 같은 메시지를 받게 됩니다:

ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_01/12/2008

00:23:14'.

ORA-38786: Flash recovery area is not enabled.

이를 피하기 위해서는, 미리 플래시 복구 영역을 생성해야 합니다. 이미 그렇게 하지 않았다 하더라도, 걱정할 필요는 없습니다. 지금 생성하면 되기 때문입니다:

SQL> alter system set db_recovery_file_dest_size = 2G;

 

System altered.

 

SQL> alter system set db_recovery_file_dest= '/db_recov';

 

System altered.

이제 절차를 마쳤으므로, 다음과 같은 간단한 커맨드를 사용해 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환할 수 있습니다:

SQL> alter database convert to snapshot standby;

Database altered.

이제 데이터베이스를 리사이클링합니다:

SQL> shutdown immediate

ORA-01507: database not mounted

...

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

이제 데이터베이스가 읽기/쓰기 작업을 위해 개방되었습니다:

SQL> select open_mode, database_role

  2  from v$database;

 

OPEN_MODE  DATABASE_ROLE

---------- ----------------

READ WRITE SNAPSHOT STANDBY

이제 데이터베이스를 변경할 수 있습니다. 여기가 Database Replay를 사용하여 캡처한 작업을 재생할 최적의 지점입니다. 이제 데이터베이스에서 시스템을 변경하고 변화의 영향력을 보기 위하여 몇 차례 재생할 수 있습니다. 이것은 프로덕션 데이터베이스의 복사본이므로, 재생은 해당 작업을 정확하게 재현합니다.

테스트가 완료되면, 스냅샷 스탠바이 데이터베이스를 정상적인 물리적 스탠바이 데이터베이스로 변환합니다. 다음과 같은 단계를 거칩니다:

SQL> connect / as sysdba

Connected.

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

 

...

Database mounted.

SQL> alter database convert to physical standby;

 

Database altered.

이제 끄고, 데이터베이스를 마운팅하고 복구 관리를 시작합니다.

SQL> shutdown

ORA-01507: database not mounted

 

 

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

...

Database mounted.

Start the managed recovery process:

SQL> alter database recover managed standby database disconnect;

이제 스탠바이 데이터베이스가 복구 관리 모드로 복귀했습니다. 당연히, 데이터베이스가 스냅샷 스탠바이 모드에 있으면, 기본의 아카이브 로그가 적용되지 않습니다. 이것은 지금 적용되며 작업 완료까지 몇 분 걸립니다.

스냅샷 스탠바이 데이터베이스는 스탠바이 데이터베이스를 사용하여 프로덕션 데이터베이스의 변화를 사전에 정확히 예상할 수 있습니다. 그러나 이게 전부가 아닙니다. 또 다른 장점이 있습니다. 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? 누군가 기본 데이터베이스에서 대규모 업데이트를 하거나 일부 코드를 변경하는 등 실수를 한다면 어떻게 될까요? 이전 버전에서, 이 같은 실수가 스탠바이로 확산되는 것을 방지하기 위하여, 신중하게 스탠바이 데이터베이스에서 딜레이를 사용합니다. 그러나 딜레이로 인해, 스탠바이가 올바로 작동하지 않거나 프로덕션의 활성 카피로 사용될 수 없을 수 있습니다.

더 이상은 필요 없습니다. 스탠바이 데이터베이스를 플래시백할 수 있기 때문에, 딜레이를 유지하고 있을 필요가 없습니다. 문제가 있다면, 언제든지 이전 상태로 플래시백할 수 있습니다.

물리적 스탠바이에서 논리적 스탠바이로의 변환

이제 물리적 스탠바이 데이터베이스를 논리적인 것으로 쉽게 변환할 수 있습니다. 다음 단계를 거칩니다:

스탠바이 데이터베이스는 어딘가로부터 데이터 딕셔너리 정보를 가져올 필요가 있습니다. 딕셔너리 정보는 기본의 재실행 스트림에 배치되어야 합니다. 따라서, 기본 데이터베이스에서, 다음과 같이 하여 딕셔너리를 위한 LogMiner 테이블을 만듭니다:

SQL> begin

  2    dbms_logstdby.build;

  3  end;

  4  /

 

PL/SQL procedure successfully completed.

스탠바이에서, 복구 관리 프로세스를 멈춥니다

SQL> alter database recover managed standby database cancel;

Database altered.

이제, 스탠바이에 커맨드를 입력해 이를 논리적인 것으로 변환합니다:

SQL> alter database recover to logical standby pro11sb;

 

Database altered.

1 단계를 실행하지 않았다면, 위의 커맨드는 딕셔너리 정보가 없기 때문에, 멈춰 있을 것입니다. 이 경우 여기서 1 단계를 실행하면 됩니다. RTA를 실행했다면, 정보는 스탠바이 데이터베이스에 즉각 정보가 나타날 것입니다.

기본의 몇 가지 로그 변환을 통해 아카이브 로그를 생성해 스탠바이로 보내야 합니다:

SQL> alter system switch logfile;

 

System altered.

잠시 후, 스탠바이에서, 데이터베이스 변경 커맨드가 완료되는 것을 볼 수 있습니다. 이제 스탠바이가 논리적인 것으로 변했습니다. 알림 로그에서 다음과 같은 것이 나타납니다:

RFS[12]: Identified database type as 'logical standby'

Recycle the database:

SQL> shutdown

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

 

Total System Global Area 1071333376 bytes

...

Database mounted.

SQL> alter database open resetlogs;

 

Database altered.

이제 논리적 스탠바이로 되었으므로, SQL Apply 프로세스를 시작해야 합니다

SQL> alter database start logical standby apply immediate;

SQL> alter database start logical standby apply immediate; 논리적 스탠바이 데이터베이스가 이제 완전 작동합니다! 일단 물리적 스탠바이를 논리적인 것으로 변환하면, 다음에서 설명할 특수 구문 ("keep identity")을 사용하지 않는 한 ,이를 다시 물리적인 것으로 변환할 수 없습니다.

롤링 업데이트

DBA의 업무에서 어려운 점은 업그레이드를 위해 꽤 오랜 시간 데이터베이스를 내려야 하는 정당성을 밝히는 것입니다. Oracle Database 11g에서는, 롤링 업데이트를 통해 어떠한 유형의 스탠바이 데이터베이스라도 가지고 있다면, 이 일은 매우 쉬어집니다:

스탠바이를 업그레이드합니다.

애플리케이션을 스탠바이로 옮깁니다.

기본을 업그레이드합니다.

애플리케이션을 다시 본래의 기본으로 옮깁니다.

이것이 논리적 스탠바이라면, 스탠바이가 단지 기본의 SQL을 적용하면 되기 때문에, 프로세스가 매우 간편합니다. SQL이 적용되면, 업그레이드는 해당 데이터베이스에서 쉽게 이루어집니다. 복구를 멈추고, 스탠바이를 업그레이드하고, 복구를 진행한 후, 스탠바이를 기본으로 변환할 수 있습니다. 나중에, 본래의 기본을 업그레이드 할 스탠바이로 만들 수 있습니다. 마지막으로, 역할을 바꿔, 본래의 기본을 새로운 기본으로 만들 수 있습니다.

그러나, 많은 스탠바이 데이터베이스는 사용 및 관리의 간편성을 위해 본질적으로 물리적입니다. 스탠바이가 논리적이 아니라 물리적이라면, 단계는 거의 흡사합니다. 스탠바이를 임시로 논리적으로 변환한 후 다시 물리적으로 변환하는 것입니다. 여기서 중요한 것은 영구적이 아니라 임시로라는 것입니다. 따라서, 다음과 같이 "keep identity"구문을 가진 변환 커맨드를 입력합니다:

SQL> alter database recover to logical standby keep identity;

 

Database altered.

보다 자세한 내용은 문서에서 확인할 수 있습니다.

기타 개선 사항

Data Guard 프로세스 자체에 몇 가지 중요한 개선 내용이 있습니다:

재실행 압축

Data Guard는 기본의 아카이브 로그를 스탠바이 데이터베이스 서버로 옮겨 이를 해당 데이터베이스에 적용한다는 전제를 가지고 있습니다. 기본과 스탠바이 사이의 시간 지체의 핵심 요소의 하나는 아카이브 로그를 옮기는 시간입니다. 이는 재실행 스트림을 압축하면 어느 정도 줄일 수 있습니다.

Oracle Database 11g에서는 TRUE로 설정된 파라미터 압축을 사용하여 SQL*Net를 통해 스탠바이 서버 전체를 경유하는 재실행 스트림을 압축할 수 있습니다. 이는 오로지 갭 해소 중에 옮겨지는 로그를 위한 것입니다. 이 문서의 앞부분에 제시된 사례에서 압축을 할 때 사용할 수 있는 커맨드는 다음과 같습니다.

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable'

네트 타임 아웃

Data Guard 환경은 데이터베이스 인스턴스 연결을 통해 재실행 데이터를 스탠바이 서버로 보내 작동시킨다. 인스턴스가 시간 내 응답하지 않으면, 로그 전송 서비스는 지정된 타임 아웃 값을 기다린 후 중단합니다. 이 타임 아웃 값은 Oracle Database에 net_timeout이라는 파라미터를 사용해 설정할 수 있습니다. 최대 보호 모드에서, 로그 전송 서비스는 중단 전 20회의 재시도를 합니다.

그러나 우선 로그 전송에서 얼마만큼의 딜레이가 존재하는지 알아야 합니다. 새로운 뷰 v$redo_dest_resp_histogram에 막대 그래프 모양으로 시간이 나타납니다:

SQL> desc v$redo_dest_resp_histogram

 Name                   Null?    Type

 ---------------------- -------  --------------

 DEST_ID                         NUMBER

 TIME                            VARCHAR2(20)

 DURATION                        NUMBER

 FREQUENCY                       NUMBER

 

뷰는 해당 버킷에서 전송 시간 측정 결과를 보여줍니다. 작동 후 며칠 후 뷰를 조사해 보면, 타임 아웃에 설정에 대한 구상을 할 수 있을 것입니다. 다음과 같이 하여 타임 아웃 값을 설정할 수 있습니다:

alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC

valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'

다시 한 번 말하지만, 이는 앞에서 제시한 사례와 관련된 것입니다. 파라미터 값의 "net_timeout=20" 구문을 기억해 두십시오.

동적 변경 가능 파라미터

논리적 스탠바이 데이터베이스 환경 운영 프로세스에서, 프로세스를 튜닝하고 일부 파라미터 값을 조정할 필요가 있습니다. Oracle Database 11g에서, 이들 대부분의 파라미터는 온라인에서 업데이트할 수 있습니다. 뷰 dba_logstdby_parameters를 쿼리하면 이를 알 수 있습니다.

col name format a30

col value format a10

col unit format a10

col setting a6

col setting format a6

col dynamic format a7

select *

from dba_logstdby_parameters

order by name

/

NAME                           VALUE      UNIT       SETTIN DYNAMIC

------------------------------ ---------- ---------- ------ -------

APPLY_SERVERS                  5                     SYSTEM YES

EVENT_LOG_DEST                 DEST_EVENT            SYSTEM YES

                               S_TABLE

LOG_AUTO_DELETE                TRUE                  SYSTEM YES

LOG_AUTO_DEL_RETENTION_TARGET  1440       MINUTE     SYSTEM YES

MAX_EVENTS_RECORDED            10000                 SYSTEM YES

MAX_SERVERS                    9                     SYSTEM YES

MAX_SGA                        30         MEGABYTE   SYSTEM YES

PREPARE_SERVERS                1                     SYSTEM YES

PRESERVE_COMMIT_ORDER          TRUE                  SYSTEM NO

RECORD_APPLIED_DDL             FALSE                 SYSTEM YES

RECORD_SKIP_DDL                TRUE                  SYSTEM YES

RECORD_SKIP_ERRORS             TRUE                  SYSTEM YES

RECORD_UNSUPPORTED_OPERATIONS  FALSE                 SYSTEM YES

칼럼 DYNAMIC이 값을 동적으로 변경 가능한지를 보여 준다는 사실을 기억해 두십시오. 거의 모든 파라미터는 동적입니다. 예를 들어, 스탠바이를 멈추지 않고 파라미터 APPLY_SERVERS를 변경하려면, 다음과 같이 합니다.

SQL> begin

  2     dbms_logstdby.apply_set('APPLY_SERVERS',2);

  3  end;

  4  /

이는 apply_servers 값을 2로 설정하는데, 이는 스탠바이를 멈추지 않고 할 수 있습니다.

SQL Apply 이벤트 테이블

Oracle Database 10g에서, SQL Apply와 관련된 이벤트는 알림 로그에 작성되는데, 알림 혹은 리포팅 확인을 위하여 스크립트를 작성하는 편이 좋기 때문에, 그다지 유용한 것이 못됩니다. Oracle Database 11g에서, 이벤트는 디폴트로 SYSTEM 스키마의 새로운 테이블 LOGSTDBY$EVENTS에 작성되도록 되어 있습니다. 다음은 샘플 쿼리입니다:

select event_time, error

from system.logstdby$events

order by 1;

The output:

EVENT_TIME                    ERROR

----------------------------- -------------------------------------------------

13-JAN-08 11.24.14.296807 PM  ORA-16111: log mining and apply setting up

13-JAN-08 11.24.14.320487 PM  Apply LWM 2677727, HWM 2677727, SCN 2677727

14-JAN-08 07.22.10.057673 PM  APPLY_SET: APPLY_SERVERS changed to 2

14-JAN-08 07.22.11.034029 PM  APPLY_SERVERS changed to 2

14-JAN-08 07.45.15.579761 PM  APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

14-JAN-08 07.45.16.430027 PM  EVENT_LOG_DEST changed to DEST_ALL

여러 가지 이유로, 이 이벤트를 테이블에 가지고 있는 것이 좋습니다. 예를 들면, 조작 및 리포팅이 간편해집니다. 그러나 때로는, 특히 오류 및 메시지 알림 로그를 스캐닝하기 위한 모니터링 툴을 구현했다면, 이를 알림 로그에서 보는 것도 괜찮습니다. 이는 논리적 스탠바이 데이터베이스 적용 파라미터 "event_log_dest"를 "DEST_ALL"로 설정하면 가능해집니다:

begin

   dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');

end;

이는 동적으로 이루어지며, 이벤트는 테이블과 알림 로그 모두에 전달됩니다. 이 커맨드를 입력한 후, 알림 로그를 확인할 수 있습니다. 많은 SQL Apply 이벤트와 더불어 최소한 다음의 2 라인이 보일 것입니다:

LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL

LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL

결론

우선, 우리는 활성 기본 데이터베이스로부터 물리적 스탠바이 데이터베이스를 구현하는 것이 별 것 아니라는 것을 알게 되었습니다. 또한, 물리적 스탠바이를 논리적으로 변환하는 것이 매우 간단하다는 것도 알게 되었습니다. 이 사실로부터 누릴 수 있는 최대의 장점은 스탠바이 데이터베이스를 어떤 방식으로든 비즈니스 지원을 위해 사용할 수 있다는 것입니다. Active Data Guard 기능은 스탠바이 데이터베이스를 개방해 아카이브 로그가 적용되는 동안 쿼리를 허용합니다. 스냅샷 스탠바이 데이터베이스는 데이터베이스에서 프로덕션 데이터베이스 로딩을 허용한 후 정상적 복구 관리 프로세스를 다시 시작하도록 처음 시작했던 지점으로 플래시백합니다. 이들 2가지 기능은 스탠바이 서버의 프로세싱 기능을 활용할 수 있도록 허용하기 때문에 11g로의 업그레이드를 위한 강력한 촉매 역할을 할 것입니다.