모니터링과 제어

개요

이 장은 기업 데이터 센터에서 프로액티브 모니터링을 수행하기 위해 사용하는 도구와 절차를 소개한다. 경고, 현재 동작 윈도우, 이벤트 로그와 다른 모니터링 기술에 대한 내용이다. 리액티브 모니터링과 문제 해결 기술 또한 소개 될 것이다. 여기에 추천된 모든 것을 적용한다면, 각각의 운영 환경에 적합한 모니터링 체계를 수립할 수 있다.

소개

데이터 센터 운영은 정보시스템의 핵심으로 고객과 약속하고 인정한 모든 정보 기술 서비스를 관리하여 특정 서비스 수준 유지(SLA: service level agreements)에 부합하도록 서비스를 제공해야 한다. 서비스 수준 유지는 IT 관리자와 다양한 고객의 비즈니스 조직이(8장 참조) 협상하여 합의한 것이다. 이런 중요한 임무를 수행하려면, 운영 팀이 서비스 모니터링을 참조하여 용량을 산정하는 것은 필수적이다.

서비스 모니터링은 운영 팀이 실시간(real-time)으로 서비스 상태를 관찰하는 것으로 여기서 정의되는 실시간은 데이터 소스 컨텍스트에 전적으로 할당된 시간으로 정보 관리 및 데이터 보정을 위해 필요하다. 즉, 서비스가 시작, 다운, 한계에 도달했는지를 파악해야 한다. 보통 이렇게 중요한 작업을 장애가 일어나는 상황에서만 수행하는 경향이 있다. 요즘과 같은 시장 경쟁 환경에서, IT 서비스 문제가 일어나야만 조치하는 서비스 모니터링은 충분하지 못하다. 게다가, 서비스 모니터링이 운영 팀에게 서비스 작동을 프로액티브하게 관찰할 수 있도록 하는 능력을 제공하는 것은 매우 중요하다.

사전지원 모니터링은 문제가 발생되기 전에 문제점과 잠재적인 서비스 중지를 찾아 내는 것을 의미한다. 운영관리에 있어 사후지원과 사전지원 모니터링 능력을 제공하는 것은 최선의 서비스 모니터링 방법이다.

만일 운영 팀이 현재 서비스 상태를 파악하거나 서비스가 중지 될 수 있는 잠재적인 문제를 찾아내고, 이에 상응하는 작업을 수행할 권한 및 능력을 가지고 있어야 한다. 이것은 운영 팀이 직접 작업을 취하거나, 적어도 특정한 형태의 사후지원 또는 사전지원 작업이 적절하게 이루어 지도록 작업 그룹에 알려주는 것을 의미하기도 한다. 이것은 "제어"라는 용어로 설명되기도 한다. 적절한 작업과 기술지원이 제공되었을 때, 서비스 모니터링과 제어는 운영 팀에게 항상 동일한 서비스 수준을 유지할 수 있는 중요한 역량을 제공한다. 적절한 서비스 모니터링과 제어가 없으면 서비스 수준 유지는 불가능하고, 생산성이 떨어지며, 결과적으로 유용하지도 않게 된다.

이 장은 모니터링 시스템을 구성하기 위해 필요한 모든 지식을 제공하고 있다. 이 장에서 소개하고 있는 프로세스, 평가해야 하는 기술, 모니터링 카운터를 주목해야 한다.

디자인 고려사항

모니터링 시스템은 개발과 운영 팀 사이에 갭을 없애 준다. 양 팀에게 유용한 정보를 제공한다. 이 장에서 제안된 모니터링 시스템은 계속 진행 중인 운영과 응용 프로그램 개발 팀을 모두 만족시키기 위한 것이다. 개발자들이 반드시 수행해야 하는 응용 프로그램 모니터링을 수행하지 않을 때를 추측해 보자. 다음과 같은 모니터링 시스템 디자인은 책임의 분리를 권고한다. 기술된 시스템은 문제를 해결할 수 있는 개발자에게 정보를 제공하는 한편, 현장에서 응용 프로그램을 감시하는 운영 요원을 가장 잘 이용할 수 있다.

필요 리소스

최소한 DBA와 모니터링 담당자는 적절한 모니터링 시스템이 필요하다. 모니터링 담당자는 현장에서 사용되는 모니터링 도구를 잘 알아야 한다. DBA는 모니터링 해야 할 응용 프로그램과 친숙해야 할 뿐만 아니라 응용 프로그램 문제를 검사하기 위해 사용하는 다양한 분석 도구에 대해서도 잘 알아야 한다.

사전에 필요한 시스템

여기서는 기존에 사용하던 모니터링 시스템에 대하여 다루지는 않을 것이다(모니터링 시스템의 개발은 이장에 걸쳐 논의될 것이다). 응용 프로그램 구성요소와 서비스 수준 유지 문서로 제공된 서비스 수준을 잘 알아야 한다.

프로세스 흐름도

마이크로소프트 SQL 서버에서 사용할 모니터링 시스템을 만드는 것은 요구 수집 단계, 디자인 단계, 구현 단계와 같이 비교적 간단한 프로세스로 구성된다. 각 단계를 지나면서, 수용해야 할 기술, 모니터링 할 카운터, 개발 방법론이 결정된다. 만일 이런 결정이 잘 못 된다면, 항상 다시 원점으로 돌아가 재 작업을 해야 한다. 모니터링 솔루션은 지속적으로 발전하고 변경되는 시스템이다.

반드시 구현해야 할 시스템 요소 중 하나는 운영 방안이다. 운영 방안은 시스템의 성공과 실패를 결정한다. 만일 운영 담당자가 개발된 모니터링 절차에 대해 부정적이라면, 응용 프로그램 문제를 발견하지 못하고 방치될 것이다. 적절한 운영 방안을 확립하려면 다음의 가이드 라인을 따라야 한다.

자기만족 회피

모니터링 담당자가 상세하게 체크하지 않고 리포트나 상태 표시자(indicator)를 대충 다룬 다면, 시간이 가면 갈수록, 문제는 많이 발생할 것이다. 이런 자기만족을 갖지 않도록 해야 한다. 모니터링 담당자는 그 들이 마치 의사처럼 행동하고, 리포트나 시스템이 제공하는 표시자를 잠재적인 증상으로 다루도록 해야 한다. 그리고 모니터링 담당자는 응용 프로그램 상태를 근거로 결론을 도출할 수 있도록 해야 한다. 응용 프로그램에 문제가 없을 지라여 세심하게 처리하는 자세를 가져야 한다. 이 과정을 통하여 모니터링 담당자가 시스템에 깊이 관여하게 되며 미세한 상황도 놓치지 않게 될 것이다. 규칙적으로 정해진 미팅 또는 전자메일의 정규화된 형식을 통하여 모니터링 담당자로부터 피드백을 받는 것이 필요하다.

