Chapter02.SQL Performance Methodology

2.1 응용 프로그램 설계 지침
좋은 SQL 성능을 얻으려면 애플리케이션의 성능을 염두에 두어야합니다.
 
2.1.1 데이터 모델링 지침
데이터 모델링은 성공적인 애플리케이션 설계에 중요합니다. 비즈니스 관행을 나타내는 방식으로 데이터 모델링을 수행해야합니다. 
정확한 데이터 모델에 대한 논쟁이 가열 될 수 있습니다. 중요한 것은 가장 빈번한 비즈니스 트랜잭션에 의해 영향을 받는 이들 개체에 
큰 모델링에 노력을 적용하는 것입니다. 모델링 단계에서 비 핵심 데이터 요소를 모델링하는데 너무 많은 시간을 소비하려는 유혹이 있으며 
개발 리드 타임이 늘어납니다. 모델링 도구를 사용하면 신속하게 스키마 정의를 생성 할 수 있으므로 빠른 프로토타입이 필요할 때 유용 할 수 있습니다.
 
2.1.2 효율적인 응용 프로그램 작성 지침
시스템 개발의 설계 및 아키텍처 단계에서 응용 프로그램 개발자가 SQL 실행 효율성을 이해하는지 확인하십시오.
이 목표를 달성하려면 개발 환경이 다음 특성을 지원해야합니다.
• 좋은 데이터베이스 연결 관리
데이터베이스에 연결하는 것은 확장 할 수 없는 값 비싼 작업입니다. 따라서 데이터베이스에 대한 동시 연결 수를 최소화하는 것이 가장 좋습니다. 
사용자가 응용 프로그램 초기화 시 연결하는 간단한 시스템이 이상적입니다. 그러나 응용 프로그램 서버가 데이터베이스 연결을 사용자에게 
다중화 하는 웹 기반 또는 다중 계층 응용 프로그램에서 이 접근 방법은 어려울 수 있습니다. 이러한 유형의 응용 프로그램에서는 
데이터베이스 연결을 풀링하고 각 사용자 요청에 대한 연결을 다시 설정하지 않도록 응용 프로그램을 설계하십시오.
 
• 좋은 커서 사용 및 관리
사용자 연결을 유지하는 것은 시스템에서 파싱 작업을 최소화하는 것과 똑같이 중요합니다. 
구문 분석은 SQL문을 해석하고 이에 대한 실행 계획을 작성하는 프로세스입니다. 이 프로세스는 구문 검사, 보안 확인, 실행 계획 생성, 공유 구조로 
공유 구조 로드 등의 많은 단계가 있습니다.
구문 분석 작업에는 두 가지 유형이 있습니다.
- 하드 파싱
SQL문이 처음 제출되고 공유 풀에서 일치하는 항목이 없습니다. 하드 파싱은 구문 분석과 관련된 모든 작업을 수행하기 때문에 
가장 리소스 집약적이고 확장성이 뛰어납니다.
- 소프트 파싱
SQL이 처음 실행되고 공유 풀에서 일치된 것이 발견됩니다. 일치된 것은 다른 사용자가 이전에 실행한 결과 일 수 있습니다. 
성능에 최적화된 SQL문이 공유됩니다. 그러나 소프트 구문 분석은 이상적이지 않습니다. 시스템 리소스를 소비하는 
구문 및 보안 검사가 여전히 필요하기 때문입니다.
 
가능한 한 구문 분석을 최소화 해야 하기 때문에 응용 프로그램 개발자는 응용 프로그램을 설계하여 SQL문을 한 번 구문 분석하고 
여러 번 실행해야 합니다. 이것은 커서를 통해 수행됩니다. 숙련된 SQL 프로그래머는 커서를 열고 다시 실행하는 개념에 익숙해야 합니다.
• 바인드 변수의 효과적인 사용
응용 프로그램 개발자는 SQL 문이 공유 풀 내에서 공유되도록 해야 합니다. 이 목표를 달성하려면 바인드 변수를 사용하여 실행되는 
쿼리 부분을 나타냅니다. 이것이 수행되지 않으면 SQL문은 한 번 구문 분석되어 다른 사용자가 다시 사용할 수 없게 됩니다. 
SQL이 공유되도록 하려면 바인드 변수를 사용하고 SQL 문에 문자열 리터럴을 사용하지 마십시오.
문자열에 리터럴이 있는 문:
SELECT *
FROM employees
WHERE last_name LIKE 'KING';
 
바인드 변수를 사용한 선언문:
SELECT *
FROM employees
WHERE last_name LIKE :1;
 
 
다음 예제는 간단한 OLTP 응용 프로그램의 일부 테스트 결과를 보여줍니다.
테스트                                          #지원되는 사용자
모든 문을 구문 분석하지 않음       270
모든 문장의 소프트 구문 분석       150
모든 문장을 하드 구문 분석         60
각 트랜잭션 다시 연결               30
이 테스트는 4-CPU 컴퓨터에서 수행되었습니다. 시스템의 CPU 수가 증가하면 차이가 커집니다.
 
2.2 응용 프로그램 배포 지침
최적의 성능을 얻으려면 응용 프로그램을 설계 할 때와 동일한 주의를 기울여 응용 프로그램을 배포하십시오.
 
