SQL Server 성능 개선 방법론 장윤석 과장 기술사업부 ㈜한국마이크로소프트 [제목과 문서속성 값을 입력해 주세요.

Presentation on theme: "SQL Server 성능 개선 방법론 장윤석 과장 기술사업부 ㈜한국마이크로소프트 [제목과 문서속성 값을 입력해 주세요."— Presentation transcript:

1

2 SQL Server 성능 개선 방법론 장윤석 과장 기술사업부 ㈜한국마이크로소프트 [제목과 문서속성 값을 입력해 주세요.
문서속성 값은 파일 메뉴>속성에서 입력해 주시면 됩니다.] [하단의 슬라이드 노트 내용 입력란에 슬라이드별 스크립트를 삽입해 주시기 바랍니다.] 장윤석 과장 기술사업부 ㈜한국마이크로소프트

3 강사 소개 현) 마이크로소프트 SQL Server Technology Specialist
Exchange Technology Specialist Workflow Engine개발 Exchange 5.5 Server Exchange 2000 Server SQL Server TechEd, DevCon, TechNet, MSDN 세션 다수 발표 [강사 소개 부분은 필수 사항은 아니나 되도록이면 사진, 경력 등을 기입해 주시기 바랍니다.]

4 목차 성능 방법론 성능에 영향을 미치는 요소 성능 튜닝 방법론 기타 정보 소스 결론 대기와 큐 원인
애플리케이션 라이프 사이클 – 개발 전반 성능 튜닝 방법론 대기와 큐 성능 툴 관련 대기와 큐 기타 정보 소스 문서화되지 않은 기능 결론

5 ? 성능 – 대기와 큐 성능은 광범위한 주제 대기와 큐 방법론 예술인가 과학인가? SQL 고객의 경험에 근거
애플리케이션을 3~4일 동안 분석 반복적인 과정 병목을 신속하게 확인하는데 유용 성능, 아키텍처, 코드 ?

6 성능 라이프 사이클 성능 모니터링은 애플리케이션 라이프 사이클의 전반에 걸쳐 중요한 역할을 수행한다 (운영 직전의 마지막 단계에서만이 아니라) 다음을 포함하여 애플리케이션에 있는 문제점들을 감지하는 단서를 제공한다 SQL 애플리케이션 아키텍처 데이터베이스 디자인 Configuration 하드웨어

7 성능 모니터링으로 가능한 일 전형적인 병목 형태 애플리케이션에 있어서 전형적으로 문제가 발생하는 영역은? 캐시 관리
쿼리 실행계획 재사용 재컴파일 트랜잭션 관리 리소스 사용

8 대기와 큐 상호 보완관계에 있는 정보 큐 SQL 대기 애플리케이션의 성능 확인을 위해서는 두 가지 정보를 함께 분석해야 한다
대부분 큐에는 익숙하다 (절반의 성공) 문제를 확인하는데 있어서 두 가지 정보가 필수적이다 큐 성능 모니터 카운터 정보 – 리소스 사용의 척도 큐는 충족되지 않은 리소스 요청을 나타낸다 SQL 대기 애플리케이션 또는 사용자 연결(User connection) 입장에서의 대기

9 대기 SQL 대기 애플리케이션은 SQL 쿼리 문들을 전송한다 그러면 SQL 서버는 리소스 요청을 발생시킨다
서브시스템 IO, 메모리, CPU로 변환 예를 들어, 잠금 획득, 데이터 페이지 읽기 | 쓰기, 정렬 SQL2000의 경우에 50가지가 넘는 대기 유형이 존재한다 사용자 연결이 결과를 얻기 위하여 대기할 때마다, SQL 서버가 대기 유형 정보를 설정한다

