성능을 고려한 설계
DB CAFE
thumb_up 추천메뉴 바로가기
- DBA { Oracle DBA 명령어 > DBA 초급 과정 > DBA 고급 과정 }
- 튜닝 { 오라클 튜닝 목록 }
- 모델링 { 데이터 모델링 가이드 }
목차
1 DB 성능을 고려하여 설계 하는 법[편집]
1.1 지나친 범용 테이블 사용 자제[편집]
- 어플리케이션 개발시 유연성이 핵심이나 데이터베이스는 유연성이 성능에 최악이라는것을 명심해야한다.
- 성능을 고려하여 하나를 최적화 시키면 다른 하나는 최악인 경우가 많기 때문이다.
1.2 데이터 무결성 제약 조건을 반드시 검토 하라[편집]
- 제약조건(Constraints: PK,FK,UK,NOT NULL, CHECK) 은 데이터 무결성 보장 및 쿼리 옵티마이저의 실행계획을 세울때 중요하게 사용된다.
- 어플리케이션에서 제악조건을 검사하는 것은 한계가 있다는걸 명심해야한다.(데이터는 게속 변하기 때문에 속성도 변하게 된다.)
1.3 취약한 물리 DB 설계[편집]
- 모든 테이블을 heap테이블로 설계해야한다는 고정관념을 버려라
- 성능을 고려하여 IOT(Index-Organized Table),Indexed Cluster,Hash Cluster 사용을 검토하라.
- 인덱스 설계시에 성능을 고려하여 비트맵인덱스,Compressed 인덱스,Reverse-key 인덱스,Function-based 인덱스,Text 인덱스 사용을 검토하라
- 대용량 테이블은 파티셔닝 인덱스 설계를 검토하라.
1.4 부적절한 데이터타입 검토[편집]
- 날짜 속성에 사용하는 타입에서 DATE,TIMESTAMP,VARCHAR2 중 부적절한 타입을 사용하여 문제가 많이 발생된다.
- 발생되는 주요 문제점
- 취약한 데이터 유효성 검증
- :문자형 데이터타입에 숫자값을 저장하지 않도록 한다.
- 데이터 변환시 정보 손실
- : 발생시간 + 날짜를 TIMESTAMP WITH TIME ZONE 데이터타입을 사용하지 않고 DATATYPE 으로 저장시 초 단위 아래의 밀리세컨즈 정보와 타임존 정보는 손실된다.
- 예상치 못한 동장 발생
- : RANGE 파티셔닝 테이블과 ORDER BY 절 이슈
- 쿼리 옵티마이져 이상 현상
- : 잘못된 데이터타입으로 인하여 옵티마이져의 잘못된 판단 발생
- 취약한 데이터 유효성 검증
1.5 바인드 변수를 사용하라[편집]
- 바인드 변수 사용 장단점
- 장점
- 라이브러리 캐시에 커서를 공유하여 사용할수 있다.
- 커서를 공유한다는것은 SQL의 하드파싱을 줄여주고 오버헤드를 감소 시킨다.
- 단점
- WHERE 절에 사용되는 바인드 변수는 쿼리 옵티마이져에게 중요한 정보를 제공하지 못한다는것임.
- 쿼리 옵티아미져 입장에서는 리터럴 SQL이 모든 SQL구문의 실행계획을 최적화하는데 좋다.
- 장점
1.6 고급 데이터베이스 기능 사용을 자제 하라[편집]
- 가상 컬럼 사용 문제점 (export/import시 문제 발생)
- 다른 시스템으로 포팅시 큰문제가 발생됨
1.7 데이터 중심적인 처리에 PL/SQL 사용 하라[편집]
- 추출 과 적재가 동일한 데이터베이스 환경이라면 PL/SQL을 이용하여 변환하는게 최적이다.(ETL툴을 이용하여 추출,적재하는것 보다는)
1.8 불필요한 커밋 수행을 자제하라[편집]
- commit은 직렬화가 필요한 오퍼레이션임.(리두로그 파일에 기록하는 로그라이터(LGWR) 프로세스가 하나이기 때문)
- insert 할때마다 commit을 수행하는것 보다는 일괄로 insert 된 데이터에 한번 커밋을 수행.
1.9 DB 연결을 반복적으로 열고 닫기[편집]
- DB연결시 오라클서버에서 전용 프로세스가 생상됨
- 커넥션풀을 사용하여 오라클 전용프로세서에 대한 오버헤드를 줄여야함.