로그인

Select the product you need help with

SQL Server는 컴파일 잠금으로 인해 블로킹 설명

기술 자료: 263889 - 이 문서가 적용되는 제품 보기.

기계 번역 고지 사항 보기

기계 번역된 문서와 영문 원본 문서 나란히 보기

모두 확대 | 모두 축소

Microsoft SQL Server 저장된 프로시저 계획의 복사본을 하나만 일반적으로 한 번에 캐시에 저장되어 있습니다. 이 강제 컴파일 프로세스의 일부 직렬화 필요하며 이 동기화 부분적으로 컴파일 잠금을 사용하여 수행됩니다. 시스템 프로세스 ID (SPID) 많은 연결을 동시에 같은 저장된 프로시저를 실행하는 실행될 때마다 해당 저장된 프로시저에 대한 컴파일 잠금을 가져와야 하는 경우 각 개체에 대한 컴파일 단독 잠금의 얻을 때 서로 차단할 시작할 수 있습니다.

위로 가기 | 피드백 보내기

추가 정보

저장된 프로시저 재컴파일 하나의 저장 프로시저나 트리거 컴파일 잠금을 설명입니다. 이 경우 해결 줄이기 위해 또는 제거하는 경우 재컴파일 것입니다. 저장된 프로시저를 다시 컴파일해야 할 가장 일반적인 원인은 설명 및 재컴파일 빈도를 줄이는 몇 가지 유용한 방법에 대한 내용은 Microsoft 기술 자료를 다음 문서를 참조하십시오.

243586

