problema di blocco escalation di SQL Server

Question

Sto leggendo escalation di blocco di SQL Server da MSDN Pagina su blocco di SQL Server escalation

La mia domanda è, sembra la ragione principale per cui v'è escalation dei blocchi è quello di ridurre l'overhead di mantenere più serrature (ad esempio quando altre blocchi di riga vengono acquisiti per un tavolo, poi fila serratura livello viene aumentato a livello di tabella). La mia domanda è, per mantenere più serrature migliorerà la concorrenza, è un vantaggio, perché è un overhead? A mio modesto idea, blocco dovrebbe essere il più piccolo abbastanza per fare la prestazione db meglio, migliorando la concorrenza. Qualcuno potrebbe spiegare in modo semplice il motivo per cui è necessaria l'escalation dei blocchi e qual è la cosiddetta testa di blocco per favore?

Grazie in anticipo, George

Answer 1

  

Qualcuno potrebbe spiegare in modo semplice il motivo per cui è necessaria l'escalation dei blocchi e qual è la cosiddetta testa di blocco per favore?

Quando si aggiorna un tavolo e bloccare una riga, è necessario registrare questo fatto in qualche modo: questa è una fila, è stato aggiornato e bloccato

.

Quando si aggiornano milioni di righe, è necessario fare questo milione di volte, e quindi avere un po 'di spazio per mantenere milioni di serrature.

SQL Server mantiene un elenco di serrature in memoria, mentre Oracle fa in sulle tabelle.

Questo è probabilmente perché Oracle è vecchio (più di me), e SQL Server è giovane rispetto a Oracle.

Come mantenere le risorse temporanee (come serrature) in una memoria permanente non è soluzione in modo evidente dal punto di vista del progettista. Solo una cosa da menzionare:. Potrebbe essere necessario una scrittura su disco per eseguire un SELECT FOR UPDATE

funzioni principali di Oracle sono stati sviluppati nei primi anni '80, quando mantenere le cose in memoria non era un'opzione a tutti. Hanno appena had di utilizzare lo spazio su disco in qualche modo.

Se lo spazio su disco doveva essere usato in ogni caso, si doveva mettere un blocco da qualche parte sul disco.

E dove per mantenere una serratura per una riga, se non all'interno della riga stessa?

Gli sviluppatori del sistema di blocco di SQL Server, quando inventando progettazione del loro RDBMS chiamato Sybase, ha deciso di memorizzare le cose temporanee (i. E. Serrature) nella memoria temporanea (i. E. RAM).

Ma il design di Oracle è sempre equilibrata:. Se si dispone di un 1.000.000 di righe nel database, allora avete uno spazio di archiviazione per 1.000.000 di serrature, se si dispone di un miliardo di file, è possibile memorizzare miliardi di serrature, ecc

disegno di SQL Server è flawy in questo senso, perché la vostra RAM e spazio su disco fisso possono essere sbilanciato. Si può facilmente avere 16M di RAM e diversi terabyte di spazio su disco. E la memoria proprio non può contenere tutte le serrature.

Ecco perché quando il conteggio di blocco raggiunge un certo limite, SQL Server decide di intensificare le serrature: invece di tenere chiuse per, diciamo, 10 singole righe in una pagina di dati (che richiede 10 dischi), si blocca l'intera pagina di dati (che richiede 1 disco).

Oracle, d'altra parte, quando si aggiorna una riga, solo scrive il blocco a destra nella DataPage.

Ecco perché le serrature di Oracle sono a livello di riga.

Oracle non "gestire" le serrature in un senso comune della parola:. Non si può, per esempio, avere una lista delle pagine bloccate in Oracle

Quando una transazione ha bisogno di aggiornare una riga, si va solo per la riga e vede se è bloccato.

Se lo è, sembra che delle transazioni contiene un blocco (queste informazioni sono contenute all'interno del descrittore di blocco nella pagina di dati) e si aggiunge alla coda di notifica che dell'operazione: quando le operazioni di bloccaggio muore, quello originale viene avvisato e si blocca i dati.

Dal punto di vista della concorrenza, l'escalation dei blocchi è totalmente la soluzione di un uomo povero: non aggiunge nulla alla concorrenza. È possibile, ad esempio, ottenere un blocco su una riga che non ha nemmeno toccato.

Dal punto di vista della prestazione, fare le cose in memoria è, ovviamente, più veloce di farle sul disco.

Ma poiché Oracle memorizza i bloccodati e le operazioni effettive sopra descritte vengono eseguite in memoria ogni caso, la prestazione è uguale o vicino ad esso.

Answer 2

Se le stime per ottimizzare SQL Server / decide che una query si 'visitare' tutte le righe in un certo intervallo sarà più efficace per contenere un singolo blocco su tale intervallo, piuttosto che avere a negoziare molte serrature (serrature devono essere testati per tipo). Questo è oltre a consumare meno risorse di blocco (una vasta risorsa di sistema).

Se si dispone di uno schema ben progettato, e gli indici appropriati per il carico di lavoro query, che vengono regolarmente mantenuti, non dovreste preoccuparvi di all'escalation che si sta verificando. In molti casi, bloccando blocchi di tabella possono essere eliminati dagli indici di copertura appropriate.

UPDATE: Un indice di copertura per una query significa che una ricerca nel cluster non dovrà essere eseguita, e questo riduce le probabilità di bloccaggio inserti nella tabella

.

Answer 3

l'overhead mezzi di bloccaggio che la gestione della serratura una tabella è meglio perf saggio di gestire un sacco di blocchi di riga. poiché ogni blocco richiede una certa memoria, un sacco di blocchi di riga può consumare molta più memoria di un blocco di tabella. così l'escalation dei blocchi va da row-> page-> blocco di tabella.

Answer 4

La definizione di "efficiente" è complessa. A volte è più efficace di ottimizzare per la concorrenza, se un sacco di processi possono fare lì cosa senza collisioni. A volte è più efficiente di fare una concorrenza temporanea colpire per ottenere un unico processo fatto più velocemente. Il blocco escalation non mancherà di tenere gli altri processi in modo questo processo può ottenere il suo lavoro fatto e ottenere fuori del modo.

Answer 5

Per info specifiche su come le serrature sono mantenuti, è possibile vedere il capitolo 8 di Microsoft SQL Server 2005: il motore di memorizzazione (Io non sono affiliati, questo è solo il primo informazioni interni mi sono imbattuto). Se si dispone di un account Books24x7, è lì. Essa mostra su una macchina> memoria 16GB ci sono 2 ^ 25 (33554432) slot nella tabella hash serratura, con un limite massimo di 2 ^ 31 slot.

Per una data applicazione che si può benissimo trovare il throughput totale ad essere più elevati utilizzando solo pregiati serrature grana. Come si può intuire, tutto dipende da come il sovraccarico di gestione di blocco a fronte di potenziale blocco eccessivo.