[오라클]1-3단계 로그버퍼 영역

1-3 단계 : 로그버퍼영역

로그 버퍼 영역의 튜닝 분석   사용자들이 데이터베이스에 접속 한 후 INSERT, UPDATE, DELETE 작업을 실행하면 트랜잭션에 의해 만들어진 모든 변경정보(UPDATE문을 실행했다면 변경 전 데이터와 변경 후 데이터)가 로그버퍼 영역에 저장됩니다. 그러나, 로그버퍼 영역에는 사용자의 모든 변경된 데이터를 저장해 둘 수 없기 때문에 이 데이터들을 영구히 저장하기 위해 로그기록기(LGWR)에 의해 로그파일에 기록하게 됩니다. 리두로그 버퍼영역은 여려 명의 사용자가 같이 사용하는 공간이기 때문에 너무 많은 서버 프로세스가 동시에 많은 변경된 데이터를 저장하려고 한다면 서버 프로세스간에 경합(CONTENTION)이 발생할 것입니다. 또한, 사용자의 변경된 정보를 저장할 충분한 리두로그 버퍼공간이 없다면 미처 변경된 정보를 저장하지 못하고 대기(WAITING)해야 하는 경우도 발생할 것입니다. 이러한 문제가 발생하면 결국 UPDATE, INSERT, DELETE 시에 좋은 성능을 기대할 수 없습니다. 로그버퍼 영역의 크기는 INIT<DB명>.ORA 파일에 있는 LOG_BUFFER 파라메터에 의해 결정됩니다. 이 파라메터를 설정하지 않으면 오라클 서버는 블록크기(DB_BLOCK_SIZE 파라메터의 크기)의 4배 값을 기본 로그버퍼 영역의 크기로 할당합니다.   로그 버퍼 캐시 영역을 보다 크게 할당한다.             로그버퍼 영역에 대한 튜닝은 여러 사용자가 동시에 변경 작업을 했을 때 변경된 데이터를 저장할 만한 충분한 메모리 공간이 할당되어야 한다는 것입니다. 이 공간이 너무 작으면 서로 변경 데이터를 저장하기 위해 경합(CONTENTION)이 발생하고 결론적으로 어떤 서버 프로세스는 대기(WAITING) 상태가 발생할 것입니다. 다음은 자료사전을 통해 로그버퍼 영역을 분석하는 방법입니다.       V$SESSION_WAIT 자료사전을 참조하면 이 영역에 대한 튜닝 여부를 확인할 수 있습니다 SECOND_IN_WAITS 컬럼의 값이 계속 증가되는 값을 나타내고 STATE 컬럼이 "WAITING"을 나타내면 로그버퍼 영역이 작아서 서로 프로세스간에 경합이 발생하고 있음을 의미합니다.           SQL> SELECT sid, event, second_in_wait, state   FROM v$session_wait   WHERE event = 'log buffer space%';       SID EVENT SECOND_IN_WAIT STATE   -----------------------------------------------------   5 log buffer space 110 WAIT           V$SYSSTAT 자료사전에서 서버 프로세스가 로그정보를 저장했던 로그버퍼의 블록 수(REDO ENTRIES)와 로그버퍼의 경합으로 인해 발생한 대기상태에서 공간이 생겨 다시 로그버퍼 공간을 할당 받았던 블록 수(REDO BUFFER ALLOCATION RETRIES)를 확인할 수 있습니다. REDO BUFFER ALLOCATION RETRIES의 값은 0 이어야 하고 REDO ENTRIES 값의 1% 미만일 때 로그버퍼 영역에 대한 좋은 성능을 기대할 수 있습니다.           SQL> SELECT name, value   FROM v$sysstat   WHERE name IN ('redo buffer allocation retries', 'redo entries');       NAME VALUE   --------------------------------------------   redo entries 2015   redo buffer allocation retries 12             만약, 기준치에 적합하지 않은 결과가 나오면 리두로그 영역이 작아서 발생한 문제임으로 LOG_BUFFER 파라메터 값을 더 높게 설정해야 합니다.           $ cd $HOME/dbs $ vi init<SID>.ora   LOG_BUFFER = 8192 ß 이전 값 보다 더 크게 설정해야 합니다.   :wq!                 인덱스 생성시 NOLOGGING절을 적용한다.         사용자가 테이블을 생성하고 데이터를 입력, 수정, 삭제하면 트랜잭션에 의해 발생한 모든 변경 전, 변경 후 정보가 로그버퍼 영역에 저장되는데 이러한 방법을 로깅모드(LOGGING)라고 합니다. 테이블, 인덱스를 생성할 때 NOLOGGING 키워드를 사용하면 생성 후 발생하는 모든 트랜잭션의 로그정보가 로그버퍼 영역에 저장되지 않습니다. 만약, 해당 테이블의 데이터가 다른 시스템 또는 다른 데이터베이스로부터 이동된 테이블이거나 언제든지 복구가 가능한 테이블이라면 LOGGING 모드로 데이터베이스를 사용하는 것보다 NOLOIGGING 모드로 사용하는 것이 로그버퍼 영역을 적게 사용하기 때문에 로그버퍼 영역에 대한 경합 현상을 최소화시킬 수 있습니다. 인덱스는 테이블을 통해 언제든지 만들 수 있기 때문에 NOLOGGING모드로 만드는 것이 좋은 성능에 도움이 될 수 있습니다. 다음 예제를 따라 해 보세요. EMP10 테이블을 NOLOGGING 키워드로 생성하고 다시 LOGGING 모드로 바꿔보십시오. 그리고, I_EMP10 인덱스를 NOLOGGING 모드로도 생성해 보십시오.             SQL> CONNECT scott/tiger SQL> CREATE TABLE emp10 (no NUMBER, name VARCAHR2(10))   NOLOGGING;                   SQL> ALTER TABLE emp10 LOGGING; SQL> CREATE INDEX I_emp10 ON emp10 NOLOGGING;       앞에서도 언급되었듯이 테이블을 NOLOGGING 모드로 설정할 때는 데이터의 유형과 복구 전략에 대한 충분한 고려를 한 후 결정해야 하며, 인덱스에 대해선 자주 변경이 발생하는 테이블에 대해 적용한다면 INSERT, UPDATE, DELETE 작업 시 보다 빠르게 변경작업을 수행할 수 있을 것 입니다. 만약, 데이터베이스에 문제가 발생하여 복구작업을 수행해야 한다면 인덱스의 경우에는 재 생성하는 것이 복구이기 때문에 반드시 LOGGING 모드일 필요가 없습니다.