데이터베이스 모니터링 지표 정리 (2) Oracle

핵심 요약

최근 데이터베이스 일일 점검을 자동화하는 프로젝트를 맡게 되면서, DBA가 매일 들여다보는 모니터링 지표들을 처음부터 정리하고 있습니다. 지난 글에서 MySQL을 다뤘는데, 이번에는 Oracle 차례입니다. Oracle은 같은 관계형 데이터베이스이면서도 내부 구조가 MySQL과 꽤 달라서, 지표 이름도 절반쯤은 처음 보는 단어들이었습니다. Redo, Undo, Library Cache, Hard Parse, 테이블스페이스 같은 말이 그렇습니다. 그래서 이번에도 하나씩 정리해 두기로 했습니다.

이 글에서는 Oracle(및 Oracle on RDS)에서 자주 보는 지표들을 ① 무엇을 의미하는지 ② 평소 어느 정도 값이 정상인지(실제 관측 범위·평균) ③ 값이 튀면 무엇을 의심해야 하는지 ④ 함께 보면 좋은 지표 ⑤ 직접 확인하는 쿼리로 묶어 정리했습니다. Oracle만의 개념(SGA, Redo, Undo, Library Cache, 파싱, 테이블스페이스)은 지표를 보기 전에 먼저 한 번 풀어 두었습니다. 이 개념들이 그대로 뒤의 지표로 이어지기 때문입니다. 각 지표마다 그것을 실제로 움직이게 만드는 쿼리 패턴을 "나쁜 예 → 고친 예" SQL로 가능한 한 함께 적었고, 실제 장애로 이어지는 시나리오도 붙였습니다.

본문의 "관측값"은 실제 운영 인스턴스 한 대에서 1분 간격으로 한 달간 수집한 값입니다. 인스턴스마다 다르므로 절대적인 기준은 아니고, "보통 이 정도구나"를 감 잡는 용도입니다.

---

Oracle은 어떤 데이터베이스인가

지표를 보기 전에, Oracle이 MySQL·PostgreSQL과 어떻게 다른지부터 짚고 가겠습니다.

• Oracle: 상용 데이터베이스의 대표 격입니다. 은행·통신·대기업의 핵심 업무 시스템(기간계)에 오랫동안 쓰여 왔습니다. 기능이 강력하고 안정적이며, 대규모 트랜잭션을 안정적으로 처리하는 데 강점이 있습니다. 대신 라이선스 비용이 비쌉니다.
• MySQL: 오픈소스이고 가볍고 빠릅니다. 읽기가 많은 웹 서비스에서 오래 사랑받아 왔습니다. 스토리지 엔진(InnoDB 등)을 갈아 끼울 수 있는 것이 구조적 특징입니다.
• PostgreSQL: 오픈소스이면서 표준 준수와 확장성이 강점입니다. 복잡한 쿼리와 다양한 데이터 타입이 필요한 곳에 잘 맞습니다.

세 데이터베이스 모두 CPU·메모리·세션·I/O 같은 공통 지표를 보지만, 그 위에 각자 고유한 지표가 얹힙니다. MySQL은 InnoDB에서 나오는 지표(버퍼풀 적중률, Row Lock Waits 등)가 많았는데, Oracle은 Redo, Undo, Library Cache, 파싱, 테이블스페이스에서 나오는 지표가 많습니다. 이 단어들이 처음이면 지표 이름이 외계어처럼 보이므로, 핵심 개념을 먼저 쉽게 풀어 두겠습니다. 아래 개념들이 그대로 뒤의 지표로 이어집니다.

Oracle의 핵심 개념 먼저 풀기

• 인스턴스와 SGA(공유 메모리): Oracle을 켜면 메모리에 거대한 공유 공간을 하나 잡습니다. 이것을 SGA(System Global Area) 라고 합니다. 모든 사용자가 이 공유 메모리를 같이 씁니다. 자주 쓰는 데이터 블록을 캐싱하는 버퍼 캐시, SQL 실행계획을 캐싱하는 Library Cache, Redo를 잠시 모으는 Redo 로그 버퍼가 모두 이 SGA 안에 있습니다. MySQL의 버퍼풀에 해당하는 것이 SGA 안의 버퍼 캐시라고 보면 됩니다. (사용자 한 명마다 따로 쓰는 작업 공간은 PGA라고 부르는데, 정렬·해시 작업 등에 씁니다.) SGA는 "모두가 공유하는 큰 책상", PGA는 "개인 책상" 정도로 구분하면 됩니다.
• Redo(리두, 변경 로그): 데이터를 바꿀 때마다 "무엇을 어떻게 바꿨는지"를 먼저 적어 두는 기록입니다. 정전이나 장애로 DB가 갑자기 죽어도, 이 Redo 기록을 다시 적용하면 마지막 상태를 복구할 수 있습니다. 회계 장부에 거래를 적는 것과 비슷합니다. 데이터를 바꾸기 전에 장부에 먼저 적어 두므로, 사고가 나도 장부를 보고 복원합니다. 그래서 데이터 변경(INSERT/UPDATE/DELETE)이 많으면 Redo가 많이 발생합니다. 뒤의 Redo Entries·Log File Sync 지표가 이것에서 나옵니다.
• Undo(언두, 되돌리기·읽기 일관성): 데이터를 바꾸기 전의 "원래 값"을 따로 보관해 두는 곳입니다. 두 가지로 쓰입니다. ① 트랜잭션이 ROLLBACK 하면 이 원래 값으로 되돌리고, ② 다른 사용자가 변경 중인 데이터를 읽을 때 변경 전의 깨끗한 모습을 보여 줍니다(읽기 일관성). 사진을 수정해도 원본을 따로 남겨두는 것과 같습니다. 뒤의 Undo Change Vector Size·DBWR Undo Block Writes·Consistent Reads 지표가 이것에서 나옵니다.
• Library Cache(라이브러리 캐시, SQL 실행계획 캐시): SQL 한 문장을 실행하려면 Oracle은 먼저 그 문장을 분석해 "어떤 인덱스를 타고 어떤 순서로 읽을지"라는 실행계획을 세워야 합니다. 이 분석은 비용이 큰 작업이라, 한 번 세운 실행계획을 SGA 안의 Library Cache에 보관해 두고 같은 문장이 또 오면 재사용합니다. 자주 쓰는 요리법을 매번 처음부터 짜지 않고 적어 둔 레시피를 다시 보는 것과 같습니다.
• 파싱(Hard parse vs Soft parse): SQL 문장이 들어왔을 때 실행계획을 찾는 과정을 파싱이라고 합니다. Library Cache에 이미 같은 문장의 실행계획이 있으면 그것을 그대로 가져다 쓰는데, 이것이 Soft parse(소프트 파스) 입니다. 가볍습니다. 반대로 캐시에 없어서 처음부터 분석해 실행계획을 새로 세워야 하면 Hard parse(하드 파스) 입니다. 무겁습니다. 핵심은, 바인드 변수를 쓰지 않고 매번 값을 문자열로 박은 SQL은 Oracle 입장에서 매번 다른 문장으로 보여서 Hard parse가 폭증한다는 점입니다. 이것이 Oracle 성능 문제의 단골 원인이고, 뒤의 Parse Count (Hard)·Library Cache Lock 지표가 이것을 봅니다.
• 테이블스페이스(저장 공간): Oracle이 데이터를 저장하는 논리적인 공간 단위입니다. 테이블·인덱스는 어느 테이블스페이스에 저장할지 정해지고, 테이블스페이스는 실제 디스크 파일(데이터 파일)에 대응합니다. 창고를 구역으로 나눠 "이 구역엔 주문 데이터, 저 구역엔 회원 데이터" 식으로 두는 것과 비슷합니다. 이 공간이 가득 차면 더 이상 데이터를 쓸 수 없어 장애로 직결되므로, 사용률을 늘 감시합니다. (RDS 환경에서는 인스턴스 전체의 Free Storage Space로도 함께 봅니다.)
• 블록(block): Oracle이 데이터를 읽고 쓰는 최소 단위입니다. 행 하나하나가 아니라 여러 행이 담긴 "블록" 단위로 디스크와 메모리를 오갑니다. 뒤의 Physical Reads·Session Logical Reads가 이 블록 수를 셉니다.

이 개념들을 머리에 넣고 보면, 뒤에 나오는 33개 지표가 따로 노는 숫자가 아니라 하나의 그림으로 이어집니다.

---

들어가기 전에 — 지표를 보는 두 가지 관점

지표를 볼 때는 보통 두 가지 기준을 같이 씁니다.

첫째는 절대 임계값입니다. "CPU 사용률 80% 이상이면 위험" 처럼 미리 정한 선을 넘었는지 봅니다. 기준이 명확하지만, DB마다 정상 범위가 달라 임계값도 DB별로 다르게 잡아야 합니다.

둘째는 평소 대비 변화입니다. 임계값을 넘지 않았더라도 "어제까지 평균 10이던 값이 오늘 40으로 뛰었다" 면 무언가 달라진 것입니다. 비유하자면 절대 임계값은 건강검진의 정상 수치표이고, 평소 대비 변화는 평소 내 컨디션과 비교하는 것입니다. 둘 다 봐야 놓치는 것이 없습니다. Oracle에는 Redo Entries나 Undo Change Vector Size처럼 평소엔 작다가 배치 때 수백, 수천 배로 튀는 지표가 많아서, 특히 "평소 대비 변화"가 중요합니다.

그리고 한 가지 더, 지표는 거의 혼자 튀지 않습니다. 그래서 각 지표마다 "함께 확인할 지표" 를 붙였습니다. 어떤 값이 튀었을 때 옆의 지표가 같이 올랐는지로 원인의 방향이 갈리기 때문입니다.

---

1. CPU · 메모리 · 디스크

서버가 얼마나 바쁜지를 보는 기본 영역입니다. 식당에 비유하면 CPU는 주방의 바쁜 정도, 메모리는 조리대의 넓이, 디스크는 식자재를 쌓아 둔 창고입니다. 주문이 몰리면 주방이 바빠지고(CPU↑), 조리대가 좁으면 그때그때 창고를 오가야 하며(메모리 부족), 창고가 가득 차면 더 이상 들여놓을 수 없습니다(디스크 가득 참).

(OS) Cpu Usage (%)

서버의 CPU 사용률입니다. 가장 먼저 보는 지표이고 의미도 직관적입니다. CPU는 결국 쿼리를 실제로 계산하는 일꾼이라, 무거운 연산(정렬·조인·집계·풀 스캔)이나 잦은 Hard parse가 많아질수록 올라갑니다.

