valid - ¿La ejecución de una base de datos de SQL Server 2005 en el nivel de compatibilidad 80 tiene un impacto negativo en el rendimiento?

sql server 2017

Question

Nuestro software debe poder ejecutarse en SQL Server 2000 y 2005. Para simplificar el desarrollo, estamos ejecutando nuestras bases de datos de SQL Server 2005 en el nivel de compatibilidad 80. Sin embargo, el rendimiento de la base de datos parece ser más lento en SQL 2005 que en SQL 2000 en algunos casos ( aún no lo han confirmado utilizando puntos de referencia). ¿Mejoraría el nivel de compatibilidad a 90 para mejorar el rendimiento en los servidores SQL 2005?

Answer 1

después de mover los DBs a 2005,

actualizar las estadísticas con escaneo completo? reconstruyó los índices?

Primero inténtalo y luego revisa el rendimiento otra vez

Answer 2

Además, para su información, si ejecuta el nivel de compatibilidad 90, algunas cosas ya no son compatibles, como las uniones externas de estilo antiguo (*= and =*)

Answer 3

Creo que leí en alguna parte, que el motor de base de datos de SQL Server 2005 debería ser aproximadamente un 30% más rápido que el motor de SQL Server 2000. Es posible que tenga que ejecutar su base de datos en modo compatibilidad 90 para obtener estos beneficios.

Pero tropecé con dos escenarios, donde el rendimiento puede caer dramáticamente cuando se usa mssql 2005 en comparación con mssql 2000:

1. Parametrización de parámetros: cuando se utiliza un procedimiento almacenado, el servidor sql calculará exactamente un plan de ejecución en el momento, primero se llama al procedimiento. El plan de ejecución depende de los valores de los parámetros dados para esa llamada. En nuestro caso, los procedimientos que normalmente duraban unos 10 segundos se ejecutan durante horas bajo mssql 2005. Eche un vistazo aquí y aquí .

2. Al usar consultas distribuidas, mssql 2005 se comporta de forma diferente con respecto a las suposiciones sobre el orden de clasificación en el servidor remoto. El comportamiento predeterminado es que el servidor copie todas las tablas remotas involucradas en una consulta al tempdb local y luego ejecute las uniones localmente. La solución alternativa es usar OPENQUERY, donde puede controlar exactamente qué conjunto de resultados se transfiere desde el servidor remoto.

Answer 4

¿Estás utilizando subselecciones en tus consultas?

Desde mi experiencia, una instrucción SELECT con subselecciones que funciona bien en SQL Server 2000 puede rastrear en SQL Server 2005 (¡puede ser 10 veces más lenta!).

Haga un experimento: vuelva a escribir una consulta para eliminar las subselecciones y vea cómo cambia su rendimiento.