[SQLP필기풀이]1장 SQL 수행 구조

✍️ 1번 : 데이터베이스 아키텍처

🍒 문제 해설

1. 기본적으로 하나의 인스턴스가 하나의 데이터베이스만 액세스하지만, RAC(Real ApplicationCluster) 환경에서는 여러 인스턴스가 하나의 데이터베이스를 액세스할 수 있다.
2. 하나의 인스턴스가 여러 데이터베이스를 액세스할 수는 없다.

🍋 기출 포인트

1. 오라클에서는 디스크에 저장된 데이터 집합(Datafile, Redo Log File, Control File 등)을 '데이터베이스'라고 부른다.
   그리고 SGA 공유 메모리 영역과 이를 액세스하는 프로세스 집합을 합쳐서 '인스턴스'라고 부른다.

✍️ 2번 : 오라클 백그라운드 프로세스

오라클 백그라운드 프로세스에 대한 설명으로 가장 부적절한 것

1. System Monitor (SMON): 장애가 발생한 시스템을 재기동할 때 인스턴스 복구를 수행하고, 임시 세그먼트와 익스텐트를 모니터링한다. 👉 ⭕️
2. Process Monitor(PMON): 이상이 생긴 프로세스가 사용하던 리소스를 복구한다. 👉 ⭕️
3. Database Writers (DBWn) : 버퍼캐시에 있는 Dirty 버퍼를 데이터파일에 기록한다. 👉 ⭕️
4. Log Writer (LGWR) : 로그 버퍼에 로그를 기록한다. 👉 ❌

🍒 문제 해설

1. Archiver (ARCn): 꽉 찬 Redo 로그가 덮어 쓰여지기 전에 Archive 로그 디렉토리로 백업한다.
2. Checkpoint(CKPT) : Checkpoint 프로세스는 이전에 Checkpoint가 일어났던 마지막 시점 이후의 데이터베이스 변경 사항을 데이터파일에 기록하도록 트리거링하고, 기록이 완료되면 현재 어디까지 기록했는지를 컨트롤 파일과 데이터파일 헤더에 저장한다.
3. Write Ahead Logging 방식 : 데이터 변경(디스크) 전에 로그부터 남기는 메커니즘
4. 장애가 발생하면 마지막 체크포인트 이후 로그 데이터만 디스크에 기록함으로써 인스턴스를 복구한다.
5. Recoverer(RECO) : 분산 트랜잭션 과정에 발생한 문제를 해결한다.

🍋 기출 포인트

1. Log Writer (LGWR) : 로그 버퍼 엔트리를 Redo 로그 파일에 기록한다.
2. 로그 버퍼에 로그를 기록하는 것은 백그라운드 프로세스가 아니라 DIL을 수행하는 각 사용자 프로세스다.
   1.사용자 프로세스가 로그 버퍼에 로그를 기록하고 데이터 블록을 변경한 이후 Log Writer(LGWR)가 주기적으로 로그 버퍼 엔트리를 Redo 로그 파일에 기록한다.

✍️ 3번 : 데이터 저장 구조

데이터 저장 구조에 대한 설명으로 가장 부적절한 것

1. 블록(=페이지) : 데이터를 읽고 쓰는 단위 👉 ⭕️
2. 익스텐트 : 공간을 확장하는 단위 👉 ⭕️
3. 테이블스페이스 : 세그먼트를 담는 컨테이너로서, 여러 데이터파일로 구성 👉 ⭕️
4. 세그먼트 : 연속된 익스텐트 집합 👉 ❌

🍒 문제 해설

1. 블록(=페이지) : 대부분 DBMS는 블록 단위로 I/O 한다. 이는 하나의 레코드에서 하나의 컬럼만 읽더라도 그것이 속한 블록을 통째로 읽게 됨을 뜻한다.
2. 익스텐트 : 공간을 확장하는 단위다.
   테이블이나 인덱스에 데이터를 입력하다가 공간이 부족해지면 해당 오브젝트가 속한 테이블스페이스(물리적으로는 데이터파일)로부터 추가적인공간을 할당받는데,
   이때 정해진 익스텐트 크기의 연속된 블록을 할당받는다.