10 큐 성능 모니터의 성능 카운터는 리소스 입장에서의 시스템 성능 관점을 제공한다 큐는 리소스 사용의 척도가 된다
성능 모니터의 성능 카운터는 리소스 입장에서의 시스템 성능 관점을 제공한다 큐는 리소스 사용의 척도가 된다 요청에 대하여 즉각적으로 제공할 수 없으면 큐에 저장된다 주요 성능 카운터 (일부) Physical Disk (IO) SQL Buffer Cache SQL Statistics Buffer Cache Hit Ratio 디스크에서 읽지 않고 버퍼 캐시에서 찾은 페이지 비율입니다. 이 비율은 SQL Server 인스턴스를 시작한 이후의 총 캐시 조회 수로 나눈 총 캐시 적중 수입니다. 시간이 많이 지나면 이 비율은 일정해집니다. 캐시에서 읽는 것이 디스크에서 읽는 것보다 비용이 적게 들기 때문에 이 비율을 높이는 것이 좋습니다. 일반적으로 SQL Server에 사용할 수 있는 메모리 양을 늘리면 buffer cache hit ratio을 높일 수 있습니다. SQL Statistics 개체 SQL Server 인스턴스로 보낸 컴파일과 요청 유형을 모니터링하는 카운터를 제공합니다. 쿼리 컴파일 및 다시 컴파일 수와 SQL Server 인스턴스에서 받은 일괄 처리 수를 모니터링하면 SQL Server가 사용자 쿼리를 처리하는 속도와 쿼리 최적화 프로그램이 쿼리를 처리하는 효율을 알 수 있습니다. 컴파일은 쿼리 반환 시간의 중요한 부분입니다. 캐시의 목적은 컴파일된 쿼리를 나중에 다시 사용할 수 있도록 저장해 컴파일을 줄여서 쿼리를 다음에 실행할 때 다시 컴파일할 필요가 없도록 하는 것입니다. 하지만 각각의 고유 쿼리는 최소 한 번은 컴파일해야 합니다. 다음 요인이 발생하면 쿼리를 다시 컴파일해야 합니다.

11 대기 유형 어떤 스레드가 현재 실행 중이 아니면, sysprocesses에 대기 유형 또는 상태 값이 저장된다
Lastwaittype Waitype Waittime 제약사항: 일시적인 sysprocesses 정보, spid 이력 Spid의 숫자 70은?

12 대기 유형 DBCC sqlperf(waitstats,[clear]) Waittype과 waittime의 누적 데이터

13 데모 대기유형 [작업 1] : Wait Type [작업 2] : Blocking SQL
[90분 강의는 3~4개의 데모가, 60분 강의는 1~2개의 데모가 반드시 포함되어야 합니다.] [데모 주제 아래의 [작업 1][작업 2]는 데모의 흐름, Task 목록 등을 기입해 주시면 됩니다.] [데모별로 상기의 슬라이드가 데모 전에 나와야 합니다.]

14 SQL Server Scheduler – 어떻게 동작하는가!
UMS UMS UMS UMS 4 way CPU UMS로 각 Connection은 할당된다. UMS는 여러 프로세서를 거쳐 스케줄한다. 하나의 연결은 스레드가 살아있는동안 UMS에 머문다. 2개의 무거운 스레드는 동일한 UMS에 대하여 경쟁한다.

15 Basics of execution model(simplified)
spid is running then needs unavailable resource, moves to resource wait list at time T0 a signal indicates resource available, spid moves to runnable queue at time T1 spid awaits running status until T2 as cpu works its way through runnable queue in order of arrival Need a resource RUNNING! Switched Yield Timer Request Runnable List No new request Timer List Expired/signaled New request Res available WorkerPool Created Resource Waiter List 15 min idle Dead

16 대기 시간 Requests Resource wait time (T1 – T0) Signal Wait Time (T2 – T1)
Number of times the wait state was entered Resource wait time (T1 – T0) Total Wait Time – Signal Wait Time Signal Wait Time (T2 – T1) Time in runnable queue prior to execution Total Wait Time (T2 – T0) Total time waiting on resource plus the time the worker thread gets scheduled so it can use the resource When Signal wait begins (at T1), resource wait is over, and spid is placed in runnable queue. Signal wait time includes the time it takes to move up the runnable queue to a running status. After the signal occurs at T1, you are waiting to get scheduled back in running status. Spid is running at T2. T0 = Request resource, enter wait state T1 = Signal Resource Availability T2 = Use resource, reset wait state Time Signal Wait Time Wait Time

