SQL Server 진단을 위한 주요 성능카운터

성능베이스라인을 만들기 위해 최모군이 SSIS를 이용해서 자동화를 시키고 있는 중입니다. 해당 SSIS를 이용하여 자동화시키는 강좌는 SQLLEADER.COM에 가면 잘 정리되어 있습니다. 많은 시행착오를 거쳐 SSIS는 거의 완성단계에 왔고, 이제 어떤 성능카운터를 넣을지만 결정하면 되는 이 시점에서 SQL Server 성능 진단을 위해서는 어떤 성능 카운터를 수집을 해야 하는지에 대해서 정리를 해볼까 합니다.

Processor\%Processor Time : % Processor Time

이 성능카운터는 프로세서가 비유휴 스레드를 실행하는데 소비하는 시간의 백분율입니다. 이것은 프로세서가 각 샘플 간격 동안 유휴 스레드를 실행하는데 소비한 시간을 측정하여 간격 기간에서 그 값을 뺀 것입니다. 각 프로세서에는 유휴 스레디가 있는데 이것은 다른 어떤 스레드도 실행되지 않을 때 사이클을 소비하는 스레드입니다. 이 카운터는 프로세서 동작의 주요 표시기이며 샘플 간격 동안 관찰되는 사용 시간의 평균 백분율을 표시합니다. 이것은 서비스가 비활성인 시간을 모니터링하여 100%에서 그 값을 뺀 것입니다. 즉, 쉽게 말해서, 1시간동안 CPU상태를 관찰하였고, 1시간중에 30분간 CPU가 일을 하였다면, %Processor Time은 50% 입니다. 일반적으로 %Processor Time가 80%이상 사용되고 있으면, 관심을 가지고 사용량의 변화를 모니터링 하셔야 합니다.

Processor\%Privileged Time : % Privildged Time

이 성능카운터는 프로세스 스레드가 특권 모드에서 명령을 실행하면서 경과된 시간을 백분율로 표시한 것 입니다. Windows 시스템 서비스가 호출되면, 서비스는 시스템 전용 데이터를 액세스하기 위해 흔히 특권 모드에서 실행됩니다. 그러한 데이터는 사용자 모드에서 실행되는 스레드가 액세스하지 못하도록 보호됩니다. 시스템 호출은 페이지 오류 또는 인터럽트가 발생할 때처럼 명시적이거나 암시적입니다. 일부 초기 운영 체제와는 달리 Windows는 사용자 및 특권모드의 일반적인 보호뿐만 아니라 하위 시스템을 보호하기 위해 프로세스 경계를 사용합니다. 응용 프로그램을 대신하여 Windows에서 수행한 일부 작업은 프로세스의 특권 시간 및 다른 하위 시스템 프로세스에서도 나타납니다. 쉽게 말해서, 운영체제가 사용한 시간의 백분율 값 입니다.

Memory\Available Bytes : Available Bytes

이 성능카운터는 컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리의 양(byte)입니다. 이것은 0으로 채워 있거나 비어 있거나 대기 중인 메모리 목록에 있는 공간을 합해 계산합니다. 빈 메모리는 사용할 준비가 된 메모리이고, 0으로 채워진 메모리는 다음 프로세스가 이전 프로세스에서 사용된 데이터를 보지 못하도록 0으로 채운 메모리 페이지로 구성되며, 대기 메모리는 프로세스의 작업 집합(실제 메모리)에서 제거되어 디스크로 라우트되었지만 다시 호출되어 사용될 수 있는 메모리를 말합니다. 이 카운터는 최근에 관찰된 값만 표시하며 평균값은 아닙니다. 사용 가능한 여유 메모리는 많이 있으면 좋겠지만, 그렇지 않다면, 최소한 5Mbyte이상은 남아 있어야 합니다.

Memory\Page Faults/sec : Page Faults/sec

이 성능카운터는 프로세스가 사용하는 메모리 공간(Working set)에 존재하는 않는 코드나, 데이터를 요청할 경우에 발생합니다. 이 때 요청된 코드나 데이터를 다른 메모리 공간에서 찾으면 Soft Page Fault라고 하면, 디스크에서 찾게되면 Hard Page Fault라고 합니다. Page Faults/sec은 초당 발생한 Soft Page Fault와 Hard Page Fault의 합 입니다. Soft Page Fault값은 Page Faults/sec값에서 Pages/sec값을 빼면 됩니다. 따라서, Page Faults/sec의 값을 작을수록 좋다고 말 할 수 있겠으며, 상황에 따라서 그 임계치는 다르므로, 평상시에 모니터하여 적정 값을 파악해 두셔야 합니다.

