CREATE TRIGGER impiega più di 30 minuti su SQL Server 2005

Question

Nel nostro database live / di produzione sto cercando di aggiungere un trigger a una tabella, ma non ho avuto successo. Ho provato alcune volte, ma ci sono voluti più di 30 minuti per completare l'istruzione trigger trigger e l'ho annullata.

La tabella è quella che viene letta / scritta spesso da un paio di processi diversi. Ho disabilitato i lavori pianificati che aggiornano la tabella e ho provato a volte quando c'è meno attività sulla tabella, ma non sono in grado di interrompere tutto ciò che accede alla tabella.

Non credo che ci sia un problema con la stessa istruzione trigger trigger. L'istruzione trigger trigger ha avuto esito positivo e rapido in un ambiente di test e il trigger funziona correttamente quando le righe vengono inserite / aggiornate nella tabella. Anche se quando ho creato il trigger sul database di test non c'era carico sulla tabella e aveva molte meno righe, che è diverso rispetto al database live / di produzione (100 contro 13.000.000+).

Ecco l'istruzione trigger trigger che sto cercando di eseguire

CREATE TRIGGER [OnItem_Updated] 
    ON  [Item]
   AFTER UPDATE
AS 
BEGIN
    SET NOCOUNT ON;

    IF update(State)
    BEGIN
        /* do some stuff including for each row updated call a stored 
          procedure that increments a value in table based on the 
          UserId of the updated row */
    END
END

Possono esserci problemi con la creazione di un trigger su una tabella durante l'aggiornamento delle righe o se ha più righe?

In SQL Server i trigger vengono creati abilitati per impostazione predefinita. È possibile creare il trigger disabilitato per impostazione predefinita?

Altre idee?

Answer 1

Il problema potrebbe non essere nella tabella stessa, ma nelle tabelle di sistema che devono essere aggiornate per creare il trigger. Se stai facendo qualsiasi altro tipo di DDL come parte dei tuoi normali processi, potrebbero trattenerlo.

Usa sp_who per scoprire da dove proviene il blocco, quindi investiga da lì.

Answer 2

Credo che il trigger CREATE tenterà di bloccare un intero tavolo.

Se hai molte attività su quel tavolo, potrebbe essere necessario attendere molto tempo e potresti creare un deadlock.

Per eventuali modifiche allo schema dovresti davvero ottenere tutti dal database.

Detto questo, è allettante inserire "piccolo" cambia con connessioni attive. Dovresti dare un'occhiata ai blocchi / connessioni per vedere dove si trova la contesa di blocco.

Answer 3

È strano. Un trigger AFTER UPDATE non dovrebbe aver bisogno di controllare le righe esistenti nella tabella. Suppongo che non sia possibile ottenere un blocco sul tavolo per aggiungere il trigger.

Potresti provare a creare un trigger che sostanzialmente non fa nulla. Se non riesci a crearlo, allora è un problema di blocco. Se è possibile, è possibile disabilitare quel trigger, aggiungere il codice desiderato al corpo e abilitarlo. (Non credo che tu possa disabilitare un trigger durante la creazione.)

Answer 4

Parte del problema potrebbe anche essere il trigger stesso. Il trigger potrebbe aggiornare accidentalmente tutte le righe della tabella? C'è una grande differenza tra 100 righe in un database di test e 13.000.000. È una pessima idea sviluppare codice su un set così piccolo quando si dispone di un set di dati così grande che non si ha modo di prevedere le prestazioni. SQL che funziona correttamente per 100 record può bloccare completamente un sistema con milioni per ore. Lo vuoi davvero sapere in dev, non quando promuovi prod.

Chiamare un proc memorizzato in un trigger è di solito una pessima scelta. Significa anche che devi passare in rassegna i record che è una scelta ancora peggiore in un trigger. I trigger devono sempre tenere conto di più inserimenti / aggiornamenti o eliminazioni di record. Se qualcuno inserisce 100.000 righe (non è improbabile che tu abbia 13.000.000 di record), il ciclo attraverso un proc memorizzato basato su record potrebbe richiedere ore, bloccare l'intera tabella e indurre tutti gli utenti a dare la caccia allo sviluppatore e uccidere (o almeno mutilare) lui perché non riescono a svolgere il proprio lavoro.

Non prenderei nemmeno in considerazione di mettere questo trigger su prod fino a quando non testerai contro un set di record simliar di dimensioni da produrre.

Il mio amico Dennis ha scritto questo articolo che illustra perché testare una piccola quantità di informazioni quando si dispone di una grande quantità di informazioni può creare difficoltà su prd che non si è notato su dev: http://blogs.lessthandot.com/index.php/DataMgmt/?blog=3&title=your-testbed-has-to-have-the-same-volume& DISP = singolo & amp; più = 1 & amp; c = 1 & amp; TB = 1 & amp; pb = 1 # C1210

Answer 5

Esegui DISABLE TRIGGER triggername ON tablename prima di modificare il trigger, quindi riattivalo con ENABLE TRIGGER triggername ON tablename