Oracle - 리두와 언두

Posted 05 17, 2012 16:42, Filed under: DataBase/Oracle


# 리두란 무엇인가?


리두 로그 파일은 오라클 데이터베이스에서 매우 중요하다.
이 파일은 데이터베이스를 위한 트랜잭션로그를 담고 있다.
오라클은 인스턴스 장애 또는 미디어 장애 시 데이터베이스를 복구할 목적으로 두 종류의 리두 로그 파일, 즉 온라인(online)리두 파일과 아카이브(archived) 리두 로그 파일을 유지한다.

데이터베이스 장비에 전력이 끊어지면 인스턴스 장애가 발생하는데, 오라클은 정전이 일어나기 바로 전 커밋된 시점까지 시스템을 복원하기 위해 온라인 리두 로그를 사용한다.
만약 디스크 드라이브에 장애가 발생하면(미디어 오류), 오라클은 그 지점까지 드라이브에 있었던 데이터를 백업하여 복구하는 데 아카이브 리두 로그와 온라인 리두 로그 둘 다 사용한다.
더 나아가서 '뜻하지 않게' 테이블을 truncate 했거나 중요한 정보를 delete 한 후 커밋했다면, 온라인과 아카이브 리두 로그 파일을 이용하여 영향받은 데이터를 백업하여 회복하고 '사고' 바로 전 시점까지 복구할 수 있다.

아카이브 리두 로그 파일은 단순히 온라인 리두 로그 파일의 과거 내용 전체를 복제한 사본에 불과하다.
시스템이 로그 파일을 채우면, ARCH 프로세스는 온라인 로그 파일의 복사본을 다른 위치에 생성한다.
또한 선택적으로 여려 개의 복사본을 로컬 또는 원격 위치에 둘 수도 있다.
디스크 드라이브 손상이나 다른 물리적 결함에 의해 문제가 발생했을 때 다른 위치에 복사해 둔 아카이브 로그 파일을 사용해 미디어 복구를 수행한다.
즉, 아카이브 리두 로그 파일을 읽어 데이터 파일 백업본에 적용한다.
그럼으로써 데이터베이스의 다른 부분과 동기화시킨다.
결국 아카이브 파일은 데이터베이스의 트랜잭션 이력이다.

-Note---------------------------------------------------------------------
오라클 10g가 나오면서 플래시백 기술이 추가되었다.
플래시백 쿼리를 수행(과거 특정 시점을 기준으로 데이터를 조회)하거나, drop한 테이블을 되살리거나, 살아있는 테이블을 원하는 시점으로 되돌리는 등 여러 가지 플래시백 작업이 가능하다.
결과적으로, 백업 파일과 아카이브 리두 로그를 이용해 전통적인 방식으로 복구하는 경우는 많이 줄었다.
그렇다고 하더라도 복구 작업은 DBA의 가장 중요한 업무며, 결코 소홀히 할 수 없는 작업 중 하나다.
--------------------------------------------------------------------------

......
리두 로그, 즉 트랜잭션 로그는 데이터베이스를 데이터베이스답게 만드는 중요한 기능 중 하나다.
물론 언두 세그먼트, 분산 트랜잭션 복구 등과 같은 요소가 없어도 데이터베이스는 작동하지 않겠지만, 특히 리두 로그는 데이터베이스에서 가장 중요한 복구 요소로서 전통적인 파일 시스템과 데이터베이스를 구분 짓는 주요 구성요소다.
온라인 리두 로그를 통해 정전으로부터 효과적으로 데이터베이스를 복구할 수 있고(정전은 데이터를 디스크에 쓰고 있는 동안에도 일어날 수 있다), 아카이브 리두 로그를 통해 미디어 장애로부터 데이터베이스를 복구할 수 있다.
리두 로그가 없다면 데이터 보호 측면에서 파일 시스템보다 나을 게 없다.



# 언두란 무엇인가?

언두는 개념상 리두의 반대 개념이다.
언두 정보는 변경이 일어나기 이전 상태로 데이터를 되돌릴 수 있도록 데이터 변경 시 데이터베이스가 생성하는 정보다.
수행 중인 트랜잭션이나 문장이 어떤 이유로 실패하거나 롤백 문장으로 되돌리기를 요청하면, 7장 '동시성과 멀티버저닝'에서 학습한 멀티버저닝의 지원 하에 이루어진다.
리두는 장애 발생 시 트랜잭션을 재현하는 데 사용되는(트랜잭션을 복원) 반면, 언두는 단일 문장 또는 문장 집합의 결과를 거꾸로 되돌리기 위해 사용된다.
언두는 리두와 다르게 데이터베이스에 언두 세그먼트로 알려진 세그먼트의 특정 집합에 내부적으로 저장된다.

-Note---------------------------------------------------------------------
'롤백 세그먼트'와 '언두 세그먼트'는 같은 뜻을 가진 용어로 생각하면 된다.
DBA는 수동 언두 관리 방식으로 '롤백 세그먼트'를 생성할 수 있다.
자동 언두 관리 방식에서는 시스템이 자동으로 언두 세그먼트를 필요한 만큼 생성하고 제거한다.
이번 장에서 이 두 용어는 모든 의도와 목적에 맞게 동일하게 최급되어야 한다.
--------------------------------------------------------------------------