Memory\Pages/sec : Pages/sec

하드 페이지 부재를 해결하기 위해 디스크에서 읽거나 디스크로 쓴 페이지의 비율입니다. 이것은 Memory\\Pages Input/sec과 Memory\\Pages Output/sec의 합 입니다. 메모리 공간이 부족하게 되면, 디스크의 페이징 파일로 메모리의 내용을 옮겨서 메모리의 여유공간을 확보하여 사용하게 되며, 또 필요시 페이징 파일에서 데이터를 메모리로 로드하여 처리하는 과정을 반복하게 되므로 성능이 저하되게 됩니다. Pages/sec 카운터 값이 20이상 지속되면 메모리 이상을 의심해야 합니다.

PhysicalDisk\%Disk Read Time

디스크가 읽기 작업을 수행한 시간의 백분율 입니다.

PhysicalDisk\%Disk Write Time

디스크가 쓰기 작업을 수행한 시간의 백분율 입니다.

PhysicalDisk\%Disk Time

디스크가 읽기 및 쓰기 작업을 수행한 시간의 백분율이며, 이 값은 Disk Read Time와 Disk Write Time의 합 입니다.

PhysicalDisk\Avg. Disk Queue Length

디스크의 읽기 및 쓰기 작업을 위해 대기중인 실제 디스크 큐 길이 입니다. 이 값은 디스크당 2를 초과하게 되면, 디스크 쪽 부하를 점검해야 합니다.

PhysicalDisk\Current Disk Queue Length

현재 시점의 디스크 읽기 및 쓰기 작업을 위해 대기중인 디스크 큐 길이 입니다. 이 값 역시 2를 초과하면, 디스크 쪽 부하를 점검해야 합니다.

Network Interface\Current Bandwidth

네트워크 인터페이스의 현재 대역폭입니다. 사용하는 네트워크 어댑터 카드의 지원 가능 대역이 100Mbps인 경우에 Current Bandwidth 값이 10Mbps이라면 네트워크 어댑터 카드의 속성 세팅이 잘 못 되었을 가능성이 큽니다.

Network Interface\Packets Outbound Errors

이 항목은 오류로 인해서 외부로 반출할 수 없는 패킷의 수를 나타냅니다.

Network Interface\Packets Received Errors

이 항목은 상위 계층의 프로토콜로 전달되지 못하도록 하는 오류를 포함하고 있는 외부로부터 유입되는 패키의 수를 나타냅니다.

Server\Bytes Total/sec

이 항목은 초당 서버가 네트워크에서 주고 받은 바이트 수 입니다. 동일 네트워크에 존재하는 서버들의 각각의 Bytes/sec 합이 네트워크 대역폭보다 크다면, 네트워크 분리를 고려하셔야 합니다.

SQLServer:Buffer Manager\Buffer cache hit ratio

SQL Server가 데이터를 디스크에서 읽지 않고 버퍼 풀에서 찾은 페이지의 비율입니다. 이 값의 높은 수치는 SQL Server가 데이터를 가져오기 위해서 하드디스크에 아주 가끔 액세스한다는 것이며, 이는 SQL 성능을 극대화 시킵니다.

SQL Server를 모니터하는 다른 카운터들과는 달리, 이 카운터는 SQL Server가 다시 시작한 시점 이후부터의 버퍼 캐시 히트율의 평균값 입니다. 즉, 이 카운터는 현재 시점의 측정 값이 아닌 SQL Server가 시작된 이후의 모든 날들의 평균값입니다. 현재 시점의 버퍼캐시가 어떤일을 하고 있는지에 대한 정확한 자료를 얻기 원한다면, SQL Server를 중지했다가 다시 시작해야만 하고, 정확한 버퍼캐시 히트율을 확인 하기 위해 SQL Server를 여러시간 동안 일반적인 활동을 하게 내버려 둬야 합니다.

만약, 최근에 SQL 서버를 재 시작 하지 않았다면, 여러분이 보고 있는 버퍼 캐시 히트율은 아마도 정확한 정보가 아닐 것 입니다. 또한, 버퍼캐시 히트율이 좋아 보일지라도, 오랜 시간의 평균값으로 계산되기 때문에 실제로는 좋지 않을 지도 모릅니다.

OLTP 응용프로그램 환경에서 이 수치는 통상 90%~95% 이상이어야 합니다. 그렇지 않다면, 여러분은 성능 향상을 위해서 서버에 RAM을 추가할 필요가 있습니다. OLAP 응용프로그램 환경에서는, OLAP작동하는 기본특성 때문에 이 수치는 OLTP보다 더 작을 수 있습니다. 어떤 경우라도, 더 많은 RAM은 SQL Server의 OLAP활동의 성능을 증가 시킬 것 입니다.

