'분류 전체보기'에 해당되는 글 44건

  1. 2019.08.31 [성능튜닝] ASH(Active Session History)
  2. 2019.08.24 undo tablespace full 관련
  3. 2019.08.07 Oracle 12C RAC DB 운영 매뉴얼
  4. 2019.07.04 CRS 설명
  5. 2019.07.03 OCR & Voting Disk
  6. 2019.07.02 ASM 모니터링
  7. 2019.07.02 OCR 관리
  8. 2019.07.02 OCR 과 Vote disk
  9. 2019.07.02 [RAC] OCR(Oracle Configuration Repository), VOTING
  10. 2019.07.02 RAC 구조

[성능튜닝] ASH(Active Session History)

ORACLE/공부하기 2019. 8. 31. 08:07
반응형

[성능튜닝] ASH(Active Session History)란?

12bme 2018.01.30 13:41

ASH(Active Session History)

 

SQL> select * from v$sgastat where name = 'ASH buffers';

 

POOL      NAME    BYTES

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

shared pool ASH buffers 16252928

 

- 오라클은 현재 접속해서 활동 중인 Active 세션 정보를 1초에 한번씩 샘플링해서 ASH 버퍼에 저장합니다.

- SGA Shared Pool에 CPU당 2MB의 버퍼를 할당받아 세션 정보를 기록하며, 1시간 혹은 버퍼의 2/3가 찰때마다 디스크로 기록합니다. 즉, AWR에 저장하는 것입니다.

- v$active_session_history 뷰를 이용해 ASH 버퍼에 저장된 세션 히스토리 정보를 조회할 수 있습니다.

 

select /* 1. 샘플링이 일어난 시간과 샘플 ID */ sample_id, sample_time /* 2. 세션정보, User명, 트랜잭션ID */ , session_id, session_serial#, user_id, xid /* 3. 수행중 SQL 정보 */ , sql_id, sql_child_number, sql_plan_hash_value /* 4. 현재 세션의 상태 정보 'ON CPU' 또는 'WAITING' */ , session_state /* 5. 병렬 Slave 세션일때, 쿼리 코디네이터(QC) 정보를 찾을 수 있게함 */ , qc_instance_id, gc_session_id /* 6. 현재 세션의 진행을 막고 있는(=블로킹) 세션 정보 */ , blocking_session, block_session_serial#, blocking_session_status /* 7. 현재 발생 중인 대기 이벤트 정보 */ , event, event#, seq#, wait_class, wait_time, time_waited /* 8. 현재 발생 중인 대기 이벤트의 파라미터 정보 */ , p1text, p1, p2text, p2, p3text, p3 /* 9. 해당 세션이 현재 참조하고 있는 오브젝트 정보. V$session 뷰에 있는 row_wait_obj#, row_wait_file#, row_wait_block# 컬럼을 가져온 것임 */ , current_obj#, current_file#, current_block# /* 10. 애플리케이션 정보 */ , program, module, action, client_id from V$ACTIVE_SESSION_HISTORY

7과 8번 '대기 이벤트' 정보는 두말할 것도 없고, 6번 '블로킹 세션' 정보와 9번 '현재 액세스 중인 오브젝트' 정보도 매우 유용합니다. 블로킹 세션 정보를 통해 현재 Lock을 발생시킨 세션을 빠릴 찾아 해소할 수 있게 도와줍니다.

 

오브젝트 정보도 더할 나위 없이 유용하지만 현재 발생 중인 대기 이벤트의 Wait Class가 Application, Concurrency, Cluster, User I/O일 때만 의미있는 값임을 알아야 합니다.

 

예를 들어, ITL 슬롯 부족?? 때문에 발생하는 enq: TX - allocate ITL entry 대기 이벤트는 Configuration에 속하므로, v$active_session_history 뷰를 조회할 때 함께 출력되는 오브젝트에 Lock이 걸렸다고 판단해서는 안됩니다. 대개 그럴때는 오브젝트 번호가 -1로 출력되지만 직전에 발생한 이벤트의 오브젝트 정보가 계속 남아서 보이는 경우가 있으므로 잘못 해석하지 않도록 주의해야 합니다.

 

column current_obj# format 99999 heading 'CUR_OBJ#'

column current_file# format 999 heading 'CUR_FIL#'

column current_block# format 999 heading 'CUR_BLK#'

select to_char(sample_time, 'hh24:mi:ss') sample_tm, session_state, event, wait_class, current_obj#, current_file#, current_block#

from v$active_session_history

where session_id = 143

and session_serial# = 9

order by sample_time;

 

 

 SAMPLE_T

 SESSION

 EVENT

 WAIT_CLASS

 CUR_OBJ#

 EUR_FIL#

 CUR_CLK#

 15:00:44

 WAITING

 Enq: TX - row lock contention

 Application

 55765

 4

 476

 15:00:45

 WAITING

 Enq: TX - row lock contention

 Application

 55765

 4

 476

 15:00:46

 WAITING

 Enq: TX - row lock contention

 Application

 55765

 4

 476

 15:00:47

 WAITING

 Enq: TX - row lock contention

 Application

 55765

 4

 476

 15:01:36

 WAITING

 Enq: TX - allocation ITL entry

 Configuration

 -1

 4

 476

 15:01:37

 WAITING

 Enq: TX - allocation ITL entry

 Configuration

 -1

 4

 476

 15:01:38

 WAITING

 Enq: TX - allocation ITL entry

 Configuration

 -1

 4

 476

 15:01:39

 WAITING

 Enq: TX - allocation ITL entry

 Configuration

 -1

 4

 476

 

초단위로 쓰기가 발생하는 ASH 버퍼를 읽을 때 래치를 사용한다면 경합이 생길 수 있습니다. 따라서 오라클은 ASH 버퍼를 읽는 세션에 대해서는 래치를 요구하지 않으며 그 때문에 간혹 일관성 없는 잘못된 정보가 나타날 수도 있습니다.

 

ASH 기능을 이용하면 현재뿐 아니라 과거시점에 발생한 장애 및 성능 저하 원인까지 세션 레벨로 분석할 수 있게 도와줍니다. 오라클 10g부터는 v$active_session_history 정보를 AWR 내에 보관하므로 과거치에 대한 세션 레벨 분석이 가능해졌습니다 (SGA를 DMA방식으로 액세스)

 

1/10만 샘플링해서 저장(문제가 되는 대기 이벤트는 일정간격을 두고 지속적으로 발생하기 때문에 샘플링된 자료만으로도 원인을 찾는데 큰 지장이 없습니다)

 

v$active_session_history를 조회했을때 정보가 찾아지지 않는다면 이미 AWR에 쓰여진것으로 dba_hist_active_sess_history 뷰를 조회하면 됩니다.

 

 

1. AWR 뷰를 이용해 하루 동안의 이벤트 발생현황을 조회해본다. 그래프는 dba_hist_system_event를 이용해 그린 것인데, 08:15~09:15 구간에서 enq: TM - contention 이벤트가 다량 발생한 것이 환인 되었다.

2. dba_hist_active_sess_history를 조회해서 해당 이벤트를 많이 대기한 세션을 확인한다.

3. 블로킹 세션 정보를 통해 dba_hist_active_sess_history를 다시 조회한다. 블로킹 세션이 찾아지면 해당 세션이 그 시점에 어떤 작업을 수행 중이었는지 확인한다. sql_id를 이용해 그 당시 SQL과 실행계획까지 확인할 수 있다. v$sql과 v$sql_plan까지 AWR에 저장되기 때문이다. 위 사례에서는 블로킹 세션인 Append Mode Insert를 수행하면서 Exclusive 모드 TM Lock에 의한 경합이 발생하고 있었다.

4. program, module, action, client_id 등 애플리케이션 정보를 이용해 관련 프로그램을 찾아 Append 힌트를 제거한다. 그러고 나서, 다른 트랜잭션과 동시에 DML이 발생할 수 있는 상황에서는 insert문에 Append 힌트를 사용해서는 안된다는 사실을 개발팀 전체에 공지한다.

 

 

ASH Viewer

ASH Viewer는 오라클 인스턴스 액티브 세션 히스토리 데이터 모니터링을 제공합니다. 링크를 통해 무료로 오픈소스기반 모니터링 툴을 다운받을 수 있습니다.

 

최근 ASH Viewer를 통해 실시간으로 Oracle 시스템을 모니터링하며 업무 진행하고 있습니다. V$ACTIVE_SESSION_HISTORY 데이터 기반으로 실시간으로 Oracle 시스템 현황을 모니터링 하는 툴인데요. 아직까지는 익숙치 않지만, 기존에 블로그를 통해 학습해왔던 오라클 시스템 튜닝 용어들을 실제 사용과 함께 눈에 익히고 있는 중입니다.

 

아래는 데모동영상에서 캡쳐한 화면입니다. 실제 Top Activity 화면도 아래와 같았습니다.

 

 

Other, Cluster, Queueing, Network, Administrative, Configuration, Commit, Application, Concurrency, System I/O, User I/O, Scheduler, CPU Used등의 항목을 Activice 세션당 사용률에 따라 아래 그래프처럼 표시됩니다. 보고싶은 시간만큼 그래프를 드래그하면 SQL, Session, Program 상세를 확인할 수 있습니다.

 

Detail 탭을 누르면 Top Activity 항목에 대한 상세 현황 그래프를 확인할 수 있습니다.

 

 

- CPU used (Active Session Waiting)

 

- Scheduler (Active Session Waiting)

 

- User I/O (Active Session Waiting)

   direct path write temp

   direct path read

   db file parallel read

   direct path read temp

   local write wait

   db file scattered read

   db file sequential read

 

- System I/O (Active Session Waiting)

   log file single write

   log archive I/O

   db file parallel write

   log file parallel write

   log file sequential read

   control file parallel write

   control file sequential read

 

- Concurrency (Active Session Waiting)

   row cache lock

   library cache lock

   os thread startup

 

- Application (Active Session Waiting)

   enq: R0 - fast object reuse

   enq: R0 - fast object reuse

 

- Commit (Active Session Waiting)

   log file sync

 

- Configuration (Active Session Waiting)

   log file switch (check point incomplete)

   enq: HW - contention

   log buffer space

   log file switch completion

 

- Administrative (Active Session Waiting)

 

- Network (Active Session Waiting)

   SQL*Net more data from client

   SQL*Net more data to client

 

- Queueing (Active Session Waiting)

 

- Cluster (Active Session Waiting)

   gc current grant busy

   gc cr block busy

   gc cr disk read

   gc current request

   gc cr request

   gc current block 3-way

   gc current multi block request

   gc current block busy

   gc cr multi block request

   gc cr block 3-way

   gc cr block 2-way

   gc current block 2-way

   gc cr grant 2-way

 

- Other (Active Session Waiting)

   enq: TT - contention

   px deq:L Signal ACK

   LGWR wait for redo copy

   reliable message

   latch: KCL gc element parent latch

   gcs log flush sync

   enq: FB - contention

   enq: WF - contention

   null event

   CGS wait for IPC msg

   DFS lock handle

   enq: PS - contention

 

 

실행방법: "/bin/java.exe" -Xmx528m -Dswing.defaultlaf=javax.swing.plaf.nimbusLookAndFeel -jar ASH.jar

 

* swing.defaultlaf 디폴트 Look&Feel 클래스 지정

 

* 실행방법 옵션 관련 추가 팁