언두를 사용해서 데이터베이스를 물리적으로 문장이나 트랜잭션이 실행되기 전 모습으로 복원한다고 오해하는 사람들이 있는데, 사실은 그렇지 않다.
데이터베이스를 논리적으로 과거 모습 그대로 복원하는 것일 뿐(어떤 변경도 논리적으로 언두된다) 데이터 구조, 데이터베이스 블록 같은 물리적인 요소는 롤백 후에 달라질 수 있다.
이유는 다중 사용자 시스템에서는 수십에서 수천 개의 동시 트랜잭션이 존재한다.
데이터베이스의 주요한 기능 중 하나는 데이터에 대한 동시 액세스를 조정하는 것이다.
한 트랜잭션이 변경한 블록은 일반적으로 또 다른 많은 트랜잭션에 의해서도 변경될 수 있다.
그러므로 트랜잭션이 시작할 때 모습 그대로 블록을 되돌린다면, 다른 사람의 작업 결과까지 언두하는 결과를 초래할 수 있다.

예를 들어 트랜잭션이 새로운 익스텐트를 할당하는 INSERT 문을 실행한다고 가정하자.
INSERT는 새로운 블록을 얻어 포맷하고 데이터를 적재한다.
그 시점에 다른 트랜잭션이 그 블록에 데이터를 삽입한다.
이 경우, 처음 트랜잭션을 롤백한다고 해서 그 블록의 포맷을 지우거나 할당을 취소할 수 없다.
그러므로 오라클이 롤백할 때는 처음에 작업했던 내용과 논리적으로 반대되는 작업을 한다.
즉, 모든 INSERT에 결과를 DELETE하고, 모든 DELETE 결과를 INSERT한다.
모은 UPDATE에 대해서는 '역 UPDATE' 또는 변경하기 전 모습으로 로우를 돌려놓는 UPDATE를 한다.

-Note---------------------------------------------------------------------
direct-path 작업 시에는 언두를 생성하지 않는다.
--------------------------------------------------------------------------

어떻게 하면 이런 과정을 볼 수 있을까? 가장 쉬운 방법은 다음 절차를 따르는 것이다.

    1. 빈 테이블을 생성한다.

    2. 빈 테이블을 전체 스캔하고 발생한 I/O 양을 관찰한다.

    3. 테이블에 로우를 많이 삽입한다(커밋은 하지 않음).

    4. 작업을 롤백하고 테이블을 언두한다.

    5. 다시 테이블을 전체 스캔하고 발생한 I/O 양을 관찰한다.

위 절차대로 빈 테이블부터 생성해보자.
SUNSHINY@ora11g > create table t
  2  as
  3  select *
  4    from all_objects
  5   where 1=0;

Table created.

이제 AUTOTRACE가 활성화된 SQL*Plus에서 I/O를 측정하기 위해 테이블 T를 쿼리한다.

-Note---------------------------------------------------------------------
이 예제에서 테이블 T를 각각 두 번씩 스캔할 것이다.
두 번째 수행된 쿼리로 I/O를 측정하는 이유는 SQL 파싱과 최적화 동안에 옵티마이저에 의해 발생하는 부가적인 I/O를 제외하기 위해서다.
--------------------------------------------------------------------------

처음에 테이블을 전체 스캔했을 때는 I/O가 전혀 발생하지 않는다.
SUNSHINY@ora11g > select * from t;

no rows selected

SUNSHINY@ora11g > set autotrace traceonly statistics
SUNSHINY@ora11g > select * from t;

no rows selected

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
       1343  bytes sent via SQL*Net to client
        513  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

SUNSHINY@ora11g > set autotrace off

빈 테이블에 대한 I/O가 0이라는 사실에 놀랄 수 있다(오라클 데이터베이스 11g 릴리즈 2 이하 버전을 사용하고 있는 오라클 사용자라면 특히).
이것은 새로운 11g 릴리즈 2의 특징인 deferred segment creation때문이다.
만약 과거 릴리즈에서 이 예제를 실행한다면, 수행된 I/O를 세 개쯤 보게 된다.

# 10g 릴리즈 2에서 실행 결과 3개의 I/O가 확인됨.
SUNSHINY@ora10g > create table t
  2  as
  3  select *
  4    from all_objects
  5   where 1=0;

Table created.

SUNSHINY@ora10g > select * from t;

no rows selected

SUNSHINY@ora10g > set autotrace traceonly statistics
SUNSHINY@ora10g > select * from t;

no rows selected

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
        995  bytes sent via SQL*Net to client
        374  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

SUNSHINY@ora10g > set autotrace off


다음으로 테이블에 데이터를 많이 추가한다. 테이블을 크게 만든 다음 롤백할 것이다.
SUNSHINY@ora11g > insert into t select * from all_objects;

70470 rows created.

SUNSHINY@ora11g > rollback;

Rollback complete.


이제 테이블을 다시 쿼리하면 이번에는 테이블을 읽기 위해 상당히 많은 I/O를 수반함을 알 것이다.
SUNSHINY@ora11g > select * from t;

