2010-08-24 3 views
0

J'ai une base de données avec un nombre plutôt élevé de tables, environ 3500, et une application qui doit accéder à une liste de tables.Requêtes d'informations de schéma très lentes sur SQL Server 2005

Sur un serveur particulier, cela prend plus de 2,5 minutes pour revenir.

EXEC sp_tables @table_type="'TABLE'" 

Je sais qu'il ya des moyens plus rapides pour le faire, mais malheureusement, je ne suis pas en mesure de modifier l'application et la nécessité de trouver un moyen de le pousser au-dessous de 30 secondes pour que l'application ne jette pas des erreurs de délai d'attente .

Donc. Que puis-je faire pour améliorer les performances de ce serveur sp au sein de sql?

+0

Intéressant, a couru cela sur un db avec 3200 tables et a pris moins d'une seconde droite – SQLMenace

Répondre

0

J'ai vu ces procédures stockées s'exécuter lentement si vous n'avez pas l'autorisation GRANT VIEW DEFINITION définie sur votre compte d'utilisateur. D'après ce que j'ai lu, cela entraînera une vérification de sécurité ralentissant la requête. Peut-être un gourou SQL peut-il commenter pourquoi, si cela aide votre problème.

0

Eh bien, sp_tables est le code du système et ne peut pas être changé (peut contourner dans SQL Server 2000, SQL Server ne 2005+)

Vos options sont

  1. Modifier le SQL
  2. Change délai d'attente de commande
  3. Bigger serveur

Vous avez déjà dit "non" aux solutions évidentes ...

+0

. Malheureusement, je n'ai pas le choix dans cette situation. – Brian

+0

@Brian: désolé alors, vous n'avez pas d'autre choix que de ralentir les performances ... si votre application est verrouillée de sorte que ceux-ci sont lents alors vous avez des problèmes plus importants avec votre application. – gbn

0

Vous devez aborder cela comme n'importe quel autre problème de performance. Pourquoi est-il lent? À savoir, où bloque-t-il? Disque IO? CPU? Réseau? Verrouiller le conflit? La méthode scientifique consiste à utiliser une méthodologie comme Waits and Queues, ou son plus récent SQL 2008 equivalent Troubleshooting Performance Problems in SQL Server 2008. Le moyen paresseux consiste simplement à vérifier les colonnes wait_type, wait_time et wait_resource dans sys.dm_exec_requests pour la session exécutant l'appel sp_tables. Une fois que vous découvrez ce que bloque l'exécution, vous pouvez procéder en conséquence. Si j'essaie de deviner, vous découvrirez que le conflit est la cause: les autres sessions verrouillent exclusivement les métadonnées de la table et bloquent ainsi l'exécution de sp_tables, qui doit attendre la fin de toutes les opérations en face de lui.