3. 세그먼트 : 데이터 저장공간을 사용하는 오브젝트(테이블, 인덱스, 파티션, 클러스터, LOB등)를 세그먼트라고 부른다.
   저장공간을 사용하지 않는 오브젝트(뷰, 시너닝, 시퀀스, 함수, 프로시저, 트리거 등)와 구분된다.
   저장공간을 사용한다는 것은 테이블스페이스로부터 한 개 이상의 익스텐트를 할당받음을 뜻한다. 세그먼트는 익스텐트의 집합이라고 말할 수 있는데, 익스텐트 내 블록이 논리적으로 서로 인접한 반면, 익스텐트끼리 서로 인접하지는않는다.
4. 테이블스페이스 : 세그먼트를 담는 컨테이너로서, 여러 데이터파일로 구성된다.
   ⭐️ 각 세그먼트는 정확히 한 테이블스페이스에만 속한다.⭐️
   한 테이블스페이스에는 여러 세그먼트가 존재할 수 있다
   ⭐️ 한 세그먼트는 여러 데이터파일에 걸쳐 저장된다. ⭐️
   한 테이블스페이스가 여러 데이터파일로 구성되기 때문이다.

🍋 기출 포인트

1. 세그먼트는 익스텐트의 집합이지만, 익스텐트끼리 서로 인접하지는 않는다.
   예를 들어,세그먼트에 익스텐트 2개가 할당됐는데 데이터파일 내에서 이 둘이 서로 멀리 떨어져
   있을 수 있다.

✍️ 5번 : 오라클이 Undo를 사용하는 목적

오라클이 Undo를 사용하는 목적과 가장 거리가 먼 것

1. Transaction Rollback 👉 ⭕️
2. Transaction Recovery 👉 ⭕️
3. Read Consistency 👉 ⭕️
4. Fast Commit 👉 ❌

🍋 기출 포인트

✅ Undo를 사용하는 목적

1) Transaction Rollback
2) Transaction Recovery (→ Instance Recovery 시 rollback 단계)
3) Read Consistency

✅ Redo 로그를 사용하는 목적

• 1) Database Recovery(=Media Recovery)
  • Redo 로그는 물리적으로 디스크에 결함이 생기는 등 Media Fail 발생 시 데이터베
    이스를 복구하기 위해 사용
  • 이때는 Archived Redo 로그를 이용하게 된다.
  • 'Media Recovery' 라고도 한다.
• 2) Cache Recovery(→ Instance Recovery 시 roll forward 단계)
  • Redo 로그는 Cache Recovery를 위해 사용된다.
  • 'Instance Recovery'라고도 한다.
  • 모든 데이터베이스 시스템이 1/0 성능을 위해 버퍼캐시를 사용하지만,버퍼캐시는 휘
    발성이다.
  • 캐시에만 적용한 변경사항을 아직 데이터파일에 기록하지 않은 상태에서 정전 등
    이 발생해 인스턴스가 비정상적으로 종료되면, 그때까지의 작업내용을 모두 잃게 된다.
  • 이러한 트랜잭션 데이터 유실에 대비하기 위해 Redo 로그를 남긴다.
• 3) Fast Commit
  • Redo 로그는 Fast Commit을 위해 사용된다.
  • 변경된 메모리 버퍼 블록을 데이터 파일에 기록하는 작업은 Randon 액세스 방식으로 이루어지기 때문에 느리다.
  • 반면 로그는 Append 방식으로 기록하므로 훨씬 빠르다.
  • 따라서 트랜잭션에 의한 변경사항을 건건이 데이터 파일에 기록하기보다 우선 Append 방식으로 빠르게 로그 파일에 기록하고, 버퍼캐시 블록과 데이터파일 블록 간 동기화는 적절한 수단(DBWR, Checkpoint)을 이용해 나중에 일괄(Batch) 수행한다.
  • 사용자가 요구한 갱신 사항을 휘발성인 버퍼캐시에만 기록한 채 아직 디스크에 영구 기록하지 않았더라도 Redo 로그를 믿고 빠르게 커밋을 완료한다
  • 이를 'Fast Commit'라고 한다.
  • 커밋 정보가 로그파일에 기록돼 있기만 하면, 인스턴스 Crash가 발생하더라도 Redo 로그를 이용해 언제든 복구 가능하므로 사용자 프로세스는 안심하고 커밋을 완료할수 있다.

✍️ 6번 : Redo 로그

Redo 로그에 대한 설명으로 가장 부적절한 것