사전지원 체계 확립

문제가 발생하기 전에 모니터링 담당자가 문제를 해결했다면 보상을 할 수 있는 체제를 구축하는 것도 중요하다. 모니터링 담당자가 미리 문제를 해결할 수 있는 능력을 갖도록 하는 한 가지 방법은 발생되는 증상을 좀 더 상세히 조사할 수 있도록 진단 도구를 제공하는 것이다. 초기 증상이 일시적인 네트워크 가동 중단으로 밝혀 지더라도 추가적인 진단 과정??이(Redundant Array) 하드디스크 오류를 발견할 수도 있다. 만일 모니터링 담당자가 이와 같은 조사를 하지도 않고, 할 수 있는 능력도 없다면, 전체 디스크 어레이가 작동하지 않을 때까지 이 문제는 방치될 것이다.

좋은 운영 방안을 수립한 후에는, 모니터링 솔루션의 다른 구성요소를 개발하기가 쉽다. 첫째로, 솔루션 요구사항을 문서화한다. 개발 과정에서 솔루션 요구사항을 문서화 하는 단계를 간과해서는 안 된다. 시스템 요구사항을 이해하고 문서화하는 것은 프로젝트의 범위를 결정하는데 도움이 된다. 이 것은 하루짜리 프로젝트이든 두 달 이상을 지속해야 하는 프로젝트이건 동일하게 적용된다.

두 번째는, 솔루션 디자인 단계는 반드시 문서화된 요구사항을 기초로 설계하며, 요구사항을 최대로 만족시킬 수 있도록 설계해야 한다. 디자인의 가장 중요한 요소는 운영 방안과 사용된 기술이다. 다음 단계로 진행하기 전에 최종 솔루션을 확실히 테스트한다.

마지막으로, 솔루션을 사용하는 최적의 방법을 결정해야 한다. 여하튼 응된다. 모니터링 솔루션 도입으로 문제가 야기되어, 결국 도입한 시스템을 제거하는 경우와 같이 예측할 수 없는 문제에 대한 계획도 수립해야 한다.

다음 흐름도는 시작에서 종료에 이르는 개발 프로세스에 대한 것이다.( 그림 5.1, 5.2, 5.3 참조)

모니터링에 대한 접근 방법

응용 프로그램을 모니터링한다면 주변에서 발생되는 모든 문제점도 세심하게 고려해야 한다. 어떤 사람은 매일 많은 성능 카운터를 모니터링 해야 한다고 확신하는 반면, 다른 사람은 과도한 메모리 페이징과 좋지 않은 캐시 히트 비율(cache hit ratio)만 관찰하면 된다고 믿는 사람도 있다. 각각의 담당자들은 자신의 경험을 기초로 하여 스스로 결론을 내리는 경향이 있다. "당신은 어떤 시스템을 선택할 것인가?"라는 질문에 대하여 자기들이 운영하는 시스템이 최적으로 운영되고 있다고 강력히 주장할 것이다.

모니터링 시스템의 목적은 서비스에 지장을 주기 전에 문제 상태를 운영 담당자와 개발자에게 알릴 수 있는 정보를 생성하는 것이다. 만일 응용 프로그램이 좀처럼 다운되지 않는다면, 시스템 상태 데이터를 분석하는데에 너무 많은 시간을 할애하지 않아도 된다. 그리고 모니터링 대상 서버가 수 백대이고, 더 이상 운영 지원도 받을 수 없다면, 제한적인 모니터링 방안을 수립할 수밖에 없다. 다른 한편으로, 중요한 비즈니스 프로세스를 처리하는 응용 프로그램 코드가 자주 변경되거나, 이러한 중요 서버가 체계적으로 관리되지 않는 데이터 센터에서 운영된다면 시스템 모니터링을 사전에 실시하는 것이 좋은 해결책이다.

이 장에서는 두 가지의 모니터링에 대한 윤곽을 제시한다. 선택한 모니터링에 대한 접근 방법은 전적으로 해당 조직의 환경에 종속적이다. 데이터 센터가 체계화 되어있는지, 담당자가 경험한 응용 프로그램 다운타임 시간은 얼마인지, 얼마나 중요한 응용 프로그램을 사용하고 있는지를 확인하고 의사결정을 해야 한다. 만일 선택한 접근 방법이 계속적이고, 신뢰할 만한 정보를 제공하지 않는다면, 적절한 정보를 제공해 줄 때까지 접근 방법을 개선해야 한다. 개선되는 접근 방법은 다른 접근 방법을 사용하거나 두 가지 접근 방법을 혼용한 형태일 것이다.

이 장에서 요약되는 모니터링 접근방법은 일반적으로 사전지원 모니터링과 예외적인 관리로서 인용되는 것들이다.

사전지원 모니터링

응용 프로그램을 사전지원 방식으로 모니터링 하는 이유는 여러 가지가 있다. 가장 중요한 것은 사전 모니터링은 오류가 발생되기 전에 오류를 잡을 수 있는 기회를 가진다는 점이다. 이와 같은 모니터링은 "불 끄기 식"(계속해서 발생되는 새로운 문제를 쫓아 다니는 방식) 방식으로부터 탈피할 수 있다. 결국, 이런 종류의 모니터링은 운영환경과 시스템환경에서 동작하는 응용 프로그램의 방법에 관한 많은 양의 정보를 제공한다. 즉, 응용 프로그램에 관한 좀 더 좋은 결정을 할 수 있도록 한다. 그럼 왜 사람들은 사전지원 형태로 응용 프로그램을 모니터링 하지 않을까?

한 가지 이유는 많은 DBA가 이런 종류의 모니터링을 수행할 시간이 없다는 것이다. 데이터센터 내의 각 응용 프로그램은 문제가 일어나기 전에 알았다면 철저히 분석되어야 한다. 만일 수백 개의 응용 프로그램을 담당하는 사람이 오직 한 사람이라면, 이런 일을 적절하게 처리하는 것이 어려울 것이다.

많은 DBA 간에 냉철하게 분리된 작업 영역을 가져야 한다. 어떤 곳에서는 몇몇 사람들이 그래프와 차트를 검사하는 권리를 위해 경쟁하는 것을 다른 사람들은 시간 낭비라고 생각할지도 모른다. 그리고 다른 곳에서는 발생하는 오류를 처리하는 작업이 행복할지도 모른다. 이런 경우에선, 사전지원 모니터링은 적절하지 못하다. 만일 응용 프로그램에 대해 좀 더 배우고 싶고, 그렇게 할 수 있는 시간이 있다면, 사전지원 모니터링을 수행하는 것을 추천한다.

