2017-05-24 1 views
0

Nous avons eu un serveur SQL 2005 s'exécutant assez bien pour des requêtes XML EXPLICIT sans problèmes de performances. La machine (un serveur Windows 2003) est malheureusement morte alors j'ai dû faire une provision d'urgence d'une boîte Windows 2012. Les fichiers de bases de données ont été rattachés à un 2008r2 et "travail". Cependant, les requêtes sont horriblement lentes. 5 secondes par requête alors qu'auparavant ils étaient au format .x fois. Cela rend les sites Web qu'ils alimentent inutilisables. J'ai reconstruit tous les index et j'ai exécuté DBCC FREEPROCCACHE sur toutes les machines mais cela n'a eu aucun effet notable. Que puis-je regarder d'autre? Je ne peux pas les exécuter sur l'instance SQL 2016 sur la boîte car certaines requêtes utilisent des jointures non-ANSI * = (j'ai dit que c'était ancien!).Performances SQL médiocres après le transfert de serveur

+1

Vous avez consulté le plan de requête? –

+0

Il peut y avoir de nombreuses raisons, comme toutes les statistiques DB, des caches de résultats, et d'autres données ont été perdues, et doit être reconstruit. Voyez-vous une amélioration lente à mesure que le serveur est utilisé ou est-il en panne maintenant? Il vaudrait la peine de commencer à l'utiliser, et de voir si cela devient plus rapide à mesure que ces données perdues sont reconstruites à nouveau. – Galcoholic

+0

Il y a tellement peu de choses à faire dans la question, nous ne pouvons pas répondre avec au moins un exemple de requête, les définitions de tables impliquées, le plan de requête, etc. Peut-être y a-t-il des conflits sur le serveur; quelle quantité de mémoire a le serveur par rapport à ce qui est vraiment nécessaire? Avez-vous des disques lents peut-être? Un grand nombre de demandes simultanées et un seul processeur? Autant de variables que vous n'avez pas mises en évidence. –

Répondre

0

Si votre requête fonctionnait bien avant, pensez aux autres éléments qui ont été modifiés: le planificateur de requêtes et le plan d'exécution réel peuvent vous aider à le repérer.

Lorsque vous dites que vous vous joignez, avez-vous réfléchi à combien vous vous joignez? Si la nouvelle machine contient plus de données dans la base de données, une jointure peut rapidement devenir trop coûteuse. Cela peut être fait en réduisant les données dont vous avez besoin, car moins de gestion des données signifie moins de charge de travail.

Y a-t-il quelque chose que vous pouvez pré-calculer avant d'exécuter votre requête, ou changer pour la faire tourner plus vite? Je suppose que vous faites un SELECT, mais si vous UPDATE ou DELETE données, les index doivent également être recalculés, ce qui prend beaucoup de temps (dans ce cas, désactiver l'index, insérer toutes les données nécessaires, puis recalculer le index)

Vous ne mentionnez aucune gestion XML, mais avez marqué la balise for-xml. Si votre jointure est effectuée sur des données XML, l'utilisation de Xquery pour obtenir les données peut également améliorer les performances.

+0

Si vous avez des informations supplémentaires sur votre requête ou comment elle se comporte, peut-être que je peux donner quelques conseils plus spécifiques :) – Martin

+0

Pourquoi pensez-vous qu'il y avait un changement dans la quantité de données? Si je comprends bien les mêmes fichiers de base de données ont été attachés à un autre serveur. Il ne devrait donc pas s'agir simplement d'une "requête lente générale", car auparavant c'était rapide avec la même quantité de données, les mêmes index, la même manipulation XML. – Galcoholic

+0

Salut - pas de changement à la quantité de données - une copie droite des fichiers mdf et ldf du serveur cassé à la nouvelle et rattacher. le "pour xml explicite" pour générer la sortie SQL à partir du SP. Ceci est fait en utilisant (ce que je n'utilise plus) le type de génération TAG/parent avec Unions pour créer l'ensemble de données et ensuite passer commande. Je ne ferais pas ça de cette façon maintenant! Aucune jointure sur les données XML. Il y a déjà un pré-calcul en cours. Je vais obtenir l'une des requêtes lentes et l'essayer sur l'instance SQL 2016 qui est également disponible sur le même.Besoin d'en trouver un qui n'a pas non-ANSI se connecte comme il le fera * PAS * de travail –