오라클 서버는 데이터베이스 내의 데이터 손실을 최소화하기 위해 온라인 리두 로그 파일을 유지(maintain)합니다. 리두 로그 파일은 데이터베이스 버퍼 캐쉬 내의 데이터에 가해진 모든 변경 사항을 기록합니다. 예외도 있는데,

오라클 서버는 데이터베이스 내의 데이터 손실을 최소화하기 위해 온라인 리두 로그 파일을 유지(maintain)합니다. 리두 로그 파일은 데이터베이스 버퍼 캐쉬 내의 데이터에 가해진 모든 변경 사항을 기록합니다. 예외도 있는데, 직접 쓰는 경우(direct write)가 그 예입니다.

리두 로그 파일은 인스턴스 실패 같은 상황에서 데이터 파일에는 쓰여지지 않은 커밋된 데이터를 복구하기 위해 사용됩니다. 리두 로그 파일은 복구를 위해서만 사용됩니다.

리두 로그 파일 구조

데이터베이스 관리자는 오라클 데이터베이스에서 온라인 리두 로그 파일 복사본을 유지 관리하도록 설정하여 어느 한 부분의 장애로 인한 데이터베이스 정보의 손실을 막을 수 있습니다.

온라인 리두 로그 그룹

온라인 리두 로그 파일의 동일한 복사본 모음을 온라인 리두 로그 그룹이라고 합니다.
LGWR 백그라운드 프로세스는 그룹에 있는 모든 온라인 리두 로그 파일에 동일한 정보를 동시에 기록합니다.
Oracle 서버에는 데이터베이스의 정상적인 운영을 위해 적어도 두 개의 온라인 리두 로그 파일 그룹이 필요합니다.

온라인 리두 로그 멤버

그룹에 있는 각 온라인 리두 로그 파일을 멤버라고 합니다.
그룹에 있는 각 멤버는 동일한 로그 시퀀스 번호 및 크기를 가집니다. Oracle 서버는 각 리두 로그 파일을 고유하게 식별하도록 로그 그룹에 기록을 시작할 때마다 로그 시퀀스 번호를 지정합니다. 현재 로그 시퀀스 번호는 제어 파일과 모든 데이터 파일 헤더에 저장됩니다.

초기 리두 파일 생성

데이터베이스를 생성하는 동안 온라인 리두 로그 그룹 및 멤버의 초기 집합이 생성됩니다.

다음 매개변수는 온라인 리두 로그 파일 개수를 제한합니다.

CREATE DATABASE 명령에서 MAXLOGFILES 매개변수는 온라인 리두 로그 그룹의 절대 최대값을 지정합니다.
MAXLOGFILES의 최대값 및 기본값은 운영 체제에 따라 다릅니다.
CREATE DATABASE 명령에서 MAXLOGMEMBERS 매개변수는 그룹당 최대 멤버 수를 결정합니다. MAXLOGMEMBERS의 최대 값 및 기본값은 운영 체제에 따라 다릅니다.
LOG_FILES 초기화 매개변수는 데이터베이스 실행 시 열 수 있는 현재 최대 로그 그룹 수를 설정하고 이 값은 MAXLOGIFLES 값을 초과할 수 없습니다.

Technical Note

데이터베이스 관리를 단순화하기 위해 릴리스 8.1에서는 LOG_FILES 매개변수를 사용하지 않습니다.

리두 로그 버퍼와 백그라운드 프로세스 LGWR
오라클 서버는 데이터베이스에 가해진 모든 변경 사항을 리두 로그 버퍼에 순차적으로 기록합니다. 리두 로그 버퍼는 원형 방법(circular manner)으로 사용됩니다. 다음 상황일 때 LGWR 프로세스가 리두 엔트리를 현재의 온라인 리두 로그 그룹이라 불리우는 온라인 리두 로그 그룹 중 하나에 기록합니다.
   -커밋 시
   -리두 로그 버퍼 풀이 3분의 1 가량 찼을 때
   -LGWR 타임 아웃 발생 시(매 3초마다)
   -DBWR이 데이터베이스 버퍼 캐쉬의 수정된 블록을       데이터 파일에 적기 전

