이미 소장하고 있다면 판매해 보세요.
|
PART I 기초 1
CHAPTER 1 성능 문제 3 1.1 성능 계획의 필요성 4 1.2 성능을 고려한 설계 11 1.3 성능 문제 확인 방법 17 1.4 성능 문제 접근 방법 19 1.5 2장에 들어가기 전에 26 CHAPTER 2 핵심 개념 27 2.1 선택도와 카디널리티 27 2.2 커서란 무엇인가? 30 2.3 커서의 생명주기 31 2.4 파싱의 작동 원리 34 2.5 블록 읽기와 쓰기 54 2.6 계측 57 2.7 2부에 들어가기 전에 66 PART II 문제 식별 67 CHAPTER 3 재현 가능한 문제의 분석 71 3.1 데이터베이스 호출 트레이스 72 3.2 PL/SQL 코드 프로파일링 123 3.3 4장에 들어가기 전에 138 CHAPTER 4 재현 불가능한 문제의 실시간 분석 139 4.1 분석 로드맵 140 4.2 동적 성능 뷰 142 4.3 진단 팩과 튜닝 팩을 이용한 분석 175 4.4 진단 팩을 사용하지 않는 분석 188 4.5 5장에 들어가기 전에 197 CHAPTER 5 재현 불가능한 문제의 사후 분석 199 5.1 리포지터리 199 5.2 Automatic Workload Repository 201 5.3 Statspack 207 5.4 진단 팩을 이용한 분석 212 5.5 진단 팩을 이용하지 않는 분석 213 5.6 3부에 들어가기 전에 220 PART III 쿼리 옵티마이저 221 CHAPTER 6 쿼리 옵티마이저 223 6.1 기초 사항 224 6.2 아키텍처 228 6.3 쿼리 변환 229 6.4 7장에 들어가기 전에 254 CHAPTER 7 시스템 통계 255 7.1 dbms_stats 패키지 256 7.2 이용 가능한 시스템 통계에는 어떠한 것들이 있는가? 258 7.3 시스템 통계 수집하기 259 7.4 시스템 통계 복원하기 266 7.5 백업 테이블을 사용한 작업 268 7.6 관리 오퍼레이션의 로깅 269 7.7 쿼리 옵티마이저에 미치는 영향 271 7.8 8장에 들어가기 전에 277 CHAPTER 8 오브젝트 통계 279 8.1 dbms_stats 패키지 280 8.2 이용할 수 있는 오브젝트 통계에는 어떠한 것들이 있는가? 282 8.3 오브젝트 통계 수집하기 312 8.4 dbms_stats 패키지 설정하기 327 8.5 글로벌 임시 테이블로 작업하기 331 8.6 펜딩 오브젝트 통계로 작업하기 333 8.7 파티셔닝된 오브젝트로 작업하기 335 8.8 오브젝트 통계 수집 스케줄링하기 343 8.9 오브젝트 통계 복원하기 348 8.10 오브젝트 통계 잠그기 350 8.11 오브젝트 통계 비교하기 353 8.12 오브젝트 통계 삭제하기 356 8.13 오브젝트 통계 export, import, get, set 358 8.14 관리 작업의 로깅 358 8.15 오브젝트 통계를 최신으로 유지하기 위한 전략 360 8.16 9장에 들어가기 전에 362 CHAPTER 9 쿼리 옵티마이저 구성하기 365 9.1 쿼리 옵티마이저를 구성할 것인가, 말 것인가? 366 9.2 구성 로드맵 367 9.3 적절한 파라미터 설정하기 369 9.4 10장에 들어가기 전에 400 CHAPTER 10 실행 계획 401 10.1 실행 계획 얻기 401 10.2 dbms_xplan 패키지 417 10.3 실행 계획 해석하기 434 10.4 비효율적인 실행 계획 식별하기 470 10.5 4부에 들어가기 전에 475 PART IV 최적화 477 CHAPTER 11 SQL 최적화 기법 479 11.1 액세스 구조 변경하기 481 11.2 SQL 구문 변경하기 483 11.3 힌트 485 11.4 실행 환경 변경하기 498 11.5 스토어드 아웃라인 502 11.6 SQL 프로파일 518 11.7 SQL 플랜 매니지먼트 539 11.8 12장에 들어가기 전에 560 CHAPTER 12 파싱 563 12.1 파싱 문제 식별 563 12.2 파싱 문제 해결하기 575 12.3 파싱 문제 해결을 위한 차선책 583 12.4 애플리케이션 프로그래밍 인터페이스 사용하기 590 12.5 13장에 들어가기 전에 603 CHAPTER 13 데이터 액세스 최적화 605 13.1 비효율적인 액세스 패스 식별 606 13.2 약한 선택도를 가진 SQL 구문 618 13.3 강한 선택도를 가진 SQL 구문 648 13.4 14장에 들어가기 전에 707 CHAPTER 14 조인 최적화 709 14.1 용어 정의 710 14.2 네스티드 루프 조인 720 14.3 머지 조인 727 14.4 해시 조인 741 14.5 아우터 조인 747 14.6 조인 방법 선택 749 14.7 파티션 와이즈 조인 751 14.8 스타 변환 756 14.9 15장에 들어가기 전에 765 CHAPTER 15 데이터 액세스와 조인 최적화를 넘어서 767 15.1 머티리얼라이즈드 뷰 768 15.2 결과 캐싱 796 15.3 병렬 처리 808 15.4 direct-path insert 855 15.5 로우 프리페칭 860 15.6 배열 처리 인터페이스 867 15.7 16장에 들어가기 전에 872 CHAPTER 16 물리 설계 최적화 873 16.1 최적의 칼럼 순서 874 16.2 최적의 데이터타입 876 16.3 로우 마이그레이션과 로우 체이닝 884 16.4 블록 경합 889 16.5 데이터 압축 900 찾아보기 907 |
|
간단히 말해서, 애플리케이션의 목적은 애플리케이션을 이용함으로써 비즈니스에 이익을 가져다 주는 것이다. 결과적으로 애플리케이션 성능을 최적화하는 이유는 이익을 극대화하기 위함이다. 무조건 애플리케이션 성능을 극대화하자는 것이 아니며, 비용과 성능 사이에서 최적의 균형점을 찾자는 것이다. 실제로 성능 최적화 작업에 소요된 노력은 이를 통해 얻을 수 있는 이익으로 보상받을 수 있어야 한다. 이는 비즈니스 관점에서 봤을 때 성능 최적화 작업이 항상 유의미한 것은 아니라는 사실을 의미한다. _19쪽
통계 수집 후 비효율적인 실행 계획이 나타난다면 다음의 두 가지 사항을 시도해볼 수 있다. 첫 번째는 통계를 수집하기 전에 이상 없이 잘 사용하던 오브젝트 통계로 복원하여 문제를 해결하는 것이다. 두 번째는 새로 수집된 오브젝트 통계를 사용하는 쿼리 옵티마이저가 비효율적인 실행 계획을 생성하게 된 원인을 찾아보는 것이다. 이를 위해 우선 새로 생성된 통계가 데이터를 올바르게 설명하는지를 조사해야 한다. 예를 들어, 분포가 바뀐 데이터에 대해 샘플링으로 통계를 수집한다면 다른 히스토그램이 만들어질 수 있다. 오브젝트 통계가 좋지 않다면, 통계 수집 자체에 문제가 있거나 통계를 수집하는 데 사용된 파라미터가 문제일 것이다. 그러나 오브젝트 통계에 아무런 문제가 없다면, 두 가지 추가 가능성이 있다. 즉, 쿼리 옵티마이저가 제대로 구성되어 있지 않거나 쿼리 옵티마이저가 오판한 것이다. 후자에 대해서는 제어할 수 있는 것이 거의 없지만, 전자에 대해서는 해결책을 찾을 수 있다. _362쪽 실행 계획(execution plan)은 SQL 구문을 실행하기 위해 데이터베이스 엔진에서 어떠한 오퍼레이션을 수행하는지 알려준다. SQL 구문과 관련된 성능 문제를 분석하거나 쿼리 옵티마이저가 내린 결정에 의문이 들 때마다 실행 계획을 살펴봐야 한다. 실행 계획이 없다면 사하라 사막 한가운데에서 지팡이를 짚고 길을 더듬거리며 찾는 장님과 다를 바 없을 것이다. SQL 구문의 성능을 분석하거나 궁금할 때 가장 먼저 해당 구문의 실행 계획을 살펴봐야 한다는 사실은 아무리 강조해도 지나치지 않다. _401쪽 여기서 핵심은 완전히 동일한 데이터를 다른 SQL 구문을 사용하여 추출할 수도 있다는 사실을 깨닫는 것이다. 따라서 SQL 구문을 최적화할 때마다 동일한 역할을 수행하는 다른 SQL 구문이 없는지 자문해봐야 한다. 만약 동일한 역할을 수행하는 다른 SQL 구문이 존재한다면, 어떤 SQL이 가장 좋은 성능을 제공하는지 평가하기 위해 SQL 구문의 실행 계획을 주의 깊게 비교해야 한다. _485쪽 여기서 딜레마는 파싱 문제를 개선하기 위해서는 테스트 케이스 1과 같은 코드를 수정할 필요가 있는데, 불행히도 코드 수정이 항상 가능한 것은 아니다. 이는 소스 코드가 없거나 코드 개선을 막는 기술적 장벽 때문이거나(예를 들어, 프로그래밍 환경에서 prepared 구문을 지원하지 않는 경우), 모든 코드를 수정하는 데 너무 많은 비용이 들기 때문일 수 있다. 다음 절에서는 올바른 방법을 적용했을 때와 비슷한 결과를 얻기 위해 이러한 문제를 우회할 수 있는 차선책을 설명할 것이다. 차선책을 적용했을 때의 성능이 올바른 방법을 사용했을 때만큼 좋지는 않더라도 어떤 상황에서는 아무것도 하지 않는 것보다는 훨씬 낫다. ---P.583 |