582. 동적 성능 뷰 (V$ 뷰, DMV) - DBA 성능 모니터링 및 락(Lock) 트레이싱

⚠️ 이 문서는 데이터베이스 서버가 갑자기 CPU 100%를 치면서 먹통이 되었을 때, 막막하게 화면만 쳐다보고 있는 주니어 개발자와 달리 베테랑 DBA가 0.1초 만에 터미널을 열고 **"지금 어떤 미친 쿼리가 메모리를 다 잡아먹고 있는지, 어떤 트랜잭션이 앞사람의 락(Lock)에 걸려 줄줄이 목이 졸려 죽어가고 있는지"를 DB 엔진의 뱃속을 실시간으로 엑스레이 찍어 투시해 내는 최강의 모니터링 창구인 '동적 성능 뷰(Dynamic Performance View)'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 오라클의 V$ 뷰나 MS-SQL의 DMV(Dynamic Management View)는 일반적인 사용자 데이터(회원, 게시판)가 들어있는 테이블이 아니다. DB 엔진이 숨을 쉬면서 실시간으로 기록해 두는 '자신의 뇌파와 심박수(통계 및 메모리 상태)'를 보여주는 가상의 뷰(메모리 테이블)다.
  2. 가치: 장애가 터졌을 때 서버 전원을 껐다 켜는 바보짓을 막아준다. 이 뷰를 쿼리하면 "3번 세션이 UPDATE 치다가 락을 걸고 화장실에 갔고, 4번 세션이 그 뒤에서 30분째 대기 중이다"라는 살인 사건의 전말을 명확히 색출해 내어 3번 세션을 킬(Kill) 시킬 수 있다.
  3. 기술 체계: 세션(Session) 상태를 보는 뷰, 1만 번씩 불리는 **악성 쿼리(SQL)**를 찾아내는 뷰, 메모리(Buffer Cache) 적중률을 보는 뷰, 마지막으로 교통 체증의 원인인 **락(Lock)**을 추적하는 뷰로 나뉘어 DBA의 대시보드를 구성한다.

Ⅰ. 엑스레이의 작동 원리: 디스크가 아닌 메모리를 읽어라

이 테이블의 데이터는 DB를 끄는 순간 흔적도 없이 증발한다.

  1. 일반 테이블 vs 동적 성능 뷰:
    • SELECT * FROM users는 하드디스크(.dbf)에서 데이터를 퍼 올려서 보여준다.
    • SELECT * FROM v$session (오라클 기준)는 하드디스크에 없다. DB가 살아 숨 쉬는 동안 RAM(메모리)에만 임시로 기록해 두는 실시간 현황판이다. DB 전원을 내리면 이 뷰의 데이터는 0으로 싹 리셋(휘발)된다.
  2. 동적 성능 뷰의 권력 (Sysdba):
    • 당연히 일반 개발자용 계정(scott)으로는 이 뷰를 볼 수 없다. "지금 DB 메모리에 누가 접속해 있나?"를 까보는 행위 자체가 엄청난 보안 위반이기 때문이다.
    • 오직 신적인 권력을 가진 DBA 계정(sys, system)만이 이 V$ (브이달러) 뷰에 접근하여 DB 전체의 생태계를 내려다볼 수 있다.

📢 섹션 요약 비유: 백화점(DB)에서 일반 손님(개발자)은 매장(일반 테이블)의 물건만 구경할 수 있습니다. 동적 성능 뷰(V$)는 백화점 지하 통제실에 있는 **'실시간 100채널 CCTV 모니터링 시스템'**입니다. 오직 보안팀장(DBA)만 들어갈 수 있으며, 이 화면을 보면 "지금 1층 에스컬레이터에 100명이 몰려 멈췄네(병목)", "3층 화장실 문이 고장 나서 10명이 줄을 서 있네(락 대기)"라는 실시간 상황을 한눈에 파악할 수 있는 무적의 눈입니다.

Ⅱ. 3대 핵심 타겟 수사: 락(Lock), 쿼리, 세션

DBA가 출근해서 가장 먼저 쳐다보는 3개의 범죄 현장.

  1. V$LOCK (병목과 교착 상태 색출):
    • 상황: 결제 시스템이 하얗게 멈췄다.
    • 조치: DBA가 SELECT * FROM v$lock WHERE block = 1; 을 날린다.
    • 결과: "아! 50번 세션(사용자)이 상품 테이블에 UPDATE를 치면서 락(독점권)을 걸어놓고 Commit을 안 한 채 밥 먹으러 갔구나. 그래서 뒤에 들어온 51번, 52번 세션이 꼼짝 못 하고 기다리느라(Wait) 서버가 터진 거네!" $\rightarrow$ 50번 세션을 즉각 강제 킬(Kill)하여 길을 뚫어버린다.
  2. V$SQL (미친 쿼리와 악성 범죄자 색출):
    • 상황: DB 서버의 CPU가 평소엔 10%인데 오늘 99%를 치고 있다.
    • 조치: SELECT * FROM v$sql ORDER BY cpu_time DESC; 를 날려 CPU를 제일 많이 갉아먹은 1등 쿼리를 잡는다.
    • 결과: 어떤 주니어 개발자가 인덱스(Index)도 없는 1억 건짜리 로그 테이블에 SELECT * FROM 로그 WHERE 날짜 LIKE '%2024%' 라는 미친 풀 스캔(Full Scan) 쿼리를 날린 것을 현행범으로 잡아내어 혼구멍을 낸다.
  3. V$SESSION (현재 접속자 엑스레이):
    • 상황: 새벽 3시에 아무도 안 써야 할 DB에 누군가 붙어있다.
    • 조치: SELECT * FROM v$session 을 친다.
    • 결과: 접속한 놈의 IP 주소, 쓰고 있는 프로그램 이름(JDBC, Toad, Python), 접속 시간까지 IP 추적기처럼 적나라하게 전부 튀어나온다.