SQLServer:Buffer Manager\

디스크로 부터 데이터를 읽는 대신에 버퍼 캐시로부터 데이터를 가져온다면 SQL Server는 보다 적은 작원으로 보다 훨씬 더 빠르게 수행합니다. 몇몇 경우에, 메모리 집중적인 명령들로 인해 데이터 페이지들이 이상적으로 플러시 되기 전에 캐시 밖으로 밀려 나기도 합니다. 이는 버퍼캐시가 충분히 크지 않거나 메모리 집중적인 명령의 작업을 위한 더 많은 버퍼 공간 요구에 의해 발생할 수 있습니다. 이런 경우에는 버퍼에 추가 적인 공간을 만들기 위해서 플러시 된 데이터 페이지들은 버퍼가 아닌 디스크로부터 읽혀지게 되며 SQL Server 성능에 안 좋은 영향을 미치게 됩니다. SQL Server가 이러한 문제를 가지고 있는지 확인 하기 위한 3개의 SQL Server 카운터가 있습니다.

SQLServer:Buffer Manager\Page life expectancy

이 성능 카운터는 데이터 페이지가 얼마나 오랫동안 버퍼에 머무르는지를 평균적으로 초 단위로 나타내 줍니다. 만약 이 값이 300초 보다 작은 값을 보인다면, SQL Server의 성능 극대화를 위해서 추가적인 메모리가 필요함을 잠재적으로 나타내는 것 입니다.

SQLServer:Buffer Manager\Lazy Writes/Sec

이 성능 카운터는 버퍼공간을 비우기 위해서 지연기록기(LaxyWriter) 프로세스가 더티페이지들을 버퍼공간에서 디스크로 초당 얼마나 많이 옮겼는지 나타냅니다. 즉, 이 항목은 높은 값(초당 20정도)이어서는 안됩니다. 이성적으로는 0에 가까워야 합니다. 만약 이 값이 0이라면 여러분의 SQL Server는 아주 큰 버퍼 공간을 가지고 있고, 일정한 체크포인트가 발생하여 더티페이지가 반환되기를 기다리는 대신에, 더피페이지 반환을 하지 않아도 됨을 나타냅니다. 만약 이 값이 높다면 보다 많은 메모리가 필요함을 나타냅니다.

SQLServer:Buffer Manager\Checkpoint Pages/Sec

일반적으로 체크포이트가 발생하게 되면 모든 더티페이지들으 디스크에 쓰여지게 됩니다. 이것이 일반적인 절차이며, 체크포인트가 처리되는 동안 이 카운터가 증가하게 됩니다. 여러분은 이 카운터가 오랜 시간에 걸쳐서 카운터가 높아 지는걸 원치 않으실 것 입니다. 이는 SQL Server의 귀중한 자원을 많이 사용할 수 있는 체크포인트 프로세스가 보다 더 자주 실행됨을 나타냅니다. 만약 이 값이 높은 값을 가진다면, 빈번한 체크 포인트 발생을 줄이기 위해서 더 많은 RAM을 추가할 것을 고려하시거나, SQL Server의 구성옵션 중에 ‘복구 간격(recovery interval)’ 옵션 값을 늘려주십시오.
[관련글] Transaction 과 CheckPoint

SQLServer:Buffer Manager\Page reads/sec

모든 데이터베이스에 대해서 발생한 물리적 데이터 페이지의 초당 읽기 수를 나타냅니다. 물리적 I/O는 상대적으로 비용이 많이 발생하므로, 더 큰 데이터 캐시를 사용하거나, 인덱스 및 쿼리를 효율적으로 작성하거나, 데이터베이스 모델링을 다시하여 물리적 I/O비용을 줄여야 합니다.

SQLServer:Buffer Manager\Stolen Page

Windows 시스템이 SQL Server가 아닌 다른 응용프로그램의 요구를 충족시키기 위하여 얼마나 많은 페이지들이 SQL Server 데이터 캐시로부터 제거되었는지를 나타냅니다. Min Server Momory를 지정하여 SQL Server가 지정한 만큼의 SQL Server 전용으로 메모리를 할당하게 할 수 있지만, 그 만큼 다른 프로그램이 적은 메모리로 운영되게 되므로 페이징이 발생하게 됩니다. 따라서 메모리증설을 고려해야 합니다. (역주 : 보통 SQL Server가 운영되고 있는 하드웨어는 SQL Server만을 위해서 존재해야 합니다. 한가지 예를들자면, WEB 서비스를 하기 위해서 한 서버에 IIS 서비스와 SQL Server을 같이 돌리는 것은 좋지 않은 예 입니다. 즉, SQL Server에서 Min Server Momory를 지정하여 윈도우에서 SQL Server 메모리를 사용하지 못하게 하는게 좋습니다.)