• 관측값: 평균 약 15.5%, 범위 약 3.7 ~ 44%. MySQL 인스턴스보다는 높게 깔려 있고, 순간적으로 40%대까지 오르기도 합니다.
• 위험 신호: 보통 경고 60%, 위험 80%로 잡습니다. 80%를 넘어 지속되면 쿼리 응답이 느려지기 시작합니다.
• 튀면 의심할 것: 무거운 쿼리(풀 스캔·정렬·조인), 갑자기 늘어난 활성 세션, 대량 배치, 바인드 변수 미사용으로 인한 Hard parse 폭증. CPU만 단독으로 튀는 경우는 드물고 보통 Active Session이나 읽기량(Physical/Logical Reads)이 같이 올라갑니다.

Oracle에서 CPU를 끌어올리는 전형적인 쿼리는 "할 일을 데이터베이스가 떠안는" 형태입니다. 인덱스를 못 타는 조건, 함수로 감싼 컬럼이 대표적입니다.

-- 나쁜 예: created_at에 인덱스가 있어도 TRUNC 함수로 감싸면 인덱스가 무력화된다
-- 풀 스캔 + 함수 연산이 겹쳐 CPU를 크게 쓴다
SELECT * FROM orders
WHERE TRUNC(created_at) = DATE '2026-06-18';

-- 고친 예: 함수 없이 범위 조건으로 바꾸면 인덱스를 탄다
SELECT order_id, member_id, total_amount, created_at
FROM orders
WHERE created_at >= DATE '2026-06-18'
  AND created_at <  DATE '2026-06-19';

지금 무엇이 CPU를 쓰고 있는지는 실행 중인 세션부터 봅니다.

-- 지금 활성(ACTIVE) 세션이 어떤 SQL을 돌리고 있는지
SELECT s.sid, s.serial#, s.username, s.status,
       s.sql_id, q.sql_text
FROM   v$session s
LEFT JOIN v$sql q ON q.sql_id = s.sql_id
WHERE  s.status = 'ACTIVE'
  AND  s.type = 'USER'
ORDER  BY s.last_call_et DESC;

• 함께 확인할 지표: Physical Reads·Session Logical Reads가 같이 오르면 → 인덱스를 못 타는 풀 스캔/무거운 읽기 쿼리가 CPU를 먹는 것입니다. Active Session이 같이 오르면 → 쿼리가 빨리 끝나지 못하고 쌓이는 중입니다. Parse Count (Hard)가 같이 뛰면 → 바인드 변수 미사용으로 파싱이 CPU를 먹는 것입니다(쿼리 효율 문제와 구분).

개발자 관점 — 정렬·집계·문자열 가공을 전부 DB 쿼리에 몰아넣으면 그 계산 부담이 그대로 CPU로 옵니다. 또 Oracle에서는 바인드 변수를 쓰지 않고 값을 문자열로 박는 코드가 Hard parse를 유발해 CPU를 갉아먹습니다. 자주 쓰는 집계는 미리 계산해 두고, 조회 조건은 바인드 변수로 넘기는 것이 기본입니다.

(OS) Memory Percent (%) / (OS) Memory Free (Bytes)

운영체제 관점의 메모리 사용률(%)과 남은 메모리(Bytes)입니다.

• 관측값: 사용률 평균 약 56.5%(범위 55.9 ~ 59.7%), 남은 메모리 약 60GB로 평탄하게 유지됐습니다. 메모리 사용률은 인스턴스 크기와 SGA 설정에 따라 크게 달라서, 어떤 곳은 90%대로 높게 유지되기도 합니다. 그래서 절대값보다 추세가 중요합니다.
• 위험 신호: 경고 90%, 위험 95%. 다만 남은 메모리가 꾸준히 줄어드는 추세가 더 위험합니다. 고갈되면 OS가 스왑(디스크를 메모리처럼 쓰는 것)을 시작하고, 그때부터 성능이 급격히 나빠집니다.
• 튀면 의심할 것: 세션 폭증(세션마다 PGA 메모리를 씀), 큰 정렬·해시 조인으로 PGA 사용 증가, SGA 설정 과다.

스왑(swap)은 메모리가 모자랄 때 운영체제가 디스크의 일부를 메모리처럼 빌려 쓰는 것입니다. 메모리는 빠르고 디스크는 훨씬 느리기 때문에, 스왑이 시작되면 모든 작업이 갑자기 느려집니다. Oracle에서 메모리 압박은 큰 정렬·해시 작업이 PGA를 많이 쓸 때 잘 생깁니다.

-- 정렬/해시 작업이 메모리에서 끝나지 못하고 디스크(temp)로 넘어가는지 확인
-- 'workarea executions - multipass'나 'sorts (disk)'가 늘면 메모리 부족 신호
SELECT name, value
FROM   v$sysstat
WHERE  name IN ('sorts (memory)', 'sorts (disk)');

• 함께 확인할 지표: Total Session이 같이 우상향하면 → 세션 누수로 메모리가 새는 것입니다. Physical Reads가 같이 오르면 → 정렬·해시가 디스크로 넘어가며 디스크 읽기를 유발하는 중입니다. 남은 메모리가 줄며 Read IOPS가 오르면 → 스왑이 시작됐을 수 있어 즉시 점검합니다.

개발자 관점 — Oracle 메모리는 세션마다 PGA를 조금씩 잡아먹고, 큰 정렬·해시 조인은 PGA를 크게 씁니다. 세션을 과하게 열거나(커넥션 풀 과다) 한 번에 거대한 결과셋을 정렬·그룹핑하는 쿼리를 자주 날리면 메모리 압박이 커집니다. 인덱스로 정렬을 대신하게 하고 결과 크기를 줄이면, 정렬이 디스크(temp)로 넘어가는 경우가 줄어듭니다.

실무 시나리오 — 메모리 사용률이 늘 56%로 평탄하면 한눈에 정상임을 알 수 있습니다. 문제는 천천히 새는 경우입니다. 애플리케이션이 세션을 닫지 않으면 세션이 쌓이며 남은 메모리가 시간당 일정하게 줄어드는 우하향 그래프가 그려집니다. 어느 순간 스왑이 시작되면 모든 쿼리가 느려지므로, 추세가 꺾이기 전에 잡는 것이 중요합니다.

(OS) Disk Percent (%)

서버 디스크 사용률입니다. 인스턴스에 붙은 디스크가 얼마나 찼는지를 봅니다.

• 관측값: 평균 약 80%, 범위 79.4 ~ 80.5%로 거의 일정합니다. 매우 평탄해서 한눈에 정상임을 알 수 있습니다.
• 위험 신호: 임계표상 절대 임계는 비활성이지만, 디스크가 가득 차면(특히 데이터·로그 영역) 쓰기 자체가 멈춰 장애로 직결됩니다. 그래서 꾸준히 우상향하는 추세를 봅니다.
• 튀면 의심할 것: 로그·아카이브 Redo 로그가 정리되지 않고 쌓임, 대량 적재로 데이터 파일이 커짐, temp 영역을 크게 쓰는 정렬 작업.
• 함께 확인할 지표: Free Storage Space(여유 용량)와 짝으로 봅니다 — 디스크 사용률이 오르면 여유 용량은 줄어듭니다. Redo Entries·Undo Change Vector Size가 함께 크면 → 변경량이 많아 로그·undo가 디스크를 먹는 중입니다.

개발자 관점 — 디스크는 한 번 차면 복구가 번거롭습니다. 대량 적재·삭제 배치는 한 번에 몰아 하지 말고 나눠서 처리하고, 큰 정렬을 유발하는 쿼리(인덱스 없는 ORDER BY)는 temp 영역을 크게 쓰므로 인덱스로 정렬을 대신하게 만드는 것이 좋습니다.

---

2. 세션 · 연결

체감상 가장 자주 보는 영역입니다. 핵심은 "연결" 과 "활성" 을 구분하는 것입니다. 카페로 치면 매장 안 손님 전체가 연결(Total Session)이고, 그중 지금 계산대에서 주문 중인 손님이 활성(Active Session)입니다. 매장에 손님이 많아도 계산대 앞은 보통 한두 명인 것이 정상입니다.

이 영역의 용어 몇 개를 먼저 풀어 두겠습니다.

• 세션(Session): 사용자가 Oracle에 접속해 작업하는 하나의 연결 단위입니다. 쉽게 말해 "지금 붙어 있는 DB 연결 한 개" 입니다. 세션이 3,000개면 그만큼이 접속해 있는 것이고, 그중 실제로 쿼리를 돌리는 세션만 "활성(ACTIVE)" 입니다.
• 커넥션 풀(Connection Pool): 연결을 매번 새로 만들었다 끊는 것은 비용이 큽니다. 그래서 애플리케이션이 연결을 미리 여러 개 만들어 두고, 필요할 때 빌려 쓰고 끝나면 반납하는 방식을 씁니다. 공구를 쓸 때마다 사 오지 않고 공구함에서 꺼내 쓰고 다시 넣어 두는 것과 같습니다. 빌린 연결을 반납하지 않으면 "세션 누수" 가 생깁니다.
• INACTIVE 세션: 연결은 되어 있지만 지금은 아무 쿼리도 돌리지 않고 다음 일을 기다리는 상태입니다. 커넥션 풀이 미리 만들어 둔 세션들은 대부분 이 INACTIVE 상태로 대기합니다. 그래서 세션 수가 수천 개여도 실제로 일하는 것은 몇 개뿐인 경우가 정상입니다.

Active Session (개)

지금 실제로 일하고 있는(ACTIVE 상태인) 세션 수입니다. 부하를 가장 잘 나타냅니다.

• 관측값: 평균 약 1.0, 범위 0 ~ 11. 뒤에 나오는 Total Session이 약 3,700인데 활성은 1 안팎입니다. 즉 대부분의 세션은 놀고 있다는 뜻이고, 이것이 정상입니다.
• 위험 신호: 경고 50, 위험 100. 활성이 갑자기 수십 개로 뛰면 쿼리들이 빨리 끝나지 못하고 쌓이고 있다는 신호입니다.
• 읽는 법: "연결(Total Session)은 그대로인데 활성만 뛰었다" 면 쿼리가 느려진 것이고, "연결도 같이 뛰었다" 면 트래픽이 몰린 것입니다. 이 구분이 원인 추적의 출발점입니다.