17 Track_waitstats 저장 프로시저
DBCC SQLPERF를 수행하여 SQL waitstats 정보를 수집한다 전체 대기에서 차지하는 비율을 기준으로 내림차순으로 대기 유형별 순위를 매긴다 성능 향상을 위한 가장 큰 기회를 확인한다 그래프화하면 작업부하에 따라 대기가 어떻게 변화하는지를 볼 수 있다 제약사항: 기간이 길어지면 대기가 감지되지 않거나 실제보다 완화되어 나타날 수 있다

18 Track_waitstats 코드 CREATE proc track_waitstats nvarchar(10)='minutes') as -- T. Davidson -- This stored procedure is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at is the number of times to capture waitstats, default is 10 times. default delay interval is 1 minute -- delaynum is the delay interval. delaytype specifies whether the delay interval is minutes or seconds -- create waitstats table if it doesn't exist, otherwise truncate set nocount on if not exists (select 1 from sysobjects where name = 'waitstats') create table waitstats ([wait type] varchar(80), requests numeric(20,1), [wait time] numeric (20,1), [signal wait time] numeric(20,1), now datetime default getdate()) else truncate table waitstats dbcc sqlperf (waitstats,clear) -- clear out waitstats numeric(20,1) datetime int = 1 = case when 'minutes' then 'm' when 'minute' then 'm' when 'min' then 'm' when 'mm' then 'm' when 'mi' then 'm' when 'm' then 'm' when 'seconds' then 's' when 'second' then 's' when 'sec' then 's' when 'ss' then 's' when 's' then 's' end not in ('s','m') begin print 'please supply delay type e.g. seconds or minutes' return

19 Track_waitstats 코드 if @dt = 's' begin select @sec = @delaynum % 60
= / 60) as int) = / 60) as int) % 60 end = 'm' = 0 % 60 = / 60) as int) right('0'+ + ':' + + + ':' + + > 23 > 59 > 59 select 'hh:mm:ss delay time cannot > 23:59:59' select 'delay interval and type: ' + convert + ',' + ' converts to ' return while insert into waitstats ([wait type], requests, [wait time],[signal wait time]) exec ('dbcc sqlperf(waitstats)') + 1 waitfor End --- create waitstats report execute get_waitstats

20 Get_waitstats 코드 CREATE proc get_waitstats as
-- This stored procedure is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at -- -- this proc will create waitstats report listing wait types by percentage -- can be run when track_waitstats is executing set nocount on numeric(20,1) datetime int select from waitstats where [wait type] = 'Total' --- subtract waitfor, sleep, and resource_queue from Total = sum([wait time]) + 1 from waitstats where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE', 'Total', '***total***') and now -- insert adjusted totals, rank by percentage descending delete waitstats where [wait type] = '***total***' and now insert into waitstats select select [wait type],[wait time],percentage=cast (100*[wait as numeric(20,1)) from waitstats where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE','Total') and now order by percentage desc

21 Track_waitstats 결과 예제

22 데모 대기유형 추적 [작업 1] : Get Waitstats [작업 2] : Track waitstats
[90분 강의는 3~4개의 데모가, 60분 강의는 1~2개의 데모가 반드시 포함되어야 합니다.] [데모 주제 아래의 [작업 1][작업 2]는 데모의 흐름, Task 목록 등을 기입해 주시면 됩니다.] [데모별로 상기의 슬라이드가 데모 전에 나와야 합니다.]

23 Track_waitstats 결과 예제 연결된 서버

