Overload의 제거
원문: http://www.dba-oracle.com
오라클 10g
사용된 SQL이 최적화되지 않았다면, 일반적인 원인은 다음과 같다.
I/O 오버로드
db file sequential read, db file scattered read의 waits가 많다면, dba_hist_filestatxs뷰에서 파악될 수 있다.
'불필요한 table block 액세스, 인덱스 부재, 빈약한 CBO 통계'을 확인해본다.
SQL이 최적되었다면, 램을 추가하여 data buffer를 늘이는 것만이 유일한 해결책이다.
CPU 오버로드
64bit 오라클의 등장과 거대한 data block buffers(db_cache_size, db_keep_cache_size)의 사용으로,
데이터베이스의 병목현상은 I/O에서 CPU로 이동되고 있다.
CPU가 wait이벤트의 상위에 존재하면, data buffers에 대해 불필요한 logical I/O를 유발하는 SQL을 찾아야 한다.
만일, 과도한 파싱으로 인해 CPU가 힘들어 한다면 library cache를 살펴볼 필요가 있다.
RAM 오버로드
EM(Enterprise Manager)에는 AMM(Automatic Memory Management)라는 유틸리티가 있다.
이 놈은 적절치 않은 크기(too-small)를 가진 SGA 영역을 찾아내는데 사용될 수 있다.
(db_cache_size, shared_pool_size, pga_aggregate_target)
이 영역에 있는 램의 크기는 조절될 수 있다.
디스크정렬, 해시조인이 없으면, pga_aggregate_target의 크기를 줄여라.
library cache의 경합이 없으면, shared_pool_size의 크기를 줄여라.
디스크 I/O가 별로 없으면, db_cache_size를 줄여라.
I/O 오버로드의 파악
physical reads가 10000 이상인 모든 파일 출력
break on begin_interval_time skip 2
column phyrds format 999,999,999
column begin_interval_time format a25
select
begin_interval_time,
filename,
phyrds
from
dba_hist_filestatxs
natural join
dba_hist_snapshot
where
phyrds > 10000;
매 1시간단위로 수행된 예. 실제 수행간격은 더 작게 하는 것이 좋겠다.
SQL> @phys_reads
BEGIN_INTERVAL_TIME FILENAME PHYRDS
------------------------- ---------------------------------------- ------------
24-FEB-04 11.00.32.000 PM E:ORACLEORA92FSDEV10GSYSTEM01.DBF 164,700
E:ORACLEORA92FSDEV10GUNDOTBS01.DBF 26,082
E:ORACLEORA92FSDEV10GSYSAUX01.DBF 472,008
E:ORACLEORA92FSDEV10GUSERS01.DBF 21,794
E:ORACLEORA92FSDEV10GT_FS_LSQ.ORA 12,123
24-FEB-04 12.00.32.000 PM E:ORACLEORA92FSDEV10GSYSTEM01.DBF 164,700
E:ORACLEORA92FSDEV10GUNDOTBS01.DBF 26,082
--------------------------------------------------------------------------------
|
This article comes from dbakorea.pe.kr (Leave this line as is)
|
