SQL 프로파일러는 문제를 해결합니다.

SQL Server 2005 프로파일러, 애플리케이션 요청 추적, 추적 템플릿, 요청 정보 그룹화

사용자 활동을 모니터링하는 가장 유용한 수단 중 하나는 프로파일러 (프로파일러). 이 도구를 사용하면 SQL Server가 현재 실행 중인 명령을 찾을 수 있습니다. 프로파일러를 사용해야 하는 경우가 매우 자주 발생합니다. 다음은 그것 없이는 매우 어려울 수 있는 몇 가지 표준 상황입니다.

● 응용 프로그램을 분석하고 서버에서 실행하는 명령을 확인하려고 합니다. 다음 정보가 유용할 수 있습니다.

· 특정 작업을 수행할 때 이 응용 프로그램이 작동하는 데이터베이스의 테이블을 이해합니다. 기업에서는 애플리케이션에서 제공하지 않는 형식으로 보고서를 생성해야 하는 경우가 매우 많으며 개발자는 데이터베이스 구조에 대한 자세한 정보를 거의 제공하지 않습니다.

· 요청이 애플리케이션에 의해 서버로 전송되는 성능 면에서 얼마나 최적인지 알아내기 위해. 실제로 프로파일러를 사용할 때 예를 들어 클라이언트에서 데이터 필터링 또는 정렬이 수행되는 경우와 같이 완전히 차선의 쿼리를 식별하는 것이 종종 가능합니다.

· 서버의 응용 프로그램에서 어떤 Transact -SQL 명령이 오류를 생성하는지 이해합니다.

q 장기간에 걸친 사용자 활동에 대한 정보를 수집합니다(예: 근무일 동안 특정 애플리케이션에서 서버로 보낸 모든 요청을 수집할 수 있음). 그런 다음 수집된 정보를 수동으로 분석하거나 자동화된 분석을 위해 Database Tuning Advisor에 전달할 수 있습니다.

q 실시간으로 서버 작동을 모니터링합니다. 예를 들어, 서버가 갑자기 느려지면 프로파일러 창에서 현재 실행 중인 명령을 볼 수 있습니다.

프로파일러에는 SQL Server 2005의 많은 새로운 기능이 있습니다.

● Integration Services 이벤트 프로파일링이 추가되었습니다. 이제 프로파일러를 사용하여 새 DTS 패키지의 진행 상황을 모니터링할 수 있습니다.

● 명령 실행에 대한 정보를 기록할 때 시스템 모니터에서 카운터 판독값을 기록할 수 있게 되었습니다.

● 추적 파일에 기록하도록 선택할 수 있는 많은 새로운 이벤트 및 정보 소스가 프로파일러에 추가되었습니다. 이제 추적 파일에 쓸 내용의 정의를 XML 형식으로 저장할 수 있습니다.

● 이제 추적 결과를 XML 형식으로 저장할 수 있습니다(ANSI, OEM, UNICODE 형식으로 쓰는 기능도 저장됨).

● 프로파일러에서 캡처한 Transact -SQL 명령에 대한 실행 계획을 XML 형식으로 저장할 수도 있습니다. 이러한 계획은 추가 분석을 위해 SQL Server Management Studio에서 열 수 있습니다.

q 프로파일러 창에서 직접 이벤트를 그룹화할 수 있게 되었습니다. 예를 들어 그룹화를 사용하면 하루 동안 특정 Transact -SQL 명령이 서버에서 실행된 횟수를 매우 쉽게 계산할 수 있습니다.

프로파일러로 작업하는 것은 매우 간단해 보입니다. 이 응용 프로그램은 메뉴에서 시작할 수 있습니다 시작| 프로그램들| 마이크로소프트 SQL 서버 2005 | 성능 도구 | SQL 서버 프로파일러 . 시작하려면 열리는 프로파일러 창의 메뉴에서 파일(파일)을 선택해야 합니다. 새로운추적하다(새 추적)을 클릭하고 모니터링하려는 SQL Server 2005 서버에 연결합니다. "추적"이라는 단어는 SQL Server 2005의 작동에 대한 정보를 수집하는 세션을 의미합니다. 그러나 정보 수집을 시작하기 전에 이 세션에 대한 설정을 구성해야 합니다. 이 설정은 창에서 추적하다속성(추적 속성), 추적 세션을 시작하기 전에 자동으로 열립니다(그림 11.1).

쌀. 11.1.추적 세션 옵션 설정

탭에서 일반적인(일반) 목록에서 사용그만큼주형(템플릿 사용) 세션 내 정보 수집에 가장 적합한 템플릿을 선택할 수 있습니다. 원칙적으로 템플릿 설정에주의를 기울일 수는 없지만 정보 수집을위한 매개 변수를 수동으로 정의합니다 (인접 탭 사용 이벤트선택(이벤트 선택)). 그러나 올바른 템플릿을 지정하면 시간을 절약하고 실수를 방지할 수 있습니다. 따라서 템플릿에 대해 더 자세히 설명합니다.

템플릿은 확장자가 있는 특수 파일에 저장됩니다. PDF추적 세션 설정. 템플릿 작업(새 템플릿 추가, 기존 템플릿 변경, 보고서를 다른 디렉토리로 가져오기 및 내보내기)은 메뉴를 사용하여 수행됩니다. 파일| 템플릿(파일| 템플릿) SQL Server 프로파일러 . 처음에는 8개의 템플릿을 마음대로 사용할 수 있습니다.

기준 (기본)- 이름에서 알 수 있듯이 이 템플릿은 대부분의 상황에 적합하므로 기본적으로 선택됩니다. 실행되는 모든 저장 프로시저 및 Transact -SQL 명령을 추적할 수 있습니다.

SP_카운트- 실행을 위해 시작된 저장 프로시저 및 기능에 대한 정보가 수집됩니다. 동시에 프로파일러 창의 정보는 저장 프로시저 이름별로 정렬됩니다(프로파일러 용어로 그룹화됨).

