About DATABASE

Automatic Tuning of Undo_retention Causes Space Problems [ID 420525.1]

[PineTree] — Tue, 15 May 2012 17:24:53 +0900

Automatic Tuning of Undo_retention Causes Space Problems [ID 420525.1]

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

수정 날짜 09-FEB-2011 유형 PROBLEM 상태 PUBLISHED

In this Document
Symptoms
Cause
Solution
References

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

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 - Release: 10.2 to 10.2
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 -- fixed by patchset 10.2.0.4 and no issues on this at 11g
Symptoms
You have verified that Note 413732.1 is not applicable and the problem is not a misunderstanding in the way EXPIRED/UNEXPIRED are used and reused over time.

Look for:

1.) System (Automatic) Managed Undo
undo_management=auto in init.ora file

2.) Fixed size undo tablespace
SQL> select autoextensible from dba_data_files where tablespace_name='<current_undo_tablespace >'

returns "No" for all the undo tablespace datafiles.

3.) The undo tablespace is already sized such that it always has more than enough space to store all the undo generated within the undo_retention time, and the in-use undo space never exceeds the undo tablespace warning alert threshold (see below for the query to show the thresholds).

4.) The tablespace threshold alerts recommend that the DBA add more space to the undo tablespace:

SQL> select creation_time, metric_value, message_type,reason, suggested_action from dba_outstanding_alerts where object_name='<current_undo_ts>';

returns a suggested action of: "Add space to the tablespace"

Or,

This recommendation has been reported in the past but the condition has now cleared:
SQL> select creation_time, metric_value, message_type, reason, suggested_action, resolution from dba_alert_history where object_name='<current_undo_ts>';

5.) The undo tablespace in-use space exceeded the warning alert threshold at some point in time:

To see the warning alert percentage threshold:

SQL> select object_type, object_name, warning_value, critical_value from dba_thresholds where object_type='TABLESPACE';

To see the (current) undo tablespace percent of space in-use:
SQL> select
((select (nvl(sum(bytes),0))
from dba_undo_extents
where tablespace_name='<current_undo_ts>'
and status in ('ACTIVE','UNEXPIRED')) *100) /
(select sum(bytes)
from dba_data_files
where tablespace_name='<current_undo_ts>')
"PCT_INUSE"
from dual;

Cause
This is due to Bug 5387030 that is fixed in 10.2.0.4 patchset of RDBMS server.

Solution
Apply the patch for the Bug 5387030. Check the Oracle Support Portal for patch availability for your platform and RDBMS version.

Workaround

There are 3 possible alternate workarounds (any one of these should resolve the problem of the alerts triggering unnecessarily):

1.) Set the autoextend and maxsize attribute of each datafile in the undo ts so it is autoextensible and its maxsize is equal to its current size so the undo tablespace now has the autoextend attribute but does not autoextend:

SQL> alter database datafile '<datafile_flename>'
autoextend on maxsize <current_size>;

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the undo tablespace size, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

2.) Set the following hidden parameter in init.ora file:
_smu_debug_mode=33554432

SQL> Alter system set "_smu_debug_mode" = 33554432;

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the fixed size undo tablespace, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

3.) Set the following hidden parameter in init.ora:
_undo_autotune = false

SQL> Alter system set "_undo_autotune" = false;

With this setting, v$undostat (and therefore v$undostat.tuned_undoretention) is not maintained and the undo_retention used is the one specified in init.ora file. NOTE: This means you loose all advantages in having automatic undo management and is not an ideal long term fix.

NOTE: Even with the patch fix installed, the autotuned retention can still grow under certain circumstances. The fix attempts to throttle back how aggressive that autotuning will be. Options 2 and 3 may be needed to get around this aggressive growth in some environments.

References
NOTE:413732.1 - Full UNDO Tablespace In 10gR2

'ORACLE > ADMIN' 카테고리의 다른 글

Automatic Tuning of Undo_retention Causes Space Problems [ID 420525.1] (0)	17:24:53
Configuring the Oracle Network Environment (0)	2012/05/11
Oracle Hang 상황에서 액티브 세션 리스트 얻기 (8)	2012/01/02
오라클 버전간의 파라미터 변경사항 비교 (Oracle 9i, 10g, 11g) (0)	2011/12/28
오라클 모니터링 쿼리 (0)	2011/12/21
oracle inactive session 정리 (0)	2011/12/15

Configuring the Oracle Network Environment

[PineTree] — Fri, 11 May 2012 11:07:44 +0900

● 개요

- 추가적인 리스너를 생성할 수 있다.
- 오라클 넷 서비스를 생성할 수 있다.
- connect-time failover를 구성할 수 있다.

● 오라클 넷 서비스(Oracle Net Services)
   ◎ 정의
       : 네트워크 connection을 가능하게 하는 소프트웨어

   ◎ 전체 구조도

   ◎ 리스너에 추가하는 법

       ○ telnet으로 추가
           - 리스너가 동작중인지 확인

OS] ps -ef|grep lsnr

- linstener.ora가 있는 디렉토리로 이동 후 확인

OS] cd $ORACLE_HOME/network/admin
OS] ls

- listener.ora의 내용을 확인

OS] vi listener.ora

- 내용을 확인해보면 다음과 같다. 빨간색 부분을 추가한다.(띄어쓰기 안맞을 경우 에러 발생할 가능성이 있다.)

L1 =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora10gr2.gsedu.com)(PORT = 1521))
    )
)

SID_LIST_L1 =
(SID_LIST =
    (SID_DESC =
      (SID_NAME = orcl)
      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
      (GLOBAL_DBNAME = orcl)
    )
    (SID_DESC =
      (SID_NAME = ikdb)
      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
      (GLOBAL_DBNAME = ikdb)
    )
)

L2 =
(DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora10gr2.gsedu.com)(PORT = 1621))
    )
)

SID_LIST_L2 =
(SID_LIST =
    (SID_DESC =
      (SID_NAME = jgh_db)
      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
      (GLOBAL_DBNAME = jgh_db)
    )
)

- 리스너를 start시킨다.
기본은 1521 포트의 리스너가 start되지만 리스너를 명시해서 start, stop을 할 수 있다.

OS] lsnrctl start
OS] lsnrctl stop
OS] lsnrctl start L1
OS] lsnrctl start L2
OS] lsnrctl stop L1
OS] lsnrctl stop L2

- lsnrctl 명령으로도 가능

OS] lsnrctl
LSNRCTL> start l1
LSNRCTL> start l2

LSNRCTL> service l1
LSNRCTL> service l2

LSNRCTL> status l1
LSNRCTL> status l2
LSNRCTL> set current l2 -- 디폴트 리스너를 바꿀 수 있다.

○ Oracle Net Manager로 추가

OS] netmgr

○ Oracle Configuration Assistant로 추가

OS] netca

○ EM으로 추가

※ Server에 기본 리스너외에 추가 리스너 등록

SQL> alter system set local_listener = a -- 같은 machine내에 a리스트를 보고 등록
SQL> alter system set remote_listener = a -- 다른 machine의 리스너 등록

<tnsnames.ora>
a =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.10)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.11)(PORT = 1621))
    (CONNECT_DATA =
         (SERVER = DEDICATED)
         (SID = orcl)
    )
)

※ RAC환경에서의 설정
- SID는 중복 불가, SERVICE_NAME은 중복 가능

SERVER1 (192.168.0.10)
OS] vi initi1.ora
instance_name = i1
service_names = haha, hoho
remote_listener = .....

SERVER2 (192.168.0.11)
OS] vi initi2.ora
instance_name = i2
service_names = haha, hoho
remote_listener = .....

SERVER3 (192.168.0.12)
OS] vi initi3.ora
instance_name = i3
service_names = haha, hoho
remote_listener = .....

CLIENT
<tnsnames.ora>
sqlplus chris/chris@a                         -- a : connect identifier(=network alias, service alias)
a =
(DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.10)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.11)(PORT = 1521))
    (CONNECT_DATA =
         (SERVER = DEDICATED)
         (SERVICE_NAME = haha)
    )
)
-- connect discriptor

- haha라는 서비스명으로 접속하므로 i1이 shutdown되어 있더라도 i2로 접속이 가능
SID=i1으로 할 경우 문제가 생길 소지가 있음. SERVICE_NAME으로 하는 것이 좋음

※ instance name이 같은 서버가 있어도 도메인으로 식별 가능

instance1
instance_name = HRDB
db_domain = asia.com

instance2
instance_name = HRDB
db_domain = africa.com

※ Dedicated Server vs. Shared Server

Dedicated Server
    - 하나의 유저에 하나의 서버 프로세스가 담당.
    - sserver process당 PGA가 생긴다.

    dedicate server로 접속시 client의 tnsnames.ora설정 파일

<tnsnames.ora>
shared =
(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.122.1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 172.16.122.1)(PORT = 1621))
      (LOAD_BALANCE = yes)
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
)

Shared Server
    - 일정 갯수의 서버 프로세스를 유저서버프로세스가 공유하는 형식
    - UGA(user session data, cursor state, sort data)가 SGA내에 생김(서버 프로세스가 공유하기 위해서)
    - 아래의 파일들을 설정해주어야 함

    shared server 접속시 client의 tnsnames.ora 설정 파일

server의 파라미터 파일 설정

SQL> alter system set shared_servers = 2; -- 서버프로세스를 2개
SQL> alter system set dispatchers = '(protocol=tsp)(dispatchers=3)'; -- 디스패쳐를 3개

기타참고사항

- JDBC 드라이버
    : Java Database Connectivity의 약자. 번역기. DBMS의 벤더들이 만든다.
      oracle net을 simmulate한 것
      사용시에 오라클의 버전에 맞게 사용할 것

- 리스너가 살아있는지 확인(서버가 살아있는지 확인하는 것은 아님)
   tnsping 172.16.122.106:1521/orcl

- name resolution
: connect identifier(network alias, service alias)를 connect descriptor로 바꾸는 행위를 말한다.

- linux : oerr ora 12154 명령을 치면 에러에 대한 내용이 나옴.

- 오라클에서의 connection과 session
   - connection
      : communication path way
   - session
      : log in ~ log out

'ORACLE > ADMIN' 카테고리의 다른 글

Automatic Tuning of Undo_retention Causes Space Problems [ID 420525.1] (0)	17:24:53
Configuring the Oracle Network Environment (0)	2012/05/11
Oracle Hang 상황에서 액티브 세션 리스트 얻기 (8)	2012/01/02
오라클 버전간의 파라미터 변경사항 비교 (Oracle 9i, 10g, 11g) (0)	2011/12/28
오라클 모니터링 쿼리 (0)	2011/12/21
oracle inactive session 정리 (0)	2011/12/15

oracle RAC 10.2.0.1 -> 10.2.0.5 패치

[PineTree] — Fri, 11 May 2012 11:00:02 +0900

RAC 10g R2 patch.pdf

'ORACLE > RAC' 카테고리의 다른 글

oracle RAC 10.2.0.1 -> 10.2.0.5 패치 (0)	2012/05/11
UDP Buffer Tuning 기법 (0)	2012/05/11
RAC 에서 특정 Instance만 성능이 느린 이유 (0)	2010/04/14
RAC(OPS) 환경하에서 양쪽 Node의 archived log file을 RMAN을 사용하여 동시에 BACKUP 받는 방법 (0)	2009/02/23
Linux / FireWire 환경에 Oracle RAC 10g Release 2 Cluster 설치하기 (0)	2008/12/23
RAC Cluster/Database 구성의 검증 (0)	2008/12/23

oracle silent install

[PineTree] — Fri, 11 May 2012 10:57:25 +0900

dbworks 에서 받은 파일입니다.

Oracle Silent Install Guide.pdf

'ORACLE > INSTALL' 카테고리의 다른 글

oracle silent install (0)	2012/05/11
[ Oracle - Admin ] Linux 커널 매게변수 및 Shell Limit (0)	2012/01/10
오라 클 9.2.0.1에서 Patch 셋 올리기 (0)	2010/05/31
oracle enterprise manager 한글 버튼 깨짐 문제 (0)	2010/01/11
RAC 패치 절차 (0)	2009/12/15
Requirements for Installing Oracle 11gR2 RDBMS on RHEL (and OEL) 4 on AMD64/EM64T (0)	2009/09/07

11g 데이타베이스 에러수집방법

[PineTree] — Fri, 11 May 2012 10:54:02 +0900

OTN펌

목적 :
Oracle 11g 부터 Alert.log 와 trace file 은 새로운 형식으로 생성이 되며, 이는 ADR (Automatic Diagnotic Repository) 에 생성이 된다.
본 문서에서는 Database 에 심각한 에러가 발생한 경우, ADRCI 명령어를 이용하여 에러를 확인하고 관련된 alert.log 및 trace file 을 오라클 고객지원센터로 전송하는 방법에 대해서 설명한다.