JAVA 기반 어플리케이션을 구동하다보면 OOM(Out Of Memory)관련 에러가 발생하는 경우가 종종있습니다. 이럴 경우, JVM 옵션을 통해 관련 부분을 튜닝할 수 있습니다. 위 실행 방법의 Xmx가 그 옵션 중 하나입니다.

 

 

 

JAVA 메모리 구조

 - Heap = Eden + Survivor + Old

 - Non-Heap = Perm

 

GC와 Heap 영역의 기본 동작 원리

 - gc는 Eden과 ss1을 클리어하고 여전히 유효한 메모리에 대해서는 ss2로 이동시킵니다.

 - 그 다음 gc는 Eden과 ss2을 클리어하고 다시 유효한 메모리에 대해서는 ss1로 이동시킵니다.

 

메모리는 우선, Heap과 Non-Heap으로 나뉩니다.

 - Heap영역: new 연산자로 생성된 객체와 배열을 저장하는 영역으로 GC대상이 되는 영역입니다.

Eden: new키워드를 통해서 객체가 처음 생성되는 공간

Survivor: GC가 수행될때 살아있는 객체는 survivor 영역으로 이동

Old: survivor에서 일정시간 참조되는 객체들이 이동되는 공간

 - Non-Heap영역: 스택, 클래스 area, method area 등의 head을 제외한 나머지 영역

      Permanent: Class 메타정보, Method 메타정보, Static Object, 상수화된 String Object, Class관련 배열 메타정보, JVM 내부 객체와 최적화컴파일러(JIT) 최적화 정보 등 포함

 

XX: MaxPerm Size 옵션 값

XX:MaxPerm Size는 hot-deploy가 있을때 메모리 사용량이 점차 증가하는 부분입니다. 가령 서버에서 PermGen OOM 에러 발생시 이부분의 사이즈를 조절해야 합니다.

 

JVM Option

  -Xms

 초기 Heap Size (Init, default 64M)

  -Xmx

 최대 Heap Size (Max, default 256M)

  -XX:PermSize

 초기 PermSize

  -XX:MaxPermSize

 최대 PermSize

  -XX:NewSize

 최소 new size(객체가 생성되어 저장되는 초기공간의 Size로 Eden+Survivor 영역)

  -XX:MaxNewSize

 최대 new Size

  -XX:SurvivorRatio

 New/Survivor영역 비율 (n으로 지정시 Eden: Survivor = 1:n)

  -XX:NewRatio

 Young Gen과 Old Gen의 비율(n으로 지정시 Young:Old = 1:n)

  -XX:+DisableExplicitGC

 System.gc() 콜을 무시

  -XX:+UseConcMarkSweepGC

 표준 gc가 아니나 Perm Gen영역도 gc하는 Concurrent Collector를 사용

  -XX:+CMSPermGenSweepingEnabled

 Perm gen영역도 GC의 대상이 되도록 지정

  -XX:+CMSClassUnloadingEnabled

 클래스 데이터도 GC의 대상이 되도록 지정

 

위에 기본 값을 기준으로 흔하게 일어나는 상황에 대한 조치 방법은 아래와 같습니다.

 

 

Hot Deploy 사용으로 재배포가 자주 일어나는 시스템 환경인 경우

1. PermGen 영역의 사이즈를 충분히 늘린다(but 한계 존재)

2. UseConcMarkSweepGC, CMSPermGenSweepingEnabled, CMSClassUnloadingEnabled 등의 옵션으로 PermGen 영역도 GC 수행

 

OOME, PermGen OOME(Out of Memory Exception) 발생

1. OOME: Xms, Xmx 조정

2. PermGen OOME: XX:PermSize, XX:MaxPermSize 조정

 

Xmx, Xmx를 동일하게 세팅하는 이유

1. Xms로 init메모리를 잡고, committed 도달할때까지 Used용량이 점차 증가하는데, committed에 도달시 메모리를 추가할 당시 시스템 부하 발생(WAS가 몇 ms가량 멈출 가능성 있음)

2. 메모리 용량은 init < used < committed < max

 

보통 운영시스템에서 Xms와 Xmx를 동일하게 지정하는 이유는 init와 max사이에서 used 메모리가 committed까지 사용하게 되면, 신규 메모리 공간을 요구하는데 이때 약 1초가량 jvm이 메모리 할당을 멈추는 경우가 생깁니다. 그래서 Xms와 Xmx를 동일하게 주고 메모리를 확보한 상태에서 jvm을 기동시키고는 합니다.

 

ASH Viewer 다운로드

 

https://sourceforge.net/projects/ashv/

 

 

'ORACLE > 공부하기' 카테고리의 다른 글

Oracle RAC의 Cache Fusion 캐시퓨전(2)  (1) 2024.02.23
Oracle RAC의 Cache Fusion 캐시퓨전(1)  (0) 2024.02.23
undo tablespace full 관련  (0) 2019.08.24
CRS 설명  (0) 2019.07.04
OCR & Voting Disk  (0) 2019.07.03
Posted by Max-Jang
,

undo tablespace full 관련

ORACLE/공부하기 2019. 8. 24. 03:25
반응형

Undo segment를 과도하게 사용하여

예를 들어, 개발한 배치, 개발자의 임의 작업 등이 잘못 진행되고 있다가 뒤늦게 발견하여 cancel했을 경우라던가 할 때

이를 rollback을 하는 중이지만 UNDO tablespace의 unexpire 영역이 반환되지 않아,

정규 배치 등의 서비스가 실패할 가능성이 있는 시나리오에 대응하려면

다음 쿼리들을 통해 문제를 해결하도록 한다.

 

 

Rollback 진행 중인 undo segment를 조회하는 쿼리

 

parallel rollback 일 경우

select * from v$fast_start_transactions where state='RECOVERING';

 

serial rollback 일 경우 (x$KTUXE(Kernel Transaction Undo Transaction Entry))

select ktuxesiz from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;

 

Undo tablespace의 사용량은 다음과 같이 확인한다.

col msg format a80
WITH TB AS (
SELECT TABLESPACE_NAME
,(SELECT ROUND(SUM(BLOCKS)*8/1024) FROM DBA_DATA_FILES WHERE TABLESPACE_NAME=A.TABLESPACE_NAME) TOT_MB
,SUM(DECODE(A.STATUS,'ACTIVE' ,SIZE_MB,0)) ACTIVE_MB
,SUM(DECODE(A.STATUS,'UNEXPIRED',SIZE_MB,0)) UNEXPI_MB
,SUM(DECODE(A.STATUS,'EXPIRED' ,SIZE_MB,0)) EXPIRE_MB
FROM (
SELECT TABLESPACE_NAME, STATUS, ROUND(SUM(BYTES)/1024/1024) SIZE_MB
FROM DBA_UNDO_EXTENTS
--WHERE tablespace_name in ( select value from v$parameter where name='undo_tablespace')
GROUP BY TABLESPACE_NAME, STATUS
) A
GROUP BY TABLESPACE_NAME
)
SELECT to_char(sysdate,'HH24:MI:SS')||' '||TABLESPACE_NAME||' : '||round((active_mb+unexpi_mb+expire_mb)/tot_mb*100)||
' % -> Act('||active_mb||') Unexp('||unexpi_mb||') Exp('||expire_mb||') TOT('||TOT_MB||')' MSG,
round(100*(ACTIVE_MB)/TOT_MB,2),
round(100*(ACTIVE_MB+UNEXPI_MB)/TOT_MB,2)
FROM TB;

 

현재 진행되고 있는 rollback의 잔여시간은 다음 쿼리로 대충 추산할 수 있다.

set serveroutput on
declare
l_start number ;
l_end number ;
r_min number ;
begin
select ktuxesiz into l_start from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;
dbms_lock.sleep(60);
select ktuxesiz into l_end from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;
r_min := round(l_end / (l_start - l_end) ) ;
dbms_output.put_line('['||to_char(sysdate,'HH24:MI:SS')||'] Remain Time : '|| r_min ||'분 '|| round(r_min/60,2)||'시간 / '||(l_start-l_end)||' blocks done / '|| l_end ||' Total blocks remains' );
end ;
/

 

운영DB에 임시 UNDO Tablespace를 생성한 후, 향후의 트랜잭션들은 이 UNDO tbs를 사용하도록 조치한다.

create undo tablespace undotbs2 datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_001';

alter tablespace undotbs2 add datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_002';

...

alter tablespace undotbs2 add datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_NNN';

 

alter system set undo_tablespace=undotbs2 ;

이때 UNDO tablespace를 변경하는 것 자체는 금방 수행되므로 긴장하지 않아도 된다.

다만, alert log에 'active transactions found in undo tablespace NN - moved to pending switch-out state 라는 로그가 트랜잭션 당 1 라인씩 계속 발생할 수 있는데, 어떤 사이트의 경우에는 이 메시지가 다량 발생하기도 하였다고 하므로, alert log가 존재하는 path의 가용량을 모니터링하면서 작업 수행하자.

이러한 세션들은 세션에서 commit을 찍고 알아서 종료되길 기다리거나, 아니면 kill하여 처리하면 된다.

 

UNDO tablespace를 switch 한 후, 이전의 UNDO tbs를 사용하는 채로 commit 되지 않고 남아있는 세션을 찾아본다

select a.usn, a.name, b.status, c.tablespace_name, d.addr, e.sid, e.serial#, e.username, e.program, e.machine, e.osuser
from v$rollname a, v$rollstat b, dba_rollback_segs c, v$transaction d, v$session e
where a.usn=b.usn
and a.name = c.segment_name
and a.usn = d.xidusn
and d.addr = e.taddr
and b.status = 'PENDING OFFLINE';

 

rollback이 종료되고 상황이 정상화 되면,

기존 UNDO tablespace를 사용하도록 파라미터를 재설정해주고,

추가했었던 UNDO tablespace를 drop하면 된다.

'ORACLE > 공부하기' 카테고리의 다른 글

Oracle RAC의 Cache Fusion 캐시퓨전(1)  (0) 2024.02.23
[성능튜닝] ASH(Active Session History)  (0) 2019.08.31
CRS 설명  (0) 2019.07.04
OCR & Voting Disk  (0) 2019.07.03
ASM 모니터링  (0) 2019.07.02
Posted by Max-Jang
,

