'Undo'에 해당되는 글 2건

  1. 2023.12.16 undo check 및 advice 스크립트
  2. 2011.05.03 REDO 와 UNDO를 차이점에서 바라본 관점

SET SERVEROUTPUT ON
SET LINES 600
ALTER SESSION SET NLS_DATE_FORMAT = 'DD/MM/YYYY HH24:MI:SS';

DECLARE
    v_analyse_start_time    DATE := SYSDATE - 7;
    v_analyse_end_time      DATE := SYSDATE;
    v_cur_dt                DATE;
    v_undo_info_ret         BOOLEAN;
    v_cur_undo_mb           NUMBER;
    v_undo_tbs_name         VARCHAR2(100);
    v_undo_tbs_size         NUMBER;
    v_undo_autoext          BOOLEAN;
    v_undo_retention        NUMBER(6);
    v_undo_guarantee        BOOLEAN;
    v_instance_number       NUMBER;
    v_undo_advisor_advice   VARCHAR2(100);
    v_undo_health_ret       NUMBER;
    v_problem               VARCHAR2(1000);
    v_recommendation        VARCHAR2(1000);
    v_rationale             VARCHAR2(1000);
    v_retention             NUMBER;
    v_utbsize               NUMBER;
    v_best_retention        NUMBER;
    v_longest_query         NUMBER;
    v_required_retention    NUMBER;
BEGIN
    select sysdate into v_cur_dt from dual;
    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('- Undo Analysis started at : ' || v_cur_dt || ' -');
    DBMS_OUTPUT.PUT_LINE('--------------------------------------------------');

    v_undo_info_ret := DBMS_UNDO_ADV.UNDO_INFO(v_undo_tbs_name, v_undo_tbs_size, v_undo_autoext, v_undo_retention, v_undo_guarantee);
    select sum(bytes)/1024/1024 into v_cur_undo_mb from dba_data_files where tablespace_name = v_undo_tbs_name;

    DBMS_OUTPUT.PUT_LINE('NOTE:The following analysis is based upon the database workload during the period -');
    DBMS_OUTPUT.PUT_LINE('Begin Time : ' || v_analyse_start_time);
    DBMS_OUTPUT.PUT_LINE('End Time   : ' || v_analyse_end_time);
    
    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Current Undo Configuration');
    DBMS_OUTPUT.PUT_LINE('--------------------------');
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace',55) || ' : ' || v_undo_tbs_name);
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (datafile size now) ',55) || ' : ' || v_cur_undo_mb || 'M');
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo tablespace size (consider autoextend) ',55) || ' : ' || v_undo_tbs_size || 'M');
    IF V_UNDO_AUTOEXT THEN
        DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : ON');  
    ELSE
        DBMS_OUTPUT.PUT_LINE(RPAD('AUTOEXTEND for undo tablespace is',55) || ' : OFF');  
    END IF;
    DBMS_OUTPUT.PUT_LINE(RPAD('Current undo retention',55) || ' : ' || v_undo_retention);

    IF v_undo_guarantee THEN
        DBMS_OUTPUT.PUT_LINE(RPAD('UNDO GUARANTEE is set to',55) || ' : TRUE');
    ELSE
        dbms_output.put_line(RPAD('UNDO GUARANTEE is set to',55) || ' : FALSE');
    END IF;
    DBMS_OUTPUT.PUT_LINE(CHR(9));

    SELECT instance_number INTO v_instance_number FROM V$INSTANCE;

    DBMS_OUTPUT.PUT_LINE('Undo Advisor Summary');
    DBMS_OUTPUT.PUT_LINE('---------------------------');

    v_undo_advisor_advice := dbms_undo_adv.undo_advisor(v_analyse_start_time, v_analyse_end_time, v_instance_number);
    DBMS_OUTPUT.PUT_LINE(v_undo_advisor_advice);

    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Undo Space Recommendation');
    DBMS_OUTPUT.PUT_LINE('-------------------------');

    v_undo_health_ret := dbms_undo_adv.undo_health(v_analyse_start_time, v_analyse_end_time, v_problem, v_recommendation, v_rationale, v_retention, v_utbsize);
    IF v_undo_health_ret > 0 THEN
        DBMS_OUTPUT.PUT_LINE('Minimum Recommendation           : ' || v_recommendation);
        DBMS_OUTPUT.PUT_LINE('Rationale                        : ' || v_rationale);
        DBMS_OUTPUT.PUT_LINE('Recommended Undo Tablespace Size : ' || v_utbsize || 'M');
    ELSE
        DBMS_OUTPUT.PUT_LINE('Allocated undo space is sufficient for the current workload.');
    END IF;
    
    SELECT dbms_undo_adv.best_possible_retention(v_analyse_start_time, v_analyse_end_time) into v_best_retention FROM dual;
    SELECT dbms_undo_adv.longest_query(v_analyse_start_time, v_analyse_end_time) into v_longest_query FROM dual;
    SELECT dbms_undo_adv.required_retention(v_analyse_start_time, v_analyse_end_time) into v_required_retention FROM dual;

    DBMS_OUTPUT.PUT_LINE(CHR(9));
    DBMS_OUTPUT.PUT_LINE('Retention Recommendation');
    DBMS_OUTPUT.PUT_LINE('------------------------');
    DBMS_OUTPUT.PUT_LINE(RPAD('The best possible retention with current configuration is ',60) || ' : ' || v_best_retention || ' Seconds');
    DBMS_OUTPUT.PUT_LINE(RPAD('The longest running query ran for ',60) || ' : ' || v_longest_query || ' Seconds');
    DBMS_OUTPUT.PUT_LINE(RPAD('The undo retention required to avoid errors is ',60) || ' : ' || v_required_retention || ' Seconds');