IPS 사용법 :
ORACLE 11g 는 problem (Database 에서 발생한 에러코드)과 incident (에러가 발생한 기록)에 관련된 trace file 들을 자동으로 수집해주는 기능을 제공한다.
이 기능을 IPS (Incident Packaging Service) 라고 하며, 인터페이스로 GUI 환경과 ADRCI command 를 제공한다.
Database 에 발생한 모든 심각한 에러들은 각각의 incident 를 생성한다.
IPS 를 통해서 생성된 압축 파일은 에러에 대한 alert.log file, 모든 trace file 과 진단 정보를 포함하고 있기 때문에, 해당 error 에 대한 정보수집을 간편히 수행할 수 있다.

Database 의 에러 확인 및 관련 file을 오라클 고객지원센터로 전송하는 방법 :

1. Database 에서 발생한 심각한 에러 발생

SQL> select * from atab;
select * from atab
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 6, block # 11)
ORA-01110: data file 6: '/opt/oracle/oradata/db11g/tt.dbf'

2. ADR과 Alert.log 에서 에러를 확인한다.

ADR에서 에러를 확인하기 위하여 11g 환경의 OS prompt에서 adrci를 실행한다.

%] adrci

ADR 홈 경로를 확인한다.

adrci> show home
--> 모든 ADR HOME 을 보여준다. 확인하고자 하는 ADR HOME 을 지정한다.

adrci> set homepath <ADR HOME>

에러 코드를 problem 이라고 하며, 이를 확인하기 위해서 다음을 실행한다.

adrci> show problem

ADR Home = /opt/oracle/diag/rdbms/db11g/db11g:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 ORA 1578 18104 2009-06-01 22:06:19.501207 +10:00
1 rows fetched

Database 에 문제가 되고 있는 에러 코드를 확인할 수 있다.
이 중, 분석이 필요한 에러코드에 대하여 압축파일을 생성할 수 있다.

3. 분석이 필요한 에러의 발생 기록을 확인한다.

에러의 발생 기록들은 Incident 라고 하며, 모든 incident 는 Alert.log 에 기록된다.
각각의 incident 는 유일한 incident ID 를 가진다.

ADR 에서 'show incident' 명령을 수행하여 에러 발생 기록을 확인할 수가 있으며,
에러에 대한 problem key를 확인하기 위해서는 'show problem' 을 수행한다.

adrci> show incident -p "problem_key='ORA 1578'"

ADR Home = /opt/oracle/diag/rdbms/db11g/db11g:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
18147 ORA 1578 2009-06-01 22:02:08.805002 +10:00

동일한 problem에 대한 incidnet는 여러 건이 발생할 수 있다.

4. IPS (incident packaging service) 를 수행하여 alert.log , trace file 및 diag 정보에 대한 압축 파일 생성.

압축 파일을 생성하기 위해서는 특정 경로를 포함한 'IPS pack' 명령을 사용한다.
다음의 예는 incident 관련 file들을 /tmp directory 에 압축 파일로 생성하는 방법이다.

adrci> ips pack incident 18147 in /tmp
Generated package 9 in file /tmp/ORA1578_20090602113045_COM_1.zip, mode complete

IPS pack 의 예제)

ips pack problem 100 in /tmp
-- problem id 100 에 관련된 trace file 들을 /tmp directory 에 압축파일로 생성한다.

ips pack incident 6439 in /tmp
-- incident id 6439 에 관련된 trace file 들을 /tmp directory 에 압축파일로 생성한다.

ips pack problemkey "ORA 1578"
-- problem_key 'ORA 1578' 를 가지는 모든 problem 에 관련된 trace file 들을 현재 directory 에 압축파일로 생성한다.

ips pack seconds 8
-- 최근 8 초 이내에 발생한 incident 에 대한 압축 파일을 생성한다.

ips pack time '2007-05-01 10:00:00.00' to '2007-05-01 23:00:00.00'
-- 특정 시간대의 incident 에 대한 압축파일을 생성한다.

'IPS pack' 명령은 'IPC create' 와 'IPS generage' 명령을 일괄적으로 수행할 수 있는 명령이다.

이와 같이 생성된 압축 파일을 SR (service request)을 통해 오라클 고객지원센터로 전송하면 된다.

동영상 참조 :
IPS package 를 생성하는 방법 (동영상 자료 02:30)
(My Oracle Support 접속 필요)

참고자료 :
DOC ID : 443529.1
11g Quick Steps to Package and Send Critical Error Diagnostic Information to Support (Video)

DOC ID: 738732.1
ADR Different Methods to Create IPS Package

엮인글 주소 : http://support.dbworks.co.kr/8730/8e3/trackback

추가적으로 trace file정리시

adrci>purge -age 30

하면 됩니다.

'ORACLE > ORACLE 11G' 카테고리의 다른 글

11g 데이타베이스 에러수집방법 (0)	2012/05/11
기준선 및 개선된 계획 (0)	2009/08/25
Oracle Advanced Compression (0)	2009/04/02

UDP Buffer Tuning 기법

[PineTree] — Fri, 11 May 2012 10:49:52 +0900

오라클 매거진 2007년 가을호 발췌자료입니다.

일반적으로 RAC의 Inter-Connects의 성능과 가장 연관이 깊은것이 UDP Buffer의 크기이다. 오라클이 공식적으로 권고하는 UDP
Buffer 크기는 256K이고 대부분의 시스템에서 적절한 성능을 보장하고있다. Inter-Connect을 통해 주고 받는 Data량이 많은 경우 UDP Buffer Size를 1M~2M 정도 사용하기도 하며 Transaction에 비해 UDP Buffer Size 가 작을 경우 Packet Loss 현상이 발생할 수 있다. Packet Loss 현상이 자주 발생할 경우“gc cr block lost”,“gc current block lost”의 Oracle Wait Event가 나타난다. 이는 각 OS 별 Monitoring Tool인 nmon, topas, glance이나 Network 명령인 ifconfig, netstat 등과
Network 진단 Tool을 통해 UDP Packet Receive Error나 Dropped 된비율을 Monitoring 하도록 한다.
[oracle@rac1]$ netstat -s
Ip: ………
Tcp: …….

앞의 Network Setting 값들은 System 운영 중에 변경이 가능하며 System Rebooting 시에는 Default 값으로 초기화되므로 System Starting Script나 Kernel Level에서 값을 Settting하여 자동 적용이 되도록 한다.

고객사 장애사례

Instance Recovery 및 Reconfigure 시간을 최대 단축하는

Hidden Parameter(_imr_max_reconfig_max)와 Instance Recovery 없이 (_imr_active=false) Open 시도를 해도 두 번째 Node의 DB는 약20분 후에 Open됨.

DB Mount 상태에서 10046-level 12로 event를 걸어 DB Open하여 trace를 살펴보니 Inter-connects 간 DB Open전에 동기화를 위한 Recursive Call 시 ”global cache cr request”event와 해당 elaspsed time이 굉장히 자주 많이 발생하여 Inter-Connects 간 Network 전송속도에 문제가 있을 것으로 판단하여 OS의 Inter-Connects용 Gigabit-NIC 설
정 값을 확인해보니 100 M Full 설정이 되어 있어 1000 M Full로 변경하여 정상적으로 DB Open 및 업무가 진행이 되었다.

OS별 Default UDP Buffer Size와 조절방법(MAX:8M)
kernel	Value	Default	Command
Linex	net.core.rmem_max	131071	sysctl -w net.core.rmem_max = 8388608
Solaris	udp_max_buf	262144	ndd -set /dev/udp udp_max_buf 8388608
AIX	sb_max	1048576	no -o sb_max=8388608 (1048576, 4194304, 83388608 값 중에서만)

OS별 Default UDP Buffer Size와 조절방법(MAX:8M)
kernel	Value	Default	Command
Linex	net.core.rmem_max	131071	sysctl -w net.core.rmem_max = 8388608
Solaris	udp_max_buf	262144	ndd -set /dev/udp udp_max_buf 8388608
AIX	sb_max	1048576	no -o sb_max=8388608 (1048576, 4194304, 83388608 값 중에서만)

Tuning Inter-Instance Performance in RAC and OPS [ID 181489.1]

		수정 날짜 29-MAR-2009 유형 BULLETIN 상태 PUBLISHED

PURPOSE
-------

This note was written to help DBAs and Support Analysts Understand Inter-Instance
Performance and Tuning in RAC.

SCOPE & APPLICATION
-------------------

Real Application Clusters uses the interconnect to transfer blocks and messages
between instances. If inter-instance performance is bad, almost all database
operations can be delayed. This note describes methods of identifying and
resolving inter-instance performance issues.

TUNING INTER-INSTANCE PERFORMANCE IN RAC AND OPS
------------------------------------------------

SYMPTOMS OF INTER-INSTANCE PERFORMANCE PROBLEMS
-----------------------------------------------

The best way to monitor inter-instance performance is to take AWR or statspack
snaps on each instance (at the same time) at regular intervals.

If there are severe inter-instance performance issues or hung sessions, you
may also want to run the racdiag.sql script from the following note
to collect additional RAC specific data:

Note 135714.1
Script to Collect RAC Diagnostic Information (racdiag.sql)

The output of the script has tips for how to read the output.

Within the AWR, statspack report, or racdiag.sql output, you can use the wait
events and global cache statistics to monitor inter-instance performance. It
will be important to look for symptoms of inter-instance performance issues.
These symptoms include:

1. The average cr block receive time will be high. This value is calculated by
dividing the 'global cache cr block receive time' statistic by the
'global cache cr blocks received' statistic:

global cache cr block receive time
----------------------------------
global cache cr blocks received

Multiply this calculation by 10 to find the average number of milliseconds. In a
9.2 statspack report you can also use the following Global Cache Service Workload
characteristics:

Ave receive time for CR block (ms): 4.1

The following query can also be run to monitor the average cr block receive time
since the last startup:

set numwidth 20
column "AVG CR BLOCK RECEIVE TIME (ms)" format 9999999.9
select b1.inst_id, b2.value "GCS CR BLOCKS RECEIVED",
b1.value "GCS CR BLOCK RECEIVE TIME",
((b1.value / b2.value) * 10) "AVG CR BLOCK RECEIVE TIME (ms)"
from gv$sysstat b1, gv$sysstat b2
where b1.name = 'global cache cr block receive time' and
b2.name = 'global cache cr blocks received' and b1.inst_id = b2.inst_id ;

The average cr block receive time or current block receive time should typically be
less than 15 milliseconds depending on your system configuration and volume, is the
average latency of a consistent-read request round-trip from the requesting instance
to the holding instance and back to the requesting instance.

Please note that if you are on 9i and the global cache current block receive
time is abnormally high and the average wait time for the 'global cache null
to x' wait event is low (under 15ms) then you are likely hitting bug 2130923
(statistics bug). This is a problem in the way statstics are reported and does
not impact performance.

More about that issue is documented in the following note:

Note 243593.1
RAC: Ave Receive Time for Current Block is Abnormally High in Statspack

2. "Global cache" or "gc" events will be the top wait event. Some of these wait
events show the amount of time that an instance has requested a data block for a
consistent read or current block via the global cache.

When a consistent read buffer cannot be found in the local cache, an attempt is
made to find a usable version in another instance. There are 3 possible outcomes,
depending on whether any instance in the cluster has the requested data block
cached or not:

a) A cr block is received (i.e. another instance found or managed to produce the
wanted version). The "global cache cr blocks received" statistic is incremented.
b) No other instance has the block cached and therefor the requesting instance
needs to read from disk, but a shared lock will be granted to the requestor
The "global cache gets" statistic is incremented
c) 9i RAC+ Only --> A current block is received (the current block is good enough for
the query ). The " global cache current blocks received" statistic is
incremented.

In all three cases, the requesting process may wait for global cache cr request.
The view X$KCLCRST (CR Statistics) may be helpful in debugging 'global cache cr
request' wait issues. It will return the number of requests that were handled for
data or undo header blocks, the number of requests resulting in the shipment of a
block (cr or current), and the number of times a read from disk status is returned.

It should be noted that having 'global cache' or 'gc' waits does not always
indicate an inter-instance performance issue. Many times this wait is
completely normal if data is read and modified concurrently on multiple
instances. Global cache statistics should also be examined to determine if
there is an inter-instance performance problem.

3. The GES may run out of tickets. When viewing the racdiag.sql output
(Note 135714.1) or querying the gv$ges_traffic_controller or
gv$dlm_traffic_controller views, you may find that the TCKT_AVAIL shows '0'. To
find out the available network buffer space we introduce the concepts of tickets.
The maximum number of tickets available is a function of the network send buffer
size. In the case of lmd and lmon, they always buffer their messages in case of
ticket unavailability. A node relies on messages to come back from the remote
node to release tickets for reuse.

4. The above information should be enough to identify an inter-instance performance
problem but additional calculations can be made to monitor inter-instance
performance can be found in the documentation.

IDENTIFYING AND RESOLVING INTER-INSTANCE PERFORMANCE PROBLEMS
-------------------------------------------------------------

Inter-Instance performance issues can be caused by:

1. Under configured network settings at the OS. Check UDP, or other network protocol
settings and tune them. See your OS specific documentation for instructions on how
to do this. If using UDP, make sure the parameters relating to send buffer space,
receive buffer space, send highwater, and receive highwater are set well above the
OS default. The alert.log will indicate what protocol is being used. Example:

cluster interconnect IPC version:Oracle RDG
IPC Vendor 1 proto 2 Version 1.0

Changing network parameters to optimal values:

Sun (UDP Protcol)
UDP related OS parameters can be queried with the following command:
ndd /dev/udp udp_xmit_hiwat
ndd /dev/udp udp_recv_hiwat
ndd /dev/udp udp_max_buf
Set the udp_xmit_hiwat and udp_recv_hiwat to the OS maximum with:
ndd -set /dev/udp udp_xmit_hiwat <value>
ndd -set /dev/udp udp_recv_hiwat <value>
ndd -set /dev/udp udp_max_buf <1M or higher>
IBM AIX (UDP Protocol)
UDP related OS parameters can be queried with the following command:
no -a
Set the udp_sendspace and udp_recvspace to the OS maximum with:
no -o <parameter>
Linux (edit files)
/proc/sys/net/core/rmem_default
/proc/sys/net/core/rmem_max
/proc/sys/net/core/wmem_default
/proc/sys/net/core/wmem_max
HP-UX (HMP Protocol):
The file /opt/clic/lib/skgxp/skclic.conf contains the Hyper Messaging Protocol (HMP)
configuration parameters that are relevant for Oracle:
- CLIC_ATTR_APPL_MAX_PROCS Maximum number of Oracle processes. This includes
the background and shadow processes. It does not
include non-IPC processes like SQL client processes.
- CLIC_ATTR_APPL_MAX_NQS This is a derivative of the first parameter; it will
be removed in the next release. For the time being, this should be set to
the value of CLIC_ATTR_APPL_MAX_PROCS.
- CLIC_ATTR_APPL_MAX_MEM_EPTS Maximum number of Buffer descriptors. Oracle
seems to require about 1500-5000 of them depending on the block size (8K or
2K). You can choose the maximum value indicated above.
- CLIC_ATTR_APPL_MAX_RECV_EPTS Maximum number of Oracle Ports. Typically,
Oracle requires as many ports as there are processes. Thus it should be
identical to CLIC_ATTR_APPL_MAX_PROCS.
- CLIC_ATTR_APPL_DEFLT_PROC_SENDS Maximum number of outstanding sends. You
can leave it at the default value of 1024.
- CLIC_ATTR_APPL_DEFLT_NQ_RECVS Maximum number of outstanding receives on a
port or buffer. You can leave it at the default value of 1024.
HP-UX (UDP Protcol):
Not tunable before HP-UX 11i Version 1.6
For HP-UX 11i Version 1.6 or later be able to use below command to set socket_udp_rcvbuf_default & socket_udp_sndbuf_default
ndd -set /dev/udp socket_udp_rcvbuf_default 1048576
echo $?
ndd -set /dev/udp socket_udp_sndbuf_default 1048576
echo $?
HP Tru64 (RDG Protocol):
RDG related OS parameters are queried with the following command:
/sbin/sysconfig -q rdg
The most important parameters and settings are:
- rdg_max_auto_msg_wires - MUST be set to zero.
- max_objs - Should be set to at least <# of Oracle processes * 5> and up to
the larger of 10240 or <# of Oracle processes * 70>. Example: 5120
- msg_size - Needs to set to at least <db_block_size>, but we recommend
setting it to 32768, since Oracle9i supports different block sizes for each
tablespace.
- max_async_req - Should be set to at least 100 but 256+ may provide better
performance.
- max_sessions - Should be set to at least <# of Oracle processes + 20>,
example: 500
HP TRU64 (UDP Protocol):
UDP related OS parameters are queried with the following command:
/sbin/sysconfig -q udp
udp_recvspace
udp_sendspace

2. If the interconnect is slow, busy, or faulty, you can look for dropped packets,
retransmits, or cyclic redundancy check errors (CRC). You can use netstat commands
to check the networks. On Unix, check the man page for netstat for a list of options.
Also check the OS logs for any errors and make sure that inter-instance traffic is
not routed through a public network.

With most network protcols, you can use 'oradebug ipc' to see which interconnects
the database is using:

SQL> oradebug setmypid
SQL> oradebug ipc

This will dump a trace file to the user_dump_dest. The output will look something
like this:

SSKGXPT 0x1a2932c flags SSKGXPT_READPENDING info for network 0
socket no 10 IP 172.16.193.1 UDP 43749
sflags SSKGXPT_WRITESSKGXPT_UP info for network 1
socket no 0 IP 0.0.0.0 UDP 0...

So you can see that we are using IP 172.16.193.1 with a UDP protocol.

3. A large number of processes in the run queue waiting for CPU or scheduling
delays. If your CPU has limited idle time and your system typically processes
long-running queries, then latency may be higher. Ensure that LMSx processes get
enough CPU.

4. Latency can be influenced by a high value for the DB_FILE_MULTIBLOCK_READ_COUNT
parameter. This is because a requesting process can issue more than one request
for a block depending on the setting of this parameter.

ADDITIONAL RAC AND OPS PERFORMANCE TIPS
---------------------------------------

1. Poor SQL or bad optimization paths can cause additional block gets via the
interconnect just as it would via I/O.

2. Tuning normal single instance wait events and statistics is also very
important.

3. A poor gc_files_to_locks setting can cause problems. In almost all cases
in RAC, gc_files_to_locks does not need to set at all.

4. The use of locally managed tablespaces (instead of dictionary managed) with
the 'SEGMENT SPACE MANAGEMENT AUTO' option can reduce dictionary and freelist
block contention. Symptoms of this could include 'buffer busy' waits. See the
following notes for more information:

Note 105120.1
Advantages of Using Locally Managed vs Dictionary Managed Tablespaces

Note 103020.1
Migration from Dictionary Managed to Locally Managed Tablespaces

Note 180608.1
Automatic Space Segment Management in RAC Environments

Following these recommendations can help you achieve maximum performance in
your clustered environment.

RELATED DOCUMENTS
-----------------
Oracle Documentation
Note 188135.1 - Documentation Index for Real Application Clusters and Parallel Server
Note 94224.1 FAQ- STATSPACK COMPLETE REFERENCE
Note 135714.1 - Script to Collect RAC or OPS Diagnostic Information
Note 157766.1 - Sessions Wait Forever for 'global cache cr request' Wait Event...
Note 151051.1 - PARAMETER:CLUSTER_INTERCONNECTS
Note 120650.1 - Init.ora Parameter "OPS_INTERCONNECTS" Reference Note

'ORACLE > RAC' 카테고리의 다른 글

oracle RAC 10.2.0.1 -> 10.2.0.5 패치 (0)	2012/05/11
UDP Buffer Tuning 기법 (0)	2012/05/11
RAC 에서 특정 Instance만 성능이 느린 이유 (0)	2010/04/14
RAC(OPS) 환경하에서 양쪽 Node의 archived log file을 RMAN을 사용하여 동시에 BACKUP 받는 방법 (0)	2009/02/23
Linux / FireWire 환경에 Oracle RAC 10g Release 2 Cluster 설치하기 (0)	2008/12/23
RAC Cluster/Database 구성의 검증 (0)	2008/12/23

세마포어에 대하여

[PineTree] — Fri, 11 May 2012 10:43:34 +0900

* 유닉스는 내부 프로세스 간의 커뮤니케이션을 위하여 세마포어를 사용한다.
세마포어는 유닉스에 의해서 증감되는 정수(integer) 값 이다. 하나의
세마포어에 대해서 하나의 프로세스만이 작업을 할 수 있도록 하여 프로세스
간의 동기화를 유지하는데 이용된다. 다른 프로세스가 사용 중인 세마포어를
이용하고자 하는 프로세스는 세마포어의 상태가 증가되거나 0 이 될 때 까지
기다리게 된다. (옵션에 따라 다를 수 있다).

* 유닉스에서의 세마포어는 한개 씩 이용되는 경우는 거의 없기 때문에 보통
세마포어 집합으로 관리된다. 유닉스 커널이 설정될 때 시스템에서 사용
가능한 세마포어의 최대 갯수와 세마포어 집합 당 최대 세마포어 갯수 및 할당
가능한 세마포어 집합의 최대 갯수가 설정된다. 이 값들은 유닉스 커널을 다시
만들고 시스템을 리부팅 하여야만 변경이 가능하다.

<오라클과 세마포어>

오라클은 백그라운드 프로세스들 간의 Concurrency 를 조절하기 위하여
세마포어를 사용한다. 그리고 Fast(Shared Memory) Driver 가 사용되는 경우
유저 프로세스와 쉐도우 프로세스 간의 Two-Task Communication 에도
사용된다.

<사용 중인 세마포어>

현재 시스템에 할당된 세마포어를 확인하는 명령은 다음과 같다.

# ipcs -sb

이 명령은 할당된 모든 세마포어 집합과 ID Number, Owner, 각 집합의
세마포어 수 등을 보여준다. 때때로 비정상적으로 종료된 오라클 프로세스에
의해서 점유된 리소스가 릴리스 되지 않고 남아 있는 경우가 있다. 만약,
오라클이 Shutdown 상태인데도 불구하고 ipcs -sb 를 통해서 보았을 때
오라클이 점유한 세마포어가 사용중으로 나온다면 그것들을 IPCRM명령으로
Free 시켜야 한다.
즉, 오라클이 할당한 세마포어 집합에 대하여

#ipcrm -s ID (ID는 ipcs 에서 출력됨)

명령으로 릴리스 시킨다. 아니면 시스템을 리부팅 하여도 된다.

<데이타베이스의 기동>

오라클은 백그라운드 프로세스에 필요한 모든 세마포어를 데이타베이스
기동시에 할당한다. init<SID>.ora 화일의 Processes 파라미터는 오라클에서
할당할 최대 세마포어 갯수를 결정한다.

?가장 흔하게 발생하는 에러는 데이타베이스 기동시에 나타나는 다음과 같은
에러이다.

ORA-7279 : spcre:semget error, unable to get first semaphore set

시스템은 한 집합내에 가장 많은 세마포어를 가진 것이나 Processes 변수에
의해 설정되는 세마포어 갯수 중 적은 값을 가진 첫번 째 세마포어 집합을
할당하려고 한다. 만약, 시스템에 설정된 세마포어가 부족하거나, 세마포어가
이미 너무 많이 사용중이거나, 사용중이지 않은 세마포어 집합이 세마포어를
너무 많이 갖고 있는가를 체크해 보고 그렇지 않다면 시스템에 충분한
세마포어를 할당하도록 한다.

?설정된 세마포어가 없거나 모든 세마포어가 이미 할당된 상태라면 다음과
같은 에러가 발생한다.

ORA-7251 : spcre:semget error, could not allocate any semaphores

?첫번째 세마포어 집합이 할당되었지만 두번째 세마포어를 할당받지 못하면
다음과 같은 에러가 발생한다.

      ORA-7252 : spcre:semget error, could not allocate semaphores

죽어있는 오라클 프로세스에 의해서 세마포어가 점유되어 있는가를 확인하고
만약 그런 문제가 아니라면 더 많은 세마포어를 할당함으로써 문제를 해결할
수 있다.

    <shutdown abort>

Shutdown abort 명령이 내려지면 사용자 Process가 끝나기를 기다리지 않고
오라클 백그라운드 프로세스는 죽게되고 그것에 의해서 점유된 세마포어는
Release 된다. 사용자는 세마포어를 늘리거나 줄여서 데이타베이스에
작업을요구할 때야 비로소 데이타베이스가 Shutdown 되었음을 알게 된다. 이
때 사용자에 의한 세마포어 변경 요구는 실패하게 되며 유저 프로세스와
오라클 Shadow Process도 함께 죽게 된다. 그러면서 다음과 같은 에러가
발생한다.

       ORA-7264 : spwat:semop error, unable to decrement semaphore
       ORA-7265 : sppst:semop error, unable to increment semaphore

DEC RISC Ultrix, MIPS machine 같은 MIPS RISC 기반의 유닉스 시스템의
경우에는 오라클은 Startup시에 Latching을 위하여 별도의 세마포어를
할당한다. 오라클은 이 때 할당된 세마포어를 사용자가 데이타베이스에 접속할
때 Latch 로 사용한다. 프로세스가 죽게되면 프로세스에 의해서 변경된
세마포어는 원래의 상태로 되돌아 간다. 따라서 접속하는 모든 프로세스는 Undo
Structure를 할당할 수 있어야 하는데 Undo Structure가 충분하지 못하면
다음과 같은 에러가 발생한다.

ORA-9702 : sem_acquire: cannot acquire latch semaphore

해결방법은 Undo Structure가 사용가능할 때까지 기다리든지 시스템의 Undo
Structure 의 최대값(SEMMNU)를 늘리면 된다.

Fast Driver에 의해서 데이타베이스에 접속되는 경우에는 Shared Memory
Buffer에 대한 사용허가를 관리하기 위하여 세마포어가 사용된다. 이 때 하나의
접속되는 세션마다 3개의 세마포어로 구성된 세마포어 집합이 할당된다.