Oracle 12C RAC DB 운영 매뉴얼

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

 

  1. 네트워크 구성정보
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

  1. Oracle Grid Infrastructure Process 구조

     

    1. Cluster Synchronization Services (CSS)
  • Cluster에 어떤 node가 추가/제거 되었는지 모니터링 및 정보관리
  • Heartbeat 메커니즘을 이용 (interconnect를 통한 Network Heartbeat)
  • 각 멤버 node 들에게 node membership 정보 전달
  • Vendor clusterware 사용시 직접 통신하면서 node membership 정보 관리
  • Css 프로세스 비정상 종료 시 node reboot
  1. Cluster Ready Services (CRS)
  • Database, Instance, Service, Listener, VIP, Application 등 모든 cluster 리소스들을 OCR에 등록되어 있는 리소스 정보에 기반하여 관리
  • 리소스 모니터링 중 장애발생시 해당 리소스 start, stop, failover 조치
  • cluster 리소스 등록/제거, 모니터링, 시동/중지 관련 명령어 인터페이스를 제공
  • crs 프로세스 종료 시, init process에 의해 자동으로 재 기동
  1. Event Manager
  • evmd.bin 프로세스
  • grid user로 동작
  • crs가 발생시키는 이벤트들을 전파
  • Log 파일에 이벤트를 기록하는 역할 (evmlogger)
  • Racgimon이 전달하는 메시지에 따라 racgevt 프로세스 fork
  • Fail시, 자동 재 기동
  1. Process Monitor Daemon(OPROCD)
  • IO fencing 기능 제공을 위한 Oracle 솔루션
  • Vendor clusterware를 사용하는 경우, 동작 하지 않음
  1. Global Service Daemon(GSD)
  • 9i 이전의 클라이언트가 11g CRS에 접속하여 각 종 관리업무를 수행할 수 있도록 돕는 프로세스
  • 11g에서는 backward compatibility를 위해서만 존재할 뿐 특별한 역할 없음
  1. Virtual IP
  • IP failover를 위해 Oracle CRS가 제공
  • Public network interface에 VIP를 할당
  • Network interface에 오류가 발생하면 CRS가 fail된 VIP의 address를 살아있는 node로 failover
  1. Single Client Access Name(SCAN)
  • 11gR2 RAC부터 소개된 기능으로 Cluster로 구성되어 운영중인 Oracle Database 에 접근하는 모든 Client에서 SCAN으로 접속할 수 있다.
  • SCAN으로 접속 시 자동으로 Server Side Load Balancing을 수행한다. (Default로 Remote Listener에 SCAN이 등록됨)
  • SCAN은 Grid 설치 시 반드시 구성해야 하며, GNS을 사용하지 않는다면, SCAN NAME을 아래와 같이 DNS상에 등록해줘야 한다.
  • 기본적으로 3개의 Public IP를 동일한 이름으로 등록해줘야 하며, Public과 SCAN 의 subset은 동일하여야 한다. (최소 1개의 IP등록)

  1. Oracle Grid Infrastructure 관련 파일

    1. Oracle Cluster Registry(OCR)
  • Cluster 리소스들에 대한 정보 저장소
  • 반드시 shared disk상에 위치
  • Multiplexing 가능 (multiplexing 권장)
  • Enterprise Manager / Server Control Utility (SRVCTL) / Database Configuration Assistant (DBCA)을 통해서 수정 가능
  1. Voting Disk
  • Cluster membership 관리를 위해 css 데몬이 이용
  • Cluster member들의 health check
  • Split brain 상태에서 node의 상태를 판단하기 위한 second heartbeat 역할
  • 반드시 shared disk상에 위치
  • Multiplexing 가능 (multiplexing 권장)

Split Brain

: 일반적으로 클러스터로 구성된 두 시스템 그룹 간 네트워크의 일시적 동시 단절현상이 발생했을때 나타나는 현상

: 클러스터 상의 모든 노드들이 노드 각자가 자신을 primary라고 인식하게 되는 상황

-> 어느 특정 리소스에 대한 두 시스템 그룹 간의 모든 네트워크 연결이 동시에 실패하면 네트워크 파이션이 발생함

-> 이 상태가 발생하면 파티션 양쪽의 시스템이 각각 반대쪽에서 응용프로그램을 재시작하여 중복서비스 또는 Split brain을 유발함

 

Split brain은 클러스터로 구성된 독립적인 두 시스템이 특정 리소스(일반적으로 파일 시스템 또는 볼륨)에 대한 배타적 액세스 권한이 있다고 가정할 경우 발생

네트워크 파티션으로인해 발생하는 가장 심각한문제는 공유디스크의 데이터에 영향을 준다는 점

 

클러스터 내의 모든 노드들이 자신이 primary(master)노드라고 인삭하는 것 -> 데이터의 동기화에 문제가 발생할 수 있음

  1. 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만 기동
  1. 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.
  1. 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

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

  1. 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

——————————————————————-
  1. 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

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

  1. Listener 기동과 정지

    1. Listener 기동
  • grid 계정으로 아래의 명령을 수행하여 Listener를 기동한다.
# su – grid
$ srvctl start 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

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

——————————————————————-
  1. 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

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

  1. 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;
  1. 새로운 User 권한 부여
  • 관리자가 User를 생성하면 해당 User에게 각각 필요한 권한을 부여할 수 있다.
  • 다음 명령어를 통하여 User로 접속 가능하도록 할 수 있는 권한과 Object를 생성할 수 있는 권한을 부여한다.
$ sqlplus “/as sysdba”
SQL> grant resource, connect to test_user;
  1. User 패스워드 변경
  • 다음 명령어를 통하여 password를 test로 변경할 수 있다.
$ sqlplus “/as sysdba”
SQL> alter user test_user identified by test
  1. User 삭제
  • 다음 명령어를 통하여 User를 삭제할 수 있다.
$ sqlplus “/as sysdba”
SQL> drop user test_user cascade;

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

  1. Database tablespace 관리

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

  1. 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
  1. 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

  1. Automatic Storage Management (ASM)

    1. ASM 구조

      1. ASM 개요

      Automatic Storage Management(ASM)는 데이터베이스 구성 시 기본이 되는 디스크를 효율적으로 관리하기 위해 Oracle Database 10g에서 새로 선보이는 데이터베이스 서비스이다. ASM은 하나의 SMP 장비뿐만 아니라, RAC을 구성하는 모든 노드들에 대해서도 지원이 가능하다.

      ASM이 관리하는 모든 디스크에 대해 load balancing 작업을 자동적으로 처리해 줌으로써, 특정 디스크에 load가 집중되는 hot spot 현상을 최소화 할 수 있으며, 이로 인해 성능을 극대화 할 수 있다. 또한, 데이터가 디스크에 균등한 크기로 저장/관리되어 fragmentation 현상이 발생하지 않는다. 그리고, ASM이 관리하는 영역에서 새로운 디스크가 추가되거나 삭제될 때마다, 기존 데이터들에 대해 재구성 작업이 자동적으로 일어난다.

      ASM은 특정 데이터에 대한 복사본을 자기 자신의 디스크에 유지할 수 있기 때문에 Software 미러링 효과를 볼 수 있다. 이처럼 ASM은 데이터에 대한 안정성, 그리고 성능을 어떻게 유지할 것인가에 대해 상당히 유연하게 달리 지정할 수 있다.

      ASM은 기존 데이터베이스 구성과 독립적으로 관리될 수 있다. 즉, 기존 데이터베이스가 데이터 저장소로 파일시스템을 사용하고 있어도, 아니면 RAW Device를 사용하고 있어도 이와는 별도로 새로운 데이터파일을 ASM에 저장/관리할 수 있는 것이다. 기존 데이터 파일들은 ASM 관리 영역으로 이관될 수도 있다.

      ASM을 단순히 기존 파일시스템, RAW Device와 같은 파일 저장소로 간과하면 큰 오산이다. ASM은 여타 디스크 Solution 없이 Striping / Mirroring 효과를 볼 수 있을 뿐만 아니라, 자동적으로 데이터 구성을 재 분배할 수 있는 기능을 제공해 줌으로써, 더 이상 I/O tuning을 할 필요로 없게 만들고 있다. 또한, 자체가 Cluster 파일시스템 이기 때문에 하나 이상의 노드에 있는 다른 데이터베이스에 대해서도 통합 관리가 가능한 것이다. DBA들은 더 이상 스토리지 관리를 위해 엄청난 시간을 투자할 필요가 없게 되었다.

  1. ASM의 기본 개념
  • Oracle 10g부터 지원되는 Volume Manager와 File system의 통합체
  • Oracle 데이터베이스 파일을 위해 특별히 구현된 Storage 관리 시스템
  • Disk간 Balance가 유지될 수 있도록 분산 저장, Mirroring을 지원

  • Oracle은 Volume Manager, File System, Raw Device 등의 방법 대신 ASM의 사용을 권장하고 있음 (11g부터는 Raw Device는 공식적으로 지원되지 않음)

     

  1. ASM 주요 기능 및 특징
구분 내용
관리 복잡성 제거
  • 매일 처리해야만 하는 스토리지 관리항목이 줄어들거나 제거된다.
  • 모든 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 파일시스템이 필요 없다.
  1. 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

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

 

  1. ASM Instance Processes
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의 이동이 발생하면 순간적으로 프로세스 개수가 여러 개 생길 수 있음.

  1. ASM 디스크

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

 

  1. 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을 정의해야 한다.
  1. Failure Group

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

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

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

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

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

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

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

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

  1. ASM 모니터링 및 관리하기

    1. ASM Instance 접속

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

[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
  1. 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
  1. ASM Disk group Drop

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

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> drop diskgroup oratest;

Diskgroup dropped.

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
  1. 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
  1. ASM Disk group disk add

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

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

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 뷰를 조회하여 리밸런싱 작업에 걸리는 시간을 추정할 수 있다.

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 10 0

DG_DATA_0000 REBAL WAIT 10 0

DG_DATA_0001 REBAL WAIT 10 0

DG_DATA_0001 REBAL RUN 10 0
  1. 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
  1. 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
  1. 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

  1. Oracle Software 변경 관리

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

 

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

 

  1. 적용된 패치 확인
  • 다음 명령어를 통하여 적용된 패치를 확인할 수 있다.
$ 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.

  1. 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 복구

  1. 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 에 적용
  1. 주요 Parameter
구분 Parameter 설정 값 설명
Archive log_archive_dest_1 LOCATION=/ARCH archive log file 이 저장될 위치
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 생성시 지연된 공간 할당설정
  1. 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’;

  1. 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
  1. 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)
  1. CRS 관련 로그
로그 위치 Directory Description
/grid/12.1.0.2/log/<hostname> crsd crs daemon이 활동한 로그가 저장된다.
cssd css daemon이 활동한 로그가 저장된다.
evmd evm daemon이 활동한 로그가 저장된다.

  1. 백업과 복구

    1. 백업 개요

      오라클은 다양한 백업(Back-up) 기능을 제공한다. 오라클은 백업의 형태에 따라 데이터베이스가 붕괴된 시점까지도 복구할 수 있다. 그러나, 오라클을 복구하는 과정에서 기본이 되는 것은 데이터베이스 백업(Backup) 이다. 즉, 데이터베이스의 일관성 있는 백업이 선행되어야 오라클 복구(Recovery) 작업도 수월하게 이루어질 수 있다.

      데이터베이스를 구축한다는 것은 하나의 데이터를 여러 유저가 공유하기 위함도 있지만 무엇보다도 데이터의 안정성이다. 만일의 사태가 발생하더라도 데이터의 손실을 막는 것에 목적이 있다.

      오라클은 ARCHIVELOG 모드이냐 NOARCHIVELOG 모드로 운영되느냐에 따라 백업의 형태가 달라지며 백업 정책도 달라진다. 각 모드마다 장단점이 있지만 ARCHIVE 모드가 물론 더 안정적이다.

      오라클에서 제공하는 백업의 종류는 다음과 같다.

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

      Oracle ASM 환경에서의 Online Backup은 RMAN으로만 가능하므로 RMAN 기능에 대한 내용은 10장에 소개하고, Export/Import 에 대한 내용은 다음과 같다.

       

    2. Export / Import

      Export 는 Database 에 저장된 내용을 file 형태의 O/S dump file 로 추출하는 tool이다. 반대로 import 는 export 로 받은 O/S Dump file 을 database 에 저장시키는 tool 이다.

      Export / Import 는 모든 user 들의 전체 backup 이나 user 단위, 또는 특정 object만 backup 할 수 있으므로 database 의 backup 은 물론, Oracle database 간의 data 이동이나, Oracle 의 새로운 version upgrade 등에 사용될 수 있으며 문제발생시 특정 object 별 복구가 가능하다는 장점이 있는 반면에, database 복구 시, 물리적인 backup ( cold backup, hot backup ) 과 상호 관련성이 없기 때문에 장애 발생 시점까지의 복구는 불가능하며, 단지 export 를 수행한 시점까지의 복구만이 가능하기 때문에 export 를 이용한 복구는 data 의 손실을 감안하여야 한다는 단점이 있다.

      1. Export option