TSQL- 서버에서 실행되는 모든 Transact -SQL 명령에 대한 정보를 수집합니다. 명령 코드 외에도 사용자 프로세스의 식별자 및 시작 시간에 대한 정보도 기록됩니다. 일반적으로 이 패턴은 응용 프로그램에서 서버로 보낸 명령을 모니터링하는 데 사용됩니다.

TSQL_지속- 이전 템플릿과 거의 동일하지만 Transact -SQL 명령이 실행된 시점에 대한 정보를 기록하는 대신 실행하는 데 걸린 시간을 기록합니다. 일반적으로 이 템플릿은 서버 성능을 "수동으로" 모니터링하는 데 사용됩니다.

TSQL_그룹화- Transact -SQL 명령의 코드 및 실행 시간에 대한 정보 외에도 응용 프로그램 이름, 운영 체제의 사용자 계정 및 연결에 사용된 사용자 로그인에 대한 정보가 기록됩니다. 기록은 로그인별로 그룹화됩니다. 일반적으로 이 패턴은 특정 애플리케이션의 활동을 추적하려는 상황에서 사용됩니다.

TSQL_다시 하다- 실행된 Transact -SQL 명령에 대한 가장 자세한 정보가 기록됩니다. 그런 다음 이 정보를 사용하여 최대 정확도로 서버의 부하를 재현할 수 있습니다. 일반적으로 이 템플릿은 성능 측면에서 다양한 서버 설정을 테스트하는 데 사용할 명령 집합을 작성하는 데 사용됩니다.

TSQL_SP- 전체 저장 프로시저(이벤트 SP: 시작 중), 이 추적 옵션은 이 저장 프로시저의 각 명령 실행에 대한 정보도 기록합니다(이벤트 SP:Stmt시작). 이 패턴은 일반적으로 복잡한 저장 프로시저의 작업을 모니터링하는 데 사용됩니다.

동조- 이 템플릿은 Database Tuning Advisor의 전송에 가장 적합한 정보를 기록하기 위한 것입니다. 자동화된 분석 및 성능 최적화를 위해 이 도구로 작업하는 방법은 다음에서 설명합니다. 비서. 11.5.5.

이미 언급했듯이 기성 템플릿 집합으로 제한될 필요는 전혀 없습니다. 탭에서 구성하여 고유한 추적 세션 설정을 사용할 수 있습니다. 이벤트선택. 이 탭의 테이블에서 필요한 이벤트(행)와 이에 대해 기록될 정보(열)를 선택해야 합니다. 기본적으로 사용 가능한 행과 열의 일부만 표시됩니다. 모든 행과 열을 표시하려면 확인란을 선택해야 합니다. 보여 주다모두이벤트(모든 이벤트 표시) 및 보여 주다모두기둥(모든 열 표시).

특정 데이터베이스, 특정 응용 프로그램 또는 특정 사용자가 수행한 작업만 추적하거나 이러한 조건을 모두 동시에 선택하려는 경우가 많습니다. 버튼을 클릭하여 정보 수집용 필터를 구성할 수 있습니다. 필터(열 필터) 탭 이벤트선택. 각 열은 특정 값만 기록하도록 구성할 수 있습니다( 처럼) 또는 특정 값이 기록되는 것을 방지( 같지 않은). 기본적으로 하나의 필터만 구성됩니다. 같지 않은컬럼용 애플리케이션 이름. 이로 인해 모든 SQL Server 프로파일러 이벤트, 즉 추적 수집 프로세스 자체와 관련된 모든 이벤트가 무시됩니다. 이 필터를 제거하지 않는 것이 좋습니다. 그렇지 않으면 정보가 끝없이 기록되어 긍정적인 피드백이 발생할 수 있기 때문입니다.

다른 버튼으로 구성기둥탭에 있는 (열 구성) 이벤트선택, 프로파일러에 표시하거나 기록할 열의 순서를 사용자 지정할 수 있습니다. 섹션에주의하십시오 그룹(그룹)이 목록에 있습니다. 그 안에 배치된 열에 대해 그룹화가 자동으로 수행됩니다. 이 섹션에 하나의 열만 넣으면 볼 때 매우 편리한 모드를 사용할 수 있습니다. 집계보다(통합 보기) (데이터베이스, 애플리케이션, 사용자 이름 등으로 정보가 자동으로 그룹화되고 원하는 데이터베이스, 애플리케이션 또는 사용자에 대한 레코드를 확장 및 축소할 수 있는 경우).

원하는 템플릿을 선택하거나 로깅을 위해 고유한 이벤트 세트를 설정한 후에는 탭으로 돌아가기만 하면 됩니다. 일반적인몇 가지 고급 추적 세션 옵션을 구성합니다.

추적 정보를 파일에 기록할 수 있습니다. 이 파일은 다양한 상황에서 사용할 수 있습니다.

q 정보의 소스로 전달될 수 있습니다. 데이터베이스 튜닝 어드바이저;

● 프로파일러에서 다시 "재생"하여 기록된 모든 명령을 반복할 수 있습니다(예: 다른 서버 설정으로 성능 평가).

q는 응용 프로그램에 대한 주장을 뒷받침하기 위해 개발자에게 제시될 수 있습니다.

추적 세션을 파일에 기록하는 것과 관련된 몇 가지 사항을 살펴보겠습니다.

● 기본 파일 크기 제한인 5MB는 매우 작습니다. 프로덕션 서버를 프로파일링할 때 이 크기는 몇 분 안에 확보됩니다. 사실, 체크박스는 기본적으로 선택되어 있습니다. ~ 할 수있게하다파일롤오버(파일 변경 활성화), 즉, 하나의 파일을 채우면 두 번째 파일이 자동으로 생성되며 이름에 숫자 1이 추가된 다음 -2 등이 추가되지만 많은 수의 파일로 작업하는 것은 그렇지 않습니다. 항상 편리합니다. Database Tuning Advisor에 보낼 정보를 수집하는 경우 파일 크기 제한을 1GB로 설정하는 것이 가장 좋습니다( 세트최고파일크기(최대 파일 크기 설정) 탭 일반적인). 추적은 관리자의 워크스테이션에서 가장 자주 파일에 기록되므로 서버가 아닌 워크스테이션에 디스크 공간이 필요합니다.