?시스템의 세마포어가 모두 할당되었다면 다음과 같은 에러가 발생한다.

ORA-2721 : osnseminit: cannot create semaphore set

이 경우에는 이용가능한 세마포어가 생길 때 까지 기다려야 한다. 그리고
비정상적으로 프로세스를 종료하는 경우에는 할당된 세마포어가 Release되지
못하며 어떤 프로세스가 어떤 세마포어를 사용하는가를 구분하기 힘드므로
사용상의 주의가 필요하다.

<세마포어 사용 계획>

세마포어 커널 파라미터의 이름, 조정 방법 및 커널 재생성 방법은 시스템에
따라서 다르다. 필요한 세마포어의 갯수는 다음의 공식으로 구할 수 있다.

   proc(init<SID>.ora에서의 processes 파라미터)
   + test(MIPS RISC 프로세서를 쓰는 경우는 1, 그 외에는 0)
   + 3 * f(fast driver connection 갯수)
   + sys(오라클 외의 프로그램에서 필요한 세마포어 수)
------------------------------------------------------------
   = tot(필요한 최소한의 세마포어 수)

세마포어의 최대 갯수를 지정하는 파라미터(보통 SEMMNS)는 최소한 위에서
계산한 값보다 커야 한다.

일반적으로 하나의 집합마다 가능한 세마포어의 최대 갯수(보통 SEMMSL)는
10~25 정도이다. fast driver를 많이 쓰는 경우라면 세마포어 집합의 갯수가 더
많이 필요하다.

'OS > UNIX 공통' 카테고리의 다른 글

세마포어에 대하여 (0)	2012/05/11
linux/unix date로 어제(yesterday) 날짜 출력 (0)	2010/05/05
Linux find 명령어 완전 정복 가이드 (0)	2009/10/07

화일의 손상 여부를 확인하는 dbv 사용 방법

[PineTree] — Fri, 11 May 2012 10:40:40 +0900

제목 : 화일의 손상 여부를 확인하는 dbv 사용 방법
==============================================

dbv 란 database verify 의 약자로, 7.3.2 부터 지원되는 유틸리티입니다.
dbv 는 data 나 index block 이 어느 정도 신뢰성이 있는지, 손상(corruption)의
유무에 대한 정도를 점검해 줍니다. dbv 는 block level 까지만 점검하기
때문에, 'ANALYZE TABLE .. VALIDATE STRUCTURE CASCADE' 와는 달리 index 와
data block 간의 일치성 점검은 수행하지는 않습니다.

(dbv 는 analyze 시 table lock(TM) 이 걸리는 문제 때문에, analyze 할 수
없는 상황에서 유용하게 사용될 수 있습니다.)

사용 방법
~~~~~~~~

Unix:         dbv FILE [options]

Windows NT: DBVERFxx FILE [options] (xx 는 Oracle server ersion)
                                     (즉, Oracle 8.0 에서는DBVERF80)

옵션:
        Keyword   Description        (Default)
        ----------------------------------------------
        FILE      File to Verify     (NONE)
        START     Start Block        (First Block of File)
        END       End Block          (Last Block of File)
        BLOCKSIZE Logical Block Size (2048)
        LOGFILE   Output Log         (NONE)
        FEEDBACK Display Progress   (0)

1. dbv 유틸리티는 data file 에 대해서만 사용될 수 있습니다.
redo log 나 control file 에 대해서는 작업할 수 없습니다.

2. raw device 에 대해서는 직접 dbv 를 수행할 수 없고, 다음과 같이
symbolic link 를 사용해야 합니다. 또한, link name 은 반드시
확장자(extension)를 주십시오

예) ln -s /dev/rvol/tools01 /user2/oraclerc/mytools01.dbf

3. raw device 에 대해서는 START 와 END 를 사용해야 합니다.
end 값을 지나치게 크게 주면, file 의 마지막 block 을 corrupt 로
report 할 수 있으니, 가급적 analyze 를 이용하십시오.

예) START=1 END=<num blocks -1>

주의 사항
~~~~~~~~
1. page number 는 해당 화일 내의 database block number 입니다.

2. 'Marked Corrupt' 나 'Failing' 이 있다면, 다시 dbv 를 수행하여
일시적인 현상인지 확인합니다.
(Datafile들은 db 가 open 된 상태이고, read-only 일 때 정확한 결과를
얻을 수 있습니다.)

만약, 재수행 시에도 위 에러가 발생한다면, 어떤 block 인지 찾아서 index
이면 ANALYZE INDEX .. VALIDATE STRUCTURE, table 이면 ANALYZE TABLE ..
VALIDATE STRUCTURE CASCADE 를 하십시오.

참고) object 찾는 방법은 FILE ID # 6, BLOCK # 82 일때,

svrmgrl
connect internal;
select * from dba_extents
where file_id = 6 and 82 between block_id and block_id + blocks -1;

예) dbv 의 결과

$ dbv file=/mnt3/rctest73/app/oracle/oradata/RC73/tools01.df

DBVERIFY: Release 7.3.4.0.0 - Production on Mon Nov 23 13:51:14 1998

DBVERIFY - Verification starting : FILE =
/mnt3/rctest73/app/oracle/oradata/RC7f

DBVERIFY - Verification complete

Total Pages Examined         : 15360
Total Pages Processed (Data) : 3086
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2385
Total Pages Failing   (Index): 0
Total Pages Empty            : 9201
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0

'ORACLE' 카테고리의 다른 글

화일의 손상 여부를 확인하는 dbv 사용 방법 (0)	2012/05/11
Oracle 데이터베이스 신규 취약점 주의 (0)	2012/05/10
오라클 12년도 교육 과정 (0)	2012/03/08
Oracle Shared Server 튜닝 (0)	2011/12/13
쿼리문이 제대로 Index를 타는지 확인하는 방법 (0)	2008/03/27
Oracle ERP에서 사용하는 DB관련 작업 (0)	2007/10/22

Oracle 데이터베이스 신규 취약점 주의

[PineTree] — Thu, 10 May 2012 10:42:21 +0900

cve-2012-1675개요

2012년 5월 1일, Oracle사는 자사 보안업데이트 발표 체계인 Critical Patch Update(CPU)를 통해 패치가 되지 아니한 Oracle 데이터베이스 제품 취약점에 대한 임시 조치 권고 발표[1]
CPU를 통해 패치되지 아니한 취약점에 대해 개념증명코드(PoC)가 공개되어 패치 전에 취할 수 있는 조치에 대한 보안권고

설명

TNS listener와 관련된 취약점으로 원격에서 사용자 인증 없이 데이터베이스에 대한 악용이 가능함
※ TNS(Transparent Network Substrate) : Oracle에서 개발한 기술로 서로 다른 Network 구성을 가지고 있는 Client/Server 또는 Server/Server 간에도 Data의 전송을 가능하게 해주는 Network 기술

해당 소프트웨어

Oracle Database 11g Release 2, versions 11.2.0.2, 11.2.0.3
Oracle Database 11g Release 1, version 11.1.0.7
Oracle Database 10g Release 2, versions 10.2.0.3, 10.2.0.4, 10.2.0.5

임시 조치 방안

Real Application Clusters(RAC) 사용자는 My Oracle Support Note 1340831.1 참고 [2]
※ RAC(Real Application Clusters) : Oracle 데이터베이스 환경에서 클러스터링과 고가용성 기능을 가능케 하는 추가 기능
Real Application Clusters(RAC) 미사용자는 My Oracle Support Note 1453883.1 참고 [3]
상기 문서를 검토하고 벤더사 및 유지보수업체와 협의/검토 후 조치 요망

기타 문의사항

한국인터넷진흥원 인터넷침해대응센터: 국번없이 118

[참고사이트]
[1] http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
[2] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1340831.1
[3] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1453883.1

'ORACLE' 카테고리의 다른 글

화일의 손상 여부를 확인하는 dbv 사용 방법 (0)	2012/05/11
Oracle 데이터베이스 신규 취약점 주의 (0)	2012/05/10
오라클 12년도 교육 과정 (0)	2012/03/08
Oracle Shared Server 튜닝 (0)	2011/12/13
쿼리문이 제대로 Index를 타는지 확인하는 방법 (0)	2008/03/27
Oracle ERP에서 사용하는 DB관련 작업 (0)	2007/10/22

Oracle Wait Event 모니터링

[PineTree] — Wed, 02 May 2012 14:03:23 +0900

Oracle Wait Event 모니터링

Oracle_Wait_Event_모니터링.doc

글: 안진철 (jcahn@warevalley.com)

現㈜웨어밸리 책임 컨설턴트
前 LG-EDS 기술 연구부문 DB 팀
- 솔루션 컨설팅 경력 6년

연재 순서

[1] Oracle Wait Event 모니터링 (2003년 1월 28일)
[2] Enqueue와 Latch (2003년 2월 12일)
[3] Shared Pool 관련 Wait Event (2003년 2월 26일)
[4] buffer cache 관련 Wait Event (2003년 3월 12일)
[5] redo log 관련 Wait Event (2003년 3월 26일)
[6] Top SQL 튜닝 (2003년 4월 9일)

[1] Oracle Wait Event 모니터링

흔히 DBA를 3D업종이라고 부르는 이유 가운데 하나는 몸은 고달픈데 반해 그 성과가 별로 티가 나지 않는다는 사실 때문일 것이다. 실제로, DBA가 수행해야 하는 일상적인 관리 업무들은 몸은 다소 피곤하게 만들지 몰라도 어느 정도 경험이 쌓이면 그리 부담을 주는 일은 아니다. 우리가 한단계 업그레이드된 전문가로서 인정 받는 DBA가 되기 위해서는 장애상황 혹은 유사 장애 상황에서 DB 모니터링 작업을 수행하고 분석할 수 있어야 한다. 시스템이 갑자기 느려지고 업무가 마비되는 상황에 맞닥뜨렸을 때 문제의 원인이 무엇인지를 집어낼 수 있는 능력이 있어야 하며 최소한 오라클의 문제인지 아닌지를 판단할 수는 있어야 몸으로 야간작업이나 때우는 DBA가 아니라 조직에 없어서는 안될 전문가로서의 나의 존재가치를 인정 받을 수 있을 것이다.

이 글에서는 오라클 Wait Event에 대하여 간단히 알아보고 일시적인 성능저하 상황에서 Wait Event를 모니터링하고 그 원인을 찾아가는 방법에 대하여 다루어 보고자 한다. 짧은 지면 위에 다룰 수 있는 내용도 제한되어 있고 글쓴이의 지식 또한 일천하지만 오라클 전문가가 되기 위해 같은 길을 가고 있는 동료로서 가진 지식 몇 가지 공유한다는 취지로 이 글을 쓴다.

오라클의 Wait Event 정보는 V$SYSTEM_EVENT, V$SESSION_EVENT, V$SESSION_WAIT 등이 있는데, 이 가운데 V$SESSION_WAIT는 각 세션이 현재 Waiting 하고 있는 Event나 마지막으로 Wait한 Event 정보를 보관하고 있으며, V$SYSTEM_EVENT와 V$SESSION_EVENT는 시스템이 Startup된 이후 각각 시스템 전체, 혹은 세션별로 발생한 Wait Event 정보를 누적하여 기록하고 있다.

오라클의 Wait Event는 성격에 따라 Network교신이나 IO를 위해 대기하는 일상적인 Wait와 특정 자원에 대해 여러 프로세스가 동시에 액세스하고자 할 때 발생하는 Wait, 별달리 할 일이 없어 대기하고 있는 Idle Wait 등 세가지 유형으로 구분할 수 있는데 그 유형에 따라 해석방법도 달라진다. 일단, Idle Wait는 일반적인 관심의 대상에서 제외되며 IO나 Network 관련 Wait는 작업량이 증가하면 같이 증가하는 Wait이므로 전체 서비스 시간(CPU time)과 비교하여 상대적으로 평가해야 하며 총 Wait time보다는 평균 Wait Time에 관심을 두고 분석을 해야 할 것이다. 시스템 자원에 대한 Wait는 데이터베이스 서버 튜닝시 가장 주된 관심 대상이 되며 이들 Wait에 대해서는 평균 Wait Time뿐만 아니라 총 Wait Time에도 관심을 가지고 분석해야 할 것이다. 유형별로 대표적인 Wait Event를 살펴본다면 아래와 같다.

[주요 Wait Event]

구분	이벤트명	설 명
일상적인 Wait Event	db file scattered read	Full Scan시 OS에 I/O를 요청해놓고 대기
일상적인 Wait Event	db file sequential read	Index Scan시 OS에 I/O를 요청해놓고 대기
(IO, Network)	log file sync	변경 log buffer를 log file에 반영하는 동안 대기
	DFS lock handle	OPS 환경에서 노드간 분산 Lock 교환에 따른 대기
	global cache cr request	OPS 환경에서 노드간 Buffer Block 교환에 의한 대기