END;
/

Sample Output

- Undo Analysis started at : 30/08/2013 11:08:40 -
--------------------------------------------------
NOTE:The following analysis is based upon the database workload during the period -
Begin Time : 23/08/2013 11:08:40
End Time   : 30/08/2013 11:08:40

Current Undo Configuration
--------------------------
Current undo tablespace                                 : UNDOTBS2
Current undo tablespace size (datafile size now)        : 20M
Current undo tablespace size (consider autoextend)      : 20M
AUTOEXTEND for undo tablespace is                       : ON
Current undo retention                                  : 900
UNDO GUARANTEE is set to                                : FALSE

Undo Advisor Summary
---------------------------
Finding 1:Undo Tablespace is under pressure. Recommendation 1:Size undo tablespace to 26 MB

Undo Space Recommendation
-------------------------
Minimum Recommendation           : Size undo tablespace to 26 MB
Rationale                        : Increase undo tablespace size so that long running queries will not fail
Recommended Undo Tablespace Size : 26M

Retention Recommendation
------------------------
The best possible retention with current configuration is    : 9171 Seconds
The longest running query ran for                            : 2543 Seconds
The undo retention required to avoid errors is               : 2543 Seconds

PL/SQL procedure successfully completed.
Posted by pat98


1. REDO
 - 모든 변경사항을 REDO로그에 기록한다.
 - REDO로그는 Online REDO와 Archuved REDO로그로 구성된다.
    Online REDO 로그는 2개 이상의 파일로 구성되어 있어,
    현재 사용중인 로그 파일이 꽉 차면 다음 로그 파일로 스위칭
    이때 꽉 차여진 로그 파일을 다른 위치로 백업래 준 파일을 Archived REDO로그 이다.
 - 목적 3가지
  - 데이타 복구 : Archived REDO이용
  - 버퍼캐시복구 : 인스턴스가 비정상적종료시 그떄까지 작업내용이 잃어버리게 됨.
                          재기동 되면 Online REDO로그에 저장된 기록사항을 읽어와 마지막
                          채크포인트와 사고발생직전까지 수행한 트랜젹션을 재현
  - Fast Commit(IO속도 차 극복) : 데이타 버퍼 블록을 디스크에 기록하는 작업은 Random엑세스 방식,
                                              Append방식 Append방식이 상대적으로 빠르게 때문에 우선 변경사항을
                                              Append방식으로 기록하고 동기화는 후에 배치방식으로 일괄수행.
 - REDO로그 버퍼를 REDO로그에 기록하는 시점
  - 3초마다 DBWR프로세스부터 신호흫 받을때
  - 로그 버퍼의 1/3이 차거나 기록된 REDO레코드량이 1MB를 넘을떄
  - 사용자 커킷 또는 롤백 명령이 날릴때
  
