¿Qué riesgos existen si habilitamos la instantánea de lectura confirmada en el servidor SQL?

He leído aquí que se almacenarán algunos datos adicionales por fila, por lo que podríamos ver una degradación del rendimiento, pero ¿qué otros riesgos existen?

p.ej. ¿Afectará esto la recuperación de la base de datos? ¿Hay algo más que debamos hacer para aprovechar esto?

Planeo ejecutar estos comandos:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Creo que esto nos dará algo más cercano a Oracle donde si una transacción se actualiza, otras transacciones aún pueden leer los datos antiguos. ¿Es esto correcto?

Estoy investigando esto porque estoy harto de problemas de bloqueo en SQL Server 2005. Espero que esto pueda reducir los bloqueos ocasionales que ven nuestros usuarios, ayudar al rendimiento general de nuestra aplicación y alentar a nuestros desarrolladores a realizar más de una operación por transacción sin miedo.

Resumen

1. Si tiene problemas de bloqueo, entonces tiene un problema con su código: no es el motor de la base de datos
2. No es una bala mágica
3. Puedes agregar más problemas

Carga

También aumentará la carga en su tempdb y CPU . Ver también:

• "Impacto en el rendimiento: el costo potencial de Read_Committed_Snapshot" (Linchi Shea)

La seguridad

Lo más importante, los aislamientos de instantáneas no son seguros en muchos casos de manera predeterminada . Lea "Aislamiento de instantáneas" (Wikipedia) para obtener más información sobre las anomalías de inclinación de escritura. La siguiente sección es "Hacer que el aislamiento de instantáneas sea serializable" para solucionar esto.

En general, por lo tanto, el aislamiento de instantáneas plantea algunos de los problemas de mantener restricciones no triviales para el usuario, que puede no apreciar ni las dificultades potenciales ni las posibles soluciones. La ventaja de esta transferencia es un mejor rendimiento.

Ver también:

• "Los peligros potenciales del nivel de aislamiento de instantáneas comprometidas de lectura" (JimMcLeod, disputado en los comentarios de Alex Kuznetsov)
• Deadlocked !: "leer una instantánea comprometida" explicado (Nick Berardi)
• Nivel de aislamiento serializable versus instantánea, el problema de mármol (Craig Freedman)
• Las lecturas que involucran UDF en READ_COMMITTED_SNAPSHOT pueden parecer inconsistentes (Alex Kuznetsov)

Sé que este es un hilo viejo, pero diría en gran medida que el aislamiento de instantáneas es una bala mágica. Eliminará todo el bloqueo entre lectores y escritores. Sin embargo, no evitará que los escritores bloqueen a otros escritores. No hay forma de evitar eso.

En mi experiencia, la carga adicional en el TEMPDB es insignificante y los beneficios de las versiones de fila para reducir los lectores bloqueados son enormes.

Como referencia, el control de versiones de filas (aislamiento de instantáneas) es el método que Oracle ha utilizado durante décadas para lograr el aislamiento sin bloquear lectores y las bases de datos Oracle en las que he trabajado durante casi 20 años experimentan muchos menos problemas de bloqueo que SQL Server. Sin embargo, la mayoría de los desarrolladores de SQL dudan en usar el aislamiento de instantáneas porque solo han probado su código en bases de datos que usan la configuración predeterminada.

Un par de puntos adicionales para agregar a las otras respuestas:

SET ALLOW_SNAPSHOT_ISOLATION ONsolo permite el aislamiento de instantáneas en una base de datos. Para aprovecharlo, debe volver a codificar y SET TRANSACTION ISOLATION LEVEL SNAPSHOTpara las transacciones a las que desea que se aplique. El código de llamada deberá cambiarse para manejar los errores de conflicto de actualización.

Después SET READ_COMMITTED_SNAPSHOT ON, las declaraciones en lectura confirmada usan versiones de fila. Tenga en cuenta que se trata de versiones de filas de nivel de instrucción solo para lecturas . Para las actualizaciones, se recupera la fila "real" y se aplican bloqueos de actualización. Consulte la sección Resumen del comportamiento en Descripción de los niveles de aislamiento basados ​​en versiones de filas

De cualquier manera, sin pruebas exhaustivas, es probable que introduzca un conjunto completamente nuevo de problemas al sistema.

Creo que esto nos dará algo más cercano a Oracle donde si una transacción se actualiza, otras transacciones aún pueden leer los datos antiguos. ¿Es esto correcto?

Si, esto es correcto .

Vale la pena leer los enlaces en la respuesta de gbn y creo que lo mismo se aplica al MVCC predeterminado de Oracle que al Servidor SQL en modo de aislamiento de instantáneas. Añadiría que si comprende las posibles dificultades, los beneficios de IMO superan con creces las dificultades adicionales (hablando desde una perspectiva de Oracle), y, por supuesto, algunos problemas de bloqueo desaparecen legítimamente, ese es el punto de MVCC (también hay una clase de problemas de bloqueo que no desaparecerán debido a problemas de código, pero supongo que entiendes esto).

Estamos utilizando AISLAMIENTO INSTANTÁNEO en todos nuestros proyectos que utilizan SQL Server DB. No más errores de 1205 SQL, que no son causados ​​por un código de aplicación incorrecto, sino por el bloqueo de página predeterminado y el comportamiento de bloqueo de fila.

El impacto en el rendimiento es mínimo y hasta ahora han pasado 7 años, se han procesado cientos de millones de operaciones en diferentes sistemas, sin problemas con respecto a la AISLAMIENTO SNAPSHOT.

Las situaciones en las que varios subprocesos diferentes están actualizando la información crítica del negocio en una sola fila en paralelo son extremadamente excepcionales, y las posibilidades de que la AISLAMIENTO INSTANTÁNEA sea la causa de cualquier problema de inconsistencia son muy cercanas a cero.

Si tiene un sistema OLTP que, por diseño, actualiza una sola fila en función de los datos de la fila actual en muchos subprocesos, por supuesto, las INSTANTÁNEAS no son aceptables en tales casos.

lo teníamos activo y una extraña instrucción select sql ejecutando 4 alguna vez bloqueó todo el db sin importar cuántos núcleos y todo. Establecer RCSI desactivado solucionó eso. Lo encendería una vez que se enfrente a otros puntos muertos, no por defecto.