sql server 2005 - tipos - ¿Cómo puedo usar transacciones que abarcan procedimientos encadenados en varios servidores?
transacciones mysql (7)
Estoy intentando probar una proposición que uno de nuestros proveedores nos presentó para acceder a su base de datos de productos y se refiere a consultas y transacciones que abarcan varios servidores. Nunca antes lo había hecho directamente en la base de datos y para ser sincero, no tengo ni idea, así que estoy intentando simular una prueba de que esto funciona al menos conceptualmente.
Tengo dos servidores SQL Server 2005. Vamos por el bien de llamarlos Server1 y Server2 [hold your aplause] cada uno contiene una base de datos ficticia. La base de datos ficticia en el Servidor1 se llama Fuente y en el Servidor2 se llama Destino, solo para mantener las cosas simples. Cada una de las bases de datos contiene una sola tabla llamada Entrada y Salida, respectivamente, por lo que la estructura se explica casi de la siguiente manera:
- Server1.Source.dbo.Input
- Server2.Destination.dbo.Output
Tengo un procedimiento almacenado en Server2 llamado WriteDataToOutput que recibe un único argumento Varchar y escribe su contenido en la tabla de salida.
Ahora comienza la dificultad:
- Quiero crear un procedimiento almacenado en Server1.Source que llama al procedimiento almacenado WriteDataToOutput definido en Server2, que parece ser el paso simple.
- Quiero que esta llamada sea parte de una transacción, de modo que si el procedimiento que la invoca falla, la transacción completa se revierte.
Y aquí termina mi conocimiento de qué hacer. ¿Alguien puede señalarme en la dirección correcta? Intenté esto en dos bases de datos diferentes en el mismo servidor, y funcionó muy bien, lo que me llevó a suponer que funcionará en diferentes servidores, la pregunta es, ¿cómo hago para hacer tal cosa? ¿Dónde empiezo?
Al usar servidores vinculados, puede ejecutar procedimientos almacenados en cualquier servidor dentro de una sola transacción usando DTC (Coordinador Transactino Distribuido). Definitivamente querrás hacer un análisis de rendimiento. He descubierto que algunos SP que usan enlaces pueden ralentizar drásticamente el rendimiento de la base de datos, especialmente si intenta unirse a los conjuntos de resultados de cada uno de los dos servidores.
Como otros han notado, acepto que un servidor vinculado es la mejor manera de hacerlo.
Aquí hay un par de consejos que me atraparon la primera vez que lidié con servidores vinculados:
Si el servidor vinculado es una instancia, asegúrese de poner el nombre entre corchetes. Por ejemplo [SERVERNAME / INSTANCENAME].
Utilice un alias para la tabla o vista desde el servidor vinculado o obtendrá un error de "no se puede vincular el identificador de varias partes". Hay un límite de una convención de nomenclatura de 4 partes. Por ejemplo, SERVER.DATABASE.dbo.TABLE.FIELD tiene cinco partes y dará un error. Sin embargo,
SELECT linked.FieldName FROM SERVER.DATABASE.dbo.TABLE AS linked
funcionará bien
Configure un servidor vinculado, luego debería poder ejecutar selecciones / inserciones / actualizaciones en los servidores. Algo como:
INSERT INTO Server2.Destination.dbo.Output
SELECT * FROM Input
WHERE <Criteria>
Esto supone que está ejecutando la consulta de Server1.Source, por lo que no necesitaría calificar por completo.
Debe configurar un enlace entre un servidor y otro.
Querrá vincular los servidores:
para el paso 2, necesita tener Coordinador de transacciones distribuidas ejecutándose, también necesita usar SET XACT_ABORT ON para asegurarse de que todo se revierte; también debe habilitar RPC, que está desactivado por defecto en 2005 y posteriores
Hay un montón de cosas que pueden morderte en el cuello
MSDN dice que puede tener transacciones entre los servidores vinculados si usa el comando BEGIN DISTRIBUTED TRANSACTION.
Sin embargo, recuerdo que tuve problemas para llamar a un procedimiento almacenado en un servidor vinculado, pero trabajé en torno a él, en lugar de resolverlo.