SQLServer:Databases\Log Flushes/sec

이 카운터는 초당 플러쉬 된 로그 수를 나타냅니다. 하나의 로그플러쉬는 하나의 트랜잭션이 커밋되어 로그파일에 기록되는 것을 의미 합니다. 이 카운터는 데이터베이스 별로 측정 되거나, 단일 SQL Server의 전체 데이터베이스에 대한 값으로 측정 될 수 있습니다.

여러분은 로그캐시에 대해서 한번도 들어보지 못했을지도 모르겠습니다. 이것은 SQL Server서버가 로그파일에 쓰여질 로그데이터를 기록하는 메모리의 한 영역입니다. 로그캐시의 목적은 트랜잭션이 커밋되기 전에 특정상황이 발생하여 롤백 해야 하는 상황에서 트랜잭션을 롤백 하는 용도로 사용되기 때문에 매우 중요합니다. 그러나, 트랜잭션이 완료되면(완료되면 절대 롤백되지 않음) 로그캐시는 즉시 물리적인 로그파일로 플러시 됩니다. 이것이 정상적인 절차입니다. SELECT쿼리는 데이터를 수정하지도 않고 트랜잭션을 생성하지도 않고 로그플러쉬를 발생하게 하지도 않음을 명심하십시오.

본질적으로, 로그캐시에 있는 데이터가 물리적인 로그파일로 쓰여질 때 하나의 로그플러쉬가 발생합니다. 따라서, 하나의 트랜잭션이 완료될 때마다, 로그플러쉬는 발생을 하며, 많은 수의 로그플러쉬 발생은 SQL Server로부터 수행되는 많은 수의 트랜잭션과 관련이 있습니다. 그리고, 짐작하시는 것처럼 로그플러쉬(얼마나 많은 데이터가 로그캐시로부터 디스크에 기록이 되어졌는가?)의 크기는 트랜잭션에 따라 다릅니다.

우리가 디스크 I/O 병목현상을 격고 있고, 그 원인을 확신하지 못하고 있다고 가정합시다. 디스크 I/O에 대한 병목을 해결하기 위한 하나의 방법은 Log Flushes/sec 카운터 데이터를 수집하고, 이 과정을 처리하는데 얼마나 바쁜지 보는 것 입니다. 여러분의 서버에 많은 트랜잭션이 발생하고 있다면 로그플러쉬의 양은 당연히 많을 것 입니다. 따라서, 이 카운터 항목으로 보는 값은 트랜잭션을 발생하는 활동 형 쿼리가 얼마나 바쁜가에 따라 서버마다 다양할 것 입니다. 이 카운터 정보로써 여러분은 초당 발생하는 로그플러쉬 수가 운영하는 서버에서 예상되는 트랜잭션의 수 보다 확연하게 높은가에 대한 상황 판단에 도움을 줄 것입니다.

예를 들어, 매일 1,000,000행을 한 테이블로 삽입하는 작업을 한다고 가정합시다. 이 행들이 삽입되어질 수 있는 방법은 다양합니다.

첫째, 각 행은 따로따로 삽입되어 질 수 있습니다. 각 INSERT는 단일 트랜잭션 내부에 감싸집니다.
둘째, 모든 INSERTS는 단일 트랜잭션 내에서 수행되어 질 수 있습니다.
마지막으로, INSERTS는 1과 1,000,000사이의 어딘가에 여러 개의 트랜잭션으로 나누어 질 수 있습니다.

각 형태의 처리는 다르며, SQL서버와 초당 플러시 되는 로그 수에 매우 다른 영향을 미칩니다. 더구나, 프로세스가 멀티 트랜잭션으로 처리되고 있는데, 단일 트랜잭션으로 처리되고 있다고 착각할 수 도 있다. 많은 사람들이 단일 프로세스를 단일 트랜잭션으로 생각하고 있는 경향이 있습니다.

