놀멍

Redo Log 튜닝 방법

argoLee — Fri, 7 Jun 2024 10:21:07 +0900

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:티스토리]

OGG19c EXTRACT/REPLICAT 구성 방법

argoLee — Thu, 21 Mar 2024 15:30:52 +0900

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

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

소스(PDB):	대상(CDB 아님):
호스트 이름: racnode1	호스트 이름: Standbyracnode
IP: 192.168.24.1	IP: 192.168.24.3
RDBMS: 19c	RDBMS: 19c
SID: cdb19c1	SID: devdbnoncdb
PDB: CDB19C_PDB	PDB: 해당 없음
ORACLE_HOME: /u01/app/oracle/product/19c/dbhome_1	ORACLE_HOME: /u01/app/oracle/product/19c/db_1
골든게이트 홈: /u01/app/goldengate/19.1.0.0/	골든게이트 홈: /u01/app/goldengate/19.1.0.0/

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 생성하기

argoLee — Fri, 8 Mar 2024 17:16:28 +0900

LISTENER.ORA, TNSNAMES.ORA 생성하기

오라클 데이터베이스 19c 를 Silent 설치를 하고 나면 listener.ora, tnsnames.ora 가 생성되지 않는다. 어떻게 수동으로 이것을 생성하는지에 대해서 알아보고 차이에 대해서 간단히 설명한다.

신기하게도 오라클 데이터베이스 19c를 Silent 설치하고 난 후에 이것을 생성하지 않는다고 하더라도 원격 클라이언트 접속에는 아무런 문제가 되지 않는다. 하지만 접속 서비스를 할당하고 접속을 쪼개고 싶다면 tnsnames.ora 파일이 반드시 있어야 한다.

Oracle Net Listener

Listener 는 정확하게는 ‘Oracle Net Listener’ 라고 한다. 리스너는 하나 혹은 그 이상의 지원하는 서비스에 대한 정보, 프로토콜 주소들을 리스닝하도록 설정된다. 리스너의 설정 정보는 listener.ora 파일에 저장된다. 모든 설정 파라메터는 디폴트 값을 가지기 때문에 별도의 설정을 하지 않더라도 시작하는데 문제가 없다. 디폴트 리스너는 LISTENER 라는 이름을 가지고 시작시 아무런 서비스를 지원하지 않으며 다음과 같은 TCP/IP 프로토콜 주소만 리스닝한다.

디폴트 리스너의 TCP/IP 프로토콜 주소 리스닝

1	(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))

리스너는 클라이언트 요청을 지원하는 서비스로 포워드 한다. 이러한 서비스들은 listener.ora 파일에 정적으로 설정되어지거나 리스너로 동적으로 등록되어질 수 있다. 이러한 등록 기능을 서비스 등록(service registration) 이라고 부른다. 등록은 PMON process 에 의해서 실행된다.

참고: Configuring and Administering Oracle Net Listener

생성하기

오라클 데이터베이스 19c 를 Silent 설치하게되면 리스너 설정 파일이 생성되지 않는다. 생성하기 위해서 netca 명령어를 이용할 텐데, 역시나 Silent 모드로 실행을 해준다. 그러기 위해서는 response 파일이 있어야 하는데, 다음과 같은 경로에 있다.

netca 를 위한 response 파일

ZSH

1 2	$ ls $ORACLE_HOME/assistants/netca/netca.rsp /u01/app/oracle/product/19.3.0/dbhome_1/assistants/netca/netca.rsp

파일을 열어보면 좀 복잡해 보이는데, 주석 등을 제거하면 설정된 값은 다음과 같다.

netca.rsp 설정

ZSH

$ cat $ORACLE_HOME/assistants/netca/netca.rsp | grep -v ^$| grep -v ^#

[GENERAL]

RESPONSEFILE_VERSION="19.0"

CREATE_TYPE="CUSTOM"

[oracle.net.ca]

INSTALLED_COMPONENTS={"server","net8","javavm"}

INSTALL_TYPE=""typical""

LISTENER_NUMBER=1

LISTENER_NAMES={"LISTENER"}

LISTENER_PROTOCOLS={"TCP;1521"}

LISTENER_START=""LISTENER""

NAMING_METHODS={"TNSNAMES","ONAMES","HOSTNAME"}

NSN_NUMBER=1

NSN_NAMES={"EXTPROC_CONNECTION_DATA"}

NSN_SERVICE={"PLSExtProc"}

NSN_PROTOCOLS={"TCP;HOSTNAME;1521"}

내용들은 그냥 디폴트 값을 가지고 있다. 오라클 데이터베이스가 listener.ora 파일이 없이 잘 작동하는 이유가 위 파일의 값을 가지고 작동하기 때문인 것인데, 그렇다면 이것을 가지고 설정 파일을 만들어도 문제가 없다는 것과 같은 의미가 된다.

listener.ora 파일 생성

ZSH

]$ netca -silent -responsefile $ORACLE_HOME/assistants/netca/netca.rsp

Parsing command line arguments:

Parameter "silent" = true

Parameter "responsefile" = /u01/app/oracle/product/19.3.0/dbhome_1/assistants/netca/netca.rsp

Done parsing command line arguments.

Oracle Net Services Configuration:

Profile configuration complete.

Oracle Net Listener Startup:

Running Listener Control:

/u01/app/oracle/product/19.3.0/dbhome_1/bin/lsnrctl start LISTENER

Listener Control complete.

Listener started successfully.

Listener configuration complete.

Oracle Net Services configuration successful. The exit code is 0

실행을 하게되면 listener.ora 파일이 생성되면서 리스너가 시작된다.

여기서 멀티테넌트 데이터베이스 구조일 경우에 PDB 에 따른 별도의 클라이언트 접속 요청을 처리해줄 필요가 있게된다. 리스너가 클라이언트 요청 파라메터에 PDB 의 SID 나 SERVICE 가 포함될 경우에 이를 받아서 처리해줘야 하는데, 그러기 위해서는 SID_LIST_LISTENER 엔트리를 사용해야 한다.

listener.ora 에 SID_LIST_LISTENER

ZSH

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = O19C)

(SID_NAME = o19c)

)

(SID_DESC =

(GLOBAL_DBNAME = PDB1)

(SID_NAME = pdb1)

)

위 내용을 생성한 listener.ora 에 추가해 준다.

주요한 설정 내용은 다음과 같다.

SID_NAME – oracle System IDentifier 초기 설정 파라메터 파일에 INSTANCE_NAME 으로부터 SID 값을 얻을 수 있다.
GLOBAL_DBNAME – 데이터베이스 서비스다. 클라이언트 접속 요청을 처리하는 동안, 리스너는 클라이언트 접속 디스크립터에 SERVICE_NAME 파라메터 값과 이 파라메터의 값을 매치시킬려고 한다. 만약 클라이언트 접속 디스크립터가 SID 파라메터를 사용한다면 리스너는 더 이상 매칭 시도를 하지 않는다. 이 파라메터는 전용 서버에서 다이나믹 설정을 지원하지 않는 Oracle8 데이터베이스 설정을 위한 것이였다. 이 파라메터는 Oracle8i 나 그 이후에 데이터베이스 서비스 사용을 위해 필요할 수도 있다. 이 파라메터 값은 기본적으로 초기화 파라메터 파일에 DB_NAME 과 DB_DOMAIN 파라메터의 조합으로부터 (DB_NAME.DB_DOMAIN) 얻을 수 있다.
ORACLE_HOME – 오라클 인스턴스의 위치. 세팅하지 않으면 오라클 홈 디렉토리으로 가정한다. 리눅스와 유닉스에서 세팅은 옵션이지만 MS Windows 에서는 세팅을 무시하면 레지스트리 값 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEID 를 사용한다.

오라클 데이터베이스의 컨테이너별 서비스를 알기위해서는 다음의 쿼리를 실행하면 된다.

오라클 데이터베이스 서비스들

PgSQL

SQL> SELECT name, pdb

FROM v$services

ORDER BY name;

NAME PDB

SYS$BACKGROUND CDB$ROOT

SYS$USERS CDB$ROOT

o19c CDB$ROOT

o19cXDB CDB$ROOT

pdb1 PDB1

Local Naming Prarameters in the tnsnames.ora 파일

tnsnames.ora 파일은 네트워크 서비스 이름을 접속 디스크립트로 매핑하거나, Net 서비스 이름을 리스너 프로토콜 주소로 맵핑을 포함한 설정 파일이다. Net 서비스 이름은 접속 디스크립터를 포함하는 데이터베이스 네트워크 주소와 연결된 별명(Alias) 이다. 접속 드스크립터는 프로토콜 주소를 통한 리스너의 위치와 연결을 위한 데이터베이스 서비스의 이름을 포함한다. 클라이언트와 서버는 애플리케이션에서 연결할대에 Net 서비스 이름을 사용한다.

오라클 멀티테넌트 데이터베이스에서 CDB, PDB 별로 접속을 하기 위해서는 tnsnames.ora 파일을 다음과 같이 생성해 준다.

tnsnames.ora 파일 내용

O19C =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oradb1.systemv.local)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = o19c)

)

PDB1 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = oradb1.systemv.local)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = pdb1)

)

참고: Local Naming Parameters in the tnsnames.ora File

listener.ora, tnsnames.ora 차이

접속하는 방법에 차이를 둔다. 원칙적으로 접속하는 방법은 다음과 같다.

Direct 접속방법

ZSH

1	]$ sqlplus hr/HrPassword1@oradb1.systemv.local:1521/pdb1

@ 를 기준으로 뒤에 있는 호스트네임:포트/서비스 이다. 이것은 Direct 연결 방법이라고 하는데, 이 연결은 listener.ora 에 정의된 리스너 설정파일에 의해서 접속이 이루어진다.

이것을 짧게 별명만으로 지정할 수 있는데, 그것을 가능하게 하는 것이 tnsnames.ora 이다. pdb1 컨테이너에 접속하기 위해서는 PDB1 별명을 사용하기 때문에 다음과 같이 해도 된다.

Alias 를 이용한 접속방법

ZSH

1	]$ sqlplus hr/HrPassword1@PDB1

PDB1 은 tnsnames.ora 파일에서 별명을 찾아서 접속 디스크립트에 값을 가져다 쓴다. 그리고 연결을 시도하고 이것을 오라클 리스너가 받아서 listener.ora 파일에 파라메터와 매핑해 접속이 이루어지게 된다.

멀티테넌트 데이터베이스 구조에서는 listener.ora 파일에서 SID_LIST_LISTENER 설정을 해줘야지만 PDB 에 접속이 가능해진다.

Begin Backup 명령을 사용한 백업 복원 및 Archive 파일

argoLee — Mon, 4 Mar 2024 13:19:20 +0900

. 사전 용어

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

오라클의 블럭단위 : 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가 필요하다.

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

argoLee — Thu, 29 Feb 2024 13:06:07 +0900

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를 지원할 수 있다.

select a.name “Group_Name”,a.total_mb,a.free_mb,b.name “Disk_Name”,b.failgroupfrom v$asm_diskgroup a, v$asm_disk b

where a.group_number = b.group_number
/
Group_Name TOTAL_MB FREE_MB Disk_Name FAILGROUP
————————————————————————————————————–

FIRST 4016 2044 FIRST_0002 THIRD
FIRST 4016 2044 FIRST_0003 THIRD

FIRST 4016 2044 FIRST_0000 SECOND

FIRST 4016 2044 FIRST_0001 SECOND

SECOND 2008 1956 SECOND_0000 SECOND_0000

SECOND 2008 1956 SECOND_0001 SECOND_0001
THIRD 2008 1956 THIRD_0000 THIRD_0000

THIRD 2008 1956 THIRD_0001 THIRD_0001

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에서 출력된 정보를 비교해 보기 바란다.

SELECT FILE_NUMBER,BLOCK_SIZE,BLOCKS,BYTES,SPACE,TYPE,REDUNDANCY,STRIPED
FROM V$ASM_FILE;

F_NUMBER BLOCK_SIZE BLOCKS BYTES SPACE TYPE REDUNDANCY STRIPED

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

256 8192 56321 461381632 927989760 DATAFILE MIRROR COARSE

257 8192 25601 209723392 424673280 DATAFILE MIRROR COARSE

258 8192 6401 52436992 106954752 DATAFILE MIRROR COARSE

259 8192 641 5251072 12582912 DATAFILE MIRROR COARSE

260 8192 283 2318336 16777216 CONTROLFILE MIRROR FINE

261 512 20481 10486272 33554432 ONLINELOG MIRROR FINE

262 512 20481 10486272 33554432 ONLINELOG MIRROR FINE

263 512 20481 10486272 33554432 ONLINELOG MIRROR FINE

264 8192 2945 24125440 50331648 TEMPFILE MIRROR COARSE

265 8192 19201 157294592 319815680 DATAFILE MIRROR COARSE

266 512 5 2560 2097152 PARAMETERF MIRROR COARSE

FILE_NAME M
—————————————————————————

+FIRST/cook/datafile/system.256.1 440

+FIRST/cook/datafile/sysaux.257.1 200

+FIRST/cook/datafile/undotbs1.258.1 50

+FIRST/cook/datafile/users.259.1 5

+FIRST/cook/example01.dbf 150

+FIRST/cook/controlfile/current.260.1

+FIRST/cook/onlinelog/group_1.261.1 10

+FIRST/cook/onlinelog/group_2.262.1 10

+FIRST/cook/onlinelog/group_3.263.1 10

+FIRST/cook/tempfile/temp.264.1 23

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의 예를 보여준다.

group_num entry_num REDUND STRIPE S NAME
———- ———- —— —— – ——————-

1 0 MIRROR COARSE Y PARAMETERFILE

1 1 MIRROR COARSE Y DUMPSET

1 2 MIRROR FINE Y CONTROLFILE

1 3 MIRROR COARSE Y ARCHIVELOG

1 4 MIRROR FINE Y ONLINELOG

1 5 MIRROR COARSE Y DATAFILE

1 6 MIRROR COARSE Y TEMPFILE

1 7 MIRROR COARSE Y BACKUPSET

1 8 MIRROR COARSE Y AUTOBACKUP

1 9 MIRROR COARSE Y XTRANSPORT

1 10 MIRROR COARSE Y CHANGETRACKING

1 11 MIRROR FINE Y FLASHBACK

1 12 MIRROR COARSE Y DATAGUARDCONFIG

2 0 UNPROT COARSE Y PARAMETERFILE

2 3 UNPROT COARSE Y ARCHIVELOG

2 5 UNPROT COARSE Y DATAFILE

2 7 UNPROT COARSE Y BACKUPSET

2 12 UNPROT COARSE Y DATAGUARDCONFIG

2 11 UNPROT FINE Y FLASHBACK

2 10 UNPROT COARSE Y CHANGETRACKING

2 9 UNPROT COARSE Y XTRANSPORT

2 8 UNPROT COARSE Y AUTOBACKUP

2 6 UNPROT COARSE Y TEMPFILE

2 4 UNPROT FINE Y ONLINELOG

2 2 UNPROT FINE Y CONTROLFILE

2 1 UNPROT COARSE Y DUMPSET

3 0 UNPROT COARSE Y PARAMETERFILE

3 1 UNPROT COARSE Y DUMPSET

3 2 UNPROT FINE Y CONTROLFILE

3 3 UNPROT COARSE Y ARCHIVELOG

3 4 UNPROT FINE Y ONLINELOG

3 5 UNPROT COARSE Y DATAFILE

3 6 UNPROT COARSE Y TEMPFILE

3 7 UNPROT COARSE Y BACKUPSET

3 8 UNPROT COARSE Y AUTOBACKUP

3 9 UNPROT COARSE Y XTRANSPORT

3 10 UNPROT COARSE Y CHANGETRACKING

3 11 UNPROT FINE Y FLASHBACK

3 12 UNPROT COARSE Y DATAGUARDCONFIG

39 rows selected.

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에 의해 수동으로 발생될 수 있다(사실 수동 작업은 필요 없다).

Oracle 12C RAC DB 운영 매뉴얼

argoLee — Thu, 29 Feb 2024 13:04:56 +0900

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

Oracle 12c R1 RAC (Real Application Cluster)

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

Oracle 12c RAC Architecture

네트워크 구성정보

Hostname	Public IP	Private IP	Virtual IP	SCAN IP
XXXDB01	172.30.xxx.xxx	11.0.0.1	172.30.xxx.xxx	172.30.xxx.xxx
XXXDB02	172.30.xxx.xxx	11.0.0.2	172.30.xxx.xxx	172.30.xxx.xxx

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

Cluster Ready Services (CRS)

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

Event Manager

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

Process Monitor Daemon(OPROCD)

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

Global Service Daemon(GSD)

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

Virtual IP

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

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등록)

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

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

Voting Disk

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

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

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

# cd /grid/12.1.0.2/bin
# ./crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

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

# su – oracle
$ srvctl start database -database -d XXXDB — 모든 node의 instance 기동
$ srvctl start instance -d XXXDB -i XXXDB1 — XXXDB1 instance만 기동

Oracle Clusterware 정지

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

# su – oracle
$ srvctl stop database -database -d XXXDB — 모든 node의 instance 정지
$ srvctl stop instance -d XXXDB -i XXXDB1 — XXXDB1 instance만 정지

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

# cd /grid/12.1.0.2/bin
# ./crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘XXXDB01’
CRS-2673: Attempting to stop ‘ora.crsd’ on ‘XXXDB01’

CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.DG_CRS.dg’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.DG_DATA.dg’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.DG_ARCH.dg’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.LISTENER.lsnr’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.LISTENER_SCAN1.lsnr’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.oc4j’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.cvu’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.cvu’ on ‘XXXDB01’ succeeded

CRS-2672: Attempting to start ‘ora.cvu’ on ‘ktms1’

CRS-2677: Stop of ‘ora.LISTENER.lsnr’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.XXXDB01.vip’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.LISTENER_SCAN1.lsnr’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.scan1.vip’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.DG_CRS.dg’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.DG_DATA.dg’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.DG_ARCH.dg’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.DG_CRS.dg’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.DG_DATA.dg’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.DG_ARCH.dg’ on ‘XXXDB01’

