DBCC CHECKDB представляє собою команду на T-SQL, яка здійснює перевірку логічної і фізичної цілісності всіх об'єктів заданої бази даних. Більшість адміністраторів баз даних (DBA), ймовірно, не дуже замислюються про регулярність запуску DBCC CHECKDB - до тих пір, поки їх бази даних не стають дуже великими.
ІТ-інфраструктура для вашого підприємства
DBCC CHECKDB представляє собою команду на T-SQL, яка здійснює перевірку логічної і фізичної цілісності всіх об'єктів заданої бази даних. Більшість адміністраторів баз даних (DBA), ймовірно, не дуже замислюються про регулярність запуску DBCC CHECKDB - до тих пір, поки їх бази даних не стають дуже великими. З певного моменту, коли розміри вашої бази даних істотно виростуть, ви почнете стикатися з різними проблемами при запуску DBCC CHECKDB. Наприклад, час, необхідний для виконання процесу DBCC CHECKDB, може стати реальною перешкодою. Крім цього, може не знайтися вільного простору для знімків даних, створюваного в ході виконання DBCC CHECKDB.
Лістинг 1 містить сценарій щоденного обслуговування сервера під назвою ServerDailyMaintenance.txt. При виконанні цього сценарію створюється завдання Admin Job для служби SQL Server Agent. Це завдання адміністратору є єдиним завданням, яке дійсно планується до запуску, а воно породжує або модифікує і, власне, запускає виконання завдання для виконавця.
На екрані 1 показаний основний крок сценарію Admin Job, який запускає збережену процедуру msdb.dbo.mnt_DBCC.
Лістинг 2 містить опис процедури, що mnt_DBCC. Ця процедура ідентифікує наявні бази даних і приступає до побудови завдання виконавцю, Maintenance_DBCC_CHECKDB.
На екрані 2 показані параметри процедури mnt_DBCC і їх можливі значення, включаючи відомості про призначення кожної величини.
Завдання виконавцю створюється і запускається з завдання адміністратору (Admin Job) і називається Maintenance_DBCC_CHECKDB. Кожен крок завдання виконавця містить наступний крок перевірки на помилки. На екрані 4 зображено приклад виконання якогось кроку завдання виконавцю для бази даних AdventureWorks, для якого значення параметра @VLDB дорівнювало 1, а значення параметра @days дорівнювало 7.
Застосування концепції Admin / Worker Job має на увазі, що кожне завдання Worker Job формується динамічно, з щоночі модифікацією. Ви не будете втрачати хронологію завдань для Worker Job, тому що це завдання кожен раз оновлюється, а не видаляється і створюється знову.
Як працює параметр @VLDB?
Якщо значення цього параметра задано рівним 0, то Worker Job запускає простий процес DBCC CHECKDB. «Чари» трапиться, якщо зробити @VLDB рівним 1. Визначити для вашого оточення відповідне значення параметру @days допоможе підбір і тестування.
Коли параметру @VLDB присвоєно значення 1, що зберігається mnt_DBCC здійснює виклик процедури mnt_DBCC_VLDB, яка інспектує всі таблиці користувача, системні таблиці, індексовані уявлення і внутрішні таблиці в базі даних і визначає розмір кожної. Після цього всі таблиці розбиваються на N груп, число яких збігається зі значенням, заданим параметром @days. Мета була в тому, щоб розподілити таблиці по групах по можливості рівномірно, щоб вирівняти нічну навантаження на сервер. Кожна група таблиць отримує свій номер (VLDB_GROUP) в залежності від величини параметра @days. Номер групи, з якою слід працювати сьогодні, визначається за формулою:
Дана формула означає, що будь-яка наступна група буде оброблена незалежно від того, коли стартувало завдання. Завдання завжди «знає», які номери груп вже пройшли і які будуть наступними в роботі, так що немає необхідності зберігати будь-які дані в таблиці.
Щоб показати, як працює параметр @VLDB, розглянемо приклад.
Припустимо, що у вас є 10 таблиць і ви задали параметру @days значення 2. Процедура локалізує таблиці і визначає їх розміри; потім поміщає найбільшу за розміром таблицю в групу з номером (VLDB_Group = 0); наступну за величиною - в групу 1 (VLDB_Group = 1), потім повертаємося до групи і так, циклічно, до тих пір, поки всі таблиці не будуть згруповані. При запуску запиту
в результаті буде отримано 0 або 1. Якщо сьогодні - 0, то завтра буде 1, післязавтра - 0, і так далі. Кожна група таблиць буде оброблена, без запам'ятовування відомостей про те, до яких груп належать будь таблиці. А що трапиться, якщо друга за розмірами таблиця сьогодні збільшиться і стане найбільшою таблицею завтра? Ця таблиця буде пропущена, так як завтра вона переміститься в групу 0. Що якщо таблиці 1 і 2 одночасно виростуть або зменшаться, але так, що їх відносні розміри залишаться колишніми? У цьому випадку обидві таблиці будуть своєчасно оброблені. Найчастіше найбільша таблиця завжди буде найбільшою; друга за величиною залишиться другий і так далі; таким чином, жодна таблиця ніколи не буде пропущена, так як відносні розміри таблиць не змінюються. Якщо ж ви хочете гарантувати, що жодна з таблиць ніколи не буде пропущена в циклі обробки, то вам все ж доведеться модифікувати код зі збереженням імен в якоїсь спеціальної таблиці. Збережіть, наприклад, групи в перший день циклу і звертайтеся до цієї таблиці протягом всього періоду. Крім того, потрібно буде перевіряти, що ніякі таблиці не були видалені або додані з часу вибірки першого дня. Тепер зміна розмірів таблиць - не проблема (в тому числі якщо найбільша на сьогодні таблиця завтра стане другою за величиною).
При параметрі @VLDB, встановленому рівним 1, створюється також завдання виконавця, яке при кожному запуску також виконує і DBCC CHECKALLOC, і DBCC CHECKCATALOG (як показано на екрані 4).
Інструкція по застосуванню
Завдання DBCC CHECKDB, що використовує описаний метод Admin / Worker Job, представляється досить розумним, гнучким і не вимагає додаткового супроводу: ви можете виконати його на базі даних будь-якого розміру. Завдання виконується автоматично з усіма базами даних, які ви додали, за винятком раніше віддалених. Крім того, код завдання ідентифікує бази даних - дзеркальні відображення (mirrored) і ті, що знаходяться в стані offline з якої-небудь іншої причини. Ви можете визначити, чи слід виконувати завдання тільки для системних або тільки для фізичних баз даних. І, головне, ви можете розгорнути навантаження DBCC CHECKDB на будь-яку кількість днів, яке буде задано.
Лістинг 1 ServerDailyMaintenance.txt
Лістинг 1 ServerDailyMaintenance.txt (закінчення)
Лістинг 2 mnt_DBCC.txt
Лістинг 2 mnt_DBCC.txt (продовження)
Лістинг 2 mnt_DBCC.txt (закінчення)
Лістинг 3 mnt_DBCC_VLDB.txt
Лістинг 3 mnt_DBCC_VLDB.txt (закінчення)