활성 세션이 갑자기 오르는 흔한 원인은, 어떤 무거운 쿼리가 배포되어 그 쿼리를 돌리는 세션들이 동시에 오래 머무는 경우입니다.

-- 지금 ACTIVE 세션을 오래 걸린 순서로 (last_call_et = 현재 작업이 시작된 뒤 경과 초)
SELECT sid, serial#, username, sql_id, event,
       last_call_et AS active_sec
FROM   v$session
WHERE  status = 'ACTIVE' AND type = 'USER'
ORDER  BY last_call_et DESC;

• 함께 확인할 지표: CPU·Physical Reads가 같이 오르면 → 느린(풀 스캔) 쿼리가 안 끝나고 쌓이는 것입니다. Lock Session·enq: TX - Row Lock Contention이 같이 오르면 → 락 대기로 활성이 막혀 쌓인 것(쿼리 자체보다 다른 트랜잭션이 원인). Total Session이 같이 뛰면 → 트래픽 급증입니다.

개발자 관점 — 활성 세션은 쿼리 하나하나의 응답 속도에 직접 좌우됩니다. 느린 쿼리 한 종류가 배포되면 그 쿼리를 실행하는 세션들이 동시에 오래 머물러 활성 수가 한꺼번에 올라갑니다. 쿼리 응답 시간을 짧게 유지하는 것(인덱스·적정 결과 크기·바인드 변수)이 활성 수를 낮게 유지하는 근본 대책입니다.

실무 시나리오 — 평소 활성 세션이 1~2였는데 어느 배포 직후 갑자기 30~40으로 치솟았다고 해보겠습니다. v$session으로 잡아 보니 같은 sql_id를 가진 세션들이 수십 개씩 동시에 ACTIVE로 떠 있고, 그 SQL이 인덱스를 못 타는 풀 스캔이었습니다. 한 요청이 느려지자 뒤따라 들어온 요청들이 끝나지 못하고 쌓인 것입니다. 해당 컬럼에 인덱스를 추가하니 활성 세션이 다시 1~2로 돌아옵니다.

Total Session (개)

세션의 상태와 상관없이 지금 연결되어 있는 전체 세션 수입니다. 아무 일도 안 하는(INACTIVE) 세션도 포함합니다.

• 관측값: 평균 약 3,713, 범위 3,681 ~ 3,825. 커넥션 풀이 큰 환경이라 수천 개가 연결된 채 거의 평평하게 유지됩니다. 세션 수 자체보다 "평소 수준에서 벗어났는가"가 포인트입니다.
• 튀면 의심할 것: 세션 누수(반납 안 된 연결), 풀 설정 변경, 트래픽 급증.

-- 상태별·사용자별 세션 수 (INACTIVE가 한쪽으로 쌓이면 누수 단서)
SELECT username, status, COUNT(*) AS cnt
FROM   v$session
WHERE  type = 'USER'
GROUP  BY username, status
ORDER  BY cnt DESC;

• 함께 확인할 지표: Active Session은 그대로인데 Total만 우상향하면 → 일 안 하는 INACTIVE 세션이 쌓이는 누수입니다. (OS) Memory Free가 같이 줄면 → 세션마다 쓰는 PGA 메모리가 누적되는 중입니다. 한도(sessions/processes 파라미터)에 가까워지면 신규 연결이 거부됩니다.

개발자 관점 — 커넥션 풀 크기를 너무 크게 잡거나, 예외 경로에서 연결을 반납하지 않으면(try-with-resources나 finally 누락) 세션이 계속 쌓입니다. 풀 크기는 DB의 sessions/processes 파라미터와 함께 설계해야 하며, 여러 애플리케이션 인스턴스가 같은 DB에 붙는다면 풀 크기 합계가 한도를 넘지 않도록 잡아야 합니다.

Database Connections (개)

클러스터에 대한 데이터베이스 연결 수의 평균입니다. (DPM에서는 단위가 credits로 표기되지만 실제로는 연결 수로 해석합니다.)

• 관측값: 평균 약 3,655, 범위 3,527 ~ 3,767. Total Session(약 3,713)과 비슷한 수준에서 평탄하게 움직입니다. 두 지표를 같이 보면 연결 수의 큰 그림을 교차 확인할 수 있습니다.
• 튀면 의심할 것: Total Session과 마찬가지로 세션 누수, 풀 설정 변경, 트래픽 급증.
• 함께 확인할 지표: Total Session과 같은 방향으로 움직이는 것이 정상입니다. 둘이 어긋나거나 한쪽만 튀면 측정 경로 차이를 의심하고, 둘 다 우상향하면 연결이 실제로 누적되는 것입니다.

개발자 관점 — 연결 수 계열 지표는 결국 애플리케이션이 연결을 빌리고 제때 반납하는지에 달려 있습니다. 연결은 빌리면 반드시 반납되는 구조로 쓰고, 풀 크기를 DB 한도에 맞춰 설계해야 합니다.

Lock Session (개)

지금 Row 락을 얻으려고 대기 중인 세션 수입니다. 락 경합을 직접 보여 주는 지표입니다. (락 자체는 아래 5번 락 섹션에서 자세히 다룹니다.)

• 관측값: 평균 약 0.01, 범위 0 ~ 5. 0이 정상이고, 0이 아니면 지금 누군가 다른 트랜잭션 때문에 막혀 있는 것입니다.
• 위험 신호: 경고 2, 위험 3. 작은 값이라도 반복되면 특정 쿼리·트랜잭션이 자주 충돌하고 있다는 뜻입니다.
• 튀면 의심할 것: 한 트랜잭션이 행을 쥔 채 커밋을 미룸, 같은 행에 대한 동시 수정 경합.

-- 누가 누구를 막고 있는지 (blocking 세션 찾기)
SELECT s.sid, s.serial#, s.username,
       s.blocking_session, s.event, s.sql_id
FROM   v$session s
WHERE  s.blocking_session IS NOT NULL;

• 함께 확인할 지표: enq: TX - Row Lock Contention(락 대기 시간)이 같이 오르면 → 실제로 락 경합이 일어나는 중입니다. Active Session이 같이 쌓이면 → 대기가 부하로 번지는 중입니다. 자세한 분석은 5번 락 섹션을 참고합니다.

개발자 관점 — 대기 세션이 있다는 것은 누군가 락을 오래 쥐고 있다는 뜻입니다. 보통 락을 잡은 트랜잭션이 커밋을 미루는 경우이므로, 변경 후 즉시 커밋하도록 트랜잭션 경계를 좁히는 것이 핵심입니다.

---

3. SQL 처리량 · 파싱

이 영역은 Oracle이 얼마나 많은 SQL을 처리하고, 그 과정에서 파싱(실행계획 분석)을 얼마나 하는지를 봅니다. 가게의 품목별 판매 건수 같은 것이라, 절대값보다 평소 대비 패턴이 중요합니다.

먼저 용어 두 가지를 짚어 두겠습니다.

• 누적값 카운터: User Calls·User Commits·Redo Entries 같은 값 중 일부는 Oracle이 켜진 뒤로 계속 더해 가는 누적 숫자입니다. 자동차 누적 주행거리계처럼 한 방향으로만 늘어납니다. "지금 1분에 몇 번이었나"를 알려면 그 값 자체가 아니라 이전 측정값과의 차이를 봐야 합니다. (DPM은 1분 간격으로 이런 차이를 계산해 제공합니다.)
• 파싱: 위에서 설명했듯, SQL이 들어왔을 때 실행계획을 찾는 과정입니다. 캐시에 있으면 가볍게 재사용(Soft parse), 없으면 처음부터 분석(Hard parse)합니다. 바인드 변수를 안 쓰면 Hard parse가 폭증합니다.

User Calls (건)

Oracle 외부(애플리케이션)로부터 들어온 사용자 호출 건수입니다. 쿼리 실행, 페치, 로그인 등 사용자가 DB에 보낸 요청을 셉니다.

• 관측값: 평균 약 117,778, 범위 25,761 ~ 235,982. 트래픽 수준을 한 숫자로 보고 싶을 때 씁니다. 평소 대비 몇 배로 뛰면 호출량 증가입니다.
• 튀면 의심할 것: 트래픽 급증, 한 요청이 DB 호출을 여러 번 유발하는 비효율(N+1 패턴), 불필요한 폴링 로직.

User Calls를 비정상적으로 늘리는 흔한 원인은 "한 번에 끝낼 수 있는 조회를 반복 호출"하는 N+1 패턴입니다. 목록을 한 번 가져온 뒤 각 항목마다 쿼리를 또 날리는 형태입니다.

-- 나쁜 예: 주문 100건을 가져온 뒤, 각 주문마다 회원을 1번씩 더 조회
-- (애플리케이션이 루프를 돌며 아래 쿼리를 100번 더 호출 → User Calls 증가)
SELECT * FROM orders WHERE status = 'PAID';
-- 이후 루프 안에서: SELECT * FROM members WHERE member_id = :id;  (100번 반복)

-- 고친 예: 조인으로 한 번에 가져오면 호출 횟수가 1번으로 준다
SELECT o.order_id, o.total_amount, m.name
FROM   orders o
JOIN   members m ON m.member_id = o.member_id
WHERE  o.status = 'PAID';

• 함께 확인할 지표: TPS·Active Session이 함께 오르면 → 실제 부하 증가입니다. User Calls는 뛰는데 TPS(트랜잭션 수)가 평탄하면 → 한 트랜잭션이 호출을 잘게 여러 번 나눠 날리는 것(N+1)입니다.

개발자 관점 — 한 API 호출이 DB 호출을 몇 번 유발하는지가 이 지표를 좌우합니다. 반복문 안에서 매 건마다 쿼리를 날리면 User Calls가 호출량에 비례해 폭증합니다. 조인·IN 절로 한 번에 가져오고, 잘 변하지 않는 데이터는 캐시를 두면 줄어듭니다.

TPS (건/초)

초당 트랜잭션 수입니다. 산식은 (user commits + user rollbacks) / 5로, 커밋·롤백으로 끝난 트랜잭션을 초당 단위로 본 것입니다.

• 관측값: 평균 약 25.6, 범위 0.2 ~ 535.4. 평소엔 낮다가 배치·트래픽 몰림 시 수백까지 튑니다.
• 튀면 의심할 것: 대량 배치(잦은 단건 커밋), 트래픽 급증.

쓰기 쪽 TPS가 비정상적으로 높은 흔한 원인은 한 건씩 커밋하는 코드입니다.