CRS-2676: Start of ‘ora.cvu’ on ‘ktms1’ succeeded

CRS-2677: Stop of ‘ora.DG_CRS.dg’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.DG_DATA.dg’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.DG_ARCH.dg’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.asm’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.asm’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.scan1.vip’ on ‘XXXDB01’ succeeded

CRS-2672: Attempting to start ‘ora.scan1.vip’ on ‘ktms1’

CRS-2677: Stop of ‘ora.XXXDB01.vip’ on ‘XXXDB01’ succeeded

CRS-2672: Attempting to start ‘ora.XXXDB01.vip’ on ‘ktms1’

CRS-2677: Stop of ‘ora.oc4j’ on ‘XXXDB01’ succeeded

CRS-2672: Attempting to start ‘ora.oc4j’ on ‘ktms1’

CRS-2676: Start of ‘ora.scan1.vip’ on ‘ktms1’ succeeded

CRS-2672: Attempting to start ‘ora.LISTENER_SCAN1.lsnr’ on ‘ktms1’

CRS-2676: Start of ‘ora.XXXDB01.vip’ on ‘ktms1’ succeeded

CRS-2676: Start of ‘ora.LISTENER_SCAN1.lsnr’ on ‘ktms1’ succeeded

CRS-2676: Start of ‘ora.oc4j’ on ‘ktms1’ succeeded

CRS-2673: Attempting to stop ‘ora.ons’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.ons’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.net1.network’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.net1.network’ on ‘XXXDB01’ succeeded

CRS-2792: Shutdown of Cluster Ready Services-managed resources on ‘XXXDB01’ has completed

CRS-2677: Stop of ‘ora.crsd’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.crf’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.ctssd’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.evmd’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.storage’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.gpnpd’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.drivers.acfs’ on ‘XXXDB01’

CRS-2673: Attempting to stop ‘ora.mdnsd’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.drivers.acfs’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.storage’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.asm’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.crf’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.ctssd’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.mdnsd’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.gpnpd’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.evmd’ on ‘XXXDB01’ succeeded

CRS-2677: Stop of ‘ora.asm’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.cluster_interconnect.haip’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.cluster_interconnect.haip’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.cssd’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.cssd’ on ‘XXXDB01’ succeeded

CRS-2673: Attempting to stop ‘ora.gipcd’ on ‘XXXDB01’

CRS-2677: Stop of ‘ora.gipcd’ on ‘XXXDB01’ succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on ‘XXXDB01’ has completed

CRS-4133: Oracle High Availability Services has been stopped.

Oracle Clusterware 상태 확인

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

# su – grid
$ crsctl check cluster -all
**************************************************************
XXXDB01:

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

**************************************************************

CRS 리소스 상태 확인

$ crsctl status res -t
——————————————————————-
Name Target State Server State details
——————————————————————-

Local Resources

——————————————————————-

ora.DG_ARCH.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_CRS.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_DATA.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.LISTENER.lsnr

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.asm

ONLINE ONLINE XXXDB01 Started,STABLE

ONLINE ONLINE XXXDB02 Started,STABLE

ora.net1.network

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.ons

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

Cluster Resources

——————————————————————-

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE XXXDB01 STABLE

ora.MGMTLSNR

1 ONLINE ONLINE XXXDB01 169.254.110.154 11.0

.0.1,STABLE

ora.cvu

1 ONLINE ONLINE XXXDB01 STABLE

ora.mgmtdb

1 ONLINE ONLINE XXXDB01 Open,STABLE

ora.oc4j

1 ONLINE ONLINE XXXDB01 STABLE

ora.scan1.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB.db

1 ONLINE ONLINE XXXDB01 Open,STABLE

2 ONLINE ONLINE XXXDB02 Open,STABLE

ora.XXXDB01.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB02.vip

1 ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

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

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

# su – oracle
$ srvctl start database -database -d XXXDB — 모든 node의 instance 기동
$ srvctl start instance -d XXXDB -i XXXDB1 — XXXDB1 instance만 기동

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

$ crsctl stat res -t
——————————————————————-
Name Target State Server State details
——————————————————————-

Local Resources

——————————————————————-

ora.DG_ARCH.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_CRS.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_DATA.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.LISTENER.lsnr

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.asm

ONLINE ONLINE XXXDB01 Started,STABLE

ONLINE ONLINE XXXDB02 Started,STABLE

ora.net1.network

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.ons

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

Cluster Resources

——————————————————————-

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE XXXDB01 STABLE

ora.MGMTLSNR

1 ONLINE ONLINE XXXDB01 169.254.110.154 11.0

.0.1,STABLE

ora.cvu

1 ONLINE ONLINE XXXDB01 STABLE

ora.mgmtdb

1 ONLINE ONLINE XXXDB01 Open,STABLE

ora.oc4j

1 ONLINE ONLINE XXXDB01 STABLE

ora.scan1.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB.db

1 ONLINE ONLINE XXXDB01 Open,STABLE

2 ONLINE ONLINE XXXDB02 Open,STABLE

ora.XXXDB01.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB02.vip

1 ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

DB Instance 정지

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

# su – oracle
$ srvctl stop database -database -d XXXDB — 모든 node의 instance 정지
$ srvctl stop instance -d XXXDB -i XXXDB1 — XXXDB1 instance만 정지

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

$ crsctl stat res -t
——————————————————————-
Name Target State Server State details
——————————————————————-

Local Resources

——————————————————————-

ora.DG_ARCH.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_CRS.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_DATA.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.LISTENER.lsnr

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.asm

ONLINE ONLINE XXXDB01 Started,STABLE

ONLINE ONLINE XXXDB02 Started,STABLE

ora.net1.network

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.ons

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

Cluster Resources

——————————————————————-

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE XXXDB01 STABLE

ora.MGMTLSNR

1 ONLINE ONLINE XXXDB01 169.254.110.154 11.0

.0.1,STABLE

ora.cvu

1 ONLINE ONLINE XXXDB01 STABLE

ora.mgmtdb

1 ONLINE ONLINE XXXDB01 Open,STABLE

ora.oc4j

1 ONLINE ONLINE XXXDB01 STABLE

ora.scan1.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB.db

1 OFFLINE OFFLINE XXXDB01 Instance Shutdown,ST

ABLE

2 ONLINE ONLINE XXXDB02 Open,STABLE

ora.XXXDB01.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB02.vip

1 ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

Listener 기동과 정지
1. Listener 기동

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

# su – grid
$ srvctl start listener -n XXXDB01 — XXXDB01 node의 listener 기동

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

Listener 정지

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

# su – grid
$ srvctl stop listener -n XXXDB01 — XXXDB01 node의 listener 정지

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

$ crsctl stat res -t
——————————————————————-
Name Target State Server State details
——————————————————————-

Local Resources

——————————————————————-

ora.DG_ARCH.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_CRS.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.DG_DATA.dg

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.LISTENER.lsnr

OFFLINE OFFLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.asm

ONLINE ONLINE XXXDB01 Started,STABLE

ONLINE ONLINE XXXDB02 Started,STABLE

ora.net1.network

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

ora.ons

ONLINE ONLINE XXXDB01 STABLE

ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

Cluster Resources

——————————————————————-

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE XXXDB01 STABLE

ora.MGMTLSNR

1 ONLINE ONLINE XXXDB01 169.254.110.154 11.0

.0.1,STABLE

ora.cvu

1 ONLINE ONLINE XXXDB01 STABLE

ora.mgmtdb

1 ONLINE ONLINE XXXDB01 Open,STABLE

ora.oc4j

1 ONLINE ONLINE XXXDB01 STABLE

ora.scan1.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB.db

1 ONLINE ONLINE XXXDB01 Open,STABLE

2 ONLINE ONLINE XXXDB02 Open,STABLE

ora.XXXDB01.vip

1 ONLINE ONLINE XXXDB01 STABLE

ora.XXXDB02.vip

1 ONLINE ONLINE XXXDB02 STABLE

——————————————————————-

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

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

$ sqlplus “/as sysdba”
SQL> create user test_user identified by test_user
default tablespace test_data
temporary tablespace test_tmp;

새로운 User 권한 부여

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

$ sqlplus “/as sysdba”
SQL> grant resource, connect to test_user;

User 패스워드 변경

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

$ sqlplus “/as sysdba”
SQL> alter user test_user identified by test

User 삭제

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

$ sqlplus “/as sysdba”
SQL> drop user test_user cascade;

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

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 생성시 사용자 임의로 지정한다.

Tablespace 추가 및 삭제

구분	파일 구분	SQL 수행
파일 추가	Datafile	alter tablespace test_data add datafile ‘+DG_DATA’ size 30000M;
파일 추가	TEMP File	alter tablespace test_tmp add tempfile ‘+DG_DATA’ size 30000M;
신규 생성	Data TBS	create tablespace test_data datafile ‘+DG_DATA’ size 30000M;
	TEMP TBS	create temporary tablespace test_tmp tempfile ‘+DG_DATA’ size 30000M;
	UNDO TBS	create undo tablespace UNDOTBS1 datafile ‘DG_DATA’ size 30000M;
삭제		drop tablespace test_data including contents and datafiles;

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