첫째의 경우에서, 만일 1,000,000행이 1,000,000개의 트랜잭션으로 삽입되어진다면, 1,000,000번의 로그 플러시가 발생할 것입니다.그러나, 두 번째 경우에는, 단일 트랜잭션에서 1,000,000행이 삽입되어 질 것이고, 단지 하나의 로그 플러시가 발생할 것입니다. 그리고, 세 번째  경우 에는 플러시 되는 로그의 수는 트랜잭션의 수와 같을 것입니다. 명백히, 로그 플러시의 크기는 1,000,000트랜잭션이 1트랜잭션보다 훨씬 클 것입니다, 그러나, 대개의 경우 성능의 관점에서 여기서 언급한 내용은 그다지 중요하지 않습니다.

어떤 옵션이 가장 좋은가요? 모든 경우에서, 많은 디스크 I/O를 유발할 것입니다. 1,000,000행을 핸들링 할 경우에는 I/O양을 줄일 묘안이 없습니다. 그러나, 하나 혹은 적은 수의 트랜잭션을 사용함으로써 로그 플러시 양을 많이 줄일 수 있을 것이고, 이는 디스크I/O양을 줄이게 되어, I/O병목 감소와 성능을 높여줄 것입니다. 우리는 두 가지 포인트를 배웠습니다. 첫째는, 여러분이 플러시 되는 로그 양을 가능한 많이 줄이길 원할 것이라는 것과, 둘째, 여러분의 서버에서 발생하는 트랜잭션의 수를 줄이는 것 입니다.

SQLServer:Databases\Transactions/sec

선택한 데이터베이스에서 발생한 초당 발생하는 트랜잭션 수를 나타냅니다.

SQLServer:General Statistics\User Connections

SQL Server를 사용하는 사용자 수가 많음에 따라 SQL Server 성능에 영향을 미치기 때문에 여러분은 SQL Server General Statistics Object : User Connections 카운터에 관심을 가질것 입니다. 이 카운터는 사용자 수가 아닌, SQL Server에 연결된 사용자 연결 수를 나타냅니다. 이 수치를 해석할 때, 하나의 단일 사용자는 여러 개의 연결들로 열릴 수 있음을 유념하십시오. 그리고 또한, 여러 명의 사람이 하나의 단일 사용자 연결을 공유할 수 도 있습니다. 이 수가 실제 사용자수를 나타낸다고 가정하지 마십시오. 대신에, 서버가 얼마나 바쁜가에 대한 상대적 척도로 사용하십시오. 여러 시간에 걸쳐서 이 수치를 모니터 해보시면, 서버가 많이 사용되고 있는지, 적게 사용되고 있는지 느낄 수 있을 것 입니다.

SQL Server:Latches\

래치는 본질적으로 “경량 잠금” 입니다. 기술적인 관점에서, 래치는 가볍고, 짧은 동기화 개체입니다. 래치는 마치 잠금 처럼 동작하고, 예상치 않은 변화로부터 데이터를 보호하기 위한 목적을 가지고 있습니다. 예를 들면, 하나의 행이 버퍼로부터 SQL서버의 저장소 엔진으로 이동될 때, 이 매우 짧은 시간 동안의 이동 중에 행 내부의 데이터 변형을 방지하기 위해서 SQL서버에 의해서 래치가 사용되어 집니다.마치 잠금과 같이, 래치는 데이터베이스의 행들에 대해 접근하지 못하게 SQL서버를 방해 할 수 있고, 이는 성능에 안 좋은 영향을 줍니다. 이러한 이유 때문에 여러분은 래치 시간을 최소화하길 원하실 것입니다. SQL서버는 래치의 활동을 측정하기 위한 3가지 다른 방법을 제공합니다.

SQL Server:Latches\Average Latch Wait Time(ms)

래치 요청들을 위해 대기해야 하는 시간입니다. 이는 오직 대기해야 하는 래치 요청들에 대한 측정값입니다. 대부분의 경우에 대기가 없습니다. 따라서, 이 값은 모든 래치에 대한 것이 아니라, 대기 해야 하는 래치에 대해서만 적용된 값임을 유념하십시오.

SQL Server:Latches\Latch Waits/sec

이 값은 즉시 승인 받지 못한 래치 요청수입니다. 다시 말해서, 1초 동안에 대기 해야 했던 총 래치의 수입니다. 따라서, 이는 Average Latch Wait Time으로 부터 측정된 래치들 입니다.

SQL Server:Latches\Total Latch Wait Time (ms)

이는 지난 초 동안의 총 래치 대기 시간 (ms) 입니다.

이 값을 읽을 때, 성능카운터에서 배율을 정확히 읽었는지 확인하십시오. 배율은 카운터 값마다 다르게 표시될 수 있습니다. 제 경험에 비추어 볼 때, Average Latch Wait Rime 카운터는 거의 변함이 없습니다. 반면에 다른 두 개의 카운터(Latch Waits/sec , Total Latch Wait Time (ms)) 는 SQL서버가 뭘 하느냐에 따라서 큰 변동폭을 보일 수 있습니다.