로그 스위치
LGWR는 온라인 리두 로그 파일에 순차적으로 씁니다. 즉, 현재의 온라인 리두 로그 그룹이 차게 되면 LGWR는 다음 그룹에 쓰기 시작합니다. 마지막 온라인 리두 로그 파일도 차면 LGWR는 첫번째 온라인 리두 로그 그룹으로 돌아가서 다시 쓰기 시작합니다.
로그 스위치는 LGWR이 한 온라인 리두 로그 그룹에 쓰기를 멈추고 그 다음 온라인 리두 로그 그룹에 쓰기 시작하는 이벤트입니다.
데이터베이스 관리자가 로그 스위치를 발생시킬 수 있습니다.(다음절을 참조하십시오.) 로그 스위치가 발생하고 LGWR이 새 로그 그룹에 쓰기 시작할 때마다 오라클 서버는 리두 엔트리들을 식별하기 위해 로그 시퀀스 번호를 할당합니다.
로그 스위치가 발생할 때 체크포인트라는 이벤트도 시작됩니다.

체크포인트
체크포인트 동안에 다음과 같은 작업이 이루어 집니다.
- 체크포인트가 발생한 로그와 관련된 사용된 모든 데이터     베이스 버퍼(더티 버퍼)는 DBWR에 의해 데이터 파일로     옮겨 쓰여집니다.
- 체크포인트 백그라운드 프로세스 CKPT는 완료된 것을     반영하여 모든 데이터 파일의 헤더와 과 콘트롤을 갱신     합니다.
체크포인트는 데이터베이스의 모든 데이터 파일에 발생할 수도 있고 특정 데이터 파일에만 발생할 수도 있습니다.

체크포인트는 다음 상황에서 발생합니다.
- 모든 로그 스위치 때
- 인스턴스가 정상 종료나 트랜잭션 종료, 또는 즉시 종료     되었을 때
-  LOG_CHECKPOINT_INTERVAL LOG_CHECKPOINT      _TIMEOUT 초기화 파라미터의 설정에 따라(다음 절을     참조하십시오.)
-  데이터베이스 관리자가 수동으로 요구했을 때(다음 절을     참조하십시오.)

초기화 파라미터 LOG_CHECKPOINTS_TO_ALERT가 TRUE로 설정되어 있으면 모든 체크포인트에 대한 정보가 ALERT 파일에 기록됩니다. 기본값은 FALSE로, 이 경우는 체크포인트를 기록하지 않습니다.

리두 로그 파일 아카이브
데이터베이스 관리자가 내려야 하는 중요한 결정 중의 하나는 데이터베이스가 ARCHIVELOG 모드로 작동하게 구성할 것인지, 아니면 NOARCHIVELOG 모드로 작동하게 구성할 것인지 하는 것입니다.

NOARCHIVELOG 모드
NOARCHIVELOG 모드에서는 온라인 리두 로그 파일이 찰 때와 로그 스위치가 발생할 때마다 온라인 리두 로그 파일이 겹쳐 쓰여집니다. LGWR는 해당 그룹에 대한 체크포인트가 완료될 때까지 리두 로그 그룹을 겹쳐쓰지 않을 것입니다.

ARCHIVELOG 모드
데이터베이스가 ARCHIVELOG 모드로 구성되어 있다면 차(fill)버린 온라인 리두 로그 파일의 비활성 그룹은 아카이브되어야만 합니다. 데이터베이스에 가해진 모든 변경 사항이 온라인 리두 로그 파일에 기록되므로 데이터베이스 관리자는 어떠한 경우의 실패가 있더라도 물리적 백업과 아카이브된 온라인 리두 로그 파일을 사용하여 커밋된 데이터를 잃어버리지 않고 데이터베이스를 복구할 수 있습니다.

온라인 리두 로그 파일이 아카이브될 수 있는 방법이 두 가지 있습니다.
  - 수동으로
  - 자동으로

초기화 파라미터 LOG_ARCHIVE_START는 인스턴스가 시작될 때 아카이브가 자동과 수동, 어느 쪽으로 행해질 것인지 나타냅니다.
  - TRUE는 아카이브가 자동으로 이루어짐을 의미합니다. ARCH는 로그 스위치 때마다 사용한 로그 그룹을 아카이브하기 시작할 것입니다.
  - 기본값인 FALSE는 데이터베이스 관리자가 사용한 리두 로그 파일을 수동으로 아카이브할 것이라는 것을 의미합니다. 온라인 리두 로그 파일을 아카이브하고자 할 때마다 Server Manager 명령을 수행해야  합니다. 모든 온라인 로그 파일을 수동으로 아카이브할 수도 있고, 지정한 온라인 로그 파일을 수동으로 아카이브할 수 있습니다.

