Чи можна покращити продуктивність на таблицях з роздутою системою?


12

Передумови: У
мене є чимало баз даних з великою кількістю VIEW та надзвичайно великою кількістю SYNONYM. Наприклад, один db має більше 10 кб оглядів і 2+ млн. SYNONYM.

Загальна проблема:
Запити, що стосуються 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 зчитування 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

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


Ой. Я здогадуюсь, що ти робиш якийсь заплутаний тип мульти-орендаря, зберігаєш дані всіх в одних і тих же таблицях і фільтруєш їх за поданнями та використовуєш синоніми для назви їх за базовим об’єктом у великому масштабі? Так чи інакше, я відчуваю вас
Philᵀᴹ

2
Багатоорендарний? Власне, ні. Це не так. Досить розгублений, правда? FWIW, я розумію, що для кожного користувача програми існує 5 SYNONYM, створених для кожної таблиці. Мені пощастило.
Дейв Мейсон

Чи дозволяє видалення дозволів на деякі з цих об'єктів підвищувати продуктивність (щоб їх було менше потенційно використовувати?) Я не знаю, чи це навіть варіант на рівні користувача.
КонстантинК

Цікаво було б побачити план виконання. можливо, ви могли б опублікувати його від sql sentry plan explorer на answer.sqlperformance.com та покласти на нього посилання, якщо тільки немає способу вставити це також тут. Мені буде цікаво подивитися
ШелдонH

Відповіді:


1

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


Я думаю, що це слушна порада, однак, було б заперечено на сильний вплив, якщо налаштування IO не є звичайним фізичним сервером із приєднаними дисками, наприклад, віртуальний екземпляр з SAN або SSD-накопичувачами, мінімізує помітний вплив розділення первинних файлів даних в інше місце, правда?
ШелдонH

1
Якщо ви керуєте обладнанням (тобто вас не приймає третя сторона), ви можете мати різні набори шпинделів в SAN (наприклад, два або більше окремих томів RAID-10). Якщо ви використовуєте (або розміщуєте їх) із SSD, то шпинделів немає, і введення-виведення обмежуватиметься, головним чином, вузьким місцем між накопичувачами та материнською платою (наприклад, карткою SATA, RAID або NIC, кабелями, маршрутизаторами / комутаторами) , SAN, швидкість SSD), тому ви нічого не отримаєте, розділяючи файли в цьому випадку.
Ziggy Crueltyfree Zeitgeister
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.