각각의 서버가 약간씩 다르기 때문에, 래치 활동도 각 서버마다 다릅니다. 전형적인 작업부하가 있을 때, 이 카운터에 대한 기준 값을 확보해 두시는 것은 아주 좋은 생각입니다. 이는 현재 어떤 일이 발생하고 있는가에 대해서 래치 활동이 평상시 보다 많은지 적은지에 대한 비교자료가 될 것입니다.

래치 활동이 기대치 보다 높다면, 이는 종종 하나 혹은 두 개의 잠재적인 문제점들을 나타냅니다. 첫째, 여러분의 SQL서버가 보다 많은 메모리를 사용할 수 있음을 의미할지도 모릅니다. 래치 활동이 높다면, 버퍼 캐시 히트 비율이 어떤지 확인하십시오. 이 값이99% 이하라면, 보다 더 많은 양의 메모리가 서버의 성능에 도움을 줄 것입니다. 만약 99% 이상이라면, 문제를 유발하는 것은 IO시스템일수도 있습니다. 빠른 IO시스템은 서버 성능에 유리합니다. 래치에 대해서 보다 더 많이 배우고, 실험해보고 싶으시면, 여기 두 개의 명령이 있습니다.

SELECT * FROM SYSPROCESSES WHERE waittime>0 and spid>50

이 쿼리는 현재 대기상태에 있는 waittype, waittime, lastwaittype, waitresource, SPID들을 표시해 줍니다. lastwaittype은 래치 종류를, waitresource는 SPID가 어떤 개체를 위해 대기 중인지를 알려줍니다. 이 쿼리를 실행하게 되면, 실행 시점에 대기가 발생하고 있지 않다면, 아무런 결과도 얻지 못 할 지도 모릅니다. 그러나 계속해서 실행하다 보면, 결국 몇몇 결과를 얻게 될 것입니다.

DBCC SQLPerf (waitstats, clear) --대기 통계초기화
DBCC SQLPerf (waitstats) -- SQL서버 재시작(대기 통계 초기화) 이후의 대기 통계정보

이 쿼리는 대기유형, 대기시간과 함께 현재의 래치들을 나타내줍니다. 여러분은 아마도 통계정보를 초기화하길 원할 겁니다. 그런 다음에는 어떤 래치가 가장 많은 시간을 차지하는지 알기 위하여, DBCC SQLPerf(waitstats)명령을 짧은 시간에 걸쳐서 정기적으로 실행하십시오.

SQL Server: Locks\Average Wait Time(ms)

만약에, 사용자들이 트랜잭션의 완료를 위한 대기시간 때문에 불만을 나타낸다면, 여러분은 개체 잠금이 이 문제가 되고 있는지 찾고 싶을 것 입니다. 문제점을 찾기 위해서, SQL Server Locks Object: Average Wait Time (ms) 카운터를 사용하십시오. 이 카운터는 database, extent, key, paLock Timeouts/secge, RID, table의 다양한 잠금에 대한 평균 대기 시간 정보를 측정합니다. DBA로써, 여러분은 평균 대기 시간이 얼마 정도까지 허용될 수 있는지 결정해야 합니다. 한가지 방법으로써, 개별 잠금 종류에 대해서 장시간 동안 이 카운터 항목을 모니터 하시고, 각 잠금 별 평균을 파악하시는 겁니다. 그리고 그 평균값을 참고 자료로 활용 하시는 거죠. 예를 들어, RID의 평균 잠금 대기시간이 500ms 라면, 500보다 큰 대기시간을 가지는 개체들은 , 잠재적인 문제점을 가지고 있다고 판단할 수 있을 것입니다. 특히 500보다 훨씬 크거나, 장시간 동안 연장되는 개체들은 더 쉽게 판단할 수 있습니다.

여러분이 트랜잭션 지연에 의한 단일 혹은 다양한 종류의 잠금을 확인 할 수 있다면, 어떤 트랜잭션들이 잠금의 원인이 되었는지 확인할 수 있는지 알기 위해서 조사하길 원할 것 입니다.

SQL Server: Locks\Lock Timeouts/sec

리소스에 잠금을 걸기 위해 대기하면서 타임 아웃된 잠금 요청 횟수를 나타냅니다.

SQL Server: Locks\Lock Waits/sec

즉시 충족시킬 수 없고, 잠금을 허가하기 위해서 호출자가 기다려야 하는 잠금 요청의 수

SQL Server: Locks\Number of Deadlocks/sec