주
Oracle8: Backup and Recovery Workshop 과정에서 더 자세히 다루어집니다.

아카이브 정보 얻기

다음 SQL 명령은 데이터베이스 로그 모드와 자동 아카이브 사용 가능 여부를 보여줍니다.

SQL> ARCHIVE LOG LIST

Database log mode No Archive Mode

Automatic archival Disabled

Archive destination ?/dbs/arch

Oldest online log sequence 688

Current log sequence 689

V$DATABASE 및 V$INSTANCE 동적 성능 뷰를 질의하여 데이터베이스 로그 모드와 아카이브 모드를 표시합니다.

SQL> SELECT name, log_mode

2 FROM v$database;

NAME LOG_MODE

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

U15 NOARCIVELOG

1 rows selected.

SQL> SELECT archiver

2 FROM v$instance;

ARCHIVE

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

STOPPED

1 rows selected

온라인 리두 로그 그룹의 갯수와 현재 로그 그룹, 그리고시퀸스 번호를 알고 싶으면 동적 성능 뷰 V$THREAD를 질의하십시오. 병렬 서버 관리자에게는 유용한 정보를 제공할 것입니다.

   SVRMGR> SELECT group, current_group#, sequence#
                      2> FROM v$thread;

        GROUPS       CURRENT_GR         SEQUENCE#
       --------        ------------          -----------
                   2                           1                        689

       1 row selected.

로그 그룹 정보 얻기(계속)

다음 질의는 제어 파일에서 온라인 리두 로그 파일에 대한 정보를 반환합니다.

SQL> SELECT group#, sequence#, bytes, members, status

2 FROM v$log;

GROUP# SEQUENCE# BYTES MEMBERS STATUS

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

1 688 1048576 1 CURRENT

2 689 1048576 1 INACTIVE

2 rows selected.

다음 항목은 STATUS 열에 가장 일반적인 값입니다.

UNUSED는 온라인 리두 로그 그룹에 기록된 적이 없음을 나타내며 방금 추가된 온라인 리두 로그 파일의 상태입니다.
CURRENT는 현재 온라인 리두 로그 그룹을 나타내며 온라인 리두 로그 그룹이 활성화 상태임을 암시합니다.
ACTIVE는 온라인 리두 로그 그룹이 활성화 상태지만 현재 온라인 리두 로그 그룹은 아님을 나타냅니다. 온라인 리두 로그 그룹은 고장 복구에 필요하고 블록 복구에 사용될 수 있으며 아카이브될 수도 있고 안될 수도 있습니다.
CLEARING은 로그가 ALTER DATABASE CLEAR LOGFILE 명령 후에 비어있는 로그로 재생성 중임을 나타내며 로그가 지워진 다음 상태는 UNUSED로 변경됩니다.
CLEARING_CURRENT는 현재 로그 파일이 닫힌 스레드에 대해 지워지고 있음을 나타냅니다. 새 로그 헤더를 기록하는 중 I/O 오류 같은 스위치 장애가 발생한 경우 로그는 이 상태가 될 수 있습니다.
INACTIVE는 인스턴스 복구에 온라인 리두 로그 그룹이 더 이상 필요하지 않음을 나타내며 온라인 리두 로그 그룹은 아카이브될 수도 있고 안될 수도 있습니다.

그룹의 모든 멤버의 이름을 알고자 할 때는 동적 성능 뷰 V$LOGFILE을 질의하십시오. 뷰 안의 STATUS 컬럼은 다음의 값들을 갖습니다.

INVALID는 파일에 접근할 수 없다는 것을 의미합니다.
STALE은 파일에 내용이 완료되지 않았음을 의미합니다. 예를 들자면 파일 멤버가 추가되고 있는 중인 경우입니다.
DELETED는 파일이 더 이상 사용되고 있지 않음을 의미합니다.
NULL은 파일이 사용중임을 의미합니다.
  SVRMGR> SELECT *
       2> FROM v$logfile;
  GROUP# STATUS MEMBER
  ------ ------ ----------------
       1          /DISK3/log1a.rdo
       2          /DISK4/log2a.rdo