24 Get_waitstats2 (version 2)
전체 대기의 퍼센트 기준으로 내림차순으로 대기유형을 보여줌 성능개선의 여지가 가장 큰 영역을 찾는다. Resource와 Signal Waits를 분리 가장 리소스 대기가 많은 곳이 리소스 병목이 있는 곳이다. 높은 Signal Waits은 프로세스의 Runnable Queue를 진행하기 위한 CPU의 낮은 속도를 표시한다. Corroborate with %user time Dbcc sqlperf(umsstats) CREATE proc get_waitstats varchar(20)='all') As -- version 2 -- This stored procedure is provided "AS IS" with no warranties, and confers no rights. -- Use of included script samples are subject to the terms specified at -- -- this proc will create waitstats report listing wait types by percentage. -- (1) total wait time is the sum of resource & signal reports resource & signal -- (2) Basics of execution model (simplified) a. spid is running then needs unavailable resource, moves to resource wait list at time T0 b. a signal indicates resource available, spid moves to runnable queue at time T1 c. spid awaits running status until T2 as cpu works its way through runnable queue in order of arrival -- (3) resource wait time is the actual time waiting for the resource to be available, T1-T0 -- (4) signal wait time is the time it takes from the point the resource is available (T1) to the point in which the process is running again at T2. Thus, signal waits are T2-T1 -- (5) Key questions: Are Resource and Signal time significant? a. Highest waits indicate the bottleneck you need to solve for scalability b. Generally if you have LOW% SIGNAL WAITS, the CPU is handling the workload e.g. spids spend move through runnable queue quickly c. HIGH % SIGNAL WAITS indicates CPU can't keep up, significant time for spids to move up the runnable queue to reach running status -- (6) This proc can be run when track_waitstats is executing set nocount on numeric(20,1) datetime int select from waitstats where [wait type] = 'Total' --- subtract waitfor, sleep, and resource_queue from Total = sum([wait time]) + = sum([signal wait time]) + 1 from waitstats where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE', 'Total', '***total***') and now -- insert adjusted totals, rank by percentage descending delete waitstats where [wait type] = '***total***' and now insert into waitstats select select 'start = 'all' select [wait type],[requests] ,'Total wt (T2-T0)'=[wait time], 'wt_%'=cast (100*[wait as numeric(20,1)) ,'Resource wt (T1-T0)'=[wait time]-[signal wait time] ,'res_wt_%'=cast (100*([wait time] - [signal wait time]) as numeric(20,1)) ,'Signal wt (T2-T1)'=[signal wait time] ,'sig_wt_%'=cast (100*[signal wait as numeric(20,1)) from waitstats where [wait type] not in ('WAITFOR','SLEEP','RESOURCE_QUEUE','Total') and now order by 'wt_%' desc else select [wait type],[wait time],percentage=cast (100*[wait as numeric(20,1)) order by percentage desc

25 Get_waitstats2: verbose

26 데모 대기유형 추적(2) [작업 1] : Get Waitstats2 [작업 2] : Track waitstats
[90분 강의는 3~4개의 데모가, 60분 강의는 1~2개의 데모가 반드시 포함되어야 합니다.] [데모 주제 아래의 [작업 1][작업 2]는 데모의 흐름, Task 목록 등을 기입해 주시면 됩니다.] [데모별로 상기의 슬라이드가 데모 전에 나와야 합니다.]

27 상관관계에 있는 대기와 큐 대기는 큐와 서로 관련되어 있다 상황이 좋을 때의 성능을 확인해 두면 유용하다
증상만으로 판단해서는 안 된다 증상에만 치중하면 근본적인 문제를 보지 못할 수 있다 특정 리소스 제약을 관련 대기 유형들과 함께 확인한다 실제 문제는 리소스 제약 보다는 애플리케이션, SQL, DB 디자인일 가능성이 높다 상황이 좋을 때의 성능을 확인해 두면 유용하다 성능이 저하되면 – 무엇이 변경되었는가?

28 관련 대기와 큐 IO 이슈인가 아니면 메모리 이슈인가?
설명 IO_Completion Async_IO_Completion PageIOLatch_x PageLatch_x 1. SQL Buffer Mgr Avg Page Life Expectancy (초 단위) Checkpoint pages/sec Lazywrites/sec 2. Physical Disk Avg disk sec/read Avg disk sec/write Disk queues 이런 대기가 발생하면 IO 이슈가 있음을 나타낸다 Avg. disk 초가 높으면 IO 이슈가 있음을 나타낸다 그렇지만 Avg page life 수치가 낮으면 메모리 압박이 있음을 나타낸다 예, 캐시 플러싱

