모두의 문제집

SQLP

시험 직전 요약장

판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.

이론 목록

n-Tier 부분범위 처리 구현: Stateful Cursor·Stateless Pagination·Connection Pool

원래 이론 →

판단 기준

단순 판단정확한 기준
Pool을 쓰면 이전 Cursor를 다음 요청에서 이어갈 수 있다다음 요청은 다른 Physical Connection·Session을 받을 수 있다
Statement Cache가 Page 위치도 저장한다Statement 준비 자원을 재사용하고 ResultSet 위치는 보존하지 않는다
Keyset은 마지막 PK 하나만 Token에 넣으면 된다ORDER BY의 모든 Key·방향·Tie-Breaker와 Filter·Version이 필요하다
Keyset이면 Page 사이 Snapshot도 같다별도 Statement이므로 READ COMMITTED에서는 Snapshot이 달라질 수 있다
UNDO_RETENTION만 크게 하면 Flashback Page가 보장된다실제 Undo 공간·부하·Token 수명과 ORA-01555 정책이 필요하다
Connection.close()는 항상 물리 연결을 종료한다Pool에서는 Logical Connection을 닫아 Physical Connection을 반환한다
ResultSet만 닫으면 Cursor가 완전히 해제된다Statement도 닫거나 Cache로 반환해야 한다
Query Timeout이면 SQL Thread가 정확한 시각에 반드시 종료된다Cancel과 Network·Database 응답에 의존하며 지연될 수 있다
Abandoned Timeout이 정상 Resource 정리를 대신한다누수 회수용 안전장치이며 정상 Close·Rollback을 대신하지 않는다
Page Query가 빠르면 COUNT(*)도 빠르다Count는 전체 조건을 처리해야 할 수 있다
이 부분의 원문 →

헷갈리는 개념

Oracle JDBC·UCP의 Statement Cache는 Physical Connection별로 존재한다. UCP에서 maxStatements를 설정하지 않거나 0으로 설정하면 Statement Caching은 비활성화된다.

Statement Cache가 재사용하는 대표 기준:

  • 동일한 SQL String
  • 동일 Statement Type (PreparedStatement·CallableStatement)
  • 동일 ResultSet Type (forward-only·scrollable)
  • 같은 Physical Connection의 Cache

Implicit Statement Cache가 활성화된 Connection에서 Statement를 close()하면 재사용 가능한 Statement 객체와 Cursor 준비 자원이 Cache에 들어갈 수 있다.

Statement Cache가 보존하지 않는 것:

  • 이전 ResultSet 객체
  • 이전 ResultSet의 현재 Row 위치
  • 이전 실행의 Bind 값과 업무 Page 상태
  • 이전 실행의 Statement Snapshot
  • 다른 Physical Connection의 Cursor 실행 위치
도식
Statement Cache Hit
→ 새 요청에서 Statement 준비 비용 일부 절감
→ SQL은 다시 Execute됨
→ 새 ResultSet과 새 Snapshot이 생성됨

Connection 수 × Connection별 Cached Statement 수가 커지면 Database Open Cursor 한도와 Client Memory를 함께 소비할 수 있다. Cache 크기는 자주 반복하는 Distinct Statement 수와 OPEN_CURSORS, V$OPEN_CURSOR를 함께 보고 정한다.

이 부분의 원문 →
이 단원 최대 5문제 →

내 최근 연습 오답

현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.

학습 기록 →

오답 기록을 확인하고 있습니다.