로그 스위치 및 체크포인트 시행

LGWR가 한 온라인 리두 로그 그룹에 기록하는 것을 중지하고 다른 그룹에 기록을 시작할 때 로그 스위치가 발생합니다.

예ㄷ를 들어, 현재 온라인 로그 파일 그룹이 채워질 때 로그 스위치와 체크포인트는 자동 발생되는 이벤트입니다. 그러나 로그 스위치와 체크포인트는 시행될 수도 있습니다.

로그 스위치 시행

다음 SQL 명령을 사용하여 로그 스위치를 시행할 수 있습니다.

SQL> ALTER SYSTEM SWITCH LOGFILE;

체크포인트 시행

다음 SQL 명령을 사용하여 체크포인트를 수동으로 시행할 수 있습니다.

SQL> ALTER SYSTEM CHECKPOINT;

데이터베이스 체크포인트 간격 설정

데이터베이스가 대형 온라인 리두 로그 파일을 사용하는 경우 다음과 같이 초기화 매개변수를 설정하여 추가 데이터베이스 체크포인트를 설정할 수 있습니다.

LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
FAST_START_IO_TARGET(릴리스 8.1, 단 Enterprise Edition에서만 사용 가능)

LOG_CHECKPOINT_INTERVAL

릴리스 8.1 이전 버전에서는 LGWR가 LOG_CHECKPOINT_INTERVAL 매개변수에 의해 지정된 블록 개수를 기록하는 즉시 체크포인트가 시작됩니다.

LOG_CHECKPOINT_INTERVAL 값은 운영 체제 블록에서 지정되고 오라클 데이터베이스 블록에서는 지정되지 않습니다.

이 값에 상관없이 한 온라인 리두 로그 파일에서 다른 파일로 스위치가 발생하면 체크포인트는 항상 발생합니다.

이 값이 실제 온라인 리두 로그 파일 크기를 초과하면 로그 스위치가 발생할 때만 체크포인트가 발생합니다.

체크포인트 간격 값을 0으로 지정하면 마지막 요청이 시작된 후 리두 로그 버퍼가 하나만 기록되더라도 새 요청이 시작되므로 체크포인트가 매우 자주 발생할 수 있음을 참고하십시오.

릴리스 8.1에서 LOG_CHECKPOINT_INTERVAL을 지정하면 체크포인트 위치에 대한 대상은 이 매개변수가 지정한 리두 로그 블록 수 이상으로 로그 마침을 지연할 수 없습니다. 이것은 인스턴스 복구 중 고정된 수의 리두 블록만이 읽혀져야 함을 보장합니다.

LOG_CHECKPOINT_TIMEOUT

릴리스 8.1 이전 버전에서 이 초기화 매개변수 값은 다른 체크포인트가 발생하기 전의 최대 시간을 지정하며 이 값은 초 단위로 지정됩니다. 시간은 이전 체크포인트 시작 시에 측정되기 시작하여 이 매개변수가 지정한 시간 후에 체크포인트가 발생합니다.

시간 초과 값을 0으로 지정하면 시간 기준 체크포인트를 비활성화합니다.

릴리스 8.1에서 LOG_CHECKPOINT_TIMEOUT이 지정된 경우 이 매개변수는 체크포인트 위치에 대한 대상을 지정 시간(초)에 로그가 끝났던 로그 파일의 위치로 설정합니다. 이것은 복구 중에 지정된 시간(초)을 초과하지 않는 범위 내에서 리두 블록을 읽어야 함을 보장합니다.

FAST_START_IO_TARGET

FAST_START_IO_TARGET 매개변수는 고장 복구 및 인스턴스 복구의 성능을 향상시킵니다. 이 매개변수 값이 작을수록 작은 수의 블록이 복구되어야 하므로 복구 성능이 향상됩니다. 이 매개변수를 설정하면 DBWn은 더티 버퍼를 보다 적극적으로 기록합니다. 이 매개변수는 릴리스 8.1에서 도입되었습니다.

Technical Note

빠른 체크포인트 프로시저에 대한 자세한 정보는 Oracle8i Administration: Backup and Recovery 과정에서 설명합니다.

