Compile locks on Resource database only

Question

Our server was recently crippled by blocked processes on the Resource database.
Restarting the instance resolved the problem, however I would like to understand why Resource DB was blocking on compile, yet no other database was experiencing blocking.
<blocked-process-report monitorLoop="717845">
 <blocked-process>
  <process id="processeb92c99c38" taskpriority="5" logused="0" waitresource="OBJECT: 32767:-412:0 [COMPILE]" waittime="7822" ownerId="6639115589" transactionname="sqlsource_transform"
lasttranstarted="2014-09-05T23:00:11.117" XDES="0x201b053d20" lockMode="X" schedulerid="19" kpid="10208" status="suspended" spid="819" sbid="0" ecid="0" priority="-5"
trancount="0" lastbatchstarted="2014-09-05T23:00:11.117" lastbatchcompleted="2014-09-05T23:00:11.117" lastattention="1900-01-01T00:00:00.117" clientapp="ediEnterpriseServiceRunner" hostname="WG1-SPRC-22"
hostpid="138648" loginname="OdysseyAdmin" isolationlevel="read committed (2)" xactid="6639115589" currentdb="796" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
   <executionStack>
    <frame line="2" stmtstart="-1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"/>
    <frame line="2" stmtstart="-1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"/>
    <frame line="2" stmtstart="-1" sqlhandle="0x02000000b8e27d16fe8d28b092004808170c1d201fbac34b0000000000000000000000000000000000000000"/>
   </executionStack>
   <inputbuf>
SELECT name, type_desc
FROM [Odyssey1_SD001].sys.triggers
WHERE parent_class = 0
AND is_ms_shipped = 0
AND is_disabled = 0   </inputbuf>
  </process>
 </blocked-process>
 <blocking-process>
  <process status="suspended" waitresource="OBJECT: 32767:-412:0 [COMPILE]" waittime="8574" spid="766" sbid="0" ecid="0" priority="-5" trancount="0" lastbatchstarted="2014-09-05T23:00:10.367"
lastbatchcompleted="2014-09-05T23:00:10.367" lastattention="1900-01-01T00:00:00.367" clientapp="ediEnterpriseServiceRunner" hostname="WG1-SPRC-24" hostpid="18348" loginname="OdysseyAdmin" isolationlevel="read
committed (2)" xactid="6639111342" currentdb="1070" lockTimeout="4294967295" clientoption1="671090784" clientoption2="128056">
   <executionStack>
    <frame line="2" stmtstart="-1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"/>
    <frame line="2" stmtstart="-1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"/>
    <frame line="2" stmtstart="-1" sqlhandle="0x02000000f030cd2a8c487038f8e4314b6bf429f9681699700000000000000000000000000000000000000000"/>
   </executionStack>
   <inputbuf>
SELECT name, type_desc
FROM [Odyssey2_SD001].sys.triggers
WHERE parent_class = 0
AND is_ms_shipped = 0
AND is_disabled = 0   </inputbuf>
  </process>
 </blocking-process>
</blocked-process-report>

Answer 1

Hi Erland,
I found that if I run the below query, I can get the -412.
select
*fromsys.sysobjectswherename='triggers'
From the information of "waitresource=OBJECT: 32767:-412:0 [COMPILE]", I suspect there's a stored procedure invoked the triggers view and many connections are concurrently running the same stored procedure , so the blocking issue
occured.
In Microsoft SQL Server, only one copy of a stored procedure plan is generally in cache at a time. Enforcing this requires serialization of some parts of the compilation process, and this synchronization is accomplished in part by using compile locks. If
many connections are concurrently running the same stored procedure and a compile lock must be obtained for that stored procedure every time that it is run, system process IDs (SPIDs) might begin to block one another as they each try to obtain an exclusive
compile lock on the object.
Another scenario in which compile locks occur is when the following conditions are true:
The user who runs the stored procedure is not the owner of the procedure.
If an existing plan is found during the SP executing, SQL Server reuses the cached plan and does not actually compile the stored procedure. However, the lack of owner-qualification forces SQL Server to perform a second cache lookup and obtain an exclusive
compile lock before the program determines that the existing cached execution plan can be reused.
Reference : http://support2.microsoft.com/kb/263889
I think we need to check whether customer's stored procedure often conconcurrently running and often recomplie.
Halin Huang