Link Server ayuda

05/11/2005 - 02:48 por Natacha | Informe spam
Hola

Imaginense que estamos implementando un esquema de link server un poco
complejo pero nada que hacer, no poseemos los fuentes y debemos hacer una
interfaz entre varios aplicativos...

Las sentencias se resumen en muchos procedimientos almacenados que se
ejecutan en cada uno de los 3 servidores que tenemos linkeados.

Fuera de eso, son servidores que estan en ciudades diferentes.

El esquema es mas o menos así

Servidor 1
exec sp 1 ..
exec sp 2..
exec sp 3..
exec servidor 2.bd1.dbo.sp1 --
exec servidor 2.bd1.dbo.sp2 --
exec servidor 2..bd1.dbo.sp3 --
exec servidor 3.bd1.dbo.sp1 --
exer servidor 3.bd1.dbo.sp2 --

Todo esto está disparándose desde un trigger por un evento de insert en una
tabla del servidor 1.

Resulta que si se ejecutan las sentencias con 1 solo usuario no hay
problema, ellas se ejecutan en su totalidad y con un tiempo de respuesta muy
bueno.

El problema está cuando se conectan varios usuarios a la vez.

En todo el proceso ya hemos usado las siguientes optimizaciones pero nada:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
set xact_abort on
set ANSI_NULLS on

El problema radica en que si enviamos las sentencias por aparte todo
funciona sin importar el numero de usuarios, pero en el momento en que
interviene la transaccion distribuida con concurrencia tenemos problemas de
interbloqueos o abrazos moratlaes.

Muchas gracias por la ayuda que me puedan brindar

Preguntas similare

Leer las respuestas

#1 Isaias
05/11/2005 - 02:49 | Informe spam
En lo personal, no me gusta ejecutar STORE PROCEDURES desde los triggers, en
tu lugar, yo ejecutaria los stores desde el store mismo que hace la
actualizacion a la tabla, de esta forma, bien puedes controlar los dead_lock
con Begin Tran, Commit Tran, Rollback Tran.
Saludos
IIslas


"Natacha" escribió:

Hola

Imaginense que estamos implementando un esquema de link server un poco
complejo pero nada que hacer, no poseemos los fuentes y debemos hacer una
interfaz entre varios aplicativos...

Las sentencias se resumen en muchos procedimientos almacenados que se
ejecutan en cada uno de los 3 servidores que tenemos linkeados.

Fuera de eso, son servidores que estan en ciudades diferentes.

El esquema es mas o menos así

Servidor 1
exec sp 1 ..
exec sp 2..
exec sp 3..
exec servidor 2.bd1.dbo.sp1 --
exec servidor 2.bd1.dbo.sp2 --
exec servidor 2..bd1.dbo.sp3 --
exec servidor 3.bd1.dbo.sp1 --
exer servidor 3.bd1.dbo.sp2 --

Todo esto está disparándose desde un trigger por un evento de insert en una
tabla del servidor 1.

Resulta que si se ejecutan las sentencias con 1 solo usuario no hay
problema, ellas se ejecutan en su totalidad y con un tiempo de respuesta muy
bueno.

El problema está cuando se conectan varios usuarios a la vez.

En todo el proceso ya hemos usado las siguientes optimizaciones pero nada:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
set xact_abort on
set ANSI_NULLS on

El problema radica en que si enviamos las sentencias por aparte todo
funciona sin importar el numero de usuarios, pero en el momento en que
interviene la transaccion distribuida con concurrencia tenemos problemas de
interbloqueos o abrazos moratlaes.

Muchas gracias por la ayuda que me puedan brindar

Respuesta Responder a este mensaje
#2 Maxi [MVP SQL Server]
06/11/2005 - 17:31 | Informe spam
Si, yo estoy contigo y por lo siguiente: si hace esto el trigge estara
pensado por registro y no por instruccion y si quiere hacer q todos los
registros pasen por el Store debera usar Cursores con lo cual..