만약 여러분들의 데이터베이스들이 데드락 문제로 괴로워하고 있다면, SQL Server Locks Object: Number of Deadlocks/sec 카운터를 통해서 추적할 수 있습니다. 그러나, 이 값이 상대적으로 높지 않다면, 이 값은 초단위로 측정되기 때문에 여러분은 더 많이 보기 원할 것입니다. 그리고, 눈에 띄게 보여지기 위해서는 다량의 데드락이 있어야 합니다. 그러나, 여전히 이 카운터는 여러분이 데드락 문제를 가지고 있는지 확인하기 위해서 가치있는 항목입니다. 차라리, 데드락을 추적하기 위해서 프로필러를 이용하십시오. 이는 보다 상세한 정보를 제공할 것입니다. 데드락 문제를 발견하기 위해서 Number of Deadlocks/sec 카운터를 활용하시고, 좀 더 세부적인 분석을 위해서 프로필러를 사용하십시오.

SQL Server: Memory Manager\Memory Grants Pending

작업 영역 메모리 허가를 위해 대기하고 있는 현재의 프로세스 수

SQL Server: Memory Manager\Target Server Memory(KB) & Total Server Memory(KB)

이 두 카운터를 관측하는걸 고려하십시요. SQLServer:Memory Manager: Total Server Memory (KB) and SQLServer:Memory Manager: Target Server Memory (KB). 첫번째 카운터 SQLServer:Memory Manager: Total Server Memory (KB) 는mssqlserver서비스가 메모리를 얼마나 사용하고 있는가를 말해줍니다. 이것은 SQL서버 Bpool영역으로 커밋된 전체 버퍼수를 포함하고, ‘OS in Use’ 로 표시되는 OS버퍼들도 포함합니다. 두번째 카운터, SQLServer:Memory Manager: Target Server Memory (KB)는 SQL서버가 얼마나 많은 메모리를 가용할 수 있는가를 나타냅니다. 이는 SQL서버가 시작시에 예약한 버퍼수에 기초합니다. 만약, Total Server Memory (KB)이 Target Server Memory (KB)보다 작다면, 이는 SQL서버가 충분한 메모리를 가졌고, 효율적으로 사용하고 있다는 것을 의미합니다. 반면에Total Server Memory (KB)이 Target Server Memory (KB)보다 크거나 같다면, 이는SQL서버가 메모리 압박을 받고 있고, 더 많은 물리적 메모리에 액세스 하고 있음을 나타냅니다.

SQL Server: SQL Statistics\Batch Requests/sec

SQL서버가 얼마나 바쁜지 알기 위해서, SQLServer: SQL Statistics: Batch Requests/Sec 카운터를 모니터 하십시오. 이 카운터는 초당 SQL서버가 받는 배치 요청 수를 측정하고, 일반적으로 서버의 CPU들이 얼마나 바쁜지 나타냅니다. 말하자면, 초당 1000배치가 넘어서면, SQL서버가 매우 바쁘다는 것을 나타내며, CPU병목 현상이 아직 나타나지 않고 있다면,조만간 CPU병목 현상이 나타날 것임을 알 수 있습니다. 물론 이 수치는 상대적인 것이며, 여러분의 하드웨어가 고 사양이라면, 보다 더 많은 초당 배치요청 수를 커버할 수 있을 것입니다. 네트워크 병목의 관점에서 보자면, 100Mbps 네트워크 카드는 초당 3000 배치 요청을 처리 할 수 있습니다. 만일 네트워크 병목이 심한 서버를 운영하고 계시다면, 네트워크 카드를 2개이상 늘리거나, 1Gbps 네트워크 카드로 교체 할 필요가 있을 것입니다.

몇몇 DBA들은 전체 SQL서버활동량을 측정하기 위해서 SQLServer: Databases: Transaction/Sec: _Total 카운터를 모니터 하는데, 이는 좋은 방법이 아닙니다. Transaction/Sec 카운터는 전체 활동량이 아닌 한 트랜잭션의 내부활동을 측정하며, 왜곡된 값을 나타냅니다. 대신에, SQL서버의 전체 활동량을 측정하는 SQLServer: SQL Statistics: Batch Requests/Sec 카운터를 사용하시기 바랍니다

SQL Server: SQL Statistics\SQL Compilations/sec