사전 모니터링 체계

모든 것이 어디서 시작될까? 첫 재로, 각각의 응용 프로그램을 위해 베이스라인을 설정해야 한다. 포함된 기술을 재검토하거나 운영 체계를 발전시키기 전에 베이스라인을 정의해야 한다. 베이스라인라인을 가지고, 각 응용 프로그램에 대한 운영방법과 친숙해질 수 있는 단서를 마련해야 한다.

모니터링 베이스라인의 목적은 정상인 상태에서 응용 프로그램이 어떻게 작동하는 가를 명확히 문서화하는 것이다. 응용 프로그램이 가용한 모든 CPU 자원을 소비하는가? 페이징을 일으킬 정도로 많은 메모리를 사용하는가? 사용자가 요구하는 모든 서비스가 구동되고 있는가? 정상인 상황에서 응용 프로그램이 어떻게 작동되는가를 이해한 후, 제기된 문제에 관하여 답을 할 수 있을 것이다. 이런 방법으로 응용 프로그램을 이해하는 것은 문제가 발생되었을 때 문제를 변별해 낼 수 있기 때문에 중요하다.

정상 운영시에 일어나는 문제를 구별할 수 있어야 한다. 추가적으로, 이 문제는 두 개의 그룹으로 나뉘어 질 수 있다. 하나는 응답을 필요로 하는 문제 그룹이고 다른 하나는 응답이 없는 문제 그룹이다. 응답이 없는 문제 그룹은(백그라운드 문제로서 인용될 수 있는 그룹) 정확히 식별되지 않는 다면 모니터링 프로세스에 커다란 붕괴를 일으킬 수 있다.

백그라운드 문제

모든 모니터링 시스템에서 문제 소지가 있는 증상에 대해 조치하는 것은 중요하다. 그렇지만, 증상에 대한 조치 자체만이 모니터링 시스템에서 가장 중요하다고 한다면 거기에는 논쟁의 여지가 있다. 만약 조치사항이 어플리케이션이 동작하는데 있어 별반 도움이 되지 않는다면 그러한 조치를 위해 선행하였던 모든 모니터링은 시간낭비에 불과하기 때문이다. 여기서 문제가 되는 것은, 불행하게도, 나타날 수 있는 모든 증상들과 그에 대한 적절한 조치사항들을 미리 문서화할 수 없다는 점이다. 오히려, 많은 조치사항들은 모니터링 담당자들이 전체 라이프사이클 동안 응용 프로그램을 운영하는 과정에서 경험에 의해 학습한 것이다.

이러한 학습이 가능하기 위해선 시스템 운영 초기부터 조치하지 않은 (백그라운드 문제점이라 부르는) 문제점이라도 가능한 많이 기록해 놓아야 한다. 초기 운영부터 가능한 많이 '조치하지 않은' 시나리오를 모아둘 수 있다면, 모니터링 담당자가 응용 프로그램을 다루는 데에 있어 헛된 시간을 소비하지는 않을 것이다. 모니터링 담당자들이 조치해야 하는 새롭고 흥미로운 상황에 맞닥뜨리고 그런 상황의 트러블 슈팅을 통해 운영상의 개선점을 발견하려는 태도를 독려하는 것은 정말 바람직하다. 그와는 달리, (이전의 백그라운 문제들이 기록하지 않아서) 모니터??는데 많은 시간을 소비하는 것은 바람직하지 않다. 모니터링 담당자가 응용 프로그램의 여러 증상들이 조치할 필요도 없고 무시해도 괜찮다는 것을 자꾸 경험하게 된다면, 담당자는 시스템에 세심한 주의를 기울이지 않을 것이며 종국에는 정말 치명적인 오류를 놓치고 말 것이다.

조치가 당장 필요 없는 문제에 대해서도 모니터링 담당자들이 미리미리 알리도록 만들어야 한다. 모니터링 담당자들이 응용 프로그램을 운영하는 과정에서, 전에 보지 못한 증상이 나타나더라도, 알리지 않고 무시해도 괜찮다는 것을 학습하게 된다면, 결국에는 응용 프로그램 전체가 무시되고 방치되고 말 것이다. 베이스라인을 설정하려는 초기부터 당장의 조치가 필요하지 않을지라도 백그라운드 문제를 기록하자.

베이스라인 생성 - 추천 성능 카운터

이 섹션에서는 차트를 생성하는데 필요한 절차와 성능 카운터를 제시할 것이다. 가령 타임 프레임 같은 차트 요소는 시스템 환경에 따라 다르다. 또한, 응용 프로그램이 다르기 때문에, 차트에 대한 해석도 달라진다.

시스템 모니터 차트는 실시간으로 생성되거나 성능모니터링 로그 파일로 생성 될 수 있다(그리고 .htm 파일로 저장 가능하다). 원하는 기간 동안 통계를 기록할 수 있도록 차트를 로그 파일로 생성하는 것이 추천된다. 종료 시에는, 특정 시간으로 자르거나 전체 시간으로 하여 로그를 볼 수 있다. 만일 간단하게 현재 활동 시스템 모니터 그래프를 .htm파일로 저장하였다면, 최근에 스크린에 보여진 데이터만 오직 볼 수 있다.

정확한 데이터를 수집하기 위하여 결정할 두 가지 구성 옵션이 있다. 첫 번째는 샘플링 간격이다. 성능 카운터 사용은 SQL 서버에 오버헤드를 주지 않는다(로그를 기록하기 위해 요구되는 디스크 I/O는 제외). 만일 베이스라인 데이터가 디스크 공간을 너무 많이 차지한다면, 데이터 샘플을 수집하는 시간 간격을 늘리면 된다. 데이터 샘플 간격이 커질수록, 그래프의 정확도는 떨어진다.

두 번째, 반드시 SQL 서버를 모니터링 하기 위하여 어떤 서버를 사용할지 결정해야 한다. 원격으로 모니터링 할 수 있으나 장기간 동안 네트워크를 연결하여 카운터를 사용하는 것은 네트워크 트래픽을 가중 시킨다. 만일 SQL 서버에 성능 모니터링 로그를 위한 공간이 있다면, 성능 로그 정보를 로컬로 기록하는 것이 추천된다.

시스템 성능으로 인하여 성능 카운터는 적절하게 사용되어야 한다. 시스템 환경에 가장 잘 맞는 카운터 수와 수집 빈도수를 테스트 하자. 초기에는 베이스라인을 설정할 목적으로 가능한 높은 빈도를 가진 많은 수의 카운터를 사용하도록 권장한다.

다음 카운터는 베이스라인 설정 시에 반드시 포함되어야 한다.

베이스라인 차트 생성

