tengo un server con dos bases de datos, y ahora hemos comprado un
segundo server, para separar las bases de datos, tengo muchos
procedimeintos almacenados consultas, y codigo de otra indole que
hacen querys entre bases de datos, y como estaban en el mismo server
pues no habia problemas.



como es sql server 2000 no podemos cerar entidades para
que sea tranparente porque por naturaleza el 2000 no es para bd
distribuidas.

el linkserver no podemos porque tenemos muchos
nolock y esta onda no me desja desbloquearlos, con el openqury no me
deja guardar los valores que trae en variables, el procecimiento de
sp_executesql si deja pero alli no puedo ponerlo cuando son tablas que
hagan referencia a las dos, y no puedo crear tablas remotas.



alguna idea que pueda usar???,

nota: no me puedo cambiar a sql server 2005 porque un sistema que tenemos requiere
unas transacciones que solo venian con el sql server 6 y no podemos
modificarlo porquie es propietario


de antemano gracias

__________________
Consejos de programación

Que onda, despes de mucha investigación pruebas y la mother,

puedo responderme yo solo, y les dejo aqui en lo que hemos concluido
espero que a más de uno le sirva.

Trabajando con Link Servers en SQL SERVER


Algunas veces cuando queremos trabajar con dos bases de datos diferentes, y no queremos modificar lo que son los codigos PHP, o Java o lo que tengamos a fin de no tener que crear otro objeto conexión empatar los registros, y hacerlo más rápido, optamos por crear links entre los servidores de las bases de datos,

Pero debemos de tener que tomar en cuenta muchos aspectos para trabajar de una forma eficiente.


Primero que nada el usuario y la contraseña con el que creamos y ejecutamos los link Server debe de ser el mismo en los dos servidores.

Las transacciones distribuidas con los link Server pueden generar más procesos que las transacciones que se generan en un mismo Server, esto se debe a que participa más de un servidor en las transacciones aparte del trafico de la red que este genera, las transacciones distribuidas se deben de evitar cuando se pueden evitar. Es decir solo se deben usar transacciones distribuidas cuando no hay otra forma de lograr un objetivo definido.


Si necesita acceder a los datos desde un servidor remoto desde una consulta, es más eficiente llevar un linked Server en lugar de usar las funciones de OPENROWSET o la OPENDATASOURCE

Por defecto cuando se ejecuta una consulta con un linked Server esta se ejecuta a nivel local, esto no puede ser tan eficiente en funciona de los datos que se envían al servidor local para su procesamiento, a veces es más eficiente pasar el query completo al servidor remoto para que se ejecute y solo regresaría el conjunto de registros, para ser procesados en el servidor local. Con el OPENQUERY podemos enviar una consulta para ser procesada en el servidor remoto.

Cuando ejecutas consultas distribuidas con linked servers si los servidores tienen los mismos collations entonces puede reducir los procesos que se ejecutan y aumentar el rendimiento si se ejecuta el SP_SERVEROPTION que es la compatibilidad entre collations esto es que el SQL Server creara una relación para hacer compatibles los tipos de datos de ambas bases de datos, se puede configurar en el Enterprise Manager


Si esto no esta configurado el servidor remoto traerá todo el conjunto de datos a fin de que las condiciones se apliquen en el servidor local lo que nos ocasionara problemas.

Si se ejecutan transacciones distribuidas hay que asegurarse de que la comunicación entre los servidores sea rápida, esto quiere decir que por lo menos estén en la misma subred.

En SQL Server 2000 y 2005, cuando se crea un servidor vinculado, en la pestaña Opciones del servidor, hay una opción llamada y tiempo de conexión Query Timeout. La configuración predeterminada para ambas opciones es 0, lo que significa que no hay tiempo definido de cualquiera de estas opciones.




Para aumentar el rendimiento las operaciones que se deben de ejecutar a nivel local son:

 Operaciones de conversión de datos
 Consultas que utilicen bits, hora y fecha, o tipos de datos uniqueidentifier
 Consultas que utilicen la cláusula TOP
 INSERTS, UPDATES, or DELETES


Si deseas saber exactamente que consultas se están ejecutando en local y que consultas en remoto en el Management Studio o en el Query Analyzer puedes revisar el plan de consulta

__________________
Consejos de programación

otra vez muy interesante eduardo

__________________

y eso no se contagia?

__________________

No siempre que uses el modulo sql_condom_secure cuando vayas a hacer las Inserts.

¿Que cuando le vaya a insertar qué cosa en dónde?

__________________
Si seguimos haciendo lo que estamos haciendo, seguiremos consiguiendo lo que estamos consiguiendo.

que tal amigos, espero puedan ayudarme estoy usando servidores vinculados para acceder a una BD de otro servidor, el manejo de transacciones lo hago desde la aplicación dentro de la cual invoco a un procedimiento almacenado que en primera instancia actualizaba datos de las tablas del servidor local y tablas del servidor vinculado como se detalla a continuación:

--inserción en servidor local
insert into alumno (id_alumno,alu_periodo,id_empresa,id_distrito,alu_ nombres,alu_apellidos,
alu_direccion,alu_telefono,alu_fec_nacimiento,alu_ lib_electoral,
alu_centro_estudio,alu_categoria,alu_estado,alu_cl iente,alu_sexo,alu_fecha,
alu_mac,alu_correo_ele,alu_celular)
values (@codigo_alu,@periodo,@emp,@distri,@nombre,@apell, @direc,
@telef,@fecnan,@dni,@cest,NULL,
@est,@id_cliente,@sexo, @fecha, @mac, @corr,@celu)

--inserción en servidor vinculado
insert into CAMPUS_SISE_VINCULADO.CAMPUS_SISE.dbo.alumno
(id_alumno,id_local,alu_periodo,id_empresa,id_dist rito,alu_nombres,
alu_apellidos,alu_direccion,alu_telefono,alu_fec_n acimiento,alu_lib_electoral,
alu_centro_estudio,alu_categoria,alu_estado,alu_cl iente,alu_sexo,alu_fecha,
alu_mac,alu_correo_ele,alu_celular)
values (@alumno,@centro_lucro,@periodo,@emp,@distri,@nomb re,@apell,@direc,
@telef,@fecnan,@dni,@cest,NULL,@est,@id_cliente,@s exo,@fecha,@mac,
@corr,@celu)

Pero al ejecutar el procedimiento desde la aplicación me generaba error indicando que se debe usar transacciones distribuídas por lo que no me quedó otra opción que trabajarlo en 2 procedimientos separados uno para la actualización local y otro para la actualización del servidor vinculado, el manejo de transacciones se realiza en el servidor local desde la aplicación.

Hasta allí no tenía problemas, pero estoy verificando que en algunas ocasiones algunos registros se actualizan en el servidor local pero no en el servidor remoto.

No se si esto se deba a que no trabajo todo en una sola transacción, teniendo en cuenta que varios usuarios pueden ejecutar el proceso al mismo tiempo.

Espero me puedan ayudar es super urgente......