sql server 2000 - ver - Rendimiento del servidor vinculado y opciones
eliminar servidor vinculado sql server (9)
En el trabajo, tenemos dos servidores, uno está ejecutando una aplicación que usa mucha gente que tiene un back-end de SQL Server 2000. He sido libre de consultar esto durante mucho tiempo pero no puedo agregarle nada, como procedimientos almacenados o tablas adicionales.
Esto nos ha llevado a tener un segundo servidor SQL vinculado al primero y a crear una biblioteca de procedimientos almacenados que consulta datos de ambas partes utilizando el servidor vinculado. Algunas de estas consultas tardan más de lo que me gustaría.
¿Puede alguien señalarme algunos buenos artículos sobre el uso de servidores vinculados? Estoy particularmente interesado en saber qué datos se están transfiriendo entre los dos, ya que normalmente la mayoría de los enunciados SQL se pueden realizar de forma remota, pero tengo la sensación de que puede transferir las tablas completas, por lo general es solo unirme a una pequeña final mesa localmente
Además, ¿qué opciones de servidor vinculado tengo actualmente?
- Collation Compatible True
- Acceso a datos verdadero
- Rpc True
- Rpc Out True
- Usar colación remota Falso
- Nombre de intercalación (en blanco)
- Tiempo de espera de conexión 0
- Tiempo de espera de consulta 0
EDITAR:
Solo pensé en actualizar esta publicación. Utilicé openqueries con parámetros dinámicos por un tiempo para aumentar el rendimiento, gracias por la sugerencia. Sin embargo, hacer esto puede hacer que las consultas sean más complicadas a medida que termina manejando las cadenas. finalmente, este verano, actualizamos SQL Server a 2008 e implementamos la duplicación de datos en vivo. Para ser sincero, las consultas abiertas se acercaban a la velocidad de las consultas locales para mis tareas, pero la duplicación ciertamente ha hecho que el sql sea más fácil de tratar.
¿Existe la posibilidad de que pueda configurar una base de datos separada en el servidor en lugar de usar un servidor vinculado?
Cuando utiliza servidores vinculados para combinaciones como esta, es importante que el servidor al que está conectado de inmediato ("local") sea el que tenga la mayor cantidad de datos, donde el servidor vinculado solo proporciona una pequeña parte de los datos. de lo contrario, sí, extraerá todos los datos que necesite para realizar la unión.
Las alternativas incluyen copiar un subconjunto de los datos en una tabla temporal con tanto trabajo hecho para adelgazar los resultados y cualquier preproceso que pueda realizar el servidor vinculado, y luego hacer la unión en el lado "local".
Puede encontrar que puede aumentar fácilmente el rendimiento invirtiendo la forma en que lo hace, conectándose al servidor sobre el que no tiene control (tendrán que crear un servidor vinculado para usted) y luego conectándose a su servidor a través del enlace. Si necesita realizar un trabajo importante con los datos en los que tendría que crear sprocs, inserte los datos en su servidor y utilice sus sprocs allí.
En algunos casos, simplemente hice que el servidor vinculado realizara una creación nocturna de este tipo de resumen que envió al servidor local, y luego el servidor local realizó su trabajo con la combinación.
Las consultas que implican semiuniones en un servidor vinculado no suelen ser muy eficientes. Tal vez sea mejor que use OPENQUERY para completar datos en una tabla temporal local y luego trabajar desde allí.
dolor real
Solíamos tener varios servidores vinculados en nuestra tienda y resultó ser un PITA .
Antes que nada, hubo severos problemas de rendimiento similares a los que describes. Me sorprendió cuando vi las estadísticas de E / S de la red. A pesar de todos los esfuerzos, fallamos al indicarle a SQL Server un comportamiento razonable.
Otro problema era que los procesos almacenados tenían estos nombres de servidores vinculados codificados en todas partes, sin posibilidad de anularlos. Por lo tanto, los desarrolladores no podían probar fácilmente en sus sandboxes de desarrollo ninguna funcionalidad que afectara a los servidores vinculados. Este fue un obstáculo importante para la creación de un conjunto de pruebas de unidad de uso universal.
Al final, abandonamos por completo los servidores vinculados y movimos la sincronización de datos a los servicios web.
Evite las uniones a tablas de servidor vinculadas.
Puede usar un nombre de cuatro partes para su unión, pero es más costoso. Su unión podría contener criterios que pueden usarse para limitar el conjunto de datos del servidor vinculado y usar las columnas indexadas.
Ejemplo:
SELECT loc.field1, lnk.field1
FROM MyTable loc
INNER JOIN RemoteServer.Database.Schema.SomeTable lnk
ON loc.id = lnk.id
AND lnk.RecordDate = GETDATE()
WHERE loc.SalesDate = GETDATE()
Esta consulta también aplica un criterio en la combinación que puede ser utilizado por el servidor vinculado antes de calcular la unión.
El método recomendado es el uso de OPENQUERY.
Al evitar la unión con el uso de OPENQUERY, el servidor local solo envía la consulta para que se ejecute de forma remota, en lugar de enviar un conjunto de ID para la combinación.
Use el enlace para recuperar un conjunto de datos y realizar los cálculos localmente. Utilice una tabla temporal (para consultas ad hoc) o inserte la fila en una tabla permanente en un trabajo nocturno.
Las transacciones iniciales pueden fallar dependiendo de si el coordinador de transacciones remotas está configurado en el servidor que le gusta. Usarlo consumirá más recursos.
Además, tenga en cuenta que está llegando a un servidor de producción que ejecuta una aplicación, mientras que usted no lo especifica, creo que es seguro asumir que está utilizando transacciones pesadas y haciendo inserciones y actualizaciones. Estás quitando recursos de la aplicación.
Su propósito parece ser el uso de los datos para los informes. Su servidor puede configurarse para tener un registro simple en lugar de completo, lo que lo hace más eficiente.
También evitará que se cancelen sus consultas debido al movimiento de datos en el servidor vinculado. Siempre tenga en cuenta establecer el nivel de aislamiento adecuado para sus consultas y sugerencias de tabla como NOLOCK.
¡Y por favor! ¡Nunca coloque una OPENQUERY (o cualquier servidor vinculado) dentro de un bucle!
Aconsejaría openqueries dinámicas en un bucle de cursor en lugar de uniones vinculadas. Esta es la única forma en que he podido replicar el rendimiento de las uniones enlazadas de MS Access (al menos para las tablas remotas únicas)
Las uniones enlazadas regulares en ms sql son demasiado ineficientes tirando de todo especialmente en tablas enormes.
- Me gustaría saber qué tiene de malo openqueries dentro de los bucles de cursor. si se hace correctamente, no hay problemas de bloqueo.
Es un problema muy generoso, que puede tener muchas soluciones. Pero como hemos visto tantos usuarios que dicen que han intentado todo.
Lo que resolvió mi problema es ...
Actualicé SQL server 2000 de sp2 a SP4 y si ya tiene sp4 en sql server 2000, ejecute Instcat.sql. Según mi experiencia, puedo asegurarle que esto funcionará con seguridad, si está agotado con todas las otras soluciones.
Gracias, Mithalesh [email protected]
SQL dinámico y una función se pueden usar para evitar la pregunta del nombre codificado. Por ejemplo, estoy probando una implementación donde la función ufn_linkedDatabase (@purpose nvarchar (255)) con la entrada ''cpi.cpi'' (CPI específico, valor por defecto del propósito secundario) devuelve ''[SERVER-NAME.DOMAIN.LCL, 2000]. [CPI] ''en el entorno de producción (donde utilizamos un número de puerto alternativo para SQL Server, no sé por qué, incluso en el nombre del servidor vinculado). Luego se ensambla un comando SQL en @template varchar (max) con la expresión @ {cpi.cpi} que representa el servidor y la base de datos vinculados, y luego @workstring = REPLACE (@template, N''@{cpi.cpi} '',. ..). La forma en que la función obtiene realmente el nombre de la base de datos es independiente de los procedimientos; una tabla de búsqueda es agradable.
Problemas: hacer OPENQUERY (), que probablemente sea mejor al menos a menos que la opción del servidor vinculado "intercalación compatible" esté configurada como "verdadera" para que se pueda ejecutar más tareas en el servidor vinculado, lo que es importante incluso en una red rápida. y nuestra red interna de sala de servidores es respetablemente rápida - para hacer OPENQUERY () Probablemente necesite manejar ''cpi.cpi.server'' y ''cpi.cpi.database'' y ''cpi.cpi.server.database'' por separado. Y, puedo terminar escribiendo exactamente una aplicación usando este diseño, en cuyo caso está sobre diseñado. Aún así, eso significa que la función en sí misma no tiene que ser ningún tipo de trabajo elegante.
Lanzar hardware de red rápido al problema puede ser la respuesta más barata, de todos modos.
Hace un par de años escribí una aplicación de servidor vinculado remoto en SQL 2000 y encontré los mismos problemas de rendimiento que usted describe. Terminé reescribiendo mis procedimientos almacenados varias veces para obtener el mejor rendimiento.
Usé tablas temporales extensivamente. Descubrí que era menos costoso recuperar grandes cantidades de datos remotos en una tabla temporal, luego unirme a él, manipularlo, etc. Unirme a las tablas locales y remotas era muy lento a medida que lo deseabas.
Mostrar el plan de ejecución y mostrar el plan de ejecución estimado tendieron a ayudar, aunque no entendí mucho de lo que estaba viendo.
No sé si realmente existe una forma eficiente de hacer estas consultas con un servidor remoto porque parece que SQL Server no puede aprovechar sus optimizaciones normales cuando se dirige contra un servidor vinculado. Puede parecer que estás transfiriendo toda la mesa porque, de hecho, eso es lo que está sucediendo.
Me pregunto si un escenario de replicación podría funcionar para usted. Al tener los datos en su servidor local, debería poder escribir consultas normales que funcionarán según lo deseado.
No conozco ningún buen artículo al que apuntar. Mientras escribo aplicaciones de SQL Server más complicadas, comencé a pensar que necesitaba una mejor comprensión de cómo funcionaba SQL Server debajo. Con ese fin, compramos la serie MS Press Inside de Microsoft SQL Server 2005 editada por Kalen Delaney aquí en el trabajo. Volumen 1: El motor de almacenamiento es definitivamente el lugar para comenzar, pero no he llegado tan lejos. Dado que mis últimos proyectos no han involucrado a SQL Server, mi estudio se ha vuelto poco estricto.