옵션 내용
userid 유저명과 패스워드를 쓴다.
file export 받는 덤프 파일을 지정한다.
log export 받을 때 로그 파일을 지정한다.
rows 데이터를 받을 것인지 아닌지를 지정한다.
constraints 테이블의 제약 조건을 받을 것인지 지정한다.
indexes 인덱스를 받을 것인지를 지정한다.
tables 유저의 특정 테이블을 받고자 할 때 사용된다.
compress 테이블을 위해 EXTENT 된 값이 Storage 값의 INITIAL 값에 설정된다.
full userid 가 system이거나 dba 권한이 있는 유저일 경우에만 설정 가능하며, 데이터베이스 전체를 받고자 할 때 사용된다.
  1. Import option
옵션 내용
userid 유저명과 패스워드를 쓴다.
file export 받은 덤프 파일을 지정한다.
log import 할 때 로그 파일을 지정한다.
rows 데이터를 삽입 할 것인지 아닌지를 지정한다.
constraints 테이블의 제약 조건을 넣을 것인지 지정한다.
indexes 인덱스를 생성 할 것인지를 지정한다.
tables 유저의 특정 테이블을 지정하여 삽입 할 때 사용된다.
indexfile 데이터를 import하지 않고 create index 문장의 SQL로 파일이 만들어진다.
fromuser 다른 유저에게 export 한 파일을 import 하고자 할 때 export 한 유저를 지정한다.
touser import 할 유저를 지정한다.
  1. 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

  1. 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 을 줄 수 있다.
  1. 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에 기록한다. 이 과정까지 끝나면 백업이 완료된다.

  1. 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를 사용할 경우만 해당)

  1. RMAN 명령어

    1. RMAN 접속

    SQL*Plus로 데이터베이스에 접속하듯이 RMAN으로도 데이터베이스에 접속한다.

    차이점은 RMAN은 SYSDBA 권한을 가지고 타겟과 보조 데이터베이스에 접속해야 하는데 AS SYSDBA 키워드는 사용하지 않아도 묵시적으로 가진 것으로 접속이 가능하다.

    ORACLE USER로 수행 한다.