베이스라인에 포함될 카운터를 살펴 보았으므로, 다음은 베이스라인 차트를 생성해보자. 다음 단계는 실제 운영 서버가 정상적으로 작동하는 시간 동안 실제 운영 서버에서 실행되어야 한다.

로그 파일 탭을 선택하고?위치?란의 파일 위치를 입력하자. 이러한 작업을 모두 정상적으로 수행했다면 성능 로그 수집 작업은 성공적으로 수행된 것이며, 베이스 로그를 수집할 수 있도록 설정을 스케줄하면 된다.

로그를 생성한 다음, 성능 윈도우에서?시스템 모니터?성능 옵션을 클릭한 다음, 오른 쪽 창에서?로그 파일 데이터 보기를 클릭한다(아이콘은 회색 실린더 모양이며 왼쪽에서 4번째 아이콘이다).?로그 파일 선택 창이 나타나면 로그 파일을 연다. 그러면 로그 된 결과를 그래프로 볼 수 있다.

성능 베이스라인을 생성했으므로, 진행중인 모니터링 솔루션 개발을 시작할 수 있다. 분명히 시스템 모니터는 운영 체계에서 중요한 역할을 할 것이다. 그러나 다른 기술도 사용 할 수 있을까? 다음 섹션은 다른 도구에 대한 설명과 시스템 모니터 그래프를 조사하는 방법에 관한 것이다.

차트의 계속적 사용

응용 프로그램의 초기 윤곽을 잡기 위해 시스템 모니터 차트는 유용하고, 계속되는 모니터링 솔루션의 주요 부분이 되어야 한다. 이 섹션에서는 계속되는 모니터링 체계의 시스템 모니터 차트를 어떻게 적절하게 추가하느냐는 것이다.

항상 실행중인 응용 프로그램의 성능 로그를 가지고 있어야 한다. 이러한 로그 사이즈를 관리할 수 있는 크기로 유지하려면 일 마감 종료 시점에 로그 파일을 잘라낸(옮기거나) 후, 저장하고 새로운 로그를 다시 시작해야 한다. 또한 카운터의 샘플링 간격을 15초에서 15분으로 감소시켜야 한다. 지속적인 모니터링을 통해 사용되는 카운터 수를 줄여나갈 수 있다. 다음 카운터는 매일 모니터링 해야 할 카운터이다.

로그 파일 데이터로부터 매일 생성된 차트는 반드시 응용 프로그램의 상태를 결정하기 위해 (다음 날) 재검토 되어야 한다. 이상한 증후는 반드시 검토되어야 한다. 만약 가능하다면, 차트에서 갑자기 곡선이 변화된다면 이 것의 원인을 밝히려는 시도를 해야 한다. 그 날 진급 발표가 있었는지? 특정 시간 동안 서버가 문제 있었는지? 이런 분석을 위하여 일정한 시간을 확보하자. 응용 프로그램 운영 시에 어떻게 반응하는 가에 대해 잘 알 수 있으며, 이 것은 장애 시에 아주 귀중한 자료가 된다.

문제가 발생했을 때, 문제를 해결하기 위하여 처음 베이스라인 성능 모니터링을 사용하자. 카운터가 매 15초 마다 검색되기 때문에 베이스라인 성능 모니터링 모드는 많은 정보를 제공한다. 이 것은 짧은 시간 동안 그래프를 정밀하게 조사할 때 유용하다. 문제가 있을 때, 반드시 짧은 시간 동안만 베이스라인 성능 모니터링을 작동시킨다. 베이스라인 성능 모드에서 데이터를 충분히 수집한 후에는 로그를 저장하고 제한된 카운터를 가지고 로그를 새로 시작한다. 서버 상태가 정상 일 때 모니터링을 계속하여 문제가 발생 시에 비교할 수 있어야 한다.

몇 가지 성능 로그를 저장한 후에, 그래프 추이 분석을 달과 같이 특정 시간 동안의 그래프 차트를 비교할 수 있다. 가령 "금요일에는 왜 이렇게 CPU 사용률이 높았나?", "그래프가 이상한 것은 서버가 다운되었기 때문인가? 와 같은 질문을 할 수 있어야 한다. 네트워크 부하로 인하여, 때때로 카운터 데이터가 유실되는 경우가 있기 때문에 특정 기간 동안 카운터 값이 없다고 서버가 다운되었다고 간단히 단정 지으면 안 된다.

그래프 상태가 이상하다면 원인을 밝히기 위해서는 확실한 증거를 제시해야 한다. 만일 사용자 서버가 아침에 느리다는 것을 불평한다면, 그 기간 동안의 그래프를 철저히 분석하자. 그래프를 다른 것과도 비교해보자. 그래프에 대하여 잘아는 것은 유용하다.

경고

다른 유용한 모니터링 기술은 경고이다. 경고는 미리 정의된 이벤트이다. CPU사용률이 100%에 이르면 시스템을 사용할 수 없게 된다. 이런 경우를 미리 설정하고 발생 시에는 시스템에서 자동으로 알릴 수 있도록 하는 것이다.

경고와 알림을 설정하는 방법에 관한 문서는 많다. 하지만 정의해야 할 조건에 대한 정보는 적다. 이 섹션에서는 실제 운영 환경에 적용해야 할 내용에 대한 것이다.

모니터링 담당자에게 경고를 보내야 하는 상황은 다음과 같다.

SQL 서버 로그

모니터링의 다른 중요한 구성요소는 SQL 서버 로그 및 SQL 에러 로그이다 (엔터프라이즈 관리자에서 찾을 수 있다). SQL 서버 로그는 응용 프로그램의 상태 정보를 알기 위한 훌륭한 자료이다. SQL 서버 로그는 서비스가 시작할 때부터 종료될 때까지 계속 메시지를 기록한다.

모니터링 관리의 효율을 위하여 모니터링 담당자가 SQL서버 로그에서 찾아야 할 것을 정의하자. 이 로그는 심각도 수준 19-25의 값을 가진 모든 오류를 기록한다. 모니터링 할 때, SQL 서버 로그에서 심각도 수준 19-25 사이의 값을 가진 오류는 반드시 체크해야 한다. 이 심각도 수준을 가진 오류는 트랜잭션을 실패하게 하고 응용 프로그램이 적절하게 운영되지 않도록 한다. 심각도 수준 20에서 25사이의 오류는 치명적인 것이다. 만일 이 오류가 발생되면, 클라이언트 연결은 오류 메시지를 받은 후에 종료된다.