29 관련 대기와 큐 IO 이슈인가 아니면 DB 디자인 이슈인가?
설명 1. IO_Completion 2. Async_IO_Completion 3. Writelog 1. SQL Buffer Mgr Avg Page Life Expectancy (초 단위) Checkpoint pages/sec Lazywrites/sec 2. Physical Disk Avg disk sec/read Avg disk sec/write Disk queues 1. 프로필러에 다음이 발생하면: Scan started Reads Writes 2. 실행계획에 다음이 나타나면: Table Scan Clustered index range scans Nonclustered index range scans 정렬(sorts)

30 SQL 2000 Waits & Queues * SQL Server Magazine Jan 2004

31 가상 시스템 테이블 ::Fn_virtualfilestats (dbid, [fileId | -1]) Syscacheobjects
파일별 IO 정보를 제공한다 IostallMS 값을 점검해야 한다 Physical Disk reads/writes 수치와 비교한다 Syscacheobjects 쿼리 실행계획 정보와 같은 컴파일된 오브젝트를 반환한다 Sysprocesses SQL 스레드와 대기 유형 정보를 반환한다 Syslocks

32 데모 가상 시스템 테이블 [작업 1] : fn_virtualfilestats (dbid, [fileid])
[작업 2] : InputBuffer [90분 강의는 3~4개의 데모가, 60분 강의는 1~2개의 데모가 반드시 포함되어야 합니다.] [데모 주제 아래의 [작업 1][작업 2]는 데모의 흐름, Task 목록 등을 기입해 주시면 됩니다.] [데모별로 상기의 슬라이드가 데모 전에 나와야 합니다.]

33 동시성/CPU 이슈 캐싱된 오브젝트 Master..Syscacheobjects 다음의 실행계획 재사용
프로시저나 배치(batch) 이름 실행 계획에 대한 Set 옵션 Ref counts, Use counts 컴파일된 계획 (Compiled Plan) 단일 본 (순차 및 병렬) 재진입 및 재사용 가능 재컴파일이 발생하면 컴파일된 실행계획에 **잠금** 을 건다 실행가능한 계획( Executable plan) 사용자 컨텍스트를 위한 데이터 구조(structure), 재진입 불가 실행계획 재사용 점검: usecounts > 1 다음의 실행계획 재사용 저장 프로시저, 트리거, 뷰 디폴트, Check 제약조건, 규칙(rule) 임의 SQL, sp_executesql

34 저장 프로시저 Syscacheobjects를 조회하면 쿼리 실행계획을 확인할 수 있다 Sp_procinfo
Execution plan (N) 사용자 컨텍스트, 변수 값 등 Compiled plan (1) 액세스 전략 – 순차적 또는 병렬 컴파일된 실행계획 한 본 Sp_procinfo 저장 프로시저 정보를 반환해 준다 매개변수 실행계획 재사용 (usecounts) 자동시작 소유자

35 Syscacheobjects와 실행계획 재사용

36 실행계획 재사용 SQL Batch requests/sec SQL Compilations/sec
초기 컴파일 및 재컴파일 포함 재컴파일 제거 syscacheobjects의 usecounts값이 낮은 SQL 문 확인 SQL Re-compilations/sec 재컴파일만 발생하는 경우 SQL 문을 확인하려면 프로필러에서 sp:recompile 이벤트 점검

37 실행계획 재사용 프로필러 정보 Syscacheobjects의 실행계획 재사용 정보
SP:ExecContextHit 이벤트 – 실행계획이 캐시에 존재하는 경우 SP:Cache Miss 이벤트 – 실행계획이 캐시에 없는 경우 SP:Cache Insert – 실행계획이 캐시에 없어서, 실행계획을 생성하여 syscacheobjects에 insert하는 경우 Syscacheobjects의 실행계획 재사용 정보 Usecounts > 1