[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>
  1. 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’;
  1. 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 값이 나타난다.
  1. 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

  1. 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
  1. 수동 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
  1. Channel 할당 정리

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

  1. 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
  1. 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
  1. 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
  1. 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
  1. 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
  1. 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

  1. Incremental backup

    Archivelog mode 인 경우 open 상태에서 database, tablespace, datafile 단위에서 incremental backup 이 가능하다. 즉 parent incremental backup 의 SCN 과 비교해서 큰 block 만을 copy 한다. incremental 은 differential incremental 과 cumulative incremental 로 나뉜다. default 는 differential 이다.

    Level N incremental Backup은 가장 최근의 N 또는 N보다 작은 Backup이후의 변경된 부분만을 Backup하는 것이다. List Backup Set을 조회해 보면 Type Column에는 ‘Incr’, LV Column에는 ‘0’이라고 나타날 것이다.

    만약 recovery time 이 disk space 보다 중요한 고려사항이라면 cumulative backup 이 differential backup 보다 유리하다.

    10g 이상부터는 block change tracking 을 enable 시키면 datafile 을 full scan 하지 않고서도 변경된 block 을 tracking 할 수 있으므로 backup 시 성능향상을 꾀할 수 있다.

    1. Incremental backup 수행

      아래 예제는 level 0으로 데이터베이스 전체를 백업 받는 내용 이다. Filesperset 파라미터는 backup file에 최대 4개의 데이터 파일씩 백업 받도록 하는 파라미터이다

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
  1. 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이후에 모든 변화된 내용을 포함하고 있기 때문이다.

  1. 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

  1. 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 로 나타남.

  1. 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
  1. 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
  1. 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
  1. 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
  1. 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 최종 확인
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

TEST 5 +DG_DATA/XXXDB/test01.dbf

6 rows selected.

SQL> select * from test02;

NO

———-

1

2

  1. 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
  1. 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
  1. 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
  1. 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

  1. 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이 걸리는 문제를 미리 대비할 수 있도록 한다.
  1. Control file
  • 매일 control file backup을 받았는지 alert_SID.log에서 확인 한다.
  1. 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가 발생한다.
  1. Archived log (Archive log Mode로 운영 시에만 해당됩니다.)
  • archive file이 생성되는 destination에 여유 공간이 있도록 유지한다. XXXDB의 경우에는 DG_ARCH disk group을 확인해야 하며, 여유 공간이 없을 시 DB Hang이 발생 할 수 있다.

  • alert.log에 Archive log들에 관한 error가 있는지 확인하라.

  1. 주 단위 Checklist
  • UNDO tablespace에 충분한 공간을 확보하여 ORA-1555 error를 피한다. ORA-1555에러는 Undo 공간이 부족해서 발생하면 발생하지만, bad query로도 유발될 수 있다.
  • SYSTEM tablespace 내에 다른 일반 사용자의 object들이나 temporary segments가 있는지 확인한다.

  • OS의 운영 상태를 확인할 수 있는 통계를 만들어서 관리한다.

  1. 월 단위 Checklist
  • 월 단위 지표 별 DB성능증감 추이를 만들어 관리한다.
  • 6개월에 한 번씩 recovery test를 한다. 장애가 발생할 때 대처할 수 있는 속도를 증가시키는 의미에서 6개월에 한번씩 recovery test가 필요하다.

  1. ASM Disk Path 변경 방법

    1. XXXDB stop (Node:1)

$ srvctl stop database -d XXXDB

  1. DG_DATA, DG_ARCH Multi-Path Change Owner (Node:Both)

# chown grid:dba /dev/sddlmaa2

# chown grid:dba /dev/sddlmab1

  1. DG_DATA, DG_ARCH Diskgroup Stop (Node:1)

$ srvctl stop diskgroup -g DG_DATA

$ srvctl stop diskgroup -g DG_ARCH

  1. DG_DATA, DG_ARCH Single-Path Change Owner (Node:Both)

# chown root:disk /dev/sdb2

# chown root:disk /dev/sdc1

  1. DG_DATA, DG_ARCH Diskgroup Start & Check (Node:1)

# srvctl start diskgroup -g DG_DATA

# srvctl start diskgroup -g DG_ARCH

  1. 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

  1. 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

  1. CRS Stop (Node : Both)

# /grid/12.1.0.2/bin/crsctl stop crs

  1. DG_CRS Multi & Single Path Change Ownership (Node:Both)

# chown grid:dba /dev/sddlmaa1

# chown root:disk /dev/sdb1

  1. CRS Stat (Node:Both)

# /grid/12.1.0.2/bin/crsctl start crs

  1. 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

  1. XXXDB Start & Check (Node:1)

$ srvctl start database -d XXXDB

$ crs_stat -t

$ crsctl stat res –t

– alert log check

  1. /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

  1. Server Reboot & Device Ownership Check (Both)

/grid/12.1.0.2/bin/crsctl stop crs

Reboot

  1. 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

  1. 모든 오라클 클러스터웨어가 기동중인지 확인.

  2. 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

  1. root유저를 통해 모든 노드의 오라클 클러스터웨어를 내리고 비활성화하시기 바랍니다.

# crsctl stop crs

# crsctl disable crs

  1. 요구된 사항으로 OS레벨에서 네트워크 구성 변경을 수행하고, 그 변경이후 모든 노드에서 새로운 인터페이스가 가용한지 확인하시기 바랍니다.

$ ifconfig -a

$ ping <private hostname>

  1. 오라클 클러스터웨를 활성화하고 root유저로서 모든 노드에서 오라클 클러스터웨어를 재기동하시기 바랍니다.

# crsctl enable crs

# crsctl start crs

  1. 필요하다면 기존 인터페이스를 제거하시기 바랍니다.

$ oifcfg delif -global <if_name>[/<subnet>]

eg:

$ oifcfg delif -global eth0/192.168.0.0

  1. 주의사항

    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 가 잘못된 서브넷 주소나 인터페이스명을 가지고 수행되었다면 동일한 문제가 일어날 것입니다.

  1. 클러스터에 어느 한 노드라도 다운되었다면 oifcfg 명령은 다음의 에러와 함께 실패할 것입니다.

$ oifcfg setif -global bond0/192.168.0.0:cluster_interconnect

PRIF-26: Error in update the profiles in the cluster

회피방법: 기동되어 있지않은 노드의 오라클 클러스터웨어를 기동하시기 바랍니다. 오라클 클러스터웨어가 모든 클러스터 노드에서 기동중인지 확인하시기 바랍니다.

만약 어떤 OS 문제로 그 노드가 다운되었다면 사설 네트워크 변경을 수행하기전에 클러스터로부터 그 노드를 제거하시기 바랍니다.

  1. 만약 그리드 인프라스트럭처 소유자가 아닌 유저가 위의 명령을 수행하면, 다음과 같은 에러가 발생하며 실패할 것입니다.

$ oifcfg setif -global bond0/192.168.0.0:cluster_interconnect

PRIF-26: Error in update the profiles in the cluster

회피방법: 그러한 명령을 수행하기위해 그리드 인프라스트럭처 소유자로 로그인하였는지 확인하시기 바랍니다.

  1. 11.2.0.2 부터, 새로운 인터페이스를 추가하지 않고 마지막 사설 인터페이스(cluster_interconnect)를 지우려고 시도한다면 다음의 에러가 발생.

PRIF-31: Failed to delete the specified network interface because it is the last private interface

회피방법: 기존 사설 인터페이스를 지우기전에 우선 새로운 사설 인터페이스를 추가하시기 바랍니다.

  1. 오라클 클러스터웨어가 노드에서 다운시, 다음의 에러 발생

$ oifcfg getif

PRIF-10: failed to initialize the cluster registry

회피방법: 그 노드에서 오라클 클러스터웨어를 기동하시기 바랍니다

'ORACLE > RAC_설치' 카테고리의 다른 글

RAC - Archive log mode 로 변경하기  (0) 2020.07.07
RAC - VMware 환경, RAC 모드일때 디스크 추가하기  (0) 2020.07.07
RAC 3 - RAC 구성 완료 후 테스트 하기  (0) 2020.07.07
RAC 2 - RAC 구성하기 (패치 및 에러조치)  (0) 2020.07.07
RAC 1 - 설치 전 이론 (RAC설치순서, Network구성, CTF/TAF 차이점)  (0) 2020.07.07
Posted by Max-Jang
,

CRS 설명

ORACLE/공부하기 2019. 7. 4. 15:39
반응형

Clusters 개념

클러스터란, 대칭형 다중 처리 방식(symmetric multiprocessing 또는 SMP)의 대안으로,

상호 연결된 하나 이상의 컴퓨터가 그룹을 이루어 작업을 함께 처리하는 방식입니다.

시스템을 이용하는 사용자 입장에서는 하나의 시스템을 사용하는 것과 같은 효과를 나타냅니다.

즉 최종 사용자 입장에서는 사용중인 시스템이 물리적으로 한대의 노드로 구성되어 있는지,

또는 여러 대의 노드가 클러스터를 구성하여 서비스를 제공하는지 고려하지 않아도 되는 것입니다

 

 

Cluster 의 Components

클러스터는 두개의 주요 요소로 구성됩니다.

클러스터 노드는 작업을 처리하는데 필요한 자원을 제공해 주는 시스템입니다.

즉, application이 작업할 수 있는 하드웨어를 말합니다.

이 하나 이상의 노드를 논리적으로 하나의 시스템으로 묶어주는 software가 필요하게 됩니다.

클러스터 매니저가 이 역할을 해 주는 시스템 소프트웨어입니다.

일반적으로, 클러스터를 구성하는 노드 관리, 클러스터 내 노드 추가, 삭제 , 자원 모니터링, Failover 처리 기능을 갖습니다.

Cluster내에서 작동하는 software는 cluster system에서 작동할 수 있도록 설계되어야 합니다.

즉, stand alone node에서 작동하도록 설계된 application은 cluster system에서 작동하지는 않습니다.

 

 

 

 

The Oracle Cluster

OCR과 Voting disk도 또한 oracle cluster의 콤포넌트입니다.

스토리지에서 제일 하단의ocr, voting disk부터 controlfile, database files 의 순서로

oracle은 file을 check하면서 read하기 시작합니다.

이 때 storage는 cluster 내의 모든 node에서 동시에 access가 가능해야 합니다.

여기서 CRS가 전체 node에 걸쳐 작동하고 있는 것을 알 수 있습니다.

ASM으로 구성된 경우라면 ASM instance가 필요하게 되고,

이 모든 Layer들이 정상적으로start 된 이후 oracle database instance가 작동하게 됩니다.

Public network 망에서 interface 는 일반 public IP 를 사용하지 않고, VIP를 사용하게 됩니다.

이것은 IP failover를 위해 ORACLE CRS가 제공하는 것 입니다.

 

랜카드 여러개를

랜카드 2개를 묶어서 쓰는 걸 Bonding 이라고 한다.

 

 

 

Architecture

오라클 클러스터 아키텍처를 이해하는데 필요한 중요한 개념들이 있습니다.

서비스, Node Application, Cluster Ready Services, Cluster Resources 등 입니다.

먼저 Service는 클러스터 내 작업을 배분해 주는 수단을 제공해줍니다.

서비스는 하나 또는 그 이상의 인스턴스에서 제공되는데, 데이터베이스 명이 기본적으로 하나의 서비스입니다.

Oracle 10g 이전 버전에서도 이 Service라는 개념이 있었지만,

10g 에서는 더 확대된 개념으로 하나의 instance에서 여러 Service를 제공할 수 있고,

하나의 서비스가 여러 instance에 걸쳐 제공될 수도 있습니다.

Node Application은 Oracle Listener, Global Services Daemon (GSD),

Oracle Enterprise Manager Agent (OEM Agent), Virtual IP Address (VIP) 등이 포함됩니다.

Cluster Ready Service는 logical하게 node를 묶어주는 Cluster Manager이고,

Cluster Resource는 Oracle Cluster Service에 의해 관리되는 Resource들이며 데이터베이스 인스턴스,

서비스, Listener 및 VIP 등이 포함됩니다.

Resource의 속성은 failover 특성 및, 재구동방식, 의존관계 등을 지정하기 위해 정의할 수 있습니다.

 

 

IP 용어들 잘 알아 두어야 합니다.

실제 서비스는 vip

public 은 매니지먼트

 

RAC 를 직접 건드릴 일은 거의 없습니다. 정말 중요한 곳 아니면 RAC 를 쓰지 않아요.

 

신규는 11g, 기본은 raw device 인데 asm 을 요구하기도 한다.

asm 설치는 asm bug로 인한 책임을 묻지 않겠다는 도장을 받고 설치하여야 합니다.

 

 

 

 

Cluster Applications Architecture

이 그림은 앞에서 설명한 몇가지 용어를 그림으로 표시한 것입니다.

3개의 node를 사용하고 있고, 각 node들은 기본적으로 Cluster Ready Services에 의해 하나의 system 으로 clustering 되어 있습니다.

각 Node application 들이 각각의 node 에서 작동하고 있고, Database 를 위한 Instance가 각 node에 올라와 있습니다.

Service 를보면, 이 Database 는 AP, HR, CRM 3개의 Service 가 있습니다.

회색으로 표시된 것은 failover 시 작동할 Service 입니다.

CRM 을 예를 들면 평시에는 Node1 에서 Service 를 제공하고,

만약 Node1 에 이상이 있을 경우 Node2 에서 CRM service 를 제공하게 됩니다.

이 후 Fail 된 Node 가 복구되면 다시 Service 는 ‘preferred’ Node로 돌아올 수 있습니다.

단, 이 경우는 user가 manual 하게 옮겨주어야 합니다.

 

 

 

 

 

앞의 그림은Service의 관점에서 그린 그림이고,

이 그림은 CRS와 Oracle Instance, Application의 관계를 보여줍니다.

Oracle Database Instance가 각 node에 하나씩 작동하고 있고, 이 두 개의 Instance가

Service A, B, C 3개의 Service를 제공합니다.

이 그림에서는 두개의 Instance가 모두 작동하고 있지만,

어떤 경우는 다른 하나의 Instance 는 Stand by 용 혹은 Failover 용으로 대기 중일 수도 있습니다.

그렇다고 하더라도 Node Application, 즉, Listener, EM, GSD 등은 여전히 각 node별로 작동하고 있습니다.

Client Application은 기본적으로 VIP를 통하여 접속이 되고, Oracle Listener 도 이 VIP를 listen하게 됩니다.

EM, DBCA, SRVCTL, NETCA 등은 HA적 관점에서 CRS와 통신하게 되며,

새로운 Resource 들을 생성할 때 CRS와 통신하여 OCR에 정보를 기록하게 합니다.

이 OCR과 voting Disk는 OS storage에 위치하게 됩니다.

 

 

 

CRS (Cluster Ready Services)

CRS는 크게 3개의 콤포넌트로 구성이 됩니다.

CSS, EVM, CRS. 이렇게 3개가 존재하며, 마지막의 CRS는 Oracle Cluster를 부를때 사용하는

CRS 와는 구분이 되는 Process 명으로 CRS의 resource를 관리합니다.

 

 

 

CRS Structure

이 그림은 앞의 그림들 좀더 확장한 그림입니다.

CRS는 Unix의 init에 의해 기동되고, windows에서는 service controller에 의해 기동됩니다.

여기서 하얀box내의 사각형들은 모두CRS의 component 들입니다.

Oprocd 는 oracle10g에서 사용하는 io fencing기능을 제공합니다.

Evmd 는cluster 내의 event 발생 시 이 event 를 전파하는 기능을 합니다.

이 그림에 표시되어 있지는 않지만, ‘crs_stat –t’ 명령을 수행하면 gsd(group service daemon) 가 나타나는 것을 보실 수 있습니다.

Gsd 는 10g version 에서는 사용되지 않지만, 9i version 의 srvctl 의 interface 가 gsd 로 되어있기 때문에 10g 에서도 아직 남아 있습니다.

실제로 oracle 9i 때의 gsd 의 역할은 이제 모두 crsd 가 담당하게 되었고, 9i version 을 지원하기 위해 존재하는 것 이외의 의미는 없습니다.

Ocssd 는 heartbeat 을 다른 node 에 보내어 health check를 하는 기능을 담당하며,

상대 node 의 이상 감지 시 cluster reconfiguration 도 css 가 담당합니다.

Crsd 는 cluster resource manager로써 CRS가 사용하는 resource를 start/stop/disable/configure 하는 역할을 합니다.

Process로서 존재하지는 않지만, OCR과 Voting disk도 CRS의 구성 Component 입니다.

OCR 은 cluster 와 cluster 내의 resource 의 정보가 저장되어있으며, Voting Disk 는 각 node 의 status 를 확인하기 위해 사용됩니다.

 

 

 

OPROCD (Processor Monitor Daemon)

Oprocd는processor monitor로써init에 의해 기동됩니다.

앞에서 말한 것처럼 oprocd는 Oralce Cluster 가 제공하는 IO fencing solution 입니다.

Linux 에서는 hangcheck timer 가 이 oprocd 의 기능을 제공하기 때문에 oprocd 는 작동하지 않습니다.

이외의 platform중에서 vendor clusterware가 설치되어 있다면, 마찬가지로 oprocd는 기동 되지 않습니다.

Linux를 제외한 flatform에서 Vendor clusterware가 설치되지 않은 경우만 oprocd가 기동 되어 processor를 monitoring하게 됩니다.

Monitoring하는 방법은 특정시간동안 sleep후 깨어나서 예정된 시간보다 늦게 깨어나게 되면,

system hang으로 간주하여 processor를 reset하고 machine을 reboot하게 됩니다.

 

 

 

EVMD (Event Forwarding Daemon)

EVMD는 Event forwarding Daemon입니다. 이 process도 init에 의해 기동됩니다.

Evmd는 evmlogger를 fork하는데 이 process는 log file에 event를 기록하는 역할을 합니다.

Oralce 10g에서는 oracle instance를 monitoring하는 racgimon이라는 process가 있는데,

이 process로부터 forwarding되는 message를 처리하기위해 evmlogger는 필요에 따라 racgevt라는 process를 생성합니다.

Racgevt는 message를 받을 때 마다 callout directory를 확인하여 필요 시 callout를 실행합니다.

Callout이란 특정 event에 따라 행해져야 하는 특정 action을 정한 script입니다.

Callout directory는 $ORA_CRS_HOME/racg/usrco입니다.

이 directory에 user가 특정 action을 미리 define하여 callout script를 생성할 수도 있습니다.

Evmd는 oracle user로 기동되며 fail발생시 자동적으로 재기동 됩니다.

 

 

 

EVM Architecture

EVM Daemon은 다시 두 개의 component로 구분할 수 있습니다.

하나는 local EVM(LEVM)이고 하나는 cluster EVM(CEVM)입니다.

CEVM은 clusters내의 evm daemon에 대한 cluster membership정보를 유지관리 합니다.

즉, 상태 node의 CEVM의 TCP connection정보를 유지하고, 상대 node의 evm에게 event를 전달하는 역할을 합니다.

LEVM은 clusterwide하게 전달될 event가 생성되면, Cluster event Queue에 event를 넣어서 CEVM이 clusterwide하게 event를 전달하도록 합니다.

CEVM이 다른 node로부터 event를 받는 경우, 마찬가지로 clustger event Queue에 event를 넣어 LEVM으로 전달합니다.

Cluster내의 어느 node가 새로 cluster에 join하는 경우, CEVM은 상대 node의 CEVM으로부터 이 event를 전달받고,

inbound cluster event queue에 이 event를 넣습니다.

그리고 CRSD에게 이 event를 넘겨줘서 CRSD가 node join을 알게 합니다.

LEVM은 queue에 있는 event를 받고 이 내용을 기록합니다.

이와 같이 CSS, CRSD가 발행하는 event들은 EVM을 통하여 clusterwide하게 전파됩니다

 

 

CSSD (Cluster Synchronization Service)

CSSD는 cluster synchronization service daemon의 약자입니다.

이 process는 다음 세가지의 service를 제공합니다.

Group service, lock service, node information service입니다.

Node information service는 어떤 node가 cluster에 join했는지 혹은 cluster를 떠났는지 monitoring하는 기능입니다.

Cssd는 process fail시 OS reboot이 됩니다.

 

CSS의 역할인 그룹서비스는 9i version에서의 skgxn의 역할이 확장된 것입니다.

Oracle database instance가 join하는 것을 처리하고 Cluster내의 이미 존재하는 member들에게

새로운 member가 join되거나 leave되는 것을 알려줍니다.

Lock service는 crsd가 사용하는 lock을 css의 lock service가 제공합니다.

Node Information Services는 node의 정보를 유지 관리하는 service입니다.

여기에는 cluster configuration정보, node명, node number등이 있으며 node추가나 삭제 시 갱신됩니다

 

다른 crs process들처럼 cssd도 multi thread로 되어있으며, 크게 두 부분으로 나눌 수 있습니다.

Node monitor는 nm이라고 불리우며, Node자체가 살아있는지 여부를 check한는 역할을 합니다.

이 기능은 heartbeat을 이용하게 됩니다.

상대 node의 css endpoint는 ocr에 기록되어있으며, 이 end point로 매초마다 interconnect를 통해 network heartbeat을 보냅니다.

일정 시간동안, 즉 miscount동안 heartbeat을 받지 못하면 css는 해당 node를 죽은 것으로 간주합니다.

이와는 별도로 voing disk을 매초마다 read하게 됩니다.

Network heartbeat이 miscount동안 오지 못하여 일부 node가 죽은 것으로 판단되면,

이 voting disk를 확인하여 어느 node들을 cluster에서 제거해야 하는지 voting을 하게 되는데 이 단계가 reconfiguration입니다.

Nm이 어느 node가 죽었는지 판단하여 nm reconfiguration을 한 이후에, gm이 해당 node의 crs,

evm, css등이 사용했던 resource들을 제거하고 cluster group에서 삭제하는 gm reconfiguration이 진행됩니다.

Reconfiguration은 node join시에도 발생합니다.

 

 

 

CRSD

다음은 crsd에 대해 알아보겠습니다.

CRSD는 cluster내에서 사용하는 resource를 monitoring하고 관리하는 역할을 합니다.

CRSD는 shell script인 racgwrap을 call하게 되고, 이 racgwrap은 racgmain을 call하여 특정

resource를 start/stop/check할 수 있습니다.

이 resource들을 관리하기 위해 해당 resource의 정보를 담아야 하는 공간이 필요하며, 이것이 ocr입니다.

CRSD는 이 OCR내의 정보를 직접 read/write하여 data를 유지 관리하는 역할을 합니다.

Read/write시 disk io를 최소화하기위해 OCR data를 memory에 caching하는 기능도 제공합니다.

CRSD는 root user로 기동하고, process fail이 발생하면 자동적으로 재기동 됩니다.

 

 

 

CRS Resources

Oracle entity는 database, instance, service나 listener등이 있습니다.

이런 oracle entity의 생성은 dbca, netca, srvctl등의 oracle tool들에 의해 생성하도록 요청되고,

CRSD가 실질적으로 OCR을 update하여 생성하게 됩니다.

이런 crs resource들간에는 dependency를 가질 수 있습니다.

예를 들어 database instance나 listener는 vip가 있어야만 생성될 수 있고, start될 수 있습니다.

이 경우 dependency가 성립됩니다.

 

 

 

 

Oracle crs가 crs resource를 관리하기위해 내부적으로 관리하는 명령어들은 다음과 같습니다.

이 명령어들이 담당하는 역할은 하나의 resource의 lifecycle과 동일합니다.

Crs_profile은 resource의 각종 attribute를 정의합니다.

일단 attribute가 정의되면, crs_register에 의해 resource로서 추가되고, ocr에 쓰여지게 됩니다.

Crs_start는 resource를 start할때 사용됩니다.

Crs_stat는 해당 resource의 정보를 조회할때 사용합니다.

Crs_relocate는 해당 resource를 move할때 사용합니다.

Crs-stop은 resource를 stop하며, crs_unregister를 이용하여 resource를 삭제할 수 있습니다.

Resource를 관리한다는 것은 위의 7가지 상태를 말하며, 이 7개의 단계는 resource의 life cycle이 됩니다.

 

 

 

CRS application resources

일단 resource가 startup 되면 crsd 는 resource 마다 하나씩 thread 를 생성하여 이 resource를

check_interval을 주기로 정상작동 여부를 check하게 됩니다.

Resource가 비정상 종료되면(예를 들어 instance crash) resource의 state는 offline으로 변경되고,

restart_attemps에 해당되는 숫자만큼 restart를 자동적으로 시도하게 됩니다. 이 숫자를 넘어서게 되면

더 이상 restart를 시도하지 않습니다.

Crs resource의 현재 상태는 crs_stat을 통하여 알 수 있습니다.

이 명령 결과로 조회되는 state는 current상태를 표시하고, target은 crs가 유지해야 하는 resource의 상태입니다.

즉, target이 대부분 online으로 되어있으므로 crs는 해당 resource의 current state를 online으로 유지하려고 합니다.

 

 

 

CRS Action

Crsd가 resource를 관리하기위해 node간에 message를 주고받는 예를 한번 보겠습니다.

Node는 2개이고, instnace start상황이라고 가정을 하겠습니다.

1. Node1의 client에서 api를 통해‘crs_start oracle’요청이 들어옵니다.

2. local CRSD는 이 요청을 받고, 이를 처리하기위해 새로운 thread를 생성합니다.

요청이 타당한지 검증을 하고, 어느 node에서 이 명령이 수행되어야 하는지 판단합니다.

여기서는 node2에서 작동하는 경우를 예로 들겠습니다.

3. Request=start resource=oracle로 key/value형태로 message를 생성합니다.

4. Node2의 crsd와 통신할 수 있는 port를 확인합니다.

5. Node2의 port가 open되고, socket이 open됩니다. Node2의 crsd는 이 요청을 처리하기 위한 thread를 생성합니다.

6. 3번에서 생성한 message를 node2로 보냅니다.

7. Node2의 crsd는 message를 decode하고, 이 message가 타당한지 여부를 확인하기 위해 ocr을 확인합니다.

특히, timeout value인 script_timeout의 값을 확인합니다.

8. Node2는 script_timeout의 값을 node1에 보내서 응답을 이 시간동안 기다리도록 합니다.

9. Node1은 timer를 시작하여 이 script_timeout동안 응답이 오기를 기다립니다.

10. Node2는 resource를 start합니다.

11. Node2는 node1으로 action program이 수행되었음을 socker을 통해서 보냅니다.

12. Node2에서 socket을 close합니다.

13. Node1에서 resource의 status를 변경함으로써 모든 작업이 완료됩니다.

 

 

 

OCR (Oracle Cluster Registry)

OCR은 oracle cluster registry의 약자입니다. CRS에서 사용하는 data를 저장하는 repository 역할을 합니다.

Data의 구조는 window의 registry처럼 tree구조로 되어있고, keyvalue의 형태로 data가 저장되어있습니다.

이 OCR data는 DBCA, NetCA, SRVCTL등의 oracle tool과 CRS가 사용합니다.

Srvctl에서 resource를 생성하는 예를 보면, srvctl create database –d mydatabase –o myOracleHome 의 형태입니다.

이 명령으로 OCR에는 mydatabase라는 database가 추가됩니다.

그러나 실제로 database가 생성 되는 것은 아닙니다.

Database의 생성은‘create database’문장으로 생성을 해야 합니다.

Dbca를 이용하면 database를 실제로 생성한 후 OCR에 등록하는 역할까지 합니다.

OCR은 shared device에 생성되어야 하며, raw device나 cluster file system도 가능합니다.

OCR의 위치는 일반적으로 /var/opt/oracle/srvConfig.loc file에 지정되어있거나, 환경 변수인 SRV_CONFIG로 지정이 가능합니다.

 

 

OCR Cache Architecture

Srvctl등의 oracle tool이 OCR정보를 access해야되는 경우 local node의 crsd가 관리하는 local ocr cache를 읽습니다.

Ocr cache는 각 node의 crs에 의해 관리되지만 그중의 한 crs는 cluster master cache로서 역할을 합니다.

이 master cache만이 OCR disk에 disk io를 발생시키게 되고 read한 data를 다른 node의 ocr cache로 전파합니다.

Resouce start/add등 OCR disk에 write해야 되는 상황에도 master cache를 담당하는 crsd가 write를 하고,

이 사실을 다른 node의 crsd에 전파합니다.

OCR write가 발생하면, 기존에 cache되어있던 해당 data는 invalid상태로 변경되어 master ocr cache로부터 다시 전달 받아야 합니다.

 

 

OCR Record 구조

각 ocr record는 key, value, permission의 3개의 field를 갖습니다.

여기 예에서 보면, 제일 위의 Databases.reld.instance.reld1은 key입니다.

여기서는 database instance를 예를 들었습니다.

그 밑에 oratext항목에 나타나는 reld1은 key에 대한 value입니다.

여기서는 instance명인 reld1이 value입니다.

세번째 항목은 security입니다.

Unix에서 permission을 관리하는 방식처럼 user, group, other group의 세 부분으로 나뉘고,

username과 primary_group_name에 이 user의 user명과 그룹 명이 표시됩니다.

여기 예에서는 oraha user에 other group으로 표시되었지만, 일반적인 경우에 oracle user에 dba group이 표시됩니다.

 

 

Voting disk

Voting disk는 split brain상태에서 node의 상태를 판단하기위한 second heart beat의 역할을 합니다.

Nm은 이 상태에서 어느 sub cluster node를 evict할지 결정하기 위해 voting disk를 사용합니다.

Eviction이 결정되면 해당 node가 eviction되도록 eviction message를 voting disk에 적어줍니다.

Voting disk는 dd로 backup을 받아 disk failure시 복구할 수 있습니다.

10gR1에서는 multiple voting disk를 지원하지 않으므로 os level의 mirroring 기능을 이용해야 하지만,

10gR2에서 multiple voting disk기능을 지원합니다.

참고로 OCR backup은 $ORA_CRS_HOME/cdata// direcotry에 자동적으로 backup이 됩니다.

Backup은 매 4시간마다 1개, 매일 1개, 매주 1개의 갯수로 유지됩니다.

Oraconfig –showbackup 명령으로 가용한 backup을 알수 있으며,

oraconfig–restore filename 명령으로 restore할 수 있습니다. Restore시는 crs를 down후 restore해야 합니다.

자세한 절차는 metalink에서 note. 268937.1를 확인하시기바랍니다.

 

 

Installation

CRS는 $ORACLE_HOME과는 별도의 경로에 $ORA_CRS_HOME이라는 환경 변수를 설정 후, 이 directory에 install합니다.

Install과정의 마지막 부분에 root.sh shell을 실행하도록 message가 나타납니다.

이 root.sh는 inittab file에 crs process들이 booting시 startup되도록 inittab에 관련 정보를 기록합니다.

이 inittab들 보면 crs는 root권한으로 evm은 oracle권한으로 기동되며, process fail시 자동으로 재기동됩니다.

Css는 oracle권한으로 기동되며, fatal mode로 기동되므로 process fail시 os reboot이 됩니다.

Booting시 실행되는 script는 init.crsd, init.cssd, init.evmd 이 세개가 실행되어 crs가 기동되게 됩니다.

이 process들은 $ORA_CRS_HOME//log directory에 각각의 log를 관리합니다.

따라서 각 process에 이상 발생시 우선적으로 이 log directory를 참조 하시기 바랍니다.

Install시 root.sh가 모든 node에서 실행되어야 합니다. 만약 정상적으로 실행되지 않은 경우라면, 문제발생시 원인을 찾기 힘들게 됩니다.

 

 

 

Starting CRS

CRS 가 start 되는 과정을 다시 한번 review 해보겠습니다.

Init.crsd, init.evmd, init.cssd 는 init.crs 에 의해 call 이 되어, manual 하게 start 될 수 있습니다.

‘Init.crs start’ 명령이 발생하면, 먼저 cssd 를 start 하여 cluster 를 형성하게 되고, 이후 evm 이 start 됩니다.

마지막으로 crsd 가 start 되어 crs 가 모두 기동됩니다.

Css 의 주요 thread 는 voting disk polling thread 와 network heartbeat thread입니다.

Disk polling thread 는 매 초마다 voting disk 를 read 합니다.

Heartbeat thread 도 또한 매초마다 작업합니다.

Css 는 이외에 timer thread, 기타 관리를 위한 thread 등이 있습니다.

Css 는 startup 하면서 OCR 과 voting disk 를 읽어 cluster node 들을 확인합니다.

이 단계에서 OCR이나 Voting disk 를 read 할 수 없는 상황이 되면 start 되지 못합니다.

이후 evm 이 start 됩니다.

CRSD 가 start 되면서 OCR data 를 cache 하기 위해 OCR cache thread 를 기동합니다.

OCR cache 는 node 간에 master-slave 관계를 갖게 되는데, 가장 먼저 booting 된 node 가 master 가 되고,

OCR disk 에 대한 write 는 이 master 에 의해서만 이루어집니다.

이후 변경된 data 의 전파도 이 master crs 가 하게 됩니다.

Crsd 는 ocr 을 읽어서 모든 resource 들을 파악하고, 이들간의 dependency 도 확인합니다.

이후 racgwrap 을 call 하여 각각의 resource 들을 start합니다.

Racgwrap 은 racgmail 을 call 하면서 argument 로써 resource name 과 start 를 넘겨줍니다.

각각의 resource 의 health check 를 하기 위해 매 초마다 sga의 특정 영역을 polling 합니다.

이 단계를 마치게 되면 모든 crs daemon들과 nodeapps, database, instance등의 resource가 모든 node에서 기동된 상태가 됩니다.

 

 

 

 

Diagnostics

다음은 문제 초기단계에서 볼 수 있는 trace file들을 확인해보겠습니다.

Crs, css, evm은 Oracle 10g R1 의 경우는 $ORA_CRS_HOME directory 밑에 process 명 아래에 log directory에 해당 log가 있습니다.

우선적으로 봐야 할 log file 은 이 log file 들입니다.

Css 의 경우는 interconnect 의 networking 이 안 되는 경우도 있으므로, css 의 network trace file인

$ORA_CRS_HOME/css/log/ocsns*.log 가 필요할 수도 있습니다.

그리고 network configuration 을 파악하기 위해 hosts, netstat 결과도 확인이 필요합니다.

 

Emvd의 log는 각각 다음과 같습니다.

EVM daemon log 는 $ORA_CRS_HOME/evm/init/.log

EVM event logger log 는 $ORA_CRS_HOME/evm/log/_evmdaemon.log

Oprocd 가 있는 경우는 $ORA_CRS_HOME/log에oprocd log file 이 있습니다.

Ocr의 이상 시는 먼저 ocr 의 위치를 지정하고 있는 ocr.loc file을 확인하세요.

이 file은 linux 의 경우는 /etc/oracle, 기타 unix 는 /var/opt/oracle 에 위치합니다.

Ocr 내부의 data를 확인하기 위해 ocrdump 명령을 사용할 수 있습니다.

별도의 이름을 주지 않은 경우 OCRDUMP 라는 file명으로 생성됩니다.

공통적으로 OS system log를 확인하여, network error나 io error, 혹은 다른 message가 있는지 확인이 필요합니다.

CRS의 경우도 여러 형태의 문제가 발생할 수 있기 때문에 문제 유형별로 trace를 발생시킬 수 있습니다.

이 내용에 대해서는 iSeminar에서 언급하지는 않겠습니다.

위의 기본적인log file들과 함께 Oracle Suppport Engineer와 함께 진행하시기 바랍니다.

'ORACLE > 공부하기' 카테고리의 다른 글

[성능튜닝] ASH(Active Session History)  (0) 2019.08.31
undo tablespace full 관련  (0) 2019.08.24
OCR & Voting Disk  (0) 2019.07.03
ASM 모니터링  (0) 2019.07.02
OCR 관리  (0) 2019.07.02
Posted by Max-Jang
,

OCR & Voting Disk

ORACLE/공부하기 2019. 7. 3. 16:20
반응형

 OCR

1. oracle clusterware 가 control 하는 컴포넌트에 대한 저장/관리 (RAC DB , Service , listener, VIP )

2. 설정 정보를 key-value 쌍으로 tree 구조로 관리한다.

3. crs 데몬이 죽은거 살릴떄 ocr 정보를 이용

 

 Voting Disk

1. 어느 node 가 cluster의 멤버인지를 determine , cluster 의 무결성 보장

2. CSS 데몬이 노드간에 동기화 작업을 하는데 voting disk 정보를 이용하고 node 제거 시

    interconnect 차후로 voting disk 에 알린다.

3. 메인 목적은 interconnect fail 시를 대비하기 위함

4. 어느 노드가 죽었는지에 대한 정보를 결정

5. Voting Disk가 없으면 네트웍이 문젠지 노드가 죽었는지 알 수 가 없다.

 

 

ASM 기반의 OCR , VOTING DISK 관리

 

Each node must be able to access a majority of vote disks otherwise it will be evicted from the cluster.

Voting disk can be stored on an ASM disk.

   

    not regular ASM files.

    

     Clusterware knows location in case ASM is unavailable.

 

The number of voting disks is determined by ASM disk group redundancy.

 

       1 for external redundancy disk group

       3 for normal redundancy disk group

       5 for high redundancy disk group

 

A separate failure group is required for each voting disk.

 

Voting disks are managed using crsctl utility.

 

ASM managed voting disks are automatically backed up into the OCR.

 

        Any configuration change in the cluster triggers a new backup of the voting disks.

       

        A failed voting disks is restored by ASM automatically.

 

 

The OCR is backed up automatically every 4 hours.

 

      Manual backups can also be taken as required.

    

      OCR should be protected by disk group redundancy or mirroring in the disk storage system.

 

ONLY IF all voting disks are corrupted or filed, AND the OCR is also corrupted or unavaliable,

THEN manual intervention is required.

 

Voting disk 는 홀수로 구성 한다. 50% 이상이 유실되면 오라클은 데이터 보호를 위해 모두 shutdown 된다.

하지만 ASM 내에 voting disk를 꺠기란 쉽지 않다.

 

 

'ORACLE > 공부하기' 카테고리의 다른 글

undo tablespace full 관련  (0) 2019.08.24
CRS 설명  (0) 2019.07.04
ASM 모니터링  (0) 2019.07.02
OCR 관리  (0) 2019.07.02
OCR 과 Vote disk  (0) 2019.07.02
Posted by Max-Jang
,

ASM 모니터링

ORACLE/공부하기 2019. 7. 2. 16:32
반응형
WIEW 이름                         설 명
   
   
   
   
   
   
   

1. ASM 관리하기

 

WIEW 이름                        설 명

v$ASM_DISKGROUP             디스크 그룹에 관련된 정보

v$ASM_DISK                       디스크에 대한 정보

v$ASM_FILE                        ASM내부에 생성 된 파일에 대한 정보

v$ASM_TEMPLATE                ASM내 모든 디스크 그룹에 설정된 템플릿 정보

v$ASM_ALIAS                      ASM디스크 그룹의 alias정보

v$ASM_OPERATION              ASM Instance 상에서 실행되는 작업들 현황

v$ASM_CLIENT                     ASM을 사용하는 DB Instance 현황

 

 

1) ASM disk 내용 확인