자세하게 살펴보아야 하는 다른 중요한 정보는 응용 프로그램 내의 코드 오류 메시지다. 코드 속에서는?RAISERROR … WITH LOG?문법을 사용하여 각각의 오류를 발견해 낼 수 있다. 이 것은 오류 정보를 SQL 서버 로그(그리고 이벤트 뷰어 응용프로그램 로그, 이 장에서 나중에 논의될 것임)에 나타나게 한다.?RAISERROR의 사용이 정말 중요하다. 응용 프로그램이 무엇이든 간에, 오류 상태가 발생했을 때 절대적으로?RAISERROR … WITH LOG를 사용하자. 운영 담당자에게 문제에 대한 경고를 하고 기록을 남길 수 있다는 것은 효율적이고, 표준적이고, 현명한 방법이다.

SQL 에이전트 로그

SQL 에이전트 서비스는 작업 및 복제를 관리한다. SQL 에이전트는 모니터링에서 귀중한 도구가 될 수 있는 로그를 남긴다.

디폴트 로그 위치는 C:\Program Files\Microsoft SQL Server\Mssql\Log\ Sqlagent.out. 이다. 현재의 로그는 "out" 확장자를 가지고 있다. 반면에 예전 9개의 로그는 1 에서 9까지의 확장자를 가진다.

이벤트 뷰어

이벤트 뷰어는 사용자가 응용 프로그램, 보안, 시스템 로그에 기록되는 이벤트를 모니터링 할 수 있도록 한다. 이 로그는 SQL 서버 로그와 SQL 에이전트 로그로 분리시켜 추가적인 정보를 제공한다. SQL 서버 메시지가 응용프로그램 로그에서 발견되기 때문에 응용 프로그램 로그에 주로 관심을 가질 것이다. SQL 서버 메시지는 "MSSQLSERVER" 또는 "SQLSERVERAGENT" 라는 원본을 가진 메시지로 구별될 수 있다. RAISERROR 메시지도 여기에서 볼 수 있다.

응용 프로그램 로그에서 메시지와 연관된 자세한 정보를 보기 위해서는:

중앙 콘솔에서 이런 종류의 메시지를 정해진 경로로 보낼 수 있는 많은 3rd 파티 모니터링 응용 프로그램이 있다. 사실, 이런 종류의 응용 프로그램은 대부분의 엔터프라이즈 모니터링 시스템의 기본이다. 대부분의 회사들은 이미 이런 종류의 응용 프로그램 중의 하나를 사용하고 있을 것이다. 이 장은 모든 종류의 콘솔 응용 프로그램에 대해 다루지는 않더라도, 이 들 응용 프로그램에 대하여 간략히 살펴볼 것이다.

만일 SQL 서버 보안에 대해 관심이 있으며, 로그인 계정이 만료된 사용자 또는 가짜 인증서(credential)로부터 SQL 서버를 지키려면, 실패된 로그인 시도에 대하여 보안 로그를 모니터링 할 수 있다. 이 정보는 부적절한 접근에 대한 정보를 제공한다. 또한 잘못된 인증서를 사용하며 적절하게 구성될 필요가 있는 응용 프로그램에 대하여 경고해 줄 것이다.

작업 런타임(Run-time) 추세 모니터링

응용 프로그램이 가령 데이터베이스 백업, 파일 처리, 테이블 삭제와 같은 하나 혹은 여러 개의 스케줄 된 작업을 포함할 수 있다. 또한 이 들 작업 상태가 직접적으로 응용 프로그램의 상태에 영향을 준다. 다행히도, SQL 서버는 스케줄 된 작업 상태를 모니터링 하는 훌륭한 방법을 제공한다. 각각의 스케줄 작업은 작업 실행 기록을 가진다. 이 작업 기록은 규칙적으로 점검 되어야 한다.

작업 기록을 점검하기 위해서는:

작업 기록 창에서, 각 작업 실행에 대한 결과와 실행 기간이 나열된다. 작업 런타임 추세에 대해 관심을 가지자. 작업이 오전 1시에 항상 실패하는가? 작업이 실행 시 수행 시간이 길어지는가? 이런 추세를 통하여 실패가 발생되기 전에 실패를 예측할 수 있을 것이다. 나열된 각각의 실행 정보를 클릭할 때, 결과에 대한 상세 정보를 실행된 작업 / 단계로부터의 오류 및 / 또는 메시지 필드에서 발견할 수 있다.

만일 상세한 정보를 원한다면, 윈도우의 오른쪽 위에 있는 단계 정보 표시 체크 박스를 선택하자. 이 것은 작업의 모든 단계에 대한 정보를 제공할 것이다.

응용 프로그램과 연관된 작업 기록을 모니터링 하는 것은 시스템이 손상되기 전에 문제를 찾을 수 있다. 작업 기록을 검토하는 것은 시스템 손상이 일단 발생되었을 때에도 문제를 해결하는데 있어 좋은 방법이다. 그러나 작업 기록은 좀 더 복잡한 응용 프로그램을 관리할 때는 필요한 것보다도 적은 정보를 제공한다. 작업에 의하여 실행되는 절차는 문제 발생 시 SQL 서버 로그에 오류로 남을 수 있도록 작성되어야 한다. 이 것은 모니터링 담당자들에게 정확한 메시지를 전달 할 수 있도록 도와 줄 것 이다. 작업 기록이 "작업이 종료되었습니다" 라는 것보다 좀 더 자세한 정보를 제공하는 것은 가능하다. 이 것은 오류 발생시에 수행되는 코드가 자세하고, 서술적인 오류 메시지를 포함하고 있는 것이 얼마나 중요한 것인 가를 나타낸다.

다른 모니터링 응용 프로그램

대부분의 엔터프라이즈 모니터링 응용 프로그램은 네트워크에 중점을 두고 SQL 서버 응용 프로그램은 무시한다. 이 들 모니터링 툴은 이벤트 뷰어에 나타나는 오류 메시지에 초점을 두며 오류의 심각도를 결정하는 나름대로의 로직을 가지고 중앙 콘솔로 메시지를 보낸다. SQL 서버 응용 프로그램 코드에서도?RAISERROR … WITH LOG를 써서 상태 정보에 대한 일정 부분을 중앙 콘솔로 보낼 수 있도록 해야 한다.

엔터프라이즈 모니터링 응용 프로그램은 다른 응용 프로그램에 대하여 잘 알고 있지 않더라도, 운영되는 서버에 대해서는 많은 것을 알고 있다. 모니터링 응용 프로그램은 서버 문제를 발견하기 위해 미리 정의된 모니터링 방식을 이용한다. 모니터링 응용 프로그램 중에서 두각을 나타내는 것 중 하나는 마이크로소프트 오퍼레이션 매니저(MOM: Microsoft Operations Manager)이다.

마이크로소프트 오퍼레이션 매니저