38 프로필러 이벤트 실행계획 재사용 (또는 재사용 미비) IO 재컴파일
Batch requests를 SQL compiles/sec와 비교 IO Reads 값과 writes 값 재컴파일 Cache hit, Cache insert, Cache miss, Cache remove 인덱스 사용 (또는 인덱스 사용 미비) 오브젝트 액세스

39 동시성/CPU: 재컴파일 실행계획 생성은 CPU를 많이 사용하는 작업 프로필러 시스템 테이블에 대한 잠금
Recompile 이벤트와 관련 SQL 문 확인 가능 재컴파일이 발생한 원인을 보여 주는 데이터 열: EventSubClass 시스템 테이블에 대한 잠금 저장 프로시저 실행계획을 재컴파일하면 동시성이 높은 시점에는 다른 사용자들을 기다리게 한다 컴파일된 계획에 잠금을 건다 재컴파일은 다음에 따라 발생된다 변경된 행의 수에 대한 임계값 (rowmodctr) DDL문의 위치, 스키마 변경 코딩 습관 및 임시 테이블의 사용

40 EventSubClass 재컴파일 발생 원인
1 컴파일 또는 실행 사이에 스키마, 바인딩 또는 권한이 변경된 경우 2 통계(Statistics)가 변경된 경우 3 컴파일 시점에 오브젝트가 존재하지 않은 경우, 오브젝트 존재 여부 점검을 실행 시점으로 지연시킨 경우 4 일괄 처리 내에서 SET 옵션이 변경된 경우 5 임시 테이블 스키마, 바인딩 또는 권한이 변경된 경우 6 원격 행 집합(rowset) 스키마, 바인딩 또는 권한이 변경된 경우

41 Eventsubclass=2 Stats changed
Table Type Empty Condition Threshold when empty Threshold when not empty Permanent < 500 Rows # of Changes >= 500 # of Changes >= (20% of Cardinality) Temporary < 6 Rows # of Changes >= 6 Table Variable No thresholds 통계 업데이트로 인한 재컴파일을 피하고 싶을 때 Add OPTION(KEEPFIXED PLAN) Use table variables (no stats maintained, scoping issue) Segregate re-comp statement & do a nested call

42 실행계획의 예상 수치 이슈 Set Statistics Profile on 예상 값과 실제 값의 비교 비용 과다평가
고정 비용(해시) 전략을 선호 극단적인 경우에는 LOOP JOIN 힌트를 추가함으로써 성능을 향상시킬 수 있다 비용 과소평가 변동 비용 (예, 중첩 루프) 전략을 선호 극단적인 경우에는 HASH 옵션을 사용하여 성능을 향상시킬 수 있다

43 CPU 리소스의 사용 정렬 Distinct, order by, group by
인덱스로 얻을 수 있는 이득과 인덱스로 인한 오버헤드를 비교 조인 Worktable, 임시 테이블 실행계획에서 조인 유형을 확인 실행계획 재사용 미비 SQL 컴파일 – SQL 재컴파일 Batch Requests값과 syscacheobjects usecounts 값을 비교 Parameterization 점검 재컴파일 SQL Recompiles/sec Batch Requests 수치와 비교 IO 관리 프로필러 스캔, 메모리 압박, DB 디자인 인덱스 활용 점검 Page Life 수치가 충분히 높은지 확인

44 메모리 추가가 도움이 되는 경우 다음과 같은 경우에는 메모리를 추가하는 것이 도움이 된다
SQL Buffer Mgr:Page Life Expectancy 수치가 낮은 경우 페이지가 캐시에 머무르는 평균 시간 (초 단위) SQL Server Memory Mgr: Memory Grants Pending 수치가 높은 경우 쿼리를 수행하는데 충분한 메모리가 확보되지 않으면 SQL Server가 쿼리를 실행하지 않는다 메모리 추가 후에, Page Life Expectancy 수치가 높아지면, 메모리를 추가한 것이 성능에 도움이 되었다고 볼 수 있다