q 매개변수 섬기는 사람프로세스추적하다데이터(서버가 추적 데이터를 처리하고 있음) 추적 정보 기록의 신뢰성을 높이는 데 사용할 수 있습니다. 기본적으로 SQL Server 프로파일러는 추적 데이터를 처리하며 실행 중인 시스템(서버일 필요는 없음)에서 수행합니다. 이 확인란을 선택하면 서버가 추적 정보 처리를 처리합니다. 이렇게 하면 모든 추적 정보가 수집되지만(확인란을 선택 취소하면 서버 사용량이 많은 시간에 일부 정보가 누락될 수 있음) 서버의 로드가 증가합니다.

추적 정보를 쓰기 위한 또 다른 옵션은 SQL Server 테이블에 쓰는 것입니다. 원하는 열 집합이 있는 테이블이 자동으로 생성됩니다. 이 테이블의 최대 항목 수만 조정할 수 있습니다. 이 탭에는 최대 항목 수가 천 단위로 표시됩니다.

탭의 마지막 옵션 일반적인- ~ 할 수있게하다추적하다멈추다시각(추적 정지 시간 활성화). 추적이 자동으로 비활성화되는 시간을 지정할 수 있습니다. 일반적으로 로깅 관점(백업, 대량 데이터 로드, OLAP 큐브 처리 등)에서 관심이 없는 일부 하우스키핑 작업을 시작하기 전에 추적을 끄는 것이 좋습니다.

모든 추적 매개변수를 구성한 후 버튼을 클릭할 수 있습니다. 달리다(실행) 탭 일반적인추적을 시작합니다(그림 11.2).

쌀. 11.2.추적 세션 중 정보 보기

Trace Information Viewer의 작동은 매우 간단합니다. 상단 섹션은 서버에서 발생하는 이벤트를 보여주고 하단 섹션은 자세한 정보(예: SQL 명령 코드)를 제공합니다. 다음은 이 창에서 사용할 수 있는 몇 가지 옵션입니다.

q if 탭 구성기둥그룹화를 위해 열을 선택한 템플릿 속성에서 보기 창에서 이러한 열을 기준으로 레코드를 그룹화할 수 있습니다. 이를 위해 메뉴 보다(보기) 명령 제공 그룹화보다(그룹화 보기);

q 목록의 템플릿 속성에서 동일한 탭에 있는 경우 그룹하나의 열만 배치되었으므로 더욱 편리한 표시 모드를 사용할 수 있습니다. 집계보다(그림 11.3). 이 모드는 명령으로 활성화됩니다. 집계보다같은 메뉴에서 보다그리고 선택한 열의 값을 축소 및 확장할 수 있는 트리 노드로 전환할 수 있습니다. 또한 이러한 각 노드에 대해 이벤트 수가 자동으로 계산됩니다.

쌀. 11.3.디스플레이 모드 집계보다

● 프로파일러에서는 방금 포착된 이벤트뿐만 아니라 저장된 파일 및 추적 테이블도 표시할 수 있습니다. 또한 Transact -SQL 명령을 사용하여 일반 SQL Server 스크립트를 열 수 있습니다. 이러한 파일 또는 테이블의 정보는 기록된 작업을 재생하는 데 사용할 수 있습니다. 메뉴 명령은 이를 위한 것입니다. 다시 하다(반복하다);

● SQL Server 2005 프로파일러에는 추적 정보를 성능 모니터 성능 카운터에 연결하는 새로운 기능이 도입되었습니다. 이 기회를 활용하려면 다음이 필요합니다.

열에 대한 정보를 기록해야 하는 동안 추적 세션을 정의합니다. 시작 시간그리고 종료 시간;

· 파일이나 테이블에 기록된 정보로 추적 세션을 시작합니다. 이와 동시에 성능 모니터의 검침 로그를 파일로 수집합니다.

프로파일러의 추적 파일에서 수집된 정보를 연 다음 다음 명령을 사용합니다. 수입성능데이터메뉴에서 (성능 데이터 가져오기) 파일.

SQL Server 2005는 프로파일러를 대체합니다. 추적 저장 프로시저입니다. 기능은 프로파일러와 거의 동일합니다. 예를 들어, 추적할 이벤트를 선택하고 텍스트 파일에 쓸 수도 있습니다. 주요 차이점은 모든 설정이 Transact -SQL 코드에서 수행되어야 한다는 것입니다.

추적 저장 프로시저로 작업하는 것은 프로파일러보다 어렵고 편리하지 않으며 추가 기능을 제공하지 않습니다. 따라서 우리는 그것들을 자세히 고려하지 않을 것입니다. 간단한 설명과 함께 이러한 저장 프로시저 목록만 제공합니다.

sp_trace_create- 추적 세션의 매개변수를 구성할 수 있습니다.

sp_trace_setevent- 생성된 추적 세션에 필요한 이벤트를 선택할 수 있습니다.

sp_trace_setfilter- 추적 정보를 수집하도록 필터를 구성할 수 있습니다.

sp_trace_setstatus- 추적을 시작하거나 중지하거나 생성된 저장 프로시저를 삭제할 수 있습니다. sp_trace_create현재 세션 정의;

sp_trace_generateevent- 추적 중에 가로챌 사용자 지정 이벤트를 생성할 수 있습니다.

SQL Server Profiler 소프트웨어 제품은 추적을 생성하고 추적 결과를 분석하도록 설계된 그래픽 셸입니다. 이벤트는 추적 파일에 저장되며, 이 파일은 발생한 문제를 식별하기 위해 특정 단계 시퀀스를 재생하거나 분석하는 데 사용할 수 있습니다.

현재 실행 중인 작업을 추적하려면 MS SQL 프로파일러를 실행하고 새 추적을 만들고 지표 분석을 구성해야 합니다.

"일반" 탭에서 추적 이름을 지정해야 합니다. 캡처된 추적 데이터가 파일 및/또는 데이터베이스 테이블에 저장될 위치를 지정합니다.

큰 관심은 "이벤트 선택"탭입니다.

이 페이지는 모니터링해야 하는 이벤트를 나열합니다. 이 예에서는 쿼리 계획을 추적하는 데 필요한 데이터를 지정합니다.