SQL 서버를 위한 NetIQ AppManager, NetIQ Operations Manager, 마이크로소프트 오퍼레이션 매니저는 같은 코드 기반의 엔터프라이즈 모니터링 도구이다. 이들은 SQL 서버와 응용 프로그램 성능에 아주 중요한 아이템과 이벤트를 모니터링 한다.

사전 하드웨어 모니터링

하드웨어가 관점에서DBA로서 주요한 책임은 하드웨어 문제 발생시 담당직원에게 알리는 것이다. 사전에 모니터링을 하여 조기에 문제를 발견하고 해결되도록 하자. 다음 섹션은 모니터링 프로세스에 관한 내용이다.

사전 하드웨어 모니터링 시스템의 주요 목적 중의 하나는 시스템 용량에 대해 잘 이해하고 관리하기 위해 하드웨어를 모니터링 하는 것이다. 이 것은 문제가 발생하기 전에 문제를 예방할 수 있도록 한다.

다음 목록은 이 목적들을 만족 시키기에 필요한 기본 유형의 정보를 제공한다. 마이크로소프트 오퍼레이션 매니저 또는WMI(Windows?? Management Instrumentation)과 같은 도구를 사용하여 정보를 모을 수 있다. 정보를 제공하기 위하여 다음 사항을 고려해야 한다.

용량 계획을 위한 모니터링

응용 프로그램에 적절한 부하를 갖도록 환경을 구축한 후에, 응용 프로그램 로드 시에 생기는 변화를 모니터링 한다. 향후 용량 계획을 세우기 위해 자세히 응용 프로그램 로드를 살펴 보아야 한다. 이 프로세스는 본질적으로 용량 계획을 위한 모니터링 이다. 용량 계획 모니터링을 시작하기 위해서, 시스템의 하드웨어 성능과 직접적으로 연관되고 측정 가능한 성능개체를 선택해야 한다. 측정할 성능 개체는 다음과 같다.

이 성능 개체를 모니터링 하는 좋은 방법은 계속하여 성능 로그를 생성하는 것이다.

성능 로그의 사용

하드웨어 문제는 운영하면서 적절한 카운터를 포함시켜 성능 로그를 수집하고 분석하여 문제를 파악하는 것이다. 규칙적으로 다음 카운터를 모니터링 하는 것을 고려해야 한다.

모니터링 프로세스

반드시 모니터링 개체에 개별적인 임계 값을 설정하자. 임계 값은 시스템의 특정 동작에 대하여 대응해야 할 작업이 명시된 경우 경고가 일어 날수 있도록 작업하는 것이다. 만일 작업이 간단하다면 자동화하고, 자동화할 수 없다면 자세한 행동 지침을 문서로 제공한다.

모니터링 데이터 샘플 간격을 10분으로 정하고 오전 2시와 오후 4시, 즉, 하루에 두 번 수행하는 복잡한 스케줄을 구성할 수도 있다. 모니터링이 자주 실행되면 될수록, 서버 프로세서 사용이 더욱더 요구된다는 것을 명심하자.

경고하기 전에 발생하는?연속적인?경고 상태 발생 수를 입력하자. 그리고 적절한 작업이 실행되도록 한다.

만일 두 개 이상의 연관된 개체를 모니터링 한다면, 예상되는 결과가 무엇인지를 정확히 나타내야 한다. 예를 들어, Memory\Available Mbytes 카운터를 모니터링 하는 경우를 생각해보자. 카운터가 20MB 이하로 떨어질 때, 이벤트 뷰어에서 다른 응용 프로그램에 의해 원본 "XYZ"부터 윈도우 이벤트 1365 가 발생된다. 그리고 이 것은 가용 메모리 임계 값에 이르러 발생한 경고와 같이 발생된다. 위의 예에서 보는 것처럼 상호 연관되는 모니터링 정보의 각 부분을 정의해야 한다.

특정 시점에서 모니터링을 하는 것보다 중요한 것은 변화율을 모니터링 하는 것이다. 만일 보통 프로세서 사용량이 고정된 비율로 서서히 증가하는데, 갑자기 짧은 기간 동안에 사용 증가율이 급격히 커진다면, 데이터 수집과 분석 프로세스를 통해 자세히 살펴 보아야 한다. 이 것을 통해 감지된 변화는 예상되는 것 보다 더 빨리 리소스 부족 현상이 일어나는 것을 경고해주는 것이다. 이 경고를 통하여 예상하지 못한 문제를 피할 수 있다.

예외 관리

응용 프로그램을 모니터링 하는 다른 접근 방법은 "예외 관리"이다. 예외 관리는, 오직 정상 서비스에서 예외적인 경우만을 모니터링 하는 것이다. 예외는 성능 저하를 일으키는 하드웨어 실패에서부터 작업 실패에 이르는 것을 말한다. 시스템은 예외와 관련된 데이터만 수집하고 예외가 발생했을 때 만 경고한다. 가장 작은 시간을 투자하여 최대의 효과를 얻을 수 있다.

예외 관리는 모니터링 담당자가 모니터링 정보가 너무 많아 분석할 수 없다면, 도입을 고려해 볼 수 있다. 중앙 콘솔을 사용하는 엔터프라이즈 데이터 센터에서는 응용 프로그램 메시지 볼륨을 취급하지 못할 정도로 많을 것이다. 이런 경우, 콘솔로 보내진 메시지는 무시되거나 분석 요구일자 이 후에 취급되기 쉽다. 이런 상황은 오직 콘솔로 보내지는 메시지를 제한하는 방법만으로 해결할 수 있다. 최적화된 모니터링 시스템은 예외 관리와 더불어 이 문제를 인식할 수 있다.

예외 관리를 어렵게 하는 것은 응용 프로그램에서 발생될 수 있는 모든 문제에 대해 알아야 한다는 것이다. 만일 발견되는 문제의 상태를 모르고, 발생되는 문제의 추적 방법을 모르면, 시스템은 경고를 하지 못할 것이다.

예외 관리 방안

예외 관리 방안은 제한된 성능 모니터링, 적절한 경고, 폭 넓은 오류 로그 정보에 달려 있다. 이들 요소에 대한 자세한 사항은 다음 섹션에서 논의된다.

성능 모니터링

성능 모니터는 프로그램 상태를 알기 위한 도구로만 제공된다. 성능 모니터 데이터는 성능 로그 포맷으로 저장될 수 있다. 그러나 그래프 형태로 카운터를 보는 대신에, 빠른 결과 분석을 위해 확장자 .tsv,.csv로 저장하여 데이터를 가져 올 수 있다. 엑셀은 문제를 발생시키는 개별 값을 검색하고, 문제가 되는 값이 없다면, 저장하지 않고 엑셀 파일을 닫으면 된다.

