Сторінка 5 з 6
Як працює відстеження змін
Як я вже згадував, відстеження змін - це синхронний процес, який куди менш складний, ніж збір даних змін. Це частина транзакції, яка вносить зміну в рядок в відслідковується таблиці і той факт, що рядок змінилася, відслідковується в окремій таблиці. Дана таблиця - це те, що називається внутрішньої таблицею, і її ім'я з місцем зберігання не можна контролювати. Я не вважаю це проблемою, оскільки в цій таблиці має бути набагато менше даних, ніж в таблиці змін, використовуваної для збору даних змін. Але, як я зараз поясню, проблеми з простором на диски все ж можливі.
Той факт, що відстеження змін виконується синхронно, означає, що всередині кожної транзакції відбувається набагато меншою додаткової обробки, що змінює відстежуємо таблицю. Вплив на продуктивність подібно до того, що має місце при існуванні на таблиці некластерізованний індексу, який необхідно змінювати з кожною зміною таблиці. Самі транзакції також відслідковуються при їх послідовної фіксації у внутрішній таблиці sys.syscommittab.
Відстеження змін включається і відключається з використанням звичайного синтаксису ALTER DATABASE і ALTER TABLE і слід тієї ж моделі, що і збір даних змін, де воно повинно бути включено на рівні бази даних перед включенням на рівні таблиці. Послідовність операцій буде виглядати приблизно так:
Необхідні дозволи для включення відстеження змін на рівнях бази даних і таблиці також відрізняються від необхідних для включення збору даних змін: db_owner і власника таблиці, відповідно. Коли відстеження змін включається на рівні бази даних, можна встановити період зберігання, а також вказати, чи будуть дані змін очищатися автоматично. Період зберігання за умовчанням - 2 дня, з максимумом в 90 днів і мінімумом в одну хвилину.
Автоматичне очищення також включається за замовчуванням. При внесенні змін до ці параметри, необхідно оцінити ті ж пріоритети, про які я говорив стосовно збору даних змін, - що важливіше для програми: простір на диску або продуктивність.
За замовчуванням для кожного рядка збирається лише факт її зміни. Це виконується шляхом створення замітки з первинного ключа змінилася рядки (що означає неможливість відстежувати зміни на таблиці без первинного ключа), разом з номером версії (після того як на базі даних включено відстеження змін, встановлюється номер версії, що дозволяє визначити порядок операцій) і тип операції, яка виконала зміну. Як варіант, можна також відстежити, які стовпці змінилися, це вимагає 4 байт на змінився стовпець.
Спостереження за простором на диску дещо відрізняється від відстеження змін, оскільки дані про зміни зберігаються у внутрішніх таблицях. Щоб знайти імена використовуваних внутрішніх таблиць, просто використовуйте уявлення каталогу системи sys.internal_tables:
Потім передайте ім'я в sp_spaceused, щоб побачити, скільки використовується дискового простору.
На відміну від збору даних змін, коли включено відстеження змін, існують обмеження на DDL, який можна виконувати на відслідковується таблиці. Найбільш помітним обмеженням є неможливість будь-яким чином змінювати основний ключ. Інше обмеження, яке заслуговує згадки тут, полягає в тому, що ALTER TABLE SWITCH потерпить невдачу, якщо на будь-який з порушених таблиць було включено відстеження змін. Це, швидше за все, викликається тим фактом, що не має сенсу автоматично починати або видаляти відстеження змін для відключався, з відслідковується, розбитою на розділи, таблиці, розділу або відслідковується таблиці, що включається в розбиту на розділи таблицю, відповідно.
Зміни витягуються з внутрішніх таблиць змін з використанням нової функції CHANGETABLES (CHANGES ...). Вона приймає ім'я відслідковується на предмет змін таблиці плюс номер версії з попереднього разу, коли вона використовувалася, і повертає інформацію про всіх рядках, що змінилися з минулого разу. Існують різні функції для пошуку поточної і найбільш старої допустимої версії. Додаток може потім використовувати повернуту інформацію для запиту таблиці, відслідковується на предмет змін, щоб отримати реальні значення стовпців. Це, звісно ж, багатоетапний процес - спершу виходить поточна версія, потім ця версія використовується для запиту відстеження змін і потім власне таблиці запитуються на предмет даних стовпців, відповідних цій версії.
Всі ці питання я постійно бачу на форумах SQL Server, тому в даній статті я збираюся надати огляд системи ведення журналу та відновлення і пояснити, для чого існує ця невід'ємна частина модуля сховищ SQL Server. Буде розглянута архітектура журналу транзакції і те, яким обр.
Але хіба це єдине, що можна зробити? Існує можливість проводити попереджуючий моніторинг продуктивності, просту процедуру управління, яка використовує визначення базових параметрів роботи системи, отримання еталонів і безперервне спостереження. У цій статті я розповім про те, як п.
Однак вам не обов'язково так поступати. Є дуже проста альтернатива, яка використовує те, що ще відомо під назвою хеш-блоків або хеш-ключів. Що таке хешування? Говорячи коротко, хешування - це цілочисельний результат алгоритму (відомого як хеш-функція), що застосовується до заданої рядку.