267개의 1C 비디오 강의를 무료로 받으십시오:

기본적으로 추적은 모든 데이터베이스에서 지정된 모든 이벤트를 통해 실행됩니다. 수신된 데이터에 필터를 적용하려면 "열 필터 ..." 버튼을 클릭해야 합니다.

예를 들어 정보 베이스 ID로 선택을 설정해 보겠습니다(SELECT DB_ID(N'BaseName') 쿼리를 사용하여 데이터베이스 ID를 찾을 수 있음).

1C용 프로파일러에서 추적 시작

모든 설정이 끝나면 추적을 시작해야 하므로 "실행"(RUN)을 클릭해야 합니다. 이 순간부터 필터에 지정된 모든 작업이 추적되기 시작합니다.

예를 들어, 가장 노동 집약적인 작업을 추적하기 위해 "상품 및 서비스 수령" 문서 기간 동안 경로를 실행합니다.

추적을 수신한 후 분석해야 합니다.

프로파일러에서 데이터 분석

분석을 위해 결과 추적을 파일이나 테이블에 저장할 수 있습니다. 우리는 데이터베이스 테이블에 저장할 것입니다:

이 강의에서는 "저장 프로시저 생성 및 관리"에서 시작한 저장 프로시저에 대한 연구를 계속할 것입니다. Microsoft SQL Server 쿼리 분석기와 SQL Server 프로파일러를 사용하여 저장 프로시저 및 기타 T-SQL 문을 구문 분석하는 방법을 배웁니다. 이 분석을 통해 T-SQL 문이 얼마나 효율적인지 결정할 수 있습니다. 효율적인 SQL Server 쿼리는 올바른 작업 순서와 올바른 인덱스를 사용하여 행 처리를 줄이고 I/O를 최소화합니다.

쿼리 분석기를 사용하여 T-SQL 문에 대해 선택된 실행 계획을 볼 수 있습니다. 쿼리 옵티마이저 SQL 서버. 쿼리 옵티마이저각 T-SQL 문에 대한 최상의 실행 계획을 찾는 내부 모듈입니다. 쿼리 옵티마이저각 T-SQL 문을 구문 분석하고 가능한 여러 실행 계획을 살펴보고 필요한 리소스 및 처리 시간 측면에서 각 계획의 "비용"을 평가합니다. 비용이 가장 저렴한 플랜이 선택됩니다. 각 계획의 비용은 시스템에서 수집하고 최신 정보가 아닐 수 있는 사용 가능한 통계를 기반으로 결정됩니다. 당신이 당신의 데이터베이스와 데이터에 대해 더 많이 알고 있을 수 있기 때문에 쿼리 옵티마이저, 그러면 쿼리 최적화 프로그램보다 더 나은 계획을 만들 수 있습니다. 쿼리 분석기에서 제공하는 정보를 사용하여 특정 명령문에 대한 쿼리 최적화 프로그램 계획이 효율적인지 결정할 수 있으며, 그렇지 않은 경우 수정하거나 SQL 힌트를 사용하여 해당 명령문을 최적화할 수 있습니다. 이 강의에서는 쿼리 분석기 사용법과 함께 T-SQL 구문을 최적화하는 방법을 배우게 됩니다.

프로파일러를 사용하면 SQL Server 시스템 내의 작업을 분석하여 불필요한 시스템 리소스를 사용하는 SQL 문과 저장 프로시저를 확인할 수 있습니다. 이 정보를 사용하여 먼저 이러한 명령문 및 저장 프로시저에 대한 조정 노력을 집중할 수 있습니다. 프로파일러를 사용하는 방법을 설명하는 것 외에도 이 장에서는 프로파일러에서 얻은 정보를 최대한 활용하는 방법도 보여줍니다.

SQL 쿼리 분석기 사용

쿼리 분석기 유틸리티는 대신 Microsoft SQL Server 2000과 함께 제공됩니다.

우리 작업에서 우리는 특정 쿼리가 느리게 실행되고 쿼리 텍스트에 명백한 문제가 보이지 않는 상황을 자주 접합니다. 일반적으로 이 경우 더 깊은 수준에서 문제를 조사해야 합니다. 일반적으로 SQL 쿼리의 텍스트와 해당 계획을 살펴보는 것이 필요하며 SQLProfiler가 도움이 되는 곳입니다.

SQL 프로파일러란 무엇이며 왜 필요한가요?

SQLProfiler는 MS SQL Server와 함께 제공되는 프로그램으로, SQL Server에서 발생하는 모든 이벤트를 조회하거나 추적을 기록하도록 설계되었습니다. 1C 프로그래머에게 SQLProfiler가 필요한 이유는 무엇입니까? 적어도 SQL에서 쿼리 텍스트를 얻고 계획을 보려면. 물론 이것은 기술 잡지의 도움으로 할 수도 있지만 약간의 기술이 필요하고 TJ의 계획은 그렇게 아름답고 읽기 쉽지 않습니다. 프로파일러에서는 텍스트뿐만 아니라 그래픽 쿼리 실행 계획도 볼 수 있습니다. 제 생각에는 훨씬 더 편리합니다. 또한 프로파일러를 사용하여 다음을 결정할 수 있습니다. 특정 시간보다 긴 요청 잠금 교착 상태 시간 초과 시 특정 대기 테이블에 대한 요청 등 ...

SQL 프로파일러를 사용한 쿼리 분석

대부분의 경우 프로파일러는 특히 쿼리 분석에 사용됩니다. 일반적으로 모든 쿼리를 추적할 필요는 없으며 1C 언어의 특정 쿼리가 SQL로 변환되는 방식과 실행 계획을 확인해야 하는 경우가 많습니다. 예를 들어, 쿼리가 느리게 실행되는 이유를 확인하거나 대규모 쿼리를 작성했으며 SQL 쿼리 텍스트에 하위 쿼리 조인이 포함되어 있지 않은지 확인하기 위해 필요할 수 있습니다. 추적에서 요청을 포착하려면 다음을 수행하십시오.