모니터링 해야 하는 카운터는 다음과 같다.

경고

경고는 잘 알려져 있는 실패 상태를 위해서 설정한다. 각 작업 실패 시에도 경고를 해야 한다. 로그인 실패 또한 경고를 해야 한다. 경고는 데이터베이스에 접근할 수 있는 사용자의 수를 초과했을 때에도 발생되어야 한다.

SQL 서버 로그

시간이 많이 걸리는 예외 관리 요소 중의 하나는 SQL 서버 로그의 사용이다. SQL 서버 로그는 예상되거나 예상되지 않는 모든 오류를 추적한다. 예외관리 접근을 활용할 때는 모든 잘 알려진 문제의 상태에 대하여 숙지하는 것이 필요하기 때문에 SQL 로그에 나타나는 여러 메시지와 친숙해져야 한다. 오류를 어떻게 그룹화할까? 어떻게 평가할까? 오류와 실제 이벤트와 어떤 연관이 있을까? 각각의 오류와 관련하여 경고 설정 하였는가? 각 오류에 대한 해결책이 있는가?

SQL 서버로그에 나타나는 문제를 얼만큼 잘 해결하는가에 따라 예외 관리 접근법이 해당 시스템에 적합한지 아닌지를 판단할 수 있을 것이다. 로그가 충분한가? 오류가 발생된 이후에 오류에 대하여 정보를 수집하는 것이 용이한가? 문제를 해결할 수 있을 만큼 로그에 충분한 정보가 있는가? 문제 해결 프로세스를 시작함에 있어 무엇보다도SQL 서버 로그에 저장된 오류 메시지를 검토하는 것이 편하다면, 이 접근 방법을 고려해야 한다.

하드웨어 예외 관리

하드웨어 문제를 처리하기 위해 소비하는 시간은 다소 제한 되어야 한다. 직접 서버를 구축하지 않았다면, 하드웨어 유지관리는 해야 할 일이 아닐 것이다. 제한된 역할 때문에, 예외 관리 접근을 사용하여 하드웨어를 모니터링 하는 것이 가능하다. 하드웨어 문제가 발생된 후 대응 하면 된다. 이 방법은 하드웨어를 모니터링할 수 없을 때 유용한 방법이다.

하드웨어 예외에 대한 대응

하드웨어 모니터링 도구는 하드웨어 문제에 대해 제한적으로 사용할 수 있다. 하드웨어 모니터링의 목적은 특정 서버의 어느 부분에서 문제가 발생했는지 결정하는 것이다. 하드웨어 모니터링을 통하여 하드웨어 문제가 없다는 것을 확인했으면, 응용 프로그램 문제를 해결하도록 해야 한다.

사용할 도구는 다음과 같다.

로그 메시지와 부트 시간에 대하여 기록해야 할 중요한 것이 있다. 부팅 시간 후에 기록되는 모든 메시지는 부팅할 때 적용된다. 가동 시간 동안 표시 되는 하드웨어 문제를 항상 기록하도록 하자. 이렇게 하는 것은, 가동시간 동안 표시되는 하드웨어 증상과 관련된 로그 메시지를 연관 시킬 수 있다. 이 것은 종종 추적하는 것이 힘들 수 있다. 그러나 하드웨어 문제를 분리하기 위해서 중요하다.

종종, 하드웨어 문제를 해결하려고 할 때, 문제를 알아내기 위해 서버에 많은 변경을 주게 된다. 변화를 준 후에, 서버를 재 부팅 할 필요가 있을 것이다. 만약 변경 전후의 로그 메시지를 추적할 수 없다면 문제를 해결하기 힘들 것이다.

CPU와 메모리 제약 구별

하드웨어와 연관된 몇 가지 문제들은 사실 리소스 제약에 의해 발생된다. 가장 신경 써야 할 리소스는 CPU와 메모리이다. 만일 CPU 리소스가 완전히 사용되고 있다면, 성능을 만족시키기 위해 다른 요청은 기다려야 한다. 이 것은 메모리 사용과도 비슷하게 발생한다. 만일 하드웨어 사용을 요청하는 작업이 메모리 할당을 기다려야 한다면, 응용 프로그램의 성능을 위해 기다려야 하는 것보다도 더 오래 기다려야 한다. 항상 CPU와 메모리의 부하를 검사해야 한다.

만 CPU와 메모리 문제가 계속해서 나타난다면, 문제가 발생하기 전?태를 피하기 위한 좋은 계획과 관리를 제공할 수 있어야 한다. 항상 CPU와 메모리 리소스에 기반을 둔 작업 부하를 감시하자. 작업 부하의 좋은 표시자는 사용자수이다. 다른 좋은 표시자는 총 사용자 요청사항(request)수이다. 만일 사용자 수 또는 총 사용자 요청사항이 증가하기 시작했다면, 작업부하를 견딜 수 있는지 CPU와 메모리 용량을 검토해야 한다.

클러스터링 하드웨어

클러스터 데이터베이스 서버는 같은 데이터베이스에 접근하는 서버를 허용하기 위하여 공유 스토리지를 사용한다. 이 스토리지는 광(fiber) 스위치를 경유하여 대부분 사용된다.

만일 클러스터 서비스가 문제라면, 공유 디스크에 접근하는 것이 어려울 것이다. 문제 발생 시간 동안 광 스위치 또는 공유 디스크의 상태를 판단하는 것이 어려워 진다. 모니터링 담당자는 특정 클러스터 하드웨어에 대해 잘 알고 있어야 한다.

문제에 대한 대응

문제에 대해 모니터링 시스템에서 적절히 경고를 하게 될 것이다. 자 무엇을 할 수 있을까? 7장 "문제해결과 장애조치"에서처럼, 문제해결 프로세스를 시작만 할 수 있다. 사실, 이런 일련의 이벤트를 시작하는 경고는 단순히 증상이다. 실제 문제를 구별하기 전에 밟아야 할 많은 단계가 있을 수 있다.

더 상세한 문제해결 방법을 이해하려면 7장에서 간략히 제시된 응용 프로그램 문제의 고립화와 관리를 위한 방법론을 따라야 한다. 문제 상태를 자세히 조사하며 베이스라인 모니터링 방안의 한 부분이 되어야 하는 도구가 있다. 비록 모니터링 담당자가 발생하는 문제를 해결할 수 없더라도, 문제에 대해 좀 더 찾고, 추가적인 증상 데이터를 수집하고, 해결하도록 해야 하는 것은 중요하다.

도구

문제 분석 시에 사용되는 몇 가지 도구는 제일 먼저 응용 프로그램을 모니터링 하기 위해 사용되는 도구와 같다. 모니터링 작업을 할 때, 도구는 리포팅보다는 진단을 위해 더 많이 사용된다.