-- 나쁜 예: 한 건씩 1,000번 INSERT + 매 건 COMMIT (트랜잭션 1,000개)
-- TPS와 Log File Sync가 함께 치솟는다
BEGIN
  FOR i IN 1..1000 LOOP
    INSERT INTO logs(msg) VALUES ('row ' || i);
    COMMIT;            -- 매 건 커밋 → 트랜잭션 수·Redo flush 폭증
  END LOOP;
END;

-- 고친 예: 여러 건을 모아 한 번에 커밋 (트랜잭션 수가 크게 준다)
BEGIN
  FOR i IN 1..1000 LOOP
    INSERT INTO logs(msg) VALUES ('row ' || i);
  END LOOP;
  COMMIT;              -- 한 번만 커밋
END;

• 함께 확인할 지표: User Commits·Log File Sync가 같이 오르면 → 잦은 커밋이 Redo flush를 유발하는 중입니다(아래 4번 Redo 섹션). Active Session·CPU가 동반이면 → 실제 부하 증가입니다.

개발자 관점 — TPS는 커밋·롤백 횟수에 비례합니다. 매 건마다 커밋하는 코드는 트랜잭션 수를 잘게 늘리고 Log File Sync 부담을 키웁니다. 한 묶음 단위로 커밋하면 TPS와 Redo flush 부담이 함께 줄어듭니다.

User Commits (건) / User Rollbacks (건)

사용자가 트랜잭션에 대해 Commit / Rollback을 수행한 횟수입니다.

• 관측값: User Commits 평균 약 128 / 1 ~ 2,677, User Rollbacks 평균 약 0.6 / 0 ~ 22. 커밋이 압도적으로 많고 롤백은 거의 없습니다. 정상적인 모습입니다.
• 읽는 법: Rollback이 평소보다 늘면 트랜잭션이 자주 실패해 되돌려지고 있다는 뜻입니다. 락 경합·교착(deadlock)·제약조건 위반·애플리케이션 예외 등을 의심합니다.
• 튀면 의심할 것: Commit 급증 → 대량 배치·잦은 단건 커밋. Rollback 급증 → 트랜잭션 실패 증가(에러·교착).

-- 커밋/롤백 누적 카운터 확인
SELECT name, value
FROM   v$sysstat
WHERE  name IN ('user commits', 'user rollbacks');

• 함께 확인할 지표: User Commits·TPS·Log File Sync가 함께 오르면 → 정상적인 쓰기 부하입니다. User Rollbacks가 enq: TX - Row Lock Contention·Lock Session과 함께 오르면 → 교착·락 경합으로 트랜잭션이 되돌려지는 것일 수 있습니다.

개발자 관점 — 롤백이 잦다는 것은 비즈니스 로직이 실패를 자주 만난다는 뜻입니다. 교착(deadlock)으로 인한 롤백이라면 트랜잭션 안에서 여러 테이블·행을 건드리는 순서를 코드 전반에서 일정하게 맞춰 교착 가능성을 줄입니다. 제약조건 위반이 잦다면 사전 검증을 강화합니다.

Parse Count (Hard) (건)

오라클이 문장을 처음부터 최적화한 횟수, 즉 Hard parse가 수행된 횟수입니다. 위에서 설명했듯 Hard parse는 무거운 작업이라, 이 값이 크면 CPU와 Library Cache에 부담을 줍니다.

• 관측값: 평균 약 0.07, 범위 0 ~ 360. 평소엔 거의 0인데(실행계획이 잘 재사용되고 있다는 뜻), 어느 순간 360까지 튄 적이 있습니다. 이 순간이 바로 위험 신호입니다.
• 튀면 의심할 것: 바인드 변수를 쓰지 않고 매번 값을 문자열로 박은 SQL. Oracle은 이런 SQL을 매번 다른 문장으로 보고 실행계획을 새로 세웁니다.

이것이 Oracle 성능 문제의 단골 원인이라, 코드로 자세히 보겠습니다.

-- 나쁜 예: 값을 문자열로 직접 박는다 → 회원 ID마다 SQL 텍스트가 달라
-- Oracle이 매번 새 문장으로 보고 Hard parse를 한다 (캐시 재사용 불가)
SELECT * FROM members WHERE member_id = 1001;
SELECT * FROM members WHERE member_id = 1002;
SELECT * FROM members WHERE member_id = 1003;
-- ... 값만 다른 같은 모양 쿼리가 수천 개 생기며 Hard parse 폭증

-- 고친 예: 바인드 변수를 쓴다 → SQL 텍스트가 항상 동일
-- 첫 실행 때만 분석하고, 이후엔 Library Cache의 실행계획을 재사용(Soft parse)
SELECT * FROM members WHERE member_id = :member_id;
-- 애플리케이션에서 :member_id 자리에 값만 바꿔 넘긴다

Java/JDBC에서는 Statement에 값을 문자열로 이어 붙이지 말고 PreparedStatement에 ?(바인드)를 쓰면 같은 효과입니다. 이것은 Hard parse를 막을 뿐 아니라 SQL 인젝션도 방지합니다.

-- Hard parse를 많이 유발하는 SQL 후보 찾기 (실행 대비 파싱이 잦은 것)
SELECT sql_id, parse_calls, executions, sql_text
FROM   v$sqlarea
WHERE  parse_calls > 0
ORDER  BY parse_calls DESC
FETCH FIRST 20 ROWS ONLY;

• 함께 확인할 지표: CPU가 같이 오르면 → 파싱이 CPU를 먹는 중입니다. Library Cache Lock이 같이 오르면 → 잦은 Hard parse로 Library Cache 경합이 생긴 것입니다(아래). v$sqlarea에서 값만 다른 비슷한 SQL이 수천 개 보이면 → 바인드 변수 미사용이 거의 확실합니다.

개발자 관점 — Hard parse 폭증은 거의 항상 바인드 변수를 안 쓰는 코드에서 나옵니다. ORM이 기본적으로 바인드 변수를 쓰지만, 직접 SQL을 문자열로 조립하는 코드나 동적 쿼리에서 값을 그대로 붙이는 경우 문제가 됩니다. 조회 조건 값은 항상 바인드 변수로 넘기는 것이 원칙입니다.

실무 시나리오 — 새로 추가된 통계 화면이 배포된 뒤 CPU가 평소보다 높게 깔리기 시작했다고 해보겠습니다. v$sqlarea를 보니 WHERE region = '서울', WHERE region = '부산'처럼 값만 다른 거의 똑같은 SQL이 수천 종류 잡혀 있고, 각각 한두 번씩만 실행됐습니다. 동적 쿼리에서 지역 값을 문자열로 박은 것이 원인이었습니다. 바인드 변수로 바꾸자 SQL이 한 종류로 합쳐지며 Hard parse와 CPU가 함께 내려갑니다.

Library Cache Lock (초)

라이브러리 캐시에 오브젝트를 적재하려는 세션이 LCO(Library Cache Object) 핸들에 대한 락을 얻는 과정에서 발생하는 대기 시간입니다. 쉽게 말해, 여러 세션이 Library Cache의 같은 자원을 두고 경합하며 기다린 시간입니다.

• 관측값: 평균 약 0.00006초, 범위 0 ~ 0.01초. 사실상 0에 가깝게 유지되는 것이 정상입니다.
• 튀면 의심할 것: 잦은 Hard parse로 Library Cache가 자주 갱신됨, DDL(테이블·인덱스 변경)이 운영 중 자주 실행되어 관련 SQL의 실행계획이 무효화됨.

-- 지금 Library Cache 관련 이벤트를 대기 중인 세션이 있는지
SELECT sid, event, seconds_in_wait, sql_id
FROM   v$session
WHERE  event LIKE 'library cache%';

• 함께 확인할 지표: Parse Count (Hard)가 같이 오르면 → 바인드 변수 미사용으로 인한 잦은 파싱이 Library Cache 경합을 유발한 것입니다. 운영 중 DDL이 돌면 → 관련 SQL이 무효화되며 일시적으로 오를 수 있습니다.

개발자 관점 — Library Cache Lock은 잦은 Hard parse나 운영 중 DDL과 함께 오릅니다. 바인드 변수를 써서 파싱을 줄이고, 테이블·인덱스 변경 같은 DDL은 트래픽이 적은 시간대로 분리하면 경합을 줄일 수 있습니다.

---

4. Redo · Undo

이 영역이 Oracle 지표 중 가장 Oracle다운 부분입니다. 위에서 풀어 둔 Redo(변경 로그)와 Undo(되돌리기·읽기 일관성) 개념이 여기서 지표로 나타납니다. 데이터를 바꿀 때마다 Oracle은 "바꾼 내용"을 Redo에 적고, "바꾸기 전 값"을 Undo에 적습니다. 그래서 데이터 변경(INSERT/UPDATE/DELETE)이 많을수록 이 영역 지표가 함께 오릅니다. 대량 적재 배치를 잡아내는 데 특히 유용합니다.

용어를 다시 한 번 짧게 정리하면:

• Redo: 변경 내용을 먼저 적어 두는 장부. 장애 시 이 장부로 복구합니다. LGWR라는 백그라운드 프로세스가 Redo 로그 버퍼의 내용을 디스크의 Redo 로그 파일에 기록합니다.
• Undo: 변경 전 값을 보관하는 곳. 롤백과 읽기 일관성에 씁니다.
• 커밋과 Log File Sync: 사용자가 COMMIT을 하면, 그 시점까지의 Redo가 디스크에 안전하게 기록될 때까지 기다립니다. 이 "Redo가 디스크에 써지길 기다리는" 시간이 Log File Sync입니다. 그래서 커밋을 자주 할수록 Log File Sync가 늘어납니다.

Redo Entries (건)

발생한 Redo Entry 개수입니다. 데이터를 변경할 때마다 Redo가 생기므로, 대량의 DML(INSERT/UPDATE/DELETE)이 발생할 때 급격히 증가합니다.

• 관측값: 평균 약 2,772인데 범위가 25 ~ 1,407,527로 극단적으로 넓습니다. 평소엔 수천 건이다가 어떤 순간 140만 건을 넘겼다는 뜻입니다. 바로 이 "순간 폭증"이 대량 적재 배치의 지문입니다.
• 튀면 의심할 것: 대량 INSERT/UPDATE/DELETE 배치, 데이터 마이그레이션, 한 트랜잭션으로 묶인 거대한 변경.

대량 변경을 한 번에 몰아 하면 Redo가 한꺼번에 폭증합니다. 나눠서 처리하면 분산됩니다.