(http://support.microsoft.com/kb/243586/ )

저장된 프로시저 재컴파일 문제 해결

다음 조건에 해당하는 경우 컴파일 잠금이 발생하는 또 다른 시나리오는 다음과 같습니다.

저장된 프로시저를 실행하는 사용자가 프로시저 소유자가 아닙니다.
저장된 프로시저 이름이 정규화된 개체 소유자의 이름이 아닙니다.

예를 들어, 개체를 소유한 사용자 dbo"dbo.mystoredproc다음 개체의 소유자 한정 아니기 때문에 해당 명령을 "exec mystoredproc," 개체 이름이 실패하면에 의해 초기 캐시 조회 사용하여 다른 사용자가 "해리"이 저장된 프로시저를 실행합니다. (이 아직 Harry.mystoredproc 명명된 다른 저장된 프로시저가 있는지 여부를 알 수 없습니다. 따라서 SQL Server dbo.mystoredproc 캐시된 계획을 실행할 수 있는 올바른지 확신할 수 없습니다.) SQL Server 프로시저에 대한 단독 컴파일 잠금을 가져오고 준비 절차를 컴파일할 수 있습니다. 여기에는 개체 ID가 개체 이름 확인 SQL Server 계획을 컴파일합니다 전에 SQL Server 프로시저 캐시의 더 정확한 검색을 수행하는 데 사용하는 개체 ID 및 소유자가 한정하지 않고 훨씬 이전에 컴파일된 계획을 찾을 수 있습니다.

기존 계획이 없으면 SQL Server 캐시된 계획을 재사용합니다 및 저장된 프로시저가 실제로 컴파일되지 않습니다. 그러나 SQL Server 두 번째 캐시 조회 수행 전에 기존 캐시된 실행 계획을 다시 사용할 수 있는 프로그램이 결정합니다 컴파일 단독 잠금을 얻을 수 부족 소유자 한정 됩니다. 잠금 획득 및 조회를 수행하고 이 지점에 도달하는 데 필요한 다른 작업을 안내하는 차단하는 데 지연이 컴파일 잠금 도입할 수 있습니다. 소유자의 이름을 제공하지 않고 프로시저를 동시에 실행할 저장된 프로시저의 소유자는 아닌 사용자가 많은 경우 특히 것입니다. SPID는 컴파일 잠금을 기다리는 표시되지 않으면 소유자 한정 부족 수 있습니다. 저장된 프로시저의 실행 지연이 발생할 불필요하게 높은 CPU 사용률을 발생시킬 수 있습니다.

이 문제가 발생하면 SQL Server 프로필러 추적에서 다음과 같은 일련의 이벤트가 기록됩니다. (캐시 관련 이벤트를 추적할 수 고급 이벤트를 사용하면 합니다. 이렇게 하려면 클릭하십시오.options24번째도구메뉴와 선택합니다모든 이벤트 클래스)

표 축소표 확대

이벤트 클래스	Text:
RPC: 시작	mystoredproc
SP:CacheMiss	mystoredproc
SP:ExecContextHit	mystoredproc
SP: 시작	mystoredproc
...	...

SP:CacheMiss이름 캐시를 조회가 실패할 때 발생합니다. 다음SP:ExecContextHit모호한 개체 이름 개체 ID가 확인된 후 일치하는 캐시된 계획을 최종적으로 캐시에서 찾을 나타냅니다. 상황에 따라SP:CacheHit대신 표시될 수 있습니다.SP:ExecContextHit.

이 문제를 해결하려면 컴파일 잠금 소유자 한정된 저장된 프로시저에 대한 참조가 있는지 확인합니다. (대신exec mystoredproc를 사용하여 실행dbo.mystoredproc.) 성능상의 이유로 소유자 한정 중요하지만 저장된 프로시저 추가 캐시 조회 방지하기 위해 데이터베이스 이름으로 한정할 필요가 없습니다.

차단 컴파일 잠금을 사용하여 블로킹 스크립트를 다음 Microsoft 기술 자료 문서에서 정의된 것과 같은 검색될 수 발생합니다.

251004

(http://support.microsoft.com/kb/251004/ )

INF: SQL Server 7.0 블로킹 모니터링 방법

271509

(http://support.microsoft.com/kb/271509/ )

INF: SQL Server 2000 차단을 모니터링하는 방법

블로킹 스크립트 출력 관찰할 수 컴파일 블로킹 일부 일반적인 특성은 다음과 같습니다.

lastwaittype차단된 및 차단 (일반적으로 SPID는 LCK_M_X (단독) 입니다,대기형식은 "Tab: dbid:object_id[[, 저장 프로시저의 개체 ID "object_id" 어디 컴파일]] ".
차단 기능을 있습니다.waittype0x0000 실행 가능 상태입니다. blockees 있습니다.waittype0x000e 단독 잠금 상태를 대기.
블로킹 문제 기간이 긴 수도 있지만 다른 SPID는 오랫동안 차단하는 없는 단일 SPID가 것입니다. 롤링 차단하는 것입니다. 한 컴파일이 완료된 즉시 다른 SPID가 몇 초 이내에, 헤드 차단 등의 역할을 통해 수행됩니다.

다음 정보를 통해 스냅샷입니다.sysprocesses블로킹 동안 이러한:

   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]

에 있는대기데이터베이스 ID 열 ("6:834102"), 6 및 834102 개체 ID입니다. 저장된 프로시저, 테이블 "Tab" 잠금 유형 불구하고 수 없는 개체 ID 속한 주의하십시오.

참고

SQL Server 2005를 사용하는 경우 SQL Server 2000 시스템 테이블에서 많은 이제 뷰 집합으로 구현됩니다. 이러한 보기는 알려진 호환성 뷰로 및 이전 버전과의 호환성을 위해 것은. 호환성 보기 SQL Server 2000에서 사용할 수 있었던 동일한 메타데이터를 노출합니다. SQL Server 2000 시스템 테이블 및 SQL Server 2005 시스템 뷰 간의 매핑에 대한 자세한 내용은 SQL Server 2005 온라인 설명서의 "매핑 SQL Server 2000 시스템 테이블 위해 SQL Server 2005 시스템 뷰" 항목을 참조하십시오.

저장된 프로시저 이름을 "sp_" 접두사로 시작하는 및 master 데이터베이스에 없는 경우SP:CacheMiss각 실행 경우에에 대한 적중 캐시 전에 사용자가 소유자 - 저장된 프로시저가 한정합니다. sp_ 접두사를 시스템 저장 프로시저는 다른 이름 확인 규칙이 있고 저장 프로시저에서 SQL Server 시스템 저장된 프로시저가 있는지 알 수 있기 때문입니다. "기본 위치는 master 데이터베이스에 있습니다. 사용자가 만든 저장된 프로시저 이름을 sp_로 시작하지 않아야 합니다.

소유자 정규화된 프로시저 소유자 정규화된 프로시저 파일로 만든 것보다 다른 사례는 소유자 한정 프로시저를 실행하면 얻을 수 있는CacheMiss잠금을 요청하는 있지만 결국 캐시된 계획을 사용하십시오. 따라서 이 프로시저가 실제로 컴파일할 수 있으며 많은 오버헤드가 발생할 합니다. 하지만 경우 많은 SPID 같은 프로시저를 만든 것과 다른 경우 동일한 절차를 실행하려고 했습니다 특정 상황에서 잠금 요청하지 "체인 차단" 상황이 발생할 수 있습니다. 이 서버 또는 데이터베이스가 사용되고 데이터 정렬 또는 정렬 순서에 관계없이 적용됩니다. 프로시저 캐시의 찾기 위해 사용되는 알고리즘은 다른 경우 변경할 수 있는 해시 값을 성능 향상 위한 기반으로 이 동작을 때문입니다.

해결 방법은 응용 프로그램이 실행되는 삭제하고 동일한 절차 경우로 프로시저를 만들 수 있습니다. You can also make sure that the procedure is executed from all applications that use the same case.

If you try to execute a stored procedure as a Language Event instead of as an RPC, SQL Server must parse and compile the language event query, determine that the query is trying to execute the particular procedure, and then try to find a plan in cache for that procedure. To avoid this situation in which SQL Server must parse and compile the language event, make sure that the query is sent to SQL as an RPC.

For more information, see the "System Stored Procedures" section in the Books Online article "Creating a Stored Procedure."

Known issues

Here are some known issues that can prevent plan caching:

You use BLOB variables as a Stored Procedure parameter. 위 핫픽스 관련 추가 정보는 다음 Microsoft 기술 문서를 참조하십시오.:
2380435
(http://support.microsoft.com/kb/2380435/ )
FIX: The query plan for a stored procedure is not cached if the stored procedure uses a BLOB variable and the variable is used in a string function in Microsoft SQL Server 2008
You use OPEN SYMMETRIC KEY in a Stored Procedure/Query Batch. For more information, see the following MSDN blog entry:
http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx
(http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx)

위로 가기 | 피드백 보내기

속성

기술 자료: 263889 - 마지막 검토: 2010년 11월 24일 수요일 - 수정: 1.0

본 문서의 정보는 다음의 제품에 적용됩니다.

Microsoft SQL Server 7.0 Standard Edition
Microsoft SQL Server 2000 Standard Edition
Microsoft SQL Server 2005 Standard Edition
Microsoft SQL Server 2005 Developer Edition
Microsoft SQL Server 2005 Enterprise Edition
Microsoft SQL Server 2005 Express Edition
Microsoft SQL Server 2005 Workgroup Edition

kbinfo kbmt KB263889 KbMtko

기계 번역된 문서

중요: 본 문서는 전문 번역가가 번역한 것이 아니라 Microsoft 기계 번역 소프트웨어로 번역한 것입니다. Microsoft는 번역가가 번역한 문서 및 기계 번역된 문서를 모두 제공하므로 Microsoft 기술 자료에 있는 모든 문서를 한글로 접할 수 있습니다. 그러나 기계 번역 문서가 항상 완벽한 것은 아닙니다. 따라서 기계 번역 문서에는 마치 외국인이 한국어로 말할 때 실수를 하는 것처럼 어휘, 구문 또는 문법에 오류가 있을 수 있습니다. Microsoft는 내용상의 오역 또는 Microsoft 고객이 이러한 오역을 사용함으로써 발생하는 부 정확성, 오류 또는 손해에 대해 책임을 지지 않습니다. Microsoft는 이러한 문제를 해결하기 위해 기계 번역 소프트웨어를 자주 업데이트하고 있습니다.

이 문서의 영문 버전 보기:263889

(http://support.microsoft.com/kb/263889/en-us/ )

위로 가기 | 피드백 보내기