Remkomplekty.ru

IT Новости из мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Sql проверка на ошибки

Проверка базы данных 1C на целостность и исправление ошибок MS SQL

Делимся опытом, как исправить ошибки в логической целостности в базе 1С, размещенной на Microsoft SQL Server.

Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.

Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.

Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:

Для начала переводим нужную нам БД в однопользовательский режим

Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:

Далее, вводим запрос на сканирование базы данных:

Проверка продлилась около 15 минут, после чего выдала следующее:

Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить

Вариант решения №2: В справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:

REPAIR_FAST

Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.

REPAIR_REBUILD

Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).

REPAIR_ALLOW_DATA_LOSS

Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай — пробуем REPAIR_REBUILD:

Не помогло, переводим базу данных обратно в многопользовательский режим:

На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.

Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку

Выгрузить базу данных в *.dt файл тоже не удалось:

Что ж, стало понятно, что часть потерянных данных – меньшее зло, по сравнению с «развалившейся» базой данных, пробуем REPAIR_ALLOW_DATA_LOSS:

И, наконец, после нескольких прогонов, количество ошибок немного уменьшилось:

Ситуацию это не спасло: база, по-прежнему не выгружалась и не «лечилась» средствами 1С.

Дальнейшие попытки (по очереди несколько раз запускал REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS) не увенчались успехом: количество ошибок не уменьшилось, база, по-прежнему, не выгружалась и не «лечилась».

Коллеги подсказали попробовать очистить (именно очистить, без удаления самой таблицы) «проблемную» таблицу в MS SQL.

Больше всего ошибок в таблице «_AccRg1051» – ей и было принято решение заняться:

И, после успешного выполнения, прогоняем проверку еще раз:

15 минут ожидания и, о чудо – все ошибки исчезли, в том числе и в остальных таблицах.

Перевожу базу в многопользовательский режим, выгружаю в *.dt файл и загружаю обратно.

Звоню бухгалтеру – прошу проверить проблемные документы: всё работает нормально. Пускаю остальных пользователей в базу.

Через час снова ошибка:

Делаем вывод, что выгрузка в *.dt – не панацея. Выгоняем Вежливо просим пользователей выйти и ещё немного потерпеть и тестируем базу с исправлением ошибок в режиме конфигуратора 1С со следующими параметрами

Видим, что всё ОК

Пускаем обратно пользователей в 1С и идём молиться настраивать планы обслуживания баз данных.

Проверка, восстановление и оптимизация баз MySQL

Программа mysqlcheck используется для проверки целостности (-c, -m, -C), восстановления (-r), анализа (-a) или оптимизации (-o) таблиц базы данных MySQL. Некоторые опции (например -e и -q) могут использоваться одновременно.

Не все опции поддерживаются различными движками MySQL. Опции -c, -r, -a и -o взаимоисключаемые, что означает, что будет применена последняя указанная опция.

Если не указано ничего, то будет применена опция -c. Альтернативами (синонимами) являются:

mysqlrepair: опция по умолчанию -r
mysqlanalyze: опция по умолчанию -a
mysqloptimize: опция по умолчанию -o

Проверить все базы данных. Аналогична опции —databases, если указать все базы данных.

Вместо выполнения запросов для каждой таблицы в отдельности выполнить все запросы в одном отдельно для каждой таблицы. Имена таблиц будут представлены в виде списка имен, разделенных запятой.

Анализировать данные таблицы.

Если проверенная таблица повреждена, автоматически восстановить ее. Исправления будут произведены после проверки всех таблиц, если были обнаружены повреждения.

Выводит информацию журнала отладки. Часто используется следующий набор параметров: ‘d:t:o,filename’

Директория, где находятся установки символов.

Проверить таблицу на наличие ошибок.

Проверить только таблицы, измененные со времени последней проверки или некорректно закрытые.

Использовать сжатие данных в протоколе сервер/клиент.

Вывести данную вспомогательную информацию и выйти из программы.

Проверить несколько баз данных. Обратите внимание на разницу в использовании: в этом случае таблицы не указываются. Все имена аргументов рассматриваются как имена баз данных.

Установить набор символов по умолчанию.

Проверить только базы данных, которые не были закрыты должным образом.

