#40_140807_OWI_ENQUEUE

# ENQUEUE

l LOCK

1.    Latch : 메모리를 보호하기 위한 락

2.    enqueue : 디스크를 보호하기 위한 락

3.    Enqueue의 종류

- TX enqueue : update 하려다 wating 할때 발생하는 현상

- SQ enqueue : 동일한 sequence를 서로 사용할 때 wating 하는 현상

- HW enqueue : 동일한 테이블에 서로 동시에 insert하려 할 때 wating 하는 현상

- US enqueue : Undo segment를 서로 사용하려 할 때 발생하는 waiting 현상

l LOCK 테스트

- 2개의 터미널 창으로 동시에 scott 계정으로 접속한다

- 양쪽 동시에 update 문으로 scott의 월급을 접근하면 한쪽은 Lock이 걸린다

# SQLGATE

# ORANGE(Session monitoring)

- wating 이 걸려있다면 active 상태가 되고 아니라면 inactive 상태다

- Lock 이 걸린다면 첫번째로 일의 중요도에 따라서 어떤 세션을 죽일지 정해야 한다.

- 일반적으로 홀더를 죽인다. 왜냐하면 홀더로 인해서 다른 세션들이 전부다 Lock이 걸리기 때문이다

- update 같은 경우는 사실 메모리에서 업데이트를 하기 떄문에 latch라고 착각할 수도 있지만 본래 테이블스패이스는 디스크의 영역이기 때문에 enqueue 이다

l SQ enqueue

l Sequence 생성하는 법

시퀀스 이름 : seq20

시작 : 1

증가치 : 1

최대값 : 500

나머지는 default

SQL> create sequence seq20     start with 1     increment by 1     maxvalue 500 cache 20; - cache 20 : 미리 1~20번까지 생성해서 메모리에 만들어 놓는다 - nocache : 메모리에 올리지 않는다 - nocache 를 해놓고 여러 사람이 sequence를 필요로 하게 되면 경합을 하면서 row cache lock 대기 이벤트가 발생한다 - cache 값이 너무 작아서 메모리에 올라와있는 sequence number를 전부 사용하고 나서 다시 메모리에 올리는 시간동안 이벤트가 발생하는데 그것이 SQ enqueue 대기 이벤트다

l SQ enqueue 발생시 해결방법

1.     해당 sequence 가 무엇인지 알아낸다

2.     해당 sequence의 cache 값이 몇인지 알아낸다

3.     해당 sequence의 cache 값이 작다면 늘려야 한다

l SQ Enqueue 테스트

- SQ enqueue 대기 이벤트를 발생시키고 awr report를 통해서 확인 후 성능 개선

>> report를 위한 snapsot을 찍고 sq enqueue 발생 시킨다 SQL> exec dbms_workload_repository.create_snapshot; SQL> @exec Event name to simulate: sq_enqueue Session count [10]: 10 Expired by time(1) or looping count(2) [1]: 1 Execution internval(sec or count) [30]: 60 Enable_trace (1=TRUE, 0=FALSE) [0]: 1 Exec method(0=Oracle Job, 1=Unix Shell) [0]: 0 Init data(1=TRUE, 0=FALSE) [1]: 1 # ORANGE - enq : SQ - contention 이라는 event가 발생하는 것을 확인할 수 있다 SQL> exec dbms_workload_repository.create_snapshot; SQL> @?/rdbms/admin/awrrpt.sql - 가장 오랫동안 대기한 event들이 나온다 - sequence의 이름을 report에서 알아낼 수 있다 >> 위에서 찾은 sequence의 cache 값이 몇인지 data dictionary 를 조회해서 알아낸다 # SQLGATE SELECT * FROM dba_sequences WHERE sequence_name = 'SEQ_SQ_ENQUEUE'; # OWI 계정에서 SQL> alter sequence seq_sq_enqueue cache 500; - cache 값을 500으로 수정 >> cache 값을 500으로 수정한 후에 report에서 얼마나 성능이 개선됐는지 알아본다 SQL> exec dbms_workload_repository.create_snapshot; SQL> @exec Event name to simulate: sq_enqueue Session count [10]: 10 Expired by time(1) or looping count(2) [1]: 1 Execution internval(sec or count) [30]: 120 Enable_trace (1=TRUE, 0=FALSE) [0]: 1 Exec method(0=Oracle Job, 1=Unix Shell) [0]: 0 Init data(1=TRUE, 0=FALSE) [1]: 1 SQL> exec dbms_workload_repository.create_snapshot; SQL> @?/rdbms/admin/awrrpt.sql - 확인결과 cache가 20일때보다 500으로 수정한 후에 waits와 time이 많이 줄은 것을 확인할 수 있다

l 현업에서 SQ ENQUEUE 대기 이벤트

- 현업에서 sequence를 만든적이 없는데도 불구하고 SQ Enqueue 이벤트가 발생하는 경우가 있다

- 이것은 그림처럼 많은 session 들의 접속이 발생하여 session 들의 sequence 번호를 생성해야 했는데 여기서 session의 sequence 번호를 생성에 필요한 시스템sequence 중에 하나인 audses$의 cache 사이즈가 작아서 문제가 생긴다

- cache 사이즈가 작아 생기는 문제가 바로 SQ enqueue 대기 이벤트이다

- 현업에서 10g를 사용하면 보통 cache 사이즈가 20으로 되어있는 경우가 많기 때기 때문에 이런 현상이 발생한다