2. UNDO
 - 각 트랜지션별로 UNDO세그먼트를 할당해주고 그 트랜지션이 발생시킨 테이블과 인댁스에
    대한 변경사항을 UNDO레코드 단위로 UNDO세그먼트 블록에 기록.
 - 목적 3가지
  - 트랜지션 롤백
  - 트랜지션 리커버리(인스턴스 리커버리시 롤백단계)
  - READ Consistency(읽기 일관성)
  타 DBMS는 Lock를 통해 일기 일관성을 구현하지만,
  오라클에서는 UNDO데이타를 이용해서 읽기 일관성을 구현한다.  
             읽기 일관성이란 Transaction이 진행되는 동안 Database의 다른 사용자는 이 Consistent Read에 의해
             Commit되지 않은 변경 사항을 볼 수 없는 기능 입니다.  
 - UNDO레코드에 기록되는 내용
  - Insert : 추가된 레코드의 rowid
  - Update : 변경되는 컬럼에 대한 before image
  - Delete : 지워지는 로우의 모든 컬럼의 대한 before image
------------------------------------------------------------------------------------
REDO 와 UNDO를 차이점에서 바라본 관점.
------------------------------------------------------------------------------------
REDO 는 UNDO를 포함 합니다.
REDO 는 시스템 장애시 복구를 위해 사용 합니다.
복구시에 UNDO 데이터도 같이 복구하구요. Commit 되지 않은 데이터를 Rollback 하게 됩니다.
UNDO 는 Rollback 시에도 사용 되지만 Read Consistency(읽기 일관성) 을 위해서 도 사용 됩니다.
REDO 는 모든 변경사항(UNDO 포함)을 기록 합니다.
복구는 UNDO 를 통해서 복구를 하게 됩니다. 즉, ROLLBACK을 한다는 말이죠.
시스템 장애가 발생하게 되면 UNDO 데이터도 모두 날아가게 되겠죠.
결국 시스템 장애시 REDO 데이터를 이용해서 마지막 CHECK POINT 부터 장애까지의 DB BUFFER CACHE 를 복구하게 됩니다.
이게 완료가 되면 UNDO DATA 를 이용하여 COMMIT 되지 않은 데이터를 모두 ROLLBACK 함으로써 복구를 완료하게 됩니다.
결국 REDO 가 UNDO 를 복구하고 최종적으로 UNDO가 복구를 하게 됩니다.
UNDO(안한것 처럼)는 되돌리는 것 이라고 보시면 될거에요.
어떤 세션에서 DML을 발생시키면 commit이나 rollback을 날리기 전까지 이전 정보를 저장하기 위해서
UNDO 블럭에 해당 정보를 기록하죠.. 해당 세션이 트렌젝션 중에 비정상적으로 종료가 되었다면,
안한것 처럼(UNDO) 다시 원복해야 되니까요.
REDO(다시 함)는 위에 설명에도 있듯이 인스턴스 실패시(DB가 내려감) 데이터 파일에 쓰여지지 않은 커밋된 데이터를 복구한다고 되어 있습니다.
좀 더 설명을 해드리자면 커밋을 날릴 경우 LGWR가 로그 파일에 변경된 정보를 기록하게 되고
그 다음에 DBWR이 버퍼캐쉬에 있는 변경 사항에 대해서 데이터 파일에 내려 쓰게 됩니다.
이는 복구 정보가 더 중요해서 그런 것이라고 이해하시면 됩니다(복구 정보가 있으면 재적용이나 되돌릴 수 있으므로).
DB가 비정상적으로 내려가면, 데이터 파일에 쓰여지지 않은 정보들이 리두로그에 기록되어 있으므로
리두로그에서 정보를 가져와 다시 적용(REDO)하는 것입니다.
Posted by pat98
이전버튼 1 이전버튼

05-10 00:00
Flag Counter
Yesterday
Today
Total

글 보관함

최근에 올라온 글

달력

 « |  » 2024.5
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

최근에 달린 댓글