Продолжать даже при получении ошибки SQL.

При использовании данного параметра совместно с CHECK TABLE можно быть уверенным в целостности таблицы. Если же использовать этот параметр с REPAIR TABLE, запустится расширенное восстановление таблицы.

Хост базы данных.

Быстрее, чем —extended-check, но находит только 99,99 процентов всех ошибок.

Используемый пароль при подключении к серверу. Если пароль не указан, у пользователя запрашивается пароль с терминала.

Номер порта, используемого для подключения по TCP/IP.

Для указания протокола соединения, который надлежит использовать.

При использовании данной опции совместно с CHECK TABLE предотвращается сканирование строк для корректировки неправильных связей. Это наиболее быстрый метод проверки. Если же использовать этот параметр с REPAIR TABLE, программа попытается восстановить только систему индексов. Это наиболее быстрый метод восстановления таблицы.

Может исправить почти все, за исключением уникальных ключей, имеющих дубликаты.

Выводить только сообщения об ошибках.

Файл сокета, используемый для подсоединения.

Перекрывает опцию —databases (-B).

Имя пользователя MySQL, если этот пользователь в данное время не является активным.

Вывести информацию о различных этапах.

Вывести информацию о версии и выйти из программы.

Статья: Исправление ошибок DBCC CHECKDB (1С, SQL) вручную

Все началось с того, что после проблем с жестким диском на сервере и «не совсем удачным» восстановлением рабочей базы данных 1С начала сообщать «could not continue scan with nolock» при проведении документов и закрываться с непоправимой ошибкой. Бэкап был, но не самый свежий, а данные терять не хотелось. Что же лучше делать?

Такое сообщение говорит, как правило, о том, что данные базы разрушены.

Первым делом нужно сделать резервную копию.

Далее запускаем в SQL Management Studio и выполняем DBCC CHECKDB. Выполняем ее так, чтобы данные не терялись, параметр REPAIR_ALLOW_DATA_LOSS оставим на случай совсем безнадежный.

Например, наша база называется Office

Выполняем следующие запросы:

ALTER DATABASE Office
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB (N’Office’, REPAIR_REBUILD) WITH NO_INFOMSGS
GO

Смотрим что сообщила проверка и видим множество сообщений примерно такого содержания:

Msg 8928, Level 16, State 1, Line 2
Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data): Page (1:3605) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data). Page (1:3605) was not seen in the scan although its parent (1:6481) and previous (1:8859) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.

CHECKDB found 0 allocation errors and 8 consistency errors in table ‘DT3311’ (object ID 1970106059).
CHECKDB found 0 allocation errors and 43 consistency errors in database ‘Office’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Office, repair_rebuild).

После проверки выполняем запрос для дальнейших операций с базой данных:

Читать еще:  Ошибка айтюнс 1

ALTER DATABASE Office
SET MULTI_USER;

Как восстанавливать поврежденные страницы писать не буду. Статья рассчитана на простое администрирование и поможет даже при модели Simple. Те, кто делают бэкапы логов журнала транзакций очень-очень часто, сюда заходить не будут. Единственное условие — нам потребуется резервная копия (будем надеяться, что по теории вероятности самые свежие данные мы спасли без повреждений и бэкапы хоть иногда делали).

Как видим, все ошибки относятся к index id = 0 или index id = 1. Это говорит о том, что повреждены данные. Но не будем отчаиваться и воспользуемся резервной копией.

Обращаем внимание на сообщенную таблицу DT3311. Пытаемся открыть ее или прочитать данные запросом, возникает сообщение об ошибке:

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xacafd5b7; actual: 0x21c9cf6a). It occurred during a read of page (1:8473) in database ID 8 at offset 0x00000004232000 in file ‘E:SQL_DataOffice.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Обращаем внимание, на какой строке таблицы останавливается запрос при полном показе содержимого таблицы в графическом интерфейсе. Например, он показал нам данные до строки 1915.

Проверяем: запрос Select top 1915 * From DT3311 выполняется, а Select top 1916 * From DT3311 — уже нет.

Смотрим резервную базу, поле IDDOC в таблице начиная со строки 1916, это документ с ID ‘ 1SP ‘

