Нові динамічні адміністративні уявлення в sql server 2016. Введення. Частина i

Відео: Зміна таблиці, індекси, уявлення MS SQL Server (Alter table, index, view)

У SQL Server 2016 з`явилося зовсім нове уявлення sys.dm_exec_session_wait_stats. За своєю суттю, воно дуже схоже на вже існуючі sys.dm_os_wait_stats: служить головним чином для повернення інформації про очікування на момент відгуку процесора на поточний запит, ініціатором якого є запит від призначеного для користувача сеансу. Однак між ними є дуже важлива відмінність: нове уявлення повертає цю інформацію з сеансовим рівнем деталізації.

Це надзвичайно цікаво, оскільки, включаючи ідентифікатор sessionid в форматі одного з повертаються стовпців, дане подання дає нам можливість підключення до безлічі інших динамічних адміністративних об`єктів, які відображають session id в формі одного зі своїх шпальт. На додаток до можливості виявлення обмежених ресурсів для проведення сеансу тепер ми можемо використовувати ідентифікатор sessionid для підключення до подання sys.dm_ exec_requests з метою агрегування статистики очікування в рівень запиту. Крім того, ми можемо виконувати аналогічні дії з використанням рівня журналу реєстрації транзакцій через уявлення sys.dm_trans_session_transactions (проміжне динамічне адміністративне уявлення, що встановлює відносини між ідентифікаторами session_id і transaction_id в системі SQL Server).


Після додавання в уявлення sys.dm_ exec_sessions стовпчика database_id в версії SQL Server 2014 ми можемо агрегувати очікування для всіх сеансів, пов`язаних з тією чи іншою конкретною базою даних. До виходу в світ версії SQL Server 2014 року, для того щоб повернути ідентифікатор database_ id або використовувати його в якості фільтра, потрібно об`єднати уявлення sys.dm_exec_sessions і sys.dm_exec_request. А це означає, що результати можна було отримувати тільки для сеансів з активними запитами - серйозний недолік, з точки зору тих, хто працює з метаданими. Просто дивно: на те, щоб прийти до думки про включення статистики очікування рівня сеансу, пішло цілих шість версій SQL, якщо вести відлік від моменту створення динамічних адміністративних об`єктів. Досить побіжного погляду на sys. sysprocesses, щоб зрозуміти, що ці відомості були доступні споживачеві ще до появи динамічного адміністративного об`єкта (див. скріншот вище):

SELECT spid, lastwaittypeFROM sys.sysprocesses

Звідси випливає, що дана інформація записувалась на рівні сеансів і навіть більш ймовірно, що на рівні запитів, оскільки запити виконувалися процесором Query Engine, але пред`являлися користувачеві або адміністраторові баз даних лише після агрегування на рівні примірника. Причому ми могли бачити цю інформацію з іншим рівнем деталізації тільки в уявленнях sys.dni_exec_sessions і sys. dm_exec_requests і тільки у вигляді окремих "відповідей" (а не агрегованих значень протягом життєвого циклу сеансу або запиту).

Відео: VIEW - створення простого представленіе.avi

Як було показано в численних статтях, журналах, книгах і презентаціях, ця статистика очікувань є накопичувальною. Щоб розібратися з існуючим станом очікувань, ми повинні докласти певних зусиль. Результати уявлення sys.dm_exec_wait_stats повертають відомості про очікування з моменту останнього запуску або перезапуску служб. Це означає, що ми бачимо результати всіх періодів діяльності: нормальні терміни завантаження і обслуговування, коли цілком ймовірно стрибкоподібне збільшення часу очікування OLEDB внаслідок виконання запитів за поданням sys.dm_db_index_ physical_stats, щоб отримати відомості про фрагментацію індексів, необхідні для обслуговування індексів. Крім того, ми отримуємо статистику очікування, пов`язану з такими періодами, коли який-небудь співробітник з відділу кадрів виконує нестандартний запит з метою отримання всіх відомостей про наймання співробітників компанії (оскільки він знову забув включити в свій запит дійсну дату початку). Тут я схиляюся до того, щоб здійснювати "нарізку" з часу всієї своєї колекції статистичних даних очікування. Я маю на увазі періодичне отримання відповідно до визначеного графіком дампов уявлення sys. dm_os_wait_stats, що включає стовпець date stamp, і перенесення цих даних в фізичну таблицю в базі даних, призначену для зберігання відомостей про завдання адміністрування і обслуговування або даних на кожному з моїх примірників. Це дозволяє скорочувати періоди очікування, утримуючи їх в певних межах, а не все навантаження з того моменту, коли служби були перезапущени. Труднощі з виконанням цього процесу тривали аж до випуску SQL Server 2016.

---