¿Agrego lectura confirmada después de SET TRANSACTION ISOLATION LEVEL SERIALIZABLE?

Dentro de un procedimiento almacenado, tengo lo siguiente: (servidor SQL 2008)

 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
 BEGIN TRANSACTION getStuff
 BEGIN TRY 
    /*  some selects, updates, etc, etc. */
    ....
    COMMIT TRANSACTION getStuff
 END TRY
 BEGIN CATCH 
   ...
 END CATCH

Como esto se basa en transacciones, pensé que el resto de las conexiones de la base de datos no se verán afectadas por SERIALIZABLE.

¿Necesito establecer implícitamente el nivel de aislamiento para leer confirmado después de mi confirmación? ¿Esto afectará negativamente a otras conexiones entre mi servidor de aplicaciones y el servidor de la base de datos?

El comando es TRANSACTION ISOLATION LEVEL, no SERVER ISOLATION LEVEL. Solo cambia el nivel de aislamiento para el alcance de la transacción.

No, no tiene que volver a establecer implícitamente el nivel de aislamiento para leer confirmado.

De libros en línea .

Si emite SET TRANSACTION ISOLATION LEVEL en un procedimiento almacenado o disparador, cuando el objeto devuelve el control, el nivel de aislamiento se restablece al nivel vigente cuando se invocó el objeto. Por ejemplo, si establece REPEATABLE READ en un lote y el lote llama a un procedimiento almacenado que establece el nivel de aislamiento en SERIALIZABLE, la configuración del nivel de aislamiento vuelve a REPEATABLE READ cuando el procedimiento almacenado devuelve el control al lote.

El comando que publicó acaba de ejecutar la transacción en el SP con TRANSACTION ISOLATION LEVEL SERIALIZABLE. Otras conexiones tendrán el nivel de aislamiento predeterminado: lectura confirmada (a menos que se especifique explícitamente un nivel de aislamiento diferente).

Hay una excelente serie de Paul White : niveles de aislamiento de SQL Server: una serie que lo ayudará a comprender en profundidad lo que significan y hacen los diferentes niveles de aislamiento cuando se usan.

Un algoritmo bastante nuevo que evita la mayoría de las desventajas de los enfoques anteriores. Utiliza un enfoque optimista, permitiendo que las transacciones continúen sin bloqueo. Cuando una transacción desea confirmar, se verifica y se cancela si la ejecución no fue serializable. Más detalles de todos los enfoques en: http://writeulearn.com/relational-database-transactions/