오라클 백업 및 복구(Redolog, Undo)
1. Undo의 관리
가. parameter에 값을 설정한다.
– UNDO_MANAGEMENT : AUTO, MANUAL 지정
– UNDO_TABLESPACE : 기본 UNDO 테이블 스페이스 지정
– UNDO_RETENTION : UNDO 데이터의 보유 시간을 결정(단위 : 초),
나. 관리방식
– 자동 : 오라클이 관리(AUTO), startup 시(mount 단계에서 open 단계로 넘어갈 때) undo 데이터파일의 무결성을 확인하며, 장애발생 시 open에 실패한다.
– 수동 : DBA가 관리(MANUAL), startup 시 undo 데이터파일의 무결성을 확인하지 않아, undo 데이터파일에 장애가 발생했을 시 사용하는 모드이다.(undo 데이터파일이 존재하지 않아도 open 된다.)
다. UNDO의 생성/삭제 등
-- undo 정보 조회 show parameter undo NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string AUTO undo_retention integer 900 undo_tablespace string UNDO -- 사용중인 rollback segment 확인 select s.sid, s.serial#, s.username, r.name "rollback seg" from v$session s, v$transaction t, v$rollname r where s.taddr=t.addr and t.xidusn=r.usn; SID SERIAL# USERNAME rollback seg ---- ------- --------------- -------------------- 138 18 SCOTT _SYSSMU17$ -- undo tablespace 생성 create undo tablespace undo_test datafile '/home/oracle/oradata/testdb/undo_test01.dbf' size 10M autoextend on; -- default undo tablespace 변경 -- 영구적용을 위해서는 parameter 파일의 undo_tablespace 값도 변경해줘야 한다. alter system set undo_tablespace=undo_test; -- 테이블 스페이스 삭제 drop tablespace undo_test including contents and datafiles; -- 장애난 undo tablespace segment 조회 select segment_name, owner, tablespace_name, status from dba_rollback_segs;
참고 : 사용중인 세그먼트로 undo 테이블스페이스가 삭제되지 않을 때 강제 삭제방법 drop tablespace undo_test including contents and datafiles; drop tablespace undotbs * ERROR at line 1: ORA-01548: active rollback segment ‘_SYSSMU1$’ found, terminate dropping tablespace 아래와 같이 parameter파일에 hidden parameter를 사용한다. 보통 _SYSSMU1$ 에서 _SYSSMU10$처럼 10개 단위로 세그먼트가 생성되므로, 오류메시지에 나와있는 세그먼트를 포함하여 10개정도를 적어준다. _offline_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)
참고 : ORA-03113: end-of-file on communication channel 위 에러는 SQLPLUS를 재시작하면 해결된다.2. Instance Recovery 데이터베이스가 비정상적으로 종료되어 STARTUP 할 때 SMON이 redolog file과 Undo Segment 정보를 가지고 데이터 복구 하는 과정을 말한다. 이 때 복구해야할 데이터는 모두 Redolog 파일에 기록되어 있어야 하며, 복구할 데이터가 Archive 파일에도 있을 경우 자동복구(SMON이 자동실행)는 실패하고 수동복구(DBA가 수행)가 필요하게 된다. 3. RedoLog의 생성 및 기록원리 가. DML 작업 발생 나. 필요블럭 DB Buffer Cache에 로드 -> Block Lock(page fix) 다. PGA에서 Redolog Change Vector 생성 라. redo copy latch 획득 마. redo allocation latch 획득 바. redolog buffer 에 Change Vector 기록 사. LGWR이 redolog buffer의 내용을 redolog 파일에 기록 (buffer가 1/3이상이 찼을 경우, 1M가 넘었을 경우, 3초에 한 번)
참고 : Change Vector Change Vector에는 변경 전 데이터와 변경후 데이터가 모두 기록되는데, 그 이유는 비정상적인 서버종료 시 Roll forward와 Rollback 작업을 수행하기 위해서이다. Rollforward는 사용자가 commit 하였지만 비정상적인 서버종료로 datafile에 기록하지 못한 데이터를 저장하는 행위이며, rollback는 commit하지 않았거나 rollback 명령어로 해당 트랜잭션을 취소했을 때 원래대로 데이터를 되돌리는 행위이다.
참고 : latch Latch는 SGA의 공유 데이터구조를 보호하기 위해서 사용되는 기법으로 빨리 획득되고 풀리는 Lock의 일종이다. 한 순간에 하나 이상의 프로세스가 동시에 같은 메모리를 접근하는 것을 방지하는데 사용된다. 추가정보 : http://blog.naver.com/PostView.nhn?blogId=dangtong76&logNo=140064903533
참고 : latch의 경합 및 관리 Latch는 모든 메모리영역(DB Buffer Cache, Redolog, Shared pool 등)에 각각 존재하며 갯수도 다르다. Latch는 여러개가 존재하거나 1개만 존재할 수 도 있다. Latch가 1개일 경우 이것을 차지하기 위한 프로세스의 경합이 발생한다. 이러한 경합이 자주 발생할수록 서버의 성능은 저하된다. 그러므로 이를 해결하기 위한 방법이 여러가지 고안되었는데 그 중 shared redo strand가 있다. shared redo strand는 redolog buffer를 여러개의 공간으로 나누어 각 공간별로 redo allocation latch를 할당해주는 것을 말한다.(이 기능이 도입되기 전에는 redo allocation latch는 1개였다), 이후 shared reo strand의 확장버전인 private redo strand 기능을 도입하였다. 이 기능은 shared pool에 자신만의 private redo strand 영역을 만들어 그곳에 change vector를 생성하고 필요할 경우 LGWR이 redo log 파일에 기록하는 것을 말한다. 이를 zero copy라고 부른다. 이처럼 latch의 경합을 줄이기 위해 많은 기술이 계속 발전하고 있다.
참고 : SCN(System Commit Number) Vs SCN(System Change Number) – System Commit Number : Commit 가 발생하면 해당 트랜잭션은 고유한 번호를 부여받는데 이를 SCN이라 한다. SMON이 kcmgas 라는 함수를 사용하여 관리한다. scn_base(4byte) + scn_wrap(2byte)으로 구성 – System Change Number : 데이터파일, 리두로그파일, 컨트롤파일의 동기화를 맞추기 위해 사용, scn_base(4byte) + scn_wrap(2byte) + scn_sequence(1byte)로 구성, scn_sequence는 여러개의 서버프로세스가 동일한 블록을 변경하려고 할 때 이를 구분하기 위해 사용한다.4. Commit Write 가. Commit 발생 시 LGWR이 해당 트랜잭션을 기록하는 것, 이 과정은 4가지 방식이 있다. – WAIT : 변경된 트랜잭션이 리두로그파일에 기록될 때까지 서버프로세스, SMON등이 기다림 – NOWAIT : WAIT와는 반대로 서버프로세스나 SMON등이 기다리지 않음(다음 작업을 바로 수행) – IMMEDIATE : COMMIT 발생 시 리두로그파일에 바로 기록 – BATCH : COMMIT이 발생하더라도 일정시간동아 모아서 한번에 기록 나. 일반적으로 위 4가지 방식 중 2개씩 혼합하여 사용(IMMEDIATE+WAIT, IMMEDIATE+NOWAIT 등) 다. BATCH나 NOWAIT와 같이 리두로그파일에 기록작업이 끝나지 않아도 서버프로세스나 SMON등이 다른 작업을 할 수 있도록 하는 방식을 비동기식 커밋(Asynchronous Commit)라고 한다.
참고 : 비동기식 커밋방식(NOWAIT, BATCH)의 장단점 – 데이터의 안정성은 높아지나 DISK I/O가 발생하므로 서버의 성능이 저하됨 – OLTP 환경에서는 자제하는 것이 좋음5. Checkpoint의 종류 가. Database / Global Checkpoint : DB Buffer Cache에 있는 모든 Dirty Buffer의 내용을 데이터파일에 저장 나. Thread checkpoint / Logical Checkpoint : RAC환경하에 사용, 해당 Thread내의 저장되지 않은 Dirty Buffer의 내용을 데이터파일에 저장 다. Data file Checkpoint : 특정 데이터 파일에만 발생하는 체크포인트, tablespace의 offline, hotbackup 수행 시 발생 라. Mini Checkpoint : 특정 DDL 발생 시 특정 블록에만 발생 마. Recover Checkpoint : 데이터파일에 장애발생 시 발생하는 체크포인트
참고 : FAST_START_MTTR_TARGET 8i부터 사용되는 파라미터, 단위는 초, 값이 작을수록 복구시간이 짧아지나 checkpoint가 자주 발생하여 서버의 성능이 저하된다. * MTTR(Mean Time To Recovery) : 복구평균시간
최신 댓글