В рабочей базе мы ничего с документом не можем сделать: ни открыть его в 1С, ни прочитать его табличную часть, ни удалить его. Что делать?

Предлагаю перебросить по кусочкам данные из разных баз (рабочей и резервной), удалить таблицу в рабочей базе, создать ее повторно и положить данные на место.

Создаем временную базу test, в ней создаем такую же таблицу DT3311 (для тех, кто не знает как это сделать быстро — картинки ниже на примере создания индексов) и выполняем запрос:

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC <> ‘ 1SP ‘

Запрос выполнился без ошибок. Это говорит о том, что других данных с «мусором» в этой таблице нет.

Данные о поврежденном документе берем из резервной копии. Выполняем запрос в резервной базе:

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC = ‘ 1SP ‘

Теперь в тестовой базе есть полные данные. Удаляем таблицу в рабочей базе, создаем заново и выполняем запрос:

Insert into DT3311
Select * From Test.dbo.DT3311

Пробуем прочитать полностью другие таблицы, ведь мы помним, что не проводились документы. Выясняется, что не могут прочитаться некоторые таблицы итогов регистров (RGXXX). В данном случае можно просто удалить эти таблицы, данные в них восстановит сама 1С. Заходим монопольно в 1С: Предприятие, сдвигаем ТА на самый первый документ, затем на самый последний проведенный документ. В результате итоги по регистрам пересчитаются.

Производим повторную проверку ошибок и убеждаемся в их отсутствии.

Беремся за другую базу, Acc.

Выполняем следующие запросы:

ALTER DATABASE Acc
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB (N’Acc’, REPAIR_REBUILD) WITH NO_INFOMSGS
GO

Для нее мы получили такой перечень ошибок:

Msg 8978, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:17191) is missing a reference from previous page (1:19106). Possible chain linkage problem.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 2
Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data): Page (1:19106) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data), page (1:19106). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 62916617 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:19106) was not seen in the scan although its parent (1:20741) and previous (1:15201) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 4 consistency errors in table ‘SC59729’ (object ID 1685581043).
CHECKDB found 0 allocation errors and 4 consistency errors in database ‘Acc’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Acc, repair_rebuild).

Тут картина совсем нестрашная. Данные не повреждены. Ошибки можно исправить удалением и созданием некластерных индексов.

Не забываем вернуть доступ к базе данных:

ALTER DATABASE Acc
SET MULTI_USER;

Для начала запишем скрипты на создание индексов (поочередно):

Затем удаляем индексы:

Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть).

Все исправили, производим повторную проверку и убеждаемся в отсутствии ошибок.

Оптимизация работы DBCC CHECKDB

В ваши обязанности, как DBA, вероятно входит оптимизация производительности, восстановление, настройка прав доступа и тд. Но многие склонны забывать о такой важной операции, как проверка целостности БД (DBCC CHECKDB). Вы можете решить данную задачу просто создав план обслуживания «»Check Database Integrity Task», однако это всего лишь checkdbox.

Читать еще:  Ошибки http протокола

Как вы видите, здесь мы почти не можем ничего контролировать, хотя для данной операции существует множество интересных ключей. Я думаю, что вам следует более детально погрузиться в DBCC CHECKDB и создать собственное, подходящее именно вам, задание. Основным преимуществом собственного задания будет сокращение времени работы и как следствие уменьшение требуемых ресурсов для данной операции. Так же могут быть такие преимущества как универсальность, управляемость, обработка ошибок и тд.

Уменьшение вывода и сбор всех ошибок:

Не важно где вы запускаете CHECKDB, всегда запускайте с опцией WITH NO_INFOMSGS. Эта простая опция подавляет все информационные сообщения, которые просто сообщают вам как много строк в каждой таблице, если вам необходима данная информация, вы можете получить её из DMV, вне команды CHECKDB.

Так же вы всегда должны использовать опцию WITH ALL_ERRORMSGS, особенно если вы используете SQL Server 2008 RTM или SQL Server 2005 (тогда вы сможете увидеть более 200 строк). Любая CHECKDB операция обрезается 1000 строками в Management Studio и иногда может потребоваться перенаправить вывод в файл. Понимание данного механизма позволит вам получать всю информацию с первого раза и не будет надобности перезапускать процесс.