TSQL코드의 컴파일은 SQL서버의 일반적인 동작입니다. 그러나, 이 컴파일이 CPU와 다른 리소스들을 많이 잡아 먹기 때문에, SQL서버는 가능한 많은 실행계획을 캐시에 저장해서 실행계획이 컴파일 되지 않고 재사용되도록 시도합니다(실행계획은 컴파일이 발생할 때 생성됩니다). 보다 더 많은 실행계획이 재 사용 되어지면, 서버에 대한 부담은 더 적어지게 되며, 전체적인 성능은 더욱 더 향상 됩니다.

SQL서버가 얼마나 많은 컴파일을 하고 있는지 확인 하려면, SQLServer: SQL Statistics: SQL Compilations/Sec 카운터를 모니터 하십시오. 여러분이 기대하시는 것처럼, 이 카운터는 초당 얼마나 많은 컴파일이 SQL서버에 의해서 실행되었는지를 측정합니다.

말하자면, 이 카운터의 수치가 초당 100을 넘어서면, 불필요한 컴파일 오버헤드를 경험하고 계신 것 입니다. 이러한 높은 수치는 여러분의 서버가 매우 바쁨을 나타내거나, 불필요한 컴파일들이 실행되고 있다고 볼 수 있겠습니다. 예를 들어, 오브젝트의 스키마가 변경되거나, 병렬로 실행계획이 잡혀있던 것이 직렬로 실행되어야 하거나, 통계가 다시 계산되었다거나 하는 등의 이유로 SQL서버로부터 재 컴파일 하라는 지시를 받았을 수도 있습니다. 어떤 경우에는, 불필요한 컴파일을 줄이기 위해서 여러분의 노력이 필요할 수 도 있습니다. 만약, 여러분의 서버가 초당 100회 이상의 컴파일을 수행한다면, 이 원인이 여러분이 조절할 수 있는 것인지 아닌지 찾기 위해 애 쓰셔야 합니다. 너무 많은 컴파일은 SQL서버의 성능에 악영향을 끼칩니다.

SQL Server: SQL Statistics\Re-Compilations/sec

초당 SQL문이 재 컴파일 되는 수 (역주 : 컴파일이 되어서 버퍼에 올라가 있으면 SQL Server는 다시 컴파일을 하지 않고 버퍼에 있는 컴파일된 것을 사용하게 됩니다.. 하지만 어떠한 특정 이유로 그 SQL문들은 재컴파일을 하게 되는데, 앞서 컴파일 카운트를 보셨듯이 컴파일 자체가 Server의 리소스를 사용하는 것 이기 때문에 되도록이면 재 컴파일 이슈가 없는것이 좋습니다. 해당 카운트가 너무 높다면 프로파일러나 DMV로 일일이 살펴볼 필요가 있습니다.)

SQL Server Access Methods Object: Full Scans/sec

그런데 가끔 인덱스 탐색보다 테이블 스캔이 빠른 경우에, 일반적으로 적은 테이블 스캔이 보다 많은 테이블 스캔 보다 좋다. 여러분의 서버에서 얼마나 많은 테이블 스캔이 발생하는지 알아보기 위해서, SQL Server Access Methods Object: Full Scans/sec 카운터를 사용하십시오.이 카운터는 단일 데이터베이스가 아닌 전체 서버에 대한 값이라는 사실을 염두에 두셔야 합니다. 이 카운터 값으로 알게 될 사실 하나는 가끔씩 예측이 가능한 스캔 형태를 나타낸다는 것 입니다. 대부분의 경우에 이 값들은SQL서버가 내부적으로 사용하는 것 들입니다.

여러분의 응용프로그램에서 나타나는 불규칙적인 테이블 스캔들을 파악하길 원하실 것입니다. 과도한 테이블 스캔이 발생될지를 고려하기 위해서 프로필러 데이터를 수집하고 인덱스 튜닝 마법사를 통해서, 어떤 것이 원인이 되는지 결정 할 수 있게 도움을 받을 수 있습니다. 그리고 몇몇 인덱스를 추가함으로써 테이블 스캔을 줄일 수 있을 것 입니다. 물론 SQL서버는 이 작업을 훌륭하게 수행할 것이고, 더 효율적이라면, 인덱스를 사용하는 것 대신에 테이블 스캔을 수행 할 것입니다. 그러나 내부적으로 어떤 일이 발생하는지 찾아 보지 않는 한 여러분은 알지 못 할 것입니다.


해당 정보들은 아래 블로그에서 "펌"하여 정리한 것 입니다.
[출처] http://cid-f08341357ef26d93.spaces.live.com/blog/cns!F08341357EF26D93!166.entry
[출처] http://ceusee.springnote.com/pages/260330
[원문] http://www.sql-server-performance.com/performance_monitor_counters_sql_server.asp
[번역] 김종균 (jkkim@techdata.co.kr)