Dbcc checkdb для дуже великих баз даних, windows it pro

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.

Dbcc checkdb для дуже великих баз даних, windows it pro

Лістинг 2 містить опис процедури, що mnt_DBCC. Ця процедура ідентифікує наявні бази даних і приступає до побудови завдання виконавцю, Maintenance_DBCC_CHECKDB.

На екрані 2 показані параметри процедури mnt_DBCC і їх можливі значення, включаючи відомості про призначення кожної величини.

Dbcc checkdb для дуже великих баз даних, windows it pro

Dbcc checkdb для дуже великих баз даних, windows it pro

Завдання виконавцю створюється і запускається з завдання адміністратору (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 для дуже великих баз даних, windows it pro

Інструкція по застосуванню

Завдання 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 (закінчення)