log buffer space

리두 버퍼에 리두 레코드를 기록하려는 프로세스는 리두 버퍼 내에 필요한 공간을 확보하기 위해 redo allocation 래치를 획득해야 합니다. redo allocation 래치를 획득한 상태에서 리두 버퍼에 공간을 확보하려는 순간에 적절한 여유공간이 없는 경우, 공간이 확보되기를 기다려야합니다. 이 때, 경우에 따라 두가지 종류의 이벤트를 대기하게 됩니다. 만일 현재 사용 중인 리두 로그 파일이 꽉 차서 더이상 여유 공간을 확보할수 없다면, LGWR 프로세스는 로그 파일 스위치를(log file swtich)를 수행하고, 서버 프로세스는 log file switch completion 이벤트를 대기합니다. 그외의 경우에는 log buffer space 이벤트를 대기하게 됩니다. 전자의 경우, 로그 파일 스위치가 끝난 직후 log buffer space 대기가 한번에 증가하는 현상이 생길 수 있습니다. 이는 리두 버퍼에 기록을 하려는 다수의 세션들이 로그 파일 스위치가 끝나기를 기다렸다가 한번에 리두 버퍼에 기록을 하기 위해 경쟁하기 때문입니다.

* Wait Time

일반적으로 1초를 대기하나 log file switch가 발생하는 경우 5초를 대기한다.

* Parameter

log buffer space 대기 이벤트는 대기 파라미터를 사용하지 않는다.

* Common Causes and Actions

 - 원인: 생성되는 리두의 양에 비해 로그버퍼의 크기가 작은 경우

 - 진단 방법: Redo Size 지표 모니터링 및 LOG_BUFFER 파라미터 Size 확인

 - 개선 방법: LOG_BUFFER 크기를 충분히 크게 한다.

Oracle Version에 따른 MView 사용과 Redo 발생량

10g 이상 버전에서 Materialized View(MView)의 Refresh 방식으로 COMPLETE를 사용한다면 DBMS_MVIEW.REFRESH Procedure 호출 Argument에 대한 확인이 필요합니다. COMPLETE 방식의 Refresh의 경우 데이터를 모두 삭제한 후 다시 쿼리한 데이터를 적재하는 방식으로 수행됩니다. 이때 데이터 삭제방법으로 10g 이하의 버전에서는 기본적으로 Delete가 아닌 Truncate 방식을 사용하면서 Redo 발생량을 억제하였습니다. 하지만 10g 버전에서부터 DBMS_MVIEW.REFRESH Procedure의 Argument 중 ATOMIC_REFRESH Argument의 Default값이 TRUE로 변경되면서 Default 값으로 Refresh를 수행할 경우, 데이터 삭제 Operation이 Delete 방식으로 수행되면서 Redo 발생량이 증가할 수 있습니다.

이에, COMPLETE 방식을 사용하는 MView에 대해서 Redo 발생과 관련된 문제를 경험한다면 ATOMIC_REFRESH Argument에 대한 확인이 필요합니다.

log file parallel write

log file parallel write 이벤트는 LGWR 프로세스에서만 발생하는 대기 이벤트입니다. LGWR 프로세스는 리두 버퍼의 내용을 리두 로그 파일에 기록하기 위해 필요한 I/O 콜을 수행한 후 I/O 작업이 완료되기를 기다리는 동안 log file parallel write 이벤트를 대기하게 됩니다.

만일 비동기식 I/O가 사용되는 환경에서 하나의 리두로그 그룹에 설정된 로그 멤버(member)가 두 개 이상이라면 병렬(parallel)로 기록합니다. 동기식 I/O가 사용된다면 각각의 로그 멤버에 대해서 순차적으로 기록합니다. 해당 이벤트는LGWR 프로세스의 정상적인 활동에서도 발생됩니다. 하지만 대기시간이 길다면 리두 로그파일이 위치한 디스크의 성능이 좋지 않거나 경합현상이 발생하고 있다고 볼 수 있습니다.

log file parallel write 대기는 I/O 관련 대기현상에서 다룬바 있는 db file parallel write 대기와 그 속성이 거의 유사합니다. 이 두 개의 대기는 근본적으로 I/O 시스템의 성능문제와 많은 관련이 있습니다. 여기에 성능문제를 바라보는 약간의 철학적 관점이 필요한데, 가령 이런 것입니다. I/O 시스템의 성능에는 문제가 없는데도 더티 버퍼의 양이 지나치게 많은 경우 db file parallel write 대기가 증가할 수 있습니다. 마찬가지로 I/O 시스템의 성능에는 아무런 이상징후가 없는데도 리두 데이터 양이 지나치게 많은 경우 log file parallel write 대기가 증가할 수 있습니다. 이 경우의 성능 문제는 지나치게 많은 데이터를 생성하는 애플리케이션의 문제인지, 아니면 더욱 빠른 속도로 데이터를 처리하지 못하는 I/O 시스템의 문제인지 알 수 없습니다. 이때, 일차적으로는 애플리케이션에서 문제와 해결책을 찾되, 더 이상의 해결책이 보이지 않을 때 I/O 시스템의 문제로 생각할 것을 권유합니다. 특히 경제적인 관점에서라도 이 방법을 따를 필요가 있습니다.

* Wait Time

모든 I/O 요청이 완료될 때까지 소요된 실질적인 시간을 나타낸다. 비동기식 I/O의 경우 병렬로 기록될 수 있지만, 마지막 I/O 수행이 완료될 때까지는 완료된 것이 아니기 때문이다.

* Parameter

P1(File Count(member count)), P2(Block count(redo log block count)), P3(I/O requests)

* Common Causes and Actions

 - 원인: Redo Log File이 위치한 File System의 I/O 성능에 문제가 있다.

 - 진단 방법: 쓰기 성능 관련 지표 확인(redo writes/redo blocks written/redo write time)

 - 개선 방법

: Redo Log Member를 Disk I/O 성능이 좋은 곳으로 옮긴다.

: RAID 5 구성 같은 경우 I/O 성능에 적합하지 않은 경우가 많다.

 - 원인: Redo 발생량이 많다.

 - 진단 방법: 발생량 관련 지표 확인 (redo size / redo entries)

 - 개선 방법

: Tablespace가 Hot Backup 상태가 아닌지 확인한다.

: Redo 발생량을 줄이기 위한 NOLOGGING / UNRECOVERABLE 옵션을 고려한다.

Redo

REDO는 오라클 SGA에 있는 Redo Buffer와 Redo Log File로 이루어져 있는데 이는 Database의 복구를 목적으로 하고 있습니다. 이 REDO는 Database에 적용된 모든 변경사항에 대한 이력을 저장합니다. 여기에 포함되는 정보는 DML, DDL, Recursive SQL에 의해 변경된 모든 Data의 이력들이며 DDL의 경우는 SQL Text도 저장됩니다. 그러나 NOLOGGIG Option을 부여한 상태에서의 Data 변경 이력과 DML SQL Text는 저장되지 않습니다.

Redo Log File은 Redo Buffer의 내용을 그대로 저장하게 되는데 이 작업은 LGWR 프로세스에 의해 이루어집니다. Redo Buffer의 내용이 Redo Log File에 기록하는 시점은 보통 4가지 경우입니다.

첫번째는 매 3초마다 자동적으로 기록되고, 두번째는 _LOG_IO_SIZE의 설정 값에 이르렀을 때입니다. 이 히든 파라미터는 Redo Buffer의 사이즈에 의해 자동으로 설정되는데 보통 LOG_BUFFER의 1/3 또는 1MB로 설정됩니다. 세번째는 사용자의 Commit 또는 Rollback이라는 명시적인 명령에 의해 강제적으로 기록되는 경우인데 이를 Log Force at Commit으로 부르는 경우도 있습니다. 이 경우 해당 Transaction과 관계된 모든 Redo 정보를 Log File에 저장하고 나서 Commit을 완료하게 됩니다. 마지막으로 DBWR 프로세스에 의해 신호를 받았을 경우입니다. 이 경우 Write Ahead Log라고도 하는데 DBWR 프로세스가 Data Buffer Block을 Disk로 기록하기 전에 Redo Buffer Log를 먼저 기록하기 때문에 발생하는 경우입니다. 

Redo의 쓰기 성능

select 	round((a.value/b.value) + 0.5, 0) as avg_redo_blks_per_write,
	round((a.value/b.value) + 0.5, 0) * c.lebsz as avg_io_size
from 	v$sysstat a,
	v$sysstat b,
	x$kccle c
where	c.lenum = 1
and	a.name = 'redo blocks written'
and	b.name = 'redo writes';

Redo의 쓰기 성능을 판별하기 위한 지표로는 Redo Writes와 Redo Blocks Written이 존재합니다. 위 스크립트는 두 Statistics의 지표와 Redo Block 단위(대부분 512B)를 이용하여 1회 쓰기에 몇 블록을 처리하였는지 확인할 수 있으며, 이를 이용하여 Redo File이 존재하는 디스크의 쓰기 성능을 확인할 수 있습니다.

log file switch completion

서버 프로세스가 리두 버퍼에 리두 레코드를 기록하려는 시점에 리두 로그 파일이 꽉 차서 더이상 쓰기를 할 수 없으면 프로세스는 LGWR 프로세스에게 로그 파일 스위치를 수행할 것을 요청합니다. 서버 프로세는 LGWR 프로세스에 의해 로그 파일 스위치가 끝날때까지 log file switch completion 이벤트를 대기하게 됩니다.

해당 대기 이벤트의 발생 원인은 트랜잭션이 생성하는 리두 데이터의 양에 비해 리두 로그 파일의 크기가 지나치게 작다는 것입니다. 따라서 해결책은 리두 로그 파일의 크기를 충분히 키워주는 것입니다. 더불어 Direct Load Operation이나 Nologging 옵션을 사용하여 리두 데이터의 양을 줄이는 것도 도움이 됩니다.

* Wait Time

1초

* Parameter

log file switch completion 대기 이벤트는 대기 파라미터를 사용하지 않는다.

* Common Causes and Actions

 - 원인: 생성되는 리두의 양에 비해 로그버퍼의 크기가 작은 경우

 - 진단 방법: Redo Size 지표 모니터링 및 LOG_BUFFER 파라미터 Size 확인

 - 개선 방법: 로그 버퍼의 크기를 충분히 크게 한다.

log file switch completion 관련 event

로그 파일 스위치가 끝나느 시점에, 새로 사용할 리두 로그 파일에 대해 아직 종료되지 않은 작업이 이싿면, 아래와 같이 추가적으로 이벤트를 대기해야 합니다. 새로 사용할 리두 로그 파일에 대한 체크 포인트 작업이 아직 끝나지 않았다면 프로세스는 DBWR 프로세스에 의해 체크 포인트가 끝나기를 기다려야 합니다. 이 경우 프로세스는 log file switch(checkpoint incomplete) 이벤트를 대기하게 됩니다.

새로 사용할 리두 로그 파일에 대해 아카이브(Archive) 작업이 아직 끝나지 않았다면 프로세스는 ARCH 프로세스에 의해 아카이브 작업이 끝나기를 기다려야 합니다. 이 경우 프로세스는 log file switch(archiving needed) 이벤트를 대기하게 됩니다. 이 이벤트는 아카이브 모드의 데이터베이스에서만 발생합니다.

새로 사용할 리두 로그 파일에 대해 Private Strands에 대한 플러쉬(flush) 작업이 아직 끝나지 않았다면 이 작업이 끝나기를 기다려야 합니다. 이 경우 프로세스는 log file switch(private strand flush incomplete) 이벤트를 대기하게 됩니다. 이 이벤트는 오라클 10g R2에서 추가된 것이며, Private redo strands 기능을 사용할 경우에만 발생합니다.

위의 3가지 대기현상은 리두 로그 파일이 순환적으로(Circular) 사용되는 상황에서, 아주 많은 리두 데이터가 생성되기 때문에 이전 작업을 다 끝내기도 전에 다시 재사용할 경우에 발생하게 됩니다. 따라서 이들은 log file switch completion 대기현상과 항상 같이 나타납니다. 정확하게 말하면, 서버 프로세스는 먼저 log file switch completion 이벤트를 대기하고 특수한 경우 다시 log file switch(checkpoint incomplete)나 log file switch(archiving needed), log file switch(private strand flush incomplete) 이벤트를 대기하게 됩니다.

