Snapshot su, ancora situazioni di stallo, ROWLOCK

Question

ho acceso l'isolamento dello snapshot nel mio database utilizzando il seguente codice

ALTER DATABASE MyDatabase 
SET ALLOW_SNAPSHOT_ISOLATION ON 

ALTER DATABASE MyDatabase 
SET READ_COMMITTED_SNAPSHOT ON 

e sbarazzato fuori un sacco di situazioni di stallo.

Ma il mio database produce ancora deadlock, quando ho bisogno di eseguire uno script ogni ora per ripulire oltre 100.000 righe.

• C'è un modo per evitare deadlock nel mio script di pulizia, devo impostare ROWLOCK in modo specifico in quella query?
• C'è un modo per aumentare il numero di blocchi a livello di riga utilizzati da un database?
• Come vengono promossi i blocchi? Dal livello della riga al livello della pagina fino al livello della tabella?

Il mio script di eliminazione è piuttosto semplice:

delete statvalue 
from statValue, 
(select dateadd(minute,-60, getdate()) as cutoff_date) cd 
where temporaryStat = 1 
and entrydate < cutoff_date 

In questo momento sto cercando una soluzione rapida, ma una soluzione a lungo termine sarebbe ancora più bello.

Grazie mille, Patrikc

Answer 1

Il modo per farlo per ridurre (o evitare) deadlock è quello di eliminare in lotti con una breve attesa tra ogni lotto (usando WAITFOR DELAY)

Inoltre, deadlock può essere mitigato avendo un indice di copertura.

Questo codice richiede alcune dichiarazioni, ed è solo a titolo di esempio (Esegui a proprio rischio!).

SELECT @intRowCount = 1, 
    @intErrNo = 0 

DECLARE @cutoff_date DATETIME 

SET @cutoff_date = dateadd(minute,-60, getdate()) 

SELECT @intRowsToDelete = COUNT(*) -- Number of rows to be deleted 
FROM dbo.statValue 
WHERE temporaryStat = 1 
AND entrydate < @cutoff_date 

WHILE @intRowCount > 0 AND @intErrNo = 0 
BEGIN 

    SET ROWCOUNT @DEL_ROWCOUNT 

    delete statvalue 
    FROM dbo.statValue 
    WHERE temporaryStat = 1 
    AND entrydate < @cutoff_date 

    SELECT @intErrNo = @@ERROR, @intRowCount = @@ROWCOUNT 

    SET ROWCOUNT 0 -- Reset batch size to "all" 

    SELECT @intRowsToDelete = @intRowsToDelete - @intRowCount 

    WAITFOR DELAY '000:00: 
END 

Ho anche incluso il suggerimento di John di non calcolare ripetutamente i criteri dell'intervallo di date.

Answer 2

Si prega di ri-scrivere il vostro query di eliminazione in questo modo:

DECLARE @cutoff_date DATETIME 

SET @cutoff_date = dateadd(minute,-60, getdate()) 

delete statvalue 
from statValue 
where temporaryStat = 1 
and entrydate < @cutoff_date 

si vedrà una riduzione dei costi nel vostro piano di esecuzione

Answer 3

isolamento SNAPSHOT può solo attenuare (alcune) delle situazioni di stallo che coinvolgono letture, ma non fa assolutamente nulla per evitare i deadlock write vs. write. Se si generano 100k + righe all'ora, si tratta di ~ 30 inserimenti al secondo, pertanto la scansione dell'eliminazione è praticamente in conflitto con altre operazioni di scrittura. Se tutto ciò che fai è Inserisci, non aggiorna mai, quindi il blocco di eliminazione, ma non il deadlock al blocco a livello di riga, ma poiché la tabella è abbastanza grande e l'eliminazione esegue una scansione, il motore sceglierà probabilmente un blocco di pagina per l'eliminazione, quindi probabilmente lo stallo si ottiene.

w/o un indice sulla data di ingresso la cancellazione non ha scelta ma per eseguire la scansione dell'intera tabella. Questo tipo di tabelle che vengono frequentemente inserite nella parte superiore e cancellate in fondo sono in effetti delle code e il tuo deve organizzarle entro la data di entrata. Ciò significa che data di ingresso dovrebbe probabilmente essere la chiave più a sinistra nell'indice cluster. Questa organizzazione consente una chiara separazione degli inserti che si verificano all'estremità della tabella rispetto alle eliminazioni che si verificano all'altra estremità. Ma questo è un cambiamento piuttosto radicale, specialmente se si usa lo statvalueid per leggere questi valori. Immagino che adesso abbiate un indice cluster basato su un campo autoincremento (StatValueId). Suppongo anche che la data di entrata e lo statvalueid siano correlati.Se entrambe le ipotesi sono vere, allora si dovrebbe eliminare base di don lo statvalueid: trovare il più grande id che è sicuro da eliminare, quindi eliminare tutto su l'indice cluster sinistra di questo id:

declare @statvalueidmax int; 
select @statvalueidmax = max(statvalueid) 
from statvalue with (readpast) 
where entrydate < dateadd(minute,-60, getdate()); 

delete statvalue 
where statvalueid <= @statvalueidmax; 

Ci sono una serie di ipotesi Ho fatto, potrebbero essere sbagliati. Ma il succo dell'idea è che devi separare gli inserti dalle eliminazioni in modo che non si sovrappongano.