1. Online Redo 로그는 인스턴스가 비정상적으로 종료되었을 때 캐시를 복구하기 위해 사용한다. 👉 ⭕️
2. Archived(=Offline) Redo 로그는 물리적인 저장 매체에 문제가 생겼을 때 데이터베이스를 복구하기 위해 사용한다. 👉 ⭕️
3. 대부분 DBMS는 Redo 로그를 이용해 Fast Commit을 구현한다. 👉 ⭕️
4. Online Redo 로그는 최소 두 개 이상의 파일로 구성해야 하며, 로그 스위치 주기는 빠를수록 좋다. 👉 ❌

🍋 기출 포인트

1. 동시에 많은 트랜잭션이 몰려 로그 스위치가 너무 자주 발생하면 자칫 백업(Archive)을 완료하지 못한 Online Redo 로그로 스위칭이 일어나면서 DB Hang이 발생할 수 있다. 그런 현상이 발생하지 않도록 적절한 크기와 적절한 개수의 Redo 파일을 할당해야 한다.

✍️ 7번 : Redo 메커니즘

Redo 메커니즘과 관련이 적은 것

1. Write Ahead Logging 👉 ⭕️
2. Log Force at Commit 👉 ⭕️
3. Fast Commit 👉 ⭕️
4. Snapshot Too Old 👉 ❌

🍒 문제 해설

✅ Fast Commit

• 사용자가 요구한 갱신 사항을 휘발성인 버퍼캐시에만 기록한 채 아직 디스크에 영구 기록하지 않았더라도 Redo 로그를 믿고 빠르게 커밋을 완료한다
• 커밋 정보가 로그파일에 기록돼 있기만 하면, 인스턴스 Crash가 발생하더라도 Redo 로그를 이용해 언제든 복구 가능하므로 사용자 프로세스는 안심하고 커밋을 완료할 수 있다.

✅ Log Force at commit ( 로그 버퍼 > 로그 파일 )

• DML을 수행하는 사용자 프로세스가 로그 버퍼에 로그를 기록하고 데이터 블록을 변경한다.
• 이후 Log Writer(LGMR)가 주기적으로 로그 버퍼 엔트리를 Redo 로그 파일에 기록한다.
• 메모리상의 로그 버퍼는 언제든 유실될 가능성이 있다.
• 따라서 트랜젝션의 영속성을 보장하려면 최소한 커밋 시점에는 로그를 메모리가 아닌 데이터파일에 안전하게 기록해야 한다.

✅ Write Ahead Logging ( 로그 파일 > 데이터 파일 )

• 버퍼캐시 블록을 갱신하기 전에 먼저 Redo 엔트리를 로그 버퍼에 기록해야 하며, DBWR가 버퍼캐시의 Dirty 블록들을 데이터파일에 기록하기 전에 먼저 LGWR가 해당 Redo 엔트리를 모두 Redo 로그 파일에 기록했음이 보장되어야 한다.

🍋 기출 포인트

1. 오라클은 데이터를 읽는 도중에 다른 트랜잭션에 의해 변경되었거나 변경이 진행 중인 블록을 만나면 과거 시점으로 되돌린 CR Copy 블록을 만들어서 읽는다.
   이때 Undo 정보를 이용하는데, 필요한 Undo 블록이 다른 트랜잭션에 의해 재사용(Overwriting)된 상태면 CR Copy를 생성할 수 없다.
   그럴 때 'Snapshot Too Old 에러가 발생하므로 이는 Undo와 관련된 메커니즘이다.

✍️ 8번 : 오라클 SGA 구성요소

오라클 SGA 구성요소가 아닌 것

1. 버퍼 캐시 👉 ⭕️
2. 딕셔너리 캐시 👉 ⭕️
3. 로그 버퍼 👉 ⭕️
4. Sort Area 👉 ❌

🍋 기출 포인트

1. Sort Area는 SGA가 아니라 PGA 할당된다.

✍️ 9번 : 오라클이 사용하는 메모리 캐시

오라클이 사용하는 메모리 캐시에 대한 설명으로 가장 부적절한 것

1. DB 버퍼캐시 : 테이블 블록, 인덱스 블록, Undo 블록을 캐싱 👉 ⭕️
2. 라이브러리 캐시 : DB 저장형 함수/프로시저, 트리거를 캐싱 👉 ⭕️
3. Result 캐시 : SQL 결과집합을 캐싱 👉 ⭕️
4. 딕셔너리 캐시 : SQL, 테이블 정보, 인덱스 정보, 데이터파일 정보, 시퀀스 등을 캐싱 👉 ❌

🍋 기출 포인트

1. SOL은 라이브러리 캐시에 캐싱된다.

✍️ 10번 : 버퍼 블록의 상태

