개발은 너무해

DATABASE 일일 점검 리스트 본문

Oracle/Oracle Scrap

DATABASE 일일 점검 리스트

까칠 평생초보 2009.12.15 09:49
출처 카페 > 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 되고 있는지 항상 확인

0 Comments
댓글쓰기 폼