2024. 5. 22. 13:02ㆍDBMS/ORACLE Admin
Library Cache Object 는 Handle과 LCO로 구성된다. Handle은 Name과 메타정보를 포함하고, LCO는 SQL문, 실행계획 등이 Library Cache에 저장되는 정보의 단위로 DB에서 캐싱되는 정보를 분류하는데 사용된다. LCO에는 sql문장, 프로시저, 함수,트리거 등 DB object 에 메타데이터를 포함하고 있다. SQL 문장이나 PL/SQL 블록과 같은 파싱된 개체를 식별하고 각 객체는 고유한 LCO 핸들을 가지고 라이브러리 캐시 객체에 액세스할 때 LCO 핸들을 사용하여 해당 객체를 참조하여 찾고 사용함으로써 DB에서 블록을 효율적으로 관리하고 공유하여 시스템 자원을 절약하고 성능을 향상시킬 수 있다.
Library cache 는 SQL 실행에 필요한 모든 객체(SQL, Table, View, Procedure)에 대한 정보를 관리하며, 모든 Session이 접근 가능하도록 Shared pool에 저장된다. 라이브러리 캐시는 Hash Table, Hash Bucket, Hash Chain, Handle, Object로 구성된다.
Library Cache Lock은 LCO 에 접근할 때 handle 을 획득하는 lock 이며 LCO에 대한 메타 정보 포인터 정보를 가지고 있다. library cache object 를 식별하는 Handle을 보호하여 객체의 정의를 변경하는 동안 다른 세션이 해당 객체를 참조하는 것을 방지한다. SQL 문을 실행하는 프로세스는 soft parsing 하는 동안 해당 LCO에 대해 library cahce lock 을 shared 모드로 획득한다. shared mode 로 lock을 획득하는 것은 여러 프로세스가 동시에 같은 SQL문을 수행할 수 있다는 것이며 이벤트 대기, 경합발생은 없다. soft parsing이 끝나면 library cache lock을 null 모드로 변환하여 LCO invalidation을 자동화 시킨다.
Library Cache Pin은 LCO를 보호하여 객체가 실행되는 동안 변경되는 것을 방지하고 실행중인 세션 간 정보를 공유한다.
■ SOFT PARSING
Soft Parsing은 SQL 문장을 실행하기 전에 기본적인 구문 및 권한 체크를 수행하는 과정으로 캐시에 존재하는 SQL 문장이 있는지 확인하여, 캐시에서 실행 속도를 향상시키고 시스템 자원을 절약한다.
SQL 문장 수행요청을 하면 기본적인 문법, 사용자의 권한 확인한 후 LIBRARY CACHE의 HASH BUCKET 을 관리하고 CACHE 내의 객체를 액세스하는 LIBRARY CACHE LATCH를 획득하여 LIBRARY CACHE 영역에 동일한 SQL 문장(즉, 동일한 LCO)이 존재하고 있는지 확인한다.
만약 LIBRARY CACHE LATCH를 획득하는 과정에서 경합이 발생하면, 해당 래치를 얻을 때까지 대기하며 "latch: library cache" 이벤트를 기다린다.
동일한 LCO (동일한 SQL 문장)이 캐시에 존재하는 경우, LCO에 대한 LIBRARY CACHE LOCK과 LIBRARY CACHE PIN을 공유 모드로 획득하고 실행 단계로 넘어갈 수 있다.
일반적으로 SQL 커서가 객체(TABLE,view, index ,PROCEDURE..etc)를 참조할 때 LIBRARY CACHE LOCK과 LIBRARY CACHE PIN 을 공유 모드로 획득하여 다른 세션에서도 동시에 해당 객체에 대한 읽기 액세스를 할 수 있게한다. 하지만 객체를 변경하는 DDL 문장을 실행할 때는 해당 객체에 대한 LIBRARY CACHE LOCK과 LIBRARY CACHE PIN을 배타적으로 획득하여 동시에 여러 세션에서의 변경을 방지한다.
■ HARD PARSING
library cache에서 동일한 LCO를 참조하는 것에 실패하면 hard parsing이 발생한다.
먼저 동일한 SQL 문장이 존재하지 않는 경우, DB는 Shared Pool LATCH를 획득하여 프리 리스트에서 적절한 크기의 free chunk를 찾아 새로운 SQL 문장을 저장할 메모리 공간을 할당할 준비를 한다.
만약 Shared Pool LATCH를 획득하는 과정에서 경합이 발생하면 "latch: shared pool" 이벤트를 대기하며 FREE LIST 에서 적절한 크기의 free chunk를 찾는다. free chunk가 확보될 때까지 계속해서 더 큰 크기의 프리청크를 찾아서 분할(split)하고 남은 공간은 다시 프리 리스트에 등록시킨다. 모든 free list에서 free chunk를 찾지 못하면 LRU list를 탐색한다. LRU 리스트의 chunk들은 현재 pin 되지 않은 recreateble 상태의 청크들이며 여기서도 찾지 못하면 shared pool 안의 여유 메모리 공간을 추가적으로 할당한다. 마지막까지 여유 공간이 확보가 되지 않았을 경우 ORA-4031 오류가 발생한다.
적절한 프리청크를 찾으면 해당 SQL 문장에 대한 LIBRARY CACHE HANDLE에 대해 LIBRARY CACHE LOCK을 배타적 모드로 획득 (다른 세션들이 동시에 해당 LCO에 접근하지 못하도록) 한다. LIBRARY CACHE LOCK을 획득한 후 SQL 문장에 대한 라이브러리 캐시 객체(LCO)가 성공적으로 생성되면 LIBRARY CACHE LOCK 을 null 모드로 변환 (다른 세션들이 LCO에 대한 읽기 액세스를 할 수 있게 해줌) 하고, LIBRARY CACHE PIN을 exclusive mode로 획득한 후에 실행 계획을 생성한다. 하드 파싱에 소요된 시간만큼 parse time elapsed도 증가한다.
'DBMS > ORACLE Admin' 카테고리의 다른 글
Redo log file과 archive redo log file (0) | 2024.05.27 |
---|---|
spfile.ora init.ora 파일 (0) | 2024.05.25 |
Shared Pool Reserved (0) | 2024.05.21 |
listener log (0) | 2024.05.17 |
Tablespace 공간 확인 (0) | 2024.05.16 |