SYS/+ASM> set line 200
SYS/+ASM> col disk_group for a10
SYS/+ASM> col label for a10
SYS/+ASM> col state for a10
SYS/+ASM> select a.name as disk_group, d.name "Label", a.state
2 from v$asm_disk d, v$asm_diskgroup a
3 where d.group_number=a.group_number
4 order by 2;

 

DISK_GROUP Label STATE
---------- ---------- ----------
DATA ASM1 MOUNTED
FRA FRA1 MOUNTED

 

2) ASM 내부 살펴보기

2.1 ASM인스턴스에 현재 연결되어 있는 Disk group확인

SYS/+ASM> set line 200
SYS/+ASM> col group_number for 99
SYS/+ASM> col name for a10
SYS/+ASM> col type for a10
SYS/+ASM> col state for a10
SYS/+ASM> select group_number, name, type, state from v$asm_diskgroup;

 

GROUP_NUMBER NAME TYPE STATE
------------ ---------- ---------- ----------
1 DATA EXTERN MOUNTED
2 FRA EXTERN MOUNTED


2.2 디스크 그룹별 세부 상세 정보 보기

SYS/+ASM> col group_number for 999
SYS/+ASM> col disk_number for 999
SYS/+ASM> col name for a10
SYS/+ASM> col mount_status for a10
SYS/+ASM> col path for a15
SYS/+ASM> select group_number, disk_number, name, mount_status, path, total_mb
2 from v$asm_disk;

 

