registro delle transazioni nella RAM o nel file fisico?


9

Sono un principiante nella transazione, solo una domanda sul registro delle transazioni. Sappiamo che quando eseguiamo il commit di una transazione, le modifiche vengono scritte nel registro delle transazioni, ma il registro delle transazioni è nella RAM o nei file fisici? Se è nella RAM e quando si verifica un errore del sistema, ovviamente la RAM verrà cancellata in modo da perdere le informazioni sulla transazione, quindi come possiamo recuperare il commit?

Risposte:


15

Puoi trovare una guida abbastanza completa a questa domanda qui , ma per riassumere, SQL Server non restituirà il controllo all'applicazione che ha eseguito una transazione fino a quando la transazione non è stata ripristinata sul disco. In particolare, una volta indurito nel file di registro delle transazioni, è possibile restituire il controllo.

I dati, a questo punto, potrebbero non essere protetti nel file di dati, potrebbero essere ancora nella cache del buffer dei dati, ma poiché sono stati rafforzati nel registro delle transazioni, il recupero del database, in caso di errore, può recuperare questo transazione e persistere le modifiche in modo sicuro.

Esiste una cache del buffer di registro in memoria utilizzata per ridurre l'impatto delle prestazioni delle scritture sequenziali nei registri delle transazioni. Il buffer viene scaricato sul disco in diverse condizioni, ma uno di questi è un commit di transazione. Fino a quando questi dati non sono stati induriti, il controllo non viene restituito al chiamante, quindi anche se si verifica un errore durante lo svuotamento del buffer, la coerenza transazionale viene mantenuta poiché questa transazione non è ancora considerata impegnata. Perderai le modifiche ai dati in quella transazione, ma poiché non è stato eseguito il commit, l'applicazione considererà già tali modifiche perse poiché il commit non è mai stato completato.



4

Un database è composto da due file, un file di dati e un file di registro delle transazioni. Questi sono memorizzati su disco.

Ogni database ha una cache di registro nella RAM, quando viene impegnata una transazione, questa viene spostata nella cache di registro in attesa di essere scaricata sul disco. Pertanto temporaneamente quando una trasformazione è stata impegnata e in attesa di essere scaricata su disco, è in memoria, tuttavia alla fine viene archiviata sul disco nel file, non nella RAM.

Sto semplificando eccessivamente qui, ti suggerisco di leggere sui registri delle transazioni, ti consiglio una delle lezioni di Paul Randals qui

https://youtu.be/LvlFgxZZOj4


@kevinwhat Grazie per la risposta. Pertanto, se eseguiamo il commit di una transazione e questa viene aggiornata nella cache del registro, il sistema non riesce prima che la cache del registro venga scaricata sul disco, quindi come possiamo ripristinare la transazione?

1
@slowjams in quel caso le modifiche apportate alla transazione sarebbero state ripristinate, poiché non era stabile sul disco nel registro nel momento in cui si è verificato l'arresto anomalo.
Sean Gallardy - Utente in pensione

3
slowjamsm ciò che desrcibe non accade. Il commit è sincrono - non termina fino a quando tutti i record di registro non sono stati scritti fino a quel momento nel tempo ("hardened").
Tibor Karaszi,

0

Come scritto dalle altre persone, il registro delle transazioni verrà sempre scritto sul disco, prima che venga COMMITrestituito un controllo all'applicazione. Per questo motivo il file di registro deve essere sempre posizionato su un SSD veloce.

Ma per completezza: con almeno Windows Server 2016 più SQL Server 2016 è possibile aggiungere NVDIMM (DIMM non volatile = Flash o RAM con batteria) al server. In questo caso SQL Server userebbe questo NVDIMM per posizionare la coda del registro delle transazioni "a caldo" sugli NVDIMM, poiché sopravvivono a un evento di spegnimento per definizione.

Ciò aumenterebbe drasticamente la velocità delle scritture (poiché la RAM è molto più veloce di un SSD), ma la citerai solo su un database con molte piccole scritture / commit (ad esempio il database dietro un negozio online occupato o un gioco online con molti giocatori simultanei).


3
Questa non è davvero una risposta alla domanda, è una spina per dischi più veloci. I registri non devono sempre essere in memoria veloce, ci sono molte ragioni commerciali per cui non lo sono. Se vuoi comprare velocemente, se non hai bisogno di velocità ....
James Jenkins
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.