log file sync

사용자가 Commit 또는 Rollback 명령을 요청하면 Server Process는 LGWR 프로세스에게 요청을 전달합니다. LGWR 프로세스는 Redo Buffer에서 가장 마지막에 기록이 이루어진 이후 시점부터 Commit 지점까지의 모든 Redo Entry를 Redo Log File에 기록합니다. 이것을 "sync write"라고 부르며 redo sync writes 통계값을 통해 조회 가능합니다. Server process는 Commit 명령을 내린 후 LGWR 프로세스가 성공적으로 기록할 때까지 기다리게 되는데, 이때 log file sync 이벤트를 대기하게 됩니다.

다시 말해 로그 동기화(log synchronization)를 수행하는 동안, LGWR 프로세스는 "sync write"가 완료할 때까지 log file parallel write 대기 이벤트를 대기하게 되고, Server Process는 log file sync 대기 이벤트를 대기하는 것입니다.

Server Process는 2가지 이유로 인해 log file sync 대기 이벤트를 겪게 됩니다. 하나는 로그 동기화가 완료되기를 대기하는 것입니다. 다른 하나는 대기가 타임아웃(일반적으로 1초)되는 경우입니다. 타임아웃이 발생하면 Server Process는 Commit 정보가 디스크에 기록되었는지를 확인하기 위해 현재 로그 SCN(System Change Number)을 확인합니다. 만일 Commit 정보가 디스크에 기록되었다면 대기를 그만두고 작업을 진행하며, 그렇지 않을 경우 계속 log file sync 대기 이벤트를 지속하게 됩니다.

만일 세션이 동일한 buffer#를 대기한다면 V$SESSION_WAIT의 SEQ# 칼럼의 값은 매초마다 증가합니다. SEQ# 컬럼의 값이 증가할 경우의 블로킹 프로세스는 LGWR입니다. 이러한 경우 LGWR 프로세스가 다른 이유로 인해 대기 중인지를 확인해야 합니다.

일반적으로, log file sync는 매우 평범한 대기 이벤트입니다. 사용자가 인식하기 힘든만큼 매우 단시간에 발생합니다. 하지만, log file sync 대기 이벤트의 과다 현상은 응답시간을 상당히 지연시키게 되며, V$SYSTEM_EVENT 및 V$SESSION_EVENT 뷰에서 눈에 띌만한 대기통계정보를 나타내게 됩니다.

* Wait time

  1초

* Parameter

P1(buffer#), P2(sync scn)

* Common Causes and Actions 

 - 원인: 과다한 Commit 횟수

 - 진단방법: User Commit 지표 확인 및 소스 내 Commit 수행 위치 확인

 - 개선 방법: 만일 세션이 배치 프로세스라면, 루프 내에서 반복적으로 Commit을 수행할 수 있습니다. 이 경우 모듈의 이름을 확인한 후 Commit의 횟수를 줄일 수 있는지를 점검하기 위해서 개발자에게 코드를 점검합니다.

 - 원인: I/O 시스템의 성능 저하

 - 진단 방법: LGWR 프로세스가 log file parallel write이벤트를 대기하는 평균시간이 높거나 전체 시스템에서 대기시간 대비 차지하는 비중이 높다면 Redo Log File이 위치한 I/O 시스템의 성능에 문제가 있다고 파악

 - 개선 방법: Redo Log File을 가장 빠른 디바이스에 위치시킵니다. 그리고 디스크 경합을 피ㅏ하기 위해 서로 다른 그룹의 Redo Log File은 서로 다른 디스크에 분산시켜야 합니다. Redo Log File을 데이터 파일이나 컨트롤 파일과 다른 디스크에 배치시키는 것 또한 필요합니다.

 - 원인: 불필요한 Redo 데이터 생성

 - 진단 방법: Redo Size 지표 모니터링 및 LOG_BUFFER 파라미터 Size 확인

 - 개선 방법

: Direct load 기능과 Create ..., Alter .. 류의 작업들은 대부분 Nologging 옵션을 제공합니다. 이런 기능들을 잘 활용하면 Redo 데이터의 양을 극적으로 줄일 수 있습니다. 

: SQL*Loader로 대량의 데이터를 적재시 Direct load option을 사용

: 임시 작업이 필요할 때는 임시 테이블(Temporary Table)을 사용
: 인덱스가 있는 테이블에 대해 Direct load 작업을 수행시 인덱스를 Unusable 상태로 변경하여 작업

: LOB 데이터의 경우 데이터의 크기가 크다면 가급적 Nologging 속성을 부여

 - 원인: Redo Buffer가 지나치게 크게 설정된 경우

 - 진단 방법: Redo Size 지표 모니터링 및 LOG_BUFFER 파라미터 Size 확인

 - 개선 방법

: Redo Buffer는 background writes 횟수를 감소시키고, LGWR 프로세스의 활동성을 낮추게 되므로 Redo Buffer에는 많은 양의 Redo Entry가 저장되는 현상을 야기시킵니다. 프로세스가 Commit을 수행할 때, LGWR 프로세스는 더 많은 양의 Redo Entry를 디스크에 기록해야 하므로, sync write 시간은 더 오래 소요되고 서버 프로세스는 log file sync 대기 이벤트를 경험하게 되므로 로그 버퍼 사이즈를 작게 변경합니다.

Sequence와 log file sync

Sequence를 생성할 때 NOCACHE 옵션을 주는 경우가 종종 있습니다. NOCACHE 속성의 시퀀스는 많은 성능 문제를 야기하는데 대표적인 경우가 row cache lock 대기를 증가시키는 것입니다. 재미있게도, NOCACHE 속성의 Sequence는 log file sync 대기를 유발하는 원인이 될수도 있습니다. NOCACHE 속성의 Sequence에 대해서 Sequence.nextval을 호출하면 매번 Dictionary 테이블의 정보를 갱신하고 commit을 수행해야 하기 때문입니다. Sequence를 사용할 때는 Transaction의 양을 고려하여 반드시 적절한 크기의 CACHE 속성을 부여해야 합니다.

PROCESS Parameter와 log file sync

PROCESSES 파라미터 수치를 크게 설정할 경우 log file sync 대기현상이 증가하게 됩니다. 모든 동기화 작업(sync operation)동안, LGWR 프로세스는 어떠한 세션들이 해당 이벤트를 대기하고 있고 어떠한 세션의 Redo를 디스크로 기록해야 하는지 확인하기 위해서 프로세스의 데이터 스트럭처를 스캔해야 합니다. PROCESSES 파라이커 수치를 작게 설정할 경우 log file sync 대기현상을 감소시키는데 도움이 됩니다. 적정한 값을 알기 위해서는 V$RESOURCE_LIMIT 뷰를 사용하면 도비니다.

출처: https://12bme.tistory.com/320?category=749950 [길은 가면, 뒤에 있다.]

출처: https://enterone.tistory.com/293 [Lifelong Study:티스토리]

이 활동에서는 GoldenGate 소프트웨어가 이미 설치되어 있다고 가정합니다.

우리는 다음 서버에서 스키마 HR을 복제할 예정입니다.

PDB로 작업하고 있으므로 INTEGRATED 엑스트라를 사용해야 한다는 점에 유의하세요.

이 활동을 구현하는 단계는 다음과 같습니다.

1:- 초기 로드/대상 DB로 데이터 가져오기:

EXPORT:
  
  [oracle@RACnode1 ~]$ mkdir /tmp/EXPORT
  [oracle@RACnode1 ~]$ chown oracle:oinstall /tmp/EXPORT
  [oracle@RACnode1 ~]$ 
    
  SQL> alter session set container=CDB19C_PDB;
  Session altered.
  SQL> create or replace directory HR_SYNC  as '/tmp/EXPORT';
  Directory created.
   
  
  [oracle@RACnode1 ~]$ cd /tmp/EXPORT
  [oracle@RACnode1 EXPORT]$ vi expdp_script.sh
  [oracle@RACnode1 EXPORT]$ ls -tlr 
  total 4
  -rw-r--r--. 1 oracle oinstall 236 Oct  1 10:11 expdp_script.sh
  [oracle@RACnode1 EXPORT]$ chmod 744 expdp_script.sh 
  [oracle@RACnode1 EXPORT]$ cat expdp_script.sh
  #!/bin/bash
  
  SYS_PWD=Pas5w0rd
  export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
  nohup $ORACLE_HOME/bin/expdp \"sys/$SYS_PWD@CDB19C_PDB as sysdba\" directory=HR_SYNC dumpfile=HR_%U.dmp logfile=HR_EXPORT.log cluster=NO schemas=HR &
  [oracle@RACnode1 EXPORT]$ 
  
  
  Make sure pdb is pingable and set in tnsnames.ora:
  
  [or acle@RACnode1 EXPORT]$ tnsping cdb19c_pdb  
  ... 
  Use d TNSNAMES adapter to resolve the alias  
  Attempting to contact (DESCRIPTION = (ADDR  ESS = (PROTOCOL = TCP)(HOST = racnode1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME =  CDB19C_PDB)))  
  OK (10 msec)
  [oracle@RACnode1 EXPORT]$ 
  
  [oracle@RACnode1 EXPORT]$ ./expdp_script.sh 
  
  [oracle@RACnode1 EXPORT]$ tail  HR_EXPORT.log
  . . exported "HR"."JOB_HISTORY"                          7.195 KB      10 rows
  . . exported "HR"."JOBS"                                 7.109 KB      19 rows
  . . exported "HR"."DEPARTMENTS"                          7.125 KB      27 rows
  . . exported "HR"."COUNTRIES"                            6.367 KB      25 rows
  . . exported "HR"."REGIONS"                              5.546 KB       4 rows
  Master table "SYS"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
  ******************************************************************************
  Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:
    /tmp/EXPORT/HR_01.dmp
  Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at Fri Oct 1 10:39:48 2021 elapsed 0 00:04:12
  [oracle@RACnode1 EXPORT]$ 
  
IMPORT:

  [oracle@standbyracnode ~]$ mkdir /tmp/IMPORT
  [oracle@standbyracnode ~]$ 
  
  [oracle@RACnode1 EXPORT]$ scp -p HR_01.dmp oracle@standbyracnode:/tmp/IMPORT  
  oracle@standbyracnode's password:   
  HR_01.dmp                                                                                                                                                                             100%  716KB  32.3MB/s   00:00    
  [oracle@RACnode1 EXPORT]$ 
  
  SQL> create or replace directory HR_SYNC  as '/tmp/IMPORT';
  Directory created.
  SQL> 
  
  
  [oracle@standbyracnode IMPORT]$ cat import_script.sh 
  #!/bin/bash
  
  SYS_PWD=Pas5w0rd
  export ORACLE_HOME=/u01/app/oracle/product/19c/db_1
  nohup $ORACLE_HOME/bin/impdp \"sys/$SYS_PWD@DEVDB_NONCDB as sysdba\" directory=HR_SYNC dumpfile=HR_%U.dmp logfile=HR_IMPORt.log cluster=NO schemas=HR &
  [oracle@standbyracnode IMPORT]$ 
  
  
  [oracle@standbyracnode IMPORT]$ ./import_script.sh 
  
  [oracle@standbyracnode IMPORT]$ tail HR_IMPORt.log
  Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
  Processing object type SCHEMA_EXPORT/VIEW/VIEW
  Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
  Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
  Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
  Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
  Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
  Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
  Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
  Job "SYS"."SYS_IMPORT_SCHEMA_01" completed with 1 error(s) at Fri Oct 1 13:51:55 2021 elapsed 0 00:02:03
  [oracle@standbyracnode IMPORT]$ 
  
  **ERROR for HR schema already exist, can be ignored

2:- 소스 DB 준비:

Enable minimal supplemental logging:

	SQL> ALTER DATABASE FORCE LOGGING;
	Database altered.
	SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
	Database altered.
	SQL> ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH;
	System altered.
	SQL> 
	SQL> alter session set container=CDB19C_PDB;

	Session altered.
	SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
	Database altered.
	SQL> 
	

Create common user:

	SQL> CREATE USER c##ggadmin IDENTIFIED BY ggadmin
	DEFAULT TABLESPACE users
	QUOTA UNLIMITED ON users;  
	User created.
	SQL> GRANT DBA to c##ggadmin CONTAINER=ALL;
	Grant succeeded.
	SQL>  exec dbms_goldengate_auth.grant_admin_privilege( grantee => 'c##ggadmin',container => 'ALL');
	PL/SQL procedure successfully completed.
	SQL> 

3:- 타겟 DB 준비:

Enable RDBMS to be used by GoldenGate:

	SQL>  ALTER SYSTEM SET enable_goldengate_replication=TRUE SCOPE=BOTH;
	System altered.

Create common user:
	
	SQL> CREATE USER ggadmin IDENTIFIED BY ggadmin
	DEFAULT TABLESPACE users
	QUOTA UNLIMITED ON users;
	User created.
	SQL> GRANT DBA TO ggadmin;
	Grant succeeded.
	SQL> EXEC dbms_goldengate_auth.grant_admin_privilege('ggadmin');
	PL/SQL procedure successfully completed.
	SQL> 

4:- 소스에서 GoldenGate 준비:

Configure Manager parameter:

	GGSCI (RACnode1.localdomain) 1> EDIT PARAM mgr


	PORT 7809
	PURGEOLDEXTRACTS ./dirdat/et* , USECHECKPOINTS, MINKEEPHOURS 72
	AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
	DOWNREPORTMINUTES 15
	LAGCRITICALSECONDS 10
	LAGINFOMINUTES 0
	LAGREPORTMINUTES 15
	ACCESSRULE, PROG *, IPADDR 192.168.24.3, ALLOW

Create credentialstore: 

	GGSCI (RACnode1.localdomain) 5> add credentialstore
	Credential store created.
	GGSCI (RACnode1.localdomain) 6> alter credentialstore add user c##ggadmin@192.168.24.1:1521/cdb19c alias cdb19c
	Password: 
	Credential store altered.
	GGSCI (RACnode1.localdomain) 7> info credentialstore
	Reading from credential store:
	Default domain: OracleGoldenGate
  		Alias: cdb19c
  		Userid: c##ggadmin@192.168.24.1:1521/cdb19c
	GGSCI (RACnode1.localdomain) 8> 
	GGSCI (RACnode1.localdomain) 8> dblogin USERIDALIAS cdb19c
	Successfully logged into database CDB$ROOT.


Configure EXTRACT parameter file:

	GGSCI (RACnode1.localdomain) 2> EDIT PARAM exthr
	
	
	EXTRACT exthr
	SETENV (ORACLE_SID='CDB19C_PDB')
	SETENV (ORACLE_HOME = '/u01/app/oracle/product/19c/dbhome_1')
	DISCARDFILE ./dirrpt/exthr.dsc, APPEND
	EXTTRAIL ./dirdat/et
	--- User login
	USERIDALIAS cdb19c
	--- DDL Parameters
	LOGALLSUPCOLS
	DDL INCLUDE MAPPED
	DDLOPTIONS REPORT
        SOURCECATALOG CDB19C_PDB
	TABLE HR.* ;


Configure EXTRACT PUMP parameter file:
	GSCI (xtivia12) 3> EDIT PARAM ephr
	
	EXTRACT ephr
	RMTHOST 192.168.24.3, MGRPORT 7809
	PASSTHRU
	RMTTRAIL ./dirdat/rt
        SOURCECATALOG CDB19C_PDB
	TABLE HR.* ;


Create EXTRACT group, EXTRAIL, PUMP AND RMTTRAIL:

	GGSCI (RACnode1.localdomain) 17> ADD EXTRACT exthr, INTEGRATED TRANLOG, BEGIN NOW
	EXTRACT (Integrated) added.
		GGSCI (RACnode1.localdomain) 18> ADD EXTTRAIL ./dirdat/et, EXTRACT exthr, MEGABYTES 5
	EXTTRAIL added.
		GGSCI (RACnode1.localdomain) 19> ADD RMTTRAIL ./dirdat/rt, EXTRACT exthr, MEGABYTES 5 
		RMTTRAIL added.
	GGSCI (RACnode1.localdomain) 20> ADD EXTRACT ephr, EXTTRAILSOURCE ./dirdat/et
		EXTRACT added.
        GGSCI (RACnode1.localdomain) 21> ADD RMTTRAIL ./dirdat/rt, EXTRACT ephr, MEGABYTES 5 
                RMTTRAIL added.

 	
	GGSCI (RACnode1.localdomain) 22> info all
	
	Program     Status      Group       Lag at Chkpt  Time Since Chkpt
	
	MANAGER     RUNNING                          
	EXTRACT     STOPPED     EPHR        00:00:00      00:00:07    
	EXTRACT     STOPPED     EXTHR       00:00:00      00:00:15    
	
	GGSCI (RACnode1.localdomain) 22> 


Register EXTRACT in DB:

	GGSCI (RACnode1.localdomain) 10> dblogin userid c##ggadmin, password ggadmin
	Successfully logged into database CDB$ROOT.
	GGSCI (RACnode1.localdomain as c##ggadmin@cdb19c1/CDB$ROOT) 11> register extract exthr database container (CDB19C_PDB)
	2021-10-01 16:20:35  INFO    OGG-02003  Extract EXTHR successfully registered with database at SCN 2985612.
	GGSCI (RACnode1.localdomain as c##ggadmin@cdb19c1/CDB$ROOT) 12> 

5:- 대상에서 GoldenGate 준비:

Configure Manager parameter:

	GGSCI (standbyracnode.localdomain) 2> EDIT PARAM mgr
		
	PORT 7809
	PURGEOLDEXTRACTS ./dirdat/rt* , USECHECKPOINTS, MINKEEPHOURS 72
	AUTORESTART ER *, RETRIES 3, WAITMINUTES 5, RESETMINUTES 60
	DOWNREPORTMINUTES 15
	LAGCRITICALSECONDS 10
	LAGINFOMINUTES 0
	LAGREPORTMINUTES 15
	ACCESSRULE, PROG *, IPADDR 192.168.24.3, ALLOW
	ACCESSRULE, PROG *, IPADDR 192.168.24.1, ALLOW 

Create credentialstore:
	
	GGSCI (standbyracnode.localdomain) 3> add credentialstore
	Credential store created.
	GGSCI (standbyracnode.localdomain) 5> alter credentialstore add user ggadmin@DEVDBNONCDB alias DEVDBNONCDB
	Password: 
	Credential store altered.
	GGSCI (standbyracnode.localdomain) 5> info credentialstore
	Reading from credential store:
	Default domain: OracleGoldenGate
	  Alias: DEVDBNONCDB
	  Userid: ggadmin@DEVDBNONCDB
	GGSCI (standbyracnode.localdomain) 6> 
	
	GGSCI (standbyracnode.localdomain) 7> dblogin USERIDALIAS DEVDBNONCDB
	Successfully logged into database.

Configure REPLICAT parameter file:

	GGSCI (standbyracnode.localdomain) 2> EDIT PARAM rephr

	REPLICAT rephr
	DISCARDFILE ./dirrpt/rephr.dsc, APPEND
	DBOPTIONS ENABLE_INSTANTIATION_FILTERING
	ASSUMETARGETDEFS
	--- User login
	USERIDALIAS DEVDBNONCDB
	DDL INCLUDE ALL
	DDLOPTIONS REPORT
	MAP CDB19C_PDB.HR.*, TARGET HR.*;


Create REPLICAT group and Trail Files:

	GGSCI (standbyracnode.localdomain) 3> dblogin USERIDALIAS DEVDBNONCDB
	Successfully logged into database.
	GGSCI (standbyracnode.localdomain as ggadmin@devdbnoncdb) 4> ADD CHECKPOINTTABLE ggadmin.chktbl
	Successfully created checkpoint table ggadmin.chktbl.
	GGSCI (standbyracnode.localdomain as ggadmin@devdbnoncdb) 5> ADD REPLICAT rephr, INTEGRATED, EXTTRAIL ./dirdat/rt, CHECKPOINTTABLE ggadmin.chktbl
	    REPLICAT (Integrated) added.
        GGSCI (standbyracnode.localdomain as ggadmin@devdbnoncdb) 9> info all

        Program     Status      Group       Lag at Chkpt  Time Since Chkpt

        MANAGER     RUNNING                                           
        REPLICAT    STOPPED     REPHR       00:00:00      00:00:03    

        GGSCI (standbyracnode.localdomain as ggadmin@devdbnoncdb) 10> 

6:- 추출 시작:

Restart Manager (since we edited parameter)

	GGSCI (RACnode1.localdomain) 1> stop mgr
	Manager process is required by other GGS processes.
	Are you sure you want to stop it (y/n)?y
	
	Sending STOP request to MANAGER ...
	Request processed.
	Manager stopped.
	GGSCI (RACnode1.localdomain) 2> start mgr
	Manager started.


Start EXTRACT and PUMP:

	GGSCI (RACnode1.localdomain) 3> start extract exthr
	Sending START request to MANAGER ...
	EXTRACT EXTHR starting
	GGSCI (RACnode1.localdomain) 4> start extract ephr
	Sending START request to MANAGER ...
	EXTRACT EPHR starting
	
	
	GGSCI (RACnode1.localdomain) 5> info all
	Program     Status      Group       Lag at Chkpt  Time Since Chkpt
	MANAGER     RUNNING                                           
	EXTRACT     RUNNING     EPHR        00:00:00      00:00:34    
	EXTRACT     RUNNING     EXTHR       00:00:00      00:00:27    
	GGSCI (RACnode1.localdomain) 6> 

7:- REPLICAT 시작:

Restart Manager (since we edited parameter):

	GGSCI (standbyracnode.localdomain) 1> stop mgr
	Manager process is required by other GGS processes.
	Are you sure you want to stop it (y/n)?y
	Sending STOP request to MANAGER ...
	Request processed.
	Manager stopped.
	GGSCI (standbyracnode.localdomain) 2> start mgr
	Manager started.

Start REPLICAT:

	GGSCI (standbyracnode.localdomain) 3> start replicat REPHR
	Sending START request to MANAGER ...
	REPLICAT REPHR starting
	GGSCI (standbyracnode.localdomain) 4> info all
	Program     Status      Group       Lag at Chkpt  Time Since Chkpt
	MANAGER     RUNNING                                           
	REPLICAT    RUNNING     REPHR       00:00:00      00:00:10    
	GGSCI (standbyracnode.localdomain) 5> 

테스트:

1:- 삽입:

Source DB prev. State:

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 cdb19c1
	
	SQL> alter session set container=CDB19C_PDB;
	Session altered.
	SQL> select count(*) from HR.jobs;
	  COUNT(*)
	----------
		19
	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';
	no rows selected

Target DB prev. State:

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 devdbnoncdb
	
	SQL> select count(*) from HR.jobs;
	  COUNT(*)
	----------
		19
	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';
	no rows selected


Insert on SOURCE DB:

	SQL> show con_name
	CON_NAME
	------------------------------
	CDB19C_PDB
	
	SQL> INSERT INTO HR.jobs
	(JOB_ID, JOB_TITLE, MIN_SALARY, MAX_SALARY )
	VALUES
	('DB_MAN', 'DBA Administrator',40000,70000);  
	
	1 row created.
	
	SQL> commit;
	Commit complete.


REPLICATED in target DB??

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 devdbnoncdb

	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';
	
	JOB_ID	   JOB_TITLE			       MIN_SALARY MAX_SALARY
	---------- ----------------------------------- ---------- ----------
	DB_MAN	   DBA Administrator			    40000      70000

	SQL> select count(*) from HR.jobs;
	  COUNT(*)
	----------
	 	20

2:- 삭제:

Source DB prev. State:


	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 cdb19c1
	
	SQL> alter session set container=CDB19C_PDB;
	Session altered.
	SQL> select count(*) from HR.jobs;
	  COUNT(*)
	----------
			20
	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';

	JOB_ID	   JOB_TITLE			       MIN_SALARY MAX_SALARY
	---------- ----------------------------------- ---------- ----------
	DB_MAN	   DBA Administrator			    40000      70000


Target DB prev. State:

	SQL> show parameter instance_name
	
	NAME				     TYPE	 VALUE
	------------------------------------ ----------- ------------------------------
	instance_name			     string	 devdbnoncdb
	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';
	
	JOB_ID	   JOB_TITLE			       MIN_SALARY MAX_SALARY
	---------- ----------------------------------- ---------- ----------
	DB_MAN	   DBA Administrator			    40000      70000
	
	SQL> select count(*) from HR.jobs;
	
	  COUNT(*)
	----------
		20
	
Delete on Source DB:

	SQL> delete from HR.JOBS where JOB_TITLE like '%DBA%';
	1 row deleted.
	SQL> commit;
	Commit complete.
	SQL> 

REPLICATED on target DB??

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 devdbnoncdb

	SQL> select * from HR.jobs where JOB_TITLE like '%DBA%';
	no rows selected
	SQL> select count(*) from HR.jobs;

  	COUNT(*)
	----------
	        19

3:- DDL:

Source DB prev. State:

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 cdb19c1
	
	SQL> alter session set container=CDB19C_PDB;
	Session altered.

	SQL> desc HR.TEST
	ERROR:
	ORA-04043: object HR.TEST does not exist

Target DB prev. State:

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 devdbnoncdb

	SQL> desc HR.TEST
	ERROR:
	ORA-04043: object HR.TEST does not exist

Create table in Source:

	SQL>  CREATE TABLE HR.TEST
	( test_id            NUMBER PRIMARY KEY,
	  test__name          VARCHAR2(30) );  2    3  
	
	Table created.
	
	SQL> desc HR.TEST
	 Name					   Null?    Type
	 ------------------------- -------- ---------------------
	 TEST_ID				   NOT NULL NUMBER
	 TEST__NAME					        VARCHAR2(30)

REPLICATED on target DB??

	SQL> show parameter instance_name
	NAME				     TYPE	 VALUE
	------------------------ ------- ----------------------
	instance_name		     string	 devdbnoncdb
	SQL> desc HR.TEST
	 Name					   Null?    Type
	 ------------------------- -------- ---------------------
	 TEST_ID				   NOT NULL NUMBER
	 TEST__NAME					        VARCHAR2(30)

그리고 짜잔! 우리는 지금 GoldenGate를 가동하고 있습니다!

LISTENER.ORA, TNSNAMES.ORA 생성하기

. 사전 용어

본문을 읽기전에 본문에서 표현된 "정합성이 깨졌다","손상되었다." 라는 뜻은 아래 내용과 같다.

오라클의 블럭단위 : 8KB
OS의 블럭단위 : 4KB

# 오라클의 Datafile을 OS의 cp 명령으로 원하는 장소에 복사하는 상황이 있다 가정하자.
[1] OS에서 cp명령으로 Oracle datafile을 원하는 특정장소에 복사를 수행하려한다.
[2] cp 명령이 수행될때 OS의 블럭단위는 4KB이기 때문에 오라클의 Datafile을 cp할때, 4KB씩 복사할것이다.
[3] cp 명령이 수행되며 특정 A라는 Oracle 8KB짜리 블럭을 복사한다 가정한다.
[4] A라는 Oracle 8KB짜리 블럭이 OS에 의해 4KB로 쪼개져 전체 4KB블럭 두개중(4KB*2=8KB) 앞에 하나의 블럭만
    복사가 수행됬다.
[5] 그 다음 4KB블럭 두개중 나머지 마지막 4KB블럭을 복사하려던 참에, 마침 Oracle 사용자가 쿼리를 입력하였고,
    해당쿼리로 인해 마지막 4KB블럭안에 있는 데이터가 변경이 되었다.
[6] Oracle 사용자가 입력한 쿼리로 인해 데이터 변경이 일어난 다음, OS가 4KB블럭 두개중 뒤의 나머지 하나의
    블럭을 복사하였다.
[7] Oracle의 입장에서는 Block단위는 8KB이며, OS의 4KB단위의 블럭이 2개가 합해진 8KB를 하나의 블럭으로
    인식한다.

위의 [1]~[6] 과정에서 오라클 8KB전체 블럭중 앞에 복사된 4KB블럭과 변경이 가해진후 복사된 4KB블럭은
Oracle입장에서 서로 하나의 블럭으로써 합해져 취급되는데 각 4KB블럭마다 담겨져 있는 Data의 시간대가 일치하지
않게된다. 이를 아래 본문에서, "정합성이 깨졌다","손상되었다"라고 표현할 예정이다.

2. 잘못된 상식

아래글은 많은 사람들이 알고 있는 잘못된 상식을 작성한 글이다.

BEGIN BACKUP을 수행도중 Database에 들어오는 DML 쿼리에 대해 데이터들이 변경이 가해졌고,
COMMIT이나 CHECKPOINT가 발생할 때, 변경된 내용들은 Datafile의 Data block에 적용되지 않고,
REDO LOG나 Archive 파일에 변경된 데이터가 Chage vector ( A -> B ) 형식으로 기록된 다음 END BACKUP을
수행할 때 REDO LOG나 Archive 파일에 Chage vector ( A -> B ) 형식으로 기록된 변경 데이터분 내용들이
Datafile( Datablock ) 에 적용된다.

BEGIN BACKUP과 END BACKUP 사이에 외부에서 쿼리로 수행한 명령들에 대해
변경된 내용들은 Datafile의 Data block에 기록되지 않고, REDO LOG의 REDO REDO RECORD에 기록이 되기 때문에
cp명령으로 복사중인 Datafile에 변경을 가하지 않고, Datafile의 손상없이 안전하게 cp명령을 사용해, OS level에서
Database 파일을 복사 할수 있다.

또 END BACKUP을 수행한 즉시, REDO LOG의 REDO REDO RECORD에 기록된 내용들이 바로 Datafile에 적용이 되며,
사용자들이 백업도중 입력한 데이터들은 손실되지 않고, DB에 저장이 되어, 백업이 끝난 후에 Data에 대한 정합성을
만족한다. 이러한 BEGIN/END BACKUP 프로세스는, 사용자가 cp명령으로 Datafile의 백업을 수행하는 도중에
서비스에서 DB에 입력/수정 되었던 데이터들이 END BACKUP과 REDO LOG 또는 ARCHIVE LOG의
Chage vector 적용을 통해 Datafile들에 적용이 되므로 서비스를 운영하며 동시에 백업을 받을수 있는
HOT BACKUP 수행이 가능하게 하는 프로세스이다.

위의 말대로,
사용자들이 BEGIN BACKUP과 END BACKUP 사이에 요청한 DML, 변경분에 대한 내용들이, Datafile에 없고, Chage vector ( A -> B ) 형식으로 REDO RECORD 형태로만 있다면,
BEGIN BACKUP과 END BACKUP 사이에 변경한 내용들은 Datafile에 적용되어 있지 않기 때문에
BEGIN BACKUP과 END BACKUP 사이에 변경한 내용이 조회가 불가능할 텐데, 어떻게
BEGIN BACKUP과 END BACKUP 사이에 변경한 내용을 조회하여 서비스를 온전히 유지할수 있을까?
BEGIN BACKUP과 END BACKUP 사이에 변경한 내용중 조회한 내용에 대해서만 REDO RECORD에 내용을
Datafile에 적용하여, BEGIN BACKUP과 END BACKUP 사이에 변경한 내용을 사용자들이 온전하게 볼수 있는것일까?
그렇다면 Datafile에 변경이 일어날것이고, cp명령으로 복사하는 도중 Datafile에 변경이 일어나 Datafile이 손상된 채로 복사가 되게 됨으로 BEGIN BACKUP과 END BACKUP을 안전하게 수행하지 못하게 될수 있다.

즉, 위의
"BEGIN BACKUP을 수행도중 Database에 들어오는 DML 쿼리에 대해 데이터들이 변경이 가해졌고,
COMMIT이나 CHECKPOINT가 발생할 때, 변경된 내용들은 Datafile의 Data block에 적용되지 않는다." 라는 말은
잘못된 내용이다.

3. 올바른 상식

BEGIN BACKUP을 수행도중 Database에 들어오는 DML 쿼리에 대해 데이터들이 변경이 가해졌고,
COMMIT이나 CHECKPOINT가 발생할 때, 쿼리에 의해 변경되는 데이터들은 BEGIN BACKUP 이전과 동일하게
Datafile의 Data block에 입력/수정이 된다.
REDO RECORD ( Chage vector ( A -> B ) )들도 BEGIN BACKUP 이전과 동일하게 REDO LOG 또는 ARCHIVE 파일에
기록이 된다. 이와 동시에 BEGIN BACKUP 이후 사용자가 입력한 쿼리로인해 변경이 가해진 블럭들은
처음 변경이 가해졌을 때만 변경된 블럭과 함께, Chage vector ( A -> B ) 형식이 같이 REDO LOG나 ARCHIVE FILE에
기록된다.

그 이후에 또, (앞서 변경이 가해졌고, REDO RECORD에 기록이 됬던 블럭)동일블럭에 변경이 가해진다면,
그때는 변경이 가해진 블럭을 제외하고 평소처럼 Chage vector ( A -> B ) 형식만 REDO LOG나 ARCHIVE FILE에
기록된다. 또한 Data block header가 아닌 Datafile header에는 CHECK POINT SCN이 BEGIN BACKUP 시점의 SCN값으로 고정된 채 증가하지 않고, END BACKUP 명령 수행 이후 평소처럼 CHECKPOINT 발생시
CHECKPOINT SCN이 증가한다.

이렇게 되면 사용자가 BEGIN BACKUP을 수행하고, 사용자가 cp명령으로 Datafile들을 복사하여 백업을 받을 때,
분명히 cp명령을 수행하여 Datafile(Data block)을 복사하는도중, 복사하는 Datafile(Data block)에 대해
서비스 쿼리(DML)에 의해 변경되는 Data block이 발생할 것이다, 이는 복사 시작지점을 기준으로 데이터 정합성이
깨져버린 백업본이 될것이다.


그럼 이 데이터 정합성이 깨져버린 백업본을 복구를 할때는 어떻게 복구를 하는가?!
복구 할 때는 일반적인 상식처럼 백업 Datafile( 정합성이 깨져버린 Data block )위에 ARCHIVE LOG들을 적용시켜 recovery를 수행한다. 다만 ARCHIVE LOG들( REDO LOG : REDO RECORD )에 들어있던 "BEGIN BACKUP 이후 변경이
처음 가해진 블럭"을 Datafile( 정합성이 깨져버린 Data block )에 덮어쓰기 하며
cp명령을 수행하는 도중 Data가 변경되었던 정합성이 깨져버린 블록을 대체하며 초기화 시켜준다.그리고 초기화된 블럭에 Chage vector ( A -> B ) REDO record를 적용시켜 복구를 시켜준다. 이렇게 된다면, cp명령을 수행하는 도중 Data가 변경되었던 ( 정합성이 깨져버린 ) Data block에 대해 정합성을 맞춰주어 온전한 백업 복구데이터가 될것이다.
또한 사용자들이 BEGIN BACKUP과 END BACKUP 사이에 요청한 DML, 변경분에 대한 내용들이, Datafile에 평소처럼 적용이 되기 때문에 온전한 DB 서비스를 제공하며, HOT BACKUP을 수행할수 있을것이다.

4. 결론

"3. 올바른 상식" 에 의하면,
BEGIN BACKUP과 END BACKUP을 사용해 cp명령으로 Database를 백업하였을때,
해당 백업본을 RESTORE하기 위해서는 반드시 아래 두 항목의 파일이 필요하다.

- BEGIN BACKUP과 END BACKUP 사이에 생성된 Archive파일
- END BACKUP 직후 생성된 Archive파일

Archive 파일은 cp 명령으로 Datafile 복사도중 사용자들이 입력한 DML쿼리로 인해 정합성이 깨져버린 블록을
복구하는데 반드시 필요하기 때문이다.
만약 백업본 복구시 Archive파일 없이 Datafile만 RESTORE하여, 백업복구를 수행하려 한다면, 반드시 Mount 단계에서
Open 단계로 올릴때, 아래 오류로 인해 Database를 OPEN상태로 올리지 못할것이다.

------------------------------------------------------------------------------------------------------------------------------
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/oradata/ORCL/system01.dbf'
------------------------------------------------------------------------------------------------------------------------------
만약 BEGIN BACKUP과 END BACKUP사이에 아무런 DML 쿼리가 수행되지 않아, cp명령으로 Datafile을 복사도중
Datafile 변경이 일어나지 않았다면,
Archive 파일은 필요가 없을것이다. 다만, 서비스를 운영중에 수행하는 백업인 HOTBACKUP을 수행하는데, Datafile의
변경을 일으키는 DML이 일어나지 않을 가능성은 희박하다 생각된다.

5. 추가

BEGIN BACKUP과 END BACKUP으로 백업을 수행했을 때 Archive파일이 필요한 이유가 위와 별개로 추가로 또 있다.
보통 관리자들이 백업을 받을때, 아래와 같이 스크립트를 수행해 테이블스페이스 단위로 백업을 수행한다.
------------------------------------------------------------------------------------------------------------------------------
alter tablespace TBS1 begin backup;
!cp /u01/oradata/ORCL/tbs1_data.dbf
alter tablespace TBS1 end backup;

alter tablespace TBS2 begin backup;
!cp /u01/oradata/ORCL/tbs2_data.dbf
alter tablespace TBS2 end backup;

...

alter database backup controlfile to <file_location>;
------------------------------------------------------------------------------------------------------------------------------
위와 같은 스크립트가 수행될때 복사된 Datafile들과 Controlfile들은 아래 그림과 같이 파일헤더의 SCN이 각각 다르게
복사가 되 백업될것이다.

이렇게 백업된 Datafile과 Controlfile을 복구하려할 때 각각의 파일들은 제각각의 파일들은 다른 SCN을 갖고
있을것이다. Database를 Mount 단계에서 Open하려 할때는 Datafile들과, Controlfile들의 SCN이 모두 동일하게
일치해야 OPEN상태로 변경시킬수 있다. 제 각각의 파일들이 다른 SCN을 갖고 있기 때문에 recover명령으로 백업받은
Archive 파일들을 적용시켜 복원해주고, 각 파일중 낮은 SCN을 갖고있는 파일을 Archive 파일들을 적용시켜 SCN을
높혀주며, 각 파일중 가장 큰 SCN을 갖고 있는 파일의 SCN을 기준으로 모든 파일들의 SCN 맞춰줘 recovery를 수행하고, OPEN 상태로 Database를 변경할수 가 있다.


만약 tablespace 단위가 아닌 database단위로 begin backup을 수행하였을때는 아래 그림처럼

Controlfile을 제외한 모든 tablespace datafile의 SCN이 일치하기 때문에
복원시 Archive 파일을 사용해 SCN이 제일 높은 Controlfile의 SCN에 맞춰 모든 datafile들을 recovery 시켜주어야
할것이고, Controlfile을 재생성하여 복구하려한다면, 모든 datafile들의 SCN이 동일하기 때문에 Archive파일을
사용해 recovery를 해주지 않아도 될것이다. 다만, BEGIN BACKUP과 END BACKUP사이에 DML쿼리가 발생하지
않았다는 전제하이다.

DATABASE 단위로 백업을 받던, TABLESPACE 단위로 백업을 받던 BEGIN BACKUP과 END BACKUP사이에 DML쿼리가 발생했다면, Data block들의 정합성을 맞춰주기 위해 무조건 Archive파일을 통한 recovery가 필요하다.

http://haisins.synology.me/wordpress/?p=4004

ORACLE ASM이 스토리지를 관리하는 데이터 구조 list

Disk Group

ASM Disk group은 논리적인 단위로써 관리되는 디스크 집합체이며, ASM에서 고려되는 최상의 데이터 구조이다. 개별 Disk group은 자신의 파일 Directory와 Disk Directory 그리고 다른 Meta data를 포함하고 있다(Directory 개념은 해당 목차에서 다루도록 하겠다).

디스크의 크기에 비례하는 숫자의 Extent가 개별 Disk에 할당 됨으로써, Application에 의해 발생되는 I/O load는 하나의 Disk group에 속해있는 모든 Disk에 골고루 분산된다. 이러한 기능으로 Disk group의 디스크 공간이 없는 상태는, 바로 모든 Disk가 데이터로 꽉 차있다는 것을 의미한다.

이렇게 균등하게 I/O load가 분산되어 처리되기 때문에, 특정 Disk group구성 시 사용되는 Disk들은 크기가 비슷하고, 동등한 수준의 성능을 나타내는 것으로 지정해야 원하는 수준의 결과를 달성할 수 있다. 즉, 가장 좋은 성능을 나타내는 Disk 들을 모아 특정 Disk group을 생성하고, 이 Disk group에 Application에서 가장 중요한 데이터들을 저장하는 방법을 모색할 수 있는 것이다.

현재, ASM Disk group은 동시에 63개의 Disk group을 mount 할 수 있다.

Failure Group

Failure group은 스토리지 리소스를 공유하는 Disk group의 일부분이다. 여기서 말하는 ‘리소스’는 장애 발생 시 함께 영향을 받게 되는 Disk들이 서로 공유하고 있는 리소스를 일컫는다. 예를 들어, 어느 Disk들은 SCSI 컨트롤러 1번에 연결되어 있고, 나머지 Disk들은 SCSI 컨트롤러 2에 연결되어 있다면, 전자의 Disk들은 Failure group 1이 되는 것이고, 나머지 Disk 들은 Failure group 2에 속하게 되는 것이다. 즉, 운명을 같이하는 Disk 들의 집합체가 Failure group을 형성하는 것이다. 결과적으로, 하나의 Disk group은 여러 개의 Failure group으로 구성될 수 있다.

Failure group을 어떻게 지정하는 가는 고객이 원하는 안정성의 수준이 무엇인가에 따라 상당히 다를 수 있기 때문에, 사용자가 수동으로 지정/활용하는 것이 일반적이라 하겠다. 만약 Disk group 생성 시 Failure group을 지정하지 않는 다면, ASM은 개별 Disk에 대한 Failure group을 자신의 Disk로 지정한다.

Disk group을 생성할 때마다, DBA들은 그 Disk group의 redundancy를 고려해야 한다. 즉, 데이터의 복사본을 어떻게 유지할 것인가를 판단해야 한다(Data mirroring과 관계 있다). 이는 아래와 같이 세 개로 분류하여 지정된다.

■ EXTERNAL REDUNDANCY

ASM은 생성되는 Disk group에 대해 어떠한 redundancy를 고려하지 않겠다는 것을 의미한다. 이런 경우, 해당 Disk group에 대한 redundancy를 위해 Hardware solution을 사용하던지, 아니면 Disk 장애를 그대로 받아 들여야 한다.

■ NORMAL REDUNDANCY : 2-way mirroring

하나의 failure group에 장애가 발생하더라도 데이터 손실을 예방할 수 있는 방법이다. 이렇게 지정하기 위해서는 적어도 2개의 failure group을 지정할 수 있어야 한다.

■ HIGH REDUNDANCY : 3-way mirroring

가장 높은 수준의 데이터 보호 방법이다. 두 개의 failure group에 장애가 발생하더라도 데이터 손실이 발생하지 않는다. 적어도 3개의 failure group을 지정해야 한다.

ASM Disk

하나의 Disk group은 ASM Disk의 집합체로 구성되는 것이다. 즉, Disk group에 스토리지가 추가 되거나 삭제될 때 ASM Disk 단위로 처리된다. 또한, 데이터베이스 인스턴스에서 Direct I/O가 가능한 물리적인 disk이어야만 한다.

ASM Disk는 서로 다른 노드에서도 동일하게 인식되는 추상적인 이름을 갖고있다. 즉, OS에서 disk를 접근하기 위해 사용하는 이름과는 다르다. 이렇게 다른 이름을 유지하는 이유는 다른 노드들이 동일한 Disk에 대해서 상이한 OS 이름을 갖게 될 경우가 있기 때문이다. ASM Disk 이름은 Disk가 추가될 때 관리자가 지정할 수도 있고, 지정하지 않으면 자동적으로 지정된다. ASM 인스턴스가 Disk group을 mount 할 때, 정확한 ASM Disk를 찾기 위해 관련 OS 이름들이 검색된다. 그리하여 개별 OS 이름과 ASM Disk header 정보의 매핑작업이 이뤄지고 어떤 ASM Disk가 사용될 것인지를 결정하는 것이다. 위 매핑정보는 데이터베이스 인스턴스의 메모리에 저장/관리된다. OS 이름은 사전 경고 없이 변경될 가능성이 있기 때문에, ASM Disk에 저장되지 않는 특성을 갖는다.

ASM은 동시에 10,000개의 disk를 지원할 수 있다.

ASM Files

개념

ASM File은 ASM Disk group에 저장되는 Oracle 데이터파일이다. 파일이 생성될 때, Mirroring을 어떻게 할 것인지, Striping은 어떻게 할 것인가에 대한 정보가 함께 적용된다.

ASM File은 OS에 의해 확인될 수 없으며, RMAN이나 다른 Oracle 지원 툴에 의해 확인 가능하다. OMF(Oracle Managed File)와 유사하다. OMF 처럼 더 이상 필요치 않는 파일들은 자동적으로 제거된다. 생성/삭제/읽기/쓰기/크기 변경이 가능하고, 하나의 ASM File은 하나의 Disk group에 분산 저장된다. Disk group을 이루는 개별 파일들이 모든 disk에 분산 저장되기 때문에 하나의 disk에 대한 백업은 유용하지 않다. 때문에, ASM File에 대한 백업은 RMAN을 통해서 만이 가능하다. 그러나 PL/SQL 인터페이스를 통해서 ASM File의 내용을 읽어 내는 것은 가능하다.

특성

■ Load balancing

Disk group에 있는 모든 Disk에 걸쳐서 데이터가 분산 저장되는 이유로 파일접근 형태가 균형을 이루게 된다. 이러한 특성의 장점을 극대화 하기 위해서는 동일한 성능을 나타내는 disk들로 Disk group을 구성해야 한다.

ASM은 Disk group을 구성하는 모든 disk에 걸쳐서 하나의 AU(Allocation Unit) 단위로 파일들을 분산시킨다. 이것을 COARSE striping 이라고 한다. 이에 반해, 개별 AU 단위를 더 작은 크기로 잘라 분산 시키는 것을 FINE striping 이라고 일컫는다. FINE striping은 일반적인 크기의 I/O operation을 더욱더 작은 여러 개의 I/O operation으로 나누어 병렬로 처리하는 것이다.

■ Mirroring

RAID-1과 같은 형태처럼, ASM도 다중의 데이터 복사본을 유지함으로써, 중요 데이터를 보호할 수 있다. 그러나, RAID-1과 다르게 파일단위로 처리된다. RAID-1은 멤버들이 획일적인 알고리즘을 따르게 된다.

생성 예

ASM File의 개별 정보와 DBA_DATA_FILES에서 출력된 정보를 비교해 보기 바란다.

ASM File type

ASM Disk group 내에 저장될 수 있는 파일형태는 아래와 같다.

■ Control File

■ Datafile

■ Online Redo Log

■ Archive Log

■ Temporary data file

■ RMAN backup piece

■ Datafile Copy

■ SPFILE

■ Disaster Recovery Configuration

■ Flashback Log

■ Change Tracking Bitmap

■ DataPump Dumpset

그러나, Oracle 실행모듈과 ASCII 파일, alert log / trace 파일들은 ASM Disk에 저장될 수 없다.

ASM File template

ASM File template은 데이터파일 생성 시 파일에 적용될 성질(redundancy,striping)을 다양하게 분류하여 목록화한 형태를 말한다. Template이 없다면, 파일 생성 시 마다 개별 성질들을 지정해야 할 것이다. 성질부여 작업을 간편하게 수행하기 위한 도구라고 생각하면 무리가 없겠다.

특정 Template은 하나의 Disk group과 연결관계를 갖는다. 서로 다른 Disk group은, 다른 성질을 갖고 있으면서 이름이 동일한 Template을 가질 수 있다.

새로운 Disk group이 생성될 때, ASM은 그 Disk group과 관계된 Default template을 생성한다. 이 Default template은 다양한 Oracle 데이터파일 type에 대한 기본적인 성질들을 포함하게 되는 것이다. Default template의 성질내용은 DBA에 의해 변경 가능할 뿐만 아니라, DBA는 새로운 template을 만들 수 있다. Default template은 삭제될 수 없다.

ASM File 생성 후에, 그 파일에 대한 성질을 변경하기 위해서는 RMAN을 통해 새로운 성질을 갖고 있는 파일로 복사해야 한다. 이것이 파일의 성질을 변경할 수 있는 유일한 방법이다.

아래 내용은 System Default template의 예를 보여준다.

Template을 정의하거나 변경할 때, COARSE/Fine-Grained striping 성질도 함께 지정한다.

ASM Meta data에 대한 redundancy/striping 성질은 ASM에 의해 사전 정의되기 때문에, 이 값들은 template 을 통해서 변경이 불가능 하다.

ASM File name

ASM filename은 아래와 같은 다양한 형태로 존재할 수 있다.

■ Fully Qualified ASM Filenames

존재하고 있는 ASM File을 참조하기 위한 형태이다. 이는 Disk group 이름, 데이터베이스 이름, 파일 type, type에 따른 tag 정보, 파일 number, 그리고 incarnation number를 가지고 ASM File을 표현한다. 이 형태는 ASM File이 생성될 때 자동적으로 지정된다. ‘Alias’를 사용하여 ASM File이 생성된다고 하더라도 이러한 형태의 filename도 함께 지정된다.

ASM은 파일생성 시 이 파일형태를 사용하기 때문에, DBA는 파일생성 문장에서 이 형태를 사용할 수 없다.

형태 : +<group>/<dbname>/<file type>/<tag>.<file>.<incarnation>

• <group> : Disk group 이름
• <dbname> : 파일이 속해 있는 데이터베이스 이름
• <file type> : 오라클 파일 type
• <tag> : 데이터파일에 대한 테이블스페이스와 같은 특수 정보
• <file>.<incarnation> : 유일성 보장을 위한 File과 Incarnation 정보
• 예제 : +dgroupA/db1/controlfile/CF.257.8675309
  

■ Numeric ASM Filenames

존재하고 있는 ASM File을 참조하기 위한 형태이다. 이는 Disk group 이름, 파일 number, 그리고 incarnation number로 구성된다. ASM은 파일 생성 시 파일/Incarnation number를 내부적으로 사용하기 때문에, 이 형태는 파일 생성 시 사용될 수 없다.

이 형태는 Fully qualified name 형태에서 유추되며, 사용자에게 공개되지 않는다. 다만, 존재하는 파일을 참조하기 위한 API를 통해 사용 가능하다.

• 예제 : +dgroupA.257.8675309
  

■ Alias ASM Filenames

이 형태는 기존의 ASM File을 참조할 뿐만 아니라 새로운 ASM File을 생성할 때에도 사용될 수 있다. 파일과 Incarnation 숫자를 지정하지 않고, 단지 Disk group 이름과 사용자가 임의로 지정하는 문자열로 이뤄진다. 즉, DBA가 자신이 구별하기 쉽도록 파일 참조정보를 지정할 수 있는 것이다.

Alias Filename은 ‘/’ 문자를 가지는 Directory 구조를 사용한다. 이름을 이루는 각 항목들은 UTF-8 format을 따르며 48 byte 이상이 될 수 없다. 또한, 모든 항목이 포함하는 문자열은 256 byte를 넘을 수 없다. 문자열 사이에 space 문자를 넣을 수 있으나, 대소문자를 구별한다는 것을 유념해야 한다.

예제1 : +dgroupA/myfiles/control_file1

예제2 : +dgroupA/A rather LoNg and WeiRd name/for a file

ASM File은 파일 생성 시 Fully qualified name 형태를 따른다. DBA는 이때 alias를 사용하여 파일을 생성할 수도 있고, 추후 ‘ALTER DISKGROUP ADD ALIAS’ 명령어로 파일을 만들 수 있다.

■ Alias ASM Filenames with template

오직 ASM File을 생성할 때에만 사용되는 형태이다. 이는 Disk group 이름, alias 이름, 그리고 파일에 대한 Template 이름으로 구성된다. 파일 생성시 이러한 형태가 지정되고, alias가 존재하는 파일을 가리킨다면 Template은 무시된다.

• 예제 : +dgroupA/config1(spfile)
  

■ Incomplete ASM Filenames

파일 생성시에만 사용되는 형태이다. Disk group 이름만으로 구성한다. 이를 위해, ASM은 해당 파일의 type이 정의되어 있는 Default template을 사용한다.

예제 : +dgroupA

■ Incomplete ASM Filenames with template

파일 생성시에만 사용되는 형태이다. Disk group 이름과 Template 이름으로 조합된다. Template은 파일에 적용되어질 여러 가지 성질을 결정하게 된다.

예제 : +dgroupA(datafile)

이상의 ASM Filename 6개의 형태는 아래와 같은 범주로 나눠볼 수 있다.

그림. ASM Filenames

Allocation Unit(AU)

AU는 Disk group 내에서 저장영역을 할당하고자 할 때 사용하는 기본적인 단위/개념이다. ASM Disk내에서 가용한 공간은 AU 크기의 배수가 되는 것이다. ASM Disk의 header에는 이러한 AU에 대한 정보를 포함하고 있는 테이블이 존재한다.

_ASM_AUSIZE에 의해 변경하지 않는 이상, 기본적으로 AU는 1MB 이다. 이 크기는 하나의 ASM File이 여러 Disk에 골고루 분산되어 저장될 수 있을 정도로 작은 크기일 뿐만 아니라, 하나의 I/O operation에 의해 처리되는 하나의 AU가 좋은 처리량을 보장할 수 있을 정도로 충분히 큰 크기로 생각되는 것이 일반적이다(Oracle SAME 방법론 참조). 또한, AU을 접근하는 시간은 AU가 시작되는 곳을 찾아가는 seek time 보다, Disk의 전송속도에 지대한 영향을 받는다. Disk group에 대한 Rebalancing 작업은 이 AU 단위로 처리된다.

ASM Rebalancing

Disk가 추가/삭제 또는 크기조정이 일어날 때, Disk group은 모든 Storage에 대한 load를 균등히 하기 위해 rebalancing 작업을 수행한다. Rebalancing은 I/O load에 대한 통계정보에 근거하여 수행되지 않는다. 다만, Disk group에 포함되는 Disk의 크기를 기준으로 해당 작업을 수행하는 것이다. 이 작업은 Storage의 구성정보가 변경될 때 자동적으로 수행되며, DBA에 의해 수동으로 발생될 수 있다(사실 수동 작업은 필요 없다).

http://haisins.synology.me/wordpress/?p=3854

1. Oracle 12c R1 RAC (Real Application Cluster)
   

• Oracle RAC에서는 Oracle Database (데이터를 실제로 보유하고 있는 Storage의 물리적 구조 즉, 데이터 파일들에서 Oracle Instance (데이터 접근 지원을 위해 서버 상에서 실행되는 프로세스 및 메모리 구조)를 분리할 수 있다.
  
• 클러스터 데이터베이스는 여러 개의 인스턴스가 접근할 수 있는 단일 데이터베이스이다. 각 인스턴스는 클러스터내의 별도의 서버에서 실행된다. 추가 자원이 필요한 경우, 시스템 중단 없이 클러스터에 노드 및 인스턴스를 손쉽게 추가할 수 있다. 새로운 인스턴스가 시작되면, 애플리케이션이나 애플리케이션 서버를 변경하지 않고도 서비스를 사용하는 애플리케이션이 이를 즉시 활용할 수 있다.
  
• Oracle RAC는 Oracle Database의 확장 기능이기 때문에 Oracle Database 12c의 관리 용이성, 안정성 및 보안성을 활용할 수 있다.
  

1. Oracle 12c RAC Architecture
   

1. 네트워크 구성정보
   

1. Oracle Grid Infrastructure Process 구조
   
   
   
   1. Cluster Synchronization Services (CSS)
      

• Cluster에 어떤 node가 추가/제거 되었는지 모니터링 및 정보관리
  
• Heartbeat 메커니즘을 이용 (interconnect를 통한 Network Heartbeat)
  
• 각 멤버 node 들에게 node membership 정보 전달
  
• Vendor clusterware 사용시 직접 통신하면서 node membership 정보 관리
  
• Css 프로세스 비정상 종료 시 node reboot
  

1. Cluster Ready Services (CRS)
   

• Database, Instance, Service, Listener, VIP, Application 등 모든 cluster 리소스들을 OCR에 등록되어 있는 리소스 정보에 기반하여 관리
  
• 리소스 모니터링 중 장애발생시 해당 리소스 start, stop, failover 조치
  
• cluster 리소스 등록/제거, 모니터링, 시동/중지 관련 명령어 인터페이스를 제공
  
• crs 프로세스 종료 시, init process에 의해 자동으로 재 기동
  

1. Event Manager
   

• evmd.bin 프로세스
  
• grid user로 동작
  
• crs가 발생시키는 이벤트들을 전파
  
• Log 파일에 이벤트를 기록하는 역할 (evmlogger)
  
• Racgimon이 전달하는 메시지에 따라 racgevt 프로세스 fork
  
• Fail시, 자동 재 기동
  

1. Process Monitor Daemon(OPROCD)
   

• IO fencing 기능 제공을 위한 Oracle 솔루션
  
• Vendor clusterware를 사용하는 경우, 동작 하지 않음
  

1. Global Service Daemon(GSD)
   

• 9i 이전의 클라이언트가 11g CRS에 접속하여 각 종 관리업무를 수행할 수 있도록 돕는 프로세스
  
• 11g에서는 backward compatibility를 위해서만 존재할 뿐 특별한 역할 없음
  

1. Virtual IP
   

• IP failover를 위해 Oracle CRS가 제공
  
• Public network interface에 VIP를 할당
  
• Network interface에 오류가 발생하면 CRS가 fail된 VIP의 address를 살아있는 node로 failover
  

1. Single Client Access Name(SCAN)
   

• 11gR2 RAC부터 소개된 기능으로 Cluster로 구성되어 운영중인 Oracle Database 에 접근하는 모든 Client에서 SCAN으로 접속할 수 있다.
  
• SCAN으로 접속 시 자동으로 Server Side Load Balancing을 수행한다. (Default로 Remote Listener에 SCAN이 등록됨)
  
• SCAN은 Grid 설치 시 반드시 구성해야 하며, GNS을 사용하지 않는다면, SCAN NAME을 아래와 같이 DNS상에 등록해줘야 한다.
  
• 기본적으로 3개의 Public IP를 동일한 이름으로 등록해줘야 하며, Public과 SCAN 의 subset은 동일하여야 한다. (최소 1개의 IP등록)
  

1. Oracle Grid Infrastructure 관련 파일
   
   1. Oracle Cluster Registry(OCR)
      

• Cluster 리소스들에 대한 정보 저장소
  
• 반드시 shared disk상에 위치
  
• Multiplexing 가능 (multiplexing 권장)
  
• Enterprise Manager / Server Control Utility (SRVCTL) / Database Configuration Assistant (DBCA)을 통해서 수정 가능
  

1. Voting Disk
   

• Cluster membership 관리를 위해 css 데몬이 이용
  
• Cluster member들의 health check
  
• Split brain 상태에서 node의 상태를 판단하기 위한 second heartbeat 역할
  
• 반드시 shared disk상에 위치
  
• Multiplexing 가능 (multiplexing 권장)
  

1. Oracle RAC 기동(Startup), 정지(Shutdown)
   
   1. Clusterware 기동과 정지
      
      1. Oracle Clusterware 기동
         

• CRSCTL 유틸리티는 Oracle Clusterware를 관리한다.
  
• 다음의 명령어로 OHASD process가 기동되면서 Oracle Clusterware 의해 관리되는 프로세스와 리소스를 시작할 수 있다.
  
• 각 node에서 root 계정으로 수행하여 Cluster 리소스를 기동한다.
  

• oracle 계정으로 아래의 명령 중 선택하여 수행하여 DB instance를 기동한다.
  

1. Oracle Clusterware 정지
   

• 다음 명령어로 Oracle Clusterware 의해 관리되는 모든 프로세스와 리소스를 정지한다.
  
• oracle 계정으로 아래의 명령 중 선택하여 수행하여 DB instance를 정지한다.
  

• 각 node에서 root 계정으로 수행하여 Cluster 리소스를 정지한다.
  

1. Oracle Clusterware 상태 확인
   

• 전체 노드상의 Clusterware stack 상태 확인
  

• CRS 리소스 상태 확인
  

1. Database 기동과 정지
   
   1. DB Instance 기동
      

• oracle 계정으로 아래의 명령 중 선택하여 수행하여 DB instance를 기동한다.
  

• 아래의 명령으로 instance 상태를 확인한다.
  

1. DB Instance 정지
   

• oracle 계정으로 아래의 명령 중 선택하여 수행하여 DB instance를 정지한다.
  

• 아래의 명령으로 instance 상태를 확인한다.
  

1. Listener 기동과 정지
   
   1. Listener 기동
      

• grid 계정으로 아래의 명령을 수행하여 Listener를 기동한다.
  

• 아래의 명령으로 listener 상태를 확인한다.
  

1. Listener 정지
   

• grid 계정으로 아래의 명령을 수행하여 Listener를 정지한다.
  

• 아래의 명령으로 listener 상태를 확인한다.
  

1. Database 사용자 관리
   
   1. User의 생성
      

• Password와 Default Tablespace 및 Temporary Tablespace를 지정하여 User 생성
  

1. 새로운 User 권한 부여
   

• 관리자가 User를 생성하면 해당 User에게 각각 필요한 권한을 부여할 수 있다.
  
• 다음 명령어를 통하여 User로 접속 가능하도록 할 수 있는 권한과 Object를 생성할 수 있는 권한을 부여한다.
  

1. User 패스워드 변경
   

• 다음 명령어를 통하여 password를 test로 변경할 수 있다.
  

1. User 삭제
   

• 다음 명령어를 통하여 User를 삭제할 수 있다.
  

※ 참고 : cascade option을 이용할 경우 test_user 계정의 스키마는 물론 종속적인 foreign key 까지도 drop 시킨다. 그러므로 이용 시 주의해야 한다.

1. Database tablespace 관리
   
   1. Tablespace 종류
      

• System tablespace
  Oracle의 Dictionary 가 저장되는 영역으로 재생성은 불가능 하다. Database 당 하나의 System Tablespace가 존재한다.
  
• Undo tablespace
  Undo Segment 가 저장되는 공간으로 RAC 의 경우 Instance 각각 독립적인 Undo Tablespace를 가진다. 읽기의 일관성 유지해 줍니다.
  
• Temp tablespace
  임시 영역으로 SGA에서 수행할 수 없는 Sort등의 작업 시 사용된다.
  
• Data tablespace
  Table 이 저장되는 영역으로 Table 생성시 사용자 임의로 지정한다.
  

1. Tablespace 추가 및 삭제
   

1. Tablespace 관리
   
   1. 테이블스페이스 사용률 조회
      

1. ASM diskgroup 사용률 조회
   

• 다음 명령어를 통하여 User를 삭제할 수 있다.
  

1. Automatic Storage Management (ASM)
   
   1. ASM 구조
      
      1. ASM 개요
         
      Automatic Storage Management(ASM)는 데이터베이스 구성 시 기본이 되는 디스크를 효율적으로 관리하기 위해 Oracle Database 10g에서 새로 선보이는 데이터베이스 서비스이다. ASM은 하나의 SMP 장비뿐만 아니라, RAC을 구성하는 모든 노드들에 대해서도 지원이 가능하다.
      ASM은 특정 데이터에 대한 복사본을 자기 자신의 디스크에 유지할 수 있기 때문에 Software 미러링 효과를 볼 수 있다. 이처럼 ASM은 데이터에 대한 안정성, 그리고 성능을 어떻게 유지할 것인가에 대해 상당히 유연하게 달리 지정할 수 있다.
      ASM을 단순히 기존 파일시스템, RAW Device와 같은 파일 저장소로 간과하면 큰 오산이다. ASM은 여타 디스크 Solution 없이 Striping / Mirroring 효과를 볼 수 있을 뿐만 아니라, 자동적으로 데이터 구성을 재 분배할 수 있는 기능을 제공해 줌으로써, 더 이상 I/O tuning을 할 필요로 없게 만들고 있다. 또한, 자체가 Cluster 파일시스템 이기 때문에 하나 이상의 노드에 있는 다른 데이터베이스에 대해서도 통합 관리가 가능한 것이다. DBA들은 더 이상 스토리지 관리를 위해 엄청난 시간을 투자할 필요가 없게 되었다.
      
   2. ASM은 기존 데이터베이스 구성과 독립적으로 관리될 수 있다. 즉, 기존 데이터베이스가 데이터 저장소로 파일시스템을 사용하고 있어도, 아니면 RAW Device를 사용하고 있어도 이와는 별도로 새로운 데이터파일을 ASM에 저장/관리할 수 있는 것이다. 기존 데이터 파일들은 ASM 관리 영역으로 이관될 수도 있다.
      
   3. ASM이 관리하는 모든 디스크에 대해 load balancing 작업을 자동적으로 처리해 줌으로써, 특정 디스크에 load가 집중되는 hot spot 현상을 최소화 할 수 있으며, 이로 인해 성능을 극대화 할 수 있다. 또한, 데이터가 디스크에 균등한 크기로 저장/관리되어 fragmentation 현상이 발생하지 않는다. 그리고, ASM이 관리하는 영역에서 새로운 디스크가 추가되거나 삭제될 때마다, 기존 데이터들에 대해 재구성 작업이 자동적으로 일어난다.
      

1. ASM의 기본 개념
   

• Oracle 10g부터 지원되는 Volume Manager와 File system의 통합체
  
• Oracle 데이터베이스 파일을 위해 특별히 구현된 Storage 관리 시스템
  
• Disk간 Balance가 유지될 수 있도록 분산 저장, Mirroring을 지원
  
• Oracle은 Volume Manager, File System, Raw Device 등의 방법 대신 ASM의 사용을 권장하고 있음 (11g부터는 Raw Device는 공식적으로 지원되지 않음)
  
  
  

1. ASM 주요 기능 및 특징
   

1. ASM 및 타사 File System 대응 File Type 비교
   

1. ASM Instance의 개념
   
   RAC 클러스터에서 ASM을 사용하려면 각각의 노드에서 ASM 인스턴스가 실행되고 있어야 한다 ASM 인스턴스는 ASM 디스크그룹의 메타데이터 관리 및 데이터베이스 인스턴스를 지원한다. 다른 데이터베이스 인스턴스가 ASM 스토리지에 있는 파일에 접근하기 전에 ASM 인스턴스가 구동되어 있어야 한다 ASM 인스턴스가 종료되면 모든 클라이언트 데이터베이스 인스턴스도 종료된다. 또한， ASM 인스턴스는 디스크 추가, 제거, 리밸런싱 작업을 처리한다.
   
   1. ASM Instance의 특징
      

1. ASM Instance
   

• DB instance와 같은 구조로 생성 (smaller SGA, BG processes)
  
• Cluster 환경에서 Node 당 하나의 ASM INSTANCE 를 가진다.
  
• ASM 파일(Diskgroup)을 DB 에서 share할 수 있도록 마운트 및 연결
  
• Init+ASM.ora 파일에서 파라미터 변경가능(asm설치시 orapwd및 spfile생성)
  
• Disk Group 에 대한 Meta data를 관리한다.
  
• ASM Metadata 는 디스크 그룹 관리를 위한 정보를 담고 있고, 생성된 디스크 그룹 내에 저장.
  

1. ASM Instance Processes
   

1. ASM 디스크
   
   1. ASM DiskGroup
      

• ASM 에 의해 관리되는 최상위 객체.
  
• 논리적 단위로써 관리되는 ASM Disks의 집합체
  
• 각각의 디스크 그룹 내에 디스크 그룹의 메타데이터 정보를 저장.
  
• 하나의 디스크 그룹이 여러 개의 database에 의해 공유될 수 있고, 하나의 database가 여러 개의 디스크 그룹을 사용할 수도 있다.
  

1. ASM mirroring Option
   

• ASM은 ASM 디스크그룹에 대해 다음 세 가지 중복 구성 유형을 제공한다.
  

• 외부 중복 구성(External redundancy)은 어떠한 미러링도 하지 않는다. 이것은 RAID나 LVM 같은 기존 운영체제나 스토리지 어레이의 보호 기능을 사용한다. 하지만 외부 중복 구성을 선택했을 경우 하부 스토리지가 올바르게 구성되었는지 확인하는 것은 사용자의 책임이다. ASM은 장애 발생 시 복구를 보장하지 않는다. 또한， 외부 중복 구성을 사용할 경우 어떠한 failure group도 정의할 필요가 없다.
  
• 일반 중복 구성(Normal redundancy)은 기본 설정이며 한 개의 주 extent와 한 개의 미러 extent를 사용하여 각 파일 extent를 두 개의 디스크그룹에 기록하는 이중 미러링을 구현한다. 일반 중복 구성을 보장하려면 최소 두 개의 failure group을 정의해야 한다.
  
• 높은 중복 구성(High redundancy)은 각각의 파일 extent가 한 개의 주 extent와 두 개의 미러 extent를 사용하여 세 개의 디스크그룹에 기록하는 삼중 미러링으로 구현되어 있다. 높은 중복 구성을 보장하려면 최소 세 개의 failure group을 정의해야 한다.
  

1. Failure Group
   

디스크 컨트롤러에 장애가 발생하면 연결된 모든 디스크에는 접근할 수 없다 ASM은 컨트롤러 같은 단일 장애 지점 에 영향을 받는 디스크를 그룹화하여 failure group으로 정의한다. 중복 구성을 보장하기 위해 각각의 미러는 서로 다른 failure group에 위치해야 한다. 따라서 컨트롤러 장애 같은 상황이 발생했을 때. ASM은 다른 디스크그룹에 미러링 된 extent의 사본을 사용하여 장애가 발생한 디스크그룹을 재구성할 수 있다.

• 장애 발생시 동일하게 영향을 받게 되는, 공통의 리소스를 공유하는 디스크의 집합체
  
• Failure Group은 Data의 Copy 본을 저장하는 목적으로 사용됨
  
• Normal Redundancy를 사용하는 File의 경우 Oracle ASM은 서로 다른 Failure Group에 속하는 Primary Copy와 Secondary Copy를 할당함
  
• Failure Group 할당 시 동일 H/W 구성요소를 사용하지 않거나 해당 H/W 구성 요소가 이중화된 Diskgroup으로 설정해야 함
  
• Extent의 중복된 복사본은 분리된 Failure Group 에 저장
  
• Default는 디스크 이름과 Failure group의 디스크로 구성
  
• Disk controller 별로 failure Group 의 디스크로 구성
  
• DBA나 ASM에 의해 자동으로 지정됨
  

1. Striping
   

ASM은 I/0 성능을 최적화하기 위해 디스크그룹의 디스크에 파일을 분산하여 스트라이핑 한다. 따라서 디스크그룹 내의 모든 디스크는 동일한 유형과 성능 특성을 가져야 한다. 스트라이핑의 두 가지 유형은 coarse와 fine이며, 데이터베이스 파일 유형에 따라 어느 방식을 사용할지 결정된다

Coarse 스트라이핑은 데이터베이스 파일, 트랜스포터블 테이블스페이스(transportable tablespaces), 백업세트, 덤프세트, 컨트롤 파일 자동 백업, 블록 변경 추적 파일(block change tracking file), 데이터 가드 구성 파일 등 대부분의 파일 유형에 사용된다.

또한 fine 스트라이핑은 컨트롤 파일, 온라인 리두 로그, 플래시백 로그에만 사용된다.

1. Rebalancing
   

• File이 Disk Group내에서 보다 균등하게 분포하도록 조정하는 작업
  
• Data가 Disk에 균등히 분포할 경우 Load Balancing은 자동으로 이루어짐
  
• Rebalancing은 자동/수동으로 이루어질 수 있으며 자동으로 이루어지는 경우는 Storage Configuration이 변경되는 경우에 발생.
  
• Rebalancing 수행 중에도 Database는 정상적으로 운영될 수 있음
  
• 다만 Rebalancing 작업이 Disk I/O 자원을 많이 사용할 수 있으며 이에 따른 Online 성능 저하 현상을 최소화 하기 위해 Power Setting Parameter (ASM_POWER_LIMIT)를 통해 Rebalancing에 의한 I/O 사용량을 제한할 수 있음
  

1. Mirroring
   

ASM은 데이터를 중복 구성하기 위해 미러링을 사용하며 파일 레벨에서 extent를 미러링 한다. 이것은 디스크 레벨에서 미러링을 수행하는 대부분의 운영체제 미러링과 다르다. ASM 디스크가 손실된 경우, 다른 ASM 디스크에 미러링 된 extent를 사용하여 데이터 손실이나 서비스 중단 없이 작업을 계속할 수 있다. 디스크 장애가 발생한 경우， ASM은 통일 그룹의 다른 디스크에 미러링 된 extent를 사용하여 망가진 extent를 재구성할 수 있다.

미러링은 Diskgroup 생성 (또는 변경) 시 Failure Group을 정의할 수 있으며 Failure Group은 Disk Group Type을 Normal Redundancy / High Redundancy 로 설정할 경우만 유효하다.

1. ASM 모니터링 및 관리하기
   
   1. ASM Instance 접속
      
   오라클 10g에서 ASM 인스턴스에 접속하려면 SYSOPER나 SYSDBA 권한이 필요했었다. 오라클 11.1에서는 스토리지 관리자와 DBA 그룹을 분리할 수 있도록 SYSASM 권한이 새로 도입되었다. 오라클 11.2에서 ASM 관리 작업의 대부분은 SYSASM 권한을 필요로 한다. ASM 인스턴스의 시작, 중지, 마운트, 마운트 해제, 디스크그룹의 점검 및 오프라인, ASM 동적 성능 뷰에 접근하기 위해서는 SYSASM 권한이 필요 하다.
   

오라클은 각 노드에 하나의 ASM 인스턴스만 존재할 수 있으며, 인스턴스 이름은 수정할 필요가 없다. 인스턴스 이름은 ASM 리소스의 리소스 프로파일 내부에 정의되며, crsctl status resource ora.asm -p 명령어를 사용하여 이를 조회할 수 있다. 다음 예제처럼 생성된 인스턴스 이름을 확인할 수 있다. 일반적으로 1번 노드 ASM Instance 이름은 +ASM1, 2번 노드 ASM Instance 이름은 +ASM2가 된다.

1. ASM Diskgroup Creation
   

디스크그룹은 asmca, asmcmd, EM(엔터프라이즈 관리자)을 사용하여 생성할 수 있다 또한, 다음 ASM 인스턴스의 SQL Plus로 접속하여 CREATE DISKGROUP 명령어를 사용해 수동으로 생성할 수도 있다.

• 디스크 그룹 확인
  

• 추가 할 디스크 확인
  

• Disk Group 생성
  
  일단 CREATE DISKGROUP 명령어가 시작되면 ASM은 새로 생성된 디스크그룹을 자동으로 마운트한다. 동적 성능 뷰 GV$ASM_DISKGROUP을 조회하여 전체 클러스터 노드의 신규 ASM 디스크그룹 상태를 점검할 수 있다.
  

1. ASM Disk group Drop
   

커맨드를 통해서 diskgroup을 drop 할 수 있다. 이를 위해 sysasm으로 접속하여 drop diskgroup diskgroupName 명령어를 실행한다. 이 명령어는 diskgroup이 비어있지 않으면 오류를 발생한다. 파일을 수동으로 삭제하거나 including contents 절을 지정하여 삭제한다.

1. ASM Disk group Mount/Umount
   

Init+ASM.ora 파일에 asm_diskgroups 항목에 지정된 diskgroup는 자동으로 asm instance 시작 시에 mount된다. ASM 디스크그룹을 수동으로 마운트하려면, alter diskgroup diskgroupName mount 명령어를 사용한다.

1. ASM Disk group disk add
   

아무리 신중하게 계획했더라도 ASM 디스크그룹의 증설이 필요할 수 있다. ASM 디스크그룹 증설은 일단 전체 클러스터 노드에 블록 디바이스를 제공하고 나면 비교적 간단한 작업이다. ASM에 새 LUN을 추가할 때, 기존 ASM 디스크와 성능과 크기가 통일하거나 가급적 비슷한 디스크를 사용하는 것이 좋다.

Rebalance power 옵션은 asm_power_limit parameter (default 1)의 수치를 해당 operation에 한해 일시적으로 조정하는 옵션이다. 이 수치가 높을수록 disk 추가, 삭제 시에 발생하는 rebalancing 작업이 빠르게 진행된다. (수치가 높을 수록 disk i/o 점유율이 높음)

위 명령어 프롬프트는 거의 즉시 반환되지만 백그라운드에서 리밸런싱 작업이 일어난다. V$ASM_OPERATION 뷰를 조회하여 리밸런싱 작업에 걸리는 시간을 추정할 수 있다.

1. ASM Disk group disk drop
   

디스크를 drop하면 rebalancing 작업이 일어난다. V$ASM_DISK 뷰에서 제거 대상 디스크의HEADER STATUS가 FORMER인 경우에만 클러스터에서 ASM 디스크를 물리적으로 안전하게 제거할 수 있다. 디스크그룹에서 디스크를 drop 하려면 ALTER DISKGROUP 명령어를 사용한다.

disk drop 명령실행 후 add와 마찬가지로 내부적으로 리밸런싱 작업이 진행된다.

1. ASM Disk size 변경
   

ASM DISK의 size를 변경 할 수 있는 방법이 있다. 디스크를 size 없이 추가 했을 때, 해당 디스크는 할당 할 수 있는 영역까지 디스크 용량을 잡는다. 만약 디스크를 추가 할 때 사이즈를 줬다면 추가적으로 사이즈를 더 줄 수 있다.

1. ASM check Disk
   

디스크 그룹의 정합성을 체크할 수 있으며, 수행 결과는 ASM Instance의 Alert.log에 기록된다. 단 Diskgroup 이 mount 상태 일 때 만 check 가 가능하다.

1. Oracle Software 변경 관리
   
   1. Patch 적용 Process
      

• 평상시 : 운영장비로의 Patch 적용은 사전에 테스트 장비를 이용하여 적용한 후 일정 시간 모니터링 후 적용한다.
  

• 긴급 상황 시 : 긴급하게 조치해야 할 장애를 위한 패치는 경우에 따라 테스트 장비에서의 점검 프로세스를 생략할 수도 있다.
  

1. 적용된 패치 확인
   

• 다음 명령어를 통하여 적용된 패치를 확인할 수 있다.
  

Rac system comprising of multiple nodes

Local node = XXXDB01

Remote node = XXXDB02

——————————————————————————–

OPatch succeeded.

1. Patch 적용
   

• Patch 적용 전 적용되는 제품(Clusterware, Database, Listener)은 종료한다.
  
• Download 받은 Patch File을 적당한 곳에 두고 압축을 푼다.
  
• 패치마다 적용 방법이 다르므로 README.txt 또는 README.html 파일의 지시에 따른다.
  
• RAC 의 경우 기본적으로 모든 노드에 동시에 적용되므로, 노드 각각에 따로 적용하는 경우 반드시 -local option을 사용한다.
  
• Patch 적용 확인 후 종료된 제품을 시작한다.
  
• Opatch 사용 방법 및 옵션 사항
  

1. Oracle Database Parameter 변경 관리
   
   oracle Database의 Parameter의 설정 값에 따라 system에 미치는 영향이 다양하다. 이에 충분한 검토가 사전에 필요하며, 관련 팀과의 협조가 필요한 부분에 대해서는 조율을 통해 조정토록 한다. Parameter변경은 변경 이력 관리를 통해 사후에 조정될 항목을 미리 점검해 보며, 문제점과 위험성을 도출해 사전 제거토록 한다.
   
   1. Parameter 변경 Process
      
      
      
   1. Parameter 변경 방법
      
      XXXDB Database는 SPFile (Server Parameter File) 를 사용하므로 Parameter 변경 시 SQL*Plus 를 사용해야 한다.
      

1. 주요 Parameter
   

1. Parameter 적용 예제
   

1. Oracle 로그 파일 관리
   
   1. ADR(Automatic Diagnostic Repository)
      
      11g의 새로운 기능으로 ADR(Automatic Diagnostic Repository)이라는 concept으로 관리 되며 ADR은 기존에 BDUMP와 UDUMP로 나뉘어 관리되던 것을 한 곳에 모아 관리하고 손쉽게 Oracle Support에 그 Data를 전달할 수 있다.
      
      1. ADR 관련 Parameter
         

1. ADR 관련 로그 확인
   

Oracle Database 및 listener 로그는 자동으로 삭제되지 않는다. 따라서 주기적으로 복사 후 삭제가 필요하다. Database에서 문제 발생시 또는 Action에 대한 Log는 중요한 역할을 하기 때문에 일정기간 보관 후 삭제한다.

1. CRS 관련 로그
   

1. 백업과 복구
   
   1. 백업 개요
      
      오라클은 다양한 백업(Back-up) 기능을 제공한다. 오라클은 백업의 형태에 따라 데이터베이스가 붕괴된 시점까지도 복구할 수 있다. 그러나, 오라클을 복구하는 과정에서 기본이 되는 것은 데이터베이스 백업(Backup) 이다. 즉, 데이터베이스의 일관성 있는 백업이 선행되어야 오라클 복구(Recovery) 작업도 수월하게 이루어질 수 있다.
      오라클은 ARCHIVELOG 모드이냐 NOARCHIVELOG 모드로 운영되느냐에 따라 백업의 형태가 달라지며 백업 정책도 달라진다. 각 모드마다 장단점이 있지만 ARCHIVE 모드가 물론 더 안정적이다.
      

      	Offline Backup	Online Backup	Export
      Datafile 과의 관계	Database를 구성하는 Datafile들을 논리적인 내용과는 무관하게 복사하는 방법		물리적인 위치와 무관하게 Database내용을 읽어서 file(dump)에 기록하는 방법
      DBMS 운영 방법	Archive모드, Noarchive모드로 운영가능	Archive모드 운영 시만 가능	Archive모드, Noarchive모드로 운영가능
      DBMS 기동 상태	DBMS 정상 정지 후 사용가능	DBMS 운영 중에만 사용가능	DBMS 운영 중에만 사용가능
      Archive 모드로 운영 시	장애 발생시점까지 복구 가능	장애 발생시점까지 복구 가능	Export 받은 시점까지만 복구 가능
      Noarchive 모드로 운영 시	Cold Backup, 받은 시점까지만 복구가능	적용 불가능	Export 받은 시점까지만 복구 가능

      Oracle ASM 환경에서의 Online Backup은 RMAN으로만 가능하므로 RMAN 기능에 대한 내용은 10장에 소개하고, Export/Import 에 대한 내용은 다음과 같다.
   2.  
   3. 오라클에서 제공하는 백업의 종류는 다음과 같다.
   4. 데이터베이스를 구축한다는 것은 하나의 데이터를 여러 유저가 공유하기 위함도 있지만 무엇보다도 데이터의 안정성이다. 만일의 사태가 발생하더라도 데이터의 손실을 막는 것에 목적이 있다.
      
   5. Export / Import
      
      Export 는 Database 에 저장된 내용을 file 형태의 O/S dump file 로 추출하는 tool이다. 반대로 import 는 export 로 받은 O/S Dump file 을 database 에 저장시키는 tool 이다.
      
      1. Export option
         
   6. Export / Import 는 모든 user 들의 전체 backup 이나 user 단위, 또는 특정 object만 backup 할 수 있으므로 database 의 backup 은 물론, Oracle database 간의 data 이동이나, Oracle 의 새로운 version upgrade 등에 사용될 수 있으며 문제발생시 특정 object 별 복구가 가능하다는 장점이 있는 반면에, database 복구 시, 물리적인 backup ( cold backup, hot backup ) 과 상호 관련성이 없기 때문에 장애 발생 시점까지의 복구는 불가능하며, 단지 export 를 수행한 시점까지의 복구만이 가능하기 때문에 export 를 이용한 복구는 data 의 손실을 감안하여야 한다는 단점이 있다.
      

1. Import option