2.2.1 테스트 환경에 배포하기위한 가이드 라인
테스트 프로세스는 주로 기능 및 안정성 테스트로 구성됩니다. 이 프로세스의 어느 시점에서 성능 테스트를 수행해야합니다. 
다음 목록은 응용 프로그램의 성능을 테스트하기위한 간단한 규칙을 설명합니다. 
제대로 문서화된 경우, 이 목록은 생산 응용 프로그램과 응용 프로그램이 라이브 간 후 용량 계획 프로세스에 대한 중요한 정보를 제공합니다.
• 디자인 검증을 위해 ADDM (Automatic Database Diagnostic Monitor) 및 SQL Tuning Advisor를 사용하십시오.
• 현실적인 데이터 볼륨 및 배포로 테스트하십시오.
모든 테스트는 완전히 채워진 테이블을 사용하여 수행해야합니다. 테스트 데이터베이스에는 데이터 볼륨 및 테이블 간의 
카디널리티 측면에서 프로덕션 시스템을 나타내는 데이터가 있어야합니다. 모든 프로덕션 인덱스를 빌드하고 스키마 통계를 올바르게 채워야 합니다.
• 올바른 최적화 모드를 사용하십시오.
프로덕션 환경에서 사용할 계획인 옵티마이저 모드로 모든 테스트를 수행하십시오.
• 단일 사용자 성능을 테스트합니다.
허용 가능한 성능을 위해 유휴 또는 가볍게 사용되는 데이터베이스에서 단일 사용자를 테스트하십시오. 
단일 사용자가 이상적인 조건에서 만족스러운 성능을 달성 할 수 없는 경우 실제 상황에서 여러 사용자가 만족할 만한 성능을 얻을 수 없습니다.
• 모든 SQL문의 계획을 수립하고 문서화하십시오.
각 SQL문에 대한 실행 계획을 얻습니다. 이 프로세스를 사용하여 최적화 프로그램이 최적의 실행 계획을 얻고 있는지, 
그리고 SQL문의 상대 비용이 CPU 시간 및 물리적 I/O의 관점에서 이해되는지 확인하십시오. 이 프로세스는 향후 
가장 많은 튜닝 및 성능 작업이 필요한 과도한 사용 트랜잭션을 식별하는 데 도움이 됩니다.
• 다중 사용자 테스트를 시도하십시오.
사용자 작업 부하 및 프로필이 완전히 계량되지 않을 수 있으므로 이 프로세스를 정확하게 수행하기는 어렵습니다. 
그러나 DML문을 수행하는 트랜잭션은 잠금 충돌이나 직렬화 문제가 발생하지 않는지 테스트해야 합니다.
• 올바른 하드웨어 구성으로 테스트하십시오.
가능한 한 프로덕션 시스템에 가까운 구성으로 테스트하십시오. 현실적인 시스템을 사용하는 것은 
네트워크 대기 시간, I/O 서브 시스템 대역폭 및 프로세서 유형 및 속도에 특히 중요합니다. 이 접근 방식을 사용하지 않으면 
잠재적인 성능 문제를 잘못 분석 할 수 있습니다.
• 정상 상태 성능을 측정합니다.
벤치마킹 할 때, 정상 상태 조건에서 성능을 측정하는 것이 중요합니다. 
각 벤치 마크 실행에는 사용자가 응용 프로그램에 연결되어 점진적으로 응용 프로그램에서 작업을 시작하는 램프 업 단계가 있어야합니다. 
이 프로세스를 통해 자주 캐시 된 데이터를 캐시로 초기화하고 파싱과 같은 단일 실행 작업을 정상 상태가 완료되기 전에 완료 할 수 있습니다. 
마찬가지로, 벤치 마크 실행 후 시스템이 자원을 비우고 사용자가 작업을 중단하고 연결을 끊을 때 감속 기간이 유용합니다.

2.2.2 응용 프로그램 롤 아웃 지침
새로운 애플리케이션이 출시되면 일반적으로 모든 사용자가 새로운 시스템으로 즉시 이전하는 Big Bang 방식과 사용자가 
기존 시스템에서 새로운 시스템으로 천천히 마이그레이션하는 방식 인 두 가지 전략이 일반적으로 채택됩니다. 
두 방법 모두 장점과 단점이 있습니다. Big Bang 접근법은 필요한 규모로 응용 프로그램을 안정적으로 테스트하는데 의존하지만 
간단히 스위치를 끄기 때문에 이전 시스템과의 데이터 변환 및 동기화가 최소화된다는 장점이 있습니다. Trickle 방식을 사용하면 
작업 부하가 증가함에 따라 확장성 문제를 디버깅 할 수 있지만 전환이 진행됨에 따라 데이터를 레거시 시스템 간에 마이그레이션해야 할 수도 있습니다. 
하나의 접근 방식을 다른 접근 방식보다 추천하는 것은 어렵습니다. 각 기술마다 전환이 발생할 때 시스템 중단을 초래할 수 있는 
위험이 관련되어 있기 때문입니다. Trickle 접근 방식은 실제 사용자가 새 응용 프로그램에 도입 될 때 프로파일링을 허용하고 
마이그레이션 된 사용자에게만 영향을 미치면서 시스템을 재구성 할 수 있게 합니다. 이 접근법은 얼리 어답터의 업무에 영향을 미치지만 
지원 서비스의 로드를 제한합니다. 따라서 예정되지 않은 중단은 사용자 인구 중 적은 비율에만 영향을 미칩니다. 
새로운 애플리케이션을 출시하는 방법에 대한 결정은 각 비즈니스에 따라 다릅니다. 채택된 접근 방식에는 고유한 압력과 스트레스가 있습니다. 
테스트 프로세스에서 파생된 테스트와 지식이 많을수록 롤 아웃에 가장 적합한 것이 무엇인지 깨닫게 됩니다.