GROUP_NUMBER DISK_NUMBER NAME MOUNT_STAT PATH TOTAL_MB
------------ ----------- ---------- ---------- --------------- ----------
1 0 ASM1 CACHED ORCL:ASM1 7680
2 0 FRA1 CACHED ORCL:FRA1 2460

2.3 디스크 그룹별 파일 내역

SYS/+ASM> set line 200
SYS/+ASM> set pagesize 50
SYS/+ASM> col group_number for 99
SYS/+ASM> col file_name for 999
SYS/+ASM> col type for a15
SYS/+ASM> select group_number, file_number, round((bytes/1024/1024),1) MB, redundancy, type
2 from v$asm_file;

GROUP_NUMBER FILE_NUMBER MB REDUNDANCY TYPE
------------ ----------- ---------- ------------ ---------------
1 256 6.7 UNPROT CONTROLFILE
1 257 50 UNPROT ONLINELOG
1 258 50 UNPROT ONLINELOG
1 259 50 UNPROT ONLINELOG
1 260 300 UNPROT DATAFILE
1 261 200 UNPROT DATAFILE
1 262 120 UNPROT DATAFILE
1 263 20 UNPROT TEMPFILE
1 264 5 UNPROT DATAFILE
2 256 6.7 UNPROT CONTROLFILE
2 257 50 UNPROT ONLINELOG
2 258 50 UNPROT ONLINELOG
2 259 50 UNPROT ONLINELOG
2 260 0 UNPROT PARAMETERFILE

14 rows selected.

※ redundancy의 의미 - 만약의 경우를 위해 미러링하는 정도를 의미.

ASM 인스턴스 생성시 디스크 그룹을 선택할 때 생성하는 것으로 3가지 타입 중 하나를 선택할 수 있음.

 

Disk Group Type              Supported Mirroring Levels            Default Mirroring Level

Normal redundancy          2-way 3-way Unprotected(none)      2-way

