init<SID>.ora

에보면

log???_interval파라미터를 늘리시면 됩니다.



그리고 다음

SQL> select name,value

2 from v$sysstat

3 where name in('redo buffer allocation retries','redo log space requests',

4 'redo entries');

NAME VALUE

----------------------------------- ------

redo entries 78 -> redo log buffer를 얼만큼 사용했나



redo buffer allocation retries 0 -> 내가 쓰려는 공간이 아직 disk에 쓰이지 않아

기다리는 통계정보

redo log space requests 0 -> 0이 아니면 혹시 archive log file에 full 있나 확인

======================================================================
===========================================



* LGWR가 freeing buffer를 하는데 느려지는 현상 monitor & tuning



- redo log file에 경합이 있는지(log files 의 i/o 여러 disk에서 동시에 발생하도록)

- v$system_event에 log file switch completion에 wait가 있는지.

있다면 redo log file size를 늘리자

SQL> select event,total_waits,time_waited,average_wait

2 from v$system_event

3 where event like 'log file switch completion%';

- DBWn가 끝나지 않아 Redo log file의 spining을 위해 LGWR가 waiting

-- redo log group의 size와 수를 확인해라...(중요)

-- alert.log file을 보면 spining시 "CHECKPOINT NOT COMPLETE" 가 자주 발생(2~3분마다)

-- 다음과 같이 v$system_event 를 확인해도됨

SQL> select event,total_waits,time_Waited, average_wait

2 from v$system_event

3 where event like 'log file switch (check%';

-- 다음 parameter 확인

SQL> show parameter log_checkpoint



NAME TYPE VALUE

------------------------------------ ------- ------------------------------

log_checkpoint_interval integer 10000

log_checkpoint_timeout integer 1800

log_checkpoints_to_alert boolean FALSE

- archiver가 redo log를 archived redo logfile에 쓰지 않아 LGWR가 기다리는경우

-- archive device가 full이 아닌지 확인

-- redo log group 을 추가

-- 다음과 같이 v$system_event 를 확인

SQL> select event,total_waits,time_Waited, average_wait

2 from v$system_event

3 where event like 'log file switch (arch';

-- ARCn process가 바쁠때 LGWR가 새로운 ARCn process를 띄우도록 다음 parameter 설정

log_archive_max_processes = n -> n개 만큼 까지 ARCn process를 띄우면서 작업



-- data block, redo log block이 깨졌는지 안깨졌는지 확인하는 mechanism인

db_block_checksum parameter가 true로 되어있는지 확인



======================================================================
===========================================



* Cache Hit Ratio : 이것 역시 db startup 이후 어느정도 안정되게 사용한 후 계산해야 맞다.



SQL> select 1-(phy.value / (cur.value+con.value)) " Cache Hit Ratio"

2 from v$sysstat cur, v$sysstat con, v$sysstat phy

3 where cur.name = 'db block gets'

4 and con.name = 'consistent gets'

5 and phy.name = 'physical reads';



Cache Hit Ratio

----------------

.95751146 > 90%



위에서 db block gets + consistent gets = logical gets 이므로

1-(physical gets / logical gets) 가 cache hit ratio이다.



* Data나 application Design에 따라, data를 access하는 방법에 따라 많이 차이가 나는데

예를 들면 full table scan 같은 경우에는 dirty buffer가

MRU end쪽으로 가는게 아니라 Memory에서 빨리 내리려는 목적으로 LRU end 쪽으로 간다.

(특히 OLTP성 업무와는 달리 DW성 없무는 장기간 full table scan을 해야 하므로 hit ration보다는

I/O에 point를 두고 tuning을 한다.)



DB_BLOCK_BUFFERS를 늘리고 속도를 test해 보아 효과가 없을 경우에는 반복적으로 할 필요없이

답이 아니다.