1. SQL 프로파일러 실행 시작 - 모든 프로그램 - Microsoft SQL Server 2008 R2 - 성능 도구 - SQLProfiler
2. 새 트레이스 파일 생성 - 트레이스 생성(Ctrl+N)
3. 데이터베이스가 위치한 DBMS 서버를 지정하고 "연결"을 클릭합니다.

당연히 다른 컴퓨터에 있는 DBMS 서버를 추적하는 것을 막을 수는 없습니다. 4. "속성 추적" 창이 나타나면 두 번째 탭인 "이벤트 선택"으로 이동합니다.

5. 이제 추적에서 보려는 이벤트와 이러한 이벤트의 속성을 지정해야 합니다. 쿼리와 쿼리 계획이 필요하므로 적절한 이벤트를 활성화해야 합니다. 속성 및 이벤트의 전체 목록을 표시하려면 "모든 열 표시" 및 "모든 이벤트 표시" 플래그를 활성화하십시오. 다음으로 아래 그림과 같은 이벤트만 선택하고 다른 모든 이벤트는 비활성화해야 합니다.


이벤트 설명: ShowplanStatisticsProfile - 텍스트 쿼리 실행 계획.
ShowplanXMLStatisticsProfile - 그래픽 쿼리 실행 계획입니다.
RPC:Completed - 요청 텍스트, 프로시저로 실행되는 경우(1C 요청이 매개변수와 함께 실행되는 경우).
SQL:BatchCompleted - 일반 쿼리로 실행되는 경우 쿼리 텍스트입니다(1C 쿼리가 매개변수 없이 실행된 경우).

6. 이제 이벤트에 대한 필터를 구성해야 합니다. 이것이 완료되지 않으면 이 DBMS 서버에 있는 모든 데이터베이스에 대한 쿼리가 표시됩니다. "열 필터" 버튼을 클릭하고 데이터베이스 이름으로 필터를 지정합니다.

이제 추적에서 "TestBase_8_2" 데이터베이스에 대한 요청만 볼 수 있습니다. 원하는 경우 다른 필드에 필터를 적용할 수 있습니다. RowCounts(요청에 의해 반환된 행 수).

예를 들어 "TestBase_8_2" 데이터베이스에서 3초 이상 지속되는 "_InfoRg4312" 테이블에 대한 모든 요청을 포착해야 하는 경우 다음을 수행합니다.
a) 데이터베이스별로 필터링(위에 표시된 예)
b) 기간(밀리초)으로 필터링합니다.

C) 요청 텍스트로 필터링


여기서 마스크를 지정합니다. 여러 테이블에 액세스하는 쿼리를 추적해야 하는 경우 "모양" 섹션에서 여러 항목을 만듭니다. 모든 필터의 조건은 함께 작동합니다.

7. 이제 추적을 시작할 수 있습니다. 추적 작업이 시작된 후 "시작"을 클릭하면 표시하도록 구성하고 필터에 해당하는 이벤트를 볼 수 있습니다. 명령 모음의 버튼을 사용하여 추적을 제어할 수 있습니다.


왼쪽에서 오른쪽으로: 지우개 - 추적 창 지우기, 시작 - 추적 시작, 일시 중지 - 추적 일시 중지, 시작을 누르면 추적 재개, 중지 - 추적 중지

8. 추적 창 자체는 두 부분으로 구성됩니다. 이벤트 및 이벤트 속성은 상단에 있습니다. 하단에는 이벤트의 종류에 따라 다른 정보가 표시됩니다. 우리의 경우 요청 텍스트 또는 계획이 여기에 표시됩니다.

9. 1C 쿼리 콘솔에서 쿼리를 실행하고 프로파일러에 어떻게 반영되는지 확인합니다.


추적은 여러 요청이 있었고 그 중 하나만 우리의 요청임을 보여줍니다. 나머지 요청은 서비스입니다.

10. 이벤트 속성을 통해 쿼리가 실행된 시간(초), 논리적 읽기(읽기) 수, 쿼리 결과로 반환된 행 수(RowCounts) 등을 이해할 수 있습니다. 필자의 경우 쿼리는 2밀리초가 걸리고 4개의 논리적 읽기를 수행하고 1개의 행을 반환했습니다.

11. 하나의 이벤트 위로 올라가면 쿼리 계획을 그래픽으로 볼 수 있습니다.
계획에서 알 수 있듯이 이 계획은 이상적이라고 할 수 없지만 가격별 인덱스로 검색이 수행됩니다. 인덱스가 포함되지 않는 경우 코드 및 이름 필드는 시간의 50%가 소요되는 KeyLookup을 사용하여 가져옵니다.


컨텍스트 메뉴를 사용하여 그래픽 계획을 별도의 *.SQLPlan 파일에 저장하고 다른 컴퓨터의 프로파일러에서 열거나 고급 SQL Sentry Plan Explorer 프로그램을 사용할 수 있습니다.

12. 더 높이 올라가면 동일한 쿼리 계획을 볼 수 있지만 텍스트 형식입니다. TJ, TsUP 및 기타 1C 성능 제어에 표시되는 것은 이 계획입니다. 이를 분석하려면 메모장++과 같은 강조 표시가 있는 고급 텍스트 편집기를 사용하는 것이 좋습니다.

13. "파일-다른 이름으로 저장" 메뉴를 사용하여 전체 추적을 다양한 형식으로 저장할 수 있습니다.
a) 프로파일러 자체의 형식, 즉 *.trc 확장자 포함
b) xml 형식으로
c) 추적에서 템플릿을 만들 수 있습니다. 다음 단락을 참조하십시오.
d) 추적을 데이터베이스 테이블로 저장할 수 있습니다. 예를 들어 전체 추적에서 가장 느린 요청을 찾거나 일부 매개변수로 요청을 선택해야 하는 경우 편리한 방법입니다. 파일 - 다른 이름으로 저장 - 추적 테이블 - DBMS 서버를 선택하고 연결합니다. 다음으로 지정된 서버에서 데이터베이스를 선택하고 추적을 저장할 테이블의 이름을 지정해야 합니다. 기존 테이블을 선택하거나 새 이름을 쓰면 선택한 데이터베이스에 테이블이 자동으로 생성됩니다.

