DATABASE 일일 점검 리스트

 카페 > ProDBA | jams
 http://cafe.naver.com/prodba/15608

< 일일 CECKLIST > <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><?xml:namespace prefix = o />

 

l DATABASE

 

1.1   매일 alertSID.log 화일의 내용과 trace file의 내용을 check

 - 이 화일에서 internal error나 다른 oracle error들을 알수 있다.

이 화일의 내용은 무한히 늘어나므로 이 화일의 directory space도 조절할 필요가 있다.

 

1.2 alerSID.log화일이나 trace 화일 일정 크기 이상이 되면 backup

- alertSID.ora는 무한히 커지므로 적당한 양만큼 bacup을 받아라. 이 화일로 장애 발생의 유추가 가능하므로 필요하다.

 

1.3 *_dump_dest의 free space여부를 항상 확인

- InitSID.ora이나 configSID.ora에 *_dump_dest가 설정되어 있다.

 

1.4 각 tablespace에 free space의 fragmentation이 일어났는지 확인

- fragmentation이 많이 일어나고 free space는 많이 존재하지 않는다면 하나의 data file을 첨가하라.fraementation도 높고 free space와 disk space가 거의 존재하지 않는다면 table들과 free space를 각각 연속적으로 연결이 되도록 backup/export를 받은 후 다시 drop/import를 하고 재구성한다.

 

1.5 각 tablespace에 free space를 생성되는 속도를 확인

- 즉 database의 성장 속도를 확인하여 space 부족으로 생길 수 있는 DB가 hang이 걸리는 문제를 미리 대비할 수 있도록 하라.

 

2 CONTROL FILE

 

2.1 매일 밤 hot backup을 받아라. (ARCHIVE경우)

 

3 Online Redo Log File

 

3.1 V$LOG를 사용해서 invalid하거나 stale 상태를 check하라.

- INVALID log file error는 I/O error로서 alert.log에 기록되지 않으며 alert.log file을 분석함으로써탐지가 가능하다. STALE은 shutdown abort전에 쓰여지고 있는 log가 완전하지 않거나 그log에 대해 걸려있는 write 상태가 알 수 없는 것일 때에 생성된다. 이것도 역시 alert.log 화일에 기록되지 않는다.

이런 현상이 자주 일어나면 hardware의 문제를 가리키는 것일 수도 있다.

 

3.2 log switch interval을 자주 check하라.

- log switch interval은 위의 time의 차이를 계산하면 알 수 있다.

Log Switch가 너무 자주 발생하면 혹시 hot backup 상태로 두고 있는 화일이 있는지 확인 하라.

 

3.3 checkpoint 간격을 자주 확인

- 권할 만한 checkpoint의 간격은 매10에서 15분 정도이다.이 checkpoint의 간격은 Background process가 죽어서 instance가 abort되는 극한 상황에서 database를 살리고 잠깐의 시간 동안crash recovery를 할 때 반영된다.위의 간격을 조절하려면 database에서 checkpoint interval setting 또는 checkpoint_timeout을 조절함에 의해 가능하다.checkpoint_timeout을 0으로 그리고checkpoint_interval을 online redo log file의 크기보다 크게 두면 checkpoint는 log switch가 일어날때 일어난다.

- 잦은 checkpoint는 crash recovery의 기간은 줄여주나 dirty buffers를 자주 쓰는 것과 file headers를 자주 update하는데 드는 overhead가 발생한다.

 

4 Rollback Segment tablespace

 

4.1 Rollback Segment가 online이 되어있는지 확인

- 어떤 rollback segment는 의도적으로 offline이 되어있을 수 있다.

예를 들면 rollbacksegment를 가진 datafile에 문제가 발생시 등에서다. 이런 경우의 원인을 조사하라.

 

4.2 ORA-1555 error가 생성되는지 여부를 확인

- Database는 여전히 사용가능하며 application error가 일어날 수도 있다.

 

4.3 ORA-1538,1551,1552,1553,1554,1555,1556,1557,1558,1559,1562를 check하라.

- 위의 error는 extent를 할당할 수 없거나 tablespace fragmentation이 일어나는 경우에 나타난다.위의 error가 발생해도 database는 여전히 사용이 가능하나 application errors가 일어날 수 있다.

- 이 경우datafile을 더함으로써 많은 space를 추가하거나 더욱 큰 rollback segments를 추가하여더 큰 transaction을 다룰 수 있도록 재구성하라.

 

5 Archived Redo Logs (ARCHVIE LOG MODE ONLY)

 

5.1 archive file이 생성되는 destination에 여유 공간이 있도록 유지하라.

- disk에 여유공간이 없어 archive log를 write할 수 없어서 DB가 hang이 걸림을 방지하기 위해서 필수적이다.archive destination에 freespace가 특정 threshold이상이면 alarm하게 함으로써 수시 점검이 가능하도록 하여야 한다

 

5.2 archived log file을 특정 threshold에 도달할 때마다 backup을 받아라.

- Archived redo log file의 갯수는 log file의 크기와 redo의 양에 의해 달려있다. 그리고 redo의 양은 transaction의 비율과 연관성이 있다. 위의 양에 따라 더 자주backup을 받을 수 있다. backup을 받을 때 archiver가 완전이 다 쓴 archived redo log file만을 받도록 해야 한다.

 

5.3 Archived redo log file의 sequence number가 순차적인지 확인

- Archive file에 이름이 명명되어질 때 archived log file은 log sequece가 주어지도록 되어 있다.그러므로 log switch가 일어날 때마다 sequence number는 하나씩 증가된다.

그러나,OPS의 경우에는 thread number가 함께 명명되어짐을 잊지 말아야 한다.

 

5.4 ARCH process가 움직이는지를 자주 확인하라

- OS상에서 ARCH process가 움직이는지 확인함으로써 ARCH process가 움직이지 않아서DB가 hang이 걸리는 문제를 막을 수 있다.

 

5.5 alert.log에 Archive log들에 관한 error가 있는지 확인

- 위의 화일은 대걔 $ORACLE_BASE/admin/$ORACLE_SID/bdump에 존재하거나 initSID.ora (parameter file)내의 *_dump_dest방향을 참조하라.

 

6 OS detection

 

6.1 Disk failure나 controller의 이상이 있는지 항상 확인

 

6.2 OS mirroring이 되고 있는지 항상 확인