버퍼캐시 블록과 데이터파일 블록 간 동기화가 필요한 블록

1. Dirty 버퍼 👉 ⭕️

🍒 문제 해설

1. Free 버퍼 : 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어 있는 상태(Clean 버퍼)이거나,
   데이터가 담겼지만 데이터파일과 서로 동기화돼 있는 상태여서 언제든지 덮어 써도 무방한 버퍼 블록을 말한다.
2. 오라클이 데이터파일로부터 새로운 데이터 블록을 로딩하려면 먼저 Free 버퍼를 확보해야 한다.
3. Free 상태인 버퍼에 변경이 발생하면 그 순간 Dirty 버퍼로 상태가 바뀐다.
4. Dirty 버퍼 : 버퍼캐시에 적재된 이후 변경이 발생했지만, 아직 데이터파일에 기록하지 않아 동기화가 필요한 버퍼 블록을 말한다.
5. Dirty 버퍼를 다른 데이터 블록을 위해 재사용하려면 데이터파일에 먼저 기록해야 하며, 그 순간 Free 버퍼로 상태가 바뀐다.
6. Pinned 버퍼 : 읽기 또는 쓰기 작업을 위해 현재 액세스되고 있는 버퍼 블록을 말한다.

✍️ 11번 : SQL 언어의 특징

SQL 언어의 특징과 가장 거리가 먼 것

1. 구조적(Structured) 👉 ⭕️
2. 집합적(Set-based) 👉 ⭕️
3. 선언적(Declarative) 👉 ⭕️
4. 절차적(Procedural) 👉 ❌

🍋 기출 포인트

1. 절차적 (procedural) 프로그래밍 기능을 구현할 수 있는 확장 언어는 오라클 PL/SQL, SOL Server T-SQL이다.
2. SQL은 기본적으로 구조적(structured)이고 집합적(set-based)이고 선언적(declarative)인 질의 언어다.

✍️ 12,13번 : SQL 처리 과정

SQL 처리 과정 중 문법적 오류 또는 의미상 오류가 없는지 확인하는 단계

1. SQL 파싱 👉 ⭕️
2. SQL 최적화 👉 ❌
3. 로우 소스 생성 👉 ❌
4. SOL 실행 👉 ❌

SQL 처리 과정 중 데이터 딕셔너리에 미리 수집해 둔 오브젝트 통계 및 시스템 통계 정보를 활용하는 단계

1. SQL 파싱 👉 ❌
2. SQL 최적화 👉 ⭕️
3. 로우 소스 생성 👉 ❌
4. SOL 실행 👉 ❌

🍒 문제 해설

✅ SQL을 실행하기 전 최적화 과정

• ① SQL 파싱
  • 사용자로부터 SQL을 전달받으면 가장 먼저 SQL 파서(Parser)가 파싱을 진행한다.
  • 파싱 트리 생성 : SQL 문을 이루는 개별 구성요소를 분석해서 파싱 트리 생성
  • Syntax 체크 : 문법적 오류가 없는지 확인
    • 예를 들어, 사용할 수 없는 키워드를 사용했거나 순서가 바르지 않거나 누락된 키워드가 있는지 확인
  • Semantic 체크 : 의미상 오류가 없는지 확인
    • 예를 들어, 존재하지 않는 테이블 또는 컬럼을 사용했는지, 사용한 오브젝트에 대한 권한이 있는지 확인
• ② SQL 최적화
  • 옵티마이저 (Optimizer)가 역할을 맡는다.
  • SQL 옵티마이저는 미리 수집한 시스템 및 오브젝트 통계정보를 바탕으로 다양한 실행경로를 생성해서 비교한 후 가장 효율적인 하나를 선택한다.
  • 데이터베이스 성능을 결정하는 가장 핵심적인 엔진이다.
  • [순서]
    • 1. 사용자로부터 전달받은 쿼리를 수행하는 데 후보군이 될만한 실행계획들을 도출한다.
    • 2. 데이터 딕셔너리(Data Dictionary)에 미리 수집해 둔 오브젝트 통계 및 시스템 통계정보 를 이용해 각 실행계획의 예상비용을 산정한다.
    • 3. 최저 비용을 나타내는 실행계획을 선택한다.
• ③ 로우 소스 생성
  • SQL 옵티마이저가 선택한 실행경로를 실제 실행 가능한 코드
    또는 프로시저 형태로 포맷팅하는 단계다.
  • 로우 소스 생성기(Row-Source Generator)가 그 역할을 맡는다.

