CHECKLIST에 대한 개요
모든 DBA는 ORACLE이 안정적으로 운영되도록 하고, 문제발생시 그 원인을 찾아내어 신속히 대처해야 할 업무를 가지고 있다. 이것을 위해서는 사전에 발생할 수 있는 문제들이 어떠한 것이 있는지 파악하고 있어야 하며, 일단 문제가 발생하였을 경우 ORACLE 운영환경을 점검하여 빠른 시간 내에 문제를 해결할 수 있어야 한다.
본 문서는 ORACLE 운영중에 점검해야 할 다양한 항목들에 대한 checklist들을 제시하고 있다. Checklist에서는 크게 DATABASE 전체와 DATABASE를 구성하는 FILE 및 TABLESPACE 종류별로 BACKUP, CONFIGURATION, MONITORING 등의 측면을 구분하여 각각 점검할 사항들을 다루고 있다. 문서상에서 밑줄로 나타난 부분들은 특히 주의해서 점검해야 할 사항들이다.
각 구성요소별 점검사항들을 BACKUP, CONFIGURATION, MONITORING 등의 측면에서 살펴보고, 이것을 업무에 적용함으로써 ORACLE 운영과 문제상황에 대해 효과적으로 대처할 수 있으리라 본다.
DATABASE
Backup
q Backup 에 사용될 tape 와 같은 장비상태가 불안정하다고 판단될 때는 절대로 사용하지 말아야 한다.
q Backup된 정보는 즉시 확인할 수 있어야 한다. 어느 file이 어느 backup 위치에 있는지 바로 알 수 있어야 한다.
q 시스템 open 시점에서 backup 절차 전체에 대한 full test를 수행한 후, 그 결과를 확인하여 변경할 사항들이 있는지 확인하여야 한다.
q Backup 되는 file 이름은 날짜, 업무 등의 정보를 포함시켜서 나중에 보더라도 알기 쉽도록 지정한다.
q 3개월 단위마다 정기적으로 backup을 이용한 recovery test를 실시한다.
Configuration
q 가장 최신의 ORACLE patch들을 적용하여 시스템이 안정적으로 운영될 수 있도록 해야 한다.
q DB_FILES값의 설정에 주의해야 한다. 이 값을 초과하여 datafile을 추가 하려고 할 때는 에러가 발생하게 되고, 이러한 상황에서 DB_FILES를 변경하게 되면 DB는 shutdown후 다시 start되어야 한다.
q ENQUEUE_RESOURCES는 OS의 lock resource를 조절하는 역할을 한다. 이 값이 너무 낮게 설정되어 있게 되면 특정 application에서 time out이 발생하게 된다.
q DML_LOCKS값은 object에 대한 작업을 하는 모든 사용자를 고려하여 최대한 크게 설정한다. 이 값이 부족하게 되면 application에서 에러가 발생하게 된다.
q DB를 재생성할 경우에 대비해서 그 절차를 숙지하고 있어야 한다. 그렇지 않으면 소요 작업시간이 길어지게 된다.
Monitoring
q Alert.log 와 trace file의 내용을 점검하여 에러가 없는지, 또 archive나 checkpoint에 대한 waiting이 발생하지 않았는지 점검한다. 이 file들을 이용하여 ORACLE internal error나 다른 error 정보를 얻을 수 있다
q *_dump_dest의 free space여부를 확인한다. InitSID.ora나 configSID.ora에 *_dump_dest가 설정되어 있다. 특히 Alert log 는 계속 늘어나게 되므로 일정한 크기가 되었을 때 backup을 받고, background_dump_dest의 free space를 수시로 점검하여 space문제가 발생하지 않도록 주의한다.
q Tablespace별로 성장속도를 확인한다. 이렇게 하면 space 부족으로 발생할 수 있는 DB hang 문제를 미리 대비할 수 있게 된다.
q Utlbstat.sql/utlestat.sql으로 DB 상태를 정기적으로 점검하여 system에 대한 통계 정보를 기록해 둔다. 이 자료는 tuning을 위한 기초자료가 된다.
q 각 tablespace에 대해 fragmentation을 점검한다. fragmentation이 많이 발생하여 free space가 부족하다면 coalesce를 수행하거나 data file을 추가하도록 한다. disk space가 거의 존재하지 않는다면 export를 받은 후 다시 import를 실시한다.
q InitSID.ora file에 변경이 있을 때 마다 그 history를 기록해 둔다. 이렇게 하면 parameter의 변경으로 발생하는 문제를 대처할 수 있고, performance의 변화도 알 수 있다.
DATABASE 구성 FILE별 CHECKLIST
ORACLE DATABASE를 구성하는 file들은 control file, online redo log file, archive log file, datafile 등으로 나누어진다. 각각의 file들은 DB운영을 위해 중요한 정보들을 포함하고 있으므로 수시로 그 상태를 잘 점검하여야 한다.
CONTROL FILE
Backup
q 정기적으로 backup 받도록 한다. Cold backup일 경우는 control file자체를 복사하여 backup을 받고, DB가 운영중일 경우는 다음 command를 이용하여 file을 backup 받도록 한다.
SVRMGR> alter database backup controlfile to <file name>;
q Control file을 재생성하기 위해서는 다음 command를 사용하여 user_dump_dest에 생성되는 trace file이 필요하다. 그러므로 이 trace file을 backup 받아 두는 것은 꼭 필요한 일이다.
SVRMGR> alter database backup controlfile to trace;
q Datafile과 redo log file 의 추가나 삭제 등의 원인으로 DB에 변경사항이 있을 때마다 backup받도록 한다.
q Hot backup시 end backup이 발생할 때마다 backup을 받도록 한다.
q backup받은 file 이름에 날짜와 업무정보 등을 포함시켜 쉽게 알아볼 수 있도록 한다.
Configuration
q MAXDATAFILES 값은 예상치보다 크게 설정하여야 한다. Default 값은 platform별로 다르게 지정된다. InitSID.ora에서 DB_FILES가 크게 설정되어 있더라도 MAXDATAFILES 값이 너무 작으면, DB에서 동시에 open할 수 있는 datafile의 개수는 MAXDATAFILES 값을 넘을 수가 없게 된다. 이 값을 변경하기 위해서는 control file을 재생성해야 한다.
q 별도의 disk와 controller가 사용되도록 물리적 위치를 지정한다.
q *.ctl과 같이 알기 쉬운 이름을 사용하도록 한다.
q 최소 3개가 사용되도록 해야 한다.
q MAXLOGFILES 값을 확인하여 예상치보다 크게 설정하도록 한다.
q MAXLOGMEMBERS 값이 3이상이 되도록 설정한다.
q OPS의 경우 MAXINSTANCES값을 예상치보다 크게 설정하도록 한다.
q MAXLOGHISTORY는 저장될 log history정보의 양을 지정하므로, log file이 생성되는 추이를 파악하여 적절한 값을 지정하여야 한다.
q OS level에서 mirroring이 되어 있는지 확인하고, striping은 하지 않도록 한다.
ONLINE REDO LOG FILE
Backup
q Hot backup시에는 end backup 이후에 “archive log list” command 를 수행하여 현재 log sequence number를 먼저 확인해야 한다. 그리고나서 다음 command를 수행하여 archive를 추가로 생성한 후, 앞서 확인한 sequence number까지 archive log를 backup 받으면 된다.
SVRMGR> alter system switch log file;
q Hot backup시에는 archive log file이 backup되었으면 online redo log는 backup받을 필요가 없다.
q Cold backup시에는 restore 할 때의 실수를 방지하기 위하여 주요 DB file, 특히 archive log file과는 다른 위치에 backup을 받는다.
Configuration
q OPS일 경우 instance recovery를 위해서 log의 모든 member는 동시에 access가능하여야 한다.
q 각 group의 member들은 disk와 controller를 별도로 사용하도록 지정한다.
q Redo의 thread는 instance당 1개를 설정하여야 한다.
q Redo log group은 최소 3개 이상이 되도록 하고, 각 group들은 최소 2개 이상의 member를 가지도록 한다. 이렇게 log mirroring을 하게 되면 돌발적인 file delete상황에 대비할 수 있게 된다.
q Redo log member의 size는 checkpoint에 대한 waiting이 발생하지 않도록 충분한 크기를 지정하여야 한다. size가 너무 작을 경우에는 잦은 log switch로 인하여 recovery time이 지나치게 많이 소요될 수 있다.
q Redo log member의 size는 모두 같게 한다.
q DB file과 다른 물리적인 위치를 지정하도록 한다.
Monitoring
q Checkpoint 주기를 점검하도록 한다. 권장할 만한 checkpoint의 주기는10-15분 정도이다. LOG_CHECKPOINT_INTERVAL을 가장 큰 redo log file size보다 크게 설정하고 LOG_CHECKPOINT_TIMIEOUT을 0으로 설정하게 되면, log switch가 일어날 때마다 checkpoint가 발생하게 되므로 log file size 변경을 통해 checkpoint 주기를 조정할 수 있게 된다. 잦은 checkpoint는 crash recovery 시간은 줄여주지만, dirty buffers를 자주 사용하고 file headers를 자주 update하게 되어 overhead를 일으키게 된다.
q Log switch가 너무 자주 발생하지 않는지 점검한다. Log switch는 15분 정도 주기가 적당하다. Log Switch가 너무 자주 발생하면 v$backup을 통해 hot backup 상태인 file이 있는지도 확인한다.
q V$logfile을 통해 status를 수시로 점검한다. status가 invalid나 stale이 없는지 확인해야 한다.
ARCHIVE LOG FILE
Backup
q 모든 archive log가 빠짐없이 backup에 포함되었는지 점검한다. 또, V$LOG에서 archived, status 칼럼을 참조하여 archive가 완전이 끝난 log file을 backup받아야 한다.
q OPS일 경우에는 모든 thread에서 생성되는 archive를 전부 backup받아야 한다.
q Backup된 archive log file의 sequence number가 연속되어 있는지 확인해야 한다.
q Archive log file이 특정 threshold에 도달할 때마다 backup을 받아라. 가능하다면 매일 backup을 받는 것이 좋다.
q Backup된 archive file들은 삭제하도록 한다. 그러나 disk의 공간을 충분히 하여 최소한 하루의 archive log들은 backup을 받았더라도 삭제하지 않도록 한다. 이것은 장애시에 recovery시간을 줄이는 역할을 할 수 있다.
q Archived log file의 개수는 log file의 크기와 redo의 양에 달려있다. 그리고 redo의 양은 transaction의 양과 연관되어 있다. 이러한 환경을 고려하여 backup의 빈도를 결정하도록 한다.
q Backup 위치별로 그 속에 포함된 log가 어느 기간동안 생성된 것인지에 대한 정보를 기록해 두어야 한다.
q Archive log 생성속도와, file의 backup 속도에 대해 알고 있어야 한다.
q Main이 되는 backup 장비에 문제가 있을 것에 대비하여 즉시 사용가능한 대체장비를 확보하고 있어야 하며, 이 대체장비는 backup script에 반영되어 있어야 한다.
Configuration
q DB 가 ARCHIVELOG mode로 운영중인지 확인한다. 이것을 위해서는 다음 command를 사용할 수 있다.
SVRMGR> archive log list;
또는
SVRMGR>select log_mode from v$database;
q Automatic archival이 enable로 설정되어 있는지 점검한다. DB가 startup이 되기 전이라면 initSID.ora에 LOG_ARCHIVE_START=TRUE를 설정하고, startup이후에는 다음 command를 사용하도록 한다.
SVRMGR> alter system archive log start;
q 생성되는 archive file 의 위치와 file 이름 format을 알아보기 쉽도록 지정한다. 이것은 initSID.ora에서 LOG_ARCHIVE_DEST와 LOG_ARCHIVE_FORMAT을 통해 지정할 수 있다. LOG_ARCHIVE_FORMAT= "LOG%s_%t.ARC"으로 설정할 경우 %s는 log sequence number, %t는 thread number를 의미한다. 특히 OPS인 경우 %t를 설정하여 thread별로 생성되는 archive를 구별하여 관리하도록 한다.
q Archive되는 위치가 disk인지 확인한다. Tape에서 disk로 옮기는 시간을 줄여서 recovery time을 단축할 수 있다. 그러나 tape에도 archive를 copy해 두도록 한다.
q Online redo log와는 다른 disk와 controller를 사용해야 한다.
q DB file과는 다른 disk와 controller를 사용해야 한다.
q OS level에서 mirror가 되도록 하고, striping은 하지 않도록 한다.
Monitoring
q Archive file이 생성되는 위치에 여유 공간이 있는지 확인해야 한다. Disk에 여유공간이 없어서 archive log를 생성하지 못하는 경우에는 DB hang이 발생하게 된다. Archive 위치에 여유공간이 얼마 남지 않았을 경우 alert message를 발생시키도록 하는 내용을 backup script에 포함시킨다.
q Archive와 관련된 에러가 발생하지 않았는지 Alert log를 점검한다.
q Archived log file의 sequence number가 순차적인지 확인한다. Log switch가 일어날 때마다 sequence number는 하나씩 증가된다.
q DB가 ARCHIVELOG mode로 작동중인지 확인해 본다. 만약 archive log mode가 아니라면 다음과 같은 과정을 통해 mode를 변경할 수 있다.
|
SVRMGR>connect internal SVRMGR> shutdown SVRMGR>startup mount SVRMGR>alter database archivelog; |
q ARCH process가 움직이는지를 자주 확인한다. 이렇게 하면ARCH process가 움직이지 않아서 DB가 hang이 걸리는 문제를 막을 수 있다.
TABLESPACE 별 CHECKLIST
ORACLE DATABASE를 구성하는 tablespace들에는 system tablespace, rollback segment tablespace, data tablespace, temporary tablespace 등이 있다. 각 tablespace는 data를 저장하는 논리적인 공간이며, 앞에서 다룬 OS상의 DB 관련 file들과 긴밀하게 연관되어 있다.
SYSTEM TABLESPACE
Monitoring
q Free space를 수시로 점검한다.
q Extents의 개수가 MAXEXTENTS/2 지점에 이르지 않았는지 확인한다.
q Tablespace의 size가 적정수준인지 확인한다. 일반적인 system tablespace의 size는 30-50M이다.
q 일반사용자의 object나 temporary segment가 포함되지 않았는지 점검한다.
q 일반사용자에게 사용권한을 부여하지 않도록 한다.
q System tablespace 이외의 tablespace에서 발생하는 extent는 data dictionary의 정보를 사용하게 되므로 작은 extent가 지나치게 많을 경우 System tablespace의 space도 영향을 받게 된다.
q 특별한 경우가 아니면 SYS object의 storage 절을 변경하지 않도록 한다.
q Disk mirroring을 하고 striping은 설정하지 않는다.
ROLLBACK SEGMENT TABLESPACE
Backup
q Hot backup은 DB activity가 낮은 시점에서 실시한다.
Configuration
q 알기쉬운 이름을 사용해야 한다.
q 일반적인 용도의 RBS의 size는 모두 같게 한다.
q INITIAL과 NEXT는 같게 설정한다.
q PCTINCREASE는 0으로 설정한다.
q InitSID.ora에서 UNLIMITED_ROLLBACK_SEGMENTS=FALSE를 지정하여 RBS가 unlimited extent format을 사용하는 것을 방지하도록 한다.
q OS level에서 mirroring을 하고 striping은 하지 않는다.
Monitoring
q InitSID.ora에 RBS들이 등록되어 있는지 확인한다.
q RBS가 online 상태인지 주기적으로 점검한다. 이 때 dba_rollback_segs를 이용할 수 있다.
q RBS tablespace에 다른 object가 생성되지 않았는지 점검한다.
q RBS의 크기변동률을 점검한다. V$rollstat을 이용하면 RBS가 커지거나 줄어드는 비율과 wait 정보를 확인할 수 있다.
q Free space와 fragmentation 정도를 점검한다.
q ORA-1555에러가 발생하는지 점검한다. 이 경우에 DB는 여전히 사용가능하며 application error가 발생할 수 있다. Datafile을 추가하여 space를 늘여야 한다.
q RBS당 transaction의 개수는 4-5개가 적절하다.
q Batch job에만 사용되는 큰 size의 RBS를 별도로 설정하고, OLTP용 RBS와 동시에 online되지 않도록 한다. 다음 command로 특정 RBS사용을 지정할 수 있다.
SVRMGR>set transaction use rollback segment <rbs name>;
DATA TABLESPACE
Backup
q READ-ONLY tablespace일 경우 쓰기, 읽기 권한관리에 주의하여야 한다. 이러한 변화는 controlfile이나 datafile의 backup에도 영향을 미치게 된다.
q MTTR을 만족시킬 수 있는 주기 단위로 backup을 실시한다.
q Export를 이용하여 object level에서 logical backup을 받아두어야 한다.
q Hot backup 시에는 해당 datafile의 transaction 발생을 줄여서 redo가 적게 발생되도록 해야 한다.
Configuration
q 알아보기 쉬운 이름을 사용하도록 한다.
q 서로 다른 tablespace는 다른 disk에 위치하도록 하는 것이 좋다. OS file이 분실되는 것은 곧 tablespace의 분실을 의미하므로 사전에 주의하여야 한다.
q Index tablespace는 data와 분리하여 사용하도록 한다.
q Fragmentation을 줄이기 위해서는 tablespace내에 비슷한 크기의 object들이 위치하게 하는 것이 좋다.
q OPS의 경우에는 application별로 tablespace를 분리하여 운영하는 것이 좋다.
q Autoextend는 disable로 설정하여 사용한다.
q 7.3 이전 version에서는 block size 별로 tablespace의 MAX EXTENTS의 값이 제한되어 있었다. 예를 들어 block size가 2K일 경우는 121, 8K일 경우는 505 였다. 그러나 7.3이후 version에서는 MAX EXTENTS값보다 더 많은 값을 직접 지정하는 것이 가능해 졌다. MAX EXTENTS 보다 더 큰 값을 사용하게 되면 새로운 block format이 사용된다.
q Default storage 절이나 생성되는 object에 MAXEXTENTS UNLIMTED를 사용하지 않도록 한다.
q MAXEXTENTS UNLIMITED를 설정할 수도 있으나 권장되는 설정이 아니다. UNLIMITED extent format을 사용하려면 COMPATIBLE의 값이 7.3.0이상으로 설정되어 있어야 한다.
q MAXEXTENTS UNLIMITED를 설정하는 것은 해당 tablespace의 free space 전체를 사용하게 될 위험이 있다. 또, MAXEXTENTS UNLIMITED가 사용될 경우 작은 extent의 개수가 과도하게 증가하여 drop table, truncate table작업 등을 수행할 때 space와 관련된 심각한 performance 문제를 유발할 수 있다.
q OS level에서 mirror되게 한다.
Monitoring
q 주요 object에 대해서는 정기적으로 analyze를 실시한다.
q 문제를 조기에 발견하기 위해서 object가 MAXEXTENTS/2에 도달했는지를 점검한다.
q Type이 다른 object가 동일한 tablespace에서 혼용되지 않도록 한다.
q DBVERIFY를 사용하여 정기적으로 점검해 본다.
q Null device에 export하여 logical object의 상태를 점검해 본다.
TEMPORARY TABLESPACE
Configuration
q Temp tablespace의 개수는 DB 사용자별로 1개, OPS일 경우는 instance의 개수만큼으로 생성하도록 한다.
q 7.3이상 version에서는 TEMPORARY status를 설정하도록 한다.
q PCTINCREASE 는 0으로 설정하도록 한다.
q INITIAL과 NEXT의 값은 sort_area_size의 배수로 설정한다.
q 7.3 version부터 TEMPORARY tablespace 에 생성되는 sort segment는 INITIAL값으로 tablespace의 NEXT 값을 그대로 사용하게 되고, PCTINCREASE는 0, MAXEXTENTS는 UNLIMITED로 지정된다. 따라서 temp tablespace에 생성되는 sort segments의 EXTENT 전체size는 조절할 수 없으므로 default storage 절에서 NEXT값 설정에 주의해야 한다.
q Index 생성을 위해 사용되는 temp tablespace의 size는 index data의 2배정도가 되어야 한다.
q OS level에서 mirroring을 하고 striping은 하지 않도록 한다.
Monitoring
q 일반사용자가 올바른 temp tablespace를 사용하고 있는지 확인한다.
q Tablespace 내에 일반사용자의 object가 생성되지 않았는지 점검한다.
q Tablespace가 TEMPORARY status인지 확인한다.
q MAXEXTENTS UNLIMTED로 설정된 tablesapce가 TEMPORARY segments를 위해 사용된다면, SMON이 이 segments를 clean up하는데 시간이 오래 걸리게 되어 많은 resource를 소모하게 된다. 또 shutdown 작업이 지나치게 길어질 수도 있다.
OS 및 기타 CHECK LIST
ORACLE DATABASE는 OS상에서 동작하기 때문에, 안정적인 운영을 위해서 OS의 상태를 점검하는 것은 필수적이다. 또, listener와 같은 ORACLE process들의 작동상태를 수시로 점검하여 application운영에 차질이 없도록 해야 한다.
OS
q OS에서 동시에 open할 수 있는 file의 개수가 제한이 있음을 주의해야 한다. DB에 설정되어 있는 DB_FILES나 MAXDATAFILES 값이 크더라도, DB 사용자가 동시에 open하여 사용할 수 있는 file의 개수는 이 값을 넘을 수가 없다. 사용중인 control file, redo log file, datable, alert.log, trace file들의 개수를 모두 고려하여 OS에서 동시에 open 할 수 있는 file 개수를 지정하여야 한다. 이 값을 변경하기 위해서는 DB도 down되어야 하기 때문에 운영중인 system에서는 치명적일 수 있다.
q Disk나 controller에 문제가 없는지 자주 확인하도록 한다.
q OS mirroring이 제대로 동작하고 있는지 확인한다.
기타
q SQL*NET의 상태를 확인한다. Listener의 process가 running상태인지 확인하려면 다음의 command를 사용할 수 있다.
$lsnrctl status
DBA TASK에 대한 설명
|
Task |
빈도 |
설명 |
|
Installation |
한번 |
ORACLE RDBMS을 install한다. |
|
Datafile Creation |
한번 |
적절한 tablespace들을 정의하고 disk contention을 최소화하는 방법으로, datafile들을 생성한다. OFA를 사용하는 것이 좋다. |
|
Backup/ Recovery Plan |
한번 |
Database를 위해 backup/recovery 계획을 작성한다. 그 계획대로 test를 하고, 적합지 않으면 수정해야 한다. |
|
Security Procedures |
한번 |
Role 생성, permission및 privilege 관리, user 생성과 password관리, auditing을 수행한다. |
|
Table-to-Tablespace Mapping |
한번 |
OFA를 기본으로tablespace별로 어떤 table이 저장되어야 할지 결정하고 이를 문서화한다. |
|
Table Creation |
한번 |
tablespace별로 적절한 table들을 생성한다. |
|
Physical Re-orgs |
비정기적 |
tablespace내에 있는 table들을 재정리하고 index,cluster들을 관리한다.application에 투명한 수직적인 partitioning을 하도록 한다. |
|
Performance Tuning |
비정기적 |
물리적인 layout을 가지고 문제점들을 진단한다. 안정된 DB이면 performance tuning에 필요한 performance monitoring을 한다. |
|
Exception Monitoring |
매일 |
에러정보를 보여주는 trace file과 log file들을 검사한다. |
|
Performance Monitoring |
매주 |
Database의 performance를 검사한다. |
|
Datafile Management |
비정기적 |
필요하다면 disk에 있는 datafile들을 정리한다. Tablespace를 늘이기 위해 새로운 datafile들을 생성한다. |
|
Backup/ Recovery Execution |
매일 |
online/offline backup, archive log에 대해 backup을 수행하라.복구가 필요하면 적절한 복구 계획을 수립한다. |
|
Table Modification |
비정기적 |
application의 변화로 인해 table이 변화되어야 한다면 data를 보호하면서 tables을 변경하도록 한다. |