DBCC CHECKDB життєво важливий, щоб бази даних SQL Server були на 100% впевнені, що немає корупції. Однак через великі розміри баз даних дуже важко знайти вікно технічного обслуговування, коли ви стверджуєте, що на 24х7. Протягом багатьох років команда SQL Server впровадила різні механізми, які дозволять виявити найпоширеніші форми корупції, особливо пов'язані з фізичною корупцією, спричиненою апаратними засобами.
SQL Server 2005 і вище має PAGE_VERIFY = CHECKSUM, який може допомогти вам активно виявити фізичну пошкодження на сторінках бази даних, тим самим додаючи контрольну суму до кожної сторінки під час запису в систему вводу-виводу та перевіряючи контрольну суму під час її зчитування з диска.
Крім того, резервна копія (повна або диференціальна) за допомогою CHECKSUM гарантує виявлення будь-яких пошкоджень вводу / виводу, спричинених апаратним забезпеченням.
Отже, з апаратної сторони корупції, SQL Server робить гарну роботу з виявлення та повідомлення про це. (Не забудьте встановити також важливі сповіщення щодо корупції ).
Незважаючи на це, все ще логічна пошкодження , помилки, спричинені шифровальщиком - коли сторінки в пам'яті пошкоджуються або стороннім кодом, що працює в процесі роботи SQL Server, або драйверами або іншим програмним забезпеченням, що має достатньо привілеїв, що виконуються в режимі ядра Windows та / або SQL Server Помилки тощо не можна виявити за допомогою вищезазначених методів, і отже, CHECKDB з'являється на світ.
DBCC CHECKDB проводить більш ретельну перевірку, яка включає перевірку заголовків сторінок на предмет можливої корупції, яку не можна виявити будь-якими іншими способами.
Будь-які існуючі сценарії там?
Замість того, щоб винаходити колесо, настійно рекомендую поглянути на рішення перевірки цілісності Ola SQL Server
Ефективний запуск DBCC CHECKDB:
Вам просто потрібно проявити творчість, коли ви щільно стежите у вікні технічного обслуговування, маючи величезну базу даних чи велику кількість баз даних, на яких запускається CHECKDB.
Після відвідування тренінгу з SQLSkills я реалізував:
- визначте, які таблиці важливо перевірити.
- розділіть таблиці на групи з різними пріоритетами, а потім запустіть
DBCC CHECKTABLEразом із запуском DBCC CHECKALLOCтаDBCC CHECKCATALOG
- Створіть таблицю робітників, яка буде зберігати назви таблиць із пріоритетами. Просто переконайтесь, що всі таблиці з високим пріоритетом (які є масово великими) не входять до однієї групи, інакше ваш CHECKDB взагалі не заповниться.
- Ви навіть можете мати стовпець тайм-ауту у вашій таблиці робітника, який буде оркеструвати, коли ваш CHECKDB буде вбитий, коли він пройде вікно технічного обслуговування.
- Додайте, скільки часу зайняло запуск однієї таблиці
DBCC CHECKTABLE, DBCC CHECKALLOCі DBCC CHECKCATALOG. Так що ви можете відчути , як довго він зазвичай приймає для перевірки , щоб бігти.
- Ви навіть можете запустити з
NOINDEXопцією, оскільки це прискорить роботу, оскільки вона не перевіряє некластеризовані індекси на таблицях користувачів. Це має певну перевагу, оскільки це не так важливо, як корупція даних, оскільки не втрачаються дані, і ви можете скинути та відтворити індекс, якщо це необхідно.
Очевидно, що видання Enterprise може скористатись паралельним виконанням операторів DBCC, але слідкуйте за налаштуваннями MAXDOP, оскільки це може сприйняти весь ваш процесор. Це може бути жорстко обмежене губернатором ресурсів.
Примітка. Якщо у вас стовпчик "ЗАПАСНА", ваш CHECKDB буде мертвим повільно, як описано тут .
Нарешті, це як запобігти корупції баз даних, використовуючи весь доступний набір інструментів + вашу віру в апаратну систему вашого сервера баз даних і, головне, значення ваших даних.
Деякі відмінні посилання: