Puis-je améliorer les performances des tables de système gonflé?

Contexte:
J'ai de nombreuses bases de données avec un grand nombre de VUES et un très grand nombre de SYNONYMES. Par exemple, une base de données a plus de 10 000 VIEW et plus de 2 millions de SYNONYMES.

Problème général: les
requêtes impliquant sys.objects(et les tables système en général) ont tendance à être lentes. Les requêtes impliquant sys.synonymssont glaciaires. Je me demande ce que je peux faire pour améliorer les performances.

Exemple spécifique
Cette commande est exécutée par un outil tiers. Il est lent à la fois dans l'application et dans SSMS:

exec sp_tables_rowset;2 NULL,NULL

Ma question :
comment puis-je accélérer cette course?

Ce que j'ai essayé :
si SET STATISTICS IO ONj'obtiens cette sortie:

(2201538 ligne (s) affectée (s))
Table 'sysobjrdb'. Nombre de balayages 1, lectures logiques 28, lectures physiques 0, lectures anticipées 0, lectures logiques 0, lob lectures physiques 0, lob lectures anticipées 0.
Table 'sysschobjs'. Nombre de balayages 1, lectures logiques 53926, lectures physiques 0, lectures anticipées 0, lectures logiques 0, lob lectures physiques 0, lob lectures anticipées 0.

J'ai pu mettre à jour les statistiques sur les tables système sous-jacentes. Cela a fonctionné dans mes environnements SQL 2008 R2 ou plus récents:

UPDATE STATISTICS sys.sysobjrdb WITH FULLSCAN
UPDATE STATISTICS sys.sysschobjs WITH FULLSCAN

J'ai également pu effectuer la maintenance d'index. Cela fonctionne dans mes environnements SQL 2012 ou plus récents. Par exemple, l'exécution sp_help 'sys.sysschobjs'identifie les index sur la table, et à partir de là, je crée et exécute ces commandes:

ALTER INDEX clst ON sys.sysschobjs REORGANIZE
ALTER INDEX nc1 ON sys.sysschobjs REORGANIZE
ALTER INDEX nc2 ON sys.sysschobjs REORGANIZE
ALTER INDEX nc3 ON sys.sysschobjs REORGANIZE

La mise à jour des statistiques et la réorganisation des index sont utiles, mais pas beaucoup.

sql-server system-tables

— Dave Mason
source

Aie. Je suppose que vous faites un type de locataire multiple foiré, en conservant les données de tout le monde dans les mêmes tables et en les filtrant avec des vues et en utilisant des synonymes pour les nommer d'après l'objet de base, à grande échelle? Quoi qu'il en soit, je ressens pour vous

— Philᵀᴹ

Multi locataire? En fait non. Ça ne l'est pas. Assez foiré, non? FWIW, je crois comprendre que pour chaque utilisateur d'application, il y a 5 SYNONYMES créés pour chaque table. J'ai de la chance.

— Dave Mason

La suppression des autorisations sur certains de ces objets augmente-t-elle les performances (de sorte qu'il y en a moins à utiliser potentiellement?) Je ne sais pas si c'est même une option au niveau de l'utilisateur.

— ConstantineK

Il serait intéressant de voir un plan d'exécution à ce sujet. vous pouvez peut-être en publier un à partir de l'explorateur de plans sentinelles sql sur answers.sqlperformance.com et le lier à celui-ci, sauf s'il existe un moyen d'intégrer cela ici également. Je serais intéressant de le regarder

— SheldonH

Si vous ne l'avez pas déjà fait, vous pouvez gagner en performances en déplaçant le fichier de données principal vers un ensemble distinct de broches du reste des données (voir Architecture des fichiers et des groupes de fichiers et SQL Server: groupe de fichiers pour les tables système uniquement? ).

— Ziggy Crueltyfree Zeitgeister
source

Je pense que c'est un bon conseil, cependant, cela aurait un impact négatif si la configuration des E / S n'était pas un serveur physique standard avec des disques connectés, par exemple une instance virtuelle avec SAN, ou des lecteurs SSD minimiseraient l'impact notable de la séparation des fichiers de données primaires. à un endroit différent, non?

— SheldonH

Si vous contrôlez le matériel (c'est-à-dire que vous n'êtes pas hébergé par un tiers), vous pouvez avoir différents ensembles de broches dans un SAN (par exemple, deux volumes RAID-10 distincts ou plus). Si vous utilisez (ou hébergez) avec des SSD, il n'y a pas de broches et les E / S seraient limitées principalement par le goulot d'étranglement entre les lecteurs et la carte mère (c.-à-d. Carte SATA, RAID ou NIC, câblage, routeurs / commutateurs , SAN, vitesse des SSD), vous ne gagnerez donc rien en séparant les fichiers dans ce cas.

— Ziggy Crueltyfree Zeitgeister