자원 경합에 따른 Wait Event	enqueue	Type에 따라 세분화 (24개의 enqueue type (9i))
	latch free	Name에 따라 세분화 (239개의 latch가 존재 (9i))
	buffer busy waits	동일블록에 대한 동시 액세스에 따른 경합
	free buffer waits	free buffer를 할당위해 DBWR의 Write를 대기
	Log buffer space	Log buffer를 할당 받기 위해 LGWR의 write를 대기
	library cache lock	SGA내의 library cache를 참조하기 위한 대기(검색)
	row cache lock	SGA내의 dictionary cache를 참조하기 위한 대기
Idle Event	SQL*Net message from client	Client로부터의 작업요청을 대기
Idle Event	Pmon timer	PMON이 할일 없을 때 대기하는 Event

업무시간대에 시스템이 갑자기 느려졌다면서 오라클 서버에 문제가 없는지 문의가 들어오면 글쓴이는 우선 아래의 SQL을 수행시켜본다.

select /*+ ordered / distinct /* 속도를 위해 v$sql을 조인할 경우 중복되는 레코드 제거 */
           s.sid SID, s.username, s.program, p.spid "OS-Pid",w.seconds_in_wait as "W_time(Sec)",
          decode(w.wait_time,0,'Wai-ting', 'Waited') Status, w.ename event,
--              p1text || ':' || decode(event,'latch free',p1raw, to_char(p1)) ||','||
--              p2text || ':' || to_char(p2) ||','|| p3text || ':' || to_char(p3) "Additional Info",
           q.sql_text
from ( select a.*, decode(a.event,'latch free', 'latch free (' ||b.name||')',
                                         'row cache lock', 'row cache lock (' || c.parameter || ')',
                                         'enqueue', 'enqueue ('||chr(bitand(p1, -16777216)/16777215)||
                                                                             chr(bitand(p1,16711680)/65535)||':'||
                                                decode(bitand(p1,65535), 1, 'N', 2, 'SS',3,'SX',4,'S',5,'SSX',6,'X') ||')',
                              a.event ) ename
           from v$session_wait a, v$latchname b, v$rowcache c
         where a.p2 = b.latch#(+) and a.p1 = c.cache#(+) and c.type(+) = 'PARENT'
           and a.event not in ('rdbms ipc message','smon timer','pmon timer','slave wait','pipe get','null event',
                                     'SQL*Net message from client', 'SQL*Net message to client','PX Idle Wait',
                                      'PX Deq: Execution Msg', 'KXFQ: kxfqdeq - normal deqeue',
                                         'ges remote message', 'wakeup time manager', /* idle event 적절히 수정 */
                                         'lock manager wait for remote message', 'single-task message')
        ) w, v$session s, v$process p, v$sql q
where w.sid = s.sid and s.paddr = p.addr
and s.sql_hash_value = q.hash_value(+) and s.sql_address = q.address(+)
order by w.ename;

SQL의 구체적인 내용이야 필요한 정보와 개인적 취향에 따라 달라지겠지만, 중요한 것은 일단 V$SESSION_WAIT 뷰로부터 실시간 Wait Event 정보를 얻어낸다는 것이다. 위 SQL을 수행했을 때 나타나는 결과가 없다면 일단 오라클 측면에서 업무성능을 심각하게 마비시키는 Waiting이 발생하고 있지 않다고 봐도 큰 무리가 없을 것이다.

일반적인 상태에서는 주로 'db file sequential read'나 'db file scattered read' 가 나타날 텐데, 이러한 Wait Event는 보통 짧은 시간 동안 지속되며 대상 자원(블록)을 바꿔가며 Wait가 반복되는 형태로 나타날 것이다. 이는 작업 처리량이 많을 때 일상적으로 발생하는 IO관련 Wait Event이므로 해당 세션에서 IO를 제법 많이 유발하고 있다는 정도로 이해하고 넘어가면 될 것이다. 물론, Wait의 지속시간이 길거나 지나치게 빈번히 나타나는 SQL에 대해서는 비효율적인 실행계획을 수립하고 있지 않은지 검토해서 튜닝해 주어야 한다.

성능저하의 원인이 오라클 쪽에 있는 경우에는 특정 자원에 대한 Waiting이 상당히 오랫동안 지속되어 현재까지 Waiting이 진행 중인 세션들(STATUS가 'Wai-ting' (wait_time=0)이며 'W_time(sec)' (seconds_in_wait) 값이 상당히 큰 세션)이 존재할 가능성이 높다. 오라클의 내부적인 작업들은 매우 짧은 기간에 처리되어야 하므로, Idle event(where절에서 not in으로 처리한 부분, 버전에 따라 달라질 수 있다.) 이외의 특정 Wait Event가 눈에 띌 정도로 검출된다는 것은 오라클 내부적으로는 훨씬 더 많은 Waiting이 발생하고 있다고 생각해야 한다. 바로 이런 세션들이 문제의 범인들이며 이제부터 DBA는 이들 Wait Event에 대한 원인을 파악하여 조치하는 작업을 해주어야 한다. 각각의 Wait Event에 따라 원인을 추적하고 조치하는 방법은 달라질 것이다.

다음 호에서는, 자주 경험하는 몇가지 대표적인 Wait Event들에 대하여 SGA 영역별로 구분하여 좀 더 자세히 살펴보고, 그에 앞서 Lock 또는 Latch Event의 이해를 위해 필요한 Enqueue와 Latch의 개념을 간단히 알아보도록 하겠다.

[2] Enqueue와 Latch 개념 이해하기

DBMS의 가장 주된 기능 중에 하나는 동일 자원에 대한 동시 액세스를 관리하는 것이며, 이를 위해 오라클이 사용하는 대표적인 제어 구조가 Enqueue와 Latch이다.
Enqueue와 Latch는 모두 특정 자원에 대한 접근을 serialize하는 것이 목적이라는 점에서는 같은 Lock의 일종이지만 관리방식이나 용도에서 차이가 있다. Enqueue는 이름에서 보듯 Queue를 통해 관리된다. 대상 자원에 대한 Owner, Waiter, Converter Queue를 관리하면서 먼저 요청한 순서대로 Lock을 획득하도록 하는 구조이며, Exclusive 모드 뿐 아니라 다양한 수준의 공유를 허용한다. 대표적인 것이 테이블 데이터를 Update할 때 사용되는 TM, TX enqueue이다.

반면에, Latch는 Enqueue에 비해 훨씬 단순한 구조로서 매우 짧은 시간 내에 획득되고 해제된다. Queue를 통해 관리되지 않으므로 먼저 Request한 프로세스가 먼저 latch를 획득한다는 보장이 없으며, 대부분의 경우 Exclusive모드로만 획득된다. Latch는 주로 SGA의 특정 메모리 구조체에 대한 액세스(library cache latch, cache buffers chains latch) 혹은 메모리 할당 시 (shared pool latch) 사용되거나 오라클의 중요한 코드가 동시에 수행되지 않도록 하기 위한 용도로(redo writing latch) 사용된다. Latch는 Enqueue보다는 하위 level에서 Locking 자체의 부하를 최소화하며 작동하는 제어 메커니즘이라고 할 수 있으며, 실제로 Enqueue 역시 내부적으로는 Latch (enqueues, enqueue hash chains latch )에 의해 운영된다는 점을 생각하면 둘 사이의 차이를 쉽게 이해할 수 있을 것이다.

■ Enqueue

Enqueue 정보는 내부적으로 Enqueue Resource 배열과 Enqueue Lock 배열에 저장된다. 특정 자원에 대한 Lock이 요청되면 대상을 하나의 Resource로 정의하여 할당하고 그 Resource에 대해 관련 Lock 정보를 Owner, Waiter, Converter가운데 하나로서 Link시키는 방식으로 운영되며, 이러한 정보는 V$RESOURCE와 V$LOCK 뷰를 통해 조회해 볼 수 있다. V$RESOURCE와 V$LOCK은 1:M 관계로 하나의 Resource에 대하여 여러 건의 Lock 레코드가 Owner (LMODE>0, REQUEST=0), Waiter (LMODE=0 ,REQUEST>0), Converter (LMODE>0, REQUEST>0) 중 하나로서 대응된다.
Enqueue Wait이 발생하는 것은 다른 세션이 이미 나보다 먼저 해당 자원에 대한 Lock을 잡고 있으므로 인해 내가 원하는 모드로 Lock을 할당 받을 수 없기 때문이다. 자신이 필요로 하는 Lock의 획득에 실패한 세션은 Owner가 작업을 완료하고 자신을 깨워줄 때까지(세마포어를 포스트해줄 때까지) Waiter 혹은 Converter Queue에서 대기하게 되며, 기다려도 소식이 없으면 3초 간격으로 timeout에 의해 일어나 혹시 Deadlock 상황이 아닌지 점검해 본 후 다시 Sleep에 빠져들기를 반복하게 된다. 튜닝관련 자료를 보다 보면 가끔 Enqueue에 대한 Wait이 많은 경우에 Enqueue_resource나 Enqueue_lock 파라미터를 증가시켜 주어야 한다는 가이드를 보게 되는 경우가 있는데 이 파라미터들은 Enqueue resource와 lock 배열의 크기를 늘려줄 뿐 특정 Enqueue 자원에 대한 동시 경합을 해소시키는 것과는 상관이 없다. Enqueue Wait를 해소하기 위한 구체적인 방법은 Enqueue type에 따라 달라지지만 결국은 Enqueue를 불필요하게 요청하는 경우가 없는지를 살펴 Enqueue에 대한 요청을 최소화하고 Enqueue를 점유하는 시간을 최대한 단축시키는 것이다. TX Enqueue에 대한 Wait은 대상 자원에 대한 Lock을 소유하고 있는 세션과 그 세션이 수행 중인 SQL을 찾아 트랜잭션이 장시간 지속되고 있는 이유가 무엇인지 애플리케이션 측면에서 조사해야 하며, SQ enqueue는 Sequence 값 할당 시 발생하는 경합이므로 cache값을 늘려줌으로써 완화시킨다거나 ST Enqueue의 경합이 존재할 경우에는 Locally managed tablespace를 사용하거나 Initial, Next 등의 extent 크기를 적당한 값으로 조정하여 실시간 공간할당을 감소시켜주는 등의 방법들이 Enqueue Wait에 대처하는 대표적인 사례이다. 지난 호에서 소개한 Session Waiter 스크립트는 Enqueue Wait 이벤트에 대해서 Enqueue type과 모드를 함께 표시하여 주도록 하고 있으며, 참고로 Enqueue type별 누적 Wait현황을 확인하고자 하면 아래 SQL을 수행하면 된다.

select q.ksqsttyp type,
           q.ksqstget gets,
           q.ksqstwat waits,
            round(q.ksqstwat/q.ksqstget,3) waitratio
       from sys.x$ksqst q
where q.inst_id = userenv('Instance')
      and q.ksqstget > 0
order by waits desc
/

■ Latch

오라클 운영 시에 하위레벨에서 내부적으로 처리되는 다양한 조작들이 latch의 관할 하에 수행되는데 V$LATCHNAME을 조회해보면 (9i 기준으로) 239 종류나 되는 Latch가 존재하는 것을 확인할 수 있다. 이 가운데 우리가 자주 접하게 되는 latch는 다음과 같은 정도이며 각 Latch의 기능은 관련 SGA별 Wait를 다룰 때 간단하게나마 소개하도록 하겠다.

Shared pool	library cache latch, shared pool latch, row cache objects
Buffer Cache	cache buffers chains latch, cache buffers lru latch, cache buffer handle
Redo log	redo allocation latch, redo copy latch, redo writing latch
OPS	dlm resource hash list

▷ Willing to wait 모드와 No-wait 모드

Latch 획득 방식은 No-wait과 Willing to wait 의 두 가지 모드로 구분할 수 있다. Willing to wait 모드는 Latch의 획득에 실패하면 좀더 시간을 끌면서 해당 Latch를 잡을 때까지 재시도를 해보는 방식을 말한다. 일차적으로는 CPU를 놓지 않고 정해진 횟수만큼 Spinning을 한 후 재시도를 해보다가 그래도 실패하면 CPU를 놓고 Sleep하다가 timeout되어 재시도하는 작업을 반복하면서 Latch의 획득을 노력하게 된다. Latch가 sleep에 들어가게 되면 'latch free' wait event 대기가 시작된다. sleep의 지속시간은 sleep 횟수가 늘어갈수록 점점 길어지게 되는데, 따라서 V$LATCH의 Gets와 Sleeps의 비율과 함께 Sleep1~sleep4 항목에서 몇차 Sleep까지 발생했는지 여부도 각 Latch Wait의 심각성을 판단하는 요소 가운데 하나가 된다.