-- 나쁜 예: 수백만 행을 한 트랜잭션으로 통째 갱신 → Redo가 한꺼번에 폭증
UPDATE orders SET status = 'ARCHIVED'
WHERE created_at < DATE '2025-01-01';
COMMIT;

-- 고친 예: 몇 만 건씩 나눠서 처리 (Redo 발생을 분산, undo 누적도 완화)
BEGIN
  LOOP
    UPDATE orders SET status = 'ARCHIVED'
    WHERE created_at < DATE '2025-01-01'
      AND status <> 'ARCHIVED'
      AND ROWNUM <= 50000;     -- 한 번에 5만 건씩
    EXIT WHEN SQL%ROWCOUNT = 0;
    COMMIT;                    -- 묶음마다 커밋
  END LOOP;
END;

-- Redo 발생량 누적 카운터 확인
SELECT name, value
FROM   v$sysstat
WHERE  name IN ('redo entries', 'redo size');

• 함께 확인할 지표: Undo Change Vector Size·DBWR Undo Block Writes가 같이 오르면 → 대량 DML이 맞습니다(변경하면 Redo와 Undo가 함께 발생). Log File Sync가 같이 오르면 → 잦은 커밋까지 겹친 것입니다. Write IOPS·Write Throughput이 같이 오르면 → 그 변경이 디스크 쓰기로 내려가는 중입니다.

개발자 관점 — 대량 변경을 하나의 큰 트랜잭션으로 묶으면 Redo와 Undo가 한꺼번에 쌓여 부하가 집중됩니다. 배치는 몇 만 건 단위로 나눠 커밋하면 Redo 발생이 분산되고 undo 누적도 완화됩니다. 또 변경할 필요가 없는 행까지 갱신 대상에 넣지 않도록(이미 처리된 행 제외) 조건을 정확히 거는 것도 Redo를 줄이는 방법입니다.

Undo Change Vector Size (Bytes)

Oracle이 데이터를 변경(DML)할 때 생성한 Undo(변경 전 데이터) 의 총 크기입니다. 변경량이 많을수록 커집니다.

• 관측값: 평균 약 354KB인데 범위가 1,252 Bytes ~ 약 224MB로 매우 넓습니다. 평소엔 작다가 대량 변경 시 수백 MB까지 튑니다. Redo Entries와 같은 시각에 함께 움직이는 경우가 많습니다.
• 튀면 의심할 것: 대량 UPDATE/DELETE(특히 한 트랜잭션으로 묶인 것), 긴 트랜잭션.
• 함께 확인할 지표: Redo Entries와 거의 짝으로 움직입니다(변경하면 둘 다 발생). DBWR Undo Block Writes가 같이 오르면 → undo 블록이 디스크로 내려가는 중입니다. Data Blocks Consistent Reads가 같이 오르면 → 그 undo를 읽어 과거 시점을 재구성하는 읽기가 늘어난 것입니다.

개발자 관점 — Undo는 데이터를 바꿀 때마다 생기므로, 한 번에 너무 많은 행을 바꾸는 트랜잭션은 undo를 크게 만듭니다. 긴 트랜잭션(오래 열어 둔 채 커밋 안 함)은 그 undo를 오래 잡아 두어 다른 작업의 읽기 일관성 비용까지 키웁니다. 대량 변경은 나눠서 커밋하고, 트랜잭션은 짧게 가져가는 것이 좋습니다.

Log File Sync (초)

사용자 세션이 커밋/롤백한 뒤, Redo 정보가 LGWR에 의해 로그 파일에 기록되기를 기다리는 대기 시간입니다. 쉽게 말해 "커밋이 디스크에 안전하게 써지기를 기다린 시간" 입니다.

• 관측값: 평균 약 0.31초, 범위 0 ~ 8.6초. 평소엔 매우 짧다가 어떤 순간 8초 넘게 기다린 적이 있습니다. 이 순간이 위험 신호입니다.
• 튀면 의심할 것: 잦은 단건 커밋(커밋마다 Redo flush를 기다림), 디스크(로그 파일) I/O 성능 저하, 한꺼번에 몰린 커밋.

가장 흔한 원인은 반복문 안에서 매 건 커밋하는 코드입니다.

-- 나쁜 예: 매 건 커밋 → 커밋마다 Redo가 디스크에 써지길 기다린다
-- (Log File Sync 대기가 건수만큼 쌓인다)
BEGIN
  FOR r IN (SELECT id FROM staging) LOOP
    UPDATE target SET flag = 'Y' WHERE id = r.id;
    COMMIT;                 -- 매 건 커밋 → Log File Sync 폭증
  END LOOP;
END;

-- 고친 예: 묶음 단위로 커밋 (Redo flush 대기 횟수가 크게 준다)
DECLARE
  n NUMBER := 0;
BEGIN
  FOR r IN (SELECT id FROM staging) LOOP
    UPDATE target SET flag = 'Y' WHERE id = r.id;
    n := n + 1;
    IF MOD(n, 5000) = 0 THEN COMMIT; END IF;   -- 5천 건마다 커밋
  END LOOP;
  COMMIT;
END;

-- Log File Sync 대기 현황 확인
SELECT event, total_waits, time_waited, average_wait
FROM   v$system_event
WHERE  event = 'log file sync';

• 함께 확인할 지표: User Commits·TPS가 같이 오르면 → 잦은 커밋이 원인입니다. Write IOPS·Write Throughput이 같이 오르며 Log File Sync가 길어지면 → 로그 디스크 I/O가 병목인 것입니다. Redo Entries가 같이 크면 → 변경량 자체가 많은 것입니다.

개발자 관점 — Log File Sync는 커밋 횟수에 크게 좌우됩니다. 반복문 안에서 매 건 커밋하면 커밋마다 Redo flush를 기다려 누적 대기가 커집니다. 한 묶음 단위로 모아서 커밋하면 대기 횟수가 줄어듭니다. 단, 너무 크게 묶으면 undo가 커지므로 적당한 단위(수천~수만 건)로 나누는 것이 균형점입니다.

Data Blocks Consistent Reads - Undo Records Applied (건)

읽기 일관성을 유지하기 위해 Undo 레코드를 적용해 과거 시점의 데이터 블록을 재구성한 횟수입니다. 누군가 변경 중인 블록을 다른 세션이 읽을 때, 변경 전 모습을 보여 주려고 undo를 적용한 작업을 셉니다.

• 관측값: 평균 약 30, 범위 0 ~ 24,680. 평소엔 작다가 변경이 많은 데이터를 동시에 많이 읽을 때 튑니다.
• 튀면 의심할 것: 자주 바뀌는 데이터(핫 블록)를 여러 세션이 동시에 읽고 쓰는 경합, 긴 쿼리가 그 사이 바뀐 데이터를 읽으며 과거 버전을 많이 재구성.
• 함께 확인할 지표: Undo Change Vector Size가 같이 크면 → 변경이 많아 undo가 많이 쌓이고 그것을 읽는 일도 늘어난 것입니다. Session Logical Reads가 같이 오르면 → 메모리 읽기 중 일관성 재구성 비중이 커진 것입니다.

개발자 관점 — 같은 데이터를 한쪽에서 자주 바꾸고 다른 쪽에서 길게 읽으면, 읽는 쪽이 변경 전 버전을 재구성하느라 일이 늘어납니다. 핫 데이터에 대한 긴 분석 쿼리는 시간대를 분리하거나, 읽기 전용 복제본에서 돌리는 것이 부담을 줄이는 방법입니다.

DBWR Undo Block Writes (건)

DBWR(Database Writer) 프로세스가 메모리의 Undo 데이터 블록을 디스크에 기록한 횟수입니다. undo가 메모리에서 디스크로 내려가는 양을 봅니다.

• 관측값: 평균 약 50, 범위 0 ~ 20,445. 평소엔 작다가 대량 변경 시 함께 튑니다.
• 튀면 의심할 것: 대량 DML로 undo가 많이 생성되어 디스크로 내려감.
• 함께 확인할 지표: Undo Change Vector Size·Redo Entries와 같은 방향으로 움직입니다(대량 변경의 한 묶음). Write IOPS가 같이 오르면 → undo 블록 쓰기가 디스크 I/O로 잡히는 것입니다.

개발자 관점 — 이 지표는 대량 변경의 결과로 따라 오르는 것이라, 직접 줄이기보다 원인인 대량 DML을 나눠서 처리하면 자연히 완화됩니다. Redo·Undo 영역 지표들은 대체로 "변경량"이라는 한 원인에서 함께 움직인다고 보면 됩니다.

---

5. 락 · 동시성

같은 데이터를 동시에 바꾸려 할 때 락(Lock) 으로 순서를 정합니다. 화장실 한 칸을 한 사람씩 쓰는 것과 같아서, 한 사람이 너무 오래 쓰면 뒤에 줄이 길어집니다.

이 영역의 개념을 먼저 짧게 풀어 두겠습니다. (아래 지표는 이 개념들을 전제로 합니다.)

• 트랜잭션(Transaction): 여러 DB 작업을 "전부 성공 아니면 전부 취소" 로 묶은 한 묶음입니다. 계좌 이체에서 "내 계좌에서 1만 원 빼기" 와 "친구 계좌에 1만 원 넣기" 는 둘 다 되거나 둘 다 안 되어야 합니다. 다 잘 됐으면 COMMIT, 문제가 생기면 ROLLBACK 합니다.
• TX 락(행 락): Oracle에서 어떤 행을 고치기 시작하면, 커밋할 때까지 그 행에 락(TX 락)을 걸어 둡니다. 다른 세션이 같은 행을 고치려면 그 락이 풀릴 때까지 기다립니다. Oracle은 테이블 전체가 아니라 고치는 그 행만 잠그므로, 같은 테이블이라도 다른 행은 동시에 작업할 수 있습니다.
• 그래서 무엇이 문제냐면: 잠근 세션이 빨리 커밋하면 락이 금방 풀려 문제가 없습니다. 문제는 잠가 놓고 오래 안 풀어줄 때(예: 트랜잭션을 연 채 외부 API 호출을 기다림)입니다. 그동안 그 행을 고치려는 다른 작업들이 줄줄이 기다리게 됩니다. 아래 지표가 바로 이 "기다림" 을 봅니다.

enq: TX - Row Lock Contention (초)