✍️ 14번 : 비용(Cost) 기반 옵티마이저

SQL 최적화 단계에서 옵티마이저는 실행계획 후보군을 많이 생성한 후 그 중 하나를 선택한다. 이때 최종 하나를 선택하는 궁극의 기준?

1. 예상 비용(Cost) 👉 ⭕️
2. 예상 처리건수(Rows) 👉 ❌
3. 예상 CPU 사용량(Usage) 👉 ❌
4. 예상 랜덤 1/0 발생량 👉 ❌

🍋 기출 포인트

1. 비용기반 옵티마이저는 사용자로부터 전달받은 쿼리를 수행하는 데 후보군이 될만한 실행계획들을 찾아내서 각각의 예상 비용을 산정한 후 최저 비용을 나타내는 하나를 선택한다.

✍️ 15번 : 오라클 옵티마이저 힌트

오라클 옵티마이저 힌트에 대한 설명으로 가장 적절한 것

1. 옵티마이저 힌트는 명령어(directives)이므로 특별한 이유가 없는 한 그대로 실행된다. 👉 ⭕️
2. 옵티마이저는 스스로 생성한 실행계획과 사용자가 힌트로 지정한 실행계획을 비교해 더 나은것을 선택한다. 👉 ❌
3. 옵티마이저 힌트에 문법적 오류가 있으면 SQL 컴파일 과정에 에러가 발생한다. 👉 ❌
4. 옵티마이저 힌트를 많이 사용할수록 SQL 최적화 소요 시간이 늘어난다. 👉 ❌

🍒 문제 해설

✅ 힌트가 무시되는 특별한 이유

1. 문법적으로 맞지 않게 힌트를 기술
2. 잘못된 참조 사용 : 없는 테이블이나 별칭(Alias)을 사용한 경우, 없는 인덱스명을 지정
   한 경우 등
3. 논리적으로 불가능한 액세스 경로
   예1) 조인절에 등치(=) 조건이 하나도 없는데 해시 조인으로 유도
   예2) 테이블 전체 건수를 COUNT하는 쿼리에 NULL을 허용하는 단일 컬럼으로 생성한 인맥
   스를 사용하도록 힌트를 지정
4. 의미적으로 맞지 않게 힌트를 기술 : 예를 들어, 서브쿼리에 unnest와 push_subq를 같이 기술한 경우
5. 옵티마이저에 의해 내부적으로 쿼리가 변환된 경우
6. 버그

🍋 기출 포인트

1. 옵티마이저 힌트는 명령어(directives)이므로 특별한 이유가 없는 한 그대로 실행된다.
2. SQL Server는 힌트에 오류가 있으면 컴파일 에러가 발생하지만, 오라클은 그렇지 않다.
3. ⭐️ 옵티마이저 힌트를 사용하면 SQL 최적화 소요 시간은 오히려 감소한다. ⭐️

✍️ 16번 : 옵티마이저 힌트가 무시되는 경우

옵티마이저 힌트가 무시되는 경우가 아닌 것

1. 힌트를 느슨하게 기술한 경우, 예를 들어, index 힌트에 인덱스명을 지정하지 않거나 leading 힌트에 테이블을 모두 나열하지 않고 앞쪽 일부만 지정한 경우 👉 ⭕️
2. 문법적으로 맞지 않게 힌트를 기술하거나 잘못된 참조를 사용 👉 ❌
3. 논리적으로 불가능하거나 의미적으로 맞지 않게 힌트를 기술 👉 ❌
4. 옵티마이저에 의해 내부적으로 쿼리가 변환된 경우 👉 ❌

🍋 기출 포인트

1. index 힌트에 인덱스명을 지정하지 않으면, 어떤 인덱스를 사용할지를 옵티마이저가 결정한다.
2. leading 힌트에 나열하지 않은 테이블의 조인순서는 옵티마이저가 결정한다.

✍️ 17번 : 옵티마이저 힌트를 사용할 때 유의할 점

옵티마이저 힌트가 정상적으로 잘 작동하는 것

1. **** 👉 ⭕️
   
2. **** 👉 ❌
   
3. **** 👉 ❌
   
4. **** 👉 ❌
   

🍋 기출 포인트

1. 힌트 안에 인자를 나열할 땐 ''(콤마)를 사용할 수 있지만, 힌트와 힌트 사이에 사용하
   면 안 된다.