Используйте только физическую проверку данных на продуктивной среде:

В большинстве случаев, CHECKDB тратит основное время на логические проверки данных. Если у вас есть возможность провести данную проверку на достоверной копии данных, то вы можете сфокусироваться только на физической структуре на вашей продуктивной системе. Под достоверной копией данных я понимаю ТОЛЬКО восстановление БД из backup на другом сервере.

Такие способы как:

  1. Группа доступности AlwaysOn
  2. Snapshot по верх database mirroring
  3. Log Shipping
  4. И тд.

Не являются достоверной копией данных и логическая проверка на данных технологиях, не даст достоверный результат относительно продуктивной среды. Только точно такая же копия БД может быть достоверной.

Эксперименты с флагами трассировки 2549, 2562, and 2566:

Я нашёл, что флаги трассировки 2549 и 2562 могут улучшить производительность CHECKDB. Найти описание данных флагов можно в KB #2634571, но в целом:

Trace Flag 2549 (оптимизирует процесс проверки из расчёта, что каждый файл данных БД лежит на своём собственном диске. Флаг можно использовать когда БД имеет один файл данных или каждый файл данных лежит на своём диске, в противном случае это может ухудшить производительность CHECKDB)

Trace Flag 2562 (процесс CHECKDB будет запущен в одном батче, что будет более дорогой операцией для tempdb (до 5% от размера проверяемой БД). Это более лучший алгоритм для чтений страниц из БД, который уменьшает latch contention). Данный флаг уже включён в SQL Server 2012, так что начиная с этой версии включать его отдельно не требуется.

