일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- DataGuard
- 19c
- linux
- OracleGoldenGate
- goldengate
- 사일런트모드
- Oracle
- 오라클
- SILENTMODE
- ogg
- Installation
- 오지지
- Opatch
- oracle installation
- diskgroup
- oracle recovery
- 데이터베이스
- oracle goldengate
- 오라클설치
- Oracle 19c
- 오라클아키텍쳐
- 티베로
- ActiveDataGuard
- SSH
- 디비투
- 오라클구조
- 데이터가드
- ORACLE19C
- Database
- adg
- Today
- Total
DoubleDBDeep
[ORACLE] Cursor 본문
사용자가 질의한 SQL문에 할당되는 Library Cache(SGA,SharedPool)의 메모리영역으로, SQL TEXT, 실행계획, STATS와 같은 SQL문에 대한 정보를 저장함
특정 SQL문을 처리한 결과를 담고있는 메모리 영역을 가리키는 포인터
-> SQL 처리 결과를 Oracle Server Process 내부의 Private SQL Area (PGA) 메모리 영역에 저장되는데, PL/SQL에서는 Cursor를 사용하여 result set에 접근할 수 있다.
Client Process에서 Pointer(Cursor)가 이 메모리 영역을 가리킴
명시적 커서 (Explicit Cursor)
사용자가 직접 쿼리 결과에 접근해서 이를 사용하기 위해 명시적으로 선언한 커서

- 속성
묵시적 커서 (Implicit Cursor)
오라클 내부에서 각각의 쿼리 결과에 접근하여 사용하기 위한 내부적 커서
모든 쿼리가 실행될 때마다 오픈되며 오라클 내부에서 사용 및 접근하는 커서이므로 선언, 오픈 등의 작업이 필요없고 커서 속성을 명시적 커서와 동일하게 사용할 수 있음
묵시적 커서의 경우 이름을 알 수 없고 가장 최근에 실행된 SQL 문장에 대한 커서를 갖고있음. SQL이라는 이름으로 속성에 접근 가능
DECLARE coun t1 NUMBER; count2 NUMBER ; BEGIN SELECT count(* ) INTO count1 FROM employees WHERE department id 100; count2 : = SQL%ROWCOUNT ; dbms output . put line( ’ SELECT COUNT 1S ’ 1 1 count1 ) ; dbms output .put line( ’ ROW COUNT 1S ’ 11 count2 ) ; END ; |
상위커서 / 하위커서
Oracle 엔진은 실행된 각 SQL문에 대해 상위커서/하위커서 두개의 커서를 생성한다.
동일한 SQL문에 대해 다른 바인드 값이나, 두개의 다른 스키마 또는 다른 리터럴 값 등이 있을 수 있는 등의 차이가 있을 수 있기 때문
-> 다른 스키마 이나 같은 테이블명&구조로 인한 같은 SQL문 . .

상위커서 : SQL문 보유
- SQL TEXT를 저장, SQL문이 동일한 경우 동일한 상위커서를 공유
- 모든 상위커서는 하나 이상의 하위 커서와 함께 실행됨
- V$SQLAREA 뷰에 표시 (V$SQLAREA#VERSION_COUNT = 이 상위커서에 몇 개의 하위 커서가 있는지 표시)
하위커서 : 정보 보유
- 환경정보, 통계정보, 바인드변수 정보, 실행 세부정보 등과 같은 SQL문과 관련된 중요한 정보를 저장함
- TEXT는 저장되지 않기 때문에 메모리 공간을 덜 차지하는 편
- 자식 커서가 Soft or Hard Parsing 결정
- V$SQL 뷰에 표시
- V$SQL_SHARED_CURSOR는 옵티마이저가 하위 커서를 비공유하고 새로 생성한 이유를 제공 (SQL 동일하나, Hard Parsing이 발생할 때 참조)
cursor_sharing parameter
SQL이 동일한 커서를 공유할 수 있는지 결정
- SQL문의 LITERAL 값을 BIND변수로 변환하면서 공유 향상되고 SQL 실행계획에 영향을 줄 수 있음.
- EXACT(Default)
동일한 TEXT가 있는 SQL구문만 동일한 커서 공유
- FORCE
일부 문자가 다를 경우 그 문자가 SQL문의 의미에 영향을 미치지 않는 한 강제로 커서 공유
- SIMILAR
SQL문의 의미나 실행계획 최적화에 영향을 미치지 않는 한 일부 문자가 달라도 동일한 커서 공유
Bind Peeking
parameter#cursor
NAME | DESC | DEFUALT |
session_cached_cursors | 한 세션에 cache되는 cursor 수 | 50 |
_optimizer_adaptive_cursor_sharing | BIND 변수 값에 따라 실행 일량을 판단하여 성능이 급격히 떨어지는 SQL들을 다른 PLAN VERSION을 만들어 동적으로 관리하는 방식 -> PLAN 변경 발생 및 Multiple Version의 Overhead 문제로 false 권고 |
TRUE |
_optimizer_extended_cursor_sharing | Extended Cursor Sharing 기능 중에서 user defined bind operator 레벨에서 cursor sharing 사용 여부 결정 -> 불필요한 child cursor 발생 방지 및 bug 문제로 NONE 권고 (참고: 19392364.8( 12.2.0.1 fix ), 1949350.1) |
udo |
_optimizer_extended_cursor_sharing_rel | Extended Cursor Sharing 기능 중에서 relational operator (=,<,>,<=,>=,!=,like) 레벨에서 cursor sharing 사용 여부 결정 -> 불필요한 child cursor 발생 방지 및 bug 문제로 NONE 권고 (참고: 19392364.8( 12.2.0.1 fix ), 1949350.1) |
simple |
cursor_sharing | EXACT | |
open_cursors | 세션당 max cursor 수 | 50 |
'ORACLE > Architecture' 카테고리의 다른 글
[ORACLE] SQL Parsing (0) | 2024.04.17 |
---|---|
[ORACLE] 3. Oracle Process (0) | 2023.03.06 |
[ORACLE] 2. Oracle Memory 구조 (0) | 2023.03.06 |
[ORACLE] 1. Oracle Server Architecture (0) | 2023.03.03 |