45 dbcc sqlperf(umsstats)
Item Definition num users Number of SQL threads on the scheduler num runnable Number of SQL threads that are “runnable” (Scheduler queue length) num workers Number of actual workers to process threads (thread pool) idle workers Number of idle workers cntxt switches Context switches between runnable threads cntxt switches(idle) Context switches to the “idle” thread

46 IO 리소스의 사용 스캔 캐시의 내용을 비움으로써 메모리 압박을 유발할 수 있다 페이지 분할
Page life 점검 요망. 데이터 드라이브 블록 크기=64K (대량 IO 유발 애플리케이션의 경우) Physical disk:split IO/sec 페이지 분할 SQL Access Methods: Page splits/sec 인덱스 정의에 근거하여 정해진 위치에 저장되어야 하는데 새로운 행이 해당 페이지에 저장될 수 없는 경우 Forwarded record SQL Access Methods: Forwarded records/sec 업데이트 후의 레코드 크기가 더 커져서 원래의 페이지에 저장될 수 없는 경우 인덱스 유지 Inserts, updates, deletes 읽기와 균형을 이루어야 함

47 IO 이슈 트랜잭션 로그 – RAID10으로 구성하는 것이 일반적
트랜잭션 로그에 대해서는 컨트롤러나 IO 서브시스템 캐시를 100% write용으로 설정 (복제나 트리거의 빈번한 수행으로 인하여 로그에 대하여 읽기 작업이 수행되지 않는다면) 목표 : 1-2ms/write (Avg. Disk sec/write) 데이터베이스를 적용하기 전에 SAN 처리량을 테스트할 것 IOMETER(shareware)를 사용하거나 크기가 큰 파일들을 복사 채널당 120mb/sec 이하의 처리량이 나와야 함 업데이트가 많이 발생하는 시스템의 경우에는 더 많은 캐시를 읽기보다 쓰기용으로 배치한다 데이터가 가능한 한 많은 수의 드라이브들에 분산되어 있는지 확인; 디스크가 여전히 데이터베이스 활동에 있어서 가장 느린 구성요소 RAID5 – 쓰기가 많이 발생하는 애플리케이션의 경우에는 쓰기 작업으로 인한 성능 저하 유발

48 디자인 이슈 대기와 큐 방법론으로부터 얻어지는 디자인 고려사항들이 있다 관찰 대상 애플리케이션 이슈 가능한 처방
높은 IO 대기 데이터베이스 디자인 메모리 압박 부적절한 인덱스로 인한 비효율적인 쿼리 실행계획  적절한 인덱스를 추가하여 IO를 최소화 메모리 추가 높은 CPU 사용률 실행계획 재사용 재컴파일 Parameterization 실행계획 재사용, parameterization, 재컴파일이 적절하게 이루어지고 있는지 점검, 다음 자료 참조 요망 잦은 블로킹 / 낮은 동시성( concurrency) 트랜잭션 관리 Redo 트랜잭션 관리 적절한 격리 수준(isolation level) 사용

49 요약 애플리케이션 성능은 대기와 큐에 관한 모든 것
작업부하는 변할 수 있으며 그에 따라 대기와 큐도 변화한다 시스템 성능은 병목을 찾아서 해결하고 시스템의 용량을 극대화하는 것에 관한 모든 것

50 결론 SQL Server 2000은 고성능의 엔터프라이즈급 데이터베이스이다
성능 모니터링은 애플리케이션 라이프 사이클 전반에 걸쳐 사용되어야 하는 툴이다 다음에 있어서의 병목들을 찾아낸다 애플리케이션 데이터베이스 리소스 사용 모든 리소스들에 대하여 점검해야 한다 CPU I/O 네트워크 데이터 (동시성과 일관성)

51 참고 자료 Kalen Delaney 저 “Inside SQL Server 2000”
Whalen, Garcia, DeLuca, Thompson 저 “SQL Server 2000 Performance Tuning” “SQL Server 2000 Recompilation”

52 ©2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

53