Могу ли я улучшить производительность на раздутых системных таблицах?

Справочная информация: У
меня есть многочисленные базы данных с большим количеством VIEW и чрезвычайно большим количеством SYNONYM. Например, один дБ имеет более 10 000 просмотров и более 2 миллионов синонимов.

Общая проблема:
Запросы с участием sys.objects(и системных таблиц в целом), как правило, медленные. Запросы с участием sys.synonymsявляются ледниковыми. Мне интересно, что я могу сделать, чтобы улучшить производительность.

Конкретный пример
Эта команда запускается сторонним инструментом. Это медленно как в приложении, так и в SSMS:

exec sp_tables_rowset;2 NULL,NULL

Мой вопрос :
как я могу сделать это быстрее?

Что я пробовал :
если SET STATISTICS IO ONя получаю этот вывод:

(Затронуты строки 2201538)
Таблица 'sysobjrdb'. Сканирование 1, логическое чтение 28, физическое чтение 0, чтение с опережением 0, чтение логического объекта 0, чтение с физического объекта 0, чтение с опережением 0.
Таблица 'sysschobjs'. Сканирование 1, логическое чтение 53926, физическое чтение 0, чтение с опережением 0, логическое чтение с 0, физическое чтение с 0, чтение с опережением 0.

Мне удалось обновить статистику по базовым системным таблицам. Это работало в моей SQL 2008 R2 или более новых средах:

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

Я также был в состоянии выполнить обслуживание индекса. Это работает в моем SQL 2012 или более новых средах. Например, запуск работает, sp_help 'sys.sysschobjs'идентифицирует индексы в таблице, и оттуда я создаю и запускаю эти команды:

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

Обновление статистики и реорганизация индексов помогает, но не намного.

sql-server system-tables

— Дейв Мейсон
источник

Уч. Я предполагаю, что вы используете какой-то мультитенантный тип, запутывая все данные в одних и тех же таблицах, фильтруя их по представлениям и используя синонимы, чтобы называть их по имени базового объекта в большом масштабе? В любом случае, я чувствую к тебе

— Philᵀᴹ

Многоквартирные дома? Вообще-то, нет. Это не так. Довольно запутано, верно? FWIW, я понимаю, что для каждого пользователя приложения для каждой таблицы создано 5 SYNONYM. Повезло мне

— Дейв Мейсон

Повышает ли удаление разрешений для некоторых из этих объектов производительность (так что их потенциально можно использовать меньше?) Я не знаю, является ли это вариантом на уровне пользователя.

— ConstantineK

Было бы интересно увидеть план выполнения этого. может быть, вы могли бы опубликовать один из sql sentry plan explorer на answers.sqlperformance.com и ссылаться на него, если только здесь нет способа вставить это. Мне было бы интересно посмотреть на это

— SheldonH

Если вы еще этого не сделали, вы могли бы повысить производительность, переместив первичный файл данных в отдельный набор шпинделей из остальных данных (см. Архитектура файлов и файловых групп и SQL Server: файловая группа только для системных таблиц? ).

— Ziggy Crueltyfree Zeitgeister
источник

Я думаю, что это разумный совет, однако это сильно отразится на том, что настройка IO не является стандартным физическим сервером с подключенными дисками, например, виртуальным экземпляром с SAN, или SSD-диски минимизируют заметное влияние разделения первичных файлов данных. в другое место, верно?

— SheldonH

Если у вас есть контроль над оборудованием (т. Е. Вы не являетесь хостом третьей стороны), вы можете иметь разные наборы шпинделей в SAN (например, два или более отдельных тома RAID-10). Если вы используете (или размещаете) с твердотельными накопителями, то нет никаких шпинделей, и IO будет ограничен главным образом тем, что является узким местом между дисками и материнской платой (то есть карта SATA, RAID или NIC, кабели, маршрутизаторы / коммутаторы). , SAN, скорость SSD), так что вы ничего не получите, разделив файлы в этом случае.

— Ziggy Crueltyfree Zeitgeister