SQL Server Compile-Sperren?

Question

SQL Server 2000 hier.

Ich versuche ein Interim DBA zu sein, aber ich weiß nicht viel über die Mechanismen eines Datenbankservers, also bleibe ich ein bisschen hängen. Es gibt einen Client-Prozess, der drei Ansichten gleichzeitig erreicht. Diese drei Ansichten fragen einen Remote-Server ab, um Daten zurückzuholen.

Wie es aussieht ist, dass eine dieser Abfragen funktioniert, aber die anderen zwei fehlschlagen (Client-Prozess sagt es Timeout, also ich vermute, eine Sperre kann das tun). Der Abfrageprozess hat eine Sperre, die solange anhält, bis der SQL-Prozess neu gestartet wird (ich wurde mutig und versuchte, den Spid einmal zu töten, aber er ließ nicht los). Alle Abfragen an diese Datenbank nach dem Sperren hängen und den ersten Prozess für das Blockieren verantwortlich.

Der Prozess meldet diese Sperren ... (Entschuldigung für die Formatierung, die Vorschau-Funktion zeigt es als voll aufgereiht).

spid dbid ObjId  IndId Type Resource  Mode Status 
53 17 0   0  DB      S  GRANT 
53 17 1445580188 0  TAB      Sch-S GRANT 
53 17 1445580188 0  TAB  [COMPILE]  X  GRANT 

Ich kann das nicht zu gut analysieren. Das Objekt 1445580188 ist sp_bindefault, eine gespeicherte Systemprozedur im Master. Wofür hängt es an einem exklusiven Schloss?

Code anzeigen, um das proprietäre zu schützen ... Ich änderte nur die Namen (sie blieben konsistent mit Aliasen und was nicht) und versuchte, alles andere genau gleich zu halten.

SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER OFF 
GO 

ALTER view [dbo].[theView] 
as 
select 
    a.[column1] column_1  
    ,b.[column2] column_2 
    ,[column3] 
    ,[column4] 
    ,[column5] 
    ,[column6] 
    ,[column7] 
    ,[column8] 
    ,[column9] 
    ,[column10] 
    ,p.[column11] 
    ,p.[column12] 
FROM 
    [remoteServer].db1.dbo.[tableP] p 
    join [remoteServer].db2.dbo.tableA a on p.id2 = a.id 
    join [remoteServer].db2.dbo.tableB b on p.id = b.p_id 
WHERE 
    isnumeric(b.code) = 1 

GO 

SET ANSI_NULLS OFF 
GO 
SET QUOTED_IDENTIFIER ON 
GO 

Answer 1

Werfen Sie einen Blick auf this link. Sind Sie sicher, dass die Ansichten blockierende und nicht gespeicherte Prozeduren enthalten? Führen Sie diese Abfrage unten mit der ObjId aus Ihrer Tabelle aus, um das herauszufinden. Es gibt Dinge, die Sie tun können, um das erneute Kompilieren gespeicherter Prozeduren zu verringern. Das Wichtigste ist, dass Sie Ihre gespeicherten Prozeduren nicht mit einem Präfix "sp_" benennen, siehe this article auf Seite 10. Vermeiden Sie auch die Verwendung von if/else-Verzweigungen im Code. Verwenden Sie stattdessen where-Klauseln mit case-Anweisungen. Ich hoffe das hilft.

[Bearbeiten]:

Ich glaube sp_binddefault/Regel mit benutzerdefinierten Typen in Verbindung verwendet wird (UDT). Bezieht sich Ihre Ansicht auf irgendwelche UDTs?

SELECT * FROM sys.Objects where object_id = 1445580188 

Answer 2

Objekt 1445580188 wird in der Datenbank Master sp_bindefault, nicht wahr? Außerdem zeigt es resource = "TAB" = Tabelle.

USE master 
SELECT OBJECT_NAME(1445580188), OBJECT_ID('sp_bindefault') 

USE mydb 
SELECT OBJECT_NAME(1445580188) 

Wenn die zweite Abfrage NULL zurückgibt, ist das Objekt eine Arbeitstabelle.

Ich vermute, es ist eine Arbeitstabelle, die erzeugt wird, um lokal mit den Ergebnissen umzugehen. Der JOIN wird lokal passieren und alle Daten müssen übergezogen werden.

Jetzt kann ich nicht auf die Compile-Sperre Licht: die Ansicht sollte bereits kompiliert werden. Dies wird durch den Remote-Server-Zugriff erschwert, und meine Erfahrung mit Kompilierungssperren bezieht sich auf gespeicherte Prozeduren.