Sql server: dmf. Зіставлення sys.dm_db_index_operational_stats і sys.dm_db_index_usage_stats

Нарешті настав час поглянути на чисту базу даних і виконати кілька тестових запитів, щоб показати основоположне вплив на метадані, записані в sys.dm_db_index_operational_stats.

При виконанні цих запитів забезпечте можливість перегляду діючого плану виконання. У цій серії тестів нас цікавлять результати, що надаються через наступні стовпчики в sys.dm_db_index_operational_ stats:
• range_scan_count;
• singleton_lookup_count (далі в цій статті);
• row_lock_count;
• page_lock_count;
• page_io_latch_wait_count.

Якщо ви вже зараз нічого не розумієте, тоді немає сенсу продовжувати читати цю статтю: далі буде ще складніше. Тому краще спочатку пройдете профільне навчання - подробиці на kbtu.kz/ru/fit/undergraduate/ac (https://kbtu.kz/ru/fit/undergraduate/ac).

Розглядаючи динамічне адміністративне уявлення sys. dm_db_index_usage_stats, ми зосередимося на наступних шпальтах:
• user_seeks;
• user_scans;
• user_lookups;
• user_writes.



Відразу хочу звернути вашу увагу на «темну сторону індексації»: негативний вплив додавання нових рядків за допомогою операцій INSERT і зміни значень в результаті операцій UPDATE і DELETE. У нас є порожня таблиця і пора додати в неї кілька значень. Виконайте наступну команду:

INSERT INTO lifeboat. [Dbo]. [DatabaseTypes] (DBTypeID, DBType) VALUES (1, `System`), (2, `User`), (3, `Sample`), (4, `Archive`), ( 5, `Test`), (6, `Stage`), (7, `QA`), (8, `Dev`) -

План виконання повинен мати вигляд, як на малюнку вище.

SELECT - IDENTIFICATION: DB_NAME (ixO.database_id) AS database__name, O.name AS object__name, I.name AS index__name, I.type_desc AS index__type, - LEAF LEVEL ACTIVITY: ixO.leaf_insert_count, - LOCKING ACTIVITY: ixO.row_lock_count , ixO.page_lock_count, - LATCHING ACTIVITY: ixO.page_io_latch_wait_countFROM sys.dm_db_index_operational_stats (DB_ID (), NULL, NULL, NULL) AS ixOINNER JOIN sys.indexes ION ixO.object_id = I.object_idAND ixO.index_id = I.index_idINNER JOIN sys .objects AS OON O.object_id = ixO.object_idWHERE O.is_ms_shipped = 0-

Відео: Indexes in sql server Part 35

Тепер можна побачити наслідки вставки восьми значень в таблицю в обох об`єктах DMO (див. Код вище і малюнок нижче). Реєструється вісім окремих вставок поряд з блокуваннями пов`язаних рядки і сторінки і допоміжним короткочасним блокуванням. Пов`язане значення page_io_latch_wait_in_ms дорівнювало 0, тобто очікування короткочасних блокувань становить менше мілісекунди і тому статистично незначно. Звідси можна зробити висновок про додаткові витрати на індексацію в базах даних SQL. Кожен індекс, що додається заради підвищення продуктивності операцій читання, негативно впливає на операції запису. Кожну операцію запису необхідно зареєструвати у всіх індексах.

Відео: Database Design 39 - Indexes (Clustered, Nonclustered, Composite Index)

SELECT O.name AS object__name, I.name AS index__name, I.type_desc AS index__type, ixU.user_seeks + ixU.user_scans + ixU.user_lookups AS total_user_reads, ixU.user_updates AS total_user_writesFROM sys.dm_db_index_usage_stats AS ixUINNER JOIN sys.indexes AS ION ixU .index_id = I.index_idAND ixU.object_id = I.object_idINNER JOIN sys.objects AS O ON ixU.object_id = O.object_idWHERE ixU.database_id = DB_ID () ORDER BY ixU.index_id ASC-

У тих, хто читав мої статті про динамічному адміністративному поданні (DMV) sys.dm_db_index_usage_stats (або ixU), може виникнути питання, яким чином sys.dm_db_index_operational_stats (або ixO) розрізняються в порівнянні, оскільки ми також збираємо статистику застосування. В обох випадках збирається інформація про використання, але врахуйте, що операційна DMF (ixO) надає метрики з позицій рівня в збалансованому дереві індексу, тоді як DMV використання (ixU) надає інформацію з позицій самого індексу. Ці вісім рядків, зареєстровані як вісім окремих вставок кінцевих елементів, представлені єдиною операцією записи індексу з позицій sys.dm_db_index_usage_stats (див. Код вище і малюнок нижче).

---