어떤 경우에는 추가 로그 파일 그룹을 생성하는 것이 필요할 수 있습니다. 예를 들면 그룹을 추가하는 것이 가용성 문제를 해결해 줄 수도 있습니다. 새 온라인 리두 로그 파일 그룹을 생성하려면 다음 SQL 문을 사용하십시오.

          ALTER DATABASE[database]
              ADD LOGFILE [GROUP integer] filespec
              [,                       [GROUP integer] filespec] . . .]

파일 지정에 멤버의 이름과 위치를 지정합니다. 각 리두 로그 파일 그룹에 대해 GROUP 파라미터의 값을 지정할 수 있습니다. GROUP값을 지정하지 않으면 오라클 서버는 자동적으로 만들어 냅니다.

OEM
1   Backup Manager를 사용하십시오.
2   Subsystem을 선택하십시오.
3   Logfile->Add Logfile Group을 선택하십시오.

리두 로그 멤버 추가

다음 ALTER DATABASE ADD LOGFILE MEMBER 명령을 사용하여 기존 리두 로그 파일 그룹에서 새 멤버를 추가할 수 있습니다.

ALTER DATABASE [database]

ADD LOGFILE MEMBER

[ 'filename' [REUSE]

[, 'filename' [REUSE]]...

TO {GROUP integer

|('filename'[, 'filename']...)

}

]...

파일이 데이터베이스 서버의 기본 디렉토리에 생성되지 않도록 로그 파일 멤버의 전체 지정 이름을 사용합니다.

해당 파일이 이미 존재하는 경우 크기가 동일해야 하며 REUSE 옵션을 지정해야 합니다. 하나 이상의 그룹 멤버를 지정하거나 그룹 번호를 지정하여 대상 그룹을 식별할 수 있습니다.

온라인 리두 로그 파일의 위치는 온라인 리두 로그 파일을 재명명(rename)하여 변경할 수 있습니다. 온라인 리두 로그 파일을 재명명하기 전에 새 온라인 리두 로그 파일이 있는지 확인하십시오. 오라클 서버는 콘트롤 파일 내의 포인터만을 바꿔 줄 뿐이지 물리적으로 재명명해주거나 운영 체제 파일을 생성하는 것은 아닙니다.
ALTER DATABASE RENAME FILE 명령이 온라인 리두 로그 파일의 이름을 변경합니다.

       ALTER DATABASE [database]
              RENAME FILE ‘filename’ [,   ‘filename’] . . .
                                 TO ‘filename’ [,   ‘filename’] . . .

OEM
1   Backup Manager를 사용하십시오.
2   Subsystem을 선택하십시오.
3   Logfile Group 노드를 확장하십시오.
4   Log file group을 선택하십시오.
5   Property sheet의 파일명을 변경하십시오

온라인 리두 로그 그룹의 크기를 증가시키거나 감소시키려면 새 온라인 리두 로그 그룹(새 크기를 가진)을 추가하고 예전 것을 삭제하십시오.
전체 온라인 리두 로그 그룹은 ALTER DATABASE DROP LOGFILE 명령으로 삭제할 수 있습니다.

  ALTER DATABASE [database]
  DROP LOGFILE
{GROUP integer | ( ‘filename’ [,   ‘filename’ ] . . .)}
[, {GROUP integer | ( ‘filename’ [,   ‘filename’ ] . .   .)}] . . .

OEM
1   Backup Manager를 사용하십시오.
2   Subsystem을 선택하십시오.
3   Logfile Group 노드를 확장하십시오.
4   Log file group을 선택하십시오.
5   Logfile->Drop Logfile Group을 선택하십시오.
6   OK를 클릭하십시오.

제한 사항
-인스턴스는 최소한 두 그룹의 온라인 리두 로그 파일을 필요로    합니다.
-활성중인 그룹은 삭제할 수 없습니다.
-데이터베이스가 ARCHIVELOG 모드이고 로그 파일 그룹이    아카이브되지 않았으면 그 그룹은 삭제할 수 없습니다.
-온라인 리두 로그 그룹이 삭제될 때 운영 체제 파일까지 삭제   되는 것은 아닙니다.

온라인 리두 로그 멤버가 INVALID하기 때문에 삭제하고자 할 수도 있습니다. 하나 이상의 특정 온라인 리두 로그 멤버를 삭제하고자 할 때는 ALTER DATABASE DROP LOGFILE MEMBER 명령을 사용하십시오.

