Rendimiento de servidor vinculado y opciones

Question

En el trabajo tenemos dos servidores, uno está ejecutando una aplicación que mucha gente usa y tiene un servidor de fondo de SQL Server 2000. He tenido la libertad de consultar esto durante mucho tiempo, pero no puedo agregarle nada, como procedimientos almacenados o tablas adicionales.

Esto nos ha llevado a que tengamos un segundo servidor SQL Server vinculado al primero y que yo construyamos una biblioteca de procedimientos almacenados que consultan datos de ambos lados mediante un servidor vinculado. Algunas de estas consultas están tardando más de lo que me gustaría.

¿Puede alguien indicarme algunos buenos artículos sobre el uso de servidores vinculados? Estoy particularmente interesado en descubrir qué datos se están transfiriendo entre los dos, ya que generalmente la mayoría de la declaración SQL se podría realizar de forma remota, pero tengo la sensación de que puede estar transfiriendo las tablas completas, por lo general es solo una combinación para una pequeña final. tabla localmente.

También, ¿qué tengo actualmente con las opciones de servidor vinculado?

• Compatibilidad con compatibilidad verdadera
• Acceso a datos verdadero
• Rpc True
• Rpc Out True
• Usa la intercalación remota Falso
• Nombre de la colación (en blanco)
• Tiempo de espera de conexión 0
• Tiempo de espera de consulta 0

EDIT:

Pensé que actualizaría esta publicación. Utilicé openqueries con parámetros dinámicos por un tiempo para mejorar el rendimiento, gracias por la sugerencia. Sin embargo, hacer esto puede hacer que las consultas sean más complicadas a medida que terminas tratando con cadenas. Finalmente, este verano, actualizamos SQL Server a 2008 e implementamos la duplicación de datos en vivo. Para ser honesto, las consultas abiertas se acercaban a la velocidad de las consultas locales para mis tareas, pero la duplicación ciertamente ha hecho que sea más fácil tratar con el SQL.

Answer 1

Recomendaría dinámicas de puertas abiertas en un bucle de cursor en lugar de uniones vinculadas. Esta es la única forma en la que he podido replicar el rendimiento de las uniones vinculadas de MS Access (al menos para tablas remotas individuales)

Las uniones vinculadas regulares en ms sql son demasiado ineficientes al tirar todo especialmente en tablas gigantescas.

- ¿Me gustaría saber qué tiene de malo OpenCeries dentro de los bucles de cursor? si se hace correctamente, no hay problemas de bloqueo.

Answer 2

Evite las uniones a las tablas de servidor vinculadas.

Se puede usar un nombre de cuatro partes para su unión, pero es más caro. 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 está aplicando un criterio en la unión que el servidor vinculado puede usar antes de que se calcule 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 unión.

Utilice 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 deseado. Usarlo consumirá más recursos.

También considere que está golpeando un servidor de producción que ejecuta una aplicación, mientras que no lo especifique, 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 informar. Se puede configurar su servidor para que tenga un registro simple en lugar de completo, lo que lo hace más eficiente.

También evitará que sus consultas se cancelen debido al movimiento de datos en el servidor vinculado. Siempre tenga en cuenta la configuración del 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!

Answer 3

Cuando utiliza servidores vinculados para uniones como esta, es importante que el servidor al que está conectado de inmediato (" local ") sea el que tenga la mayor parte de los 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 realizado para reducir los resultados y cualquier preprocesamiento que pueda realizar el servidor vinculado, y luego hacer la unión en el " local " lado.

Es posible que pueda mejorar fácilmente el rendimiento invirtiendo la forma en que lo hace, conectándose al servidor sobre el que no tiene control (necesitarán crear un servidor vinculado para usted) y luego conectarse 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, insértelos en su servidor y utilícelos 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 unión.

Answer 4

Dolor real

Solíamos tener varios servidores vinculados en nuestra tienda y resultó ser un PITA .

En primer lugar, hubo problemas graves de rendimiento similares a los que describe. Me sorprendió cuando vi las estadísticas de E / S de la red. A pesar de todos los esfuerzos, no logramos insinuar a SQL Server en un comportamiento razonable.

Otro problema fue que los procs almacenados tenían estos nombres de servidores vinculados codificados en todas partes, sin manera de anularlos. Por lo tanto, los desarrolladores no pudieron probar fácilmente en sus sandbox de desarrollo ninguna funcionalidad que afectara a los servidores vinculados. Este fue un gran obstáculo para la creación de un conjunto de pruebas de unidades de uso universal.

Al final, eliminamos completamente los servidores vinculados y movimos la sincronización de datos a los servicios web.

Answer 5

Las consultas que involucran semifusiones en un servidor vinculado tienden a no ser muy eficientes. Puede que sea mejor utilizar OPENQUERY para llenar datos en una tabla temporal local y luego trabajar desde allí.

Answer 6

Escribí una aplicación remota de servidor vinculado en SQL 2000 hace un par de años y encontré los mismos problemas de rendimiento que describe. Terminé reescribiendo mis procedimientos almacenados varias veces para obtener el mejor rendimiento.

Utilicé tablas temporales extensivamente. Descubrí que era menos costoso recuperar grandes cantidades de datos remotos en una tabla temporal, luego unirnos a ella, manipularla, etc. Unir las tablas locales a las remotas fue muy lento a medida que describía.

Mostrar el Plan de Ejecución y Mostrar el Plan de Ejecución Estimado tendió a ayudar, aunque no entendí mucho de lo que estaba viendo.

No sé si realmente hay una manera eficiente de hacer estas consultas con un servidor remoto porque parece que SQL Server no puede aprovechar sus optimizaciones normales cuando va en contra de un servidor vinculado. Puede parecer que está transfiriendo la tabla completa 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 las consultas normales que se realizarán según lo deseado.

No conozco ningún artículo bueno para señalarle. A medida que escribo aplicaciones de SQL Server más complicadas, comencé a pensar que necesitaba una mejor comprensión de cómo funcionaba debajo SQL Server. Para ese fin compramos la serie MS Press Inside 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. Desde que mis últimos proyectos no involucraron a SQL Server, mi estudio sobre esto se ha relajado.

Answer 7

¿Existe la posibilidad de que pueda configurar una base de datos separada en el servidor en lugar de usar un servidor vinculado?

Answer 8

Es un problema muy generoso, que puede tener muchas soluciones. Pero como hemos visto, muchos usuarios han dicho que lo 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á seguro, si está agotado con todas las otras soluciones.

Gracias, Mithalesh mithalesh.gupta@gmail.com

Answer 9

SQL dinámico y una función pueden usarse para sortear la pregunta de nombre codificado. Por ejemplo, estoy probando una implementación en la que la función ufn_linkedDatabase (@purpose nvarchar (255)) con la entrada 'cpi.cpi' (propósito CPI, valor por defecto del sub-propósito) devuelve '[SERVER-NAME.DOMAIN.LCL, 2000]. [CPI]' en el entorno de producción (donde usamos 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 vinculado y la base de datos, 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: para hacer OPENQUERY (), que probablemente todavía sea mejor al menos a menos que la opción de servidor vinculado " compatible con la clasificación " se establece " verdadero " para que se pueda ejecutar más de la tarea en el servidor vinculado, lo que es importante incluso en una red rápida, y nuestra red interna de sala de servidores es muy rápida, para hacer OPENQUERY () Probablemente necesito 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. Sin embargo, eso significa que la función en sí no tiene que ser ningún tipo de trabajo elegante.

De todos modos, lanzar el hardware de red rápido al problema puede ser la respuesta más económica.