No-wait 모드는 Willing to wait과는 달리 더 이상 미련을 두지 않고 해당 Latch에 대한 획득을 포기하는 것이다. No-wait 모드가 사용되는 경우는 두 가지가 있는데, 하나는 동일한 기능을 하는 Latch가 여러 개 존재하여 그 중에 하나만 획득하면 충분하여서 특정 Latch에 미련을 가질 필요가 없는 경우이다. 물론, 이 때에도 같은 기능의 모든 Latch에 대한 시도가 실패로 끝날 경우에는 Willing to wait 모드로 요청을 할 것이다. No-wait 모드가 사용되는 다른 한가지 경우는 dead lock을 피하기 위해서 이다. 오라클은 기본적으로 latch dead lock 상황을 피하기 위하여 모든 Latch에 level을 부여하여 정해진 순서를 따라서만 Latch를 획득하도록 하고 있는데, 필요에 의해 이 규칙을 어기고 Latch를 획득하고자 할 경우 일단 No-wait 모드로 시도를 해보는 것이다. 다행히 Latch를 잡으면 좋은 것이고 비록 latch를 잡을 수 없더라도 무한정 기다림으로써 dead lock 상태에 빠지는 일은 피할 수 있는 것이다. No-wait 모드의 Latch작업에서는 당연히 Latch 관련 wait이 발생하지 않으며, redo copy latch를 제외하고는 Willing to wait 모드로 Latch를 획득하는 경우가 훨씬 많다.

▷ Parent latch와 Child latch

Latch 가운데에는 동일 기능을 하는 Child latch들의 set으로 운영되는 Latch도 있으며 하나의 Latch로만 운영되는 Latch도 있다. 전자의 대표적인 예로는 cache buffers chains (버퍼캐쉬 블록 들을 같은 이름의 다수의 Latch가 나누어 담당)가 있으며, 후자의 예로는 shared pool latch (shared pool내에서 메모리 할당을 위해 획득해야 하는 Latch로 시스템에 하나만 존재)가 있다. 이와 같은 Latch 관련 통계 정보는 Parent latch와 Child latch의 개념으로 관리가 되는데 Latch set에서 개별 Child latch에 대한 통계정보는 V$LATCH_CHILDREN 뷰를 통해 조회할 수 있으며, 단일 Latch 혹은 Latch set의 마스터 Latch (parent)에 대한 통계정보는 V$LATCH_PARENT 뷰를 통해 조회할 수 있다.

지금까지 한 회 분량을 할애하여 Enqueue와 Latch에 대해 요약해본 이유는, 많은 Waiting이 SGA내의 공유자원 (Block, Cursor 등)에 대한 경합으로 인해 발생하며 이러한 경합은 다시 해당 자원에 대한 동시 액세스를 제어하는 Enqueue와 Latch에 대한 경합으로 흔히 드러나게 되므로 오라클의 Wait Event를 모니터링하기 위해서는 Enqueue와 Latch의 구조와 작동원리에 대해 이해하는 것이 필수적이기 때문이다.

[3] Shared Pool 관련 Wait

■Share pool과 성능문제

오라클이 공유 메모리(SGA)를 사용하는 가장 큰 이유는 기본적으로 메모리 사용을 최소화하면서 처리성능은 최대화하기 위한 것이다. 한번 액세스된 블록을 Database buffer cache에 캐쉬 함으로써 비용이 큰 Disk I/O를 최소화하는 것처럼, 한번 처리된 SQL의 실행 정보를 Shared Pool에 공유함으로써 파싱 작업을 위한 CPU, 메모리 자원의 사용을 최소화하고 SQL 수행속도를 증가시킬 수 있다. Shared Pool에는 SQL이나 PL/SQL을 수행하기 위한 각종 정보 - SQL구문 및 실행계획, PL/SQL 소스, 테이블, 뷰 등의 각종 오브젝트와 오브젝트 상호간의 의존관계, 권한관계 등 - 가 저장되어 있다. 지면 관계상 이 글에서 Shared Pool의 관리 메커니즘을 상세히 기술할 수는 없지만 몇 가지 내재적인 특징으로 인해 Shared Pool은 오라클의 메모리 영역 가운데에서도 가장 성능문제의 요소가 많은 곳이면서도 효과적인 튜닝이 수월치 않은 영역이기도 하다.

무엇보다, Shared Pool에서 가장 문제가 되는 것은 메모리의 조각화(Fragmentation)이다. Shared Pool에서 라이브러리 캐쉬 오브젝트를 위해 할당되는 메모리 단위를 chunk라고 부르는데 chunk의 크기는 수 바이트에서 수 K바이트에 이르기까지 필요에 의해 다양하게 할당된다. 새로운 chunk의 할당이 필요하게 되면, 프로세스는 이미 존재하는 chunk로부터 필요한 만큼의 크기만을 떼어내어 사용하므로 시간이 흐를수록 점차 메모리가 조각화 되는 것을 피할 수 없다. ( 이는, Pctincrease가 0가 아닌 테이블스페이스에서 익스텐트의 할당과 해제가 반복됨에 따라 공간의 조각화가 심해지는 것을 떠올리면 이해가 쉬울 것이다. ). 어느 정도 정형화된 패턴의 애플리케이션이 수행되는 환경이 아니라, 공유가 불가능한 다양한 형태의 SQL(대표적으로 Literal SQL)이 빈번히 요청되는 환경이라면 Shared Pool 메모리 조각화에 따른 문제는 더욱 심각해진다.

또한, Shared Pool은 일반적인 메모리 캐쉬와는 달리 메모리에 저장되었던 정보를 잠시 기록해둘 대응되는 디스크 공간이 없으므로 한번 flush된 라이브러리 캐쉬 오브젝트를 reload하기 위해서는 해당 정보를 재생성 해야만 한다. 이 과정에서 관련 오브젝트 정보의 검색 및 참조, locking, 메모리 할당 등의 작업을 위해 많은 비용이 들기 때문에 결국 Shared Pool 관련 튜닝의 최대 과제는 SQL 공유를 최대화하여 새로운 파싱 요청과 메모리 요청을 최소화하는 것이라고 할 수 있다. 헌데, 이는 애플리케이션의 설계와 연계되는 영역으로서 이미 개발이 완료된 운영서버에서는 변경작업이 여의치 않은 것이 현실이다. 앞서, Shared Pool이 DBA로서 튜닝이 수월치 않은 영역이라고 표현한 이유 가운데 하나가 여기에 있다.

■ Shared Pool 관련 오해 바로잡기

Shared Pool과 관련하여 판단이 쉽지 않은 부분 가운데 하나가 과연 shared_pool_size를 얼마나 할당할 것인가 하는 것이다. 오라클은 Shared Pool 메모리를 최대한 효율적으로 활용하기 위하여 다양한 기법을 동원하고 있는데, 이러한 메모리 관리 메커니즘에 대해 정확히 알지 못하여 Shared Pool 크기를 지나치게 크게 할당함으로써 오히려 문제를 악화시키는 경우도 드물지 않다. 이러한 오해를 바로잡기 위해 Shared Pool의 메모리 할당과정을 간단하게나마 살펴보도록 하겠다.

새로운 메모리 Chunk가 할당되는 과정을 살펴보면, 우선 프로세스는 Free List를 검색하여 자신이 필요로 하는 크기의 Free Chunk를 찾고, 그러한 Free Chunk가 없으면 원하는 크기보다 한단계 큰 Free Chunk를 찾아서 필요한 크기만큼 분할하여 사용하게 된다. 만약 Free List에서 충분한 크기의 Free Chunk를 찾을 수 없다면, 이미 사용되었으나 현재는 사용되고 있지 않는(unpinned) Chunk들의 LRU List를 검색하여 오래된 것부터 8개씩 flush시켜 Free Chunk로 만든 후 자신이 필요한 크기를 할당하여 사용하게 된다. 만약 이 과정에서 현재 사용중인(pinned) Chunk가 대부분이거나, 너무 메모리 조각화가 많이 일어나서 기존 Chunk를 Flush시킨 후 인접한 Free Chunk들을 병합해보아도 원하는 크기의 Free Chunk를 얻어낼 수 없다면 오라클은 ORA-4031 에러를 발생시키는데, 그 이전에 한가지 최후의 비밀무기가 더 숨어 있다. 바로 Spare Free 메모리라는 것인데 오라클은 인스턴스 기동 후 처음에는 전체 Shared Pool의 50% 가량은 Free List에 올려놓지 않고 아예 숨겨두었다가 앞서와 같이 도저히 피할 수 없는 순간이 되면 조금씩 해제 시켜 사용하도록 한다. 그야말로 메모리의 조각화를 최소화하기 위한 오라클의 눈물 나는 노력이라고 할 수 있을 것이다. 물론 이 영역까지 다 소모한 후에 flush를 통해서도 필요한 Chunk를 확보할 수 없는 상황이 되면 결국 ORA-4031 에러가 발생할 것이다.

많은 이들이 Shared Pool의 남아있는 Free memory의 크기가 작으면 shared_pool_size를 증가시켜주어야 한다고 믿고 있는데 이는 잘못된 것이다. Shared Pool은 정보의 재사용을 위해 운영하는 것이므로 SQL 실행이 끝났다고 해서 해당 Chunk를 Free List로 반납하지 않는다. 즉, Free Memory가 남아있는 한 계속 소모 시키는 방식으로 사용되므로 오랜 시간동안 운영되어온 시스템에서 Shared Pool의 Free Memory가 매우 적게 남아 있는 것은 그 자체로는 문제가 되지 않으며, 오히려 피크타임이 지난 후에도 많은 양의 Free Memory가 남아있다면 이는 Spare Free 메모리도 다 소모하지 않은 상태로서 불필요하게 많은 메모리가 할당되어 낭비되고 있음을 의미한다. 더구나, Shared Pool 크기가 지나치게 크면 Free Memory를 다 사용할 때까지의 기간이 연장되는 효과는 얻을 수 있겠지만, 시간이 지날수록 Memory의 조각화가 더욱 심해지고 Free List의 길이가 길어져 Free Chunk의 검색과 할당에 걸리는 시간이 지연되므로 오히려 성능이 악화되는 결과를 초래할 것이다.

또한, 메모리 조각화에 따른 영향을 줄이기 위해 오라클은 5000 bytes가 넘는 큰 사이즈의 Chunk만을 위해 전체 Shared Pool의 5% 정도를 따로 관리하는 방법을 사용하고 있는데, 경험적으로 보면 이 공간은 거의 사용되지 않고 버려지고 있는 경우가 많다. 이는 V$SHARED_POOL_RESERVED 뷰의 USED_SPACE 값을 확인해 보면 알 수 있으며, 5000 bytes 이상의 large chunk가 거의 요구되지 않는 환경에서는 오히려 이 크기를 줄여주는 것이 나을 것이다.

■Shared Pool 관련 wait