ALTER DATABSE [database]
DROP LOGFILE MEMBER ‘filename’ [, ‘filename’] . ..

OEM
1   Backup Manager를 사용하십시오.
2   Subsystem을 선택하십시오.
3   Logfile Member 노드를 확장하십시오.
4   Log file member를 선택하십시오.
5   Logfile->Drop Logfile Member를 선택하십시오.
6   OK를 클릭하십시오.

제한 사항
   -삭제하고자 하는 멤버가 그룹의 하나 남은 유효 멤버라면 그     멤버를 삭제할 수 없습니다.
   -그룹이 활성중이면 멤버를 삭제하기 전에 로그 파일 스위치를     발생시켜야 합니다.
   -데이터베이스가 ARCHIVELOG 모드이고 멤버가 속한 로그     파일 그룹이 아카이브되지 않고 있으면 그 멤버를 삭제할 수     없습니다.
   -온라인 리두 로그 멤버가 삭제될 때 운영 체제 파일까지 삭제    되는 것은 아닙니다.

모든 멤버 중에서 한 리두 로그 파일이 훼손되었다면 데이터베이스 관리자는 훼손된 로그 파일을 재초기화하여 문제를 해결할 수 있습니다.
SQL 명령 ALTER DATABASE CLEAR LOGFILE명령이 온라인 리두 로그 파일을 재초기화해 줍니다.

ALTER DATABASE [database]

CLEAR [UNARCHIVED] LOGFILE

{GROUP integer | (‘filename’ [, ‘filename’] . . .) }

[, {GROUP integer|(‘filename’[,‘filename’] . . .) } ] . . .

온라인 리두 로그 파일을 추가하고 삭제하는 것과 결과는 동등합니다. 하지만 위 명령은 로그 그룹이 두 개 뿐이며 각 그룹이 파일을 하나만 가지고 있어도 사용할 수 있으며 지워진 그룹이 아카이브되지 않아도 사용 가능합니다.

제한 사항
온라인 리두 로그 파일이 아카이브되어 있든 아니든 지울 수 있습니다. 하지만, 아카이브되어 있지 않을 때에는 UNARCHIVED 키워드를 넣어야만 합니다. 이렇게 하면 복구에 온라인 리두 로그 파일이 필요할 때 백업을 사용할 수 없게 만들 것입니다.

주
Oracle8: Backup and Recovery Workshop과정에서 자세히 다루어집니다.

온라인 리두 로그 파일 갯수
데이터베이스 인스턴스에 적당한 온라인 리두 로그 파일의 갯수를 결정하려면 다양한 구성을 시험해봐야 합니다.
어떤 경우에는 데이터베이스 인스턴스에 단 두 개의 그룹만 필요할 수도 있고, 어떤 경우에는 LGWR에 항상 사용 가능한 그룹을 보장하기 위해 추가 그룹이 필요할 수도 있습니다. 예를 들어 LGWR 추적 파일이나 ALERT 파일에 들어 있는 메시지에 체크포인트가 완료되지 않거나 그룹이 아카이브되지 않아 LGWR가 자주 그룹을 기다리고 있다는 것을 나타낸다면 그룹을 추가해야 합니다.
비록 오라클 서버가 다중화로된 그룹이 서로 다른 갯수의 멤버를 갖는 것을 허용하긴 하지만 대칭적인 구성을 하도록 하십시오. 비대칭적인 구성은 디스크 실패 같은 비정상적인 상황에서 임시로 생기는 것이어야만 합니다.

온라인 리두 로그 파일의 위치
온라인 리두 로그 파일을 다중화할 때 한 그룹의 멤버들을 서로 다른 디스크에 놓으십시오. 이렇게 하면 멤버 하나를 사용할 수 없더라도 다른 멤버를 사용할 수 있어 인스턴스가 종료되지 않습니다.
아카이브 로그 파일과 온라인 리두 로그 파일을 서로 다른 디스크로 분리시켜 ARCH와 LGWR 백그라운드 프로세스 간의 경합(contention)을 감소시키십시오.
데이터 파일과 온라인 리두 로그 파일은 반드시 다른 디스크에 위치시켜 LGWR와 DBWR 백그라운드 프로세스 간의 경합을 감소시키고 매체 실패(media failure)시 데이터 파일과 온라인 리두 로그 파일 모두를 잃는 위험을 감소시켜야 합니다.

