OPENDATASOURCE dentro de un SP

Hola.

A nivel de rendimiento, acceder a un servidor desde otro es complicado.
Puedes probar a vincular los servidores, pero eso tampoco te dará un
rendimiento espectacular. Si son muchos los datos a modificar, lo que yo
suelo hacer es evitar hacer la modificación en remoto. Es decir, accedo al
servidor remoto, me traigo a local lo que necesito para realizar la
actualización (vía insert...select) y lo dejo en una tabla temporal. Luego,
ya en local realizo el update. Puedes optar por un dts para ello también.

Si no es lo que buscas, nos comentas.

qwalgrande

"Jorge Serrano [MVP VB]" wrote:

Hola a todos,

quería hacer una pregunta acerca del rendimiento y funcionamiento de
OPENDATASOURCE dentro de un SP.

Me explico:

Dentro de un SP tengo una instrucción como por ejemplo:

UPDATE OPENDATASOURCE('SQLOLEDB','Data Source=MAQUINA;User
ID=sa;Password=loquesea').MIBASE.dbo.MITABLA SET ...

El caso es que he notado que el rendimiento de esta acción (el SP se ejecuta
desde un SERVIDOR apuntando a otro para hacer allí el UPDATE) es
increiblemente lento.

¿Existe alguna forma adicional de modificar, consultar, insertar, etc.,
datos dentro de un SP que apunten a otro repositorio de datos que no sea por
medio de OPENDATASOURCE o bien, existe alguna forma de que el rendimiento se
mejore ostensiblemente?, ¿o bien debo fastidiarme y pensar en otro mecanismo
de acceso?.
Si tengo que pensar mejor en otro mecanimo de acceso, ¿cuál pensáis desde
vuestra experiencia que es el mejor mecanismo de acceso?.

Muchas gracias a todos por vuestro tiempo.

Ah!, FELIZ NAVIDAD y FELIZ y PRÓSPERO AÑO NUEVO 2005.

Jorge Serrano Pérez
Microsoft MVP VB.NET
PortalVB.com
http://www.portalvb.com/
Weblog de Jorge Serrano
http://weblogs.golemproject.com/jorge/

Hola qwalgrande,

muchas gracias por tus comentarios, pero me temo que no va a ser lo que
necesito.

Vamos, la solución actual funciona, pero deseo mejorar el rendimiento. Lo
que planteas de pasar los datos a local y manejarlos en local para luego
ejecutar un DTS que envíe los datos al otro servidor, podría ser válido, lo
estudiaré, pero me temo que no es viable porque la actualización de los datos
los realiza en real diferentes procesos.

Tampoco es un tema de muchos o pocos datos, el SP puede ser llamado
repetitivamente un número de veces determinado con parámetros diferentes.
Imagínate como ejemplo una lista de personas que debe ser recorrida y para
cada una, mandar como parámetro de entrada el DNI de esa persona y respecto a
ese dato, realizar las actualizaciones pertinentes. Imagínate una lista de
75000 personas. Es decir, 75000 ejecuciones del mismo SP haciendo uso de esa
instrucción.

Si pudiera haber alguna solución que no modificando mucho la arquitectura de
la aplicación sirviera para mejorar el rendimiento genial. Sino, estudiaré lo
que comentas y veré si hay alguna forma de integrarlo.

Muchas gracias por tus comentarios.

Un saludo,

Jorge



"qwalgrande" wrote:

Hola.

A nivel de rendimiento, acceder a un servidor desde otro es complicado.
Puedes probar a vincular los servidores, pero eso tampoco te dará un
rendimiento espectacular. Si son muchos los datos a modificar, lo que yo
suelo hacer es evitar hacer la modificación en remoto. Es decir, accedo al
servidor remoto, me traigo a local lo que necesito para realizar la
actualización (vía insert...select) y lo dejo en una tabla temporal. Luego,
ya en local realizo el update. Puedes optar por un dts para ello también.

Si no es lo que buscas, nos comentas.

qwalgrande

"Jorge Serrano [MVP VB]" wrote:

> Hola a todos,
>
> quería hacer una pregunta acerca del rendimiento y funcionamiento de
> OPENDATASOURCE dentro de un SP.
>
> Me explico:
>
> Dentro de un SP tengo una instrucción como por ejemplo:
>
> UPDATE OPENDATASOURCE('SQLOLEDB','Data Source=MAQUINA;User
> ID=sa;Password=loquesea').MIBASE.dbo.MITABLA SET ...
>
> El caso es que he notado que el rendimiento de esta acción (el SP se ejecuta
> desde un SERVIDOR apuntando a otro para hacer allí el UPDATE) es
> increiblemente lento.
>
> ¿Existe alguna forma adicional de modificar, consultar, insertar, etc.,
> datos dentro de un SP que apunten a otro repositorio de datos que no sea por
> medio de OPENDATASOURCE o bien, existe alguna forma de que el rendimiento se
> mejore ostensiblemente?, ¿o bien debo fastidiarme y pensar en otro mecanismo
> de acceso?.
> Si tengo que pensar mejor en otro mecanimo de acceso, ¿cuál pensáis desde
> vuestra experiencia que es el mejor mecanismo de acceso?.
>
> Muchas gracias a todos por vuestro tiempo.
>
> Ah!, FELIZ NAVIDAD y FELIZ y PRÓSPERO AÑO NUEVO 2005.
>
> Jorge Serrano Pérez
> Microsoft MVP VB.NET
> PortalVB.com
> http://www.portalvb.com/
> Weblog de Jorge Serrano
> http://weblogs.golemproject.com/jorge/

Hola Jorge :-)

¿el origen de datos remoto es SQL Server?
¿has pensado en vincular el servidor (sp_addlinkedserver) y ejecutar la
consulta con <server>.<bd>.<propietario>.<objeto>?

En algunas pruebas que yo estuve haciendo hace algún tiempo con
Opendatasource, mirando el plan de ejecución me mostraba que se recuperaba
la tabla remota completa (!!!!), se aplicaba el filtro en local y se realiza
la actualización; este caso concreto se me solucionó "vinculando" el
servidor.
¿podrías comprobar el plan de ejecución?

Saludos y Feliz Navidad !!!!

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Jorge Serrano [MVP VB]"
wrote in
message news:

Hola qwalgrande,

muchas gracias por tus comentarios, pero me temo que no va a ser lo que
necesito.

Vamos, la solución actual funciona, pero deseo mejorar el rendimiento. Lo
que planteas de pasar los datos a local y manejarlos en local para luego
ejecutar un DTS que envíe los datos al otro servidor, podría ser válido,

lo

estudiaré, pero me temo que no es viable porque la actualización de los

datos

los realiza en real diferentes procesos.

Tampoco es un tema de muchos o pocos datos, el SP puede ser llamado
repetitivamente un número de veces determinado con parámetros diferentes.
Imagínate como ejemplo una lista de personas que debe ser recorrida y para
cada una, mandar como parámetro de entrada el DNI de esa persona y

respecto a

ese dato, realizar las actualizaciones pertinentes. Imagínate una lista de
75000 personas. Es decir, 75000 ejecuciones del mismo SP haciendo uso de

esa

instrucción.

Si pudiera haber alguna solución que no modificando mucho la arquitectura

de

la aplicación sirviera para mejorar el rendimiento genial. Sino, estudiaré

lo

que comentas y veré si hay alguna forma de integrarlo.

Muchas gracias por tus comentarios.

Un saludo,

Jorge



"qwalgrande" wrote:

> Hola.
>
> A nivel de rendimiento, acceder a un servidor desde otro es complicado.
> Puedes probar a vincular los servidores, pero eso tampoco te dará un
> rendimiento espectacular. Si son muchos los datos a modificar, lo que yo
> suelo hacer es evitar hacer la modificación en remoto. Es decir, accedo

al

> servidor remoto, me traigo a local lo que necesito para realizar la
> actualización (vía insert...select) y lo dejo en una tabla temporal.

Luego,

> ya en local realizo el update. Puedes optar por un dts para ello

también.

>
> Si no es lo que buscas, nos comentas.
>
> qwalgrande
>
> "Jorge Serrano [MVP VB]" wrote:
>
> > Hola a todos,
> >
> > quería hacer una pregunta acerca del rendimiento y funcionamiento de
> > OPENDATASOURCE dentro de un SP.
> >
> > Me explico:
> >
> > Dentro de un SP tengo una instrucción como por ejemplo:
> >
> > UPDATE OPENDATASOURCE('SQLOLEDB','Data Source=MAQUINA;User
> > ID=sa;Password=loquesea').MIBASE.dbo.MITABLA SET ...
> >
> > El caso es que he notado que el rendimiento de esta acción (el SP se

ejecuta

> > desde un SERVIDOR apuntando a otro para hacer allí el UPDATE) es
> > increiblemente lento.
> >
> > ¿Existe alguna forma adicional de modificar, consultar, insertar,

etc.,

> > datos dentro de un SP que apunten a otro repositorio de datos que no

sea por

> > medio de OPENDATASOURCE o bien, existe alguna forma de que el

rendimiento se

> > mejore ostensiblemente?, ¿o bien debo fastidiarme y pensar en otro

mecanismo

> > de acceso?.
> > Si tengo que pensar mejor en otro mecanimo de acceso, ¿cuál pensáis

desde

> > vuestra experiencia que es el mejor mecanismo de acceso?.
> >
> > Muchas gracias a todos por vuestro tiempo.
> >
> > Ah!, FELIZ NAVIDAD y FELIZ y PRÓSPERO AÑO NUEVO 2005.
> >
> > Jorge Serrano Pérez
> > Microsoft MVP VB.NET
> > PortalVB.com
> > http://www.portalvb.com/
> > Weblog de Jorge Serrano
> > http://weblogs.golemproject.com/jorge/

Hola.

Como bien dices, para modificar un registro (o pocos registros, digamos
menos de 1000) muchas veces, un DTS no es la solución. Pero siguiendo el caso
de tu ejemplo, puedes hacer algo así:

create procedure Cambiar_Telefono (@pDNI varchar(15), @pTelefono
varchar(15)) as
/*Añadir control de transacciones*/

select DNI, Telefono into #Pers from [Remoto].MiDB.dbo.Personas where DNI =
@DNI

update L set L.Telefono = @pTelefono
from Personas L inner join #Pers R on L.DNI = R.DNI

/*Añadir control de errore y transacciones*/

return 0


Así, te traes un registro del servidor remoto y haces la actualización en
local. Si esto tampoco te sirve, puedes volver a preguntar.

qwalgrande.

"Jorge Serrano [MVP VB]" wrote:

Hola qwalgrande,

muchas gracias por tus comentarios, pero me temo que no va a ser lo que
necesito.

Vamos, la solución actual funciona, pero deseo mejorar el rendimiento. Lo
que planteas de pasar los datos a local y manejarlos en local para luego
ejecutar un DTS que envíe los datos al otro servidor, podría ser válido, lo
estudiaré, pero me temo que no es viable porque la actualización de los datos
los realiza en real diferentes procesos.

Tampoco es un tema de muchos o pocos datos, el SP puede ser llamado
repetitivamente un número de veces determinado con parámetros diferentes.
Imagínate como ejemplo una lista de personas que debe ser recorrida y para
cada una, mandar como parámetro de entrada el DNI de esa persona y respecto a
ese dato, realizar las actualizaciones pertinentes. Imagínate una lista de
75000 personas. Es decir, 75000 ejecuciones del mismo SP haciendo uso de esa
instrucción.

Si pudiera haber alguna solución que no modificando mucho la arquitectura de
la aplicación sirviera para mejorar el rendimiento genial. Sino, estudiaré lo
que comentas y veré si hay alguna forma de integrarlo.

Muchas gracias por tus comentarios.

Un saludo,

Jorge



"qwalgrande" wrote:

> Hola.
>
> A nivel de rendimiento, acceder a un servidor desde otro es complicado.
> Puedes probar a vincular los servidores, pero eso tampoco te dará un
> rendimiento espectacular. Si son muchos los datos a modificar, lo que yo
> suelo hacer es evitar hacer la modificación en remoto. Es decir, accedo al
> servidor remoto, me traigo a local lo que necesito para realizar la
> actualización (vía insert...select) y lo dejo en una tabla temporal. Luego,
> ya en local realizo el update. Puedes optar por un dts para ello también.
>
> Si no es lo que buscas, nos comentas.
>
> qwalgrande
>
> "Jorge Serrano [MVP VB]" wrote:
>
> > Hola a todos,
> >
> > quería hacer una pregunta acerca del rendimiento y funcionamiento de
> > OPENDATASOURCE dentro de un SP.
> >
> > Me explico:
> >
> > Dentro de un SP tengo una instrucción como por ejemplo:
> >
> > UPDATE OPENDATASOURCE('SQLOLEDB','Data Source=MAQUINA;User
> > ID=sa;Password=loquesea').MIBASE.dbo.MITABLA SET ...
> >
> > El caso es que he notado que el rendimiento de esta acción (el SP se ejecuta
> > desde un SERVIDOR apuntando a otro para hacer allí el UPDATE) es
> > increiblemente lento.
> >
> > ¿Existe alguna forma adicional de modificar, consultar, insertar, etc.,
> > datos dentro de un SP que apunten a otro repositorio de datos que no sea por
> > medio de OPENDATASOURCE o bien, existe alguna forma de que el rendimiento se
> > mejore ostensiblemente?, ¿o bien debo fastidiarme y pensar en otro mecanismo
> > de acceso?.
> > Si tengo que pensar mejor en otro mecanimo de acceso, ¿cuál pensáis desde
> > vuestra experiencia que es el mejor mecanismo de acceso?.
> >
> > Muchas gracias a todos por vuestro tiempo.
> >
> > Ah!, FELIZ NAVIDAD y FELIZ y PRÓSPERO AÑO NUEVO 2005.
> >
> > Jorge Serrano Pérez
> > Microsoft MVP VB.NET
> > PortalVB.com
> > http://www.portalvb.com/
> > Weblog de Jorge Serrano
> > http://weblogs.golemproject.com/jorge/

Ok!. :-)

lo veré a ver que hago finalmente.

Muchas gracias!

Un saludo,

Jorge Serrano
MVP VB.NET


"qwalgrande" wrote:

Hola.

Como bien dices, para modificar un registro (o pocos registros, digamos
menos de 1000) muchas veces, un DTS no es la solución. Pero siguiendo el caso
de tu ejemplo, puedes hacer algo así:

create procedure Cambiar_Telefono (@pDNI varchar(15), @pTelefono
varchar(15)) as
/*Añadir control de transacciones*/

select DNI, Telefono into #Pers from [Remoto].MiDB.dbo.Personas where DNI =
@DNI

update L set L.Telefono = @pTelefono
from Personas L inner join #Pers R on L.DNI = R.DNI

/*Añadir control de errore y transacciones*/

return 0


Así, te traes un registro del servidor remoto y haces la actualización en
local. Si esto tampoco te sirve, puedes volver a preguntar.

qwalgrande.

"Jorge Serrano [MVP VB]" wrote:

> Hola qwalgrande,
>
> muchas gracias por tus comentarios, pero me temo que no va a ser lo que
> necesito.
>
> Vamos, la solución actual funciona, pero deseo mejorar el rendimiento. Lo
> que planteas de pasar los datos a local y manejarlos en local para luego
> ejecutar un DTS que envíe los datos al otro servidor, podría ser válido, lo
> estudiaré, pero me temo que no es viable porque la actualización de los datos
> los realiza en real diferentes procesos.
>
> Tampoco es un tema de muchos o pocos datos, el SP puede ser llamado
> repetitivamente un número de veces determinado con parámetros diferentes.
> Imagínate como ejemplo una lista de personas que debe ser recorrida y para
> cada una, mandar como parámetro de entrada el DNI de esa persona y respecto a
> ese dato, realizar las actualizaciones pertinentes. Imagínate una lista de
> 75000 personas. Es decir, 75000 ejecuciones del mismo SP haciendo uso de esa
> instrucción.
>
> Si pudiera haber alguna solución que no modificando mucho la arquitectura de
> la aplicación sirviera para mejorar el rendimiento genial. Sino, estudiaré lo
> que comentas y veré si hay alguna forma de integrarlo.
>
> Muchas gracias por tus comentarios.
>
> Un saludo,
>
> Jorge
>
>
>
> "qwalgrande" wrote:
>
> > Hola.
> >
> > A nivel de rendimiento, acceder a un servidor desde otro es complicado.
> > Puedes probar a vincular los servidores, pero eso tampoco te dará un
> > rendimiento espectacular. Si son muchos los datos a modificar, lo que yo
> > suelo hacer es evitar hacer la modificación en remoto. Es decir, accedo al
> > servidor remoto, me traigo a local lo que necesito para realizar la
> > actualización (vía insert...select) y lo dejo en una tabla temporal. Luego,
> > ya en local realizo el update. Puedes optar por un dts para ello también.
> >
> > Si no es lo que buscas, nos comentas.
> >
> > qwalgrande
> >
> > "Jorge Serrano [MVP VB]" wrote:
> >
> > > Hola a todos,
> > >
> > > quería hacer una pregunta acerca del rendimiento y funcionamiento de
> > > OPENDATASOURCE dentro de un SP.
> > >
> > > Me explico:
> > >
> > > Dentro de un SP tengo una instrucción como por ejemplo:
> > >
> > > UPDATE OPENDATASOURCE('SQLOLEDB','Data Source=MAQUINA;User
> > > ID=sa;Password=loquesea').MIBASE.dbo.MITABLA SET ...
> > >
> > > El caso es que he notado que el rendimiento de esta acción (el SP se ejecuta
> > > desde un SERVIDOR apuntando a otro para hacer allí el UPDATE) es
> > > increiblemente lento.
> > >
> > > ¿Existe alguna forma adicional de modificar, consultar, insertar, etc.,
> > > datos dentro de un SP que apunten a otro repositorio de datos que no sea por
> > > medio de OPENDATASOURCE o bien, existe alguna forma de que el rendimiento se
> > > mejore ostensiblemente?, ¿o bien debo fastidiarme y pensar en otro mecanismo
> > > de acceso?.
> > > Si tengo que pensar mejor en otro mecanimo de acceso, ¿cuál pensáis desde
> > > vuestra experiencia que es el mejor mecanismo de acceso?.
> > >
> > > Muchas gracias a todos por vuestro tiempo.
> > >
> > > Ah!, FELIZ NAVIDAD y FELIZ y PRÓSPERO AÑO NUEVO 2005.
> > >
> > > Jorge Serrano Pérez
> > > Microsoft MVP VB.NET
> > > PortalVB.com
> > > http://www.portalvb.com/
> > > Weblog de Jorge Serrano
> > > http://weblogs.golemproject.com/jorge/