Shared Pool과 관련하여 흔히 발생하는 Wait은 라이브러리 캐쉬 오브젝트에 대한 동시 액세스와 메모리 할당에 따른 관련 Lock 또는 Latch에 대한 경합이 대부분이며, 구체적인 이름은 다음과 같다. (Latch free 이벤트시 괄호 안의 관련 latch 이름은 v$session_wait의 p2값과 v$latchname의 latch#를 조인하여 얻어낼 수 있다. 1회 SQL 참조)

Latch	Lock
latch free ( library cache ) latch free ( library cache load lock)	library cache lock, library cache pin library cache load lock
latch free ( row cache objects )	row cache lock
latch free ( shared pool )

Library cache lock, library cache pin, library load lock은 각각 특정 라이브러리 캐쉬 오브젝트에 대한 검색이나 변경 및 실행 또는 로드 시에 대상 오브젝트에 대해 할당되며, 이러한 Locking 작업은 library cache latch와 library cache load lock latch의 관할 하에 처리된다. Shared pool latch는 Free List나 LRU List를 검색하거나 메모리를 할당하는 작업에 사용되며, row cache lock과 row cache objects latch는 Data dictionary cache 오브젝트에 대한 동시 액세스를 제어하는데 사용된다.

Latch의 개수는 시스템 전체적으로 하나 또는 제한된 개수가 존재하는 것이고 Lock은 대상 오브젝트 각각 대해 할당되는 것이므로, 엄밀하게 말해서 Lock에 대한 경합은 직접적으로는 특정 라이브러리 캐쉬 오브젝트에 대한 동시 액세스로 인해 유발되는 것인 반면에, Latch에 대한 경합은 시스템 전체적으로 관련 오퍼레이션(즉, SQL 파싱) 자체가 지나치게 많이 발생하거나, 짧은 시간 내에 처리되지 못함으로 인해 유발되는 것이라고 구분해볼 수 있다. 그러나, 결국 이 모든 경합은 근본적으로 Shared Pool의 조각화(Fragmentation)에 따른 문제가 주된 원인이며 다시 이러한 조각화는 요청되는 SQL들이 공유되지 못하고 지속적으로 새롭게 파싱되고 메모리가 할당됨으로 인해 발생하는 것이다. 따라서, 이러한 문제를 해결하는 가장 효과적인 방법은 Literal SQL을 바인드 변수를 사용하도록 수정하거나, SQL작성 표준을 마련하고, HOLD_CURSOR/ RELEASE_CURSOR, SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME, CURSOR_SHARING 등의 파라미터를 활용하는 등의 방법을 통해 SQL의 공유도를 높여주는 것이며, 또한 자주 사용되는 PL/SQL에 대해서는 DBMS_SHARED_POOL 패키지를 사용하여 메모리에서 Flush되지 않도록 보존하는 등의 조치를 취해주면 도움이 될 것이다. SQL의 수정이 어려운 환경이거나 시스템에 요청되는 SQL의 절대량이 확보된 메모리 공간에 비해 많은 상황이라면 주기적으로 피크타임을 피해 Shared Pool을 직접 Flush(alter system flush shared_pool 명령을 사용한다.) 시켜주는 것도 권장할 만한 관리 방법이다. 많은 이들이 우려하는 바와는 달리 Shared Pool을 직접 flush 시키는 것이 심각한 성능상 문제를 야기하지는 않으며 특히 중요한 패키지나 SQL cursor, Sequence 등이 keep되어 있는 경우라면 더욱 그러하다.

가끔 버그를 포함한 특수한 상황에서 특정 라이브러리 캐쉬 오브젝트에 대한 lock이 장시간 해제되지 못하고 있는 경우도 있는데 이때는 X$KGLLK 뷰를 조회하면 library cache lock에 대한 holder/waiter를 확인하여 조치할 수 있다. 또한, Row cache lock에 대한 경합은 Locally managed tablespace를 도입하거나, DML이 빈번한 테이블에 대한 인덱스의 개수를 줄여주는 등의 조치를 통해 완화될 수 있을 것이다.

부연하자면, Shared Pool과 관련된 Wait는 특정 오브젝트 자원에 대한 경합에 의해 발생하기 보다는 애플리케이션의 설계, 보다 단순화시켜 표현하면 Literal SQL에 의한 메모리 조각화에 의해 발생하는 경우가 많다. 따라서, Shared Pool관련 Wait가 많이 발생하여 오라클이 그로 인한 성능상의 문제를 드러낼 때 눈에 띄는 하나의 주범을 찾아내려는 노력은 별 효과를 거두지 못하는 경우가 많으며, 그러한 시점에 DBA가 즉각적으로 취할 수 있는 조치로는 직접 Shared Pool을 Flush 시키는 정도가 있을 것이다. 결국, 평소에 꾸준한 모니터링을 통해 Shared Pool의 적절한 크기와 관련 파라미터 값을 찾아가는 것, 그리고 무엇보다 애플리케이션 측면에서 튜닝 및 수정 작업을 진행함으로써 성능문제를 사전에 예방하는 것이 최선이다.

[3] Buffer Cache 관련 Wait

■ Buffer Cache 구조

Buffer Cache의 기본적인 기능은 여러 프로세스에 의해 공통으로 자주 액세스 되는 데이터베이스 블록을 메모리에 캐쉬하여 물리적인 디스크 IO를 최소화함으로써 더 빠른 액세스 속도를 제공하기 위한 것이다. 복잡한 설명은 생략하고, Buffer Cache 의 기본구조를 이해하기 위한 몇 가지 핵심 용어들을 간단히 정리해 보도록 하겠다.

▷ Buffer header

모든 버퍼 블록들은 각자의 buffer header를 통해 액세스되고 관리된다. 즉, 메모리에 캐쉬된 특정 데이터 블록에 대한 액세스는 먼저 해쉬 알고리즘을 통해 cache chain 상의 buffer header를 찾고 해당 buffer header에 기록된 데이터 블록의 메모리상 주소를 찾아가 원하는 정보를 읽는 방식으로 이루어진다. Buffer header에 기록되는 주요정보는 다음과 같으며 Buffer header의 내용은 V$bh 뷰를 통하여 조회해볼 수 있다.

     - 메모리상에서의 해당 버퍼블록의 주소
     - 해당 버퍼 블록(실제로는 버퍼헤더)가 포함되어 있는 hash chain
     - LRU, LRUW, CKPTQ와 같은 리스트상에서의 해당 버퍼블록의 위치
     - 해당 버퍼블록에 대한 User, Waiter와 상태를 나타내는 각종 Flag

▷ Hash Buckets/ Hash Chains

Buffer Cache의 모든 블록은 해쉬 알고리즘을 통해 관리된다. 곧, 데이터 블록의 DBA, Class 값으로 Hash Function을 적용하여 해당 블록이 속하는 hash buckets을 할당하며, 동일한 hash buckets에 할당되는 데이터 블록의 버퍼헤더들은 linked list형태로 hash chain을 이루게 된다. Hash buckets/hash chains는 특정 데이터 블록을 찾아가기 위한 수단을 제공한다. 각각의 hash buckets에는 자신에 속한 hash chain을 보호하기 위한 latch(cache buffers chains)가 할당된다.

▷ LRU

LRU는 두개의 리스트, 즉 LRUW와 LRU 리스트의 쌍으로 구성된다. LRUW(LRU Write list)는 dirty list와 같은 말이며, 수정되어 디스크에 반영되어야 할 블록들의 리스트이다. LRU(Least recently used list)는 LRUW에 올라가지 않은 나머지 버퍼 블록들이 등록되어 있다. Buffer cache 상의 버퍼블록은 반드시 LRU나 LRUW 둘 중의 하나에 등록되며, 두 리스트에 동시에 포함되는 경우는 없다. LRU는 Free Buffer를 찾기 위한 수단을 제공한다. 경합을 피하기 위해 버퍼캐쉬 블록들을 여러 개의 LRU쌍으로 나누어 관리할 수 있으며, 각 LRU리스트를 보호하기 위해 Latch(Cache buffers lru chain)가 하나씩 할당된다.

■ Buffer Cache 운영규칙

▷ 메모리상의 특정 버퍼블록을 찾아가거나, 특정 블록이 메모리에 캐쉬 되어 있는지를 확인하기 위해서 오라클은 hash bucket/hash chain 구조를 사용한다.

▷새로운 데이터블록을 디스크로부터 메모리로 읽어 들이기 위한 free buffer를 확보하기 위해 오라클은 LRU 리스트를 사용한다.

▷ 버퍼블록은 LRU나 LRUW 둘 가운데 하나에 등록된다.

▷ 하나의 블록에 대해 시간대가 다른 여러 개의 복사본이 존재할 수 있으며, 그 가운데 오직 CURRENT 버퍼만이 변경될 수 있다.

▷하나의 버퍼블록은 한번에 오직 하나의 프로세스에 의해서만 변경될 수 있다.

■ Buffer Cache 관련 Waits

버퍼캐쉬와 관련되어 흔히 발생하는 대표적인 Wait 이벤트는 다음과 같다.

▷ buffer busy waits

여러 세션이 동시에 같은 블록을 읽으려고 하거나 여러 세션이 같은 블록에 대한 변경작업이 완료되기를 기다리고 있는 경우에 발생하며, 특정 블록에 대한 경합을 해소하기 위한 조치는 블록의 유형에 따라 달라진다. Data block에 대한 경합이 많은 경우는 Pct free나 Pct used 값을 사용하여 블록 당 로우수를 줄이거나, 특정 블록에 로우 입력이 몰리는 구조의 인덱스(right-hand-index)일 경우는 reverse key index의 사용을 검토하는 등의 방법이 있으며, segment header의 경합이 많은 경우는 freelist 수를 늘리거나 Extent의 크기를 증가시키는 등의 방법이 있고, undo header나 undo block에 대한 경합은 롤백세그먼트의 개수나 크기를 증가시키는 것이 전형적인 조치 방법이다. v$waitstat과 x$kcbfwait을 이용하며 Class 또는 file별로 wait 발생상황을 판단할 수 있다.

▷ free buffer waits/write complete waits

DBWR가 dirty buffer를 write하는 동안 서버 프로세스가 대기하고 있는 경우 발생한다. 곧, 너무나 많은 dirty buffer가 생겨나거나 DBWR의 쓰기 속도가 충분히 튜닝 되지 못한 경우에 발생한다. 점검 포인트는 물리적 디스크의 속성(stripe size, layour, cache size) 최적화, Raw device의 활용, Async IO나 multi-DBWR(db_writer_processes) 활용여부 등이다.

위와 같은 버퍼 블록에 대한 경합 역시 비효율적인 실행계획을 통해 수행되는 애플리케이션에 의하여 불필요하게 많은 블록이 메모리로 올라오는 것이 원인일 경우가 많으므로 경합이 빈번한 블록이 속하는 테이블/인덱스 명을 찾아낼 수 있다면 관련 SQL을 찾아내어 보다 효과적인 튜닝작업이 이루어질 수 있을 것이다. v$session_wait의 p1,p2 컬럼에 각각 file#, block#값을 표시하여 주므로 이 값을 이용하여 아래의 SQL문으로 현재 어떤 오브젝트에 대하여 해당 wait가 발생하고 있는지를 추적할 수 있다. ( 1회에 소개한 SQL문에서는 Additional Info 값을 참조. )

     select segment_name, segment_type
     from dba_extents
     where file_id = :file#
     and :block# between block_id and block_id + blocks -1

▷ cache buffers chains latch

SGA내에 캐쉬된 데이터블록을 검색할 때 사용된다. 버퍼캐쉬는 블록들의 chain을 이루고 있으므로 각각의 chain은 이 Latch의 child들에 의해 보호된다. 이 Latch에 대한 경합은 특정 블록에 대한 대량의 동시 액세스가 발생할 때 유발된다. 애플리케이션을 검토해 보아야 한다.
Ø cache buffers lru chain latch
버퍼캐쉬의 버퍼를 LRU 정책에 따라 이동시켜야 할 필요가 있는 경우 프로세스는 이 Latch 획득하게 된다. 이 Latch에 대한 경합은 Multiple buffer pool을 사용하거나 DB_BLOCK_LRU_LATCHES 를 증가시켜 LRU Latch의 개수를 늘려서 해소할 수 있다. SQL문을 튜닝하면 해당 프로세스에 의해 액세스 될 블록의 수가 줄어들 것이므로 당연히 효과를 거둘 수 있다.

위와 같이 버퍼캐쉬를 관리하는 Latch에 대한 경합은 경합이 집중되는 특정 Child Latch에 의해 관리되는 버퍼블록을 찾아 해당 블록이 속한 세그먼트 정보를 알아낸다면 보다 효과적인 조치가 가능할 것인데, latch free wait일 경우 v$session_wait의 p1raw 값이 해당 Latch address를 의미한다. 이 값을 x$bh의 hladdr 값과 조인하면 관련 오브젝트 이름을 추적해볼 수 있다.

     select file#, dbarfil, dbablk, obj, o.name
     from x$bh bh, obj$ o
     where bh.hladdr = :latch_address
     and bh.obj = o.obj#;

[5] Redo buffer 관련 Wait

■ Redo buffer 구조

오라클 리두 구조의 핵심은 모든 트랜잭션 정보를 OS 파일에 기록해 둠으로써 시스템 장애가 발생해도 트랜잭션 단위의 일관성을 잃지 않고 데이터베이스를 복구할 수 있도록 하겠다는 것이다. 리두버퍼(redo buffer)는 이처럼 데이터베이스에 가해진 모든 변경내역을 파일에 기록 하기 위해 잠시 사용되는 메모리 영역이며 리두버퍼에 기록된 리두 정보는 다시 리두로그 파일에 기록되어짐으로써 향후 시스템 복구 작업이 필요할 때에 사용하게 된다. 오라클의 리두 구조를 이해하기 위한 핵심적인 개념을 간단히 정리해보면 다음과 같다.

데이터베이스에 대한 변경내역은 블록단위로 저장된다. 물론 변경되는 모든 블록의 복사본을 통째로 저장하는 것은 아니고 블록별로 어떠한 오퍼레이션을 수행하는가, 그리고 그러한 블록별 오퍼레이션을 어떠한 순서로 수행하는가를 기록한다. 이러한 블록별 단위액션을 change vector라고 부르며 change vector가 순차적으로 모여 하나의 의미 있는 redo record가 된다. 리두로그는 시스템내의 모든 프로세스들에 의해 생성되는 redo record를 SCN 순서대로 저장해놓은 것이다. 이때 리두로그에 기록되는 내용에는 테이블이나 인덱스 등의 데이터 블록 뿐만 아니라 UNDO 블록 또는 UNDO 세그먼트 헤더블록에 대한 변경내용을 포함하는 모든 버퍼캐쉬 블록에 대한 변경내역이 대상이 된다.

리두 정보는 항상 실제 변경작업보다 먼저 보관되어야 어떤 상황에서도 복구가 가능해진다. 따라서 트랜잭션을 수행하는(데이터베이스 블록에 변경을 가하는) 프로세스는 우선 자신의 메모리 영역 내에서 수행하고자 하는 작업에 대한 리두 레코드를 만들며, 이를 먼저 로그버퍼에 기록하고 난 후에 실제 버퍼블록에도 리두 레코드에 담긴 내용을 따라 적용하게 된다. 또한 같은 이유로 오라클은 변경된 버퍼캐쉬 블록을 디스크에 기록하기 전에 먼저 관련된 로그버퍼를 로그파일에 기록하는 작업을 처리하게 된다. 따라서, 리두 버퍼 또는 리두 파일 (아카이브 파일을 포함해서)에 대한 쓰기 작업에 병목이 생기면 시스템에 대한 모든 작업 수행이 대기 상태로 빠지게 될 것이다.

트랜잭션 커밋을 요청한 프로세스는 우선 해당 트랜잭션에 대한 로그버퍼가 리두로그 파일에 기록되는 작업이 완료된 후에야 커밋 완료 메세지를 받을 수 있다. 그렇게 함으로써 버퍼캐쉬 변경내역을 모두 디스크에 반영하지 않고도 시스템의 비정상 종료시 리두파일에 저장된 리두 레코드로부터 커밋 트랜잭션을 보존할 수 있게 된다.

■리두 버퍼관련 Wait 이벤트

일반적으로는 로그버퍼 관련해서 심각한 Waiting이 발생하는 경우는 드물지만, 가끔 볼 수 있는 리두 관련 Wait 이벤트로는 다음과 같은 것들이 있다.

▷ Log file parallel write

LGWR가 OS에 리두 버퍼를 로그파일에 기록하도록 요청해 둔 상태에서 대기하고 있는 이벤트이다. 이 경우에는 DML 작업시 nologging 옵션 등을 사용하여 시스템에서 발생하는 리두 레코드의 절대량을 줄이거나 하드웨어적으로 DISK IO를 개선시켜주는 것이 방안이다.

▷Log buffer space

프로세스가 로그버퍼를 할당하기 위해 대기하는 이벤트인데 LGWR가 로그버퍼를 비우는 것보다 더 빠른 속도로 프로세스들이 리두 레코드를 생성하고 있다는 것을 의미한다. 로그버퍼의 크기를 늘려주거나, DISK IO의 속도를 개선시켜 주어야 할 것이다. 로그버퍼는 로그파일에 대응되는 블록이 맵핑이 된 후에 사용될 수 있으므로 로그 스위치 발생시에도 log buffer space 이벤트에 대한 대기가 발생할 수 있다. 로그 스위치가 너무 잦다면 리두 로그 파일의 크기를 증가시켜주는 것이 좋다.

▷ Log file sync

프로세스가 커밋이나 롤백을 수행할 경우 우선 LGWR에게 해당 트랜잭션까지의 로그버퍼를 Write하도록 요청하게 되는데 이때 사용자 프로세스는 LGWR가 쓰기 작업을 완료할 때까지 log file sync 이벤트를 대기하게 된다. 버전 8i 이전에서는 DBWR가 쓰기 작업을 수행하다가 아직 관련 로그버퍼가 파일에 쓰여지지 않을 경우에도 LGWR에 쓰기를 요청하고 log file sync 이벤트에 대기하였으나 8i 이상에서는 log file sync에 대기하는 대신 deferred write queue에 등록한다. 따라서 버전 8i 이상에서 log file sync 이벤트는 사용자 프로세스에 의해 요청되는 커밋, 롤백 처리 시에 발생하며 결국, 시스템 전체적으로 커밋, 롤백이 지나치게 자주 수행되거나 상대적으로 LGWR의 쓰기 속도가 느린 것이 원인일 것이다. 또는, 로그 버퍼가 너무 커서 LGWR가 백그라운드로 flush 시켜주기 전( 보통 3초 간격 및 1/3 이상의 로그버퍼가 찬 경우)에 커밋에 의한 쓰기 요청이 이루어지므로 커밋 시점에 써야 할 양이 많아 대기시간이 길어지는 경우도 있는데 이 경우엔 리두 버퍼의 크기를 오히려 줄여주어야 할 것이다. 또는, LGWR wait for redo copy 이벤트가 많이 나타난다면 redo copy latch가 너무 많아 LGWR이 사용자 프로세스가 버퍼 쓰기 작업을 마칠 때까지 기다리는 일이 잦은 경우를 뜻하며 이 경우엔 _LOG_SIMULTANEOUS_COPIES 파라미터를 사용하여 copy latch의 수를 줄여주는 조치가 필요할 것이다.

시스템에 따라서 언급한 외의 다양한 이벤트 대기와 원인이 존재할 수 있고, 더구나 버전에 따라 redo copy latch와 redo allocation latch를 포함한 리두 운영 방식상 상이한 부분이 많이 존재하여 그에 따른 추가적인 튜닝요소가 있으나 이 글에서는 지면 관계상 8i를 기준으로 간략히 정리해 보았다.

[6] Top SQL 튜닝하기 (맺음)

■ Top SQL 튜닝의 필요성

지난 회까지 실시간 Wait Event 모니터링과 이벤트별 원인분석에 대해서 간단히 살펴보았다. 일시적 성능장애 시 재빨리 원인을 찾아내는 것도 중요하지만 보다 바람직한 것은 이러한 성능문제를 사전에 최대한 예방하는 것임은 두말할 필요도 없다. 오라클 성능문제를 다루는데 있어 강조하고 싶은 한가지는 시스템 자원의 배분을 변경하거나 증가를 고려하기 전에, 불필요한 작업을 최소화함으로써 자원요구 횟수와 자원점유 시간을 줄여주는 노력이 선행되어야 한다는 점이다. Wait Event에 대한 모니터링과 분석이 DBMS의 자원에 대한 경합과 관련된 성능문제를 파악하는데 유용한 방법임에 틀림없지만, 이 같은 정보는 데이터베이스 혹은 그 하위 레벨의 구조적 비효율성을 드러내어줄 뿐 애플리케이션 레벨의 문제를 직접적으로 알려주지는 않는다. 간단히 말하자면, DBMS 튜닝을 위해 정성을 쏟기 이전에 애플리케이션 튜닝에 더 많은 투자를 하라는 것이다. 이런 관점에서 DBA가 비교적 손쉽게 수행할 수 있는 것이 오라클 메모리로부터 악성 SQL을 추출하여 튜닝하는 Top SQL 튜닝이다.

■Top SQL 추출기준

사용자로부터 요청되어 오라클 내에서 처리되는 모든 SQL은 오라클의 공유 메모리 영역 가운데 shared pool내에 캐쉬 되어 지며 이렇게 캐쉬 되어 있는 SQL과 관련 통계정보는 V$SQL 또는 V$SQLAREA 뷰를 통해서 조회할 수 있다. 이때, Top SQL을 추출하는데 중요하게 사용되는 항목은 buffer_gets, disk_reads, executions, rows_processed 등이며 일반적으로 아래와 같은 기준으로 Top SQL을 추출한다.

▷ Buffer gets 수치가 높은 SQL

Buffer gets은 해당 SQL이 처리되는 과정에서 액세스한 메모리 블록의 수(Logical IO)를 의미한다. 물론 이 값이 높다고 해서 무조건 악성 SQL임을 의미하는 것은 아니다. 즉, 이러한 SQL들 중에는 실제로 요구되는 작업량이 많아서 액세스 블록수가 많은 SQL도 있을 것이며 불필요한 처리를 수행하느라 액세스 블록수가 많은 SQL도 있을 것이다. 어느 경우이든 이 SQL들이 현재 오라클 서버에 부하를 많이 유발하고 있는 SQL들이라는 것만은 분명하며 사소한 비효율적 요소에 의해서도 서버에 큰 영향을 미칠 잠재적인 가능성이 있는 SQL들이므로 일차적으로 점검해 볼 필요가 있다.

악성 SQL여부를 판단하기 위한 Buffer gets의 수치에 절대적인 기준은 없으며 시스템의 데이터 규모와 트랜잭션량에 따라 다르다. buffer gets값을 기준으로 역순으로 정렬한 후 패턴을 살펴 적절한 추출기준을 선택하는 것이 좋을 것이다. 만일, 상위 몇 개의 SQL들과 나머지 SQL들 간의 buffer gets의 편차가 매우 크게 나타난다면 상위 몇 개의 SQL에 대해서만 튜닝을 수행해 주어도 큰 효과를 볼 수 있을 것이다. 일반적으로 시스템에서 수행되는 SQL 가운데 심각한 부하를 야기하는 SQL은 소수에 불과한 경우가 많으며 뒤에 기술될 다른 조건들과 조합하여 최대 Top 50건 정도를 추출하여 효율성을 검증하고 튜닝을 통해 개선하는 작업을 수행하여 주면 충분하다.

▷Buffer gets/Execution 수치가 높은 SQL

SQL의 단위 수행당 buffer gets 수치를 의미한다. 단위 수행당 buffer gets 값이 높다는 것은 해당 SQL의 처리가 비효율적일 가능성이 높음을 의미한다. 액세스 블록수가 비정상적으로 많다는 것은 rows_processed 값과 비교하여 상대적으로 평가되어야 할 부분이다. 실제로 반환하는 로우수가 매우 많은 배치성 SQL이거나 혹은 반환되는 로우수가 1건이라도 Group Function이 사용된 Summary성 SQL이라면 처리과정에서 많은 수의 블록을 액세스하는 것은 불가피하며 이 자체가 문제가 될 수는 없기 때문이다.

▷Execution 수치가 높은 SQL

Executions는 해당 SQL이 수행된 횟수를 의미한다. 수행횟수가 잦은 SQL은 buffer gets가 높을 경우가 많다. 일반적으로 십만 ~ 백만 회 이상 빈번하게 수행되는 SQL이라면 buffer gets/executions 값이 2자리 수 이내의 값을 나타내어야 정상이며 단위 수행당 속도는 0.1초 이내로 매우 빨라야 한다. 따라서, 이러한 SQL의 경우 SQL단위로 보면 튜닝의 효과를 체감하기도 어렵고 필요성을 느끼지 못할 수도 있으나 튜닝을 통해 아주 적은 차이라도 개선을 가져올 수 있다면 시스템 전체적인 관점에서는 매우 큰 효과를 가져다 줄 수 있다는 점이 중요하다. 하루에 백만번 수행되는 SQL에 대하여 0.01초를 개선한다면 시스템 시간으로 하루에 일만초를 절약한 셈이 될 것이다. 이러한 SQL에 대해서는 현재 빠르게 수행되고 있다고 해도 더 빠르게 처리할 여지가 없는지 점검하고 가능한 모든 방안을 동원하여 개선시키도록 노력해야 한다.

▷disk_reads 수치가 높은 SQL

disk_reads는 SQL이 처리되는 과정에서 물리적인 IO를 통해 액세스한 블록의 수를 의미한다. 물리적 IO의 발생여부는 원하는 블록이 메모리에 캐쉬되어 있는지 여부에 따라 달라지므로 수행되는 횟수와 수행되는 시간대의 데이터베이스 캐쉬 상황에 따라 유동적이라고 할 수 있다. 그러나, buffer gets의 값과 비교하여 disk_reads의 비율이 높은 SQL은 Full Scan을 수행하는 SQL일 가능성이 큰데 그 이유는 Full Scan을 통해 액세스되는 블록들은 기본적으로 DB buffer Cache의 LRU 알고리즘에 의해 관리되지 않으므로 작업 후에 곧바로 메모리로부터 밀려나 버릴 가능성이 높기 때문이다. 반면에 인덱스를 통하여 액세스하는 경우, 일상적으로 액세스되는 테이블에 대해서는 인덱스의 root block과 branch block은 항상 메모리에 캐쉬 되어 있을 확률이 높으므로 물리적 IO를 유발하는 비율이 낮을 수 밖에 없다.

■Top SQL 추출기준

글을 맺기 전에 마지막으로 언급하고 싶은 것 하나는, 문제가 발생했을 때 문제의 원인이 bug로 인한 것일 가능성을 항상 염두에 두어야 헛된 고생을 덜한다는 것이다. 오라클도 사람이 만든 프로그램이므로 버그가 없을 수 없으나 다행히 오라클의 버그 및 패치 관리는 매우 훌륭한 편이다. 오라클 메타링크를 활용하여 유사한 문제가 보고된 적은 없는지 관련 버그에 대한 정보는 없는지 살펴보아야 하며, 평소에 정기적으로 패치 및 버전 관리를 해주는 것이 바람직하다.

오라클 시스템을 운영하다 보면 현실에서는 다양한 문제가 복잡하게 얽혀 나타나므로 명백한 원인을 파악하기가 쉽지 않을 때가 많지만, 운영 시 자신의 시스템에서 자주 발생하는 Wait 패턴 또한 분명히 존재하므로 굵은 가지들부터 하나씩 이해하고 해결해 나가다 보면 오라클이 우리가 보인 애정에 보답해줄 날이 올 것이라 믿는다. 지면 관계상 OPS(RAC) 관련 Wait을 비롯한 기타 Wait 이벤트에 대해 다루지 못한 점, 그리고 각 Wait 이벤트별로 좀더 친절한 설명과 사례를 제시하지 못한 점이 아쉬움으로 남지만, 누구든 아주 작은 것 하나라도 이 글을 통해 새로이 얻을 수 있었다면 그 이상 바랄 것은 없다.

'ORACLE > TUNING' 카테고리의 다른 글

Oracle Wait Event 모니터링 (0)	2012/05/02
Chapter 9 Tuning Buffer Cache (0)	2012/05/02
AWR report 생성 및 분석 (0)	2012/03/08
10g)과거에 사용된 바인드변수 추적 / SQL이 실행된 옵티마이저 환경 (0)	2012/03/08
SQL 튜닝 대상선정(10g)하기 (0)	2012/03/08
V$SQL BIND CAPTURE (0)	2012/03/08