온라인 리두 로그 파일 크기
온라인 리두 로그 파일의 최소 크기는 50K이고 최대 크기는 운영 체제에 따릅니다. 그룹이 다른 멤버 끼리는 서로 다른 크기를 가질 수 있습니다만, 그렇게 해봐야 별 이득이 없습니다.
서로 다른 크기의 그룹은 온라인 리두 로그 그룹 멤버의 크기를 변경하고자 할 때 같은 임시 결과로써나 존재해야만 합니다. 이 경우 다른 크기로 새 온라인 리두 로그 그룹을 생성하고 기존의 그룹을 제거해야 합니다.
다음 상황의 경우 온라인 리두 로그 파일의 구성에 영향을 줄 수도 있습니다.
   -로그 스위치와 체크포인트 횟수
   -리두 엔트리의 갯수와 총량
   -아카이브가 가능한 테이프 등의 저장 매체 상의 공간

LGWR는 특정 온라인 리두 로그 멤버가 사용 불가능할 때 여러 가지로 반응합니다.
- LGWR가 그룹 내의 최소한 한 개 멤버에 접근할 수 있다면 그룹의 접근 가능한 멤버에 쓰기는 정상으로 진행됩니다. 이 경우 LGWR는 그룹 내의 사용 불가능한 멤버는 무시    (ignore)합니다. 그룹이 활성화되어 있지 않다면, 즉, 체크    포인트가 완료되었다면 리두 로그 멤버를 삭제하고 새 리두 로그 멤버를 추가하면 문제가 해결될 것입니다. 그렇지 않으면 우선 로그 스위치를 실행해야 합니다.

- 로그 스위치 시 LGWR가 다음 그룹의 멤버 전부에 접근할 수 없다면 인스턴스는 종료됩니다. 그룹이 활성화되어 있지 않다면 그 그룹을 삭제하고 새 리두 로그 그룹을 추가하여 문제를    해결할 수 있습니다. 그렇지 않다면 데이터베이스는 잃어버린 온라인 리두 로그 파일때문에 매체 복구(media recovery)를 해야 할 것입니다.

   -LGWR가 갑자기 쓰여지고 있던 현재 그룹의 멤버 전부에 접근할 수 없다면 데이터베이스 인스턴스는 종료됩니다. 데이터베이스는 잃어버린 온라인 리두 로그 파일 때문에매체 복구를 해야 할 것입니다.

LogMiner 사용 목적

LogMiner는 리두 로그 파일을 처리하고 데이터베이스에서 수행되는 논리적 작업을 표현하는 SQL 문으로 리두 로그 파일의 내용을 번역하는 프로시저를 제공합니다.

Technical Note

LogMiner는 Oracle 릴리스 8.1 이후 버전에서 실행됩니다.

데이터베이스의 릴리스 8.0 이후 버전에서 리두 로그 파일을 분석할 수 있습니다.

LogMiner 사용 전 해야 할 작업

LogMiner는 데이터베이스의 마운트 여부에 상관없이 Oracle 인스턴스에서 실행됩니다. LogMiner는 딕셔너리 파일을 사용하며 이 딕셔너리 파일은 딕셔너리 파일을 생성한 데이터베이스와 생성 시간을 표시하는 특별한 파일입니다. 딕셔너리 파일은 필수적이지는 않지만 권장됩니다.

딕셔너리 파일을 사용하지 않으면 동등한 SQL문은 객체 이름으로 Oracle 내부 객체 ID를 사용하고 열 값을 16진수 데이터로 표시합니다.

딕셔너리 파일 생성

UTL_FILE_DIR 초기화 매개변수를 지정하여 PL/SQL 파일 I/O 용으로 사용할 수 있는 디렉토리를 지정합니다.
DBMS_LOGMNR_D.BUILD 프로시저를 실행하여 딕셔너리 파일을 생성합니다.

LogMiner 세션 설정

일단 딕셔너리 파일을 생성하면 리두 로그의 분석을 시작할 수 있습니다. 첫 번째 단계에서 DBMS_LOGMNR.ADD_LOGFILE 프로시저를 사용하여 분석하려는 로그 파일을 지정합니다.