select * from (
select df.tablespace_name tablespace_name, round(df.total_bytes/1024/1024,2) total_MB,
round((df.total_bytes-fs.free_bytes)/1024/1024,2) used_MB, round(((df.total_bytes-fs.free_bytes)/df.total_bytes)*100,2) used_pct,
round(fs.free_bytes/1024/1024,2) free_MB

from (select tablespace_name, sum(bytes) total_bytes from dba_data_files group by tablespace_name) df,

(select tablespace_name,sum(bytes) free_bytes,max(bytes) max_free from dba_free_space group by tablespace_name) fs

where df.tablespace_name = fs.tablespace_name(+)

union all

select c.tablespace_name, round(sum(b.bytes)/1024/1024,2) total_MB, round(sum(a.bytes_used)/1024/1024,2) used_MB,

round((sum(a.bytes_used)/sum(b.bytes))*100,2) used_pct, round((sum(b.bytes)-sum(a.bytes_used))/1024/1024,2) free_mb

from (select bytes_used, file_id from v$temp_extent_pool) a,

(select bytes, file#, name from v$tempfile) b,

(select file_name, file_id, tablespace_name from dba_temp_files) c

where a.file_id=b.file# and b.file#=c.file_id

group by c.tablespace_name

)

order by 4 desc;

TABLESPACE_NAME TOTAL_MB USED_MB USED_PCT FREE_MB

—————————— ———- ———- ———- ———-

SYSTEM 1024 617.38 60.29 406.63

SYSAUX 1024 451.88 44.13 572.13

UNDOTBS1 1024 180.56 17.63 843.44

UNDOTBS2 1024 136 13.28 888

USERS 500 1.38 .28 498.63

TEMP 1024 0 0 1024

ASM diskgroup 사용률 조회

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

SELECT name, free_mb, total_mb, round(free_mb/total_mb*100,2) as percentage
FROM v$asm_diskgroup;
NAME FREE_MB Total Size (MB) PERCENTAGE
—————————— ———- ————— ———-

DG_CRS 576 10240 5.63

DG_DATA 718312 1013756 70.86

DG_ARCH 506621 511996 99.0

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이 관리하는 영역에서 새로운 디스크가 추가되거나 삭제될 때마다, 기존 데이터들에 대해 재구성 작업이 자동적으로 일어난다.

ASM의 기본 개념

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

ASM 주요 기능 및 특징

구분	내용
관리 복잡성 제거	매일 처리해야만 하는 스토리지 관리항목이 줄어들거나 제거된다. 모든 Application load에 대해 자동적인 I/O 튜닝이 수행된다. 생성되는 데이터파일에 대해 의미 있는 이름이 자동적으로 부여된다. 관리대상이 혁신적으로 줄어든다(파일시스템과 LVM 관리범위가 ASM Diskgroup 으로 통합 관리됨) 구성이 변경될 때, 자동적으로 데이터 재 분배가 발생한다. 실수로 파일을 삭제할 가능성 배제 (파일시스템 상에 데이터파일이 있는 것이 아니기 때문)
스토리지 제품 구입비용 절약	Logical Volume Manager와 파일시스템 기능이 데이터베이스에 포함되어 있다. 저렴한 JBOD 형태의 디스크부터 고가의 SAN 디스크 Array까지 지원
성능/확장/안전성 증대	모든 파일에 대해서 RAW Disk 수준의 I/O 성능을 보장한다. 다른 디스크 Array에 걸쳐 저장되어 있는 데이터파일 들에 대해 striping 할 수 있다. 스토리지 활용도 증대 시킨다. 일반적인 파일시스템 크기 제한을 극복 할 수 있다 Software mirroring 지원
RAC (Real Application Cluster) 지원	3rd Party Logical Volume Manager와 Cluster 파일시스템이 필요 없다.

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

구분	Local File System	Cluster File System	ASM	NAS/NFS	Raw/Block Device
Oracle Software	YES	YES	NO	YES	NO
Application Related Files	YES	YES	NO	YES	NO
Clusterware Configuration	NO	YES	YES	YES	YES
Principal Database Files	YES	YES	YES	YES	YES
Database Archived log	YES	YES	YES	YES	NO
Database External Files	YES	YES	NO	YES	NO
RMAN Backup Files	YES	YES	YES	YES	NO

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

구분	내용
구조	Oracle ASM은 Oracle Database Instance와 동일한 구조로 생성돼 운영됨 Oracle ASM Instance도 SGA 영역을 가지며 Database를 mount하지는 않음 Oracle ASM은 Oracle Database가 Install되기 전 다른 Oracle Home에 설치됨 Oracle clusterware를 통해 cluster되며 Node마다 Database Instance 수와 관계없이 1개의 ASM Instance가 필요함
관리정보	Oracle ASM은 Disk Group에 대한 Meta Data를 관리하며 Database Instance에게 File Layout 정보를 제공함 관리대상 Metadata 정보 Disk Group에 속하는 Disk Disk Group의 가용 공간 크기 Disk Group에 속하는 File 이름 Disk Group의 Data file Extent 위치 Metadata Block 변경에 대한 Redo Log Oracle ADVM(Oracle ASM Dynamic Volume Manager) Volume 정보
장애/복구	Oracle ASM Instance 장애가 발생할 경우 해당 Node에 존재하는 모든 Database Instance 모두 장애가 발생함 ASM Instance 장애 시 OS Reboot이 필요치 않으며 RAC 환경에서는 가용 Node로 Failover, Recovery 후 업무를 재개할 수 있음

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 는 디스크 그룹 관리를 위한 정보를 담고 있고, 생성된 디스크 그룹 내에 저장.

ASM Instance Processes

Process	내용
ARBn	ASM Rebalance를 수행하는 프로세스. 평상시엔 떠 있지 않다가 실제로 Rebalance를 수행하게 되면 나타남.
RBAL	ASM Rebalance를 담당하는 프로세스. Rebalance작업을 관리하며, 각 그룹에 할당된 모든 디스크에 대하여 데이터 재분배를 수행하게 됨. 이 프로세스는 항상 떠있으며, 사용자의 명령을 위해 대기 함.
GMON	ASM 디스크 그룹 내 디스크 멤버십을 관리
ASMB	데이터베이스 인스턴스 상에서 동작하며, ASM 인스턴스의 Foreground process와 통신 함. 주기적인 message 교환을 통해 통계정보를 공유하고, ASM과 데이터베이스 인스턴스 heartbeat 를 통한 health check을 수행.
MARK	Offline 디스크에 대한 재 동기화를 위해 ASM 할당 단위를 표시 하기 위한 프로세스.
Onnn	메시지를 교환하는 ASM 인스턴스에 대한 연결 풀을 형성하는 하나이상의 ASM 슬레이브 프로세스
PZ9n	하나이상의 병렬 슬레이브 프로세스.
ORBn	Rebalance시 ASM data extent의 이동을 담당하는 프로세스, ASM data extent의 이동이 발생하면 순간적으로 프로세스 개수가 여러 개 생길 수 있음.

ASM 디스크
1. ASM DiskGroup

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

ASM mirroring Option

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

Disk Group Type	Supported Mirroring Levels	Default Mirroring Level
External redundancy	Unprotected (none)	Unprotected
Normal redundancy	Two-way Three-way Unprotected (None)	Two-way
High redundancy	Three-way	Three-way

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

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에 의해 자동으로 지정됨

Striping

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

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

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

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 사용량을 제한할 수 있음

Mirroring

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

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

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

[grid@rac12c01 ~]$ sqlplus / as sysasm
SQL*Plus: Release 12.1.0.2.0 Production on Wed Jun 3 09:14:34 2015
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production

With the Real Application Clusters and Automatic Storage Management options

SQL> select instance_name, status from v$instance;

INSTANCE_NAME STATUS

—————- ————

+ASM1 STARTED

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

[root@rac12c01 ~]# crsctl status resource ora.asm -p
NAME=ora.asm
TYPE=ora.asm.type
[…]

GEN_USR_ORA_INST_NAME@SERVERNAME(XXXDB01)=+ASM1

GEN_USR_ORA_INST_NAME@SERVERNAME(XXXDB02)=+ASM2

ASM Diskgroup Creation

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

디스크 그룹 확인

SQL> select group_number, name, state from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
———— —————————— ———–
1 DG_CRS MOUNTED

2 DG_DATA MOUNTED

3 DG_ARCH MOUNTED

추가 할 디스크 확인

SQL> select group_number,mount_status,path,total_mb
from v$asm_disk
where mount_status=’CLOSED’;
GROUP_NUMBER MOUNT_S PATH TOTAL_MB

———— ——- ———————————– ———-

0 CLOSED /dev/sdb3 0

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

SQL> create diskgroup ORATEST external redundancy disk ‘/dev/sdb3’;
Diskgroup created.
SQL> select group_number,mount_status,path,total_mb
2 from v$asm_disk

3 where mount_status=’CLOSED’;

no rows selected

SQL> select group_number,name,state from v$asm_diskgroup;

GROUP_NUMBER NAME STATE

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

1 DG_CRS MOUNTED

2 DG_DATA MOUNTED

3 DG_ARCH MOUNTED

4 ORATEST MOUNTED

ASM Disk group Drop

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

ASM Disk group Mount/Umount

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

SQL> select group_number,name,state from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
———— —————————— ———–
1 DG_CRS MOUNTED

2 DG_DATA MOUNTED

3 DG_ARCH MOUNTED

4 ORATEST MOUNTED

SQL> alter diskgroup ORATEST dismount;

Diskgroup altered.

SQL> select group_number,name,state from v$asm_diskgroup;

GROUP_NUMBER NAME STATE

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

1 DG_CRS MOUNTED

2 DG_DATA MOUNTED

3 DG_ARCH MOUNTED

4 ORATEST DISMOUNTED

SQL> alter diskgroup ORATEST mount;

Diskgroup altered.

SQL> select group_number,name,state from v$asm_diskgroup;

GROUP_NUMBER NAME STATE

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

1 DG_CRS MOUNTED

2 DG_DATA MOUNTED

3 DG_ARCH MOUNTED

4 ORATEST MOUNTED

ASM Disk group disk add

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

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

SQL> select group_number,mount_status,path,total_mb
2 from v$asm_disk where mount_status=’CLOSED’;
GROUP_NUMBER MOUNT_S PATH TOTAL_MB
———— ——- —————————— ———

0 CLOSED /dev/sdb3 0

SQL> select b.name as group_name,

2 a.name as disk_name,

3 a.header_status,

4 a.state,

5 a.free_mb

6 from v$asm_disk a,

7 v$asm_diskgroup b

8 where a.group_number=b.group_number;

GROUP_NAME DISK_NAME HEADER_STATU STATE FREE_MB

————- ————— ———— ——– ———

ORATEST ORATEST_0000 MEMBER NORMAL 5064

DG_DATA DG_DATA_0000 MEMBER NORMAL 2904

DG_CRS DG_CRS_0000 MEMBER NORMAL 2891

DG_ARCH DG_ARCH_0000 MEMBER NORMAL 2857

SQL> alter diskgroup ORADATA add disk ‘/dev/sdb3’ rebalance power 10;

Diskgroup altered.

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

ASM Disk group disk drop

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

SQL> select b.name as group_name,
2 a.name as disk_name,
3 a.header_status,
4 a.state,

5 a.free_mb

6 from v$asm_disk a,

7 v$asm_diskgroup b

8 where a.group_number=b.group_number;

GROUP_NAME DISK_NAME HEADER_STATU STATE FREE_MB

————- ————— ———— ——– ———

ORATEST ORATEST_0000 MEMBER NORMAL 5064

DG_DATA DG_DATA_0000 MEMBER NORMAL 2904

DG_DATA DG_DATA_0001 MEMBER NORMAL 2904

DG_CRS DG_CRS_0000 MEMBER NORMAL 2891

DG_ARCH DG_ARCH_0000 MEMBER NORMAL 2857

SQL> alter diskgroup ORADATA drop disk DG_DATA_0001 rebalance power 3;

Diskgroup altered.

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

SQL> select d.name, o.operation, o.state, o.power, o.est_minutes
2 from v$asm_disk d, v$asm_operation o
3 where d.group_number=o.group_number
4 order by 1;

NAME OPERA STAT POWER EST_MINUTES

—————————— —– —- ———- ———–

DG_DATA_0000 REBAL RUN 3 0

DG_DATA_0000 REBAL WAIT 3 0

DG_DATA_0001 REBAL WAIT 3 0

DG_DATA_0001 REBAL RUN 3 0

SQL> select d.name, o.operation, o.state, o.power, o.est_minutes

2 from v$asm_disk d, v$asm_operation o

3 where d.group_number=o.group_number

4 order by 1;

NAME OPERA STAT POWER EST_MINUTES

—————————— —– —- ———- ———–

DG_DATA_0000 REBAL WAIT 3

DG_DATA_0000 REBAL DONE 3

ASM Disk size 변경

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

SQL> select b.name as group_name ,
2 a.name as disk_name,
3 a.header_status,
4 a.state,

5 a.total_mb

6 from v$asm_disk a,

7 v$asm_diskgroup b

8 where a.group_number=b.group_number;

GROUP_NAME DISK_NAME HEADER_STATU STATE FREE_MB

————- ————— ———— ——– ———

ORATEST ORATEST_0000 MEMBER NORMAL 8064

DG_DATA DG_DATA_0000 MEMBER NORMAL 2904

DG_CRS DG_CRS_0000 MEMBER NORMAL 2891

DG_ARCH DG_ARCH_0000 MEMBER NORMAL 2857

SQL> alter diskgroup ORATEST resize disk ORATEST_0000 size 5000m;

Diskgroup altered.

SQL> select b.name as group_name ,

2 a.name as disk_name,

3 a.header_status,

4 a.state,

5 a.total_mb

6 from v$asm_disk a,

7 v$asm_diskgroup b

8 where a.group_number=b.group_number;

GROUP_NAME DISK_NAME HEADER_STATU STATE FREE_MB

————- ————— ———— ——– ———

ORATEST ORATEST_0000 MEMBER NORMAL 5000

DG_DATA DG_DATA_0000 MEMBER NORMAL 2904

DG_CRS DG_CRS_0000 MEMBER NORMAL 2891

DG_ARCH DG_ARCH_0000 MEMBER NORMAL 2857

ASM check Disk

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

SQL> conn / as sysasm
Connected.
SQL> alter diskgroup ORATEST check all
-> alert log 확인

Sun Jun 07 07:35:07 2015

NOTE: starting check of diskgroup ORATEST

Sun Jun 07 07:35:07 2015

GMON querying group 3 at 25 for pid 36, osid 36035

GMON checking disk 0 for group 3 at 26 for pid 36, osid 36035

Sun Jun 07 07:35:07 2015

SUCCESS: check of diskgroup ORATEST found no errors

Sun Jun 07 07:35:07 2015

SUCCESS: alter diskgroup ORATEST check all

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

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

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

적용된 패치 확인

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

$ opatch lsinventory
Oracle Interim Patch Installer version 12.1.0.1.7
Copyright (c) 2015, Oracle Corporation. All rights reserved.
Oracle Home : /oracle/12.1.0.2

Central Inventory : /grid/oraInventory

from : /oracle/12.1.0.2/oraInst.loc

OPatch version : 12.1.0.1.7

OUI version : 12.1.0.2.0

Log file location : /oracle/12.1.0.2/cfgtoollogs/opatch/opatch2015-06-18_00-20-31AM_1.log

Lsinventory Output file location : /oracle/12.1.0.2/cfgtoollogs/opatch/lsinv/lsinventory2015-06-18_00-20-31AM.txt

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

Local Machine Information::

Hostname: ktms1

ARU platform id: 267

ARU platform description:: Solaris Operating System (x86-64)

Installed Top-level Products (1):

Oracle Database 12c 12.1.0.2.0

There are 1 products installed in this Oracle Home.

Interim patches (2) :

Patch 20299023 : applied on Thu Jun 18 00:06:44 KST 2015

Unique Patch ID: 18672617

Patch description: “Database Patch Set Update : 12.1.0.2.3 (20299023)”

Created on 18 Mar 2015, 00:15:50 hrs PST8PDT

Sub-patch 19769480; “Database Patch Set Update : 12.1.0.2.2 (19769480)”

Bugs fixed:

19189525, 19065556, 19075256, 19723336, 19077215, 19865345, 18845653

19280225, 19524384, 19248799, 18988834, 19048007, 18288842, 19238590

18921743, 18952989, 16870214, 19928926, 19134173, 19180770, 19018206

19197175, 19149990, 18849537, 19730508, 19183343, 19012119, 19001390

18202441, 19067244, 19189317, 19644859, 19358317, 19390567, 20074391

19279273, 19706965, 19068970, 19841800, 19512341, 14643995, 19619732

20348653, 18607546, 18940497, 19670108, 19649152, 19065677, 19547370

18948177, 19315691, 19637186, 19676905, 18964978, 19035573, 19176326

18967382, 19174430, 19176223, 19532017, 18674047, 19074147, 19054077

19536415, 19708632, 19289642, 20425790, 19335438, 18856999, 19371175

19468347, 19195895, 19154375, 16359751, 18990693, 19439759, 19769480

19272708, 19978542, 19329654, 19873610, 19174521, 19520602, 19382851

19658708, 19304354, 19052488, 19291380, 18681056, 19896336, 17835294

19076343, 19791377, 19068610, 19561643, 18618122, 20440930, 18456643

18909599, 19487147, 19143550, 19185876, 19016730, 18250893, 20347562

19627012, 16619249, 18354830, 19577410, 19687159, 19001359, 19174942

19518079, 18610915, 18674024, 18306996, 19309466, 19081128, 19915271

19157754, 19058490, 20284155, 18791688, 18885870, 19303936, 19434529

19018447, 18417036, 19597439, 20235511, 19022470, 18964939, 19430401

19044962, 19385656, 19501299, 17274537, 19409212, 19440586, 19606174

18436647, 19023822, 19684504, 19178851, 19124589, 19805359, 19024808

19597583, 19155797, 19393542, 19050649, 19028800

Patch 20299022 : applied on Wed Jun 17 23:59:08 KST 2015

Unique Patch ID: 18594999

Patch description: “OCW Patch Set Update : 12.1.0.2.3 (20299022)”

Created on 7 Apr 2015, 11:40:43 hrs UTC

Bugs fixed:

18589889, 19139608, 19280860, 19061429, 19133945, 19341538, 18946768

19135521, 19361757, 19187207, 19302350, 19130141, 19530755, 19699720

19168690, 19266658, 18899171, 19244316, 19653795, 18330979, 19471722

18634372, 19027351, 18707416, 19184188, 19131709, 20235486, 19925992

20006646, 18991776, 18439295, 19380733, 18943696, 19550195, 18135723

19163425, 20014326, 19524857, 18849021, 18890943, 18861196, 19154753

17940721, 19522313, 18748932, 18835283, 19184765, 19499021, 19046190

19051385, 19682695, 19050688, 19831611, 19226141, 19053891, 18871287

18998228, 18922918, 18980002, 19683886, 18956780, 18777835, 19026993

17338864, 18261648, 19513650, 19702758, 18952577, 17447588, 19414274

20752167, 19262534, 19147513, 19473088, 19178517, 19529729, 19455563

19319904, 18703978, 20340620, 18536826, 19703246, 19292605, 19192901

20660273, 20011635, 19479503, 19029647, 19179158, 18901356, 19140712

18964974, 18835366, 19184276, 19013789, 19207286, 20510208, 20001507

18950232, 20079414, 19680763, 19259765, 19148791, 19556820, 19449737

18962892, 19187515, 19513888, 19230771, 19853036, 19453778, 19551830

19068333, 18520351, 18843572, 19185148, 18945435, 19232454, 18541110

18834955, 19319192, 19204743, 19178629, 19304104, 19140891, 19270660

19457575, 19021575, 19069755, 18715884, 19584688, 18798573, 19812592

19018001, 19325701, 19292272, 19270956, 19222693, 18700893, 19662663

18406774, 19010177, 18910576, 18907170, 19700294, 19164099, 19331454

18955644, 18508710, 18798432, 19146822, 19589221, 19537762, 16286734

18762843, 19045143, 18945249, 19146980, 19184799, 19205086, 20091753

18862203, 19537547, 19281106, 19031737, 19079087, 18968981, 19148367

19150517, 20231741, 19217019, 18730096, 18975620, 19205617, 19513351

18843054, 19150313, 18708349, 18953639, 19067804, 19371270, 19203996

20038431, 19054979, 19209951, 19318983, 19154673, 18752378, 19150088

19013444, 19234177, 18998379, 20157569, 18999857, 19273577, 19075747

19367276, 19632437, 19612597, 19874047, 19288396, 18990354, 19557558

19427050, 19127078, 18910443, 20053557, 20033787, 19315567, 19148982

18290252, 18813323, 19777496, 19500293, 18643483, 19277814, 18523468

19134098, 19071526, 18965694, 19226858, 18850051, 19602208, 20061168

18417590, 19370739, 18920408, 19609388, 18636884, 18776786, 18989446

19148793, 19043795, 19585454, 19955755, 18317489, 18260170, 18919682

19807548, 18678829, 19124972, 19147509, 18849896, 18910748, 19273758

18953878, 19076165, 19704993, 18999195, 19498411, 18759724, 19459023

20276459, 19066844, 17208793, 19234907, 13843841, 19538714, 19383028

19649640, 19062675, 19513969, 18859710, 19504641, 19341481, 20293730

19986391, 18304090, 19343245, 19314048, 18834934, 19473851, 19241655

18242738, 19458082, 19470791, 18894342, 18372060, 19522067, 18953889

18827679, 19259290, 19140711, 19023430, 19045388, 19241857, 19076778

19522571, 18875012, 18861564, 19066699, 19273760, 19225265, 18819158

19068003, 18937186, 19049721, 19368917, 19635215, 18868829, 19141785

19885321, 19163887, 19820247, 18715868, 18852058, 19538241, 19804032

Rac system comprising of multiple nodes

Local node = XXXDB01

Remote node = XXXDB02

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

OPatch succeeded.

Patch 적용

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

명령어	설 명
opatch apply	현재 디렉토리의 Patch 적용 RAC의 경우 모든 노드에 적용
opatch apply -local	현재 디렉토리의 Patch 를 현재 노드에 적용
opatch apply -invPtrLoc	Oracle Inventory를 직접 지정하여 설치하는 경우
opatch lsinventory –oh /oracle/product/11.2.0	/oracle/product/11.2.0/db 에 적용된 Patch 표시
opatch lsinventory –all	현재 노드에 적용된 모든 Patch 표시
opatch rollback -id patch#	적용된 Patch 복구
opatch rollback -id patch# -local	현재 노드에 적용된 Patch 복구

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

alter system [SET|RESET] NAME=VALUE scope=[MEMORY|SPFILE|BOTH] sid=[‘*’|’SID’];
[SET|RESET]
SET : Parameter 값 설정
RESET : Parameter 값을 Default로 설정.

scope=[MEMORY|SPFILE|BOTH]

MEMORY : 현재 기동중인 Instance 에서만 적용. Restart후 원래 값으로 복원

SPFILE : 현재 Instance 에는 적용하지 않고 SPFile 에만 적용. Restart후 적용

BOTH : Memory, SPfile 모두에 적용

sid=[‘*’|’SID’] : Single Instance 에서는 sid 값을 생략해도 된다.

‘*’ : RAC의 경우 모든 Instance 에 적용

‘SID’ : 해당 SID 에 적용

주요 Parameter

구분	Parameter	설정 값	설명
Archive	log_archive_dest_1	LOCATION=/ARCH	archive log file 이 저장될 위치
Archive	log_archive_format	ORAPTL%t_%s_%r.arc	archive log file 형식 지정
Cluster Database	cluster_database	TRUE	RAC DB 구성 여부
	cluster_database_instance	2	Instance 개수
	thread	1, 2	Thread 번호
	instance_number	1, 2	Instance 번호
SGA/PGA Memory	db_cache_size	5G	DB Buffer Cache 크기
	shared_pool_size	2G	Shared Pool 크기
	java_pool_size	200M	Java Pool 크기
	large_pool_size	200M	Large Pool 크기
	pga_aggregate_target	10G	PGA 영역 크기
Process and Session	processes	2000	사용 가능한 최대 process 개수
	sessions	3040	Default 로 (processes*1.5)+22 로 자동 산정됨
	open_cursors	300	Open 가능한 최대 Cursor 개수
ETC	audit_trail	NONE	DB 감사기능 설정 여부
	sec_case_sensitive_logon	FALSE	password 대소문자 구분 지정
	deferred_segment_creation	FALSE	segment 생성시 지연된 공간 할당설정

Parameter 적용 예제

OS>sqlplus “/as sysdba”
— Instance가 기동 중일 동안 SGA Size를 3G 로 변경.
SQL> alter system set SGA_TARGET=3G scope=MEMORY;
System altered.

— SPFile 에만 SGA Size를 3G 로 변경.

SQL>alter system set SGA_TARGET=3G scope=SPFILE;

— Instance, SPFile 모두 PARALLEL_MIN_SERVERS 를 6으로 변경.

SQL>alter system set PARALLEL_MIN_SERVERS=6 scope=BOTH;

— Instance 에서 SPFile 에만 OPEN_CURSORS 를 초기화

SQL>alter system reset OPEN_CURSORS scope=SPFILE;

— SPFile 설정값 확인

SQL> select * from v$spparameter where isspecified=’TRUE’;

— 현재의 Parameter 값 확인

SQL> select * from v$parameter where isdefault = ‘FALSE’;

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

$ sqlplus “/as sysdba”
SQL> show parameter diagnostic_dest
NAME TYPE VALUE
———————————— ———– ——————————

diagnostic_dest string /oracle/base

ADR 관련 로그 확인

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

로그 위치	Directory	Description
/oracle/base/diag/rdbms/<SID>/<SID>/	alert	xml형식의 alert log (log.xml)가 저장된다.
	cdump	core dump 파일이 저장된다.
	trace	background and server process trace files와 SQL trace files, 그리고 text형식의 alert_SID.log가 저장된다.
	incpkg	incident packages가 저장된다.
	hm	health monitor reports가 저장된다.
/grid/base/diag/tnslsnr/<hostname>/listener/	trace	Listener 관련 로그 (listener.log)

CRS 관련 로그

로그 위치	Directory	Description
/grid/12.1.0.2/log/<hostname>	crsd	crs daemon이 활동한 로그가 저장된다.
	cssd	css daemon이 활동한 로그가 저장된다.
	evmd	evm daemon이 활동한 로그가 저장된다.

백업과 복구

백업 개요

오라클은 다양한 백업(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 에 대한 내용은 다음과 같다.

오라클에서 제공하는 백업의 종류는 다음과 같다.
데이터베이스를 구축한다는 것은 하나의 데이터를 여러 유저가 공유하기 위함도 있지만 무엇보다도 데이터의 안정성이다. 만일의 사태가 발생하더라도 데이터의 손실을 막는 것에 목적이 있다.
Export / Import
Export 는 Database 에 저장된 내용을 file 형태의 O/S dump file 로 추출하는 tool이다. 반대로 import 는 export 로 받은 O/S Dump file 을 database 에 저장시키는 tool 이다.
1. Export option
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 의 손실을 감안하여야 한다는 단점이 있다.

옵션	내용
userid	유저명과 패스워드를 쓴다.
file	export 받는 덤프 파일을 지정한다.
log	export 받을 때 로그 파일을 지정한다.
rows	데이터를 받을 것인지 아닌지를 지정한다.
constraints	테이블의 제약 조건을 받을 것인지 지정한다.
indexes	인덱스를 받을 것인지를 지정한다.
tables	유저의 특정 테이블을 받고자 할 때 사용된다.
compress	테이블을 위해 EXTENT 된 값이 Storage 값의 INITIAL 값에 설정된다.
full	userid 가 system이거나 dba 권한이 있는 유저일 경우에만 설정 가능하며, 데이터베이스 전체를 받고자 할 때 사용된다.

Import option

옵션	내용
userid	유저명과 패스워드를 쓴다.
file	export 받은 덤프 파일을 지정한다.
log	import 할 때 로그 파일을 지정한다.
rows	데이터를 삽입 할 것인지 아닌지를 지정한다.
constraints	테이블의 제약 조건을 넣을 것인지 지정한다.
indexes	인덱스를 생성 할 것인지를 지정한다.
tables	유저의 특정 테이블을 지정하여 삽입 할 때 사용된다.
indexfile	데이터를 import하지 않고 create index 문장의 SQL로 파일이 만들어진다.
fromuser	다른 유저에게 export 한 파일을 import 하고자 할 때 export 한 유저를 지정한다.
touser	import 할 유저를 지정한다.

Export / Import example

Export example

옵션	내용
Database 전체	$exp system/manager file=/backup/full_exp.dmp log=/backup/full_exp.log full=y
User 단위	$exp system/manager file=/backup/scott.dmp log=/backup/scott.log owner=scott
Table 단위	$exp system/manager file=/backup/scott_emp.dmp log=/backup/scott_emp.log tables=scott.emp

Import example

옵션	내용
Database 전체	$imp system/manager file=/backup/full_exp.dmp log=/backup/full_imp.log full=y
User 단위	$imp system/manager file=/backup/scott.dmp log=/backup/scott_imp.log fromuser=scott touser=hr
Table 단위	$imp system/manager file=/backup/scott_emp.dmp log=/backup/scott_emp_imp.log tables=scott.emp

Recovery Manager(RMAN)
1. RMAN 구조
  1. RMAN의 기본 개요
  RMAN은 Database files, Archive logs, 그리고 Control files들을 Backup하고 Restore하기 위하여 사용 된다. 또한 RMAN은 Complete 또는 Incomplete Database Recovery를 수행하기 위하여 사용할 수 있다. 단, RMAN은 initialization files이나 password files는 Backup할 수 없다. RMAN 은 current redo log 에 대한 별도의 백업 방법을 가지고 있지 않으며 수동으로 log switching을 발생시켜야 한다.
  1. RMAN의 특징

DB 전체, Tablespace단위, Database files, Archive logs, 그리고 Control files등 Backup이 자주 실행되는 명령들은 script로 저장하여 간단하게 실행할 수 있다.
Incremental block level backup을 할 수 있다.
사용되어지지 않은 database block들은 skip한다.
Backup / restore 시 각 block 에 대한 checksum 을 통해 Corrupted block 을 발견한다.
Tablespace를 Online으로 백업 할 때, tablespace를 backup mode 로 변경 할 필요가 없다.
Backup performance를 향상 시킨다. (Parallelization, less redo log 생성)
OS 의 open file limit 을 피하기 위해 open file limit 을 지정할 수 있으며, 백업 사이즈의 limit 을 줄 수 있다.

RMAN Architecture

관리자가 RMAN 유틸리티에게 백업이나 복구를 명령하면 RMAN유틸리티는 관리자를 대신하여 대상 서버 (Target Database)에 접속하여 Server Process에게 백업을 수행한다. 그리고 관련 정보를 Recovery Catalog Server가 있으면 Catalog Database에 저장하고, 만약 없다면 Target Database의 Control file에 기록한다.

RMAN은 서버 쪽의 SID를 체크하고 sys 사용자로 로그인 하게 된다. 그리고 인스턴스에 접속하기 위해 Channel Server Process를 생성하게 된다. Channel Server Process의 기본값은 1개다. 이 Server Process가 사용 할 PGA가 할당된다.

이 패키지는 Control file의 정보를 읽어서 데이터베이스 전체 의 파일들에 관한 정보와 체크포인트 정보, 생성 시간 정보, 각 Data file의 온라인/오프라인 정보 및 위치 정보들을 모으게 된다. 이렇게 정보를 모은 후 본격적인 백업 작업을 수행하기 전에 백업되는 동안 변경되는 정보들로부터 현재 시점의 정보를 지키기 위해 Control file을 스냅샷 해서 보관하게 된다.

이 후 DBMS_BACKUP_RESTORE 패키지를 호출하여 정해진 위치에 백업 피스를 만든다. 모든 백업 파일이 백업 피스에 저장 완료되면 RMAN은 다시 DBMS_BACKUP_RESTORE 패키지를 호출해서 백업 피스의 이름과 시간 마지막 체크포인트 정보 등을 Control file에 기록한다. 이 과정까지 끝나면 백업이 완료된다.

Recovery Catalog

Recovery Catalog란 RMAN 사용 시 에 RMAN으로 백업 복구 작업을 하고 관련 정보를 저장해 두는 저장소이다. Recovery Catalog Server가 없을 경우 RMAN은 Target Database Server의 control file에 해당 정보를 저장하고 Recovery Catalog Server가 있을 경우 Recovery Catalog Server에 정보를 저장한다.

Recovery Catalog에 저장되는 정보는 아래와 같다.

Data file, Archive file 및 Redo log file의 백업 셋과 copy 된 이미지에 대한 정보
백업 대상서버의 물리적인 구조
자주 사용하는 백업 스크립트 (Recovery Catalog Server를 사용할 경우만 해당)

RMAN 명령어
1. RMAN 접속
SQL*Plus로 데이터베이스에 접속하듯이 RMAN으로도 데이터베이스에 접속한다.
ORACLE USER로 수행 한다.
차이점은 RMAN은 SYSDBA 권한을 가지고 타겟과 보조 데이터베이스에 접속해야 하는데 AS SYSDBA 키워드는 사용하지 않아도 묵시적으로 가진 것으로 접속이 가능하다.

[oracle@XXXDB01 ~]$ rman target /
Recovery Manager: Release 12.1.0.2.0 – Production on Thu Jun 11 10:00:31 2015
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database: XXXDB (DBID=611517755)

RMAN>

RMAN CONFIGURE COMMAND

configure의 설정된 환경 값을 바르게 설정되어 있는 경우, 간단하게 BACKUP DATABASE; 문을 실행하여 데이터베이스를 백업할 수 있다.

RMAN이 백업과 복구를 실행하는 구성을 미리 작성한 디폴트 configure가 준비되어 적용된다. 또한 CONFIGURE 명령으로 channel parameter를 재 작성할 수 있다.

Default RMAN configuration

Show all 명령어를 사용하면, default configuration 값을 확인 할 수 있다.

RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name XXXDB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE ; # default

CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/oracle/12.1.0.2/dbs/snapcf_JCDB1.f’; # default

주요 configuration 수정 하는 방법은 다음과 같다.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 1 DAYS;
à
이 파라미터는 복구에 사용할 백업 파일의 보존 기간을 설정하는 것으로 1DAYS 하면 1일치만 복구하기 위해 보존한다는 의미이다. 이 정책을 넘어선, 즉 1일이 지난 백업 파일을 모두 지우려면 DELETE OBSOLETE 명령어를 시용하면 된다.
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
à
이 명령어는 백업본의 개수를 지정한다. 만일의 경우 백업 파일이 손상될 수 있기 때문에 REDUNDANCY 숫자만큼 백업 파일을 다중화해서 생성하라는 의미이다. 여기서는 1개로 지정한 내용이다.

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;

à
이 설정은 기본 Channel에 백업을 받을 때 백업 수행 프로세스의 병렬도를 설정하는 것이다. 이 예처럼 설정하면 기본 Channel로 백업 받을 때 백업 프로세스가 2개 생성되어 백업을 동시에 진행할 것이다.

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK

à
default backup device를 설정한다.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

à
RMAN의 BACKUP이나 COPY 명령들의 수행 후 자동으로 control file backup을 수행한다.

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’;

à
autobackup되는 control file의 기본 format을 변경한다.

RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;

à
datafile, control file의 backup set의 copy본 개수를 지정한다.

RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;

à
archivelog file의 backup set의 copy본 개수를 지정한다.

RMAN> CONFIGURE MAXSETSIZE TO UNLIMITED;

à
해당 Channel에서 백업 받아지는 백업셋의 최대 크기를 UNLIMITED로 설정하는 명령어다.

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;

à
이 설정은 만약 백업 받는 경로에 같은 백업 파일이 존재하면 그 파일은 백업 받지 말고 넘어가라는 의미이다. RMAN은 해당 백업 파일이 같은 파일인지 구별하기 위해 백업되어 있는 파일과 지금 백업하려는 파일의 DBID, Checkpoint SCN, Creation SCN, Resetlogs SCN and time을 서로 비교해서 모든 것 이 완벽하게 맞으면 동일 파일로 인정하게 Skip 한다. 기본값은 OFF

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 50M;

à
이 설정은 해당 Channel로 백업 받을 때 백업 파일 하나의 최대 크기를 지정하는 명령어 이다.

Default configuration 변경

만약 default device type을 변경하려면 다음과 같이 변경 하면 된다. 이 외의 다른 configuration 변경도 아래 step 과 동일하다.

RMAN> show default device type;
RMAN configuration parameters for database with db_unique_name XXXDB are:
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT;

old RMAN configuration parameters:

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

new RMAN configuration parameters:

CONFIGURE DEFAULT DEVICE TYPE TO ‘SBT_TAPE’;

new RMAN configuration parameters are successfully stored

RMAN> show default device type;

RMAN configuration parameters for database with db_unique_name XXXDB are:

CONFIGURE DEFAULT DEVICE TYPE TO ‘SBT_TAPE’;

SHOW 명령어

Show all 명령어를 사용하면 configuration 값을 모두 사용 할 수 있다. 특정 한 것을 볼 경우 아래와 같이 사용 하면 된다.

RMAN> show default device type;
RMAN configuration parameters for database with db_unique_name XXXDB are:
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
à 변경하지 않은 configuration은 # default 라고 표시 된다.

RMAN> show default device type;

RMAN configuration parameters for database with db_unique_name XXXDB are:

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

à 변경이 된 configuration은 # default가 사라지며 해당 configuration 값이 나타난다.

LIST 명령어

LIST DATABASE

RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

1 Full 467.06M DISK 00:00:18 11-JUN-15

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111129

Piece Name: /oracle/12.1.0.2/dbs/01q97fn1_1_1

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/system01.dbf

2 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

4 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/users01.dbf

LIST BACKUP OF DATAFILE

RMAN> list backup of datafile ‘+DG_DATA/XXXDB/system01.dbf’;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

1 Full 467.06M DISK 00:00:18 11-JUN-15

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111129

Piece Name: /oracle/12.1.0.2/dbs/01q97fn1_1_1

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/system01.dbf

LIST BACKUP

RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

1 Full 467.06M DISK 00:00:18 11-JUN-15

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111129

Piece Name: /oracle/12.1.0.2/dbs/01q97fn1_1_1

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/system01.dbf

2 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

4 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/users01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

2 Full 18.11M DISK 00:00:04 11-JUN-15

BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111156

Piece Name: /oracle/12.1.0.2/dbs/c-611517755-20150611-00

Control File Included: Ckp SCN: 1184594 Ckp time: 11-JUN-15

Channel 할당하기
Channel이란 쉽게 말하면 백업과 복구를 하는 경로를 의미한다. 백업을 수행하기 전에 Channel을 할당해주어야 RMAN이 백업/복구를 수행할 수 있다. 복구할 때는 Channel을 할당하지 않아도 되지만 백업할 경우는 반드시 Channel을 할당해 주어야 한다. Channel을 할당하는 방법은 자동 Channel 설정 과 수동 Channel 설정이 있다.
1. 자동 Channel 할당하기
자동 Channel 이란 백업을 수행할 때 별도의 경로를 주지 않아도 정해진 위치로 백업을 받는 것을 말하며 default channel의 의미가 있다. 다음과 같이 설정한다.

RMAN 접속

[oracle@XXXDB01 ~]$ rman target /
Recovery Manager: Release 12.1.0.2.0 – Production on Fri Jun 12 03:41:41 2015
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database: XXXDB (DBID=611517755)

자동 Channel 설정

아래와 같이 설정하면 default device가 파라미터 파일의 db_recovery_file_dest 파라미터 경로로 설정되며 해당 파라미터가 설정되어 있지 않다면 $ORACLE_HOME/dbs에 저장된다.

RMAN> configure default device type to disk;
using target database control file instead of recovery catalog
old RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;

new RMAN configuration parameters:

CONFIGURE DEFAULT DEVICE TYPE TO DISK;

new RMAN configuration parameters are successfully stored

자동 Channel 경로 변경

/u01/app/backup 경로를 default device로 설정한다. 즉 앞으로 특별한 경로 없이 백업을 수행하면 이곳에 백업이 생성된다. %U(대문자 U) 는 파일명이 중복되지 않도록 RMAN 이 Unique 한 번호로 파일 이름을 생성하면서 백업을 수행하라는 의미이며 %T는 백업 날짜를 표시 하라는 뜻이다.

RMAN> configure channel device type disk
2> format ‘/u01/app/backup/%U_%T’;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/u01/app/backup/%U_%T’;

new RMAN configuration parameters are successfully stored

자동 Channel 경로 변경 TEST

RMAN> backup tablespace users;
à경로 지정 없이 백업을 수행 시킴.
Starting backup at 12-JUN-15
allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=42 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: starting piece 1 at 12-JUN-15

channel ORA_DISK_1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/05q99aih_1_1_20150612 tag=TAG20150612T035601 comment=NONE

à/oracle/backup 경로에 백업 파일이 생성 된 것을 확인 할 수 있다.

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-01 comment=NONE

Finished Control File Autobackup at 12-JUN-15

수동 Channel 할당 하기

수동 Channel이란 백업을 수행할 때 백업 받을 경로를 지정해 주는 것이다. 아래 방법은 작업형 명령어를 사용하여 수동 Channel을 할당하는 것이다. /oracle/backup/manual 경로에 백업 파일이 생성 된다.

RMAN> run {
2> allocate channel c1 type disk
3> format ‘/oracle/backup/manual/%U_%T’;
4> backup tablespace users;

5> }

allocated channel: c1

channel c1: SID=42 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/manual/0aq99b12_1_1_20150612 tag=TAG20150612T040346 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-03 comment=NONE

Finished Control File

또는 아래와 같이 독립형 명렁어로도 가능하다.

RMAN> backup tablespace users format ‘/oracle/backup/manual/%U_%T’;
Starting backup at 12-JUN-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=42 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: starting piece 1 at 12-JUN-15

channel ORA_DISK_1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/manual/0cq99b6r_1_1_20150612 tag=TAG20150612T040651 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-04 comment=NONE

Finished Control File Autobackup at 12-JUN-15

Channel 할당 정리

자동 Channel 할당보다 수동 Channel 할당이 더 우선적으로 적용 된다. 그리고 수동 Channel을 사용하면 RMAN은 해당 경로에 받는 백업 파일을 관리하지 않는다. 이 말의 의미는 Retention Policy 등이 설정되어 있더라도 format 파라미터를 사용해서 경로를 변경하면 해당 정책들이 적용 안 된다는 것을 의미 한다. FRA에 저장한다 하더라도 format 파라미터로 경로가 정해지면 관리자가 수동으로 백업 파일을 관리 해야만 한다.

RMAN BACKUP
RMAN의 BACKUP 방법은 독립형 명령어(standalone)으로 백업 받기와 작업형 명령으로 백업 받기 가 있다. 독립형 명령어는 한 개의 명령어가 수행되는 것을 말하며, 작업형 명령어는 마치 프로그램의 스크립트처럼 여러 개의 명령어를 한꺼번에 사용하는 방법이다. 앞으로 예제는 작업형 명령어로 수행 하겠다.
1. Database full backup
전체 DB에 대한 백업을 수행 한다.

Database full backup 수행

/oracle/backup 경로에 백업 파일을 생성하며, database full 백업을 수행한다. List backup으로 확인 했을 때 tag는 구분 하기 쉽게 FULL_DB로 보여 지게 된다.

RMAN> run {
2> # backup the complete database to disk
3> allocate channel c1 type disk;
4> backup

5> full

6> tag full_db

7> format ‘/oracle/backup/db_%U_%T’

8> (database);

9> release channel c1;

10> }

released channel: ORA_DISK_1

allocated channel: c1

channel c1: SID=42 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00001 name=+DG_DATA/XXXDB/system01.dbf

input datafile file number=00002 name=+DG_DATA/XXXDB/sysaux01.dbf

input datafile file number=00003 name=+DG_DATA/XXXDB/undotbs101.dbf

input datafile file number=00004 name=+DG_DATA/XXXDB/undotbs201.dbf

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/db_0eq99c4i_1_1_20150612 tag=FULL_DB comment=NONE

channel c1: backup set complete, elapsed time: 00:00:25

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-05 comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Database full backup 확인

경로 및 Tag에 위에서 수행한 내용이 나타나 있다.

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

11 Full 508.86M DISK 00:00:24 12-JUN-15

BP Key: 11 Status: AVAILABLE Compressed: NO Tag: FULL_DB

Piece Name: /oracle/backup/db_0eq99c4i_1_1_20150612

List of Datafiles in backup set 11

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/system01.dbf

2 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

4 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/users01.dbf

Tablespace backup

Tablespace 별로 백업 받을 때 사용 할 수 있다.

Tablespace backup 수행

아래 예제는 USERS TABLESPACE와 SYSAUX TABLESPACE의 백업 수행 내용 이다.

/oracle/backup 경로에 백업 파일이 생성 된다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag tbs_users_sysaux

5> format ‘/oracle/backup/tbs_%U_%T’

6> (tablespace users, sysaux);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=42 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00002 name=+DG_DATA/XXXDB/sysaux01.dbf

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/tbs_0gq99cp3_1_1_20150612 tag=TBS_USERS_SYSAUX comment=NONE

channel c1: backup set complete, elapsed time: 00:00:07

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-06 comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Tablespace backup 확인

위에서 개별적으로 백업 받은 내용뿐만 아니라, FULL BACKUP 받았던 내용까지 나온다. FULL BACKUP 내역에 해당 테이블 스페이스가 존재 하기 때문이다.

RMAN> list backupset of tablespace sysaux;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

1 Full 467.06M DISK 00:00:18 11-JUN-15

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111129

Piece Name: /oracle/12.1.0.2/dbs/01q97fn1_1_1

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

2 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

11 Full 508.86M DISK 00:00:24 12-JUN-15

BP Key: 11 Status: AVAILABLE Compressed: NO Tag: FULL_DB

Piece Name: /oracle/backup/db_0eq99c4i_1_1_20150612

List of Datafiles in backup set 11

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

2 Full 1291744 12-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

13 Full 194.69M DISK 00:00:04 12-JUN-15

BP Key: 13 Status: AVAILABLE Compressed: NO Tag: TBS_USERS_SYSAUX

Piece Name: /oracle/backup/tbs_0gq99cp3_1_1_20150612

List of Datafiles in backup set 13

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

2 Full 1292370 12-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

Datafile backup

Datafile 별로 백업 받을 때 사용 할 수 있다.

Datafile 확인

Report schema를 확인 한다. 현재 datafile 및 tempfile을 알 수 있다.

RMAN> report schema;
Report of database schema for database with db_unique_name XXXDB
List of Permanent Datafiles
===========================

File Size(MB) Tablespace RB segs Datafile Name

—- ——– ——————– ——- ————————

1 700 SYSTEM YES +DG_DATA/XXXDB/system01.dbf

2 550 SYSAUX NO +DG_DATA/XXXDB/sysaux01.dbf

3 290 UNDOTBS1 YES +DG_DATA/XXXDB/undotbs101.dbf

4 200 UNDOTBS2 YES +DG_DATA/XXXDB/undotbs201.dbf

5 5 USERS NO +DG_DATA/XXXDB/users01.dbf

List of Temporary Files

=======================

File Size(MB) Tablespace Maxsize(MB) Tempfile Name

—- ——– ——————– ———– ——————–

1 23 TEMP 32767 +DG_DATA/XXXDB/temp01.dbf

Datafile backup 수행

작업형 명령어로 아래와 같이 수행 할 수 있다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag df_users

5> format ‘/oracle/backup/df_%U_%T’

6> (datafile ‘+DG_DATA/XXXDB/users01.dbf’);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/df_0lq99hic_1_1_20150612 tag=DF_USERS comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-08 comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

또는 위에서 확인 한 report schema의 결과 내용을 보고 file number로 백업 받을 수도 있다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag df_users2

5> format ‘/oracle/backup/df_%U_%T’

6> (datafile 5);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/df_0nq99hu1_1_1_20150612 tag=DF_USERS2 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-09 comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Datafile backup 확인

Datafile backup 내용 확인 같은 경우, 해당 datafile number를 적어 주어도 되고, 해당 datafile path를 적어 주어도 된다.

RMAN> list backupset of datafile ‘+DG_DATA/XXXDB/users01.dbf’;
RMAN> list backupset of datafile 5;
List of Backup Sets
===================

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

17 Full 1.03M DISK 00:00:00 12-JUN-15

BP Key: 17 Status: AVAILABLE Compressed: NO Tag: DF_USERS

Piece Name: /oracle/backup/df_0lq99hic_1_1_20150612

List of Datafiles in backup set 17

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

5 Full 1296675 12-JUN-15 +DG_DATA/XXXDB/users01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

19 Full 1.03M DISK 00:00:00 12-JUN-15

BP Key: 19 Status: AVAILABLE Compressed: NO Tag: DF_USERS2

Piece Name: /oracle/backup/df_0nq99hu1_1_1_20150612

List of Datafiles in backup set 19

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

5 Full 1297097 12-JUN-15 +DG_DATA/XXXDB/users01.dbf

Control file backup

Controlfile backup 같은 경우에 수동으로 현재 control file을 백업 받을 수 있고, autobackup을 활성화 시켜, 데이터베이스 메타데이타가 변경될 대마다 자동 백업을 수행한다. 아래 예제는 수동으로 control file을 백업 받는 내용이다.

Control file backup 수행

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag control_bk

5> format ‘/oracle/backup/cf_%U_%T’

6> (current controlfile);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting full datafile backup set

channel c1: specifying datafile(s) in backup set

including current control file in backup set

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/cf_0pq99ijk_1_1_20150612 tag=CONTROL_BK comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0a comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Control file backup 확인

현재 해당 DB에는 CONTROLFILE AUTOBACKUP ON 으로 되어 있어, tag CONTRL_BK로 controlfile을 백업 했을 때, 같이 자동으로 controlfile이 backup 되었다.

RMAN> list backup of controlfile;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

21 Full 18.11M DISK 00:00:03 12-JUN-15

BP Key: 21 Status: AVAILABLE Compressed: NO Tag: CONTROL_BK

Piece Name: /oracle/backup/cf_0pq99ijk_1_1_20150612

Control File Included: Ckp SCN: 1298018 Ckp time: 12-JUN-15

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

22 Full 18.11M DISK 00:00:02 12-JUN-15

BP Key: 22 Status: AVAILABLE Compressed: NO Tag: TAG20150612T061312

Piece Name: /oracle/12.1.0.2/dbs/c-611517755-20150612-0a

Control File Included: Ckp SCN: 1298025 Ckp time: 12-JUN-15

Archive log backup

Archive log 를 백업 받을 때 사용한다.

Archive log 확인

현재 백업 받아져 있는 archive log 를 확인 한다. 현재 백업 받아져 있는 archive는 하나도 없다.

RMAN> list backupset of archivelog all;
specification does not match any backup in the repository

Archive log backup

작업형 명령어로 archive log를 백업 받을 수 있다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> format ‘/oracle/backup/log_%U_%T’

5> (archivelog all);

6> release channel c1;

7> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

current log archived

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=2 sequence=5 RECID=10 STAMP=882156427

input archived log thread=1 sequence=33 RECID=8 STAMP=882156427

input archived log thread=2 sequence=6 RECID=11 STAMP=882156428

input archived log thread=1 sequence=34 RECID=9 STAMP=882156427

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_0rq99j1l_1_1_20150612 tag=TAG20150612T062035 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:03

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=1 sequence=1 RECID=12 STAMP=882166835

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_0sq99j1o_1_1_20150612 tag=TAG20150612T062035 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:03

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0b comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Archive log backup 확인

RAC 이기 때문에 Thread 1,2 모두 백업 받아 진다.

RMAN> list backupset of archivelog all;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time

——- ———- ———– ———— —————

23 17.53M DISK 00:00:00 12-JUN-15

BP Key: 23 Status: AVAILABLE Compressed: NO Tag:TAG20150612T062035

Piece Name: /oracle/backup/log_0rq99j1l_1_1_20150612

List of Archived Logs in backup set 23

Thrd Seq Low SCN Low Time Next SCN Next Time

—- ——- ———- ——— ———- ———

1 33 1175083 11-JUN-15 1285038 12-JUN-15

1 34 1285038 12-JUN-15 1287932 12-JUN-15

2 5 903151 03-JUN-15 1184015 11-JUN-15

2 6 1184015 11-JUN-15 1184017 11-JUN-15

BS Key Size Device Type Elapsed Time Completion Time

——- ———- ———– ———— —————

24 11.98M DISK 00:00:01 12-JUN-15

BP Key: 24 Status: AVAILABLE Compressed: NO Tag:TAG20150612T062035

Piece Name: /oracle/backup/log_0sq99j1o_1_1_20150612

List of Archived Logs in backup set 24

Thrd Seq Low SCN Low Time Next SCN Next Time

—- ——- ———- ——— ———- ———

1 1 1287932 12-JUN-15 1298316 12-JUN-15

특정 범위의 Sequence Archive log backup

Archive log file을 전부 다 받는 것이 아니고, 특정 sequence의 범위를 줘서 백업 받을 수 있다. 아래 테스트는 1번 노드의 archive log file 중에 sequence 가 1부터 3번까지 백업 받는 내용 이다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag log_1_3

5> format ‘/oracle/backup/log_%U_%T’

6> (archivelog from sequence=1 until sequence=3 thread 1);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=1 sequence=1 RECID=12 STAMP=882166835

input archived log thread=1 sequence=2 RECID=13 STAMP=882167494

input archived log thread=1 sequence=3 RECID=14 STAMP=882167497

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_0uq99jnk_1_1_20150612 tag=LOG_1_3 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0c comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

특정 시간이 경과한 Archive log backup

Sequence 뿐만 아니라, 시간의 범위를 지정하여 백업 받을 수도 있다. 아래 예제는 하루 이내에 생성된 archive log들에 대해 백업 하는 내용이다. Backup 한 이후에 해당 archive log file을 삭제 한다.

구분	내용
sysdate – 1	현재 날짜와 시간보다 1일전
sysdate – 7	현재 날짜와 시간보다 7일전
sysdate – 1/24	현재 날짜와 시간보다 1시간 전
sysdate – 9/24	현재 날짜와 시간보다 9시간 전
sysdate – 5/3600	현재 날짜와 시간보다 5분 전
all delete input	Backup이 완료되면 삭제가 된다. 만일 Backup이 실패를 한다면 Archivelog 들은 지워지지 않는다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag log_oneday

5> format ‘/oracle/backup/log_%U_%T’

6> (archivelog from time ‘sysdate-1’ all delete input);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

current log archived

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=2 sequence=5 RECID=10 STAMP=882156427

input archived log thread=1 sequence=33 RECID=8 STAMP=882156427

input archived log thread=2 sequence=6 RECID=11 STAMP=882156428

input archived log thread=1 sequence=34 RECID=9 STAMP=882156427

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_10q99jv0_1_1_20150612 tag=LOG_ONEDAY comment=NONE

channel c1: backup set complete, elapsed time: 00:00:03

channel c1: deleting archived log(s)

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_2_seq_5.274.882156427 RECID=10 STAMP=882156427

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_33.272.882156427 RECID=8 STAMP=882156427

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_2_seq_6.275.882156429 RECID=11 STAMP=882156428

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_34.273.882156427 RECID=9 STAMP=882156427

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=1 sequence=1 RECID=12 STAMP=882166835

input archived log thread=1 sequence=2 RECID=13 STAMP=882167494

input archived log thread=1 sequence=3 RECID=14 STAMP=882167497

input archived log thread=1 sequence=4 RECID=15 STAMP=882167776

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_11q99jv5_1_1_20150612 tag=LOG_ONEDAY comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

channel c1: deleting archived log(s)

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_1.276.882166835 RECID=12 STAMP=882166835

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_2.277.882167495 RECID=13 STAMP=882167494

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_3.278.882167497 RECID=14 STAMP=882167497

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_4.279.882167777 RECID=15 STAMP=882167776

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0d comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Online redo log backup

Online Redolog는 RMAN을 이용해서 Backup할 수 없다. 이것을 Backup하기에 앞서서 반드시 Archiving 되어야 한다. 즉 다음과 같은 sql command를 이용하여 Backup을 한다.

RMAN> run {
2> allocate channel c1 type disk;
3> sql “alter system archive log current”;
4> backup

5> format ‘/oracle/backup/log_%U_%T’

6> (archivelog from time ‘sysdate-1’ all delete input);

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=39 instance=XXXDB1 device type=DISK

sql statement: alter system archive log current

Starting backup at 12-JUN-15

current log archived

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=2 sequence=5 RECID=1 STAMP=882097839

input archived log thread=1 sequence=33 RECID=7 STAMP=882156401

input archived log thread=2 sequence=6 RECID=2 STAMP=882097840

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_13q99kkh_1_1_20150612 tag=TAG20150612T064744 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

channel c1: deleting archived log(s)

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_11/thread_2_seq_5.256.882097839 RECID=1 STAMP=882097839

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_33.271.882153957 RECID=7 STAMP=882156401

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_11/thread_2_seq_6.270.882097841 RECID=2 STAMP=882097840

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=1 sequence=5 RECID=16 STAMP=882168463

input archived log thread=1 sequence=6 RECID=17 STAMP=882168464

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/log_14q99kkj_1_1_20150612 tag=TAG20150612T064744 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:01

channel c1: deleting archived log(s)

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_5.279.882168463 RECID=16 STAMP=882168463

archived log file name=+DG_ARCH/XXXDB/ARCHIVELOG/2015_06_12/thread_1_seq_6.278.882168465 RECID=17 STAMP=882168464

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0e comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Incremental backup
Archivelog mode 인 경우 open 상태에서 database, tablespace, datafile 단위에서 incremental backup 이 가능하다. 즉 parent incremental backup 의 SCN 과 비교해서 큰 block 만을 copy 한다. incremental 은 differential incremental 과 cumulative incremental 로 나뉜다. default 는 differential 이다.
만약 recovery time 이 disk space 보다 중요한 고려사항이라면 cumulative backup 이 differential backup 보다 유리하다.
1. Incremental backup 수행
  아래 예제는 level 0으로 데이터베이스 전체를 백업 받는 내용 이다. Filesperset 파라미터는 backup file에 최대 4개의 데이터 파일씩 백업 받도록 하는 파라미터이다
10g 이상부터는 block change tracking 을 enable 시키면 datafile 을 full scan 하지 않고서도 변경된 block 을 tracking 할 수 있으므로 backup 시 성능향상을 꾀할 수 있다.
Level N incremental Backup은 가장 최근의 N 또는 N보다 작은 Backup이후의 변경된 부분만을 Backup하는 것이다. List Backup Set을 조회해 보면 Type Column에는 ‘Incr’, LV Column에는 ‘0’이라고 나타날 것이다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag full_level0

5> incremental level 0

6> filesperset 4

7> format ‘/oracle/backup/full_level0_%U_%T’

8> (database);

9> release channel c1;

10> }

allocated channel: c1

channel c1: SID=36 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting incremental level 0 datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00001 name=+DG_DATA/XXXDB/system01.dbf

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

input datafile file number=00004 name=+DG_DATA/XXXDB/undotbs201.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/full_level0_16q9aseg_1_1_20150612 tag=FULL_LEVEL0 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:15

channel c1: starting incremental level 0 datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00002 name=+DG_DATA/XXXDB/sysaux01.dbf

input datafile file number=00003 name=+DG_DATA/XXXDB/undotbs101.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/full_level0_17q9asf0_1_1_20150612 tag=FULL_LEVEL0 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:15

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-0f comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Backup 내용을 확인 해 보면 Incremental backup을 level 0으로 수행 한 것을 볼 수 있다.

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

34 Incr 0 272.41M DISK 00:00:07 12-JUN-15

BP Key: 34 Status: AVAILABLE Compressed: NO Tag: FULL_LEVEL0

Piece Name: /oracle/backup/full_level0_16q9aseg_1_1_20150612

List of Datafiles in backup set 34

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 0 Incr 1404169 12-JUN-15 +DG_DATA/XXXDB/system01.dbf

4 0 Incr 1404169 12-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 0 Incr 1404169 12-JUN-15 +DG_DATA/XXXDB/users01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

35 Incr 0 202.17M DISK 00:00:07 12-JUN-15

BP Key: 35 Status: AVAILABLE Compressed: NO Tag: FULL_LEVEL0

Piece Name: /oracle/backup/full_level0_17q9asf0_1_1_20150612

List of Datafiles in backup set 35

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

2 0 Incr 1404175 12-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 0 Incr 1404175 12-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

Incremental Backup을 이용한 Backup 전략의 예

구분	내용
Sun night	level 0 backup performed
Mon night	level 2 backup performed
Tue night	level 2 backup performed
Wed night	level 2 backup performed
Thu night	level 1 backup performed
Fri night	level 2 backup performed
Sat night	level 2 backup performed

만일 Database가 토요일 아침에 Crash가 발생했다고 가정하면 RMAN은 Sunday, Thursday, Friday 의 Backup을 이용하여 Recovery를 할 수 있다. 왜냐하면 Thursday의 level 1 Backup은 Sunday이후의 모든 변화된 내용을 포함하고 있고 Friday의 level 2는 Thursday이후에 모든 변화된 내용을 포함하고 있기 때문이다.

Cumulative Incremental Backup
Cumulative incremental Backup은 가장 최근의 N보다 작은 Backup이후의 변경된 부분만을 Backup하는 것이다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag Inc_level1

5> format ‘/oracle/backup/full_level1_%U_%T’

6> incremental level 1 cumulative database;

7> release channel c1;

8> }

allocated channel: c1

channel c1: SID=36 instance=XXXDB1 device type=DISK

Starting backup at 12-JUN-15

channel c1: starting incremental level 1 datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00001 name=+DG_DATA/XXXDB/system01.dbf

input datafile file number=00002 name=+DG_DATA/XXXDB/sysaux01.dbf

input datafile file number=00003 name=+DG_DATA/XXXDB/undotbs101.dbf

input datafile file number=00004 name=+DG_DATA/XXXDB/undotbs201.dbf

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

channel c1: starting piece 1 at 12-JUN-15

channel c1: finished piece 1 at 12-JUN-15

piece handle=/oracle/backup/full_level1_1bq9b10e_1_1_20150612 tag=INC_LEVEL1 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:15

Finished backup at 12-JUN-15

Starting Control File Autobackup at 12-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-11 comment=NONE

Finished Control File Autobackup at 12-JUN-15

released channel: c1

Backup 내용을 확인 해 보면 Incremental backup을 level 1으로 수행 한 것을 볼 수 있다.

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

39 Incr 1 6.87M DISK 00:00:13 12-JUN-15

BP Key: 39 Status: AVAILABLE Compressed: NO Tag: INC_LEVEL1

Piece Name: /oracle/backup/full_level1_1bq9b10e_1_1_20150612

List of Datafiles in backup set 39

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 1 Incr 1407864 12-JUN-15 +DG_DATA/XXXDB/system01.dbf

2 1 Incr 1407864 12-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 1 Incr 1407864 12-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

4 1 Incr 1407864 12-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 1 Incr 1407864 12-JUN-15 +DG_DATA/XXXDB/users01.dbf

RMAN 백업 작업 진행 사항 확인하기
RMAN 작업을 하다 보면 얼마나 진행되었고 얼마나 남았는지 궁금할 경우가 있다. 이럴 때는 아래의 방법으로 조회하면 결과를 알 수 있다.

SQL> r
1 SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
2 ROUND(SOFAR/TOTALWORK* 100,2) “%_COMPLETE”
3 FROM V$SESSION_LONGOPS

4 WHERE OPNAME LIKE ‘RMAN%’

5 AND OPNAME NOT LIKE ‘%aggregate%’

6 AND TOTALWORK != 0

7* AND SOFAR <> TOTALWORK

SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE

———- ———- ———- ———- ———- ———-

36 37905 1 101613 223360 45.49

SQL> r

1 SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,

2 ROUND(SOFAR/TOTALWORK* 100,2) “%_COMPLETE”

3 FROM V$SESSION_LONGOPS

4 WHERE OPNAME LIKE ‘RMAN%’

5 AND OPNAME NOT LIKE ‘%aggregate%’

6 AND TOTALWORK != 0

7* AND SOFAR <> TOTALWORK

SID SERIAL# CONTEXT SOFAR TOTALWORK %_COMPLETE

———- ———- ———- ———- ———- ———-

36 37905 1 180526 223360 80.82

SQL> r

1 SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,

2 ROUND(SOFAR/TOTALWORK* 100,2) “%_COMPLETE”

3 FROM V$SESSION_LONGOPS

4 WHERE OPNAME LIKE ‘RMAN%’

5 AND OPNAME NOT LIKE ‘%aggregate%’

6 AND TOTALWORK != 0

7* AND SOFAR <> TOTALWORK

no rows selected

à작업이 완료되면 no rows selected 로 나타남.

Recovery
1. Datafile 장애 복구
사용자가 DB shutdown 중 실수로 Datafile 을 삭제하였을 경우 또는 해당 Datafile이 깨졌을 경우 에 이와 같은 방법을 사용 할 수 있다

장애 발생 예제

ASM DISK Group은 Online 중에는 아래와 같이 삭제 되지 않는다.

ASMCMD [+DG_DATA/XXXDB] > rm users01.dbf
ORA-15032: not all alterations performed
ORA-15028: ASM file ‘+DG_DATA/XXXDB/users01.dbf’ not dropped; currently being accessed (DBD ERROR: OCIStmtExecute)

Instance shutdown 이후 삭제를 진행 한다.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

USERS TABLESPACE의 datafile을 삭제 한다.

ASMCMD [+DG_DATA/XXXDB] > rm users01.dbf

Datafile이 없으므로 mount 상태에서 open 되지 않는다. 5번 datafile이 깨지거나 삭제되어서 장애가 났음을 확인 할 수 있다.

SQL> startup
ORACLE instance started.
Total System Global Area 1157627904 bytes
Fixed Size 2923632 bytes

Variable Size 855638928 bytes

Database Buffers 285212672 bytes

Redo Buffers 13852672 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 5 – see DBWR trace file

ORA-01110: data file 5: ‘+DG_DATA/XXXDB/users01.dbf’

Datafile 복구 restore

데이터파일을 restore 한다. 5번 datafile 인 +DG_DATA/XXXDB/users01.dbf 파일을 restore 하는 과정이다. 위에서 백업 했던 incremental Backup의 level 0번을 가지고 restore 한다.

RMAN> restore datafile 5;
Starting restore at 12-JUN-15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=43 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00005 to +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_16q9aseg_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_16q9aseg_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

Finished restore at 12-JUN-15

Datafile 복구 recover

Restore 한 datafile에 대해 recover를 시행 시켜야 한다. 예제에서는 level0 full backup 이후 level1로 incremental backup을 받았는데, 가장 최근의 backup 파일 이므로 level1의 backup piece를 가지고 추가 recover를 시행 한다.

RMAN> recover datafile 5;
Starting recover at 12-JUN-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00005: +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level1_1dq9b2nk_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level1_1dq9b2nk_1_1_20150612 tag=INC_LEVEL1

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 12-JUN-15

Datafile 복구 Open 및 확인

정상적으로 recover가 되었는지 확인 한다. 정상적으로 +DG_DATA/XXXDB/users01.dbf 파일이 생성된 것을 확인 할 수 있다.

SQL> alter database open;
Database altered.
SQL> select instance_name, status from v$instance;
INSTANCE_NAME STATUS

—————- ————

XXXDB1 OPEN

SQL> select name from v$datafile;

NAME

———————————————

+DG_DATA/XXXDB/system01.dbf

+DG_DATA/XXXDB/sysaux01.dbf

+DG_DATA/XXXDB/undotbs101.dbf

+DG_DATA/XXXDB/undotbs201.dbf

+DG_DATA/XXXDB/users01.dbf

Tablespace 장애 복구

위에서 확인 하였던 datafile 장애 복구와 방법은 동일 하다. Restore 및 recover 할 때 tablespce로 복구 하면 된다. 아래 예제는 USERS TABLESPACE에 대해 RMAN script로 복구 하는 방법이다.

Tablespace 복구

장애가 발생한 users tablespace 에 대해 restore 후 recover 로 복구 하는 내용 이다.

RMAN> run {
2> RESTORE TABLESPACE users;
3> RECOVER TABLESPACE users;
4> }

Starting restore at 12-JUN-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=38 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00005 to +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_16q9aseg_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_16q9aseg_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 12-JUN-15

Starting recover at 12-JUN-15

using channel ORA_DISK_1

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00005: +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level1_1dq9b2nk_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level1_1dq9b2nk_1_1_20150612 tag=INC_LEVEL1

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

starting media recovery

media recovery complete, elapsed time: 00:00:00

Finished recover at 12-JUN-15

Tablespace 복구 Open 및 확인
정상 복구 되었는지 확인 한다. Users tablespace 가 정상적으로 복구 되었는지 확인 한다.

SQL> alter database open;
Database altered.
SQL> select instance_name, status from v$instance;
INSTANCE_NAME STATUS

—————- ————

XXXDB1 OPEN

SQL> select name from v$datafile;

NAME

——————————————-

+DG_DATA/XXXDB/system01.dbf

+DG_DATA/XXXDB/sysaux01.dbf

+DG_DATA/XXXDB/undotbs101.dbf

+DG_DATA/XXXDB/undotbs201.dbf

+DG_DATA/XXXDB/users01.dbf

Database 장애 복구

가장 최근에 백업한 backupset을 이용하여 database 전체 복구를 진행하는 방법이다. 아래 명령어를 수행하면 mount 까지 올린 상태에서 restore 및 recover 를 수행 한 다음, 데이터베이스를 open 시키는 방식이다.

기본적으로 restore controlfile command에 의하여 init.ora에 지정되어 있는 control_files의 위치로 자동적으로 controlfile들이 restore된다. 이렇게 하지 않고 특정한 위치를 지정하기 위해서는 restore controlfile to ‘filename’ 이라고 지정하면 된다.

RMAN> RUN {
2> startup mount;
3> RESTORE DATABASE;
4> RECOVER DATABASE;

5> sql ‘ALTER DATABASE OPEN’;

6> }

Oracle instance started

database mounted

Total System Global Area 1157627904 bytes

Fixed Size 2923632 bytes

Variable Size 855638928 bytes

Database Buffers 285212672 bytes

Redo Buffers 13852672 bytes

Starting restore at 12-JUN-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=41 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DG_DATA/XXXDB/system01.dbf

channel ORA_DISK_1: restoring datafile 00004 to +DG_DATA/XXXDB/undotbs201.dbf

channel ORA_DISK_1: restoring datafile 00005 to +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_16q9aseg_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_16q9aseg_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00002 to +DG_DATA/XXXDB/sysaux01.dbf

channel ORA_DISK_1: restoring datafile 00003 to +DG_DATA/XXXDB/undotbs101.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_17q9asf0_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_17q9asf0_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

Finished restore at 12-JUN-15

Starting recover at 12-JUN-15

using channel ORA_DISK_1

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00001: +DG_DATA/XXXDB/system01.dbf

destination for restore of datafile 00002: +DG_DATA/XXXDB/sysaux01.dbf

destination for restore of datafile 00003: +DG_DATA/XXXDB/undotbs101.dbf

destination for restore of datafile 00004: +DG_DATA/XXXDB/undotbs201.dbf

destination for restore of datafile 00005: +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level1_1dq9b2nk_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level1_1dq9b2nk_1_1_20150612 tag=INC_LEVEL1

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

starting media recovery

media recovery complete, elapsed time: 00:00:04

Finished recover at 12-JUN-15

sql statement: ALTER DATABASE OPEN

Drop table 후 복구

Drop table이나 drop user, update, delete 장애 등이 이 경우에 해당되며 모두 복구하는 원리는 동일하다. 이 방법에서 가장 중요한 것은 장애 난 시점의 시간인데 그 시간을 확인한 후 복구를 진행한다. 예로 test01 table을 생성 하고 drop 한 뒤 복구를 진행한다.

Test table 생성

SQL> set line 200
SQL> col tablespace_name for a10
SQL> col file_name for a50
SQL> select tablespace_name, bytes/1024/1024 MB, file_name from dba_data_files;

TABLESPACE MB FILE_NAME

———- ———- ————————————————–

SYSTEM 700 +DG_DATA/XXXDB/system01.dbf

SYSAUX 550 +DG_DATA/XXXDB/sysaux01.dbf

UNDOTBS1 290 +DG_DATA/XXXDB/undotbs101.dbf

UNDOTBS2 200 +DG_DATA/XXXDB/undotbs201.dbf

USERS 5 +DG_DATA/XXXDB/users01.dbf

SQL> conn wmsuser/wmsuser

Connected.

SQL> create table test01 (no number) tablespace users;

Table created.

à테스트 유저인 wmsuser에서 test01 이라는 테이블을 생성한다.

SQL> insert into test01 values(1);

1 row created.

SQL> insert into test01 values(2);

1 row created.

SQL> commit;

Commit complete.

à총2건의 데이터를 insert 한다.

SQL> select * from test01;

NO

———-

1

2

SQL> select to_char(sysdate, ‘YYYY-MM-DD:HH24:MI:SS’)

2 from dual;

TO_CHAR(SYSDATE,’YY

——————-

2015-06-12:21:56:00

à위 시간까지 테이블이 존재하는 시간이다.

Test table 삭제

테스트를 위해 위에서 생성한 table을 삭제 한다.

SQL> drop table test01 purge;
Table dropped.
SQL> select * from test01;
select * from test01

*

ERROR at line 1:

ORA-00942: table or view does not exist

à해당 테이블을 삭제하여 조회가 되지 않는다.

Test table 복구

DB를 정상 종료 시킨 후 해당 시간으로 복구를 진행하여, 위에서 삭제된 테이블을 복구 시킨다. Set until time은 그 시점까지 복구 하겠다는 의미이다. 이 시간은 위에서 테이블을 삭제 하기 전 시간이다.

이 방법에서 가장 핵심은 set until time 부분과 그 윗부분에 NLS_DATE_FORMAT 설정하는 부분이다. Drop table만 예로 했지만 drop user나 DML 장애 시에도 같은 방법으로 복구하면 된다.

RMAN> run {
2> startup mount;
3> sql ‘alter session set nls_date_format=”YYYY-MM-DD:HH24:MI:SS”‘;
4> set until time=’2015-06-12:21:56:00′;

5> restore database;

6> recover database;

7> alter database open resetlogs;

8> }

Oracle instance started

database mounted

Total System Global Area 1157627904 bytes

Fixed Size 2923632 bytes

Variable Size 855638928 bytes

Database Buffers 285212672 bytes

Redo Buffers 13852672 bytes

using target database control file instead of recovery catalog

sql statement: alter session set nls_date_format=”YYYY-MM-DD:HH24:MI:SS”

executing command: SET until clause

Starting restore at 12-JUN-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=41 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DG_DATA/XXXDB/system01.dbf

channel ORA_DISK_1: restoring datafile 00004 to +DG_DATA/XXXDB/undotbs201.dbf

channel ORA_DISK_1: restoring datafile 00005 to +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_16q9aseg_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_16q9aseg_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00002 to +DG_DATA/XXXDB/sysaux01.dbf

channel ORA_DISK_1: restoring datafile 00003 to +DG_DATA/XXXDB/undotbs101.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_17q9asf0_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_17q9asf0_1_1_20150612 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

Finished restore at 12-JUN-15

Starting recover at 12-JUN-15

using channel ORA_DISK_1

channel ORA_DISK_1: starting incremental datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

destination for restore of datafile 00001: +DG_DATA/XXXDB/system01.dbf

destination for restore of datafile 00002: +DG_DATA/XXXDB/sysaux01.dbf

destination for restore of datafile 00003: +DG_DATA/XXXDB/undotbs101.dbf

destination for restore of datafile 00004: +DG_DATA/XXXDB/undotbs201.dbf

destination for restore of datafile 00005: +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level1_1dq9b2nk_1_1_20150612

channel ORA_DISK_1: piece handle=/oracle/backup/full_level1_1dq9b2nk_1_1_20150612 tag=INC_LEVEL1

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

starting media recovery

media recovery complete, elapsed time: 00:00:09

Finished recover at 12-JUN-15

Statement processed

Test table 복구 확인

정상적으로 위에서 삭제한 테이블이 복구 되었는지 확인 한다.

SQL> select * from test01;
NO
———-
1

2

Drop tablespace 복구

사용자가 명령어로 수행 시킨 tablespace를 복구 시키는 방법 이다.

Drop tablespace test 현재 상태 확인

현재 DB 상태를 확인 한다.

SQL> set line 200
SQL> col tablespace_name for a10
SQL> col file_name for a50
SQL> select tablespace_name, bytes/1024/1024 MB, file_name

2 from dba_data_files;

TABLESPACE MB FILE_NAME

———- ———- ————————————————–

SYSTEM 700 +DG_DATA/XXXDB/system01.dbf

SYSAUX 550 +DG_DATA/XXXDB/sysaux01.dbf

UNDOTBS1 290 +DG_DATA/XXXDB/undotbs101.dbf

UNDOTBS2 200 +DG_DATA/XXXDB/undotbs201.dbf

USERS 5 +DG_DATA/XXXDB/users01.dbf

Drop tablespace test 용 테이블스페이스 생성

테스트를 위해 임시로 테이블 스페이스를 하나 생성한다.

SQL> create tablespace test
2 datafile ‘+DG_DATA/XXXDB/test01.dbf’ size 5M;
Tablespace created.
SQL> select tablespace_name, bytes/1024/1024 MB, file_name

2 from dba_data_files;

TABLESPACE MB FILE_NAME

———- ———- ————————————————–

SYSTEM 700 +DG_DATA/XXXDB/system01.dbf

SYSAUX 550 +DG_DATA/XXXDB/sysaux01.dbf

UNDOTBS1 290 +DG_DATA/XXXDB/undotbs101.dbf

UNDOTBS2 200 +DG_DATA/XXXDB/undotbs201.dbf

USERS 5 +DG_DATA/XXXDB/users01.dbf

TEST 5 +DG_DATA/XXXDB/test01.dbf

Drop tablespace test 전체 백업

해당 데이터베이스에 대해 전체 백업을 수행 한다.

RMAN> run {
2> allocate channel c1 type disk;
3> backup
4> tag full_level0

5> incremental level 0

6> filesperset 4

7> format ‘/oracle/backup/full_level0_%U_%T’

8> (database);

9> release channel c1;

10> }

using target database control file instead of recovery catalog

allocated channel: c1

channel c1: SID=69 instance=XXXDB1 device type=DISK

Starting backup at 13-JUN-15

channel c1: starting incremental level 0 datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00001 name=+DG_DATA/XXXDB/system01.dbf

input datafile file number=00005 name=+DG_DATA/XXXDB/users01.dbf

input datafile file number=00006 name=+DG_DATA/XXXDB/test01.dbf

input datafile file number=00004 name=+DG_DATA/XXXDB/undotbs201.dbf

channel c1: starting piece 1 at 13-JUN-15

channel c1: finished piece 1 at 13-JUN-15

piece handle=/oracle/backup/full_level0_1jq9c7ql_1_1_20150613 tag=FULL_LEVEL0 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:15

channel c1: starting incremental level 0 datafile backup set

channel c1: specifying datafile(s) in backup set

input datafile file number=00002 name=+DG_DATA/XXXDB/sysaux01.dbf

input datafile file number=00003 name=+DG_DATA/XXXDB/undotbs101.dbf

channel c1: starting piece 1 at 13-JUN-15

channel c1: finished piece 1 at 13-JUN-15

piece handle=/oracle/backup/full_level0_1kq9c7r5_1_1_20150613 tag=FULL_LEVEL0 comment=NONE

channel c1: backup set complete, elapsed time: 00:00:15

Finished backup at 13-JUN-15

Starting Control File Autobackup at 13-JUN-15

piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150613-00 comment=NONE

Finished Control File Autobackup at 13-JUN-15

released channel: c1

Drop tablespace test 용 테이블 및 데이터 입력

테스트를 위해 테이블 생성 및 데이터를 입력 한다. 위에서 생성한 테스트용 테이블 스페이스에 테이블을 생성 한다.

SQL> create table test02 (no number) tablespace test;
Table created.
SQL> insert into test02 values (1);
1 row created.

SQL> insert into test02 values (2);

1 row created.

SQL> commit;

SQL> @time

TO_CHAR(SYSDATE,’YY

——————-

2015-06-13:06:30:14

à위 시간까지는 해당 테이블 스페이스가 존재 한다.

Drop tablespace test 테이블스페이스 장애 발생

사용자가 실수로 해당 테이블스페이스를 삭제 한 내용이다. Drop tablespace 명령어를 사용하였다면 해당 데이터베이스의 alert log에 시간이 찍힌다.

SQL> drop tablespace test including contents and datafiles;
Tablespace dropped.
àalert log 확인
Sat Jun 13 06:31:11 2015 à 위시간 이전까지 테이블 스페이스가 존재 함.

drop tablespace test including contents and datafiles

Sat Jun 13 06:31:14 2015

Deleted file +DG_DATA/XXXDB/test01.dbf

Completed: drop tablespace test including contents and datafiles

Drop tablespace test 복구 시작

데이터베이스를 정상 기동 시킨 후, 가장 최근의 control file을 restore 한 후, 테이블 스페이스 삭제 전까지 복구를 진행 하면 된다. nls_date_format을 사용하여 NLS format 변경 후 위에서 확인 하였던 drop tablespace 전의 시간까지 복구를 진행 하면 된다. 아래 내용을 확인 하면 archive log file까지 적용하여 데이터까지 복구 된 것을 확인 할 수 있다.

RMAN> run {
2> startup nomount;
3> restore controlfile from ‘/oracle/12.1.0.2/dbs/c-611517755-20150613-00’;
4> sql ‘ALTER DATABASE MOUNT’;

5> sql ‘alter session set nls_date_format=”YYYY-MM-DD:HH24:MI:SS”‘;

6> set until time=’2015-06-13:06:31:09′;

7> restore database;

8> recover database;

9> alter database open resetlogs;

10> }

Oracle instance started

Total System Global Area 1157627904 bytes

Fixed Size 2923632 bytes

Variable Size 855638928 bytes

Database Buffers 285212672 bytes

Redo Buffers 13852672 bytes

Starting restore at 13-JUN-15

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=41 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

output file name=+DG_DATA/XXXDB/control01.ctl

output file name=+DG_DATA/XXXDB/control02.ctl

Finished restore at 13-JUN-15

sql statement: ALTER DATABASE MOUNT

released channel: ORA_DISK_1

sql statement: alter session set nls_date_format=”YYYY-MM-DD:HH24:MI:SS”

executing command: SET until clause

Starting restore at 13-JUN-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=41 instance=XXXDB1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DG_DATA/XXXDB/system01.dbf

channel ORA_DISK_1: restoring datafile 00004 to +DG_DATA/XXXDB/undotbs201.dbf

channel ORA_DISK_1: restoring datafile 00005 to +DG_DATA/XXXDB/users01.dbf

channel ORA_DISK_1: restoring datafile 00006 to +DG_DATA/XXXDB/test01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_1jq9c7ql_1_1_20150613

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_1jq9c7ql_1_1_20150613 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00002 to +DG_DATA/XXXDB/sysaux01.dbf

channel ORA_DISK_1: restoring datafile 00003 to +DG_DATA/XXXDB/undotbs101.dbf

channel ORA_DISK_1: reading from backup piece /oracle/backup/full_level0_1kq9c7r5_1_1_20150613

channel ORA_DISK_1: piece handle=/oracle/backup/full_level0_1kq9c7r5_1_1_20150613 tag=FULL_LEVEL0

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:25

Finished restore at 13-JUN-15

Starting recover at 13-JUN-15

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 3 is already on disk as file +DG_DATA/XXXDB/redo01.log

archived log file name=+DG_DATA/XXXDB/redo01.log thread=1 sequence=3

media recovery complete, elapsed time: 00:00:06

Finished recover at 13-JUN-15

Statement processed

Drop tablespace test 최종 확인

RMAN 관리하기
RMAN에 등록되어 있는 backupset등을 수작업을 통해 정리 할 필요가 생길 수도 있다. 아래 내용들은 RMAN의 정보를 동기화 및 정리 하는 방법 들이다.
1. Crosscheck
이 명령어는 정보를 동기화 시키는 역할을 한다. 불필요 backup들을 crosscheck 한다. 해당 명령어를 수행하여 backup의 상태를 확인 할 수 있다. 아래에서 AVAILABLE 이라는 것은 정상이라는 의미이다.

RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be ‘AVAILABLE’
backup piece handle=/oracle/12.1.0.2/dbs/01q97fn1_1_1 RECID=1 STAMP=882097890

crosschecked backup piece: found to be ‘AVAILABLE’

backup piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-00 RECID=2 STAMP=882156448

crosschecked backup piece: found to be ‘AVAILABLE’

backup piece handle=/oracle/backup/05q99aih_1_1_20150612 RECID=3 STAMP=882158161

만약 해당 backupset을 물리적으로(OS) 삭제 한 후 다시 crosscheck 수행을 해 보았다. 내용 중에서 파일이 삭제된 마지막 backupset을 보면 상태가 EXPIRED로 보인다. 이것은 backupset 목록에는 있는데 실제 백업 파일이 삭제되고 없다는 의미로 문제가 있음을 나타낸다. 즉 백업 파일을 지울 때도 RMAN 명령어로 삭제해야 하는데 그렇지 않고 0S 명령어로 삭제할 경우 이런 문제가 발생한다. 이럴 경우 backupset에서 EXPIRED 된 목록을 삭제해야 한다.

RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be ‘AVAILABLE’
backup piece handle=/oracle/12.1.0.2/dbs/01q97fn1_1_1 RECID=1 STAMP=882097890

crosschecked backup piece: found to be ‘AVAILABLE’

backup piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-00 RECID=2 STAMP=882156448

crosschecked backup piece: found to be ‘EXPIRED’

backup piece handle=/oracle/backup/05q99aih_1_1_20150612 RECID=3 STAMP=882158161

Delete expired backupset;

backupset에서 expired 된 목록을 삭제 하는 방법이다. EXPIRED된 목록이 나오면서 삭제 할것인지 선택 하는 부분이 나온다. 삭제를 선택 하면 RMAN 정보에서 삭제된 것을 알 수 있다.

RMAN> delete expired backupset;
using channel ORA_DISK_1
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name

——- ——- — — ———– ———– ———-

3 3 1 1 EXPIRED DISK /oracle/backup/05q99aih_1_1_20150612

Do you really want to delete the above objects (enter YES or NO)? y

deleted backup piece

backup piece handle=/oracle/backup/05q99aih_1_1_20150612 RECID=3 STAMP=882158161

Deleted 1 EXPIRED objects

Delete

특정 backup set을 삭제하고자 할 대 사용하는 명령어이다.

Backupset 목록 확인

현재 backup set 목록을 확인 한다.

RMAN> list backupset;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

1 Full 467.06M DISK 00:00:18 11-JUN-15

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20150611T111129

Piece Name: /oracle/12.1.0.2/dbs/01q97fn1_1_1

List of Datafiles in backup set 1

File LV Type Ckp SCN Ckp Time Name

—- — —- ———- ——— —-

1 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/system01.dbf

2 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/sysaux01.dbf

3 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs101.dbf

4 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/undotbs201.dbf

5 Full 1184537 11-JUN-15 +DG_DATA/XXXDB/users01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

2 Full 18.11M DISK 00:00:04 12-JUN-15

BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20150612T032724

Piece Name: /oracle/12.1.0.2/dbs/c-611517755-20150612-00

Control File Included: Ckp SCN: 1288040 Ckp time: 12-JUN-15

특정 backupset 삭제

목록에서 BS Key 라고 된 곳이 backup set number 이다. 해당 backup set을 삭제하려면 이 번호를 사용해야 한다.

RMAN> delete backupset 1;
using channel ORA_DISK_1
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name

——- ——- — — ———– ———– ———-

1 1 1 1 AVAILABLE DISK /oracle/12.1.0.2/dbs/01q97fn1_1_1

Do you really want to delete the above objects (enter YES or NO)? Y

deleted backup piece

backup piece handle=/oracle/12.1.0.2/dbs/01q97fn1_1_1 RECID=1 STAMP=882097890

Deleted 1 objects

Backupset 삭제 확인

Backup set number 1이 삭제 되었는지 확인 한다.

RMAN> list backupset;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time

——- —- — ———- ———– ———— —————

2 Full 18.11M DISK 00:00:04 12-JUN-15

BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20150612T032724

Piece Name: /oracle/12.1.0.2/dbs/c-611517755-20150612-00

Control File Included: Ckp SCN: 1288040 Ckp time: 12-JUN-15

Delete obsolete

RMAN은 보존 정책에 의해 폐기된 것으로 표시된 백업을 자동으로 삭제하지 않는다. 대신 RMAN은 이러한 백업을 REPORT OBSOLETE 출력 및 V$BACKUP_FILES의 OBSOLETE 컬럼에 OBSOLETE로 표시한다. RMAN은 사용자가 DELETE OBSOLETE 명령을 실행하면 폐기된 파일을 삭제한다.

RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
using channel ORA_DISK_1

Deleting the following obsolete backups and copies:

Type Key Completion Time Filename/Handle

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

Backup Set 2 12-JUN-15

Backup Piece 2 12-JUN-15 /oracle/12.1.0.2/dbs/c-611517755-20150612-00

Backup Set 4 12-JUN-15

Backup Piece 4 12-JUN-15 /oracle/12.1.0.2/dbs/c-611517755-20150612-01

Backup Set 5 12-JUN-15

Backup Piece 5 12-JUN-15 /oracle/backup/07q99aub_1_1_20150612

Backup Set 6 12-JUN-15

Backup Piece 6 12-JUN-15 /oracle/12.1.0.2/dbs/c-611517755-20150612-02

Backup Set 7 12-JUN-15

Backup Piece 7 12-JUN-15 /oracle/backup/manual/0aq99b12_1_1_20150612

Do you really want to delete the above objects (enter YES or NO)? Y

deleted backup piece

backup piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-00 RECID=2 STAMP=882156448

deleted backup piece

backup piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-01 RECID=4 STAMP=882158164

deleted backup piece

backup piece handle=/oracle/backup/07q99aub_1_1_20150612 RECID=5 STAMP=882158540

deleted backup piece

backup piece handle=/oracle/12.1.0.2/dbs/c-611517755-20150612-02 RECID=6 STAMP=882158543

deleted backup piece

backup piece handle=/oracle/backup/manual/0aq99b12_1_1_20150612 RECID=7 STAMP=882158626

Deleted 5 objects

Oracle Database 정기점검 Checklist
1. 일일 Checklist
  1. DATABASE

매일 alert_SID.log 파일의 내용과 trace file의 내용을 체크한다. 이 파일에서 internal error나 다른 oracle error들을 알 수 있다. 이 파일의 내용은 무한히 커지므로 이 파일이 위치한 file system 공간도 체크 할 필요가 있다.
alert_SID.log 파일이나 trace 파일 일정 크기 이상이 되면 backup을 받는다. alert_SID.ora는 무한히 커지므로 적당한 양만큼 backup을 받는다. 이 파일로 장애 발생의 유추가 가능하므로 일정 기간 이상은 보존이 필요하다.
Diagnostic dest 의 free space여부를 항상 확인한다.
각 tablespace에 free space를 생성되는 속도를 확인한다. 즉, database의 성장 속도를 확인하여 space 부족으로 생길 수 있는 DB가 hang이 걸리는 문제를 미리 대비할 수 있도록 한다.

Control file

매일 control file backup을 받았는지 alert_SID.log에서 확인 한다.

Online Redo Log file

log switch interval을 체크한다. Log Switch가 너무 자주 발생하면 Disk I/O에 영향이 있을 수 있고, 심해지면 DB hang이 걸릴 수 있다.
checkpoint 간격을 자주 확인하라. 권할 만한 checkpoint의 간격은 매 10에서 15분 정도이다. 이 checkpoint의 간격은 Background process가 죽어서 instance가 abort되는 극한 상황에서 database를 살리고 잠깐의 시간 동안 crash recovery를 할 때 반영된다. 위의 간격을 조절하려면 database에서 checkpoint interval setting 또는 checkpoint_timeout을 조절함에 의해 가능하다. checkpoint_timeout을 0으로 그리고 checkpoint_interval을 online redo log file의 크기보다 크게 두면 checkpoint는 log switch가 일어날 때마다 발생한다. 잦은 checkpoint는 crash recovery의 기간은 줄여주나 dirty buffers를 자주 쓰는 것과 file headers를 자주 update하는데 드는 overhead가 발생한다.

Archived log (Archive log Mode로 운영 시에만 해당됩니다.)

archive file이 생성되는 destination에 여유 공간이 있도록 유지한다. XXXDB의 경우에는 DG_ARCH disk group을 확인해야 하며, 여유 공간이 없을 시 DB Hang이 발생 할 수 있다.
alert.log에 Archive log들에 관한 error가 있는지 확인하라.

주 단위 Checklist

UNDO tablespace에 충분한 공간을 확보하여 ORA-1555 error를 피한다. ORA-1555에러는 Undo 공간이 부족해서 발생하면 발생하지만, bad query로도 유발될 수 있다.
SYSTEM tablespace 내에 다른 일반 사용자의 object들이나 temporary segments가 있는지 확인한다.
OS의 운영 상태를 확인할 수 있는 통계를 만들어서 관리한다.

월 단위 Checklist

월 단위 지표 별 DB성능증감 추이를 만들어 관리한다.
6개월에 한 번씩 recovery test를 한다. 장애가 발생할 때 대처할 수 있는 속도를 증가시키는 의미에서 6개월에 한번씩 recovery test가 필요하다.

ASM Disk Path 변경 방법
1. XXXDB stop (Node:1)

$ srvctl stop database -d XXXDB

DG_DATA, DG_ARCH Multi-Path Change Owner (Node:Both)

# chown grid:dba /dev/sddlmaa2

# chown grid:dba /dev/sddlmab1

DG_DATA, DG_ARCH Diskgroup Stop (Node:1)

$ srvctl stop diskgroup -g DG_DATA

$ srvctl stop diskgroup -g DG_ARCH

DG_DATA, DG_ARCH Single-Path Change Owner (Node:Both)

# chown root:disk /dev/sdb2

# chown root:disk /dev/sdc1

DG_DATA, DG_ARCH Diskgroup Start & Check (Node:1)

# srvctl start diskgroup -g DG_DATA

# srvctl start diskgroup -g DG_ARCH

XXXDB Start & Check & Stop (Node:1)

$ srvctl start database -d XXXDB

$ crs_stat –t

$ crsctl stat res –t

– alert log check

$ srvctl stop database -d XXXDB

OCR & Vote Migration (Node:1)

# /grid/12.1.0.2/bin/ocrcheck

# /grid/12.1.0.2/bin/ocrconfig -add +DG_ARCH

# /grid/12.1.0.2/bin/ocrconfig -delete +DG_CRS

# /grid/12.1.0.2/bin/ocrcheck

# /grid/12.1.0.2/bin/crsctl query css votedisk

# /grid/12.1.0.2/bin/crsctl replace votedisk +DG_ARCH

# /grid/12.1.0.2/bin/crsctl query css votedisk

CRS Stop (Node : Both)

# /grid/12.1.0.2/bin/crsctl stop crs

DG_CRS Multi & Single Path Change Ownership (Node:Both)

# chown grid:dba /dev/sddlmaa1

# chown root:disk /dev/sdb1

CRS Stat (Node:Both)

# /grid/12.1.0.2/bin/crsctl start crs

OCR & Vote Migration (Node:1)

# /grid/12.1.0.2/bin/ocrcheck

# /grid/12.1.0.2/bin/ocrconfig -add +DG_CRS

# /grid/12.1.0.2/bin/ocrconfig -delete +DG_ARCH

# /grid/12.1.0.2/bin/crsctl query css votedisk

# /grid/12.1.0.2/bin/crsctl replace votedisk +DG_CRS

# /grid/12.1.0.2/bin/crsctl query css votedisk

XXXDB Start & Check (Node:1)

$ srvctl start database -d XXXDB

$ crs_stat -t

$ crsctl stat res –t

– alert log check

/etc/rc.d/rc.local modify (Both)

# vi /etc/rc.d/rc.local

chown grid:dba /dev/sddlmaa1

chown grid:dba /dev/sddlmaa2

chown grid:dba /dev/sddlmab1

# chmod +x /etc/rc.d/rc.local

Server Reboot & Device Ownership Check (Both)

/grid/12.1.0.2/bin/crsctl stop crs

Reboot

11g R2 이상버전에서 사설 네트워크 정보를 수정하는 방법

11.2 이상의 그리드 인프라스트럭처에서, 사설 네트워크 구성은 OCR에 저장될 뿐만 아니라 gpnp 프로파일에도 저장됩니다.

만약 사설 네트워크가 가용하지 않거나 그 정의가 잘못되었다면, CRSD 프로세스는 기동되지 않을 것이며 OCR에 그 다음의 어떠한 변화도 불가능할 것입니다.

그러므로 사설 네트워크의 구성을 변경할 때는 주의를 기울이는 것이 필요합니다. 올바른 순서로 변경을 수행하는 것은 중요합니다.

또한 gpnp 프로파일의 수동변경은 지원되지 않으니 주의하시기 바랍니다.

수행전에 모든 클러스터 노드에 있는 profile.xml 을 grid 유저로 백업하시기 바랍니다:

$ cd $GRID_HOME/gpnp/<hostname>/profiles/peer/

$ cp -p profile.xml profile.xml.bk

모든 오라클 클러스터웨어가 기동중인지 확인.
grid 유저로 현재의 정보를 얻으시기 바랍니다. 예를 들면

$ oifcfg getif

eth1 100.17.10.0 global public

eth0 192.168.0.0 global cluster_interconnect

* 새로운 cluster_interconnect 정보를 추가합니다:

$ oifcfg setif -global <interface>/<subnet>:cluster_interconnect

For example:

a. add a new interface bond0 with the same subnet

$ oifcfg setif -global bond0/192.168.0.0:cluster_interconnect

b. add a new subnet with the same interface name but different subnet or new interface name

$ oifcfg setif -global eth0/192.65.0.0:cluster_interconnect

or

$ oifcfg setif -global eth3/192.168.1.96:cluster_interconnect

* 참고사항

1. 이것은 인터페이스가 아직 가용하지 않을지라도 -global 옵션을 통해 수행될 수 있습니다.

그러나 만약 인터페이스가 가용하지않다면 이것은 -node 옵션으로는 수행될 수 없으며 이것은노드 이빅션으로 연결될 것입니다.

2. 만약 인터페이스가 그 서버에서 가용하다면 서브넷 주소는 다음의 명령에 의해서

알 수 있습니다.

$ oifcfg iflist

그것은 네트워크 인터페이스와 그것의 서브넷 주소의 목록을 보여줍니다.

이 명령은 오라클 클러스터웨어가 기동중이 아닐지라도 수행될 수 있습니다.

서브넷 주소가 x.y.z.0 의 형태가 아닐 수도 있고 x.y.z.24, x.y.z.64 또는 x.y.z.128 등등 일 수도 있음을 주의하십시오.

예를 들면,

$ oifcfg iflist

lan1 18.1.2.0

lan2 10.2.3.64 << 이것은 사설 네트워크 IP: 10.2.3.86 과 관련있는 사설 네트워크 서브넷 주소입니다

3. 존재하는 사설 네트워크를 대체하는게 아닌 2번째 사설 네트워크를 추가하는 것이라면 두 인터페이스의 MTU 크기가 동일한지 확인하고

그렇지않으면 인스턴스 기동시 에러가 나타날 것입니다.

ORA-27504: IPC error creating OSD context

ORA-27300: OS system dependent operation:if MTU failed with status: 0

ORA-27301: OS failure message: Error 0

ORA-27302: failure occurred at: skgxpcini2

ORA-27303: additional information: requested interface lan1:801 has a different MTU (1500) than lan3:801 (9000),

which is not supported. Check output from ifconfig command

변경을 확인하십시오:

$ oifcfg getif

root유저를 통해 모든 노드의 오라클 클러스터웨어를 내리고 비활성화하시기 바랍니다.

# crsctl stop crs

# crsctl disable crs

요구된 사항으로 OS레벨에서 네트워크 구성 변경을 수행하고, 그 변경이후 모든 노드에서 새로운 인터페이스가 가용한지 확인하시기 바랍니다.

$ ifconfig -a

$ ping <private hostname>

오라클 클러스터웨를 활성화하고 root유저로서 모든 노드에서 오라클 클러스터웨어를 재기동하시기 바랍니다.

# crsctl enable crs

# crsctl start crs

필요하다면 기존 인터페이스를 제거하시기 바랍니다.

$ oifcfg delif -global <if_name>[/<subnet>]

eg:

$ oifcfg delif -global eth0/192.168.0.0

주의사항
1. 만약 기본적인 네트워크 구성이 변경되었지만 그 동일 변경을 위한 oifcfg 가 수행되지않았다면, 오라클 클러스터웨어가 재기동될 때 CRSD는 기동되지 않을 것입니다.

The crsd.log 는 다음과 같을 것입니다:

2010-01-30 09:22:47.234: [ default][2926461424] CRS Daemon Starting

..

2010-01-30 09:22:47.273: [ GPnP][2926461424]clsgpnp_Init: [at clsgpnp0.c:837] GPnP client pid=7153, tl=3, f=0

2010-01-30 09:22:47.282: [ OCRAPI][2926461424]clsu_get_private_ip_addresses: no ip addresses found.

2010-01-30 09:22:47.282: [GIPCXCPT][2926461424] gipcShutdownF: skipping shutdown, count 2, from [ clsinet.c : 1732], ret gipcretSuccess (0)

2010-01-30 09:22:47.283: [GIPCXCPT][2926461424] gipcShutdownF: skipping shutdown, count 1, from [ clsgpnp0.c : 1021], ret gipcretSuccess (0)

[ OCRAPI][2926461424]a_init_clsss: failed to call clsu_get_private_ip_addr (7)

2010-01-30 09:22:47.285: [ OCRAPI][2926461424]a_init:13!: Clusterware initunsuccessful : [44]

2010-01-30 09:22:47.285: [ CRSOCR][2926461424] OCR context init failure. Error: PROC-44: Error in network address and interface operations Network address and interface operations error [7]

2010-01-30 09:22:47.285: [ CRSD][2926461424][PANIC] CRSD exiting: Could not init OCR, code: 44

2010-01-30 09:22:47.285: [ CRSD][2926461424] Done.

위의 에러는 OS 설정(oifcfg iflist)과 gpnp 프로파일 설정 profile.xml 간의 부정합을 나타냅니다.

회피방법: OS 네트워크 구성을 원래 상태로 복원하시기 바랍니다. 그리고나서 다시 그 변경을 위한 위의 단계들을 수행하시기 바랍니다.

만약 기본 네트워크가 변경되지 않았지만 oifcfg setif 가 잘못된 서브넷 주소나 인터페이스명을 가지고 수행되었다면 동일한 문제가 일어날 것입니다.

클러스터에 어느 한 노드라도 다운되었다면 oifcfg 명령은 다음의 에러와 함께 실패할 것입니다.

$ oifcfg setif -global bond0/192.168.0.0:cluster_interconnect

PRIF-26: Error in update the profiles in the cluster

회피방법: 기동되어 있지않은 노드의 오라클 클러스터웨어를 기동하시기 바랍니다. 오라클 클러스터웨어가 모든 클러스터 노드에서 기동중인지 확인하시기 바랍니다.

만약 어떤 OS 문제로 그 노드가 다운되었다면 사설 네트워크 변경을 수행하기전에 클러스터로부터 그 노드를 제거하시기 바랍니다.

만약 그리드 인프라스트럭처 소유자가 아닌 유저가 위의 명령을 수행하면, 다음과 같은 에러가 발생하며 실패할 것입니다.

$ oifcfg setif -global bond0/192.168.0.0:cluster_interconnect

PRIF-26: Error in update the profiles in the cluster

회피방법: 그러한 명령을 수행하기위해 그리드 인프라스트럭처 소유자로 로그인하였는지 확인하시기 바랍니다.

11.2.0.2 부터, 새로운 인터페이스를 추가하지 않고 마지막 사설 인터페이스(cluster_interconnect)를 지우려고 시도한다면 다음의 에러가 발생.

PRIF-31: Failed to delete the specified network interface because it is the last private interface

회피방법: 기존 사설 인터페이스를 지우기전에 우선 새로운 사설 인터페이스를 추가하시기 바랍니다.

오라클 클러스터웨어가 노드에서 다운시, 다음의 에러 발생

$ oifcfg getif

PRIF-10: failed to initialize the cluster registry

회피방법: 그 노드에서 오라클 클러스터웨어를 기동하시기 바랍니다

[OGG] COLMATCH

argoLee — Sat, 20 Jan 2024 01:28:47 +0900

Extract / Replicat에서 사용
컬럼 맵핑에 대한 global 규칙 적용. global 규칙은 TABLE, MAP에서 RESET 옵션으로 해제할 수 있다.
개별 TABLE, MAP 구문에서 COLMAP으로 테이블 레벨을 사용하기보다 다른 컬럼을 가진 비슷한 구조의 테이블 사이에서 매핑을 할 수 있다.

COLMATCH
{NAMES target_column = source_column |
PREFIX prefix |
SUFFIX suffix |
RESET}

- NAMES target_column = source_column
  - CUSTOMER_CODE = CUST_CODE 형태로 지정
- PREFIX prefix | SUFFIX suffix
  - 무시할 prefix 또는 suffix 를 지정한다.
예를 들어 TARGET의 ORDER_ID 와 SOURCE의 P_ORDER_ID을 매핑하기 위해서 ("P_" 부분이 무시된다)

COLMATCH PREFIX "P_"

예를 들어 TARGET의 CUST_CODE_K 와 SOURCE의 CUST_CODE을 매핑하기 위해서 ( "_K" 부분이 무시된다)

COLMATCH SUFFIX "_K"

COLMATCH RESET은 다음으로 오는 TABLE, MAP 구문에서 규칙이 해제된다.

COLMATCH RESET

SAMPLE TABLE

ACCT Table	ORD Table
CUST_CODE CUST_NAME CUST_ADDR PHONE S_REP S_REPCODE	CUST_CODE CUST_NAME ORDER_ID ORDER_AMT S_REP S_REPCODE

ACCOUNT Table	ORDER Table
CUSTOMER_CODE CUSTOMER_NAME CUSTOMER_ADDRESS PHONE REP REPCODE	CUSTOMER_CODE CUSTOMER_NAME ORDER_ID ORDER_AMT REP REPCODE

COLMATCH NAMES CUSTOMER_CODE = CUST_CODE
COLMATCH NAMES CUSTOMER_NAME = CUST_NAME
COLMATCH NAMES CUSTOMER_ADDRESS = CUST_ADDR
COLMATCH PREFIX S_

MAP SALES.ACCT, TARGET SALES.ACCOUNT, COLMAP (USEDEFAULTS);
MAP SALE.ORD, TARGET SALES.ORDER, COLMAP (USEDEFAULTS);

COLMATCH RESET

MAP SALES.REG, TARGET SALE.REG;
MAP SALES.PRICE, TARGET SALES.PRICE;

샘플 설명
- 소스의 ACCT 와 ORD 테이블의 CUST_CODE는 타겟의 ACCOUNT와 ORDER 테이블의 CUSTOMER_CODE와 매핑된다.
- "S_" prefix는 무시된다.
- PHONE, ORDER_AMT와 같은 동일한 컬럼은 USEDEFAULTS를 사용하여 자동으로 매핑된다.
- REG와 PRICE 테이블은 COLMATCH RESET으로 인해 global 규칙은 해제되고, 모든 컬럼명이 동일하기 때문에 자동으로 매핑된다.

[OGG] FILTER 데이터 선택

argoLee — Sat, 20 Jan 2024 01:17:39 +0900

하나 이상의 OGG 컬럼 변환 함수 또는 기본 operator를 사용하여 numeric 값에 기반하여 데이터를 select하기 위해 FILTER 절을 사용한다.
string 기반 컬럼을 filter하기 위해서는 WHERE 구문 또는 OGG string 변환 함수를 사용한다.
FILTER는 하나라도 실패하거나 모드 패스될 때까지 리스트된 순서대로 실행하며, 하나라도 실패하면 모두 실패처리된다.

"ON INSERT | ON UPDATE | ON DELETE IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE" 옵션으로 filter 절에서 사용하는 SQL 작업을 지정.
RAISEERROR 옵션은 사용자 지정 오류를 생성하도록 MAP의 FILTER절에서 사용

REPERROR (9999, EXCEPTION)
MAP OWNER.SRCTAB, TARGET OWNER.TARGTAB,
                   SQLEXEC (ID CHECK, ON UPDATE, QUERY ' SELECT COUNT FROM TARGTAB WHERE PKCOL = :P1 ', PARAMS (P1 = PKCOL)),
                   FILTER (BALANCE > 15000),
                   FILTER (ON UPDATE, @BEFORE (COUNT) = CHECK.COUNT)
;
MAP OWNER.SRCTAB, TARGET OWNER.TARGEXC,
EXCEPTIONSONLY,
COLMAP (   USEDEFAULTS,
ERRTYPE = 'UPDATE FILTER FAILED'
);

Parameter file	Description
REPERROR (9999, EXCEPTION)	Raises an exception for the specified error.
MAP OWNER.SRCTAB, TARGET OWNER.TARGTAB,	Starts the MAP statement.
SQLEXEC (ID CHECK, ON UPDATE, QUERY ' SELECT COUNT FROM TARGTAB ' 'WHERE PKCOL = :P1 ', PARAMS (P1 = PKCOL)),	update될 때마다 COUNT 컬럼의 현재 값을 추출하는 쿼리. BEFOREFILTER 옵션은 FILTER 절을 처리기 전에 쿼리나 PLSQL이 실행되도록하는 옵션. SQLEXEC 에서 추출한 값은 실행 중인FILTER 내부에서 사용된다.
FILTER (BALANCE > 15000),	BALNACE가 1500보다 큰 값을 추출
FILTER (ON UPDATE, @BEFORE (COUNT) = CHECK.COUNT)	또다른 FILTER 절 사용 가능. update 전에 소스 COUNT 컬럼의 값과 target 컬럼을 업데이트 전의 컬럼 값을 매칭한다.
;	The semicolon concludes the MAP statement.
MAP OWNER.SRCTAB, TARGET OWNER.TARGEXC, EXCEPTIONSONLY, COLMAP (USEDEFAULTS, ERRTYPE = 'UPDATE FILTER FAILED');	Designates an exceptions MAP statement. The REPERROR clause for error 9999 ensures that the exceptions map to TARGEXC will be executed.

@COMPUTE 함수

product price 와 product amount의 곱 이 10000 이상인 record 추출
MAP SALES.TCUSTORD, TARGET SALES.TORD,
FILTER (@COMPUTE (PRODUCT_PRICE * PRODUCT_AMOUNT) > 10000);

@STREQ 함수

character column의 값 'JOE'인 record를 추출하는 함수
TABLE ACCT.TCUSTORD, FILTER (@STREQ ("Name", 'joe') > 0);

RECORD SELECT

amount 컬럼이 50보다 크고, update, delete 작업인 record 선택
TABLE ACT.TCUSTORD, FILTER (ON UPDATE, ON DELETE, AMOUNT > 50);

@RANGE 함수

MAP sales.acct, TARGET sales.acct, FILTER (@RANGE (1, 2, ID)

데이터 파이프 라인 쉽고 빠르게 구축하기

argoLee — Wed, 17 Jan 2024 22:13:23 +0900

비즈니스의 규모와 관계없이 데이터 분석 환경을 구축하는 것은 모든 비즈니스의 과제입니다. 그러나 정확한 분석 결과를 위해서는 데이터 레이크 파이프 라인 구축이 선행되어야 합니다.

본 강연에서는 특히 중소, 중견 기업 고객분들의 워크로드와 데이터 사이즈에 눈높이를 맞추어 빠르고 쉽게 그리고 비용 효율적으로 AWS 환경에서 데이터 레이크를 구축할 수 있는 아키텍처를 알아봅니다.

https://www.youtube.com/watch?v=n0m7ggIFkR8&t=1311s

https://catalog.us-east-1.prod.workshops.aws/workshops/19d47d52-4de6-4b4c-be00-8d99c102f74c/ko-KR

Easy DataLake

catalog.us-east-1.prod.workshops.aws

마이크로서비스 아키텍처(MSA)

argoLee — Thu, 11 Jan 2024 15:35:07 +0900

마이크로서비스 아키텍처(MSA)는 작고 독립적인 서비스들의 집합으로 구성된 애플리케이션 구조이다

마이크로서비스 아키텍처(Microservice Architecture)와 모놀리식 아키텍처(Monolithic Architecture)의 장단점을 비교하고, 각각 어떤 상황에서 각각이 적합한지에 대해 알아보겠다.

모놀리식 아키텍처 (Monolithic Architecture)

모놀리식 아키텍처는 전통적인 개발 방식으로 하나의 프로젝트에 모든 기능을 함께 포함한다. 이렇게 하면 코드 베이스가 커질수록 개발 및 배포에 복잡성이 증가한다.

아래는 모놀리식 아키텍처의 예시이다.

출처 : http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

모놀리식 아키텍처의 경우 위의 그림과 같이 모듈단위로 쪼개는 것이 아닌 하나의 프로젝트로 전체 애플리케이션을 묶어서 개발하는 방식이다. 이의 경우 회원, 상품, 주문뿐만 아니라 여러 개의 비즈니스 로직이 추가된다면 코드베이스가 커지게 되는 구조이다.

아래는 모놀리식 아키텍처의 장단점을 추려보았다

모놀리식 아키텍처의 장점
- 초기 개발에 유리하며 빠르게 프로토타입을 개발할 수 있다.
- 필요한 모든 기능을 한 번만 호출하기 때문에 복잡한 통신 없이 직접 사용할 수 있다.

모놀리식 아키텍처의 단점
- 코드 베이스가 커질수록 복잡해지고 유지관리 및 확장이 어려워진다.
- 일부 기능을 수정하거나 업데이트를 하려면 전체 애플리케이션을 재배포해야한다.

모놀리식 아키텍처를 사용하기에 적합한 상황

- 간단한 소규모 프로젝트( 사이드 프로젝트 )
- 프로토타입 제작 및 단기 프로젝트

마이크로서비스 아키텍처 (Microservice Architecture)

MSA는 여러 개의 작은 서비스로 구성되어 각 서비스가 독립적으로 개발되고 배포되는 구조이다.
MSA로 구성되어 있는 애플리케이션의 경우 전체 시트템이 분산되어 있어 개발, 배포가 독립적으로 가능하며 확장성과 유지관리가 용이해진다.

아래는 MSA에 대한 예시이다.

출처:http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

MSA의 경우 위의 그림과 같이 애플리케이션을 작은 독립적인 서비스로 분리하고, 각 서비스는 모듈 또는 프로젝트로 나눠서 개발 및 관리를 진행한다. 이렇게 개발을 진행할 경우 독립적으로 개발 및 배포가 가능하여 개별적인 배포 주기를 가질 수 있다.

아래는 MSA의 장단점을 추려보았다.

MSA의 장점
- 서비스 간 독립성으로 인해 확장성과 유연성이 높아진다.
- 기능 고립성이라는 특징 때문에 일부 서비스가 실패하더라도 전체 시스템에 큰 영향을 미치지 않는다.

MSA의 단점
- 서비스 간 통신이 필요하며, 서로 간 연결 구축 및 관리의 복잡성이 증가한다.
- 초기 개발 및 통신 등에 시간이 소요된다.