DFS lock handleDFS lock handle은 요청한 Global lock의 lock handle을 기다리고 있는 대기 이벤트입니다. 이 lock handle은 global lock과 동일합니다. lock handle을 획득하면 global lock을 소유한 상태로 lock conversion이나 lock release와 같은 여러 작업을 수행할 수 있습니다. global lock은 DLM(Distributed Lock Manager)에 의해 관리됩니다. DFS는 Distributed File System의 약자로, 오라클 제품 역사(History)와 관련 있는 용어로 생각됩니다. 오라클 10g의 RAC 기능이 완성되기 전까지 오라클은 상당한 기간동안 분산 데이터베이스를 구현해 왔으며, 최초의..

Placeholder/Fixed-up 이벤트 구조오라클 10g의 클러스터 대기 이벤트들은 다음 2가지로 분류됩니다. 1) Placeholder 이벤트2) Fixed-up 이벤트 특징은 다음과 같습니다. 1) 클러스터 클래스의 대기 이벤트에서만 사용2) Oracle 10g에서 추가된 개념 * Palceholder 이벤트Placeholder 이벤트는 특정 프로세스가 글로벌 자원, 즉 데이터 블록을 획득하는 과정에서 대기하는 이벤트를 말합니다. 모니터링 방법: V$SESSION_WAIT 에서 관찰해야 합니다. 아직 Fixed-up 이벤트로 변경되기 전이면 V$SESSION_EVENT에서도 관찰할 수 있습니다. * Fixed-up 이벤트Fixed-up 이벤트는 특정 프로세스가 데이터 블록을 최종 획득한 시점에 ..

SQL*net more data from/to clientSQL*net과 관련된 모든 대기 이벤트는 System API Call에서 비롯됨을 이해해야 합니다. 가령, SQL*net과 관련된 대표적인 대기 이벤트인 SQL*net message to client는 Server Process가 OS에서 Network Send API 요청을 하고 응답이 오기를 기다린다는 것을 의미합니다. OS는 Server Process가 요청한 Data를 TCP Send Buffer에 넣는 것으로 일을 마치고 Server Process에게 응답을 보냅니다. 즉, SQL*net message to client 대기는 실제 Network 전송이 끝나기를 기다린다는 의미가 아니라 OS가 Send Buffer에 성공적으로 Data를..

gc cr/current grant 2-way프리 블록에 대한 권한을 부여 받는 경우 오라클 10g에서는 gc current grant 2-way 이벤트를 대기한 것으로 관찰되지만, 오라클 9i에서 global cache open x 이벤트를 대기한 것으로 관찰됩니다. gc cr/current grant 2-way 이벤트는 gc cr/current request 이벤트에 대한 Fixed-up 이벤트로, 블록을 요청한 프로세스가 마스터 노드로부터 블록을 읽을 권한을 부여 받았음을(Grant) 의미합니다. gc cr/current request 이벤트가 gc cr/current grant 2-way 이벤트로 바뀌는(Fixed-up되는) 흐름은 다음과 같습니다. - 요청 노드의 유저 프로세스가 특정 데이터 블..

gc cr/current block 2-way/3-waygc cr/current block 2-way 이벤트는 gc cr/current request 이벤트에 대한 Fixed-up 이벤트로, 블록을 요청한 프로세스가 마스터 노드로부터 직접 블록 이미지를 전송 받았다는 것을 의미합니다. gc cr/current request 이벤트가 gc cr/current block 2-way 이벤트로 바뀌는(Fixed-up되는) 흐름은 다음과 같습니다. - 요청 노드의 유저 프로세스가 특정 데이터 블록을 CR 모드 또는 Current 모드로 읽고자 한다.- 유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고, 마스터 노드의 LMS(Lock Monitor Services) 프로세스에 ..

