데이터베이스 사용자가 간단한 UPDATE 문을 실행했을 때, 오라클 내부에서는 어떤 일이 벌어질까요? 단순히 데이터를 바꾸는 것을 넘어, 시스템은 데이터 무결성을 지키기 위해 수많은 검증과 보호 장치를 작동시킵니다. 오늘은 SQL 한 줄이 실행되는 내부 여정을 상세히 살펴보겠습니다.
1. 통신의 시작: 유저 프로세스와 서버 프로세스
SQL 수행의 첫 단계는 클라이언트 시스템의 유저 프로세스가 데이터베이스 서버의 서버 프로세스에 수행을 요청하는 것입니다.
이때 유저 프로세스는 해당 요청에 대한 세션 정보와 실행할 SQL 정보를 전달하며, 서버 프로세스는 이를 접수하여 처리를 시작합니다. 오라클은 이 과정을 통해 사용자가 누구인지, 어떤 작업을 원하는지 식별합니다.
2. 구문 분석(Parsing)의 정교한 절차
서버 프로세스는 SQL을 실제 수행하기 전에 공유 풀(Shared Pool)의 라이브러리 캐시를 통해 구문 분석을 수행합니다. 이 과정은 매우 까다롭게 진행됩니다.
-
문법 및 객체 확인: SQL 문법 오류를 점검하고, 데이터 딕셔너리를 조회하여 대상 테이블이나 컬럼이 실제로 존재하는지 확인합니다.
-
SQL 최적화(Transformation): 옵티마이저가 효율적인 실행 계획을 세울 수 있도록 SQL문을 내부적으로 변경하여 최적화합니다.
-
권한 및 락(Lock) 확인: 사용자가 데이터를 조작할 권한이 있는지 확인하고, 분석 중에 테이블 구조가 변경되지 않도록 TM 락을 수행합니다.
-
실행 계획 생성: 최적의 경로를 결정하여 구문 분석 트리(Parsing Tree)를 생성하고 이를 공유 풀에 저장합니다. 동일한 SQL이 들어오면 이 과정을 생략하는 소프트 파싱(Soft Parsing)을 통해 성능을 높입니다.
3. 먼저 기록하는 원칙: 로그 ahead 기법
오라클은 실제 데이터를 수정하기 전, 변경 내용을 먼저 기록하는 선 로그 기법(Log Ahead)을 사용합니다. 구문 분석이 완료되면 리두 로그 버퍼(Redo Log Buffer)에 변경 사항을 먼저 기록합니다. 이는 시스템 장애가 발생했을 때 데이터를 복구할 수 있는 ‘최후의 보루’가 됩니다.
4. 데이터 보호를 위한 안전장치: 락(Lock)과 언두(Undo)
데이터를 건드리기 직전, 오라클은 두 가지 핵심 안전장치를 가동합니다.
-
행 단위 락(TX Lock): 변경하려는 특정 행(Row)에 대해 TX 락을 설정합니다. 트랜잭션이 종료될 때까지 다른 사용자가 동일한 데이터를 수정하지 못하게 막아 데이터 충돌을 방지합니다.
-
언두(Undo) 데이터 생성: 변경 전의 원본 데이터를 언두 세그먼트에 저장합니다. 작업 취소(Rollback)가 필요하거나, 다른 사용자에게 일관성 있는 읽기 데이터를 제공하기 위해 필수적인 과정입니다.
5. 실행과 응답 (Execute & Fetch)
모든 준비가 끝나면 메모리 영역인 데이터 버퍼 캐시에서 실제 데이터 변경이 이루어집니다. 만약 해당 데이터 블록이 메모리에 없다면 디스크에서 읽어오는 과정이 추가됩니다. 변경이 완료되면 서버 프로세스는 유저에게 성공 메시지를 보냅니다. 하지만 이 상태는 아직 ‘임시’ 상태입니다.
6. 마침표를 찍는 커밋(Commit)
사용자가 COMMIT을 명령하면, 리두 로그 버퍼에 머물던 변경 로그들이 디스크의 리두 로그 파일에 물리적으로 기록됩니다. 이 ‘Write’ 작업이 완료되어야 비로소 변경 사항이 데이터베이스에 영구적으로 반영된 것으로 간주됩니다.
오라클의 SQL 실행 과정은 “확인하고(Parsing), 기록하며(Logging), 원본을 보관하고(Undo), 잠근 뒤(Lock) 실행한다”는 철저한 원칙을 따릅니다.
비유하자면 이 과정은 중요한 계약서를 작성할 때 신분 확인을 하고, 초안을 검토한 뒤, 나중에 문제가 생길 것에 대비해 복사본(Undo)을 만들고 공증(Log)을 받은 후에야 비로소 도장을 찍는(Commit) 것과 같습니다. 이러한 치밀한 단계 덕분에 수많은 사용자가 동시에 접속해도 데이터는 안전하게 유지됩니다.