다음 상수를 사용합니다.

DBMS_LOGMNR.NEW는 새 목록을 생성하고 첫 번째 로그 파일을 지정합니다.
DBMS_LOGMNR.ADDFILE은 추가된 로그 파일을 목록에 추가합니다.
DBMS_LOGMNR.REMOVEFILE은 목록에서 리두 로그를 삭제합니다.

LogMiner는 온라인 로그 파일 및 아카이브된 로그 파일을 모두 분석할 수 있습니다.

LogMiner 세션 시작

일단 딕셔너리 파일이 생성되고 리두 로그 목록이 지정되면 LogMiner를 시작하여 분석을 개시할 수 있습니다. 다음 옵션을 사용하여 시작 시 검색 범위를 축소합니다.

옵션	설명
StartScn	SCN(시스템 변경 번호) 범위 시작
EndScn	SCN 범위 종료
StartTime	시간 간격 시작
EndTime	시간 간격 끝
DictFileName	딕셔너리 파일 이름
옵션	logmnr.opt 파일에 지정된 열 맵을 사용하며 값은 USE_COLMAP입니다.

테이블 변경 사항 추적

V$LOGMNR_CONTENTS 뷰를 통해서 출력을 봅니다. 분석을 수행한 세션만 로그 정보를 볼 수 있으며 다른 세션은 로그 정보를 볼 수 없습니다. 다른 세션을 통해 결과를 보려면 로그 정보를 다른 테이블에 저장하는 것이 바람직합니다.

LogMiner 세션 중지

DBMS_LOGMNR.END_LOGMNR 프로시저를 실행하여 리두 로그를 분석하는 세션을 종료합니다.

데이터 딕셔너리 보기

일단 LogMiner가 시작되면 다음 데이터 딕셔너리 뷰를 사용할 수 있습니다.

뷰	설명
V$LOGMNR_DICTIONARY	사용 중인 딕셔너리 파일
V$LOGMNR_PARAMETERS	LogMiner에 대한 현재 매개변수 설정
V$LOGMNR_CONTENTS	분석 중인 리두 로그 파일 내용

Quick Quiz - ADM 7장

DB의 운영시 필요한 redo log group의 최소 갯수는?
A. 1개
B. 2개
C. 3개
D. 제한없다.
답
O
Redo Log Configuration을 고려할 때, 다음 중 적합한 것은?
A. I/O Contention을 줄이기 위하여, redo log member들을 모두 같은 디스크에 위치시킨다.
B. LGWR를 밤에만 기동하도록 한다.
C. 각 Redo log group에 Multiplexing을 한다.
D. 각 redo log member들의 크기를 다르게 한다.
답
O
Redo log fille에 대한 설명으로 적당하지 않은 것을 모두 고르시오.
A. redo log file의 위치를 relocate하려면 NOMOUNT단계에서 명령문을 실행해야 한다.
B. redo log file을 relocate하는 command는 다음과 같다. ALTER DATABASE RELOCATE FILE 'ORIGINAL_FILENAME' TO 'NEW_FILENAME';
C. redo log group에 member를 추가하는 command는 다음과 같다. ALTER DATABASE ADD LOGFILE MEMBER 'NEW_FILENAME' to GROUP 1;
D. Log Switch를 강제로 수행하려면 다음과 같은 command로 수행해야 한다. ALTER SYSTEM SWITCH LOGFILE;
답
X 정답:AB
Redo log group의 모든 member가 사용할 수 없게 되었을 때 발생하는 일은?
A. 인스턴스가 실패할 것이다.
B. 인스턴스는 계속 운영되나 media recovery가 필요하다.
C. 데이타베이스는 계속 open 상태이지만 instance recovery가 필요하다.
D. 시스템은 정상적으로 작동할 것이다.
답
O
체크포인트가 현재의 redo log group이 다 차기도 전에 너무 자주 일어난다. 현재 Log_checkpoint_interval과 log_checkpoint_timeout 파라미터 모두 0으로 지정되어 있다면 체크포인트 간격을 증가시키기 위해서 무엇을 해야하는가?
A. redo log group을 추가한다.
B. checkpoint timeout을 감소시킨다.
C. checkpoint internal을 증가시킨다.
D. 기존의 redo log group에 새로운 member를 추가한다.
답
X 정답:C