Row 레벨 락이 발생했을 때, 해당 행에 대한 TX 락을 얻으려고 기다린 대기 시간입니다. (enq:는 enqueue, 즉 락 대기 큐를 뜻합니다.) 다른 트랜잭션이 잡은 행 락이 풀리기를 기다린 시간이라고 보면 됩니다.

• 관측값: 평균 약 0.0018초, 범위 0 ~ 30초. 평소 0에 가깝고, 가끔 순간적으로 최대 30초까지 대기가 몰린 적이 있습니다. 30초씩 락을 기다린다는 것은 누군가 행을 오래 쥐고 안 놨다는 뜻입니다.
• 튀면 의심할 것: 장기 실행 트랜잭션이 행 락을 오래 쥠, 같은 행을 여러 트랜잭션이 동시에 수정, 커밋을 늦게 하는 코드.

락 대기는 거의 "트랜잭션을 열어놓고 커밋을 미루는" 코드에서 생깁니다.

-- 나쁜 예: 행을 수정한 뒤 외부 작업(API 호출·파일 처리 등)을 하느라 커밋이 늦어진다
-- 그동안 같은 행(id=1)을 건드리려는 다른 트랜잭션은 전부 대기한다
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
-- ... 여기서 외부 API 호출 등으로 수 초~수십 초 지연 ...
COMMIT;   -- 너무 늦게 커밋 → 그 사이 account_id=1을 노리는 작업들이 TX 락 대기

-- 고친 예: DB 변경 구간만 빠르게 묶어 곧바로 커밋한다 (외부 작업은 트랜잭션 밖에서)
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
COMMIT;   -- 즉시 커밋 → 락 점유 시간이 짧아 대기가 거의 없다

-- 지금 락 경합이 있는지 — 막은 세션(holder)과 막힌 세션(waiter) 찾기
SELECT w.sid AS waiter_sid, h.sid AS holder_sid,
       w.sql_id AS waiter_sql, h.username AS holder_user
FROM   v$session w
JOIN   v$session h ON h.sid = w.blocking_session
WHERE  w.blocking_session IS NOT NULL;

-- 진행 중인 트랜잭션을 오래된 순으로 (오래된 것이 블로커일 가능성)
SELECT t.start_time, s.sid, s.serial#, s.username, s.sql_id
FROM   v$transaction t
JOIN   v$session s ON s.saddr = t.ses_addr
ORDER  BY t.start_time;

• 함께 확인할 지표: Lock Session(대기 중인 세션 수)이 같이 오르면 → 지금 실제로 막혀 있는 세션이 있다는 뜻입니다. Active Session·CPU가 동반이면 → 대기 세션이 쌓이며 부하로 번지는 중입니다. User Rollbacks가 같이 오르면 → 교착으로 트랜잭션이 되돌려지고 있을 수 있습니다.

개발자 관점 — 트랜잭션 범위 안에 외부 API 호출이나 긴 로직을 넣으면 그동안 행 락을 쥐고 있어 같은 행을 건드리는 다른 요청이 대기합니다. 트랜잭션은 짧게 가져가고, 외부 호출이나 무거운 처리는 트랜잭션 밖으로 빼야 합니다. 여러 트랜잭션이 같은 행을 자주 갱신하는 설계 자체도 경합을 늘리는 원인입니다.

실무 시나리오 — 한 트랜잭션이 어떤 행을 수정한 뒤 커밋하지 않고 외부 결제 API 응답을 기다린다고 해보겠습니다. 그 응답이 늦어지는 동안 같은 행(예: 같은 상품 재고)을 수정하려는 요청들이 줄줄이 대기하면서 enq: TX - Row Lock Contention 대기 시간과 Lock Session이 함께 오르고, 대기하는 만큼 활성 세션이 쌓여 CPU와 응답시간까지 동반 악화됩니다. 위 v$transaction으로 가장 오래된 트랜잭션을 찾아 정리하면 한꺼번에 풀립니다. 근본 해결은 외부 호출을 트랜잭션 밖으로 빼고 커밋을 미루지 않는 것입니다.

---

6. I/O · 읽기

메모리에서 해결하지 못한 작업은 결국 디스크로 내려갑니다. Oracle에서 읽기는 두 종류로 나뉩니다. 메모리(버퍼 캐시)에서 읽는 논리 읽기(Session Logical Reads) 와, 캐시에 없어 디스크까지 내려가 읽는 물리 읽기(Physical Reads) 입니다. 책상(메모리)에서 바로 찾으면 빠르고, 서가(디스크)까지 가야 하면 느립니다.

이 영역에는 비슷해 보이지만 다른 개념이 나오므로 먼저 구분해 두겠습니다.

• 블록(block): Oracle이 데이터를 읽는 최소 단위입니다. 행 하나가 아니라 여러 행이 담긴 블록 단위로 읽습니다. Physical Reads·Session Logical Reads는 이 블록 수를 셉니다.
• IOPS(초당 입출력 횟수): 1초에 디스크를 몇 번 읽거나 썼는지, 그 횟수입니다. "서가를 1초에 몇 번 다녀왔나" 에 해당합니다.
• Throughput(처리량): 1초에 실제로 몇 바이트를 읽거나 썼는지, 그 양입니다. "1초에 짐을 몇 kg 날랐나" 에 해당합니다. 횟수(IOPS)가 적어도 한 번에 큰 짐을 나르면 처리량은 클 수 있습니다.
• Latency(지연 시간): 한 번의 작업이 끝나는 데 걸린 시간입니다. 다녀오는 데 얼마나 오래 걸렸나를 봅니다.

Physical Reads (block)

디스크에서 읽어 들인 블록 수입니다. 캐시(버퍼 캐시)에 없어서 어쩔 수 없이 디스크까지 내려가 읽은 것이라, 이 값이 크면 그만큼 느립니다.

• 관측값: 평균 약 27,708 블록, 범위 1,179 ~ 649,044. 평소에도 어느 정도 있고, 어떤 순간 64만 블록을 넘겼습니다. 이 순간이 대형 풀 스캔의 신호입니다.
• 튀면 의심할 것: 인덱스를 못 타고 풀 스캔하는 쿼리, 버퍼 캐시에 없는 대량 데이터를 갑자기 조회, 버퍼 캐시 크기 부족.

물리 읽기를 폭증시키는 대표 원인은 인덱스를 못 타는 풀 스캔입니다.

-- 나쁜 예: 인덱스 없는 컬럼 조건 → 큰 테이블을 통째로 디스크에서 읽는다
SELECT * FROM orders WHERE memo LIKE '%환불%';

-- 고친 예: 인덱스 타는 조건으로 좁히고 필요한 컬럼만 읽는다
SELECT order_id, member_id, total_amount
FROM   orders
WHERE  status = 'REFUNDED'              -- status에 인덱스
  AND  created_at >= DATE '2026-06-01';

-- 물리 읽기를 많이 한 SQL 후보 찾기
SELECT sql_id, disk_reads, executions, sql_text
FROM   v$sql
WHERE  executions > 0
ORDER  BY disk_reads DESC
FETCH FIRST 20 ROWS ONLY;

• 함께 확인할 지표: Session Logical Reads도 같이 크면 → 한 쿼리가 많은 블록을 훑는 풀 스캔입니다. Read IOPS·Read Throughput·Latency가 동반 상승이면 → 디스크 읽기가 실제로 늘어 느려지는 중입니다. CPU도 같이 오르면 → 무거운 읽기 쿼리가 CPU까지 먹는 것입니다.

개발자 관점 — Physical Reads(디스크 읽기)가 늘었다는 것은 코드가 캐시에 없는 데이터를 자주 요청한다는 뜻입니다. 조회 조건·조인 키에 인덱스를 만들어 풀 스캔을 막고, 한 번 쓰고 마는 대용량 스캔은 시간대를 분리하면 디스크 읽기가 줄어듭니다.

Session Logical Reads (block)

메모리(버퍼 캐시)에서 읽은 데이터 블록 수입니다. db block gets과 consistent gets의 합으로, 디스크까지 내려가지 않고 메모리에서 읽은 양을 봅니다. 읽기 요청 전체의 크기를 가늠하는 지표입니다.

• 관측값: 평균 약 557,704 블록, 범위 55,605 ~ 약 1,470만. 평소에도 수십만 블록을 읽고, 어떤 순간 1,400만 블록을 넘겼습니다. 한 쿼리가 엄청난 양을 훑었다는 뜻입니다.
• 튀면 의심할 것: 한 쿼리가 많은 블록을 훑는 비효율(인덱스 미사용·넓은 범위 조회), 대형 조인, 반복 호출되는 비효율 쿼리.

-- 논리 읽기(buffer gets)를 많이 한 SQL 찾기 — 튜닝 1순위 후보
SELECT sql_id, buffer_gets, executions,
       buffer_gets / GREATEST(executions, 1) AS gets_per_exec,
       sql_text
FROM   v$sql
WHERE  executions > 0
ORDER  BY buffer_gets DESC
FETCH FIRST 20 ROWS ONLY;

• 함께 확인할 지표: Physical Reads가 같이 크면 → 캐시에 없는 데이터까지 디스크에서 끌어오는 대형 스캔입니다. 반대로 Logical만 크고 Physical은 작으면 → 캐시엔 있지만 한 쿼리가 너무 많은 블록을 훑는 것(인덱스로 줄일 여지)입니다. CPU가 동반이면 무거운 쿼리입니다.

개발자 관점 — 논리 읽기가 많다는 것은 한 쿼리가 너무 많은 블록을 만진다는 뜻이고, 디스크를 안 건드려도 그만큼 CPU를 씁니다. 위 gets_per_exec(실행당 읽은 블록 수)가 큰 SQL이 튜닝 1순위입니다. 인덱스로 읽는 범위를 좁히면 논리 읽기가 줄고 CPU도 함께 내려갑니다.

실무 시나리오 — 어떤 화면이 갑자기 느려졌는데 Session Logical Reads와 CPU가 동시에 치솟았다면 인덱스를 타지 못하는 쿼리를 의심합니다. 새로 배포된 조회 쿼리가 넓은 범위를 인덱스 없이 훑어, 실행할 때마다 수백만 블록을 만지는 경우입니다. v$sql에서 buffer_gets가 큰 SQL을 찾아 인덱스를 추가하면 논리 읽기가 극적으로 줄고 CPU도 함께 내려갑니다.

Read IOPS (건/초) / Write IOPS (건/초)

초당 디스크 읽기/쓰기 I/O 연산 수입니다. "초당 몇 번 디스크에 접근했나"를 뜻합니다.

