registro de transacciones en RAM o archivo físico?


9

Soy un principiante en transacciones, solo una pregunta sobre el registro de transacciones. Sabemos que cuando confirmamos una transacción, los cambios se escriben en el registro de transacciones, pero ¿está el registro de transacciones en RAM o en archivos físicos? Si está en la RAM y cuando ocurre una falla en el sistema, obviamente la RAM se volverá a borrar para que perdamos la información de la transacción, entonces, ¿cómo podemos recuperar la confirmación?

Respuestas:


15

Puede encontrar una guía bastante completa para esta pregunta aquí , pero para resumir, SQL Server no devolverá el control a la aplicación que confirmó una transacción hasta que esa transacción se haya endurecido en el disco. Específicamente, una vez que se ha endurecido en el archivo de registro de transacciones, se puede devolver el control.

Los datos, en este punto, pueden no estar reforzados en el archivo de datos, aún pueden estar en la memoria caché del búfer de datos, pero debido a que se han endurecido en el registro de transacciones, la recuperación de la base de datos, en caso de falla, puede recuperar esto. transacción y persistir los cambios de forma segura.

Hay una memoria caché de búfer de registro en la memoria utilizada para reducir los impactos en el rendimiento de las escrituras secuenciales en los registros de transacciones. El búfer se vacía en el disco en varias condiciones, pero una de ellas es una confirmación de transacción. Hasta que estos datos se hayan reforzado, el control no se devuelve a la persona que llama, por lo que incluso si tiene un error durante este vaciado del búfer, la consistencia transaccional se mantiene porque esta transacción aún no se considera comprometida. Perderá los cambios de datos en esa transacción, pero como no se confirmó, su aplicación ya consideraría esos cambios perdidos ya que el compromiso nunca se completó.



4

Una base de datos está compuesta por dos archivos, un archivo de datos y un archivo de registro de transacciones. Estos se almacenan en el disco.

Cada base de datos tiene un caché de registro en la RAM, cuando se confirma una transacción, se mueve al caché de registro a la espera de ser vaciada en el disco. Por lo tanto, temporalmente cuando se ha confirmado una transformación y está esperando ser vaciada al disco, está en la memoria, sin embargo, finalmente se almacena en el disco en el archivo, no en la RAM.

Estoy simplificando demasiado aquí, le sugiero que lea sobre los registros de transacciones, le recomiendo una de las conferencias de Paul Randals aquí

https://youtu.be/LvlFgxZZOj4


@kevinwhat Gracias por tu respuesta. Entonces, si confirmamos una transacción y se actualiza en la caché del registro, el sistema falla antes de que la caché del registro se vacíe al disco, entonces, ¿cómo podemos recuperar la transacción?

1
@slowjams en ese caso, los cambios que realizó la transacción se revertirían, ya que no era estable en el disco en el registro en el momento en que se produjo el bloqueo.
Sean Gallardy - Usuario retirado

3
slowjamsm lo que deseas no sucede. La confirmación es síncrona: no finaliza hasta que todo el registro se registre hasta que ese momento se haya escrito en el disco ("reforzado").
Tibor Karaszi,

0

Según lo escrito por otras personas, el registro de transacciones siempre se escribirá en el disco, antes de que el COMMITcontrol vuelva a su aplicación. Por esta razón, el archivo de registro siempre debe colocarse en un SSD rápido.

Pero en aras de la integridad: con al menos Windows Server 2016 más SQL Server 2016, podría agregar NVDIMM (DIMM no volátil = Flash o RAM con respaldo de batería) a su servidor. En este caso, SQL Server usaría estos NVDIMM para colocar la cola del registro de transacciones "activas" en los NVDIMM, ya que sobreviven a un evento de apagado por definición.

Esto aumentaría drásticamente la velocidad de las escrituras (ya que la RAM es mucho más rápida que incluso una SSD), pero solo lo mencionará en una base de datos con muchas pequeñas escrituras / confirmaciones (por ejemplo, la base de datos detrás de una tienda en línea ocupada o un juego en línea con muchos jugadores concurrentes).


3
Esto no es realmente una respuesta a la pregunta, es un complemento para discos más rápidos. Los registros no siempre necesitan estar en un almacenamiento rápido, hay muchas razones comerciales para que no lo estén. Si quieres rápido, compra rápido, si no necesitas velocidad ...
James Jenkins
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.