잡학문구

🔍 Step 1. 테스트용 테이블 생성

ITL 개수를 결정하는 INITRANS와 MAXTRANS를 가장 낮게 설정하고,

데이터가 여러 블록으로 쪼개지지 않도록 하나의 블록에 최대한 모아서 넣습니다.

1. 테스트 테이블 생성 

-- 1. 테스트 테이블 생성 (INITRANS와 MAXTRANS를 최소값인 1과 2로 설정)
CREATE TABLE itl_test_tbl (
    id   NUMBER,
    val  VARCHAR2(100)
)
INITRANS 1
MAXTRANS 2 -- Oracle 10g 이후 버전부터 MAXTRANS 값은 내부적으로 무조건 256으로 고정
PCTFREE 0; -- 블록 내 여유 공간을 0으로 만들어 ITL이 동적으로 확장될 공간을 원천 차단

2. 동일한 데이터 블록에 행들이 들어가도록 연속으로 INSERT

INSERT INTO itl_test_tbl VALUES (1, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (2, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (3, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (4, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (5, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (6, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (7, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (8, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (9, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (10, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (11, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (12, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (13, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (14, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (15, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (16, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (17, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (18, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (19, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (20, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (21, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (22, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (23, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (24, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (25, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (26, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (27, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (28, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (29, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (30, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (31, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (32, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (33, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (34, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (35, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (36, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (37, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (38, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (39, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (40, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (41, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (42, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (43, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (44, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (45, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (46, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (47, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (48, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (49, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (50, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (51, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (52, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (53, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (54, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (55, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (56, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (57, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (58, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (59, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (60, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (61, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (62, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (63, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (64, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (65, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (66, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (67, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (68, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (69, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (70, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (71, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (72, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (73, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (74, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (75, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (76, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (77, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (78, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (79, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (80, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (81, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (82, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (83, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (84, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (85, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (86, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (87, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (88, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (89, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');
INSERT INTO itl_test_tbl VALUES (90, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (91, 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (92, 'BBBBBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA');
INSERT INTO itl_test_tbl VALUES (93, 'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC');
INSERT INTO itl_test_tbl VALUES (94, 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD');
INSERT INTO itl_test_tbl VALUES (95, 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF');
INSERT INTO itl_test_tbl VALUES (96, 'GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG');
INSERT INTO itl_test_tbl VALUES (97, 'HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH');
INSERT INTO itl_test_tbl VALUES (98, 'IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII');
INSERT INTO itl_test_tbl VALUES (99, 'JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ');

commit;

3. 데이터가 실제로 같은 블록에 있는지 확인
SELECT id, dbms_rowid.rowid_block_number(rowid) as block_no 
FROM itl_test_tbl;
-- 같은 Block에 저장된 데이터 확인;

* 본 테스트에서는 아래와 같이 id=79 까지는 같은 block에 저장됨
        77     613313
        78     613313
        79     613313
        80     613314
        81     613314

🔍 Step 2. 동시 다발적 트랜잭션 실행 (여러개의 세션 필요)

MAXTRANS를 256로 설정되기 때문에, 이 블록을 동시에 수정할 수 있는 세션은 테스트 환경마다 상이할 수 있습니다.

⚠️ 주의: 각각 **다른 행(Row)**을 업데이트해야 합니다. 같은 행을 업데이트하면 ITL 부족이 아니라 일반적인 Row Lock(enq: TX - row lock contention)이 걸립니다.

• 세션 1 (Session A):
• SQL

  UPDATE itl_test_tbl SET val = 'WORK_A' WHERE id = 1;
  -- COMMIT 하지 않고 대기 (ITL 슬롯 1개 점유)

• 세션 2 (Session B):
• SQL

  UPDATE itl_test_tbl SET val = 'WORK_B' WHERE id = 2;
  -- -- COMMIT 하지 않고 대기 (ITL 슬롯 2개 점유)

• 세션 3 (Session C):
• SQL

  UPDATE itl_test_tbl SET val = 'WORK_C' WHERE id = 3;
  -- -- COMMIT 하지 않고 대기 (ITL 슬롯 3개 점유)

• 세션 4 (Session D):
• SQL

UPDATE itl_test_tbl SET val = 'WORK_C' WHERE id = 4;
-- -- COMMIT 하지 않고 대기 (ITL 슬롯 4개 점유)

본 테스트에서는 세션 5, 세션 6에서 UPDATE 수행 후 commit 하지 않고 대기

•  세션 7 (Session G):
•  

  UPDATE itl_test_tbl SET val = 'WORK_G' WHERE id = 7;
  -- 실행하는 순간 락이 걸리며 세션이 멈춤 (대기 발생!)

• SQL

==> UPDATE 가 락이 걸릴 때까지 새로운 session에서 id를 변경하면서 수행

UPDATE itl_test_tbl SET val = 'WORK_G' WHERE id = 7; 

본 테스트에서는  7번째 Session 에서 Lock 이 발생함.

🔍 Step 3. 모니터링 세션에서 대기 이벤트 확인

세션이 멈춰있는 상태(본 테스트에서는 7번째 session)에서, 별도의 모니터링 창을 열어 아래 쿼리를 수행합니다.

SELECT 
    sid, 
    blocking_session, 
    event, 
    p1, p2, p3, 
    seconds_in_wait
FROM v$session 
WHERE event LIKE '%ITL%';

📊 테스트 결과 출력

SID	BLOCKING_SESSION	EVENT	P1	P2	P3	SECONDS_IN_WAIT
389	5,863	enq: TX - allocate ITL entry	1,415,053,316	62,586,881	24,382	30

여기에서 BLOCKING_SESSION은 

특징: 일반적인 Row Lock 경합과 달리 blocking_session이 명확하게 지정되지 않을 수 있습니다. 특정 세션이 나를 막은 게 아니라 "블록 자체의 방(ITL)이 꽉 차서" 못 들어가는 것이기 때문입니다.

🔍 추가로 Row lock test

본 테스트에서는 추가로 row lock test를 진행했습니다.

• 세션 8 (Session H):
• SQL

  UPDATE itl_test_tbl SET val = 'WORK_H' WHERE id = 4;
  -- row lock으로 대기

아래와 같이 ITL lock과 row lock을 확인할 수 있다.

SID	BLOCKING_SESSION	EVENT	SECONDS_IN_WAIT
---------------------------------------------------------
389	5,863	enq: TX - allocate ITL entry	1,937
3,044	5,863	enq: TX - row lock contention	1,689

1. 전제 조건

1. JDK (Java Development Kit) 설치: 자바 코드를 컴파일하고 실행할 환경이 필요합니다.
2. Oracle JDBC 드라이버 (ojdbcX.jar): 해당 드라이버 파일을 다운로드하여 클래스 경로(CLASSPATH)에 포함해야 합니다.
   • Oracle 19c: 일반적으로 ojdbc8.jar 또는 ojdbc10.jar을 사용합니다.
3. 데이터베이스 정보: 접속할 Oracle 인스턴스의 정보(URL, 사용자 ID, 비밀번호)를 알고 있어야 합니다.

2. Java 코드 예시 (OracleConnectionTest.java)

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class OracleConnectionTest {

    // 🔑 사용자 환경에 맞게 이 값들을 수정하세요.
    private static final String DRIVER = "oracle.jdbc.driver.OracleDriver";
    // TNS Listener 포트가 기본값(1521)이고, SID가 ORCL이며, DB가 로컬에 있다고 가정
    private static final String URL = "jdbc:oracle:thin:@localhost:1521:ORCL"; 
    // 또는 Service Name을 사용하는 경우:
    // private static final String URL = "jdbc:oracle:thin:@//localhost:1521/XEPDB1"; 
    
    private static final String USER = "your_username"; // 예: SCOTT 또는 SYSTEM
    private static final String PASS = "your_password"; // 예: TIGER 또는 manager

    public static void main(String[] args) {
        Connection conn = null;

        try {
            // 1. JDBC 드라이버 로드 (Class.forName)
            Class.forName(DRIVER);
            System.out.println("✅ JDBC 드라이버 로드 성공.");

            // 2. 데이터베이스 연결 (DriverManager.getConnection)
            conn = DriverManager.getConnection(URL, USER, PASS);
            System.out.println("🎉 데이터베이스 연결 성공!");
            System.out.println("DB 연결 정보: " + conn.getMetaData().getDatabaseProductName() + " " + conn.getMetaData().getDatabaseProductVersion());

        } catch (ClassNotFoundException e) {
            System.err.println("❌ JDBC 드라이버를 찾을 수 없습니다. CLASSPATH 설정을 확인하세요.");
            e.printStackTrace();
        } catch (SQLException e) {
            System.err.println("❌ 데이터베이스 연결 실패!");
            System.err.println("오류 코드: " + e.getErrorCode());
            System.err.println("오류 메시지: " + e.getMessage());
            e.printStackTrace();
        } finally {
            // 3. 연결 닫기
            if (conn != null) {
                try {
                    conn.close();
                    System.out.println("연결 종료.");
                } catch (SQLException e) {
                    System.err.println("연결 종료 중 오류 발생: " + e.getMessage());
                }
            }
        }
    }
}

3. 컴파일 및 실행 방법

1. 파일 저장: 코드를 OracleConnectionTest.java 파일로 저장합니다.
2. ojdbcX.jar 준비: Oracle 드라이버 파일(ojdbc8.jar 등)을 소스 코드가 있는 디렉토리에 복사합니다.
3. 컴파일: 터미널/명령 프롬프트에서 컴파일합니다.
4. Bash

    

   # ojdbc8.jar 파일이 현재 디렉토리에 있다고 가정
   javac -cp ojdbc8.jar OracleConnectionTest.java
   

5. 실행: 컴파일된 클래스 파일을 실행합니다.
6. Bash

    

   java -cp .:ojdbc8.jar OracleConnectionTest
   # (Windows 환경: java -cp .;ojdbc8.jar OracleConnectionTest)
   

예상 출력 (성공 시)

✅ JDBC 드라이버 로드 성공.
🎉 데이터베이스 연결 성공!
DB 연결 정보: Oracle 19.0.0.0.0
연결 종료.

예상 출력 (실패 시 - 비밀번호 오류 등)

✅ JDBC 드라이버 로드 성공.
❌ 데이터베이스 연결 실패!
오류 코드: 1017
오류 메시지: ORA-01017: invalid username/password; logon denied
... (Java Stack Trace)

힌트란 SQL 문장에 대한 지시 구문입니다.

Optimizer 힌트는 실행 계획을 변경할 수 있고 최적의 실행 계획을 사용하도록 하는 데 사용됩니다

옵티마이저가 알지 못하는 데이터에 대한 정보를 알고 있는 경우 특정 쿼리 실행 계획을 선택하도록 지시할 수 있습니다.

단, Optimizer에 대해 개념을 정확히 알고 사용해야 하며, 데이터의 변동성 등을 충분히 예측하여 사용해야 합니다.

힌트의 사용은 단기적으로 성능향상이 있을 수 있으나, 장기적으로 성능 저하를 초래할 수 있기 때문에 최대한 사용을 자제하며 정확히 알고 있는 경우에만 사용하도록 합니다..

뷰와 함께 힌트 사용하기

Oracle은 뷰(또는 하위 쿼리) 내부나에서 힌트 사용을 권장하지 않습니다. 또한 이러한 힌트로 인해 예기치 않은 실행 계획이 발생할 수 있습니다. 특히 뷰 내부 또는 뷰에 대한 힌트는 뷰가 최상위 쿼리에 병합 가능한지 여부에 따라 다르게 처리됩니다.

힌트 사용 방법

명령문 블록에는 힌트가 포함된 주석이 하나만 있을 수 있으며,

주석은 SELECT, UPDATE, INSERT, MERGE 또는 DELETE 키워드 뒤에 와야 합니다.

힌트 종류

1. Types of Hints

• Single-table : 단일 테이블 힌트는 하나의 테이블 또는 뷰에 지정됩니다. INDEX 및 USE_NL은 단일 테이블 힌트의 예입니다.
• Multi-table :다중 테이블 힌트는 힌트가 하나 이상의 테이블이나 뷰를 지정할 수 있다는 점을 제외하면 단일 테이블 힌트와 비슷합니다. LEADING은 다중 테이블 힌트의 예입니다. USE_NL(table1 table2)은 USE_NL(table1) 및 USE_NL(table2)의 형태와 동일하므로 다중 테이블 힌트로 간주되지 않습니다.
• Query block : 쿼리 블록 힌트는 단일 쿼리 블록에서 작동합니다. STAR_TRANSFORMATION 및 UNNEST는 쿼리 블록 힌트의 예입니다.
• Statement : 구문 힌트는 전체 SQL 문에 적용됩니다. ALL_ROWS는 구문 힌트의 예입니다.

SQL Plan Baselines. ???

2. Hints by Category

Optimizer 힌트는 다음 범주로 그룹화됩니다.

• Hints for Optimization Approaches and Goals
• Hints for Enabling Optimizer Features
• Hints for Access Paths
• Hints for Join Orders
• Hints for Join Operations
• Hints for Online Application Upgrade
• Hints for Parallel Execution
• Hints for Query Transformations
• Additional Hints

2.1 Hints for Optimization Approaches and Goals

ALL_ROWS 및 FIRST_ROWS(n) 힌트를 사용하면 최적화 접근 방식과 목표 중에서 선택할 수 있습니다. SQL 문에 최적화 접근 방식과 목표를 지정하는 힌트가 있는 경우 옵티마이저는 통계 유무, OPTIMIZER_MODE 초기화 매개변수 값, ALTER SESSION 문의 OPTIMIZER_MODE 매개변수에 관계없이 지정된 접근 방식을 사용합니다.

• ALL_ROWS
• FIRST_ROWS(n)

2.2 Hints for Enabling Optimizer Features

OPTIMIZER_FEATURES_ENABLE 힌트는 Oracle Database 릴리스 번호를 기반으로 최적화 기능을 활성화하기 위한 역할을 합니다. 이 힌트는 데이터베이스 업그레이드 후 계획 회귀를 확인할 때 유용한 방법입니다.
힌트에 대한 인수로 릴리스 번호를 지정합니다. 다음 예는 Oracle Database 11g Release 1(11.1.0.6)의 옵티마이저 기능으로 쿼리를 실행합니다.

SELECT /*+ optimizer_features_enable('11.1.0.6') */ employee_id, last_name
FROM    employees
ORDER BY employee_id;

2.3 Hints for Access Paths

다음 힌트는 테이블에 대한 특정 액세스 경로를 사용하도록 지시합니다.

• FULL
• CLUSTER
• HASH
• INDEX and NO_INDEX
• INDEX_ASC and INDEX_DESC
• INDEX_COMBINE and INDEX_JOIN
• INDEX_JOIN
• INDEX_FFS and NO_INDEX_FFS
• INDEX_SS and NO_INDEX_SS
• INDEX_SS_ASC and INDEX_SS_DESC

2.3.1 FULL Hint

FULL 힌트는 옵티마이저가 지정된 테이블에 대해 전체 테이블 스캔을 수행하도록 지시합니다.

SELECT /*+ FULL(e) */ employee_id, last_name
  FROM hr.employees e 
  WHERE last_name LIKE :b1;

Oracle Database는 WHERE 절의 조건에 의해 사용 가능한 last_name 열에 인덱스가 있는 경우에도 직원 테이블에 대해 전체 테이블 스캔을 수행하여 이 문을 실행합니다.
직원 테이블의 FROM 절에 별칭 e가 있으므로 힌트는 이름이 아닌 별칭으로 테이블을 참조해야 합니다.

 

2.3.2 CLUSTER Hint

CLUSTER 힌트는 지정된 테이블에 액세스하기 위해 클러스터 스캔을 명시적으로 선택합니다. 클러스터링된 개체에만 적용됩니다.

SELECT /*+ CLUSTER(e) */ employee_id, last_name
  FROM hr.employees e 
  WHERE last_name LIKE :b1;

 

2.3.3 HASH Hint

HASH 힌트는 명시적으로 해시 스캔을 선택하여 지정된 테이블에 액세스합니다. 클러스터에 저장된 테이블에만 적용됩니다.

SELECT /*+ HASH(e) */ employee_id, last_name
  FROM hr.employees e 
  WHERE last_name LIKE :b1;

 

 

2.3.4 INDEX and NO_INDEX Hint

INDEX hint

INDEX 힌트는 지정된 테이블에 대한 인덱스 스캔을 선택합니다. 도메인, B-트리, 비트맵 및 비트맵 조인 인덱스에 대해 INDEX 힌트를 사용할 수 있습니다. 그러나 Oracle은 여러 인덱스 조합에 INDEX보다 INDEX_COMBINE을 사용할 것을 권장합니다. 

SELECT /*+ INDEX (employees emp_department_ix)*/ 
       employee_id, department_id 
  FROM employees 
  WHERE department_id > 50;

NO_INDEX hint

NO_INDEX 힌트는 지정된 테이블에 대한 인덱스 집합을 허용하지 않습니다.  

SELECT /*+ NO_INDEX(employees emp_empid) */ employee_id 
  FROM employees 
  WHERE employee_id > 200; 

 

 

 

 

2.4 Hints for Join Orders

• LEADING
• ORDERED

2.6 Hints for Online Application Upgrade

온라인 애플리케이션 업그레이드 힌트는 에디션 기반 재정의를 사용하여 온라인 애플리케이션 업그레이드를 수행할 때 충돌하는 INSERT 및 UPDATE 작업을 처리하는 방법을 제안합니다.

• CHANGE_DUPKEY_ERROR_INDEX
• IGNORE_ROW_ON_DUPKEY_INDEX
• RETRY_ON_ROW_CHANGE

2.7 Hints for Parallel Execution

병렬 실행 힌트는 작업을 병렬화할지 여부와 방법에 대해 지시합니다. 다음 병렬 힌트를 사용할 수 있습니다.

• PARALLEL and NO_PARALLEL
• PARALLEL_INDEX and NO_PARALLEL_INDEX
• PQ_DISTRIBUTE

DBMS_XPLAN 을 사용하기 위해 필요한 권한입니다.

• V$SQL
• V$SQL_PLAN
• V$SQL_PLAN_STATISTICS_ALL
• V$SESSION

DBMS_XPLAN 실행권한이 없는 DB 사용자에 아래와 같이 실행권한을 부여합니다.

GRANT SELECT ON sys.v_$sql TO 유저명;
GRANT SELECT ON sys.v_$sql_plan TO 유저명;
GRANT SELECT ON sys.v_$sql_plan_statistics_all TO 유저명;
GRANT SELECT ON sys.v_$session TO 유저명;

실행계획

Oracle 실행 계획은 요청된 데이터에 액세스하는 방법을 보여주는 세부 단계의 집합입니다. 실행 계획의 각 단계는 행을 생성하거나 소비하는 데이터베이스 연산자 집합입니다.

실행계획 관련 파라미터는 timed_statistics 와 statistics_level 이 있고 힌트는 /*+ gather_plan_statistics */ 이 있습니다.

< TIMED_STATISTICS >

TIMED_STATISTICS는 시간과 관련된 통계 수집 여부를 지정합니다. 값은 true 또는 false 입니다.

• true : 통계는 trace 파일에 수집되거나 V$SESSTATS및 V$SYSSTATS 동적 뷰에 표시됩니다.
• false : 모든 시간 관련 통계 값은 0으로 설정됩니다. 이 설정을 사용하면 Oracle이 운영 체제에서 시간을 요청하는 오버헤드를 피할 수 있습니다.

11.1.0.7.0부터 STATISTICS_LEVEL의 값이 TYPICAL 또는 ALL로 설정된 경우 TIMED_STATISTICS 값을 false 로 설정할 수 없습니다. TIMED_STATISTICS를 true 로 설정하면 더 정확한 통계를 생성할 수 있습니다.

< STATISTICS_LEVEL >

STATISTICS_LEVEL은 데이터베이스 및 운영체제 통계정보에 대한 수집 수준을 지정합니다. 값은 basic, typical, all 중 하나입니다. 기본값은 typical 입니다.

• TYPICAL : 데이터베이스 자체 관리 기능에 필요한 모든 주요 통계 수집
• ALL : TYPICAL 설정으로 수집된 통계정보에 부가적인 통계 추가. 부가적인 통계는 시간이 지정된 운영 체제 통계 및 계획 실행 통계입니다.
• BASIC : Oracle Database 기능에 필요한 많은 중요한 통계 수집이 비활성화됨

/*+ gather_plan_statistics */

GATHER_PLAN_STATISTICS 힌트는 "Row source execution" 정보를 활성화합니다.

Row source execution 이란 Explain Plan에서 보는 Row수의 예측 값이 아닌 실제 실행 과정에서 추출된 Row 수를 보여줍니다.

오라클에서 실제 SQL문을 실행하는 동안의 실행 계획을 각 Row Source별로 수행통계를 수집하기 위해 gather_plan_statistics 힌트를 사용하거나 statistics_level 파리미터를 all로 설정합니다. 즉 statistics_level = all 과 /*+ gather_plan_statistics */ 힌트는 동일하게  추가적인 SQL 실행통계를 수집합니다.

/*+ gather_plan_statistics */ 힌트는 실행통계 데이터를 PLAN_TABLE에 저장하지 않고, V$SQL_PLAN 뷰에 저장합니다..

실행 계획을 보는 방법에는 EXPLAIN PLAN과 SET AUTORACE, SQL TRACE, DBMS_XPLAN 등이 있습니다.

1) EXPLAIN PLAN

EXPLAIN PLAN
SET STATEMENT_ID = 'HR_PLAN' INTO PLAN_TABLE --INTO PLAN_TABLE은 생략 가능
FOR
SELECT * 
FROM REGIONS A, COUNTRIES B 
WHERE  A.REGION_ID = B.REGION_ID;

 -- DBMS_XPLAN으로 PLAN 보기
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE','HR_PLAN','ALL'));

 -- SQL로 PLAN 보기
SELECT
    lpad(' ', level - 1)||operation|| ' ('|| options||')' "Operation",
    object_name       "Name",
    optimizer         "Optimizer",
    cost              "Cost",
    cardinality       "Cardinality",
    bytes             "Bytes",
    partition_start   "Partition Start",
    partition_id      "Partition ID"
   FROM plan_table
CONNECT BY prior id = parent_id AND prior statement_id = statement_id
  START WITH id = 0 AND statement_id = '&1'
  ORDER BY id;

EXPLAIN PLAN의 사용법은 SELECT문 앞에 실행 계획을 저장하라는 EXPLAIN PLAN 명령어를 사용하고 실행할 SQL에 statement ID를 부여한 다음 FOR를 쓰면 됩니다. 이렇게 쿼리문의 실행계획을 PLAN_TABLE에 저장한 후 직접 조회하거나 DBMS_XPLAN 패키지를 사용하여 조회하면 됩니다. EXPLAIN PLAN은 SQL의 실행 계획만을 수립하고 SQL문은 수행하지 않습니다. DBMS_XPLAN 패키지를 사용하는 것이 편리하고 효율적이지만, 추가적인 정보(Partition 정보 등)를 보고자 할 때 SQL 문을 수행할 수 있습니다. 

다만 EXPLAIN PLAN은 한번에 하나의 쿼리문의 실행계획만을 확인할 수 있고 그 실행계획을 또 확인하기 위해 별도의 SELECT문을 작성해야하는 번거로움과 데이터를 읽지 않기 떄문에 소요시간을 추정한다거나 데이터 관련 I/O정보를 확인할 수 없다는 점이 단점입니다.

2) AUTOTRACE 

SET AUTOTRACE ON;

SELECT * 
FROM REGIONS A, COUNTRIES B 
WHERE  A.REGION_ID = B.REGION_ID;

SET AUTOTRACE 명령어를 사용하면 쿼리문을 실행시킬 때마다 실행계획을 바로 확인할 수 있습니다. AUTOTRACE의 옵션을 활용하여 통계정보, 실행계획, 실제 데이터 조회 여부 등을 조정할 수 있습니다.

AUTOTRACE가 안될 경우

AUTOTRACE도 마찬가지로 PLAN_TABLE 테이블이 생성되어 있어야 하고 plustrace 라는 롤이 부여되어 있어야 합니다. plustrace 롤은 기본적으로 생성되어 있지 않으므로 sysdba로 아래 sql을 수행하여 role을 생성해 줍니다.

SQL> @$ORACLE_HOME/sqlplus/admin/plustrce.sql

PLUSTRACE ROLE을 사용자에게 부여합니다.

$ sqlplus "/as sysdba"

SQL> grant plustrace to <user>;

이제 set autotrace on 명령어를 사용할 수 있습니다.

AUTOTRACE 주요 옵션

3) SQL TRACE 

SQL TRACE는 실행 계획뿐만이 아니라 여러 세션에서 수행한 SQL의 통계 정보, 수행시간, 결과 등을 TRACE 파일로 기록하여 이를 파일 형태로 저장하는 방법을 말합니다. SQL Trace는 실행되는 SQL문의 실행통계를 세션별로 모아서 Trace 파일을 만듭니다. 이때 만들어지는 파일은 .trc의 확장자를 갖습니다. 이 .trc 파일들은 바이너리 형태로 저장되기에 읽기 편한 형태로 파일을 변환하는 과정이 필요한데 TKPROF 유틸리티를 이용하여 변환합니다.

또한 SQL Trace는 세션 레벨과 인스턴스 레벨에서 SQL 문장들을 분석 할 수 있는데 인스턴스 레벨로 SQL Trace를 수행시키면 DBMS에 성능에 영향이 있으므로 인스턴스스 레벨의 SQL Trace는 설정하지 않도록 합니다.

sql trace 설정 및 해제

SQL> alter session set sql_trace = true;
OR
SQL> execute dbms_system.set_sql_trace_in_session(true);

-- 특정 세션 sql trace 설정
SQL> execute dbms_system.set_sql_trace_in_session(session_id, serial_id, true);

-- session level sql trace 종료
SQL> alter session set sql_trace = false;
-- 특정 세션 sql trace 설정 해제
SQL> execute dbms_system.set_sql_trace_in_session(session_id, serial_id, false);

DBMS_SYSTEM 패키지 는 SYS 계정만 사용할 수 있습니다. 일반 계정이 dbms_system 패키지를 사용하려면 아래와  같이 synonym 생성 및 실행권한을 부여합니다. 일반계정에 dbms_system 실행권한을 부여할 경우에는 영향도 검토를 충분히 한 다음에 부여합니다.

SQL> CREATE PUBLIC SYNONYM dbms_system FOR dbms_system;
SQL> grant execute on dbms_system to <user>

-- To grant privileges to all users:
SQL> grant execute on dbms_system to public

trace 파일

sql_trace를 true로 설정한 session에서 수행한 sql 문에 대한 상세 정보는 diag 디렉토리에 SID_ora_spid.trc 라는 파일 이름으로 저장됩니다. 이 디렉토리에는 많은 trc 파일이 존재하므로, 특정 세션의 spid를 알아야 그 세션에서 생성한 파일임을 쉽게 알 수 있습니다.

trace 파일은 diagnostic_dest 로 정의된 디렉토리 하위에 diag/rdbms/orcl/ORCL/trace 경로에 존재합니다.

예시에서는 diagnostic_dest가 /data 이므로 /data/diag/rdbms/orcl/ORCL/trace 경로에 trace 파일이 생성됩니다. 경로는 각자의 SID에 따라 상이합니다.

$ sqlplus hr/<password>
SQL> select sys_context('USERENV', 'SID') from dual;

-- 위에서 확인한 SID 를 아래 &SID에 입력
select b.spid
  from v$session a, v$process b
 where a.sid = &sid
   and b.addr = a.paddr;

22978

## diagnostic 경로 확인(trace 파일이 저장되는 경로)
$ sqlplus "/as sysdba"
SQL> show parameter diag;
diagnostic_dest                      string      /data

SQL> exit;

$ cd /data/diag/rdbms/orcl/ORCL/trace

## 위에서 찾은 SPID로 trace 파일을 찾는다. trace 파일명은 SID_ora_spid.trc 형태임
## 예로 SID가 ORCL이고 spid가 22987인 경우 trace 파일은 ORCL_ora_22987.trc 

$ ls ORCL_ora_22987.trc

tkprof - trace 파일 분석

tkprof 명령어는 binary trace 파일을 text 파일 형태로 읽기 쉽게 변환해 줍니다.

$ tkprof trace_file.trc output_file.txt sys=no

## 위의 trace 파일을 tkprof 로 분석
$ tkprof ORCL_ora_22987.trc output_file.txt sys=no
## tkprof 로 분석한 내용을 확인(vi or vim)
$ vi output_file.txt

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.00       0.00          0          0          0           0
Execute     14      0.00       0.00          0          0          0           0
Fetch       14      0.00       0.00          0         28          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       32      0.00       0.00          0         28          0           2

Misses in library cache during parse: 3
Misses in library cache during execute: 3

sys=no 옵션은 시스템 내부적으로 수행되는 SQL 문을 분석 대상에서 제외합니다.

4) DBMS_XPLAN 패키지

DBMS_XPLAN.DISPLAY(
   table_name    IN  VARCHAR2  DEFAULT 'PLAN_TABLE',
   statement_id  IN  VARCHAR2  DEFAULT  NULL, 
   format        IN  VARCHAR2  DEFAULT  'TYPICAL',
   filter_preds  IN  VARCHAR2 DEFAULT NULL);

SELECT * FROM table (DBMS_XPLAN.DISPLAY);

SELECT * FROM table (DBMS_XPLAN.DISPLAY('my_plan_table'));

SELECT * FROM table (DBMS_XPLAN.DISPLAY('plan_table', null, 'basic'));

SELECT * FROM table (DBMS_XPLAN.DISPLAY('plan_table', 'foo'));

Syntax

DBMS_XPLAN.DISPLAY_CURSOR(
   sql_id            IN  VARCHAR2  DEFAULT  NULL,
   cursor_child_no   IN  NUMBER    DEFAULT  0, 
   format            IN  VARCHAR2  DEFAULT  'TYPICAL');

예제

SELECT * FROM table (DBMS_XPLAN.DISPLAY_CURSOR);

SELECT * FROM table (DBMS_XPLAN.DISPLAY_CURSOR('atfwcg8anrykp'));

SELECT * FROM table (DBMS_XPLAN.DISPLAY_CURSOR('atfwcg8anrykp', NULL, 'ALLSTATS LAST');

DBMS_XPLAN에서 제공하는 모든 통계 정보를 표시하려면 아래와 같이 수행합니다.

 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('atfwcg8anrykp', '0', 'advanced allstats last'))

위와 같이 다양한 방법으로 SQL문의 실행 계획과 그에 따른 통계정보를 확인할 수 있습니다.

사전 예측정보는 실제 수행 통계와 상이할 수 있으므로 간단한 SQL 실행계획 확인용으로 사용하고,

SQL튜닝을 위한 상세 정보를 위해서는 DBMS_XPLAN.DISPLAY_CURSOR를 활용합니다.

parsing, fetch, query block, current block 등의 추가 정보가 필요한 경우에는 tkprof 를 활용합니다. 

SQL 튜닝 절차

1. 튜닝대상 SQL 식별 :

     AWR report, APM 툴, DB 모니터링 툴, 개발자 요청, 전수조사, 샘플조사 등

2. 튜닝대상 SQL의 sql_id 추출 :

     SQL_ID가 제공된 경우에는 제공된 sql_id를 사용하고 그렇지 않은 경우에는V$SQLAREA, V$SQL,           

     DBA_HIST_SQLTEXT, DBA_HIST_SQLSTAT 등의 뷰에서 추출합니다.

3. DBMS_XPLAN.DISPLAY_CURSOR 수행 :

    추출한 sql_id 를 가지고  DBMS_XPLAN.DISPLAY_CURSOR 패키지로 실행계획, 통계 정보 등을 조회합니다.

4. SQL 튜닝

    인덱스 생성, SQL 재작성, SQL분리, 힌트 사용, 데이터모델 변경, 반정규화, 요약테이블 생성  등으로 SQL 문장을 튜닝합니다.

오라클은 입력된 바인드 값이 32, 128, 2000, 4000 바이트를 넘을 때마다 새로운 Child 커서를 생성한다.

즉, bind 변수를 사용한 SQL 이라도 bind 변수값의 길이가 위의 구간에 따라 새로운 Child 커서가 생성된다.

아래의 테스트 케이스로 확인해 본다.

varchar2(4000) 컬럼을 가진 테스트 테이블을 생성한다.

create table tab1 ( col1 varchar2(4000));

아래 프로시저를 수행한 후 결과값을 보면 정확히 32, 128, 2000, 4000 바이트 구간에서 child 커서가 생성되는 것을 볼 수 있다.

set serveroutput on

declare
  l_cnt number;
  l_child_cnt number;
  l_prev_child_cnt number;
  l_bind_value varchar2(4000);
  l_sql_id varchar2(13);
begin

  l_prev_child_cnt := 0;

  for c in 1..4000
  loop
    l_bind_value := lpad('A', c, '0');  
    select count(*) into l_cnt from tab1 where col1 = l_bind_value;

    if c = 1 then
      select prev_sql_id into l_sql_id -- sql_id 를 찾음
      from   v$session
      where  sid = userenv('sid')
      and    username is not null
      and    prev_hash_value <> 0;
      dbms_output.put_line('sql_id --> ' || l_sql_id);
    end if;

    select count(*) into l_child_cnt from v$sql where sql_id = l_sql_id;

    if l_prev_child_cnt < l_child_cnt then -- 새 Child 커서 생길 때마다
      dbms_output.put_line(c);
      l_prev_child_cnt := l_child_cnt;
    end if;

  end loop;
end;
/

sql_id --> 4bp0vskw058t3
1
33
129
2001

PL/SQL procedure successfully completed.

child 커서가 공유되지 못한 이유를 보기위해서는 V$SQL_SHARED_CURSOR 뷰를 조회해 본다.

위의 테스트 결과는 hash_match_failed 컬럼과 bind_lentgh_upgradeable 컬럼값이 'Y' 인 것을 볼 수 있다.

즉 child 커서를 공유하지 못한 이유가 hash_match_fail, bind_lentgh 때문이라는 것을 알 수 있다. hash_match_fail 은 histogram이 생성되어 있지 않아서 발생하는 것 같다.

HASH_MATCH_FAILED

Hash mismatch. Set to "Y" if sharing fails due to a hash mismatch, such as the case with mismatched histogram data or a range predicate marked as unsafe by literal replacement (See Bug 3461251)


BIND_LENGTH_UPGRADEABLE Bind length upgradeable and could not be shared because a bind variable size was smaller than the new value being inserted
(marked as BIND_MISMATCH in earlier versions).

reson 컬럼에는 Bind mismatch로 표시된다.

select
    sh.sql_id,
    sh.child_number, sh.hash_match_failed, sh.bind_length_upgradeable,
    xt.r1
from
    v$sql_shared_cursor sh
    inner join xmltable (
        '/ChildNode'
        passing xmlparse(content sh.reason)
        columns
            r1 varchar2(40) path 'reason'
    ) xt on ( 1 = 1 )
where sh.sql_id = '4bp0vskw058t3';


SQL_ID	CHILD_NUMBER	HASH_MATCH_FAILED	BIND_LENGTH_UPGRADEABLE	R1
4bp0vskw058t3	0	N	N	Bind mismatch(22)
4bp0vskw058t3	1	Y	Y	Bind mismatch(22)
4bp0vskw058t3	2	Y	Y	Bind mismatch(22)
4bp0vskw058t3	3	Y	Y	Bind mismatch(22)

* 참고 : child 커서가 공유되지 않는 이유

• USE_FEEDBACK_STATSCardinality feedback. Cardinality feedback is being used and therefore a new plan could be formed for the current execution.

BIND_EQUIV_FAILUREThe bind value's selectivity does not match that used to optimize the existing child cursor. When adaptive cursor sharing is used and the cursor is bind aware, then if the selectivity is outside of the current ranges and a new plan is desirable then a new child is raised with this as the reason code for non-sharing of the previous plan. For an example, see Document 836256.1. After each execution in the example, run:

select sql_id, address, child_address, child_number, BIND_EQUIV_FAILURE 
from v$sql_shared_cursor where sql_id='19sxt3v07nzm4';

once the cursor is marked as bind aware and a second plan is seen then the following will be the resultant output:  

SQL_ID        ADDRESS          CHILD_ADDRESS    CHILD_NUMBER B
------------- ---------------- ---------------- ------------ -
19sxt3v07nzm4 000000007A1C0DE0 000000007A1BF980            0 N
19sxt3v07nzm4 000000007A1C0DE0 000000007A10DDB0            1 Y

As can be seen, the new version is created due to BIND_EQUIV_FAILURE

Parent and Child Cursors

(상위 커서/하위 커서, 부모 커서/자식 커서)

"커서"는 사용자가 실행하는 SQL 문에 할당되는 라이브러리 캐시의 메모리 영역입니다. 이 메모리 영역은 SQL 텍스트, SQL 실행 계획, 통계 등과 같은 SQL 문에 대한 주요 정보를 저장합니다.

각 SQL 문에는 하나의 상위 커서와 하나 이상의 하위 커서가 있습니다. 상위 및 하위 커서가 무엇인지 설명합니다.
커서 = 메모리 영역을 염두에 두십시오.

왜 커서가 두 종류인가?

두 종류의 커서(부모 및 자식)가 있는 것은 Oracle 데이터베이스 설계에 따른 것입니다.

실행하는 각 SQL 문에 대해 Oracle 엔진은 상위 및 하위 커서라는 두 개의 커서를 생성합니다. 동일한 SQL 문에 대해 다른 바인드 값이나 두 개의 다른 스키마 또는 다른 리터럴 값 등이 있을 수 있는 것과 같은 다른 차이점이 있을 수 있기 때문에 두 개의 커서가 생성됩니다.

상위 커서는 SQL 문을 보유하고 하위 커서는 정보를 보유합니다. 차이점과 관련이 있습니다. 이것은 본질적으로 SQL 문이 하드 또는 소프트 구문 분석을 수행할 것인지 여부를 결정하는 요소로 자식 커서를 만듭니다.

PARENT CURSOR

• 커서의 SQL 텍스트를 저장합니다. 두 문장이 동일한 경우 동일한 상위 커서를 공유합니다.
• 모든 상위 커서는 그에 대해 생성된 하나 이상의 하위 커서와 함께 실행됩니다.
• 상위 커서는 V$SQLAREA 뷰에 표시됩니다. v$sqlarea의 VERSION_COUNT 열은 이 부모 커서에 몇 개의 자식 커서가 있는지 알려줍니다.

CHILD CURSOR

• 부모 커서는 적어도 하나의 자식 커서를 가진다.
• 상위 커서는 SQL 텍스트를 저장하지만, 하위 커서는 환경 정보, 통계 정보, 바인드 변수 정보, 실행 세부 정보와 같은 SQL 문과 관련된 중요한 정보를 저장합니다.
  
• SQL 텍스트가 자식 커서에 저장되지 않으므로 자식 커서는 메모리 공간을 덜 차지합니다.
  
• 모든 자식 커서는 부모에 속해야 합니다.
  
• 쿼리에 대해 자식 커서는 하드 파싱을 할지 또는 소프트 파싱을 할지를 결정합니다. SQL 쿼리가 동일해서 부모 커서는 동일하지만 자식  커서가 공유되지 않고 하드 파싱(재컴파일)을 하는 상황이 있을 수 있습니다.
  
• 상위 커서는 V$SQL 보기에 표시됩니다.
  
• V$SQL_SHARED_CURSOR는 옵티마이저가 커서를 비공유로 표시하기로 결정한 이유를 제공하므로 매우 유용한 보기입니다. 따라서 SQL 문이 동일하지만 하드파싱이 발생 때 이 뷰를 참조합니다.

V$SQL_SHARED_CURSOR

동일한 상위 커서에 대해 둘 이상의 하위 커서가 생성되되어었을 때 기존 하위 커서와 공유되지 않는 이유를 설명합니다. 뷰의 각 열은 커서를 공유할 수 없는 이유를 식별합니다. 공유되지 않은 사유의 열 값은 "Y" 로 표시됩니다.

특정 자식은 여러 가지 이유로 공유에 실패했을 수 있습니다. 이 이유는 다른 기존 자식 커서를 사용하려는 이유가 됩니다.

cursor_sharing 파라미터

CURSOR_SHARING은 어떤 SQL이 동일한 커서를 공유할 수 있는지를 결정합니다. 세 가지 값이 있습니다.

EXACT

동일한 텍스트가 있는 SQL 구문만 동일한 커서를 공유할 수 있습니다.

FORCE

일부 문자가 다를 경우 그 문자가 SQL문의 의미에 영향을 미치지 않는 한 강제로 커서를 공유합니다.

SIMILAR

문자가 SQL문의 의미나 실행계획 최적화에 영향을 미치지 않는 한 일부 문자가 달라도 동일한 커서로 공유하도록 합니다.
cursor_sharing의 default는 EXACT입니다.

예를 들어 아래 두 개의 서로 다른 SQL 문이 있습니다.

select * from EMP WHERE EMPNO=7369;
select * from EMP where EMPNO=7369;

둘 다 동일한 결과를 생성하지만 이들은 서로 다른 SQL입니다. "where"를 보면 첫 번째 문장에서는 대문자로, 두 번째 문장에서는 소문자로 작성되어 있는데 Oracle optimizer는 두 개를 상이한 SQL로 판단합니다.

V$SQLAREA 뷰를 조회합니다. 부모 커서에 대한 정보를 보여줍니다.

V$SQLAREA 에서는 SQL문에 대한 Parsing 정보 (sql text, sql_id, parse calls, executions 등)와 메모리 사용량, CPU 사용량, 수행시간, 모듈정보 등 외에도 많을 정보를 확인할 수 있습니다.

select *
from  v$sqlarea 
where upper(sql_text) like upper('%select * from EMP%7369%')
and   upper(sql_text) not like upper('%v$sqlarea%');

-- SQL 수행경과
SQL_TEXT	SQL_ID	SHARABLE_MEM	PERSISTENT_MEM	RUNTIME_MEM	SORTS	VERSION_COUNT	LOADED_VERSIONS	OPEN_VERSIONS	USERS_OPENING	FETCHES	EXECUTIONS	PX_SERVERS_EXECUTIONS	END_OF_FETCH_COUNT	USERS_EXECUTING	LOADS	FIRST_LOAD_TIME	INVALIDATIONS	PARSE_CALLS	DISK_READS	DIRECT_WRITES	DIRECT_READS	BUFFER_GETS	APPLICATION_WAIT_TIME	CONCURRENCY_WAIT_TIME	CLUSTER_WAIT_TIME	USER_IO_WAIT_TIME	PLSQL_EXEC_TIME	JAVA_EXEC_TIME	ROWS_PROCESSED	COMMAND_TYPE	OPTIMIZER_MODE	OPTIMIZER_COST	OPTIMIZER_ENV	OPTIMIZER_ENV_HASH_VALUE	PARSING_USER_ID	PARSING_SCHEMA_ID	PARSING_SCHEMA_NAME	KEPT_VERSIONS	ADDRESS	HASH_VALUE	OLD_HASH_VALUE	PLAN_HASH_VALUE	FULL_PLAN_HASH_VALUE	MODULE	MODULE_HASH	ACTION	ACTION_HASH	SERIALIZABLE_ABORTS	OUTLINE_CATEGORY	CPU_TIME	ELAPSED_TIME	OUTLINE_SID	LAST_ACTIVE_CHILD_ADDRESS	REMOTE	OBJECT_STATUS	LITERAL_HASH_VALUE	LAST_LOAD_TIME	IS_OBSOLETE	IS_BIND_SENSITIVE	IS_BIND_AWARE	CHILD_LATCH	SQL_PROFILE	SQL_PATCH	SQL_PLAN_BASELINE	PROGRAM_ID	PROGRAM_LINE#	EXACT_MATCHING_SIGNATURE	FORCE_MATCHING_SIGNATURE	LAST_ACTIVE_TIME	BIND_DATA	TYPECHECK_MEM	IO_CELL_OFFLOAD_ELIGIBLE_BYTES	IO_INTERCONNECT_BYTES	PHYSICAL_READ_REQUESTS	PHYSICAL_READ_BYTES	PHYSICAL_WRITE_REQUESTS	PHYSICAL_WRITE_BYTES	OPTIMIZED_PHY_READ_REQUESTS	LOCKED_TOTAL	PINNED_TOTAL	IO_CELL_UNCOMPRESSED_BYTES	IO_CELL_OFFLOAD_RETURNED_BYTES	CON_ID	IS_REOPTIMIZABLE	IS_RESOLVED_ADAPTIVE_PLAN
select * from EMP WHERE EMPNO=7369	2zp7d0gmunwfj	23539	8888	6752	0	1	1	0	0	1	1	0	1	0	1	2022-01-02/00:18:14	0	1	0	0	0	7	0	0	0	0	0	0	1	3	FIRST_ROWS	3	E289FB89D011220170020080AEF5C3E2CFFA332056414555519521105545551545545558591555449665851D5511058555555155515122555415A0EA0C5551454265415454449081566E001696C6A355451501025415404416FD157151551555550001550A16214545D1C31444A1011015595510250153355555155551E91F1411855B0501655D56456144551525245005F9A4160090505165551695504415957945000544000A5AD01122010502000002000000100000000100002000000210D007000000D00700002003000101000038F8000200000090010000E80300D0112201026564640202643202320000020003020A0A05050A1400020000F4010000640A0A0A0A64E803000064C010030200020000FFFF00000202324000400000E803000010270000002000000A1E03C80000080000010000102700000304810A80969800E80300004B64FFFF0000FFFF00000010000014A08601006440204E00000702C8C823F8FF0000FFFF00000204400A1450320A0A00001000	3703031112	95	95	SCOTT	0	000000008CA91018	3886707153	3891276153	3956160932	3634526668	TOAD 12.8.0.49	2077942562		0	0		835	1118		000000008CA908C0	N	VALID	0	2022-01-02 오전 12:18:14	N	N	N	0				0	0	3.83665796575199E18	1.6946033956547E19	2022-01-02 오전 12:18:14		0	0	0	0	0	0	0	0	1	2	0	0	0	N	
select * from EMP where EMPNO=7369	fah6htfu5fdjg	23539	8888	6752	0	1	1	1	0	1	1	0	1	0	1	2022-01-02/00:18:15	0	1	0	0	0	7	0	0	0	0	0	0	1	3	FIRST_ROWS	3	E289FB89D011220170020080AEF5C3E2CFFA332056414555519521105545551545545558591555449665851D5511058555555155515122555415A0EA0C5551454265415454449081566E001696C6A355451501025415404416FD157151551555550001550A16214545D1C31444A1011015595510250153355555155551E91F1411855B0501655D56456144551525245005F9A4160090505165551695504415957945000544000A5AD01122010502000002000000100000000100002000000210D007000000D00700002003000101000038F8000200000090010000E80300D0112201026564640202643202320000020003020A0A05050A1400020000F4010000640A0A0A0A64E803000064C010030200020000FFFF00000202324000400000E803000010270000002000000A1E03C80000080000010000102700000304810A80969800E80300004B64FFFF0000FFFF00000010000014A08601006440204E00000702C8C823F8FF0000FFFF00000204400A1450320A0A00001000	3703031112	95	95	SCOTT	0	000000008C9AD6E0	3025614383	4198020274	3956160932	3634526668	TOAD 12.8.0.49	2077942562		0	0		1245	1280		000000008A6EEB18	N	VALID	0	2022-01-02 오전 12:18:15	N	N	N	0				0	0	3.83665796575199E18	1.6946033956547E19	2022-01-02 오전 12:18:15		0	0	0	0	0	0	0	0	1	2	0	0	0	N

Oracle DB 에서 실행한 SQL 내역을 조회하고자 할때 v$sql 딕셔너리 뷰를 이용할 수 있습니다.

V$SQL을 조회해 봅니다. 아래와 같이 2개의 SQL 문이 조회됩니다.

v$sql 에는 실행한 SQL 문과 실행 시작시간, 종료시간, 경과시간 등의 다양한 정보가 들어있습니다.

select sql_text, sql_id, sharable_mem, loaded_versions, open_versions, executions, 
       loads, parse_calls, buffer_gets, rows_processed, elapsed_time,
       is_obsolete, is_bind_sensitive, is_bind_aware
from   v$sql 
where  upper(sql_text) like upper('%select * from EMP%7369%')
and    upper(sql_text) not like upper('%v$sql%');

-- SQL 수행결과
SQL_TEXT	SQL_ID	SHARABLE_MEM	LOADED_VERSIONS	OPEN_VERSIONS	EXECUTIONS	LOADS	PARSE_CALLS	BUFFER_GETS	ROWS_PROCESSED	ELAPSED_TIME	IS_OBSOLETE	IS_BIND_SENSITIVE	IS_BIND_AWARE
select * from EMP WHERE EMPNO=7369	2zp7d0gmunwfj	23539	1	0	1	1	1	7	1	1118	N	N	N
select * from EMP where EMPNO=7369	fah6htfu5fdjg	23539	1	1	1	1	1	7	1	1280	N	N	N

V$SQL_SHARED_CURSOR

로드된 각 자식 커서에 대한 정보를 보여줍니다.
커서를 공유할 수 없는 이유를 설명하는 컬럼을 가지고 있습니다.

select * from v$sql_shared_cursor
where  sql_id in('2zp7d0gmunwfj','fah6htfu5fdjg');

-- SQL 수행 결과
SQL_ID	ADDRESS	CHILD_ADDRESS	CHILD_NUMBER	UNBOUND_CURSOR	SQL_TYPE_MISMATCH	OPTIMIZER_MISMATCH	OUTLINE_MISMATCH	STATS_ROW_MISMATCH	LITERAL_MISMATCH	FORCE_HARD_PARSE	EXPLAIN_PLAN_CURSOR	BUFFERED_DML_MISMATCH	PDML_ENV_MISMATCH	INST_DRTLD_MISMATCH	SLAVE_QC_MISMATCH	TYPECHECK_MISMATCH	AUTH_CHECK_MISMATCH	BIND_MISMATCH	DESCRIBE_MISMATCH	LANGUAGE_MISMATCH	TRANSLATION_MISMATCH	BIND_EQUIV_FAILURE	INSUFF_PRIVS	INSUFF_PRIVS_REM	REMOTE_TRANS_MISMATCH	LOGMINER_SESSION_MISMATCH	INCOMP_LTRL_MISMATCH	OVERLAP_TIME_MISMATCH	EDITION_MISMATCH	MV_QUERY_GEN_MISMATCH	USER_BIND_PEEK_MISMATCH	TYPCHK_DEP_MISMATCH	NO_TRIGGER_MISMATCH	FLASHBACK_CURSOR	ANYDATA_TRANSFORMATION	PDDL_ENV_MISMATCH	TOP_LEVEL_RPI_CURSOR	DIFFERENT_LONG_LENGTH	LOGICAL_STANDBY_APPLY	DIFF_CALL_DURN	BIND_UACS_DIFF	PLSQL_CMP_SWITCHS_DIFF	CURSOR_PARTS_MISMATCH	STB_OBJECT_MISMATCH	CROSSEDITION_TRIGGER_MISMATCH	PQ_SLAVE_MISMATCH	TOP_LEVEL_DDL_MISMATCH	MULTI_PX_MISMATCH	BIND_PEEKED_PQ_MISMATCH	MV_REWRITE_MISMATCH	ROLL_INVALID_MISMATCH	OPTIMIZER_MODE_MISMATCH	PX_MISMATCH	MV_STALEOBJ_MISMATCH	FLASHBACK_TABLE_MISMATCH	LITREP_COMP_MISMATCH	PLSQL_DEBUG	LOAD_OPTIMIZER_STATS	ACL_MISMATCH	FLASHBACK_ARCHIVE_MISMATCH	LOCK_USER_SCHEMA_FAILED	REMOTE_MAPPING_MISMATCH	LOAD_RUNTIME_HEAP_FAILED	HASH_MATCH_FAILED	PURGED_CURSOR	BIND_LENGTH_UPGRADEABLE	USE_FEEDBACK_STATS	CON_ID
2zp7d0gmunwfj	000000008CA91018	000000008CA908C0	0	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	0
fah6htfu5fdjg	000000008C9AD6E0	000000008A6EEB18	0	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	0

V$SQLAREA 는 부모 커서에 대한 정보를 담고 있고, V$SQL 은 자식 커서에 대한 정보를 담고 있습니다.

V$SQL_SHARED_CURSOR 은 커서를 공유하지 못한 사유에 대한 정보를 담고 있습니다.

< 참조>

• Performance Tuning Basics 1 : Selectivity and Cardinality
• Performance Tuning Basics 2 : Parsing
• Performance Tuning Basics 3 : Parent and Child Cursors
• Performance Tuning Basics 4 : Bind Variables
• Performance Tuning Basics 5 : Trace and TKPROF – Part 1: Trace
• Performance Tuning Basics 6 : Trace and TKPROF – Part 2: Generating TKPROF
• Performance Tuning Basics 7 : Trace and TKPROF – Part 3: Analyzing TKPROF Files
• Performance Tuning Basics 8 : Trace File Analyzer (TRCA)
• Performance Tuning Basics 9 : Optimizer Mode
• Performance Tuning Basics 10 : Histograms
• Performance Tuning Basics 11 : Steps to analyze a performance problem
• Performance Tuning Basics 12 : Dynamic Performance Views
• Performance Tuning Basics 13 : Automatic Workload Repository (AWR) Basics
• Performance Tuning Basics 14 : Active Sessions History (ASH) Basics
• Performance Tuning Basics 15 : AWR Report Analysis
• Performance Tuning Basics 16 : Using SQL Tuning Health-Check Script (SQLHC)