2. 힌트에서 테이블을 지정할 때 스키마명까지 명시하면 안 된다.
3. 힌트에서FROM 절 테이블명 옆에 ALIAS를 지정했다면, 힌트에도 반드시 ALIAS를 사용해야 한다.
4. 힌트에 인자를 나열할 때 보기 1번 첫 번째 INDEX 힌트처럼 콤마를 사용해도 되고, 두 번째 INDEX 힌트처럼 콤마를 생략해도 된다.

✍️ 18번 : 옵티마이저 힌트

옵티마이저 힌트의 의미를 가장 정확히 설명한 것

1. UNNEST : 서브쿼리를 풀어서 조인으로 변환 👉 ⭕️
2. DRIVING_SITE : 조인 드라이빙 테이블 선택 👉 ❌
3. INDEX_FS : Index Full Scan으로 유도 👉 ❌
4. SWAP_JOIN_INPUTS : NL 조인 순서를 변경 👉 ❌

🍒 문제 해설

✅ 자주 사용하는 힌트 목록

1. SWAP_JOIN_INPUTS는 해시 조인 시 BUILD INPUT을 명시적으로 선택하는 힌트다.
2. Index Full Scan으로 유도하는 힌트는 따로 제공되지 않는다.
3. INDEX 힌트로 지정한 인덱스 선두 컬럼이 조건절에 있으면 Index Range Scan, 없으면 Index Full Scan으로 처리된다.

🍋 기출 포인트

1. DRIVING_SITE는 DB Link Remote 쿼리에 대한 최적화 및 실행 주체(Local 또는 Remote)를 지정하는 힌트다.

✍️ 19번 : 블록 단위 I/O

블록 단위로 I/O 하지 않는 오퍼레이션

1. 파일에 저장된 데이터 블록을 DB 버퍼캐시로 적재할 때 👉 ⭕️
2. DB 버퍼캐시에서 데이터 블록을 읽고 쓸 때 👉 ⭕️
3. DB 버퍼캐시에서 변경된 데이터 블록을 파일에 쓸 때 👉 ⭕️
4. 테이블 및 컬럼 정보를 딕셔너리 캐시에 적재할 때 👉 ❌

🍒 문제 해설

✅ 블록 단위 I/O

● 데이터파일에서 DB 버퍼캐시로 블록을 적재할 때
● 데이터파일에서 블록을 직접 읽고 쓸 때(Direct Path I/O)
● 버퍼캐시에서 블록을 읽고 쓸 때
● 버퍼캐시에서 변경된 블록을 데이터파일에 쓸 때

1. 블록 단위 I/O는 버퍼캐시와 데이터파일 1/0 모두에 적용된다.

🍋 기출 포인트

1. 데이터 딕셔너리에 저장된 테이블 및 컬럼 정보를 딕셔너리 캐시에 적재할 때는 로우 단위로 I/O 한다.딕셔너리 캐시를 로우 캐시(Row Cache)라고도 부르는 이유다.

✍️ 20번 : 스캔시 부하

[인덱스 구성 ]
상품_PK : 상품코드
상품 X1 : 공급업체코드

(가) SELECT *
FROM 상품
WHERE 공급업체코드 = 'K123'
ORDER BY 등록일시 DESC;

(나) SELECT 상품번호, 상품명, 가격
FROM 상품
WHERE 공급업체코드 = 'K123'
ORDER BY 등록일시 DESC;

아래 두 SOL에 대한 설명으로 가장 부적절한 것

1. 소트 공간(또는 Temp 테이블스페이스) 사용량이 다르다. 👉 ⭕️
2. 클라이언트에게 전송하는 데이터 크기(Bytes)가 다르다. 👉 ⭕️
3. Table Full Scan으로 처리할 때, 두 SQL은 같은 양의 블록을 읽는다. 👉 ⭕️
4. 상품_X1 인덱스를 사용할 때, (나) SQL이 (가)보다 더 적은 양의 블록을 읽는다. 👉 ❌

🍒 문제 해설

1. (가) SQL은 데이터를 정렬하는 과정에 모든 컬럼을 소트 공간(또는 Temp 테이블스페이스)에 저장하므로 더 많은 공간을 사용한다.모든 컬럼을 클라이언트에 전송하므로 네트워크 전송
   량도 더 많다.

🍋 기출 포인트

1. 두 SQL이 읽는 블록 개수는 Table Full Scan 할 때 서로 같을 뿐만 아니라 인덱스를 이용할때도 같다. 블록 단위로 1/0 하기 때문이다.

