Una de esas características interesantes de SQL Server que a menudo pasan desapercibidas es la capacidad de conectarse y consultar datos de diversas fuentes de datos ajenas a nuestra instancia. Esto se consigue gracias a los Linked Servers (Servidores Vinculados) que facilitan la integración de datos distribuidos, permitiéndonos interactuar con otras bases de datos como si fueran parte de nuestra instancia local de SQL Server. Ya sea porque necesitemos acceder a datos de otro servidor SQL, de Oracle, archivos Excel o incluso consultas LDAP los Linked Server son una herramienta imprescindible.
¿Qué es un Linked Server en SQL Server?
Un linked server, o servidor vinculado, es una opción de SQL Server que nos permite establecer una conexión con otra fuente de datos, que puede ser otra instancia de SQL Server, un servidor Oracle, un servidor MySQL, una hoja de cálculo y muchas más opciones. Esta herramienta está pensada para escenarios donde necesitemos acceder a datos almacenados en distintos sistemas para realizar análisis, reportes o integraciones de datos.
La principal ventaja de los linked servers es que nos permiten ejecutar consultas a datos remotos utilizando la sintaxis de cuatro partes: NombreDelLinkedServer.BaseDeDatos.Esquema.Tabla. Este enfoque simplifica la integración de datos, eliminando la necesidad de replicar físicamente los datos en un solo lugar.
Configuración y uso de Servidores Vinculados en SQL Server
Configurar un Linked Server es un proceso relativamente sencillo que se puede realizar tanto mediante SQL Server Management Studio (SSMS) como con comandos T-SQL. Para crear un linked server a través de SSMS nos dirigiremos a la carpeta Objetos de Servidor y haremos clic derecho sobre Servidores Vinculados para a continuación seleccionar Nuevo Servidor Vinculado. Se nos abrirá una ventana donde rellenaremos los datos relativos al origen de los datos y a la seguridad (usuario y contraseña remotos). Para crear un Linked Server utilizando T-SQL, el comando es el siguiente:
EXEC sp_addlinkedserver
@server = 'NombreDelLinkedServer',
@srvproduct = '',
@provider = 'NombreDelProveedorOLEDB',
@datasrc = 'NombreOIPDelServidorRemoto';Para gestionar la autenticación, que puede ser mediante Windows o especificando credenciales propias, utilizamos:
EXEC sp_addlinkedsrvlogin
@rmtsrvname = 'NombreDelLinkedServer',
@useself = 'False',
@locallogin = NULL,
@rmtuser = 'UsuarioRemoto',
@rmtpassword = 'ContraseñaRemota';Una vez configurado, podemos realizar consultas distribuidas usando la sintaxis de cuatro partes:
SELECT * FROM NombreDelLinkedServer.BaseDeDatos.Esquema.Tabla;Uso de Linked Servers con servidores no SQL Server
La sintaxis de cuatro partes es muy útil, pero solo es aplicable cuando el linked server apunta a otra instancia de SQL Server. Cuando necesitamos conectarnos a servidores que no sean SQL Server, como por ejemplo Oracle, MySQL o sistemas de archivos como Excel, esta sintaxis no es compatible. En estos casos, debemos utilizar métodos alternativos para ejecutar nuestras consultas.
¿Por qué no se puede usar la sintaxis de cuatro partes?
La sintaxis de cuatro partes (NombreDelLinkedServer.BaseDeDatos.Esquema.Tabla) depende de la estructura jerárquica de SQL Server, que organiza los objetos en bases de datos, esquemas y tablas de una manera específica. Otros sistemas de bases de datos, como Oracle, tienen una organización interna diferente que no se adapta a esta estructura. Por ejemplo, en Oracle, las bases de datos y esquemas no se organizan de la misma manera, lo que hace que esta sintaxis no sea aplicable y genere errores si la intentamos utilizar.
Alternativa: Uso de OPENQUERY para Consultas con Linked Servers
Para trabajar con linked servers que apuntan a servidores no SQL Server, OPENQUERY es la herramienta adecuada. Esta función permite enviar una consulta SQL completa al servidor remoto, ejecutarla allí y devolver los resultados a SQL Server.
También podemos usar OPENQUERY para servidores SQL Server en vez de la sintaxis de 4 partes y, aunque pueda parecer más complejo al escribir la consulta, es especialmente útil para mejorar el rendimiento en consultas distribuidas, ya que permite que el servidor remoto procese la consulta completa y solo devuelva los resultados.
La sintaxis de OPENQUERY es la siguiente:
SELECT *
FROM OPENQUERY(
NombreDelLinkedServer,
'SELECT Columna1, Columna2 FROM TablaRemota WHERE Condicion'
);Esta forma de proceder nos permite aprovechar la sintaxis y capacidades nativas del servidor remoto, como Oracle o MySQL, optimizando la ejecución de las consultas y minimizando la transferencia de datos.
Seguridad en el Uso de Linked Servers
La seguridad es un factor crucial al utilizar linked servers, no olvidemos que estamos accediendo a datos remotos y eso siempre es delicado. Dado que estamos extendiendo nuestras consultas a otros servidores, es fundamental asegurarnos de que las conexiones sean seguras y que las credenciales estén adecuadamente protegidas.
Por ello, es recomendable utilizar la autenticación de Windows siempre que sea posible, ya que nos permite aprovechar las políticas de seguridad de Active Directory. Sin embargo, también es probable que para ello tengamos que configurar la autenticación por Kerberos y registrar SPNs para no tener problemas de inicio de sesión.
La alternativa sería usar un login de SQL del servidor remoto. En este caso, si necesitamos utilizar autenticación SQL, es importante que las credenciales tengan los mínimos privilegios necesarios en el servidor remoto para realizar las tareas requeridas.
Además, debemos ser muy cuidadosos con las opciones de seguridad como «no delegation» y «mapped logins» para evitar la elevación de privilegios y controlar quién tiene acceso al linked server. Las auditorías regulares de los linked servers y sus usuarios configurados, para mi, son esenciales para mantener un entorno seguro.
Rendimiento al Usar Linked Servers y OPENQUERY
El rendimiento es un aspecto que no debemos pasar por alto al trabajar con linked servers. La latencia de la red y el rendimiento del servidor remoto son factores que pueden afectar considerablemente nuestras consultas distribuidas. Para mitigar estos problemas, debemos optimizar nuestras consultas para que solo traigan los datos necesarios.
Además, no debemos olvidar que, al trabajar con datos de un servidor remoto, nuestro motor de base de datos no va a ser capaz de estimar la cardinalidad de los datos, es decir, no va a saber de antemano cuantos registros le vienen y cuántos recursos asignar para la resolución de esa consulta. En este contexto, el uso de OPENQUERY puede ser una gran ventaja en términos de rendimiento. Al permitir que el servidor remoto procese la consulta completa, reducimos la cantidad de datos que se transfieren y optimizamos la carga en nuestra instancia local de SQL Server.
No obstante, es importante evitar las consultas donde tengamos que trabajar con datos remotos y locales a la vez, normalmente es más eficiente cargar los datos remotos en plano (con las transformaciones que hayamos podido hacer enteramente en el servidor remoto) y luego ya operarlo en combinación con los datos locales. De todas formas, como cada caso es un mundo, lo mejor es probar y ajustar las consultas para asegurarnos de que estamos obteniendo el máximo beneficio de esta técnica.
En este sentido, también debemos considerar el impacto de las transacciones distribuidas. Cuando nuestras operaciones involucran cambios en múltiples servidores, debemos asegurarnos de que todas las transacciones se manejan correctamente para evitar inconsistencias. Esto puede requerir el uso de coordinadores de transacciones distribuidas (DTC), lo que añade una capa de complejidad y potencial impacto en el rendimiento.
Conclusión
Los Linked Server en SQL Server nos ofrecen una forma versátil y eficiente de interactuar con datos distribuidos en múltiples fuentes. Sin embargo, su uso no está exento de riesgos en cuanto a la seguridad y el rendimiento por lo que debemos ir con cuidado.
Cuando trabajamos con servidores SQL Server, la sintaxis de cuatro partes es una opción sencilla y directa. Sin embargo, cuando nos conectamos a servidores que no son SQL Server, OPENQUERY se convierte en la herramienta clave para ejecutar consultas distribuidas de manera eficiente. Entender las capacidades y limitaciones de cada método nos permitirá aprovechar al máximo los linked servers, garantizando que nuestras aplicaciones funcionen de manera segura y eficiente en entornos distribuidos y heterogéneos.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
No te vayas aun. Hemos creado una página donde estamos recopilando todos estos artículos que dan respuesta a estas preguntas frecuentes de SQL Server. Pásate por aquí a echar un vistazo.
