En mi última publicación, "Planes múltiples para una consulta 'idéntica'", hablé sobre el caso en el que obtiene dos planes diferentes para lo que cree que es la misma consulta, así como el caso en el que obtiene dos copias de la igual plan (y puede que ni siquiera lo sepa). Como examinamos allí, "idéntico" puede ser una palabra bastante fuerte.
Otro escenario que lanza a las personas a un bucle es el caso en el que restauran una base de datos en un servidor diferente, por ejemplo, restauran una base de datos de producción en un servidor de prueba "idéntico", y obtienen diferentes características de rendimiento o diferentes planes para la misma consulta (no comillas esta vez, realmente estoy hablando de consultas verdaderamente idénticas).
¿Son los servidores realmente "idénticos"?
Estos tipos pueden parecer similares, pero no son del todo idénticos. Si te encuentras con este escenario, lo primero que debes preguntarte es si estos dos servidores son realmente idénticos. Algunas cosas para verificar:
- Versión – Muchos cambios en el comportamiento del optimizador y las consultas se envían a través de paquetes de servicios y actualizaciones acumulativas. A menudo he visto a gente decir:"Bueno, ¡ambos son de 2008!". – cuando, de hecho, uno era 2008 y el otro era 2008 R2, o estaban en diferentes paquetes de servicios o incluso en niveles de actualización acumulativos. Dado que muchas personas que leen @@VERSION confunden la información del paquete de servicio del sistema operativo con la información del paquete de servicio de SQL Server, diría que lo siguiente es mejor:
SELECTSERVERPROPERTY(N'ProductVersion');No puedo enfatizar lo suficiente la importancia de usar exactamente la misma versión para realizar pruebas verdaderas de manzanas con manzanas. Si usa SQL Server 2012 o superior, puede consultar nuestras publicaciones de compilación (SQL Server 2012 | SQL Server 2014) para determinar el paquete de servicio o la actualización acumulativa necesaria para asegurarse de que las versiones coincidan.
- Edición – Si bien es de esperar que esté utilizando la misma edición en ambos servidores (o equivalente, ya que, aparte de la licencia, Developer y Evaluation son los mismos que Enterprise), las discrepancias aquí pueden conducir a un comportamiento muy diferente. Por ejemplo, las diferentes ediciones tienen diferentes capacidades de cómputo para varias funciones, y luego hay cosas más sutiles como la capacidad de usar una vista indexada sin la sugerencia NOEXPAND o realizar cambios de esquema o mantenimiento de índice en línea. Puede comparar ediciones usando:
SELECTSERVERPROPERTY(N'Edition'); - Recuento de CPU – SQL Server definitivamente usa la cantidad de programadores disponibles durante el proceso de producción de un plan de ejecución, y no se puede negar que la cantidad de núcleos puede afectar el rendimiento real del tiempo de ejecución (dejemos de lado la velocidad del reloj, ya que rara vez es un factor significativo en la consulta actuación). No solo valide la cantidad de núcleos instalados físicamente en el servidor subyacente, sino que también verifique el registro de errores de SQL Server para conocer la cantidad de CPU que SQL Server puede usar debido a la licencia. Incluso olvidando el recuento de núcleos sin procesar, en un sistema NUMA, las restricciones artificiales aquí pueden conducir a perfiles de rendimiento muy diferentes. Para obtener más información, consulte la publicación reciente de Brent Ozar, "Por qué las licencias basadas en núcleo son importantes para el ajuste del rendimiento". Edition también se relaciona aquí, ya que en SQL Server 2012 y 2014, Standard Edition solo puede usar 16 núcleos, sin importar lo que su configuración o hardware físico le hagan creer. Otras configuraciones que pueden influir de manera diferente en la elección del plan basado en CPU y el rendimiento incluyen el regulador de recursos, MAXDOP en todo el servidor, afinidad de CPU y umbral de costo para el paralelismo.
- Cantidad de memoria – Al igual que las CPU, el optimizador realiza elecciones de planes en función de la cantidad de memoria disponible. Y al igual que las CPU, no solo me refiero a la cantidad de RAM instalada en el sistema, sino también a la cantidad de memoria otorgada a SQL Server y la cantidad que realmente utiliza. Verifique la configuración máxima de la memoria del servidor, pero también los contadores de rendimiento para la memoria total y de destino, e incluso DBCC MEMORYSTATUS. Otras cosas que puede querer revisar incluyen la configuración del Gobernador de recursos y Bloquear páginas en la memoria. También hay una configuración que, si es diferente entre dos servidores, puede tener un efecto significativo en la cantidad de caché del plan que se usa para el mismo conjunto de consultas:optimizar para cargas de trabajo ad hoc. Kimberly Tripp tiene una excelente publicación sobre esto:Planifique el caché y optimice para cargas de trabajo ad hoc. Finalmente, si el servidor es virtual, tenga en cuenta que el entorno puede desempeñar un papel aquí, especialmente cuando la configuración de la memoria de la máquina virtual no coincide con la producción o es dinámica.
- Grupo de búfer/caché del plan – Cuando restaura la base de datos en el servidor de prueba, hay un montón de cosas que simplemente no están listas para usted de inmediato. El grupo de búfer no contiene ninguno de los datos que pueden haber existido en el servidor de origen, por lo que se requerirán E/S adicionales para preparar los datos en la memoria la primera vez que se consulta. Y si el grupo de búfer está restringido de manera diferente a la producción debido a algunos de los factores anteriores, es posible que no sea posible lograr los mismos patrones de rendimiento incluso después de ejecutar la consulta varias veces:Paul White (@SQL_Kiwi) habla de esto en su respuesta en Administradores de bases de datos. Además, la memoria caché del plan no contendrá ninguno de los planes que existían en producción, por lo menos, incluso si finalmente se compila el mismo plan (lo que puede no suceder debido a diferentes parámetros que cuando el plan se compiló en el original). servidor) – tendrá costos adicionales de compilación. Y eso también puede cambiar si tiene algún indicador de seguimiento que afecte el plan.
- Subsistema de disco – Si bien la velocidad y el tamaño de los discos que se utilizan no afectarán directamente la elección del plan, ciertamente pueden influir en el rendimiento observado, lo que puede hacer que se pregunte por qué la misma consulta, con el mismo plan, se ejecuta mucho más rápido en uno. sistema que el otro. La E/S suele ser el mayor cuello de botella de SQL Server, y es bastante raro que un servidor de prueba tenga exactamente el mismo subsistema subyacente que su equivalente de producción. Por lo tanto, si ve diferencias de rendimiento entre los dos sistemas, y los planes y otros elementos de hardware son los mismos, este podría ser el mejor lugar para verificar. Y no olvide que, a partir de SQL Server 2014, el regulador de recursos puede imponer restricciones en su rendimiento de E/S.
- Banderas de seguimiento – Verifique la lista de marcas de seguimiento globales establecidas en ambos servidores; hay varios que pueden afectar la optimización, el comportamiento del plan y el rendimiento percibido, incluso si todas las configuraciones anteriores son idénticas. Aquí hay 10 comunes y notables (aunque esto no es en absoluto un respaldo para activar ninguno de estos sin una prueba de regresión exhaustiva):
Bandera Explicación 2301 Obliga al optimizador a pasar más tiempo tratando de encontrar un plan óptimo. 2312 Fuerza el nuevo estimador de cardinalidad de SQL Server 2014. 2335 Causa concesiones de memoria más conservadoras. 2453 Obliga a OPCIÓN (RECOMPILE) para consultas que hacen referencia a variables de tabla. 2861 Permite que SQL Server almacene en caché planes triviales/de costo cero. 4136 Efectivamente, agrega OPTIMIZE FOR UNKNOWN a todas las consultas (para frustrar el rastreo de parámetros). 4199 Un paraguas que contiene una gran cantidad de correcciones de optimización. 8744 Deshabilita la búsqueda previa para bucles anidados. 9481 Desactiva el nuevo estimador de cardinalidad de SQL Server 2014.
Esa lista de indicadores de seguimiento no es exhaustiva; hay muchos otros, incluidos los indocumentados que me han pedido que no mencione. Si está utilizando otros que no figuran en la lista anterior (y no puede explicar por qué), puede encontrar pistas en KB #920093, KB #2964518, Trace Flags (MSDN) o Trace Flags en SQL Server (TechNet). También encontrará información valiosa en varias publicaciones de Paul White, ya sea aquí o en sql.kiwi. - Simultaneidad – Presumiblemente, el sistema de prueba se usa para otras cosas además de lo que está probando actualmente. Y a menos que esté realizando una repetición de algún tipo, también es probable que tenga un perfil de carga de trabajo muy diferente. Estas diferencias en la carga de trabajo obviamente pueden tener un impacto directo en la disponibilidad de recursos para atender las solicitudes que está probando y, a su vez, el rendimiento percibido de esas solicitudes. No olvide buscar otros servicios que pueden no existir en producción, o existen pero se usan de diferentes maneras (como Analysis Services, Reporting Services, servicios de Windows e incluso sus propias aplicaciones). Por el contrario, puede haber servicios como este en producción que afecten el rendimiento allí, o una sobrecarga adicional en la instancia misma que no se imita en la prueba:además de la carga de trabajo de producción real, piense en cosas como seguimiento, eventos extendidos, monitoreo de alto impacto, Seguimiento de cambios, captura de datos de cambios, auditoría, agente de servicios, mantenimiento de índices, trabajos de copia de seguridad, comprobaciones de DBCC, duplicación, replicación, grupos de disponibilidad, y la lista sigue y sigue…
¿Las bases de datos siguen siendo "idénticas"?
Suponiendo que todas las variables de hardware y carga de trabajo coincidan lo suficientemente bien, aún puede ser un desafío garantizar que las bases de datos sigan siendo las mismas. Si está realizando una copia de seguridad/restauración en el sistema de prueba, la nueva base de datos comienza siendo idéntica a la fuente (excepto por la ubicación física y la seguridad). Pero tan pronto como comienzas a tocarlo de alguna manera, se desvía rápidamente de la copia de producción, ya que podrías hacer cualquiera de las siguientes cosas o todas:
- Cambiar datos, esquema o ambos.
- Iniciar sin darse cuenta una actualización automática de estadísticas.
- Agregue, desfragmente o reconstruya manualmente índices, o cree o actualice estadísticas.
- Cambie la configuración de la base de datos como el nivel de compatibilidad, el nivel de aislamiento, la parametrización forzada, los índices XML selectivos o cualquiera de las opciones denominadas "Auto"-
. (Diablos, incluso las ubicaciones de datos y archivos de registro y la configuración de crecimiento pueden afectar el rendimiento de las consultas, y esto incluye tempdb). - Vacíe la memoria caché del plan, el grupo de búfer o ambos, directamente o como efecto secundario de otros eventos (como una RECONFIGURACIÓN o un reinicio del servicio).
Además, una vez que comience a generar nuevos planes de consulta, incluso antes de que se produzca cualquiera de los cambios anteriores, debe recordar que pueden estar basados en datos diferentes a los datos utilizados para generar planes para las mismas consultas en producción. Como ejemplo, la cardinalidad cuando el plan se compiló en producción podría haberse desviado significativamente entre ese punto y el momento de la copia de seguridad, lo que significa que el nuevo plan se generará en función de diferentes estadísticas e información de histograma.
Estas cosas divergen aún más si no se trata, de hecho, de una restauración reciente, sino de dos esquemas y conjuntos de datos que mantiene sincronizados de otras maneras (como implementaciones manuales de cambios de esquema y/o datos, o incluso replicación). Debido a las limitaciones de espacio en disco, es posible que también haya tomado solo un subconjunto de datos de producción, o incluso un clon solo de estadísticas; estas diferencias en los datos casi seguramente conducirán a diferentes características de rendimiento para todas las consultas, excepto las más simples, incluso si lo hace. suerte y obtén los mismos planes para algunos.
¿Son las consultas realmente "idénticas"?
Incluso si todo lo anterior se verifica, todavía hay escenarios en los que obtiene un plan diferente debido a la configuración de la sesión (puede estar usando una copia diferente de SSMS, con configuraciones diferentes o una herramienta de cliente completamente diferente) o esquemas predeterminados diferentes ( puede conectarse al servidor de prueba como un inicio de sesión de autenticación de Windows o SQL diferente, por ejemplo). Hablé mucho sobre estas cosas en mi publicación anterior.
Conclusión
Si bien hay formas de mitigar algunas diferencias (consulte DBCC OPTIMIZER_WHATIF para engañar a su servidor de prueba para que crea cosas fenomenales sobre el hardware subyacente), la verdad es que será muy difícil hacer que dos servidores funcionen de manera confiable y consistentemente idéntica, y que existen potencialmente docenas de razones por las que puede obtener diferentes planes o un rendimiento diferente en dos servidores similares (o incluso idénticos).
¿Tienes algún truco en particular? ¿Tiene algún punto de dolor insoportable con las ideas anteriores (u otras que olvidé mencionar)? ¡Por favor comparte en los comentarios a continuación!