✍️ 21번 : 메모리 버퍼캐시를 경유하지 않는 블록 I/O 오퍼레이션

메모리 버퍼캐시를 경유하지 않는 블록 I/O 오퍼레이션

1. 병렬 프로세스로 테이블 블록을 Full Scan 할 때 👉 ⭕️
2. 인덱스 루트 블록을 읽을 때 👉 ❌
3. 인덱스 루트 블록에서 얻은 주소 정보로 브랜치 블록을 읽을 때 👉 ❌
4. 인덱스 리프 블록에서 얻은 주소 정보로 테이블 블록을 읽을 때 👉 ❌

🍒 문제 해설

✅ 모두 버퍼캐시 탐색 과정을 거치는 오퍼레이션

● 인덱스 루트 블록을 읽을 때
● 인덱스 루트 블록에서 얻은 주소 정보로 브랜치 블록을 읽을 때
● 인덱스 브랜치 블록에서 얻은 주소 정보로 리프 블록을 읽을 때
● 인덱스 리프 블록에서 얻은 주소 정보로 테이블 블록을 읽을 때
● 테이블 블록을 Full Scan 할 때

🍋 기출 포인트

1. Direct Path I/O를 제외한 모든 블록 I/O는 메모리 버퍼캐시를 경유한다.
2. 병렬 프로세스로 테이블을 Full Scan 할 때는 Direct Path I/O가 작동하므로 버퍼캐시를 경유하지 않는다.

✍️ 22번 : 버퍼캐시 히트율

아래 SQL 트레이스 정보를 이용해 버퍼캐시 히트율을 올바르게 구한 것

1. 1-disk/query 👉 ⭕️
2. (1-1391/18767+996) x 100 = 92.96 👉 ⭕️

🍒 문제 해설

✅ 버퍼캐시 히트율(Buffer Cache Hit Ratio, BCHR)을 구하는 공식

BCHR = ( 캐시에서 곧바로 찾은 블록 수 / 총 읽은 블록 수 ) × 100
= ( (논리적 I/O - 물리적 I/O) / 논리적 1/0) ×100
= ( 1 - (물리적 1/0) / 논리적 I/O)) × 100

🍋 기출 포인트

1. 논리적 I/O는 SQL 수행 과정에 읽은 총 블록수
   query 항목(=Consistent 모드로 읽은 블록 수)과 current 항목(=Current 모드로 읽은 블록 수)을 더해서 구한다..
2. 읽고자 하는 블록을 먼저 캐시에서 찾고, 못 찾으면 디스크에서 읽는다. 따라서 논리적 1/O 횟수에는 물리적 I/O 횟수가 이미 포함돼 있다

✍️ 23번 : LRU 알고리즘

🍒 문제 해설

DB 버퍼캐시는 일정한 크기를 갖는 메모리 공간이므로 모든 데이터를 캐싱해 둘 수는 없
다. 따라서 모든 DBMS는 사용 빈도가 높은 데이터 블록들이 버퍼캐시에 오래 남아있도록
하기 위해 LRU 알고리즘을 사용한다.

1.모든 DBMS는 사용 빈도가 높은 데이터 블록들이 버퍼캐시에 오래 남아있도록 하기 위해 LRU 알고리즘을 사용한다.
1. 모든 버퍼 블록 헤더를 LRU 체인에 연결해서 사용빈도에 따라 수시로 위치를 옮기다가, Free 버퍼가 필요해질 때면 액세스 빈도가 낮은 데이터 블록들을 우선하여 밀어낸다.
1. 자주 액세스되는 블록들이 캐시에 더 오래 남게 된다.
1. 'least recently used'의 줄임말이다.

✍️ 24번 : 랜덤 액세스

실행계획에 나타나는 오퍼레이션 중 랜덤 액세스에 해당하는 것

1. Table Access By Index Rowid 👉 ⭕️
2. Index Range Scan 👉 ❌
3. Index Full Scan 👉 ❌
4. Table Full Scan 👉 ❌

🍒 문제 해설

✅ 시퀀셜 액세스 vs. 랜덤 액세스

1. 시퀀셜(Sequential) 액세스는 논리적 또는 물리적으로 연결된 순서에 따라 차례로 블록을 읽어나가는 방식이다. 인덱스와 테이블을 스캔할 때 이 방식을 사용한다.
2. 랜덤(Random) 액세스는 논리적, 물리적인 순서를 따르지 않고, 레코드 하나를 읽기 위해 한 블록씩 접근(=touch)하는 방식이다.인덱스를 스캔하면서 얻은 ROWID로 테이블 블록을 액세스할 때 이 방식을 사용한다.