SQL 오류 로그와 SQL 에이전트 로그

전에 논의한 것처럼, SQL 오류 로그에는 많은 메시지들이 기록된다. SQL 에이전트 로그도 마찬가지이다. 문제 상태를 분석하려 할 때, 그런 메시지들은 문제해결에 방해가 될 수 있다. 문제 기록을 검토하기 위해서 날짜와 시간을 사용하자. 언제 SQL 서비스가 부팅되었는가? 부팅하는데 얼마의 시간이 소요되었는가? 복구되지 않은 데이터베이스가 있는가?

문제가 발생한 시간을 살펴보자. 로그에는 어떤 종류의 메시지가 있는가? 이벤트 뷰어 또는 다른 데이터 소스와 연관되는 로그에 특이한 점이 있는가? 로그 기록을 사용함에 의하여 문제의 원인을 찾고 분리해 낼 수 있다.

SQLDiag.exe

현재 사용자 정보, DLL버전, 환경구성 정보, 데이터베이스 사이즈 정보를 포함하여, SQL 서버의 현재 상태에 대한 정보를 얻기 위해서, SQLDiag.exe라는 유틸리티를 실행할 수 있다. 이 유틸리티의 디폴트 위치는 C:\Program Files\Microsoft SQL Server\Mssql\Binn\SQLDiag.exe이다. 유틸리티를 실행할 때, 다음 메시지는 커맨드 프롬프트 창에 나타난다.

파일 실행 후, 나중에 필요할 수도 있는 서버에 대한 자세한 모든 정보 파일을 서버에 남긴다. 만일 마이크로소프트 제품 지원 서비스(Microsoft Product Support Services)를 이용하게 된다면, 이 파일정보는 매우 유용하게 사용될 것이다.

만일 SQLDiag.exe를 한 번 이상 수행하고 실행 할 때마다 결과를 저장하고 싶다면, 각 수행 후에, QLDiag.txt의 이름을 변경한다. 그렇지 않으면, SQLDiag.txt의 내용은 실행파일을 실행할 때마다 덮어써질 것이다.

프로필러

프로필러는 문제 상태에 대한 자세한 정보를 수집하는데 있어 가장 좋은 도구이다. 7장에서는 프로필러 사용을 위한 단계가 설명되어 있다.

문제 상태를 분석하는 초기에 프로필러를 가지고 추적된 이벤트를 제한하는 것이 좋다. 프로필러는 좋은 도구인 반면에, 비용이 많이 요구된다. 프로필러를 문제가 발생하는 시점에 사용한다는 것은 시스템에 부하를 주기 때문에 주의가 필요하다.

프로필러 검사를 쉽게 하기 위하여 밟아야 할 단계가 있다. 첫째로, SQL 서버에서 직접 프로필러를 실행하자. 다음에, 이벤트 클래스 "오류와 경고"에서 발견되는 이벤트만 선택한다. 검사 시에 필요하다고 생각되는 한 개 혹은 두 개의 이벤트만 선택한다. 마지막으로, 프로필러를 실행하는 것이 문제 상태를 더 증대시키는지 아닌지를 결정하기 위하여 한 두 번 실행해 본다.

만일 프로필러가 사태를 악화시키지 않는다면, 같은 제한된 카운터 셋을 가진 좀 더 긴 추적을 해보자. 항상 SQL 서버에서 직접 수행하자. 만일 이 추적이 SQL 서버 수행을 방해하지 않는다면, 7장에서 추천되는 이벤트를 서서히 추가하는 것을 고려하자.

현재 동작

모니터링에서 사용해야 하는 다른 유용한 도구는 엔터프라이즈 관리자에서 볼 수 있는, 관리 > 현재 동작 창이다. 이 도구는 문제 발생시에 유용하게 사?, 사용자 활동, 프로세스에 의한 잠금, 개체에 의한 잠금에 관한 스냅샷 정보를 보여준다. 스냅샷만 제공하는 창을 기록하는 것은 중요하다. 만일 서버의 진행 상태에 관심이 있다면, 주기적으로 스냅샷을 새로 고침(refresh) 해야 한다.

블로킹되고 블로킹하는 트랜잭션을 모니터링 하기 위해서 현재동작 창을 사용할 수 있다. 그리고 현재 연결된 사용자와 마지막 실행 문을 볼 수 있다. 데이터베이스 개체에 의한 모든 잠금을 볼 수 있다. 선택된 프로세스를 끝낼 수 있거나 문제가 있는 트랜잭션을 실행하는 사용자에게 메시지를 보낼 수도 있다. 프로세스를 끝내기로 결정하였다면, 롤백이 발생할 수 있다는 것을 명심하자. 프로세스를 끝내는 능력을 남용하지 말자.

다음 값은 각 프로세스를 위해 현재 활동 창에서 발견될 수 있다(값은 윈도우가 처음 열릴 때나 다음에 새로 고치기를 할 때 샘플링 된다).

SP_WHO

엔터프라이즈 관리자가 SQL 서버에 접속할 수 없고 쿼리분석기 세션이 접속 가능한 경우가 있을 수 있다. 이런 경우에, SP_WHO를 이용하여 현재 연결 수와 연결 상세정보에 대한 정보를 알 수 있다.

요약

이 장에서 간략히 제시된 모니터링 시스템 개발 프로세스를 가지고 처음부터 끝까지 따라 해보는 것은 중요하다. 시스템이 갑자기 중단되어 모니터링 시스템의 귀중함을 알게 될 때까지 모니터링에 대한 필요성을 못 느끼는 것은 쉽다. 첫째로, 모든 응용 프로그램 구성요소를 확실히 문서화하자. 요구사항을 만족시키는 데에 가장 잘 맞는 모니터링 기술을 선택하자. 그런 다음 근무 환경에 적용할 엄격한 관리방안을 만들자. 마지막으로, 관리방안을 적용하고 성공을 하도록 힘쓰자.

모니터링 방식과 관계없이, 다양한 방법으로 응용 프로그램의 상태를 볼 수 있도록 하자. 하나의 도구가 중요한 이상 증후를 놓칠 수 있는 반면 다른 하나는 그 것을 잡을 수 있을 것이다. 응용 프로그램의 상태를 결정하기 위해 모든 도구를 사용하자. 비록 응용 프로그램의 상태가 완전해 보일 지라도, 사용자수, CPU사용률, 디스크 접근과 관련되어 있는 모든 점을 상세하게 점검하자. 데이터의 계속적인 분석은 아주 중요하다. 문제에 대한 증상을 계속 주시하자. 만일 미리 문제에 대한 증상을 발견했다면, 심각한 문제가 발생하는 것을 방지할 수가 있을 것이다.