Oracle

[Oracle] _gc_read_mostly_locking

bbugge 2021. 7. 28. 10:51

과거 RAC 8i 와 9i 버전에서 cache fusion 기능이 도입되면서 하나의 block에 대해 읽기와 쓰기가 여러 인스턴스에서 발생할 때 이 dirty block 을 disk가 아닌 인스턴스 레벨에서 읽도록 개선되었고  

이후 10g 에서 DRM 기능이 소개되면서 undo와 object 레벨의 DRM이 가능해졌습니다. 

_gc_read_mostly_locking 파라미터는 11g 에서 소개된 DRM 기능이며 Cache층에서 global operation 이력을 이용하여 실현한 read mostly locking 메카니즘입니다. 

read mostly locking 메카니즘은 오라클 Cache층에서 매개 오브젝트의 S lock과 X lock의 갯수가 기록되어 있는데, 만약 특정 노드에서 해당 오브젝트에 대해 S lock이 많고 X lock이 적으며 노드사이 block 전송이 적다면 
이 block은 해당 노드에서 read mostly 이며 일단 read mostly가 발생하면 해당 object는 더이상 노드사이 공유하지 않고 따라서 block 또한 더이상 interconnect를 통해 전송되지 않습니다.(block이 변경되지 않는다는 전제하에서) 

만약 하나의 오브젝트가 read mostly로 정의되면 이 block은 master node가 모든 노드에서 S affinity lock을 부여해주게 되며 이는 미리 해당 block에 대해 read 권한을 부여해준것을 의미합니다. 
따라서 read mostly locking 메카니즘은 노드사이의 S lock 메세제 전송을 줄여주게 되므로 "gc cr grant 2-way", "gc current block 2-way" and "gc current block 3-way" 와 같은 대기 이벤트를 줄여주는 장점이 있으나 
반면 인스턴스로부터 block을 읽지 않고 datafile로 부터 읽다보니 "db file sequential read" 대기 이벤트가 많이 보이고 I/O 사용률이 높아질 수 있으며 read mostly locking이 대부분 적용되는 시스템은 읽기가 많고 쓰기가 적은 시스템입니다. 

요약하면  
_gc_read_mostly_locking 파라미터는 11g 에 출시된 read mostly locking 메카니즘 활성화 여부를 정하는 파라미터이고 
이를 false로 변경하면 인스턴스사이 read에 따른 "gc cr grant 2-way", "gc current block 2-way" and "gc current block 3-way" 대기이벤트가 많이 보이고 cpu 를 많이 소모하게 됩니다. 

 

 

// 11.2.0.3 이전의 버전에서 이 기능으로 인해 인스턴스가 Crash되는 hot critical 한 bug 성 이슈들이 있어으나 11.2.0.3 버전에서 이러한 이슈들은 많이 fix되었습니다.