🍋 기출 포인트

1. 인덱스를 스캔하면서 얻은 ROWID로 테이블 블록을 액세스하는 단계가 랜덤 액세스에 해당한다.

✍️ 25번 : Multiblock I/O

Multiblock I/O에 대한 설명으로 가장 부적절한 것

1. 한번의 디스크 I/O Call로 여러 블록을 버퍼캐시에 적재하는 기능이다. 👉 ⭕️
2. Multiblock 1/0 단위는 db_file_multiblock_read_count 파라미터에 의해 결정된다. 👉 ⭕️
3. 익스텐트 경계를 넘지 못한다. 즉, 한번의 디스크 I/O Call에서 두 개 익스텐트를 읽지 않는다. 👉 ⭕️
4. Multiblock I/O를 모니터링해 보면 db file sequential read 대기 이벤트가 나타난다. 👉 ❌

🍋 기출 포인트

1. db file sequential read 대기 이벤트는 Single Block I/O 할 때 나타난다. Multiblock 1/0할 때는 db file scattered read 대기 이벤트가 나타난다.

✍️ 26번 : Single Block I/O 대상 오퍼레이션

Single Block I/O 대상 오퍼레이션이 아닌 것

1. 인덱스 루트 블록을 읽을 때 👉 ⭕️
2. 인덱스 루트 블록에서 얻은 주소 정보로 브랜치 블록을 읽을 때 👉 ⭕️
3. 인덱스 리프 블록에서 얻은 주소 정보로 테이블 블록을 읽을 때 👉 ⭕️
4. 테이블 블록을 Full Scan 할 때 👉 ❌

🍋 기출 포인트

1. 테이블을 Full Scan 하거나 인덱스를 Fast Full Scan 할 때는 Multiblock I/O 방식을 사용한다.

✍️ 27번 : 데이터베이스 I/O 원리

데이터베이스 I/O 원리에 대한 설명으로 가장 부적절한 것

1. 한 쿼리가 같은 블록을 반복해서 액세스하면 버퍼캐시 히트율(BCHR)은 높아진다. 👉 ⭕️
2. Multiblock I/O는 한번의 I/O Call로 여러 데이터 블록을 읽어 메모리에 적재하는 방식이다. 👉 ⭕️
3. **테이블을 Full Scan할 때, 테이블이 작은 익스텐트로 구성돼 있을수록 더 많은 I/O Call이 발생한다. 👉 ⭕️
4. 인덱스를 통해 테이블을 액세스할 때, 테이블이 큰 익스텐트로 구성돼 있으면 더 적은 I/O Call이 발생한다. 👉 ❌

🍒 문제 해설

1. Multiblock I/O는 한 익스텐트 안에서 이루어진다. 즉, 한 익스텐트에 속한 마지막 블록을 읽었는데 아직 Multiblock I/O 단위를 채우지 못했어도 다음 익스텐트를 추가로 읽지는 않는다.

🍋 기출 포인트

1. 인덱스를 이용해서 테이블을 읽을 때는 Single Block I/O 방식을 사용하므로 익스텐트 크기 에 따라 I/O Call 횟수가 달라지지 않는다.

✍️ 28번 : 개발자의 역할

SQL 성능을 높이기 위한 개발자의 역할로 가장 부적절한 것

1. 필요한 최소 블록만 읽도록 쿼리를 효과적으로 작성한다. 👉 ⭕️
2. 옵티마이저가 최적 실행계획을 생성할 수 있도록 인덱스, 파티션, IOT 등을 잘 활용한다. 👉 ⭕️
3. 반드시 실행계획을 확인하고, 필요하다면 힌트를 이용해 직접 최적의 액세스 경로로 유도한다. 👉 ⭕️
4. 장시간 걸리는 대량 데이터 조회 쿼리가 온라인 트랜잭션 처리에 영향을 주지 않도록 병렬
   리를 적극 활용한다. 👉 ❌

🍋 기출 포인트

1. 병렬 쿼리를 자주 수행하면 CPU와 메모리 자원을 많이 사용하고, 잦은 체크포인트 수행으로 LGWR의 작업량이 증가해 커밋 성능이 지연되는 등 온라인 트랜잭션 처리에 나쁜 영향을 즐 수 있다.