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