이 경우 Duration이 100만분의 1초 단위로 테이블에 저장된다는 점을 고려해야 하며, 결과를 표시할 때 값을 밀리초 단위로 변환하는 것이 바람직하다. RowNumber 열은 추적에서 지정된 행의 번호를 표시하는 테이블에도 추가됩니다.

14. 프로파일러를 사용하여 요청을 분석해야 하는 경우가 많으면 필요한 필터 및 이벤트를 설정하는 것이 금방 지루해지고 시간도 많이 걸립니다. 추적 템플릿은 필요한 필터와 열의 순서를 지정한 다음 새 추적을 만들 때 이 템플릿을 선택하기만 하면 됩니다. 템플릿을 만들려면 파일 - 템플릿 - 새 템플릿 메뉴를 사용하십시오.

첫 번째 탭에서는 모든 것이 간단합니다. 서버 유형, 템플릿 이름을 지정하고 필요한 경우 기본적으로 이 템플릿을 사용하도록 플래그를 설정합니다. 두 번째 탭에서는 이미 위에 표시된 대로 이벤트를 선택하고 필터를 설정합니다. 또한 추적에서 열의 순서를 조정하는 것이 좋습니다. 이렇게 하면 쿼리를 분석할 때 시간이 절약됩니다. 예를 들어 다음 순서를 사용하는 것이 더 편리합니다.

이제 새 추적을 만들 때 필요한 템플릿을 지정하기만 하면 됩니다. 그런 다음 두 번째 탭에서 모든 필터와 이벤트가 자동으로 채워집니다.

물론이 멋진 도구를 사용하는 모든 방법이 여기에 나와 있지는 않지만 청중의 관심이 있다면 앞으로이 주제에 대한 기사 모음을 보충하는 것이 가능할 것입니다.

2000년 5월 16일 Itzik Ben-Gan

범죄 현장을 재구성하면 가해자를 찾는 데 도움이 되는 것처럼 데이터베이스 작업을 추적하면 병목 현상을 식별하고 제거할 수 있습니다.

블로그 이전 호의 "Catch the Event" 기사에서는 SQL Server 7.0 추적 시스템의 아키텍처를 설명하고 SQL 프로필러에서 추적을 그래픽으로 정의하는 방법을 보여주었습니다. 이번에는 SQL Profiler를 사용하여 추적을 재생성하는 방법과 확장 추적 저장 프로시저를 통해 자동 시작을 정의하는 방법에 대해 설명합니다. 이러한 강력한 기반을 바탕으로 장기 실행 쿼리에서 복잡한 교착 상태에 이르기까지 다양한 조사에 SQL 프로파일러 및 저장 프로시저를 전문적으로 사용할 수 있습니다.

트랙 재생을 위한 사전 준비

SQL 프로파일러를 사용하면 저장된 추적을 다시 추적하여 문제가 있는 응용 프로그램을 디버그하고, 테스트 사례에 대한 실제 시나리오를 만들고, 데이터베이스를 조정하는 등의 작업을 수행할 수 있습니다. 트랙을 다시 걸으려면 몇 가지 준비 작업을 해야 합니다. 우선, 관심이 있는 것 이외의 특정 이벤트 및 데이터 열을 추적하기 위해 추적을 정의해야 합니다. 이러한 추가 이벤트 및 열을 수정하면 모든 작업이 이전에 발생한 것과 똑같이 반복됩니다. 둘째, 추적 결과를 파일, 테이블 또는 SQL 스크립트에 저장해야 합니다.

모든 재실행은 Connect, Disconnect, ExistingConnection 및 RPC:Starting 및 SQL:BatchStarting 이벤트를 캡처해야 합니다. 또한 백엔드 API 커서(즉, API 커서 기능으로 제어되는 서버 커서)를 재생할 때 CursorExecute, CursorOpen 및 CursorPrepare 이벤트를 캡처해야 합니다. 서버 측 준비된 SQL 문을 재생하려면 Exec Prepared SQL 및 Prepare SQL 이벤트를 추가하십시오. 재생에는 애플리케이션 이름, 바이너리 정보, 연결 ID 또는 SPID(서버 프로세스 ID), 데이터베이스 ID, 이벤트 클래스, 이벤트 하위 클래스, 호스트 이름, 숫자 정보, 서버 이름, 사용자 이름 SQL, 실행 데이터를 포함하는 열이 필요합니다. 시작 시간 및 텍스트 정보.

두 번째 실행 중에는 캡처된 이벤트가 시뮬레이션되지 않고 다시 발생한다는 점에 유의하는 것이 중요합니다. 따라서 초기 추적 중에 데이터베이스를 변경했을 가능성이 큽니다. 예를 들어, INSERT 문을 포함하는 추적을 재현할 때 테이블에 중복 키가 나타날 수 있습니다. 이러한 문제를 방지하려면 추적이 원본 서버(즉, 원래 추적이 실행된 서버)에서 재생되는 경우 데이터베이스를 되돌려야 합니다.

다른 서버에서 재실행을 수행할 경우 해당 서버의 데이터베이스가 원래 서버의 데이터베이스와 동일한 상태인지 확인하는 것이 중요합니다. 이 경우 원본 서버에서 사용한 것과 동일한 사용자 이름, 권한, 데이터베이스 식별자를 사용해야 합니다.

동일한 식별자를 사용하려면 특별한 기술과 경험이 필요합니다. 특히 Microsoft는 데이터베이스 식별자를 변경하는 데 필요한 sysdatabases 시스템 테이블에 직접 액세스하는 것을 권장하지 않기 때문입니다. 다른 방법으로 데이터베이스 ID를 일치시킬 수 있습니다. 이렇게 하려면 원본 서버에서 트랙이 재생될 서버로 사용자 데이터베이스 파일을 복사한 다음 원본 서버에서 마스터 데이터베이스 백업을 원본 서버로 복원합니다. 다른 방법은 사용자 데이터베이스의 백업을 원본 서버에서 실행을 위해 선택한 서버로 복원한 다음 마스터 데이터베이스의 백업을 동일한 서버로 복원하는 것입니다. 두 경우 모두 트랙이 재생되는 서버에서 데이터베이스 파일은 소스 서버와 동일한 디렉토리에 있으며 마스터 데이터베이스 시스템 테이블에는 원래 데이터베이스 식별자가 포함됩니다. 이러한 문제를 완전히 제거하려면 추적에서 데이터베이스 식별자 열을 제거하고 추적에 캡처된 각 사용자에 대한 기본 데이터베이스를 설정된 대로 설정하기만 하면 됩니다.

스크립트의 타이밍 레벨과 재생 속도를 제어할 수도 있습니다. 재생 메뉴에서 설정을 선택하여 SQL Server 재생 대화 상자로 들어갑니다. 연결 내에서 동기화를 제어하는 ​​동기화 수준 매개변수는 다음 값을 사용할 수 있습니다.

전체 동기화(전체 동기화).이 값은 기본적으로 사용됩니다. 이 경우 하나의 연결에서 발생한 모든 이벤트가 원래 순서대로 재생됩니다. 부분 동기화.이 값을 사용하면 한 연결의 이벤트가 다른 연결에 이미 기록된 이벤트보다 먼저 시작할 수 있습니다. 동기화가 없습니다.이 매개변수 값을 사용하면 동일한 연결에서 이전 이벤트가 끝난 직후, 즉 연결 내에서 동기화 없이 이벤트가 발생할 수 있습니다.

재생 속도 매개변수인 재생 속도는 다음 값 중 하나로 설정할 수 있습니다.

최대한 빨리(최대한 빨리).기본값으로 이 경우 이전 이벤트가 종료되는 즉시 다음 이벤트가 시작됩니다. 이벤트 사이의 간격을 유지합니다.이 값은 이벤트 발생 사이의 원래 시간 간격을 유지합니다. 시작 시간과의 관계를 유지합니다.이 값을 사용하면 원래 추적에서와 같이 추적 재생 시작을 기준으로 동일한 시점에서 이벤트가 발생합니다.

트랙 재생 구성

사용자가 ADO, OLE DB 또는 ODBC를 통해 서버로 보낸 Transact-SQL(T-SQL) 문인 서버 측 준비된 SQL 문의 실행 추적을 재현하려고 한다고 가정합니다. SQL Server 7.0은 클라이언트 응용 프로그램에서 호출하는 sp_prepare 및 sp_execute 의사 저장 프로시저를 사용하여 서버 측 준비된 SQL 문을 실행합니다.

sp_prepare 호출은 SQL Server가 T_SQL 문을 컴파일하고 실행 계획을 캐시하여 실행을 준비하도록 합니다. sp_execute가 호출되면 SQL Server는 이전에 캐시된 계획을 실행하며 두 번 이상 수행할 수 있습니다. 각 저장 프로시저 호출은 RPC:BatchStarting, Prepare SQL 및 Exec Prepared SQL 이벤트를 발생시킵니다. 이러한 이유 때문에 이러한 이벤트는 추적 정의에 포함되어야 합니다.

SQL 프로파일러에는 템플릿으로 사용할 수 있는 몇 가지 샘플 추적 정의가 포함되어 있습니다. 여기에는 추적 재실행을 나타내는 예제 번호 6, "재생용 T-SQL"이 포함됩니다. 이 예는 재생 중에 생성되는 추적 출력을 지정하는 데 유용합니다. 재생을 위해 저장된 추적 출력을 열려면 파일 메뉴에서 열기를 선택하고 추적 중에 수집된 정보를 저장할 파일, 테이블 또는 SQL 스크립트를 선택하십시오. 표 1에 표시된 옵션을 사용하여 재생을 제어할 수 있습니다. 재생 메뉴 항목이나 도구 모음의 버튼으로 표시할 수 있습니다.

확장 저장 프로시저 적용

SQL 프로파일러의 일부 추적 기능은 사용할 수 없습니다. 여기에는 일정에 따라 실행하기 위한 추적, 특정 이벤트가 발생할 때 실행 또는 SQL Server 시작 시 실행이 포함됩니다. 또한 Windows NT 또는 Windows 2000 응용 프로그램 로그에 추적 결과를 보내도록 SQL 프로파일러를 구성할 수 없습니다. 이러한 기능을 수행하고 추적에 대한 프로그래밍 방식 제어를 제공하기 위해 xp_trace*라고 하는 확장 저장 프로시저 집합을 사용할 수 있습니다.

sp_start_mytrace 추적을 시작하고 저장 프로시저가 sp_stop_mytrace 추적을 중지하는 예를 사용하여 이러한 저장 프로시저를 사용하는 원리를 살펴보겠습니다. 첫 번째 저장 프로시저인 sp_start_mytrace는 추적 이벤트, 데이터 열, 필터를 정의하고 캡처된 이벤트를 보관할 대기열을 만듭니다. 그런 다음 대기열에서 이벤트를 검색하여 시스템 파일에 배치합니다. sp_start_mytrace 프로시저는 이벤트 큐와 통신하고 큐를 만드는 동안 프로시저가 만드는 큐 핸들 정수 유형 핸들을 통해 해당 상태를 추적합니다. sp_stop_mytrace는 대기열을 중지해야 할 때 이 핸들을 사용합니다.

대기열 설명자의 상태를 추적하는 것은 쉬운 일이 아닙니다. 값을 얻는 방법에는 여러 가지가 있지만 가장 간단하고 기능적인 방법은 모든 추적 및 해당 대기열에 대한 데이터와 추적 시작 시간, 전원을 켠 사용자의 식별자를 기록하는 테이블을 만드는 것입니다. 추적 및 추적이 시작된 컴퓨터의 이름입니다. 목록 1은 activetraces라는 테이블을 생성하는 명령문을 보여줍니다. 현재 어떤 추적이 수행되고 있는지 보려면 이 표를 보십시오. 추적을 중지하려면 적절한 대기열 설명자에 대해 테이블을 쿼리하기만 하면 됩니다.

추적을 시작하는 저장 프로시저

이 두 저장 프로시저를 통해 추적을 시작하고 중지하는 방법을 살펴보겠습니다. 추적을 시작하는 저장 프로시저에는 4개의 선택적 입력 매개변수가 있습니다. 처음 두 가지인 @spid_filter와 @dbid_filter를 사용하면 추적 중에 수집되는 정보를 특정 서버 프로세스(ID, SPID로 식별됨) 및 지정된 데이터베이스와 관련된 정보로만 제한할 수 있습니다. 이러한 매개변수가 설정되지 않은 경우 추적은 모든 프로세스 및 데이터베이스에 대한 데이터를 수집합니다. @email_address 매개변수를 사용하면 추적 진행 상황에 대한 자세한 정보를 보낼 이메일 주소를 지정할 수 있습니다. 이 매개변수를 지정하지 않으면 sp_start_mytrace는 정보만 화면에 인쇄합니다. 주소가 지정되었지만 주소가 잘못된 경우 저장 프로시저는 오류 메시지를 발행하고 종료됩니다. 마지막 매개변수인 @filename은 추적 중에 수집된 정보가 전송될 파일의 ​​이름을 지정하기 위한 것입니다. 이 매개변수를 지정하지 않으면 기본 정보가 c:\mytraceN.trc 파일에 저장됩니다. 여기서 N은 대기열 설명자의 번호입니다. 추적 데이터를 사용하여 파일 이름을 지정하는 규칙을 정의하는 이 규칙을 사용하면 여러 추적 중 하나가 파일을 잠그어 자신에 대해서만 결과를 기록하도록 허용하지 않고 동시에 여러 추적을 촬영할 수 있습니다.

트리거를 테스트하려면 파일 속성을 변경합니다.

ALTER DATABASE testdb 수정 파일(이름=`testdb_dat`, MAXSIZE=30MB)

파일 속성이 변경되었다는 메시지가 표시됩니다.

변경된 파일 속성:
명령문: ALTER DATABASE testdb MODIFY FILE(이름 = `testdb_dat`,
최대 크기=30MB)
NT 사용자 이름: 간달프
응용 프로그램 이름: MS SQL 쿼리 분석기
SQL 사용자 이름: 해당 사항 없음
시간: 2000-11-22 14:15:28

교착 상태를 유발한 이벤트를 찾는 것은 항상 매우 어렵습니다. 그러나 SQL 프로파일러는 "조사"를 크게 촉진할 수 있는 특별한 이벤트를 제공합니다. 예를 들어 추적을 사용하여 Lock:Deadlock 이벤트의 발생을 추적할 수 있습니다. 이 사건의 발생은 말한다

난관에 봉착했다는 것입니다. 이것은 사용자에게 서버 프로세스 ID(SPID), 차단된 트랜잭션 ID, 차단 시간, 응용 프로그램 이름 및 사용자 ID를 제공합니다. 잠금이 발생할 때마다 생성되는 잠금: 교착 상태 체인 이벤트는 프로세스 식별자(SPID) 및 트랜잭션을 찾을 수 있어 매우 편리합니다.

교착 상태에 관련된 트랜잭션의 ID를 기록한 다음 트랜잭션 ID별로 추적 결과를 그룹화하고 해당 트랜잭션만 분석할 수 있습니다. 다른 접근 방식에서는 추적 결과가 테이블로 전송됩니다. 그런 다음 쿼리를 사용하여 SPID 또는 트랜잭션 ID로 필터링할 수 있습니다.

교착 상태를 생성하려면 각각 하나의 정수 열만 있어야 하는 두 개의 테이블 t1 및 t2를 만듭니다. 값 1을 포함하는 각 테이블에 하나의 행을 입력합니다. Lock:Deadlock, Lock: Deadlock Chain, 명령문 실행의 해당 시작 및 종료 이벤트(RPC, SP, SQL)가 기록될 추적을 지정합니다. ). 차단의 의도된 소스에 따라 선택해야 합니다. 이 예에서는 SQL 이벤트인 StmtStarting 및 SQL:StmtCompleted만 필요합니다.

기본 데이터 열 외에 트랜잭션 ID와 원하는 열을 캡처하는 열을 추가합니다. 작업 중인 데이터베이스의 ID와 일치하도록 추적 필터를 설정하십시오. 그런 다음 쿼리 분석기에서 두 개의 서버 연결을 엽니다. 첫 번째 연결에서 다음을 실행합니다.

트랜잭션 업데이트 시작 t1 SET col1 = 1

연결 2에서 다음 트랜잭션을 실행합니다.

거래 시작
업데이트 t2 SET col1 = 1
t1에서 * 선택
트랜잭션 커밋

마지막으로 연결 1에서 다음 명령문을 실행합니다.

t2에서 * 선택
트랜잭션 커밋

추적을 중지하고 추적 파일을 엽니다. Lock:Deadlock Chain 이벤트를 찾고 관련된 트랜잭션 수를 기록해 둡니다. 출력을 트랜잭션 ID별로 그룹화하고 해당 트랜잭션을 확장합니다. 출력은 화면 1과 유사하게 보일 것입니다.

SQL Server 엔터프라이즈 관리자에는 교착 상태의 원인을 찾는 데 사용되는 추적을 포함하여 추적을 설정하는 데 도움이 되는 마법사가 포함되어 있습니다. 추적 생성 마법사를 사용하여 추적을 정의하려면 Enterprise Manager에 로그인하고 도구 메뉴에서 마법사를 선택한 다음 관리 범주를 열고 추적 마법사 생성을 선택합니다.

최종 발언

SQL 프로필러에서 제공하는 추적 기능과 SQL Server 7.0에서 사용할 수 있는 확장 추적 저장 프로시저를 사용하면 데이터베이스 동작을 디버깅할 수 있습니다. SQL Server 환경의 상태를 모니터링하는 것이든 응용 프로그램 성능 문제를 해결하는 것이든 관계없이 지식을 실천할 때입니다.

잇직 벤간 [이메일 보호됨] MCDBA, MCSE+I, MCSD, MCT 및 SQL Server MVP 인증을 보유하고 있습니다. 그는 이스라엘의 Hi-Tech College에서 SQL Server 과정의 선임 강사이자 이스라엘 SQL Server 사용자 그룹의 회장입니다.

공유하다