High redundancy              3-way                                        3-way

External redundancy          Unprotected(none)                       Unprotected

'ORACLE > 공부하기' 카테고리의 다른 글

CRS 설명  (0) 2019.07.04
OCR & Voting Disk  (0) 2019.07.03
OCR 관리  (0) 2019.07.02
OCR 과 Vote disk  (0) 2019.07.02
[RAC] OCR(Oracle Configuration Repository), VOTING  (0) 2019.07.02
Posted by Max-Jang
,

OCR 관리

ORACLE/공부하기 2019. 7. 2. 16:19
반응형

1. OCR file이란?

- Oracle Cluster Repository약자로 cluster의 정보를 담고 있고 윈도우로 말하면 레지스트리의 역할을 하며 RAC상의 모든 노드들에 대한 정보와 모든 자원들에 대한 정보가 저장 되어 있습니다. OCR이 장애가 발생하면 RAC전체가 중단되므로 관리 철저를 요망!!!!

 

2. 특징

- OCR 디스크의 소유자는 기본적으로 root이지만 경우에 따라서 oracle사용자가 될수 있음

- 자동 백업(4시간 마다, 매일마다, 매주마다)

 

3. 상태 확인 방법

$ORACLE_CRS_HOME/bin/ocecheck 명령어 사용

 

4. 자동 백업 경로와 내역확인

$ ocrconfig -showbackup

 

5. OCR file복원하기(자동백업, 수동백업파일)

1) 자동 백업

step 1. 현재 노드의 오라클 클러스터웨어를 stop

# crsctl stop crs

 

step 2. 백업 리스트 확인 후 파일 복원

# ocrconfig -showbackup

 

파일 복원

# ocrconfig -resotre <파일 이름>

 

복원 확인

# cluvfy comp ocr -n all

 

현재 노드의 오라클 클러스터 다시 시작

# crsctl start crs

 

2) 수동 백업

step 1. 전체 노드의 오라클 클러스터웨어 stop

# crsctl stop crs

 

step 2. 수동으로 OCR file 해당 경로에 백업

# ocrconfig -export

 

step 3. 전체 노드의 오라클 클러스터웨어 start

# crsctl start crs

 

3) OCR file 리커버리

step 1. 전체 노드의 오라클 클러스터웨어 stop

# crsctl stop crs

 

step 2. 해당 백업 경로에서 복구 수행

# ocrconfig -import

 

step 3. 복원 확인

# cluvfy comp ocr -n all

 

step 4. 전체 노드의 오라클 클러스터웨어 start

# crsctl start crs

'ORACLE > 공부하기' 카테고리의 다른 글

OCR & Voting Disk  (0) 2019.07.03
ASM 모니터링  (0) 2019.07.02
OCR 과 Vote disk  (0) 2019.07.02
[RAC] OCR(Oracle Configuration Repository), VOTING  (0) 2019.07.02
RAC 구조  (0) 2019.07.02
Posted by Max-Jang
,

OCR 과 Vote disk

ORACLE/공부하기 2019. 7. 2. 14:18
반응형

OCR - Oracle Cluster Repository

RAC구성의 전체 정보를 저장하고 있는 디스크

RAC에서의 핵심역할을 한다.

OCR에 저장되어있는 정보를 보고 RAC를 구성한다.

10g까지는 RAC 시작후 ASM instance를 시작하기 때문에 OCR을ASM에 저장할 경우 RAC를 시작할 수 없게 된다. 따라서 OCR, Vote disk는 ASM storage 에 저장하지 않고 raw device 에 저장한다.

Oracle이 권장하는 OCR의 최소 크기는 100MB이다.

 

Vote disk

각 노드들의 장애 여부를 구분하기 위해서 사용하는 일종의 출석부 이다.
RAC는 여러개의 인스턴스 노드들로 구성되어 있으면 각 노드들이 문제가 있는지 없는지를 실시간으로 파악하고 있어야 한다.

RAC를 구성하는 프로세스 중에서 cssd 라는 프로세스가 각 노드 들이 정상적으로 작동하고 있는지 매 초 마다 interconnet를 통해 매 초마다 heartbit를 보내고 각 노드는 그에 대한 응답을 보낸다.
각 노드들은 cssd가 보내는 heartbit에 대하여 자신이 정상작동하고 있음을 vote disk에 기록해두고 있다.

1차 cssd 는 Heartbit를 보내고 노드의 응답을 기다린다. 응답이 없을 경우

2차 cssd는 votedisk에 가서 확인해본다.

노드의 표시가 없다면 노드에 장애가 생겼다고 판단하고 해당 노드를 cluster에서 제외하고 재부팅하게된다.

Oracle이 권장하는 vote disk의 최소크기는 20MB이고, vote disk를 3개로 다중화하기를 권장한다.

 

참고로 11g RAC 부터는 OCR 과 Vote disk 를 모두 ASM Storage 에 저장 할 수 있습니다.
그리고 11g 부터는 Clusterware 가 Grid Infrastructure 라는 프로그램에 통합이 되어서 Grid 프로그램을 설치하면 자동으로 설치가 됩니다.

'ORACLE > 공부하기' 카테고리의 다른 글

ASM 모니터링  (0) 2019.07.02
OCR 관리  (0) 2019.07.02
[RAC] OCR(Oracle Configuration Repository), VOTING  (0) 2019.07.02
RAC 구조  (0) 2019.07.02
RAC 개념  (0) 2019.07.02
Posted by Max-Jang
,

[RAC] OCR(Oracle Configuration Repository), VOTING

ORACLE/공부하기 2019. 7. 2. 14:16
반응형

1. OCR

 



1-1 OCR 이란?

  • OCR은 RAC를 구성하는 정보를 저장하는 저장소라는 것이 있습니다. 이러한 OCR정보는 RAC 환경에서 매우 중요한 관리 항목으로 주기적인 백업을 받아 두어야 합니다. 기본적으로 OCR 백업은 4시간 마다 자동으로 백업이 이루어 지며, 비상 상황을 대비하여 3벌의 백업을 자동으로 유지 관리 합니다.
  • OCR file은 root 소유로 되며 Oracle Cluster Repository의 약자로 말그대로 Cluster의 정보를 담고 있습니다.

1-2 OCR 수동 백업/복구 절차

  • ocrconfig -backuploc // 백업 시작
  • ocrconfig -showbackup // 백업 현황 조회
  • ocrconfig -restore // 복구(모든 NODE 중지 후 한 NODE씩 작업 진행)
  • ocrconfig -export // export
  • ocrconfig -import // import

1-3 CLUSTER를 중단시키고 OCR 정보를 Import 하는 방법

  • CLUSTER상의 모든 Node를 Shutdown 한 후 Node 한대만을 single-usermode로 올립니다.
  • ocrconfig -import 명령을 사용하여 import를 수행 합니다.
  • CLUSTER상의 모든 Node를 Multi-usermode로 구동시킵니다.

1-4 CLUSTER를 중단시키지 않고 OCR 정보를 Import 하는 방법

  • 모든 Node의 initab 파일을 다른 이름으로 COPY 해놓은 후 모든 NODE 상의 initab entries를 Update 하고 CRS 관련 entry를 제거합니다.
  • 모든 Node에서 /etc/init.d/init.crsstop 명령을 사용하여 CRS를 중지 시킵니다.
  • CLUSTER상의 한 Node에서 ocrconfig -import 명령을 사용하여 OCR export를 수행합니다.
  • 모든 Node에서 originalinitab file을 복원 합니다.
  • 모든 Node에서 /etc/init.d/init.crsstart명령으로 CRS START
  • /etc/initq 명령을 실행 합니다.

 



2. Voting

2-1 Votiong 이란?

  • Oracle 소유로(오라클 설치시 UID) 되며 장애시 어떤 Node를 제거할지 검사하는 용도로 사용 합니다.

2-2 Votiong 현재 상태 확인

  • crsctl query css votedisk



3. 질문사항

3-1 ocr, voting 어떻게 확인 하나요?

3-2 ocr, voting 초기화 어떻게 하나요?

3-3 ocr, voting 다른 스토리지로 이관은 어떻게 하나요?


OCR과 Voting Disk는 Oracle Cluster component들 입니다. 스토리지에서 OCR, Voting Disk부터 controlfile, datafile등의 순서로 Oracle은 파일들을 체크하면서 읽기 시작 합니다. OCR은 cluster와 cluster 내의 resource의 정보를 담고 있고 Voting Disk는 각 노드의 status를 확인하기 위해 사용 합니다



출처: https://estenpark.tistory.com/305 [DATA 전문가로 가는 길]

'ORACLE > 공부하기' 카테고리의 다른 글

ASM 모니터링  (0) 2019.07.02
OCR 관리  (0) 2019.07.02
OCR 과 Vote disk  (0) 2019.07.02
RAC 구조  (0) 2019.07.02
RAC 개념  (0) 2019.07.02
Posted by Max-Jang
,

RAC 구조

ORACLE/공부하기 2019. 7. 2. 11:53
반응형

Single server

하나의 Storage에 하나의 Instance를 연결한구조

단점 : 장애 발생시 처리 방안이 없다. Storage에 저장된 데이터에 접근할 수 없다.

 

HA (High Availability)

Active : instance - storage

Stanby : instance - storage

복제품을 하나더 만들어 놓고 Storage를 동기화한다.

단점 : 데이터 동기화 문제, stanby 서버의 활용도 낮다.

 

OPS (oracle parallel Server)

하나의 Storage 두개의 Instance

부하 분산, 서비스 취소 없이 장애 발생을 해결한다. 데이터 동기화 문제도 해결된다.

단점 : RAC Ping 두 인스턴스가 직접적으로 연결되어 있지 않기때문에 데이터 교환은 반드시 Disk를 통해서 이루어 진다.

 

 

RAC(Real Application Cluster)

-9i RAC

  • interconnet (Private network): OPS는 데이터를 받아올때 반드시 Storage를 이용해야 한다. RAC 9i 부터는 interconnet 기능을 이용하여 인스턴스간에 데이터를 직접적으로 주고 받을수 있게 된다.

  • Public network : RAC 유지보수를 위해 접속하는 망

  • VIP network : 외부 사용자들이 접속하는 망, 서비스를 제공해주는 망

 

-10g RAC

  • ASM 방식의 적용 : 9i 까지는 RAW device를 이용해서 storage를 구성하였으나 10g 부터는 ASM (Automatic Storage Management) 방식으로 storage를 구성한다.

 

-10g R2 RAC ASM 기반

RAW device로 Storage를 구성하면 각 인스턴스별로 ASM Instance 부분이 빠지게 된다
10g rac 까지는 OCR과 vote disk 를 ASM에 저장할수 없었기 때문에 별도의 RAW device를 구성해야 했다. (11g 부터는 개선되었다)

  • OCR : Oracle Cluester Repository, RAC구성의 전체 정보를 저장하고 있는 디스크이다. RAC의 핵심역할을 하고 있다.

  • Oracle이 권장하는 OCR의 최소 크기는 100MB이다.

'ORACLE > 공부하기' 카테고리의 다른 글

ASM 모니터링  (0) 2019.07.02
OCR 관리  (0) 2019.07.02
OCR 과 Vote disk  (0) 2019.07.02
[RAC] OCR(Oracle Configuration Repository), VOTING  (0) 2019.07.02
RAC 개념  (0) 2019.07.02
Posted by Max-Jang
,

티스토리툴바