• 관측값: Read IOPS 평균 약 3,014(범위 326 ~ 22,510), Write IOPS 평균 약 141(범위 13.6 ~ 5,938). 읽기 IOPS가 평소에도 꽤 높고 순간 2만을 넘기기도 합니다.
• 튀면 의심할 것: Read IOPS가 오르면 → 캐시 미스(물리 읽기 증가). Write IOPS가 오르면 → 대량 쓰기·커밋. 클라우드(RDS)에서는 IOPS에 한도가 있어, 한도에 부딪히면 전체가 느려집니다.
• 함께 확인할 지표: Read IOPS는 Physical Reads와 함께 봅니다 — 물리 읽기가 늘면 Read IOPS도 오릅니다. Write IOPS는 User Commits·Redo Entries·DBWR Undo Block Writes와 함께 보면 → 변경·커밋이 디스크로 내려가는 양을 가늠할 수 있습니다.

개발자 관점 — Read IOPS는 캐시에서 못 찾은 읽기가, Write IOPS는 변경과 커밋이 디스크로 내려가는 양입니다. 매 건마다 커밋하는 코드는 디스크 쓰기를 잘게 늘리므로 묶어서 커밋하면 부담이 줍니다. 클라우드 DB는 IOPS에 한도가 있어, 한도를 넘기는 패턴(잦은 단건 커밋·대량 풀 스캔)은 코드 단계에서 줄여야 합니다.

Read Throughput (Bytes/초) / Write Throughput (Bytes/초)

초당 디스크에서 읽은 / 디스크에 쓴 평균 바이트 수입니다. IOPS가 "횟수"라면 Throughput은 "양"입니다.

• 관측값: Read Throughput 평균 약 96MB/s(범위 3.6MB ~ 약 896MB/s), Write Throughput 평균 약 2MB/s(범위 46KB ~ 약 169MB/s). 읽기 처리량이 순간 수백 MB까지 튀는 것은 대형 풀 스캔이 데이터를 통째로 끌어올 때입니다.
• 튀면 의심할 것: 대량 풀 스캔(읽기 처리량), 대량 적재·대량 변경(쓰기 처리량).
• 함께 확인할 지표: Read Throughput과 Physical Reads·Read IOPS를 함께 봅니다 — 셋이 같이 오르면 대형 풀 스캔입니다. Write Throughput과 Redo Entries·Write IOPS가 동반이면 → 대량 변경이 디스크로 내려가는 중입니다.

개발자 관점 — 처리량은 한 번에 얼마나 많은 데이터를 디스크와 주고받는지를 봅니다. 필요 이상으로 넓은 범위를 읽거나 SELECT *로 불필요한 컬럼까지 끌어오면 읽기 처리량이 커집니다. 필요한 컬럼·범위만 읽도록 좁히면 처리량이 줄고 응답도 빨라집니다.

Latency (초)

트랜잭션당 SQL 수행 시간입니다. 한 작업이 끝나는 데 걸린 평균 시간을 봅니다. 응답 속도를 직접 나타내는 지표라 체감 성능과 가깝습니다.

• 관측값: 평균 약 0.1초, 범위 0.00215 ~ 5.83초. 평소엔 0.1초 안팎으로 빠른데, 어떤 순간 5.8초까지 늘어난 적이 있습니다. 이 순간이 느려진 시점입니다.
• 튀면 의심할 것: 무거운 쿼리(풀 스캔·대형 조인), 디스크 I/O 병목, 락 대기.
• 함께 확인할 지표: Physical Reads·Read IOPS가 같이 오르며 Latency가 길어지면 → 디스크 읽기 병목입니다. enq: TX - Row Lock Contention이 같이 오르면 → 락 대기로 느려진 것입니다(쿼리 자체보다 경합이 원인). Active Session도 같이 오르면 → 느린 쿼리가 쌓이는 중입니다.

개발자 관점 — Latency가 길어졌다는 것은 사용자 체감이 나빠졌다는 뜻입니다. 원인은 보통 무거운 쿼리거나 락 대기입니다. 함께 오른 지표(읽기 폭증인지, 락 대기인지)로 방향을 가르고, 읽기 폭증이면 인덱스를, 락 대기면 트랜잭션 경계를 손봅니다.

실무 시나리오 — 평소 0.1초이던 Latency가 특정 시간대에만 5초로 튄다면, 그 시간에 도는 무거운 배치나 락을 오래 잡는 트랜잭션을 의심합니다. 같은 시각에 Physical Reads가 함께 치솟았다면 대형 풀 스캔, enq: TX 대기가 함께 올랐다면 락 경합입니다. 어떤 지표가 같이 움직였는지가 원인을 가르는 단서입니다.

---

7. 네트워크 · 스토리지

DB가 결과를 주고받는 네트워크 트래픽과, 데이터를 담을 스토리지 여유 공간을 봅니다. 버퍼 캐시가 책상이라면, 여기는 손님에게 들고 나간 짐(네트워크)의 양과 창고에 남은 빈 공간(스토리지)입니다.

클라우드(RDS) 특유의 개념 하나를 먼저 풀어 두겠습니다.

• 버스트(burst, 크레딧): 클라우드 DB(RDS 등)는 디스크·네트워크 성능에 한도를 두는데, 평소에 한도를 다 안 쓰면 그 여유분을 "크레딧" 으로 모아 둡니다. 갑자기 일이 몰리면 모아 둔 크레딧을 헐어 잠깐 한도 이상으로 몰아 쓸 수 있습니다. 이것이 버스트입니다. 휴대폰 데이터를 평소 아꼈다가 필요할 때 몰아 쓰는 것과 비슷합니다. 다만 크레딧이 바닥나면 다시 기본 한도로 떨어지므로, 무거운 작업이 오래 이어지면 어느 순간 갑자기 느려집니다. 아래 EBS Balance 지표가 이 크레딧의 잔량을 봅니다.

Network Transmit Throughput (Bytes/초) / Network Receive Throughput (Bytes/초)

DB 인스턴스가 주고받는 네트워크 트래픽입니다. Transmit(송신)은 DB가 결과를 내보내는 양, Receive(수신)는 DB로 들어오는 쿼리·데이터의 양입니다.

• 관측값: 송신 평균 약 14.5MB/s(범위 2.7MB ~ 약 191MB/s), 수신 평균 약 12.3MB/s(범위 2.7MB ~ 약 22.5MB/s). 송신이 순간 191MB까지 튀는 것은 대량 결과를 퍼내는 쿼리가 돌 때입니다.
• 튀면 의심할 것: 대량 결과를 반환하는 쿼리(SELECT *로 큰 테이블 전체 반환 등), 대량 적재, 복제 트래픽.

-- 나쁜 예: 페이징 없이 큰 테이블 전체를 모든 컬럼으로 반환 → 송신 트래픽 폭증
SELECT * FROM products;

-- 고친 예: 필요한 컬럼만, 페이징으로 잘라서 반환
SELECT product_id, name, price
FROM   products
ORDER  BY product_id
OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY;

• 함께 확인할 지표: 송신 트래픽 급증과 Session Logical Reads가 동반이면 → 큰 결과셋을 퍼내는 쿼리입니다. 수신 트래픽과 Redo Entries·Write IOPS가 동반이면 → 대량 적재가 들어오는 중입니다. 둘 다 평탄한데 한쪽만 튀면 복제 트래픽 등 특정 경로를 의심합니다.

개발자 관점 — 페이징 없이 큰 결과를 통째로 반환하거나 SELECT *로 불필요한 컬럼까지 퍼내면 송신 트래픽이 커집니다. 필요한 컬럼만, 페이지 단위로 잘라 반환하면 송신량이 줄고 응답도 빨라집니다. 대량 적재 쪽은 한 건씩 넣는 대신 묶어서 보내면 수신 트래픽과 왕복 횟수를 함께 줄일 수 있습니다.

Free Storage Space (Bytes)

사용 가능한 스토리지 여유 공간 크기입니다. 인스턴스에 남은 빈 공간을 바이트로 봅니다.

• 관측값: 평균 약 709GB, 범위 약 690 ~ 729GB로 평탄합니다. 여유가 충분한 상태입니다.
• 위험 신호: 임계표는 사용률(%) 기준이라 여유 용량(bytes)에는 절대 임계를 비활성화하고, 대신 여유 공간이 급격히 줄어드는 추세를 감시합니다. 스토리지가 가득 차면 쓰기 자체가 멈춰 장애로 직결됩니다.
• 튀면(줄면) 의심할 것: 대량 적재로 데이터 증가, 정리되지 않고 쌓이는 로그·아카이브 Redo 로그, temp 영역을 크게 쓰는 정렬.

-- 테이블스페이스별 사용량·여유 공간 확인 (가득 차기 전에 미리 본다)
SELECT df.tablespace_name,
       ROUND(SUM(df.bytes)/1024/1024/1024, 1)            AS total_gb,
       ROUND((SUM(df.bytes) - NVL(fs.free_bytes,0))/1024/1024/1024, 1) AS used_gb,
       ROUND(NVL(fs.free_bytes,0)/1024/1024/1024, 1)     AS free_gb
FROM   dba_data_files df
LEFT JOIN (SELECT tablespace_name, SUM(bytes) AS free_bytes
           FROM dba_free_space GROUP BY tablespace_name) fs
       ON fs.tablespace_name = df.tablespace_name
GROUP  BY df.tablespace_name, fs.free_bytes
ORDER  BY free_gb;

• 함께 확인할 지표: (OS) Disk Percent와 반대로 움직입니다(여유가 줄면 디스크 사용률이 오름). Redo Entries·Undo Change Vector Size가 크면 → 변경량이 많아 로그·undo가 공간을 먹는 중입니다.

개발자 관점 — 스토리지는 한 번 차면 쓰기가 멈춰 가장 치명적입니다. 오래된 데이터는 주기적으로 정리·아카이브하고, 대량 적재·삭제는 한 번에 몰지 말고 나눠서 처리합니다. 큰 정렬을 유발하는 쿼리는 temp 공간을 크게 쓰므로 인덱스로 정렬을 대신하게 하는 것도 공간 관리에 도움이 됩니다.

실무 시나리오 — 여유 공간이 평소엔 평탄하다가 어느 날부터 매일 일정량씩 줄어드는 우하향 그래프가 그려진다면, 정리되지 않는 로그나 멈추지 않는 적재 배치를 의심합니다. 추세대로면 며칠 뒤 공간이 바닥나 쓰기가 멈추므로, 절대값이 위험선에 닿기 전에 추세를 보고 미리 손쓰는 것이 핵심입니다.