no rows selected

SUNSHINY@ora11g > set autotrace traceonly statistics
SUNSHINY@ora11g > select * from t;

no rows selected

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1005  consistent gets
          0  physical reads
          0  redo size
       1343  bytes sent via SQL*Net to client
        513  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

SUNSHINY@ora11g > set autotrace off

INSERT로 인하여 테이블의 최고 수위점(HWM, hith-water mark) 아래에 추가된 블록은 포맷된 상태로 비어 있다.
전체 스캔은 블록에 로우가 있는지 확인하기 위해 해당 블록을 읽어야만 한다.
쿼리르 처음 실행했을 때 I/O가 0이었음을 확인했다.
그것은 오라클 데이터베이스 11g 릴리즈 2에서 테이블을 생성할 때 기본값 모드가 다르기 때문에 발생하는 현상이다(세그먼트 생성이 연기된다).
CREATE TABLE 문을 전송한 것만으론 단 한 개의 익스텐트도 할당되지 않는다.
세그먼트 생성은 INSERT가 일어날 때까지 연기됐지만, 일단 생성되고 나면 롤백하더라도 세그먼트는 영구적으로 남는다.
예제를 통해 이 현상을 쉽게 확인할 수 있다.
이번엔 세그먼트 생성 연기(deferred segment creation)를 명시적으로 요청해보자.
이것이 11g 릴리즈 2에서 기본값으로 활성화되어 있을지라도 말이다.
SUNSHINY@ora11g > create table t ( x int )
  2  segment creation deferred;

Table created.

SUNSHINY@ora11g > select extent_id, bytes, blocks
  2    from user_extents
  3   where segment_name = 'T'
  4   order by extent_id;

no rows selected

SUNSHINY@ora11g > insert into t(x) values (1);

1 row created.

SUNSHINY@ora11g > rollback;

Rollback complete.

SUNSHINY@ora11g > select extent_id, bytes, blocks
  2    from user_extents
  3   where segment_name = 'T'
  4   order by extent_id;

 EXTENT_ID      BYTES     BLOCKS
---------- ---------- ----------
         0      65536          8


보다시피, 테이블이 생성되더라도 사용한 익스텐트가 없으므로 할당된 저장공간이 없다.
INSERT를 수행하고 곧바로 ROLLBACK을 하면, INSERT 시에 할당된 저장공간을 볼 수 있다(ROLLBACK은 그 공간을 해제하지 않는다).

위 두 가지 사실(세스먼트 INSERT에 의해 실제로 만들어지지만 ROLLBACK한다고 해서 그 공간이 해제되지 않는다는 것과 새롭게 포맷된 블록은 두 번째로 스캔되는 시점에 INSERT에 의해 생성되는 것)을 통해, 롤백은 논리적인 측면에서 데이터베이스를 이전 상태로 되돌리는 작업임을 알 수 있다.
데이터베이스는 정확히 이전 모습은 아니고 논리적으로만 동일하다.



출처 : 전문가를 위한 오라클 데이터베이스 아키텍처 - 토마스 카이트



※ 위 내용은, 여러 자료를 참고하거나 제가 주관적으로 정리한 것입니다.
   잘못된 정보나 보완이 필요한 부분을, 댓글 또는 메일로 보내주시면 많은 도움이 되겠습니다.
05 17, 2012 16:42 05 17, 2012 16:42


Trackback URL : http://develop.sunshiny.co.kr/trackback/759

Leave a comment

« Previous : 1 : ... 226 : 227 : 228 : 229 : 230 : 231 : 232 : 233 : 234 : ... 648 : Next »

Recent Posts

  1. HDFS - Python Encoding 오류 처리
  2. HP - Vertica ROS Container 관련 오류...
  3. HDFS - Hive 실행시 System Time 오류
  4. HP - Vertica 사용자 쿼리 이력 테이블...
  5. Client에서 HDFS 환경의 데이터 처리시...

Recent Comments

  1. 안녕하세요^^ 배그핵
  2. 안녕하세요^^ 도움이 되셨다니, 저... sunshiny
  3. 정말 큰 도움이 되었습니다.. 감사합... 사랑은
  4. 네, 안녕하세요. 댓글 남겨 주셔서... sunshiny
  5. 감사합니다 많은 도움 되었습니다!ㅎㅎ 프리시퀸스

Recent Trackbacks

  1. church building construction church building construction %M
  2. wireless clocks transmitter wireless clocks transmitter %M
  3. how to build a metal building how to build a metal building %M
  4. builder builder %M
  5. social media management company social media management company %M

Calendar

«   12 2019   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Bookmarks

  1. 위키피디아
  2. MysqlKorea
  3. 오라클 클럽
  4. API - Java
  5. Apache Hadoop API
  6. Apache Software Foundation
  7. HDFS 생태계 솔루션
  8. DNSBL - Spam Database Lookup
  9. Ready System
  10. Solaris Freeware
  11. Linux-Site
  12. 윈디하나의 솔라나라

Site Stats

TOTAL 2781568 HIT
TODAY 1151 HIT
YESTERDAY 1360 HIT