¿En cuál confiar?

Estamos solucionando un problema de larga duración con un proveedor. Su software tiene una tendencia a congelarse y dejar de funcionar una o dos veces por semana, causando interrupciones importantes en nuestra operación. No han podido determinar la causa a pesar de que les enviamos muchos GB de registros y copias de seguridad de la base de datos. Últimamente han comenzado a sugerir que los problemas están relacionados con nuestro mantenimiento y quizás no con su software (a pesar de que no hay consultas de larga duración, presión de CPU / RAM / IO o incluso puntos muertos cuando ocurren los problemas). En particular, dicen que nuestros índices son un problema.

Su herramienta favorita para usar es DBCC showcontig a pesar de que yo sostengo que MS ha desaprobado. Se obsesionan con la densidad de escaneo y la fragmentación de extensión especialmente. Para quitar la excusa, instituí un mantenimiento nocturno agresivo que reconstruye los índices con <90% de densidad de exploración o> 10% de fragmentación. Esto los ha arrojado algo fuera del tren de densidad de escaneo, pero permanecen fijos en la fragmentación de extensión. DBCC showcontig muestra una fragmentación de alto grado incluso en un índice que fue reconstruido horas antes. A continuación se muestran los resultados de dbcc_showcontig y sys.dm_db_index_physical_stats para una tabla que señalaron como un "posible problema".

DBCC SHOWCONTIG

• Páginas escaneadas ................................: 1222108
• Extensiones escaneadas ..............................: 152964
• Interruptores de extensión ..............................: 180904
• Media Páginas por extensión ........................: 8.0
• Densidad de escaneo [Mejor recuento: recuento real] .......: 84.44% [152764: 180905]
• Fragmentación de escaneo lógico ..................: 3.24%
• Extensión de fragmentación de escaneo ...................: 35.97%
• Media Bytes gratis por página .....................: 692.5
• Media Densidad de página (completa) .....................: 91,44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

¿Debería preocuparme por mis índices? El de arriba no es atípico. El MS DMV preferido parece mostrar que está bien, pero el proveedor está estancado en esa fragmentación de 35.97%. Sospecho que se trata solo de ellos tratando desesperadamente de encontrar algo para culpar a sus problemas de software, pero si tengo un problema real, quiero intentar solucionarlo.

Su software tiene una tendencia a congelarse y dejar de funcionar una o dos veces por semana, causando interrupciones importantes en nuestra operación. No han podido determinar la causa a pesar de que les enviamos muchos GB de registros y copias de seguridad de la base de datos. ... En particular, dicen que nuestros índices son un problema.

Oh, claro, creo que he escuchado esta broma antes. ¿No va algo así como:

Un pato entra a un bar. y dice: "¡Ay!" (es broma ;-) y el cantinero dice: "¿Qué quieres?"

El pato dice: "Dame 3 dedos de tu vodka más fuerte".

El cantinero dice, casi como si estuviera bromeando: "¿No te refieres a 3 'plumas'?"

El pato dice: "Mira, lo siento, ya no eres el escritor principal de Everybody Loves Raymond , pero ha sido un día difícil, ¿podrías ser un amigo y hacer el vodka?"

El camarero dice: "Claro, amigo. Espera".

Regresa un momento después, visiblemente un poco menos feliz que cuando se fue, y le dice al pato: "Parece que nos hemos quedado sin cosas buenas. Lo único que nos queda es Skyy. ¿Funcionará?"

El pato salta sobre el mostrador, agarra al camarero por el cuello con un ala (de alguna manera), saca un cuchillo de, bueno, en algún lugar con el otro ala, y dice, bastante lento, suave, pero claramente, "I. Will . Cortarte."

El barman, en pánico, dice: "Oye, es la base de datos. Es lenta. No responde".

El pato, un poco confundido sobre si debería terminar con el camarero o no, justo aquí, ahora mismo, le ladra enojado: "¿La base de datos? ¿De qué demonios estás hablando?"

El barman, ahora sollozando, exclama: "No sé ... ¿Hay algún bloqueo? Es solo lo que decimos ... ¿Puedes intentar reconstruir índices o algo así? ... ya sabes, cuando no sabemos qué más decir ... tal vez deberíamos agregar más memoria al servidor ... ¿crees que eso ayudaría? ... todos saben que el código de la aplicación es rápido y las bases de datos son el cuello de botella ... Oye, he estado escuchando sobre estas bases de datos NoSQL que son <air-quotes> web-scale </air-quotes> y generalmente son de código abierto, por lo que son gratuitas, y me gusta, Twitter y Google, y el Todos usan Facebook ya que las bases de datos relacionales están prácticamente desapareciendo ".

Y con eso, el pato había tomado una decisión ...........

Hmm Bueno, confía en mí, es mucho más divertido en el húngaro original.

Pero aún así, ¿por qué la reacción inicial de tantas personas, cuando un sistema se ralentiza, simplemente supone que es la base de datos? ¿Como si el código de la aplicación no se puede escribir horriblemente, o simplemente tener algunos errores? Las cosas que se vuelven más lentas ciertamente podrían ser la base de datos. ¿Pero simplemente bloquear / congelar? Eso no me parece un problema específico de la base de datos.

Lo que sí suena es posiblemente algún código de aplicación que no está liberando adecuadamente recursos externos (tomas de red, controladores de sistema de archivos, etc.). Si hablamos de una aplicación .NET, a veces los desarrolladores se olvidan Dispose()de los objetos que tienen recursos no administrados asociados. Por ejemplo: abrir un SqlConnectionobjeto. No obtienes una cantidad infinita de ellos. Entonces, si quieren buscar en la base de datos, entonces está bien. Pero tal vez, la próxima vez que el sistema se congele, eche un vistazo rápido a:

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

Si su código no libera las conexiones, entonces debería ser bastante obvio si hay demasiadas conexiones, especialmente si muchas de ellas tienen largos tiempos de inactividad.

Y tal vez esto ya se haya verificado y simplemente no se haya revelado en la Pregunta. Pero me parece bastante extraño que estén tan centrados en los índices y la fragmentación. Claro, hay problemas de análisis de parámetros que a veces provocan que uno, o quizás algunos, procedimientos almacenados tomen REALMENTE ＬＯＮＧ tiempo, pero que bloqueen una aplicación completa. No lo estoy comprando, especialmente si no ve una consulta que se está ejecutando y que ocupa muchos recursos o bloqueos o tiempo cuando esto sucede.

Entonces, "¿en qué confiar?" Ciertamente no este vendedor ;-).

Una cosa que puede revisar para ver si sus índices necesitan reorganizarse o reconstruirse es utilizar esta consulta:

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

Reemplazar @strBDcon your database name.

Según los resultados, proceda como se indica en https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx . Este enlace es para la versión 2012 de SQL Server; seleccione la versión adecuada para proceder correctamente.

Como alguien comentó, es mejor decirle a su proveedor que revisa y soluciona, más allá del "problema de fragmentación". Quizás identificando algunas consultas y planes de ejecución con una captura de SQL Profiler.