¿Las bases de datos de SQL Server son más lentas con el aislamiento de instantáneas?

8

Tengo muchos puntos muertos en mi sistema.

Me gustaría usar Snapshot Isolation para solucionarlos, pero mi DBA tiene reservas al respecto.

Una de sus preocupaciones es que el aislamiento de instantáneas ralentiza las escrituras. Esto se debe a que tiene que escribir en la memoria caché y luego en TempDb (versión de fila) y luego puede volver a la persona que llama.

Una escritura "normal" puede simplemente escribir en el caché y luego hacerse.

¿Es así como funciona el control de versiones de fila? ¿O es más complejo que eso? ¿De alguna manera hace esto en paralelo?

¿O las escrituras son más lentas con el aislamiento de instantáneas?

sql-server sql-server-2008 sql-server-2008-r2 snapshot isolation-level Vaccano
fuente
2
Un problema a tener en cuenta cuando habilita el aislamiento de instantáneas: el tamaño de su fila aumentará en 14 bytes. Asegúrese de haber planeado este aumento de capacidad y las divisiones de página resultantes.
StanleyJohns

Respuestas:

14

es porque tiene que escribir en el caché y luego en TempDb (versión de fila) y luego puede volver a la persona que llama.

No, esto es incorrecto. Implica de alguna manera que las escrituras en presencia de versiones tienen una latencia más alta ya que cada escritura tiene que tocar el disco (para tempdb), lo cual no es cierto. La escritura en tempdb también es una escritura en 'caché'. La única 'espera' ocurre en el momento de COMPROMISO cuando el registro debe ser reforzado. Es cierto que con el control de versiones, tanto el registro de la base de datos como el registro de tempdb deben ser reforzados, pero esto no implica necesariamente una latencia más alta (el IO debe ser paralelo en diferentes rutas de almacenamiento, el tempdb se almacena en una unidad separada de su LDF muy usado, ¿Correcto?). Para obtener una explicación completa, lea Cómo funciona: Presentación de E / S de SQL Server de Bob Dorr . Realmente espero que su DBA entienda esto mejor de lo que lo está transmitiendo aquí.

Como mencioné en su otra publicación: la instantánea no tiene costo para INSERTOS y el costo de actualizaciones y eliminaciones se puede mitigar fácilmente. El uso de recursos de versiones de fila explica las compensaciones. En este momento, probablemente debería estar probando con una carga de trabajo realista, que es la única forma de evaluar adecuadamente el impacto que experimentaría.

Remus Rusanu
fuente
44
Por cierto, considere esto: ¿usted o su DBA han usado alguna vez activadores en los últimos 7 años? Dado que los activadores de SQL 2005 se implementan utilizando instantáneas detrás de escena. Lo mismo ocurre si alguna vez utilizó la reconstrucción de índices en línea o MARS . ¿Qué tal si verifica ahora mismo sys.dm_db_file_space_usageen su servidor de producción? Si version_store_reserved_page_countno es cero , ya está utilizando el almacén de versiones .
Remus Rusanu
No creo que tempdb log tenga que ser reforzado porque redo nunca se ejecuta en tempdb. Entonces la sobrecarga es aún más baja.
usr
0

Creo que hay otros problemas en la aplicación si tienes puntos muertos. El aislamiento de instantáneas generalmente ayuda a reducir los bloqueos de espera, pero la raíz de los puntos muertos suele ser diferentes métodos de acceso en la aplicación que deben evitarse al adherirse a un patrón consistente. Las discusiones sobre puntos muertos son complicadas y hay muchos recursos dedicados a ellas.

Su DBA tiene razón al preocuparse por cambiar el nivel de aislamiento a la instantánea, ya que aumenta la carga en el tempDB. Recomiendo ir al aislamiento de instantáneas en general, pero creo que eso es solo una parte de abordar sus puntos muertos. Puede terminar con escrituras sucias, donde una transacción actualiza la fila A y luego B, y otra transacción actualiza la fila B y luego A.

Robert-Ryan.
fuente