Trace Flag 2566 (Если вы до сих пор используете SQL Server 2005 (напоминаю что Microsoft уже не поддерживает данную версию), то вы можете использовать флаг 2566, который представлен в SP2 CU9. Флаг исправляет проблему производительности DATA_PURITY на x64 системах. Вы можете посмотреть подробности KB #945770. Данный флаг не требуется включать на других версиях SQL Server)

Если вы решитесь использовать данные флаги, то я настоятельно рекомендую включать их с помощью DBCC TRACEON, а не через параметры запуска SQL Server. Это даст вам возможность выключить флаги без перезагрузок.

Уменьшение нагрузки на дисковую подсистему (оптимизация tempdb):

DBCC CHECKDB может сильно нагружать tempdb, постарайтесь выделить для данной БД достаточно ресурсов (тестируйте).

Уменьшение нагрузки на дисковую подсистему (snapshot):

Запуская DBCC CHECKDB, современные версии SQL Server создают скрытый snapshot вашей БД на том же диске (или на тех же дисках если вы используете несколько файлов tempdb). Вы не можете контролировать данный механизм, но если вы хотите указать где именно необходимо создавать snapshot, то вы можете сделать свой snapshot на любой диск (доступно только в Enterprise Edition) и запустить DBCC CHECKDB по данному snapshot. Лучше всего пользоваться данным методом в период минимальной активности на запись-обновление вашей БД.

Вы можете ускорить DBCC CHECKDB запустив его в offline mode (с блокировками) используя опцию WITH TABLOCK. Я строго не рекомендую этим пользоваться, так как это значительно ухудшит доступность БД.

Уменьшение нагрузки на CPU:

DBCC CHECKDB запускается в параллельном режиме по-умолчанию, но только если у вас Enterprise Edition. Если у вас недостаточно CPU ресурсов, то вы можете уменьшить параллелизм несколькими способами:

  1. Используйте Resource Governor начиная с 2008 (доступен только в Enterprise Edition). С помощью данного механизма можно создать ресурсный пул, которому будут выделены ограниченные ресурсы и запустить процесс DBCC CHECKDB в данному пуле
  2. Используйте флаг 2528 чтобы отключить параллелизм для DBCC CHECKDB
  3. DBCC CHECKDB не поддерживает команду MAXDOP, но её можно ограничить глобальной настройкой сервера «max degree of parallelism». Будьте осторожны, эта настройка влияет на весь сервер и всю его активность.

К сожалению, Microsoft не планирует реализовывать использование MAXDOP для CHECKDB, хотя их об этом неоднократно просили.

Мои результаты:

Я хотел бы продемонстрировать влияние описанных выше способов на время выполнения DBCC CHECKDB. Тесты производились на БД AdventureWorks2012 и с запуском скрипта, который увеличил размер данной БД до 7 ГБ:

CHECKDB results against 7 GB database

Далее я увеличил размер БД до 70 ГБ и провёл тесты снова:

CHECKDB results against 70 GB database

Главные мысли после тестов:

  1. Когда я запускал DBCC CKECKDB с логической проверкой на боевом сервере:
    • На малых БД опция NO_INFOMSGS может существенно снизить время выполнения, когда запускается в SSMS. На больших БД эффект уменьшается.
    • Оба флага трассировки оказали существенные эффект на производительность DBCC CHECKDB (40%-60% если использовать их совместно)
  2. Когда я запускал DBCC CKECKDB с логической проверкой на вторичном:
    • Я снизил время выполнения на 70-80% на боевой системе.

Хотелось бы продемонстрировать нагрузку на CPU во времяDBCC CHECKDB:


CPU impact during CHECKDB – sample mode


CPU impact during CHECKDB – historical mode

На больших БД результаты могут отличаться, поэтому вам обязательно надо проводить своё собственное тестирование.

Заключение:

DBCC CHECKDB очень важная и часто недооцененная задача DBA. Не совершайте ошибки других DBA.

DBCC CHECKDB для очень больших баз данных

DBCC CHECKDB представляет собой команду на T-SQL, которая осуществляет проверку логической и физической целостности всех объектов заданной базы данных. Большинство администраторов баз данных (DBA), вероятно, не особенно задумываются о регулярности запуска DBCC CHECKDB — до тех пор, пока их базы данных не становятся очень большими.

DBCC CHECKDB представляет собой команду на T-SQL, которая осуществляет проверку логической и физической целостности всех объектов заданной базы данных. Большинство администраторов баз данных (DBA), вероятно, не особенно задумываются о регулярности запуска DBCC CHECKDB — до тех пор, пока их базы данных не становятся очень большими. С некоторого момента, когда размеры вашей базы данных существенно вырастут, вы начнете сталкиваться с различными проблемами при запуске DBCC CHECKDB. Например, время, необходимое для выполнения процесса DBCC CHECKDB, может стать реальным препятствием. Помимо этого, может не найтись свободного пространства для снимков данных, создаваемого в ходе выполнения DBCC CHECKDB.

Читать еще:  Ошибка форматирования карты памяти на фотоаппарате

Ваше задание должно быть организовано достаточно гибко, чтобы, помимо решения проблем с очень большими базами данных (VLDB), оно могло различать новые базы данных, удаленные или иные недоступные базы данных, находящиеся в offline-режиме, или, например, зеркальные отображения баз данных. Чтобы научиться управляться со всем этим, я могу предложить простое решение, использующее концепцию «задание для администратора и исполнителя», Admin/Worker Job. Далее в статье будет рассмотрено задание администратору и задание исполнителю, а также параметр @VLDB. Все сценарии из данной статьи исполняются как на SQL Server 2008, так и на SQL Server 2005.

Задание администратору

Листинг 1 содержит сценарий ежедневного обслуживания сервера под названием ServerDailyMaintenance.txt. При исполнении этого сценария создается задание Admin Job для службы SQL Server Agent. Это задание администратору является единственным заданием, которое действительно планируется к запуску, а оно порождает или модифицирует и, собственно, запускает выполнение задания для исполнителя.

На экране 1 показан основной шаг сценария Admin Job, который запускает хранимую процедуру msdb.dbo.mnt_DBCC.

Листинг 2 содержит описание хранимой процедуры mnt_DBCC. Эта процедура идентифицирует имеющиеся в наличии базы данных и приступает к построению задания исполнителю, Maintenance_DBCC_CHECKDB.

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

Чтобы работать только с системными базами данных (model и master), параметр @system_only должен быть задан равным 1. Чтобы выполнить команду DBCC CHECKDB только с настройкой physical_only, следует присвоить значение 1 параметру @physical_only. Для большинства баз данных следует придерживаться значения для параметров @system_only и @physical_only. Для категории VLDB вам, возможно, потребуется присвоить значение 1 параметру @VLDB. Если вы зададите это значение (1) для @VLDB, то вам придется определиться и со значением для параметра @days. Параметр @days игнорируется, если @VLDB равен 0. Значение для @VLDB означает, что будет выполняться стандартная команда DBCC CHECKDB. Если вы присваиваете параметру @VLDB значение 1, то процедура mnt_DBCC вызывает на исполнение хранимую процедуру mnt_DBCC_VLDB, код которой представлен в листинге 3. На экране 3 представлен список параметров этой хранимой процедуры и возможных значений.

Задание исполнителю

Задание исполнителю создается и запускается из задания администратору (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_Group = DATEDIFF (dd, N’01–01–2009′, GETDATE ())% @days

Данная формула означает, что любая следующая группа будет обработана независимо от того, когда стартовало задание. Задание всегда «знает», какие номера групп уже прошли и какие будут следующими в работе, так что нет необходимости сохранять какие-либо данные в таблице.

Чтобы показать, как работает параметр @VLDB, рассмотрим пример.

Предположим, что у вас есть 10 таблиц и вы задали параметру @days значение 2. Хранимая процедура локализует таблицы и определяет их размеры; затем помещает самую большую по размеру таблицу в группу с номером (VLDB_Group = 0); следующую по величине — в группу 1 (VLDB_Group = 1), затем возвращаемся к группе и так, циклически, до тех пор, пока все таблицы не будут сгруппированы. При запуске запроса

SELECT DATEDIFF (dd, N’01–03–2009’, GETDATE ())% 2

в результате будет получен 0 или 1. Если сегодня — 0, то завтра будет 1, послезавтра — 0, и так далее. Каждая группа таблиц будет обработана, без запоминания сведений о том, к каким группам относятся какие таблицы. А что случится, если вторая по размерам таблица сегодня увеличится и станет самой большой таблицей завтра? Эта таблица будет пропущена, так как завтра она переместится в группу 0. Что если таблицы 1 и 2 одновременно вырастут или уменьшатся, но так, что их относительные размеры останутся прежними? В этом случае обе таблицы будут своевременно обработаны. Чаще всего наибольшая таблица всегда будет наибольшей; вторая по величине останется второй и так далее; таким образом, ни одна таблица никогда не будет пропущена, так как относительные размеры таблиц не меняются. Если же вы хотите гарантировать, что ни одна из таблиц никогда не будет пропущена в цикле обработки, то вам все же придется модифицировать код с сохранением имен в какой-то специальной таблице. Сохраните, например, группы в первый день цикла и обращайтесь к этой таблице в течение всего периода. Кроме того, нужно будет проверять, что никакие таблицы не были удалены либо добавлены со времени выборки первого дня. Теперь изменение размеров таблиц — не проблема (в том числе если наибольшая на сегодня таблица завтра станет второй по величине).

При параметре @VLDB, установленном равным 1, создается также задание исполнителя, которое при каждом запуске также выполняет и DBCC CHECKALLOC, и DBCC CHECKCATALOG (как показано на экране 4).

Инструкция по применению

Задание DBCC CHECKDB, использующее описанный метод Admin/Worker Job, представляется довольно разумным, гибким и не требует дополнительного сопровождения: вы можете выполнить его на базе данных любого размера. Задание выполняется автоматически со всеми базами данных, которые вы добавили, за исключением ранее удаленных. Кроме того, код задания идентифицирует базы данных — зеркальные отображения (mirrored) и те, что находятся в состоянии offline по какой-либо другой причине. Вы можете определить, следует ли выполнять задание только для системных или только для физических баз данных. И, главное, вы можете развернуть нагрузку DBCC CHECKDB на любое количество дней, которое будет задано.

Давид Поль Жиро — администратор баз данных в Microsoft, где он поддерживает сотни систем SQL Server для служб Xbox Live и Zune. Имеет сертификаты MCITP: Database Administrator и MCITP: Database Developer по SQL Server 2008 и 2005, а также MCDBA по SQL Server 2000

Ссылка на основную публикацию
Adblock
detector