log buffer space리두 버퍼에 리두 레코드를 기록하려는 프로세스는 리두 버퍼 내에 필요한 공간을 확보하기 위해 redo allocation 래치를 획득해야 합니다. redo allocation 래치를 획득한 상태에서 리두 버퍼에 공간을 확보하려는 순간에 적절한 여유공간이 없는 경우, 공간이 확보되기를 기다려야합니다. 이 때, 경우에 따라 두가지 종류의 이벤트를 대기하게 됩니다. 만일 현재 사용 중인 리두 로그 파일이 꽉 차서 더이상 여유 공간을 확보할수 없다면, LGWR 프로세스는 로그 파일 스위치를(log file swtich)를 수행하고, 서버 프로세스는 log file switch completion 이벤트를 대기합니다. 그외의 경우에는 log buffer space 이벤트를 대기하게 됩..

enq: TX - row lock contentionenq: TX - row lock contention 이벤트는 로우 레벨 락(row level lock)에 의한 경합이 발생했다는 것을 의미합니다. 다음과 같은 세 가지 경우에 로우 레벨 락 경합이 발생합니다. - 여러 세션이 동일 로우를 변경하는 경우 - 여러 세션이 동일 Unique Key 충돌을 일으키는 경우 - 여러 세션이 비트맵 인덱스 충돌을 일으키는 경우 * 여러 세션이 동일 로우를 변경하는 경우(mode=6)동일 로우 변경은 TX 락에 의한 경합이 발생하는 가장 보편적인 경우입니다. 특정 프로세스가 특정 로우를 변경하기 위해 해당 로우를 방문했을 때, 현재 로우가 변경된 상태라면 ITL로부터 해당 로우를 변경한 트랜잭션을 확인하고, 자기 자..

SQL의 작성과 파싱데이터베이스에서 어떤 결과값을 얻기 위해 SQL문을 작성할때에도 개발자 개개인마다 이를 표현하는 방법은 다릅니다. 데이터베이스는 같은 결과를 얻는 경우에도, SQL문의 표현이 다르면 새롭게 파싱해야합니다. SQL문을 실행하면, 데이터베이스는 아스키 값으로 계산합니다. 즉, 대문자, 띄어쓰기, 주석에 따라 아스키 값이 다르므로 표현이 달라지면 다른 SQL문으로 인식하게됩니다. 같은 결과를 얻지만 표현이 다른 SQL문은 실행할때마다 library Cache에서 하드파싱됩니다. 하드파싱은 SQL문의 검색과 공간확보를 위해 Shared Pool Latch와 Library Cache Latch를 필요로 합니다. 잦은 하드파싱은 리소스를 과도하게 사용하고 래치를 오래 점유하므로 SQL문의 수행에..

direct path writedirect path write 대기 이벤트는 세션 PGA(Program Global Area) 내부의 버퍼로부터 데이터파일로 기록할 때 발생됩니다. 세션은 다수의 direct write를 요청한 후 처리를 진행합니다. 세션이 I/O 처리가 완료되었다고 인지하는 시점에 direct path write 대기 이벤트를 대기합니다.direct path write 대기는 Direct load 작업이 발생함을 의미합니다. 이러한 작업이 요청될 경우 오라클은 SGA(System Global Area)를 경우하지 않고 데이터 파일에 직접 쓰기 작업을 수행합니다. 즉, DBWR(Database Writer) 프로세스에 의해 쓰기 작업이 이루어지는 것이 아니라 서버 프로세스에 의해 직접 쓰..

db file sequential readdb file sequential read 대기 이벤트는 싱글 블록 I/O 수행 시에 발생하는 대기 이벤트입니다. 한번의 싱글 블록 I/O가 발생할 때마다 한 번의 db file sequential read이벤트 대기가 발생합니다. 싱글 블록 I/O는 파일로부터 하나의 블록을 읽는 모든 작업들에서 발생 가능하며 일반적으로 인데스 스캔 및 ROWID에 의한 테이블 액세스 시에 발생합니다. * Parameter P1(파일#), P2(블록#), P3(블록 수(항상 1)) * Wait Time I/O를 수행하기 위해 대기한 시간을 의미 * 일반적인 문제 상황 및 개선방법 - 원인: 비효율적인 인덱스 스캔으로 인한 과다한 싱글 블록 I/O - 진단 방법: SQL 실행 계획..