EBS Byte Balance Max (credits) / EBS IO Balance Max (credits)

RDS 인스턴스의 버스트 버킷에 남아 있는 크레딧 잔량(%)입니다. EBS Byte Balance는 처리량(Throughput) 크레딧, EBS IO Balance는 I/O 크레딧의 잔여 비율입니다.

• 관측값: EBS Byte Balance 평균 약 99%(범위 98 ~ 100), EBS IO Balance 약 99%로 거의 100%에 붙어 있습니다. 크레딧을 거의 안 헐고 있다는 뜻이라 정상입니다.
• 위험 신호: 이 값이 꾸준히 떨어지면 버스트 크레딧을 계속 헐어 쓰고 있다는 뜻입니다. 0%에 닿으면 기본 한도로 떨어져 디스크·네트워크 성능이 갑자기 나빠집니다.
• 튀면(떨어지면) 의심할 것: 무거운 I/O 작업이 오래 지속(대량 풀 스캔·대량 적재가 길게 이어짐).
• 함께 확인할 지표: Read/Write IOPS·Throughput이 오래 높게 유지되면 → 크레딧이 깎이며 이 Balance가 떨어집니다. Balance가 0에 가까워지는데 Latency가 오르면 → 한도로 떨어져 느려지기 시작한 신호입니다.

개발자 관점 — 버스트 크레딧은 평소 아껴 두었다가 잠깐 몰아 쓰는 여유분입니다. 무거운 I/O 작업이 짧게 끝나면 문제없지만, 대량 처리가 오래 이어지면 크레딧이 바닥나 갑자기 느려집니다. 대량 작업을 나눠서 분산하고, 운영 트래픽과 시간대를 분리하면 크레딧 고갈을 피할 수 있습니다.

---

8. 기타

Oracle Elapse Time Monitor (ms)

SQL 수행 시간(Elapse Time)을 흩뿌려(scatter) 보여 주는 모니터링 지표입니다. 개별 SQL이 얼마나 걸렸는지의 분포를 봅니다.

• 단위 주의: 이 지표만 밀리초(ms) 단위입니다. 앞에서 본 다른 시간 지표(Latency·Log File Sync·enq: TX·Library Cache Lock)는 모두 초(sec) 단위였습니다. 같은 "시간"이라도 단위가 달라, 그래프나 리포트에서 숫자를 비교할 때 단위를 반드시 확인해야 합니다. 0.1과 100이 사실 같은 시간(0.1초 = 100ms)일 수 있습니다.
• 읽는 법: scatter 지표는 시계열 평균보다 분포가 핵심입니다. 대부분의 SQL이 짧은데 일부만 길게 튄다면, 그 길게 튄 점들이 느린 쿼리 후보입니다.

-- 수행 시간이 긴 SQL 후보 찾기 (실행당 평균 경과시간, 초 단위로 환산)
SELECT sql_id,
       ROUND(elapsed_time / GREATEST(executions, 1) / 1e6, 3) AS avg_sec,
       executions, sql_text
FROM   v$sql
WHERE  executions > 0
ORDER  BY elapsed_time / GREATEST(executions, 1) DESC
FETCH FIRST 20 ROWS ONLY;

• 함께 확인할 지표: Latency가 같이 길어지면 → 전반적으로 SQL이 느려진 것입니다. 특정 SQL만 길게 튀면 v$sql에서 그 sql_id를 찾아 실행계획(인덱스 사용 여부)을 봅니다.

개발자 관점 — Elapse Time이 길게 튀는 SQL은 대부분 인덱스를 못 타거나 결과를 너무 많이 다루는 쿼리입니다. 단위가 ms라는 점만 유의하면, 위 v$sql 조회로 느린 SQL을 찾아 인덱스·결과 크기를 손보는 흐름은 앞의 다른 지표들과 같습니다.

---

상황별로 보기 — 배치·백업이 돌 때 어떤 지표가 움직이나

지금까지는 지표를 하나씩 봤지만, 실제로는 하나의 작업이 여러 지표를 동시에 움직입니다. 특히 정기 배치나 백업처럼 정해진 시간에 도는 작업은 매번 비슷한 지표 묶음을 끌어올립니다. Oracle은 Redo·Undo 계열이 변경량에 민감하게 반응해서, 배치의 종류를 지표 패턴으로 구분하기 좋습니다.

배치 유형별 예상 지표 변화

배치 유형	함께 오르는 지표	이유
대량 적재 (INSERT/UPDATE/DELETE)	Redo Entries, Undo Change Vector Size, DBWR Undo Block Writes, Log File Sync, Write IOPS·Write Throughput, CPU	변경할 때마다 Redo(변경 기록)와 Undo(변경 전 값)가 생기고, 커밋이 Redo flush를 기다리며, 그 결과가 디스크 쓰기로 내려감
집계·리포트 (대량 SELECT)	Physical Reads, Session Logical Reads, Read IOPS·Read Throughput, Latency, CPU	큰 테이블을 훑어 집계하므로 읽은 블록 수·디스크 읽기가 급증하고 응답이 느려짐
대량 삭제·정리 (DELETE)	Redo Entries, Undo Change Vector Size, enq: TX - Row Lock Contention, Write IOPS	많은 행을 한 번에 지우면 Redo·undo가 크게 쌓이고 락을 오래 잡음
백업	Read IOPS·Read Throughput, Network, CPU(약간), EBS Balance 하락	데이터 전체를 읽어 내보내므로 디스크 읽기·네트워크가 오르고, I/O 크레딧이 깎임
바인드 변수 미사용 코드 배포	Parse Count (Hard), Library Cache Lock, CPU	값을 박은 SQL이 매번 새 문장으로 보여 Hard parse가 폭증하고 Library Cache 경합이 생김

예를 들면

매일 새벽 통계 배치가 큰 테이블을 풀 스캔해 집계한다고 해보겠습니다. 그 시간에는 Session Logical Reads가 수백만 블록으로 뛰고, Physical Reads와 Read IOPS·Read Throughput이 따라 오르며, Latency가 길어지고 CPU도 집계 연산으로 같이 오릅니다. 이 묶음이 같은 시각에 함께 움직이는 것이 이 배치의 지문 같은 패턴입니다.

월말 대량 적재 배치라면 반대로 Redo Entries·Undo Change Vector Size·DBWR Undo Block Writes가 같이 오릅니다. 만약 이때 적재를 하나의 큰 트랜잭션으로 묶어 커밋을 늦게 하면, undo가 크게 쌓이고 enq: TX 락 대기까지 동반될 수 있습니다. 매 건 커밋으로 바꾸면 이번엔 Log File Sync가 치솟습니다. 그래서 대량 작업은 너무 크지도 너무 잘지도 않은 묶음(수천~수만 건)으로 나눠 커밋하는 것이 균형점입니다.

핵심 — "언제" 올랐는지가 중요하다

여기서 중요한 점은, 이 지표들이 배치 시간대에 함께 오르는 것은 정상이라는 것입니다. 정해진 작업이 정해진 시간에 자원을 쓰는 것이니까요. 문제가 되는 경우는 두 가지입니다.

• 배치가 없는 시간대에 같은 패턴이 나타날 때 — 누군가 수동으로 무거운 쿼리를 돌렸거나, 의도치 않은 작업이 돈다는 신호입니다.
• 배치 시간대인데 평소보다 훨씬 크게, 오래 튈 때 — 데이터가 그만큼 늘었거나, 쿼리가 비효율적으로 바뀌었을 수 있습니다.

그래서 모니터링에서는 절대값만큼 "평소 이 시간대와 비교해서 어떤가" 가 중요합니다. 매일 같은 시각에 같은 모양으로 오르내리는 그래프라면 그건 배치의 정상 리듬이고, 그 리듬에서 벗어나는 순간이 들여다볼 지점입니다.

---

정리하며

Oracle 지표는 MySQL보다 처음 보는 단어가 많았지만, 무엇을 의미하고 / 평소 어느 정도이고 / 튀면 뭘 의심하고 / 어떤 쿼리로 확인하는지 로 묶고, 비유와 실제 장애 시나리오, 실측 범위를 붙여 정리하니 한결 명확해졌습니다. 핵심 개념(SGA·Redo·Undo·Library Cache·파싱·테이블스페이스)을 먼저 잡아 두니, 지표들이 그 개념들의 동작으로 자연스럽게 이어졌습니다.

Oracle에서 기억해 둘 핵심은 다음과 같습니다.

• "연결(Total Session)" 과 "활성(Active Session)" 은 다르다. 위 인스턴스도 연결은 약 3,700인데 활성은 1 안팎이었다. 부하는 활성으로 본다.
• Redo·Undo는 변경량의 거울이다. Redo Entries·Undo Change Vector Size가 평소 작다가 순간 수십만, 수억으로 튀면 대량 DML 배치다. 대량 변경은 나눠서 커밋한다.
• Library Cache·파싱은 바인드 변수가 핵심이다. Parse Count (Hard)가 튀면 거의 바인드 변수 미사용이다. 값을 문자열로 박지 말고 바인드 변수로 넘긴다.
• 읽기는 논리(Session Logical Reads)와 물리(Physical Reads)로 나뉜다. 둘 다 순간 최댓값이 크면 풀 스캔을 의심하고, v$sql의 buffer_gets·disk_reads로 범인 SQL을 찾는다.
• 테이블스페이스·Free Storage Space는 가득 차면 쓰기가 멈춘다. 절대값보다 줄어드는 추세를 본다.
• 시간 지표 단위에 주의한다. Latency·Log File Sync·enq: TX·Library Cache Lock은 초인데, Oracle Elapse Time Monitor만 ms다.
• 대부분의 지표는 혼자 튀지 않는다. CPU·Active Session·Reads·IOPS·Redo가 같은 시각에 함께 움직이는지를 보면 원인의 윤곽이 잡힌다. 그래서 각 지표마다 "함께 확인할 지표"를 같이 적어 둔 것이다.

다음 글에서는 PostgreSQL 지표를 같은 방식으로 정리해 보겠습니다. PostgreSQL은 Vacuum, Dead Tuple, 트랜잭션 ID 노화(Age) 처럼 MVCC를 청소하는 과정에서 나오는 그 DB만의 지표가 있어, Oracle의 Undo와 비교해 보면 같은 문제(변경 전 데이터 정리)를 데이터베이스마다 어떻게 다르게 푸는지가 잘 보일 것 같습니다.

---