성능을 고려한 설계

• 데이터베이스 관련 설계 문제 10개만 논의

취약한 논리 데이터베이스 설계

• "예전에는" 모든 개발 프로젝트에 DA가 참여 (무결성, 성능 보장을 위한 DB 설계)
• "오늘날은" DB 설계 없는 프로젝트 존재 (개발자가 Persistence Framework 활용하여 DB 생성)
  • DB는 데이터 저장을 위한 바보상자가 아님

지나친 범용 테이블 사용

• 유연성 : 변경된 요구사항에 쉽게 대응 → 범용 DB 설계 적용 (객체 변경 불필요)
  • 엔티티-속성-값(Entity - Attribute - Value, EAV) 모델
  • XML 기반 설계 : 식별 키 + XML 컬럼 + 메타 컬럼

• 성능 관점에서 위의 설계는 잘해야 차선 (성능과 유연성은 대립 관계)
  • 성능 요구 사항 만족 시 적용 가능

데이터 무결성을 위한 제약조건 미사용

• 제약조건(Constraints)은 데이터 무결성 보장, 실행 계획 생성 시 활용(옵티마이저)
• 어플리케이션 레벨 제약조건 검사 → 데이터베이스 제약조건 설정
• 어플리케이션 레벨 검사 단점
  • 더 많은 코드 와 테스트 수반
  • DB 레벨에서 데이터 직접 수정 시 무결성 손실
  • 무결성 유지를 위해 더 많은 리소스 사용 및 확장성 저하

취약한 물리데이터베이스 설계

• 취약 : 논리 설계 →(곧바로 변환)→ 물리 설계
  • 모든 릴레이션(Relation)을 오라클 기능 활용 없이 힙(Heap) 테이블로 매핑

• 위는 성능 관점에서 최적 접근법 아님
  • IOT, Indexed Cluster, Hash Cluster 적용 가능
  • B-트리, Bitmap 인덱스 외 기능 제공
    • Compressed, Reverse-Key, Function-Based, Linguistic, Text 인덱스
  • 파티셔닝
  • 데이터 아카이빙 정책 정의, 구현

적합하지 못한 데이터타입 선택

• 적절치 못한 데이터타입 선택 : DATE 대신 VARCHAR2 에 날짜 저장 케이스
• 문제점
  • 취약한 데이터 유효성 검증 : DB 외부에서 검증은 1.2.3 과 같은 문제점 야기
  • 정보의 손실 : DATE 타입에 TIMESTAMP 저장시 밀리세컨드 정보 손실
  • 예상대로 동작하지 않음 : 다른 타입 끼리 비교 연산시 다른 의미로 해석될 수 있음 (ORDER BY)
  • 쿼리 옵티마이저 이상 현상 : 옵티마이저가 잘못된 추정 → 잘못된 실행 계획 작성

바인드 변수 미사용

• 바인드 변수 사용
  • 장점 : LC 에서 커서 공유(하드파싱 감소), SQL Injection 방지
  • 단점 : 옵티마이저에 변수 값 정보 미전달

고급 데이터베이스 기능 미사용

• 오라클 고급 기능 활용 하여 ROI 극대화
  • 성능 강화, 디버깅/개발 비용 감소 등
• 이미 DBMS 에서 제공하는 기능 다시 개발 지양
• 포팅을 고려할 수 있으나 가능성이 낮음

데이터 중심적인 처리에 PL/SQL 미사용

• 대량 데이터 처리는 SQL 및 PL/SQL 엔진 활용이 유리 함 (소스 타겟이 같은 DB 일 때)
  • ETL(Extract - Transform - Load) : DB 외부에서 변환 수행
  • ELT(Extract - Load - Transform) : DB 내부에서 변환 수행
    • 데이터 중심의 처리는 가능한 데이터와 가까운 곳에서 수행 권장

불필요한 커밋 수행

• 커밋 : 직렬화 필요 오퍼레이션 (LGWR 프로세스 1개)
  • 확장성을 위해 직렬화는 최소화 필요
  • 여러개의 트랜잭션을 하나로 묶기 (예: 배치 작업)

데이터베이스 커넥션을 반복적으로 열고 닫음

• 커넥션 열기 : 서버에 전용 프로세스(Dedicated Process) 생성(Fork)
• 권장 : Connection Pool 사용 (전용 프로세스 재활용)