📢 섹션 요약 비유: 경찰서(DBA) 상황실입니다. V$LOCK은 고속도로 교통상황판입니다. 어떤 미친 차(세션) 하나가 고속도로 한가운데 차를 세워두고(Lock) 낮잠을 자서 뒤에 1km가 밀려있는지(Wait) 잡아냅니다. V$SQL은 과속 단속 카메라입니다. 100km 속도 제한 도로를 300km로 달리는 스포츠카(악성 쿼리)의 번호판과 그 차가 달린 전체 궤적(실행 계획)을 정확히 찍어냅니다. V$SESSION은 출입국 관리소 명부입니다. 지금 우리 땅에 외국인 100명이 어느 호텔(프로그램)에서 머물고 있는지 실시간으로 감시하는 명부입니다.

Ⅲ. 성능 지표의 진단: 히트율(Hit Ratio)과 튜닝의 시작

병원에서 피검사 수치를 보듯, DB의 체질을 숫자로 진단하라.

  1. 버퍼 캐시 적중률 (Buffer Cache Hit Ratio):
    • DB가 가장 싫어하는 건 느려 터진 하드디스크(물리 I/O)를 읽는 것이다. 그래서 한 번 읽은 데이터는 램(RAM, 버퍼 캐시)에 올려두고, 다음번엔 램에서 1초 만에 꺼내 준다(논리 I/O).
    • 동적 성능 뷰(V$SYSSTAT)를 조합해 수학 공식을 돌리면 "캐시 적중률"이 퍼센트로 나온다.
    • 정상: 95% 이상. (손님이 시킨 물건이 100번 중 95번은 RAM 창고에 있어서 하드디스크까지 안 뛰어가도 됨)
    • 비정상: 70%. (램 용량이 너무 작아서 맨날 데이터가 쫓겨나거나, 쿼리를 거지같이 짜서 매번 하드디스크 전체를 긁어오느라 DB가 죽어가고 있다는 심각한 경고). DBA는 당장 사장님께 RAM을 증설해 달라고 요구한다.
  2. 라이브러리 캐시 적중률 (Library Cache Hit Ratio):
    • 똑같은 SELECT 쿼리가 날아오면, DB는 매번 쿼리를 쪼개고(Parsing) 실행 계획을 짜느라 뇌를 쓰지 않는다. 한 번 짠 작전(실행 계획)은 램(라이브러리 캐시)에 저장해 둔다.
    • 이 적중률이 낮다면? 개발자들이 바인드 변수(WHERE id = ?)를 쓰지 않고, 매번 WHERE id = 1, WHERE id = 2 식으로 쿼리를 리터럴(Literal)로 하드코딩해서 날려대는 바람에 DB가 똑같은 쿼리를 계속 새로운 쿼리로 오해하고 매번 뇌를 갈아 넣어 번역(하드 파싱)하느라 미쳐가고 있다는 명백한 증거다.
  3. 튜닝의 예술 (AWR과 융합):
    • 뷰(V$)는 전원을 끄면 날아간다. 오라클은 이 소중한 실시간 뷰 데이터들을 1시간에 한 번씩 하드디스크에 영구적으로 사진 찍듯 저장해 두는 **AWR(Automatic Workload Repository)**이라는 기적의 리포트 기능을 만들었다.
    • DBA는 다음 날 출근해서 AWR 보고서를 뽑아 "어제 밤 12시부터 1시 사이"의 DB 건강 상태(V$ 기록의 모음집)를 한 장의 종이로 읽으며, 시스템을 어떻게 고칠지(Tuning) 메스를 들이대게 된다.

📢 섹션 요약 비유: 병원의 건강 검진 피검사 수치와 같습니다. 버퍼 캐시 적중률은 간 수치입니다. 수치가 95점 밑으로 떨어지면 "아, 당신(DB) 요즘 너무 하드디스크 읽는 막노동을 많이 해서 간(RAM)이 다 망가졌네요. 메모리 증설(영양제) 하세요"라고 처방을 내립니다. 라이브러리 캐시 적중률은 스트레스 지수입니다. "뇌(CPU)를 쓸데없는 똑같은 생각(파싱)에 너무 많이 쓰고 있어서 스트레스가 폭발 직전입니다. 개발자들 불러서 코딩 습관(바인드 변수) 고치게 멱살 잡으세요"라고 완벽한 처방전(튜닝)을 내려주는 과학적인 진단법입니다.