[Microsoft MVP SQL SERVER]
Culminis SQL-Server Speakers (http://latam.culminis.com)

Maxi - Buenos Aires - Argentina
Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Isaias" escribió en el mensaje
news:
En lo personal, no me gusta ejecutar STORE PROCEDURES desde los triggers,
en
tu lugar, yo ejecutaria los stores desde el store mismo que hace la
actualizacion a la tabla, de esta forma, bien puedes controlar los
dead_lock
con Begin Tran, Commit Tran, Rollback Tran.
Saludos
IIslas


"Natacha" escribió:

Hola

Imaginense que estamos implementando un esquema de link server un poco
complejo pero nada que hacer, no poseemos los fuentes y debemos hacer una
interfaz entre varios aplicativos...

Las sentencias se resumen en muchos procedimientos almacenados que se
ejecutan en cada uno de los 3 servidores que tenemos linkeados.

Fuera de eso, son servidores que estan en ciudades diferentes.

El esquema es mas o menos así

Servidor 1
exec sp 1 ..
exec sp 2..
exec sp 3..
exec servidor 2.bd1.dbo.sp1 --
exec servidor 2.bd1.dbo.sp2 --
exec servidor 2..bd1.dbo.sp3 --
exec servidor 3.bd1.dbo.sp1 --
exer servidor 3.bd1.dbo.sp2 --

Todo esto está disparándose desde un trigger por un evento de insert en
una
tabla del servidor 1.

Resulta que si se ejecutan las sentencias con 1 solo usuario no hay
problema, ellas se ejecutan en su totalidad y con un tiempo de respuesta
muy
bueno.

El problema está cuando se conectan varios usuarios a la vez.

En todo el proceso ya hemos usado las siguientes optimizaciones pero
nada:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
set xact_abort on
set ANSI_NULLS on

El problema radica en que si enviamos las sentencias por aparte todo
funciona sin importar el numero de usuarios, pero en el momento en que
interviene la transaccion distribuida con concurrencia tenemos problemas
de
interbloqueos o abrazos moratlaes.

Muchas gracias por la ayuda que me puedan brindar

Respuesta Responder a este mensaje
#3 Natacha
08/11/2005 - 15:51 | Informe spam
Si...estoy de acuerdo

Lo malo es que la actualizacion de esta tabla no se hace por sp sino por
codigo fuente y los fuentes no los podemos tocar.

Entonces se hace el update por codigo fuente, se dispara un trigger por
update y se lanzan todos los sp que les comenté.



"Maxi [MVP SQL Server]" escribió:

Si, yo estoy contigo y por lo siguiente: si hace esto el trigge estara
pensado por registro y no por instruccion y si quiere hacer q todos los
registros pasen por el Store debera usar Cursores con lo cual..


[Microsoft MVP SQL SERVER]
Culminis SQL-Server Speakers (http://latam.culminis.com)

Maxi - Buenos Aires - Argentina
Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Isaias" escribió en el mensaje
news:
> En lo personal, no me gusta ejecutar STORE PROCEDURES desde los triggers,
> en
> tu lugar, yo ejecutaria los stores desde el store mismo que hace la
> actualizacion a la tabla, de esta forma, bien puedes controlar los
> dead_lock
> con Begin Tran, Commit Tran, Rollback Tran.
> Saludos
> IIslas
>
>
> "Natacha" escribió:
>
>> Hola
>>
>> Imaginense que estamos implementando un esquema de link server un poco
>> complejo pero nada que hacer, no poseemos los fuentes y debemos hacer una
>> interfaz entre varios aplicativos...
>>
>> Las sentencias se resumen en muchos procedimientos almacenados que se
>> ejecutan en cada uno de los 3 servidores que tenemos linkeados.
>>
>> Fuera de eso, son servidores que estan en ciudades diferentes.
>>
>> El esquema es mas o menos así
>>
>> Servidor 1
>> exec sp 1 ..
>> exec sp 2..
>> exec sp 3..
>> exec servidor 2.bd1.dbo.sp1 --
>> exec servidor 2.bd1.dbo.sp2 --
>> exec servidor 2..bd1.dbo.sp3 --
>> exec servidor 3.bd1.dbo.sp1 --
>> exer servidor 3.bd1.dbo.sp2 --
>>
>> Todo esto está disparándose desde un trigger por un evento de insert en
>> una
>> tabla del servidor 1.
>>
>> Resulta que si se ejecutan las sentencias con 1 solo usuario no hay
>> problema, ellas se ejecutan en su totalidad y con un tiempo de respuesta
>> muy
>> bueno.
>>
>> El problema está cuando se conectan varios usuarios a la vez.
>>
>> En todo el proceso ya hemos usado las siguientes optimizaciones pero
>> nada:
>>
>> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> set xact_abort on
>> set ANSI_NULLS on
>>
>> El problema radica en que si enviamos las sentencias por aparte todo
>> funciona sin importar el numero de usuarios, pero en el momento en que
>> interviene la transaccion distribuida con concurrencia tenemos problemas
>> de
>> interbloqueos o abrazos moratlaes.
>>
>> Muchas gracias por la ayuda que me puedan brindar
>>



Respuesta Responder a este mensaje
#4 Maxi [MVP]
08/11/2005 - 16:04 | Informe spam
ok, controla bien que el trigger funcione en conjunto de registros con lo
cual seguramente y por como pinta la cosa vas a tener q aplicar algun cursor
:(


Salu2
-
[MVP] SQL Server
Orador para Culminis Latam
Miembro de GUESS



"Natacha" escribió en el mensaje
news:
Si...estoy de acuerdo

Lo malo es que la actualizacion de esta tabla no se hace por sp sino por
codigo fuente y los fuentes no los podemos tocar.

Entonces se hace el update por codigo fuente, se dispara un trigger por
update y se lanzan todos los sp que les comenté.



"Maxi [MVP SQL Server]" escribió:

Si, yo estoy contigo y por lo siguiente: si hace esto el trigge estara
pensado por registro y no por instruccion y si quiere hacer q todos los
registros pasen por el Store debera usar Cursores con lo cual..


[Microsoft MVP SQL SERVER]
Culminis SQL-Server Speakers (http://latam.culminis.com)

Maxi - Buenos Aires - Argentina
Msn_messager:
mail: Maxi.da[arroba]gmail.com

"Isaias" escribió en el mensaje
news:
> En lo personal, no me gusta ejecutar STORE PROCEDURES desde los
> triggers,
> en
> tu lugar, yo ejecutaria los stores desde el store mismo que hace la
> actualizacion a la tabla, de esta forma, bien puedes controlar los
> dead_lock
> con Begin Tran, Commit Tran, Rollback Tran.
> Saludos
> IIslas
>
>
> "Natacha" escribió:
>
>> Hola
>>
>> Imaginense que estamos implementando un esquema de link server un poco
>> complejo pero nada que hacer, no poseemos los fuentes y debemos hacer
>> una
>> interfaz entre varios aplicativos...
>>
>> Las sentencias se resumen en muchos procedimientos almacenados que se
>> ejecutan en cada uno de los 3 servidores que tenemos linkeados.
>>
>> Fuera de eso, son servidores que estan en ciudades diferentes.
>>
>> El esquema es mas o menos así
>>
>> Servidor 1
>> exec sp 1 ..
>> exec sp 2..
>> exec sp 3..
>> exec servidor 2.bd1.dbo.sp1 --
>> exec servidor 2.bd1.dbo.sp2 --
>> exec servidor 2..bd1.dbo.sp3 --
>> exec servidor 3.bd1.dbo.sp1 --
>> exer servidor 3.bd1.dbo.sp2 --
>>
>> Todo esto está disparándose desde un trigger por un evento de insert
>> en
>> una
>> tabla del servidor 1.
>>
>> Resulta que si se ejecutan las sentencias con 1 solo usuario no hay
>> problema, ellas se ejecutan en su totalidad y con un tiempo de
>> respuesta
>> muy
>> bueno.
>>
>> El problema está cuando se conectan varios usuarios a la vez.
>>
>> En todo el proceso ya hemos usado las siguientes optimizaciones pero
>> nada:
>>
>> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> set xact_abort on
>> set ANSI_NULLS on
>>
>> El problema radica en que si enviamos las sentencias por aparte todo
>> funciona sin importar el numero de usuarios, pero en el momento en que
>> interviene la transaccion distribuida con concurrencia tenemos
>> problemas
>> de
>> interbloqueos o abrazos moratlaes.
>>
>> Muchas gracias por la ayuda que me puedan brindar
>>



email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida