4-18강. 물리 데이터베이스 설계-물리데이터 모델 품질검토

과목4. 데이터베이스 구축, 18강. 물리 데이터베이스 설계-물리데이터 모델 품질검토

 

[ 목차 ]

1. 물리데이터 모델 품질 검토 필요성

2. 물리데이터 모델 품질 기준

3. CRUD

4. CRUD 분석절차

5. CRUD 매트릭스 상관 모델링 규칙

6. CRUD 매트릭스를 통해 얻을 수 있는 장점

7. SQL 성능 튜닝

8. SQL 성능 튜닝 필요성

9. SQL 튜닝 방법

10. SQL 튜닝 기초지식

11. SQL 튜닝 심화

 

1. 물리데이터 모델 품질 검토 필요성

1) 물리 데이터 모델은 시스템 성능에 대해 직접적 영향을 미치기 때문에 향후 발생할 수 있는 성능 문제 최소화를 위한 노력

 

2. 물리데이터 모델 품질 기준

1) 정확성

  1] 데이터 모델이 표기법에 따라 정확히 표현

  2] 업무 영역 또는 요구사항이 정확하게 반영

2) 완전성

  1] 데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화

  2] 요구사항 및 업무 영역 반영에 있어서 누락을 최소화

3) 준거성

  1] 제반 준수 요건들이 누락 없이 정확하게 준수

4) 최신성

  1] 현행 시스템의 최산 상태를 반영

  2] 이슈사항들이 지체없이 반영

5) 일관성

  1] 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되괴 이를 다른 영역에서 참조, 활용

  2] 모델 표현상의 일관성을 유지

6) 활용성

  1] 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달

  2] 업무 변화 시에 설계 변경이 최소화되도록 유연하게 설계

 

3. CRUD

1) 기본적인 데이터 처리 기능

2) CRUD 분석 : 프로세스와 엔터티의 상관관계를 이용해 구축된 데이터베이스 시스템을 검증하는 방법

     이름      조작      SQL      HTTP

2) CREATE - 생성 - INSERT - PUT/POST

3) READ - 읽기/인출 - SELECT - GET

4) UPODATE - 갱신 - UPDATE - PUT/PATCH

5) DELETE 삭제 - DELETE - DELETE

 

4. CRUD 분석절차

1) 모든 엔터티 목록을 나열하고 각각의 프로세스가 해당 엔터티에 대해 생성, 조회, 변경, 삭제하는가 여부를 표기

2) CRUD 매트릭스 작성 후 아래 항목들을 점검

  1] 트랜잭션 발생 횟수, 연관된 데이터 분석 이유 : 저장되는 데이터의 양을 유추가능

  2] 디스크 구성 시 유용한 자료로 활용

  3] 부하가 집중되는 데이터베이스 채널 분산

 

5. CRUD 매트릭스 상관 모델링 규칙

1) 쓸모없는 엔터티 타입이 도출되는 경우, 적절한 단위 프로세스가 도출되지 않은 경우, 단위 프로세스의 CRUD가 ㅜㅇ분히 정의되지 않은 경우인지를 판단하여 적절한 조치

2) CRUD 매트릭스에는 C가 한번 이상 있어야 함(C가 없으면 RUD가 불가능)

3) 최소한 1번은 R이 존재해야 함

4) 단위 프로세스와 관련된 엔터티타입이 누락된 경우 추가

5) 하나의 엔터티에 C가 2개 이상 존재 X

 

6. CRUD 매트릭스를 통해 얻을 수 있는 장점

1) 분석 단계의 데이터 모델과 프로세스 모델에 대한 작업을 검증

2) 시스템 구축 단계에서 애플리케이션을 개발하는데 필요한 중요 산출물로 사용

3) 테스트 단계에서 개발한 애플리케이션 테스트

4) 전페 업무간 인터페이스 파악 가능

 

7. SQL 성능 튜닝

1) 튜닝 대상이 되는 SQL을 이해하고 SQL이 가진 정보를 분석하여 성능을 개선하는 활동

2) 최소한의 CPU, I/O, 메모리를 사용하여 최대한 빠른 시간내에 원하는 작업을 수행하도록 SQL 수정

 

8. SQL 성능 튜닝 필요성

3) 개발 작업은 운영 환경이 아닌 개발 환겨에서 이루어지기 때문에 개발 환경에서 작성된 SQL을 운영 환경에서 실행했을 때 과도하게 느린 경우가 존재

4) 모든 개발자가 일정한 수준 이상의 SQL 구사 능력을 보유

5) 개발 환경은 데이터의 구성이나 데이터의 양이 운영 환경과 차이 존재

 

9. SQL 튜닝 방법

1) 튜닝 대상 SQL 수집

  1] 필요 이상의 자원을 사용

  2] 서버의 자원을 독점하여 다른 SQL에 영향

  3] 향후 문제가 될 가능성이 있는 SQL

2) SQL 문제점 분석 및 개선사항 도출

  1] 데이터가 운영 환경과 유사한 경우 수집된 SQL의 수행정보가 분석을 위한 정보로 가치가 있기 때문에 이력정보를 이용하고 TRACE 파일 분석이나 DBMS XPLAN 패키지를 활용한 분석 방법 등 사용

  2] 데이터가 운영 환경에 비해 적거나 다른 경우 해당 SQL의 실행계획을 중심으로 튜닝대상 SQL을 판단, 분석

3) 개선사항 적용 및 개선 효과 확인

  1] 성능 튜닝을 수행하는 담당자들은 개발자들에 비해 제한된 정보만으로 SQL을 검토할 가능성이 높기 때문에 개발자 차원에서의 검토가 충분히 필요

  2] 개발자와 튜너 사이의 상호검증을 통해 SQL의 성능 최적화 필요

  3] 개선사항 적용 후에는 튜닝을 통해 목표하는 결과에 도달했는지 확인하고 그렇지 못한 경우 추가분석과 튜닝 필요

 

10. SQL 튜닝 기초지식

1) WHERE 안에서 연산자의 처리 성능을 숙지

2) 조건절 칼럼에 함수는 사용하지 않음

3) 조건절에 NOT 사용 자제

4) 조건절에서 범위를 다룰 때 가급적 BETWEEN 사용

5) IN이나 EXISTS의 다음에 오는 SELECT문의 결과내용이 많을수록 JOIN 형태인 EXISTS문이 적당함

6) FROM절에 나열되는 테이블들으리 순서는 기준이 되는 테이블일수록 뒤쪽에 위치시키는 것이 속도에 좋음

7) JOIN만 한 것이 OUTER JOIN을 한 것보다 속도가 더 빠르며 OUTER JOIN은 되도록 피하고 대신 UNIOM을 사용하는 것을 고려

8) 인라인뷰를 사용하기 전에 JOIN을 사용하여 처리가능한지 확인하고 인라인뷰를 사용하게 될 경우 SELECT 문의 결과가 최소가 되도록 함. JOIN하는 테이블이 많을 경우에 인라인뷰를 고려

인라인 뷰 : 하나의 질의문 내에서만 생성되어 사용 되어지고 질의문 수행 종료 후에느 사라지는 뷰
- 뷰의 명시적인 선언이 없음
- FROM 절에서 서브 쿼리를 사용하여 생성하는 임시 뷰

11. SQL 튜닝 심화

1) 옵티마이저 선택/변경

  1] 사용자가 질의한 sql문에 대해 최적의 실행 방법을 결정하는 역할

  2] rule based optimizer : 통계 정보가 없는 상태에서 미리 정해진 룰에 따라 실행계획 수립

  3] cost based optimizer : 통계 정보로부터 모든 access path 고려하여 실행계획 수립

  4] 옵티마이저가 선택한 실행계획을 확인하고 최적화된 실행계획 수립이 이루어지도록 factor(인수) 부여

2) 힌트 사용

  1] 옵티마이저가 항상 최적화된 실행계획을 수립하는 것은 아니기에 힌트를 사용하여 원하는 실행계획으로 유도

3) 부분범위 처리

  1] 조건을 만족하는 전체집합이 아닌 일부분만 액세스하고도 결과를 리턴 할 수 있도록 하여 온라인 프로그램에서 응답시간 최소화

4) 인덱스 활용

  1] 인덱스가 있음에도 불구하고 sql을 잘 못 기술함으로써 무용지물로 만드는 오류를 없애야 함

5) 조인방식/조인순서 

  1] 동일한 sql문이라도 조인 방식과 순서에 따라 처리속도는 매우 큰 차이를 가져올 수 있기에 작성한 sql이 어떤 실행계획으로 수립되는지 확인 후 조정

6) 다중처리

  1] 배치작업의 경우 한번의 dbms 호출로 여러 건을 동시에 처리할 수 있는 다중 처리 활용

7) 병렬쿼리

  1] 배치작업의 경우 하나의 sql을 여러 개의 cpu가 병렬로 분할 처리하게 함으로써 처리속도 향상을 가져옴

8) dynamic sql 지양(사용하지 말라는 의미)

  1] 조건절에 입력된 값을 먼저 바인딩한 후 실행계획을 수립하는 다이나믹 sql은 파싱 부하가 커지므로 입력 값을 바인딩하기 전에 실행계획을 수립하는 static sql을 가급적 사용하도록 함