Read by other session
EXEM Knowledge Base
목차 |
[편집] Basic Info
read by other session 대기이벤트는 buffer busy waits 대기이벤트와 마찬가지로 Buffer Lock 경합과 관련이 있다. read by other session 대기이벤트가 발생하는 상황은 다음과 같다.
- 디스크에서 메모리(버퍼 캐시)로 적재하고자 하는 프로세스 A는 해당 블록에 대해 Buffer Lock을 Exclusive 모드로 획득한다.
- 동일 블록을 읽고자 하는 프로세스 B는 해당 블록에 대해 Buffer Lock을 Shared 모드로 획득하고자 한다. 이 때 프로세스 A가 Buffer Lock을 Exclusive 모드로 획득한 채로 블록을 읽고 있기 때문에, 프로세스 B는 프로세스 A의 작업이 끝날 때까지 대기해야 한다.
- 프로세스 A가 블록을 디스크에서 메모리로 읽어 들일 때까지 프로세스 B는 read by other session 이벤트를 대기한다.
read by other session 이벤트는 오라클 10g에서 추가된 이벤트이다. 오라클 9에서는 Reason Code 값이 220인 buffer busy waits 이벤트에 해당한다.
[편집] Parameter & Wait Time
[편집] Wait Parameters
read by other session 대기이벤트의 파라미터는 다음과
- P1 : File#
- P2 : Block#
- P3 : 블록 클래스
[편집] Wait Time
일반적으로 최대 1초까지 기다린다.
[편집] Check Point & Solution
read by other session 이벤트는 블록을 디스크에서 메모리로 읽어 들이는 과정에서 필연적으로 발생한다. 따라서 이벤트 대기 시간이 지나치게 길지 않다면 문제가 되지 않는다. 만일 read by other session 이벤트 대기 시간이 지나치게 길다면 SQL 튜닝을 통해 Physical I/O의 일량을 줄여야 한다. 또한 동시에 여러 프로세스가 동일 블록을 읽지 않게끔 어플리케이션을 수정하는 것도 고려할 필요가 있다. 또한 read by other session 대기와 함께 db file sequential read, db file scattered read 대기와 같은 I/O 대기 현상이 항상 같이 발생하는 것에 주목해야 한다. read by other session 대기는 그 속성상 항상 물리적인 I/O와 함께 나타나게 된다. 따라서 read by other session 대기가 발생했던 동일환 상황에서도 데이터가 이미 버퍼 캐시에 적재되어 있는 경우에는 물리적인 I/O가 발생하지 않고, 자연스럽게 read by other session 대기 및 db file sequential read, db file scattered read 대기현상 또한 사라지게 된다.
[편집] Event Tip
[편집] Analysis Case
[편집] 비효율 SQL에 의한 Buffer Lock 대기현상
오라클 9i 버전에서 Buffer Busy Waits (id 130) 이벤트는 10g 버전에서 Read By Other Session 으로 이벤트명이 변경되었으므로, Read by other session의 Analysis Case에서 소개합니다.
특정 시점에 Buffer Busy Waits (id 130)의 이벤트를 대기하며 SQL 수행 시간이 50초 이상인 세션들이 발견되었다. 한 세션이 db file sequential read 이벤트를 대기하면서 블록을 버퍼캐시에 적재중이며, 이 때 동일한 SQL문을 수행하는 세션들은 블록 적재가 끝날 때까지 buffer busy waits (id 130)을 대기하고 있다.
Active 세션과 Session Logical Reads(메모리 I/O), Physical Reads(디스크 I/O), Buffer busy waits 이벤트의 추이그래프를 비교해 보면, Buffer busy waits 이벤트의 대기가 발생한 시점에 I/O의 양이 증가함을 확인할 수 있다.
MaxGauge - Performance Analyzer - Session List를 통해 Buffer busy waits (id 130) 이벤트를 대기하는 세션을 검색해본다. 동일한 SQL문을 수행하고 있으며, File#와 Block#를 확인한 결과, 여러 파일과 블록에 걸쳐 Buffer busy waits (id 130) 이벤트를 대기함을 확인할 수 있다.
[편집] 결 론
동일한 SQL문을 동시에 수행할 경우, 같은 파일과 블록에 대하여 동시 액세스하므로 buffer busy waits (id 130)의 대기가 발생합니다. 즉, Hot Block이슈가 아닌 동시 SQL문의 수행 때문이며, 이는 SQL문을 튜닝하여 동시 수행에 있어 I/O 경합을 최소화 하여야 합니다.
즉, 일차적으로 SQL문의 튜닝이 필요하며 튜닝 목표는 최소한의 I/O로 결과값을 추출하는 것입니다. SQL문을 튜닝 후, 같은 블록의 액세스에서 buffer busy waits 이벤트를 대기한다면 Hot Block 이슈를 고민해 볼 수 있습니다.