À qui faire confiance?

Nous résolvons un problème de longue date avec un fournisseur. Leur logiciel a tendance à geler et à cesser de fonctionner une ou deux fois par semaine, ce qui provoque des perturbations majeures de notre fonctionnement. Ils n'ont pas pu en déterminer la cause malgré le fait que nous leur ayons envoyé de nombreux Go de journaux et sauvegardes de la base de données. Dernièrement, ils ont commencé à suggérer que les problèmes étaient liés à notre maintenance et peut-être pas à leur logiciel (malgré l'absence de longues requêtes en cours, la pression CPU / RAM / IO ou même des blocages lorsque les problèmes se produisent). Ils disent en particulier que nos indices sont un problème.

Leur outil préféré à utiliser est DBCC showcontig malgré mon argumentation que la chose est déconseillée par MS. Ils sont obsédés par la densité de numérisation et la fragmentation de l'étendue en particulier. Pour supprimer l'excuse, j'ai institué une maintenance nocturne agressive qui reconstruit les index avec une densité de balayage <90% ou une fragmentation> 10%. Cela les a quelque peu rejetés du train de densité de balayage, mais ils restent fixés sur la fragmentation de l'étendue. DBCC showcontig montre une fragmentation étendue, même sur un index qui a été reconstruit quelques heures auparavant. Voici les résultats de dbcc_showcontig et sys.dm_db_index_physical_stats pour une table qu'ils ont désignée comme un "problème possible".

DBCC SHOWCONTIG

• Pages numérisées ................................: 1222108
• Étendues numérisées ..............................: 152964
• Commutateurs d'extension ..............................: 180904
• Moy. Pages par étendue ........................: 8.0
• Densité de numérisation [Meilleur nombre: nombre réel] .......: 84,44% [152764: 180905]
• Fragmentation de l'analyse logique ..................: 3,24%
• Fragmentation de l'analyse étendue ...................: 35,97%
• Moy. Octets libres par page .....................: 692,5
• Moy. Densité de page (pleine) .....................: 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

Dois-je me préoccuper de mes index? Celui ci-dessus n'est pas atypique. Le MS DMV préféré semble montrer qu'il va très bien, mais le fournisseur est bloqué sur cette fragmentation de 35,97%. Je soupçonne que ce sont juste eux qui essaient désespérément de trouver quelque chose pour blâmer leurs problèmes logiciels, mais si j'ai un problème réel, je veux essayer de le résoudre.

Leur logiciel a tendance à geler et à cesser de fonctionner une ou deux fois par semaine, ce qui provoque des perturbations majeures de notre fonctionnement. Ils n'ont pas pu en déterminer la cause malgré le fait que nous leur ayons envoyé de nombreux Go de journaux et sauvegardes de la base de données. ... En particulier, ils disent que nos indices sont un problème.

Oh, c'est vrai, je pense avoir déjà entendu cette blague. Ça ne va pas quelque chose comme:

Un canard entre dans un bar et dit: "Aïe!" (je plaisante ;-) et le barman dit: "Qu'as-tu?"

Le canard dit: "Donne-moi 3 doigts de ta vodka la plus forte."

Le barman dit, presque comme s'il plaisantait, "Tu ne veux pas dire 3" plumes "?"

Le canard dit: "Ecoute, je suis désolé que tu ne sois plus scénariste en chef pour Tout le monde aime Raymond , mais ça a été une dure journée alors tu pourrais être un copain et faire avec la vodka?"

Le barman dit: "Bien sûr, mon pote. Tiens bon."

Il revient un instant plus tard, visiblement un peu moins heureux que quand il est parti, et dit au canard, "On dirait que nous sommes tous sortis des bonnes choses. Tout ce qu'il nous reste est Skyy. Est-ce que ça fonctionnera?"

Le canard saute sur le comptoir, attrape le barman par le col avec une aile (en quelque sorte), sort un couteau de, eh bien, quelque part avec l'autre aile, et dit, plutôt lentement, doucement, mais clairement, "I. Will . Vous couper."

Le barman, paniqué, dit: "Hé mec, c'est la base de données. Elle est lente. Elle ne répond pas."

Le canard, un peu confus quant à savoir s'il devrait ou non juste mettre fin au barman - ici, en ce moment - aboie avec colère, "La base de données? De quoi parlez-vous?"

Le barman, sanglotant maintenant, s'écrie: "Je ne sais pas ... Y a-t-il un blocage? ... C'est juste ce que nous disons ... Pouvez-vous essayer de reconstruire des index ou quelque chose? ... vous savez, quand nous ne savons pas quoi dire d'autre ... peut-être que nous devrions ajouter plus de mémoire au serveur ... vous pensez que cela aiderait? ... tout le monde sait que le code de l'application est rapide et les bases de données sont le goulot d'étranglement .. ..Hey, j'ai entendu parler de ces bases de données NoSQL qui sont <air-quotes> à l'échelle du Web </air-quotes> et sont généralement Open Source, donc elles sont gratuites, et comme, Twitter et Google, et Facebook utilise tous ce genre de choses, car les bases de données relationnelles sont sur le point de disparaître. "

Et avec cela, le canard avait pris sa décision ...........

Hmm. Eh bien, croyez-moi, c'est beaucoup plus drôle dans l'original hongrois.

Mais encore, pourquoi la réaction initiale de tant de gens, lorsqu'un système ralentit, suppose-t-elle simplement qu'il s'agit de la base de données? Comme si le code d'application ne pouvait pas être horriblement écrit, ou simplement avoir des bugs? Les choses ralentissant pourraient certainement être la base de données. Mais simplement verrouiller / geler? Cela ne me semble pas être un problème spécifique à la base de données.

Ce qu'il fait son est peut - être comme un code d'application qui ne libère pas correctement les ressources externes (sockets réseau, poignées de système de fichiers, etc.). Si nous parlons d'une application .NET, les développeurs oublient parfois correctement les Dispose()objets qui ont associé des ressources non gérées. Par exemple: ouvrir un SqlConnectionobjet. Vous n'en obtenez pas une quantité infinie. Donc, s'ils veulent regarder dans la base de données, alors très bien. Mais peut-être que la prochaine fois que le système se bloquera, jetez un coup d'œil à:

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 leur code ne libère pas les connexions, alors il devrait être assez évident s'il y a trop de connexions, surtout si beaucoup d'entre elles ont de longues périodes d'inactivité.

Et peut-être que ce truc a déjà été vérifié et tout simplement pas divulgué dans la question. Mais il me semble plutôt étrange qu'ils soient si concentrés sur les index et la fragmentation. Bien sûr, il y a des problèmes de reniflage de paramètres qui font parfois qu'une, ou peut-être quelques-unes, les procédures stockées prennent VRAIMENT ＬＯＮＧ, mais qui bloquent une application entière? Je ne l'achète pas, surtout si vous ne voyez pas de requête en cours d'exécution et occupant beaucoup de ressources ou de verrous ou de temps lorsque cela se produit.

Alors, "à qui faire confiance?" Certainement pas ce vendeur ;-).

Une chose que vous pouvez vérifier pour voir si vos index doivent être réorganisés ou reconstruits est d'utiliser cette requête:

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');

Remplacez @strBDpar your database name.

Selon les résultats, veuillez procéder comme indiqué dans https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx . Ce lien concerne la version 2012 de SQL Server; veuillez sélectionner la version appropriée pour procéder correctement.

Comme quelqu'un l'a commenté, il vaut mieux informer votre fournisseur de cette révision et correction, au-delà du «problème de fragmentation». Peut-être identifier certaines requêtes et plans d'exécution avec une capture SQL Profiler.