Firebird 성능 진단 체크리스트(실무용 완성본)

🚀 Firebird 성능 진단 체크리스트(실무용 완성본)

이 문서는 Firebird 데이터베이스 성능 문제를 빠르게 진단할 수 있도록 만들어진
현장용 체크리스트입니다.
총 7개 영역(50개 항목)으로 구성되어 있으며 하루 진단 / 주간 점검 / 월간 점검에 모두 사용할 수 있습니다.

---

1️⃣ 인덱스 점검

✔ 기본 인덱스 상태

• WHERE 조건에 사용되는 컬럼에 인덱스가 있는가?
• JOIN ON 절에 사용되는 컬럼에 인덱스가 있는가?
• PRIMARY KEY / FOREIGN KEY 인덱스가 정상적으로 생성되어 있는가?
• 인덱스가 너무 많은 것은 아닌가? (10개 이상이면 리뷰 필요)

✔ 인덱스 품질(선택도)

• 선택도(Selectivity)가 낮은 인덱스는 제거 대상인가?
• 중복값이 많은 컬럼에 인덱스를 구성하지 않았는가?
• 날짜/상태값(Y/N, 0/1) 같은 저선택도 컬럼에 인덱스가 남발되지 않았는가?

✔ 인덱스 스캔 확인

• 주요 쿼리의 PLAN에서 NATURAL 발생 여부 확인
• 테이블 크기(> 100만 로우)인데 NATURAL 스캔이면 반드시 원인 조사

---

2️⃣ SQL 쿼리 성능 점검

✔ SELECT

• SELECT * 사용을 피하고 필요한 컬럼만 가져오는가?
• ORDER BY에 함수/표현식을 사용하여 인덱스를 무력화하고 있지 않은가?
• LIKE '%keyword%' 사용 빈도가 높은가? (Full scan 유발)

✔ JOIN 성능

• JOIN 컬럼 양쪽 모두 인덱스가 있는가?
• FULL JOIN을 사용하고 있지 않은가? (Firebird에서 매우 느림 → 반드시 재작성)
• LEFT JOIN이 남용되어 있지는 않은가?

✔ 서브쿼리

• 상관 서브쿼리(Correlated Subquery)를 JOIN으로 대체 가능한가?
• EXIST/IN/NOT IN에서 인덱스가 사용되는지 확인했는가?

---

3️⃣ 테이블 상태 & 데이터 구조

✔ 테이블 크기 관리

• 100만 로우 이상 테이블은 월간 점검 대상인가?
• 불필요한 로그/백업 테이블에 purge 전략이 있는가?
• 대량 DELETE 시 분할 삭제(batch delete)를 사용하는가?

✔ 컬럼 구조

• TEXT/BLOB 컬럼이 과하게 사용되고 있는가?
• UPPER(), TRIM() 등 함수 기반 정규화 컬럼이 필요한가?
• Generated Column으로 인덱스를 만들 여지가 있는가?

---

4️⃣ 트랜잭션 관리

✔ 트랜잭션 상태

• 장시간 오픈(몇 시간~며칠)된 트랜잭션이 존재하지 않는가?
• Commit/Rollback 누락이 발생하지 않는지 모니터링되는가?
• Autocommit의 남용이 있는가?

✔ 스냅샷 기반의 문제 예방

• Oldest Active / Oldest Snapshot / Next Transaction Number 간의 갭이 너무 크지 않은가?
  → 큰 갭 = 오래된 트랜잭션 방치 = 성능 저하
• Sweep가 정상적으로 동작하고 있는가?

---

5️⃣ 서버 설정 & 환경 점검

✔ Firebird 설정(firebird.conf)

• DefaultDBCachePages 설정이 환경에 맞는가?
• TempCacheLimit이 충분한가?
• LockHashSlots 등 Lock 관리 설정 정상?

✔ OS & 하드웨어

• SSD 기반인가? (HDD는 Firebird에서 느림)
• RAID 구성 시 write penalty 최소화 구조(RAID 10 등)인가?
• RAM 용량이 충분한가? (8GB 이상 권장, 대형 DB는 16GB~32GB)

✔ 네트워크

• 3050 포트 지연 없음
• 중간 방화벽/프로시가 session을 끊지 않는가?

---

6️⃣ 백업/복구 & 유지관리

✔ 백업(gbak)

• gbak 풀 백업이 최근 7일 안에 정상 실행되었는가?
• 백업 파일이 무결한지 검증되었는가?
• 백업 스케줄이 병목을 일으키지 않는가?

✔ 복구(grestore)

• 주기적으로 test restore를 실행하는가?
• 복구 시 performance degradation 체크 여부

✔ Rebuild (옵션)

• 인덱스 rebuild 필요 여부 검토
• OAT/OST 갭 체크 후 필요 시 sweep or manual cleanup 진행

---

7️⃣ 스토어드 프로시저 & 트리거

✔ 스토어드 프로시저

• SELECT FOR 루프 내부에 NATURAL scan이 있는가?
• 필요 시 PLAN을 명시했는가?
• 임시 테이블 사용 여부 정상인가?

✔ 트리거

• AFTER UPDATE/INSERT 트리거가 과도한 연산을 하는가?
• BLOB 업데이트 등 무거운 작업을 트리거에 넣지 않았는가?
• 트리거 내부에서 불필요한 SELECT/UPDATE가 없는가?

---

🎯 Firebird 성능 문제를 의심해야 하는 신호들

다음 중 하나라도 발생하면 즉시 점검 대상입니다:

• 쿼리가 갑자기 느려졌다
• CPU가 높지 않은데도 DB 응답이 느리다
• NATURAL 스캔이 증가했다
• Oldest Active Transaction(OAT) 정체
• Sweep이 비정상적으로 오래 걸린다
• 인덱스가 “stuck” 상태
• 백업 파일 크기가 갑자기 증가
• 특정 시간대에만 응답이 느려진다

---

📌 Firebird 성능 점검 10분 프로세스(요약 버전)

1. PLAN 확인 (NATURAL 여부 체크)
2. 인덱스 확인 (유효한가? 선택도는?)
3. 트랜잭션 상태 확인 (OAT, OST)
4. 대량 DELETE/UPDATE 여부 (미완료 트랜잭션 있는지)
5. 스케줄러 작업 확인 (백업/Sweep 시간)
6. 서버 리소스 체크 (Disk I/O, RAM, Swap, CPU)
7. 스키마 변경 이력 확인 (최근 인덱스 삭제?)
8. 어플리케이션 로그 확인
9. 쿼리 캐시/실행 빈도 점검
10. Firebird 로그(firebird.log) 점검