Foreversoft.ru

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

Проверка базы sql на ошибки

Статья: Исправление ошибок 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).

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

ALTER DATABASE Office
SET MULTI_USER;

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

Как видим, все ошибки относятся к index >

Обращаем внимание на сообщенную таблицу 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

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

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).

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

Читать еще:  Msi 1921 ошибка

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

ALTER DATABASE Acc
SET MULTI_USER;

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

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

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

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

Восстановление отдельных страниц в базе данных

Предисловие

Статья Gail Shaw «Help, my database is corrupt. Now what?», перевод которой я запостил на прошлой неделе, вызвала, вроде бы, определенный интерес, но она, увы, не содержала «практики». Да, там написано как можно спасти данные, но нет никаких примеров.
Изначально я хотел сделать еще один перевод все того же автора, но, подумав, решил написать пост «от себя», как бы «по мотивам». Причины, побудившие меня поступить так, я опишу в конце поста, в примечаниях.

Восстановление баз данных в SQL Server

Как уже было сказано в предыдущей статье, в том случае, если повреждены страницы кластерного индекса или кучи, то данные, содержащиеся на этих страницах, потеряны и единственным вариантом для их восстановления является непосредственно восстановление базы данных.

SQL Server предоставляет множество возможностей для восстановления баз данных. Во-первых, это восстановление базы данных целиком — оно может занимать довольно много времени (зависит от размера БД и скорости жестких дисков). Во-вторых, восстановление отдельных файловых групп, либо файлов, если ваша БД состоит из нескольких файловых групп (или, соответствено, файлов). В этом случае, есть возможность восстановления только поврежденных частей БД, не затрагивая остальных. Эти два вида восстановления БД используются довольно часто и затрагиваться в дальнейшем не будут.
В-третьих, в SQL Server 2005 появилась возможность восстановления отдельных страниц БД — в этом случае из бэкапа будут восстановлены только указанные страницы. Такое восстановление будет особенно актуально, если DBCC CHECKDB найдет несколько поврежденных страниц в какой-нибудь огромной таблице, «лежащей» в здоровенном файле. За счет того, что восстанавливаться будет не весь файл, и даже не вся таблица, а только несколько страниц — время простоя может быть значительно сокращено.

Требования и ограничения

Модель восстановления и доступность резервных копий журнала транзакций

Самое главное, что нужно помнить — для восстановления отдельных страниц, база данных должна использовать полную (full) модель восстановления, либо модель восстановления с неполным протоколированием (bulk-logged). Если ваши базы находятся в простой (simple) модели восстановления — дальше вы можете уже и не читать.
Второе требование — ваши полные бэкапы и бэкапы журнала транзакций должны образовывать неразрывную цепочку журналов (log chain). Если вы никогда не выполняете команду BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) и не переключаетесь в простую модель восстановления для того, чтобы уменьшить журнал транзакций, и у вас есть ВСЕ резервные копии журнала транзакций с момента последней полной резервной копии не содержащей поврежденных страниц (включая эту самую полную резервную копию) — за цепочку журналов можно не волноваться.
В модели восстановления с неполным протоколированием, теоретически, восстановление отдельных страниц должно работать нормально в том случае, если соблюдаются условия описанные выше, и восстанавливаемые страницы не изменялись операциями, выполняемыми с минимальным протоколированием.

Редакции SQL Server

Восстановление страниц возможно в любой редакции SQL Server, но для редакций Enterprise Edition и Developer Edition возможно восстановление поврежденных страниц on-line, т.е. к базе данных, во время восстановления, можно обращаться (и более того, обращаться можно даже к той таблице, к которой относятся восстанавливаемые в данный момент страницы, если сами эти страницы не будут «затрагиваться» — в противном случае, запрос завершится ошибкой). Для редакций «ниже» Enterprise Edition, восстановление страниц проходит в режиме off-line и база данных, на время восстановления, становится недоступной.

Тип поврежденной страницы

В том случае если повреждены страницы индекса, либо данных, их восстановление возможно в режиме online в редакции Enterprise Edition.
Страницы, приндалежащие критически важным системным таблицам могут быть восстановлены, но база данных, при восстановлении, будет недоступна в любой редакции SQL Server.
«Карты размещения» не могут быть восстановлены «отдельно». Если повреждены GAM, SGAM, PFS, ML, DIFF-страницы, необходимо восстанавливать базу данных целиком. Единственным исключением являются IAM-страницы. Хотя они и относятся к «картам размещения», но они описывают только одну таблицу, а не всю базу данных, и их восстановление возможно.
Загрузочная страница базы данных (9-я страница в 1-м файле БД) и страница заголовка файла (0-я страница в каждом файле) не могут быть восстановлены «отдельно», при их повреждении придется восстанавливать БД целиком.

Собственно, восстановление

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

Портим БД

Для экспериментов я буду использовать базу данных AdventureWorks, которая поставляется вместе с SQL Server. Если вы не устанавливали ее, при желании, можно скачать здесь. Перевожу ее в модель восстановления full:
убеждаюсь, что ошибок в ней еще нет:
и создаю полный бэкап:

Читать еще:  Ошибка при вызове метода контекста saveas


В этой базе данных я создаю таблицу crash.
Поле типа varchar мы и будем портить, для того, чтобы проверить что произойдет, если вдруг SQL Server обнаружит в нем не те данные, которые он сам туда записал.
Прежде чем что-то испортить, надо это чем-то заполнить. Я забиваю в созданную таблицу левые данные.
Теперь делаю резервную копию журнала транзакций:


Теперь немного изменим данные:

Итак, все готово. Отсоединяем БД и открываем mdf-файл FAR’ом (или чем вам удобнее), ищем в нем строку «zzzzzzz» и заменяем несколько ‘z’ на произвольные символы:

Теперь, когда БД испорчена, подсоединяем ее. И, да, я помню, что в предыдущей статье было четко сказано, что отсоединять/присоединять БД не стоит. Но в нашем случае это абсолютно «безопасно» — база данных в «suspect» не упадет.

Ищем ошибки

Итак, испорченная БД успешно вернулась в строй. Снова запустим проверку целостности:
В результате то, чего мы ждали (обязательно запоминайте номера поврежденных страниц!):

Msg 8928, Level 16, State 1, Line 1
Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data): Page (1:20455) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data), page (1:20455). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 29493257 and -4.
CHECKDB found 0 allocation errors and 2 consistency errors in table ‘crash’ (object ID 1883153754).
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘AdventureWorks’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (AdventureWorks).
В данном случае повреждены сами данные, находящиеся в куче (index > Сейчас у нас есть три варианта:

  1. Смириться с потерей данных и выполнить DBCC CHECKDB(‘AdventureWorks’, REPAIR_ALLOW_DATA_LOSS)
  2. Сделать бэкап активной части журнала транзакций и восстановить БД целиком — в результате потери данных не будет, но это займет продолжительное время
  3. Сделать бэкап активной части журнала транзакций и восстановить только одну(!), поврежденную, страницу

Со вторым вариантом все должно быть понятно, а вот что произойдет если запустить DBCC CHECKDB или как восстанавливаются отдельные страницы — я покажу дальше.

Восстанавливаем поврежденную страницу

В первую очередь нам надо сделать бэкап заключительного фрагмента журнала транзакций (tail backup). При этом, если у вас Enterprise Edition, вы можете не добавлять параметр NORECOVERY, который переведет БД в состояние «restoring», поскольку эта редакция поддерживает on-line восстановление страниц. Более того, если у вас резервные копии журнала транзакций выполняются на регулярной основе, чтобы не нарушать цепочку журналов, в редакции Enterprise Edition, вы можете сделать COPY_ONLY бэкап.
Я же иду по пути off-line восстановления и выполняю:


Теперь, можно восстанавливать поврежденную страницу. В первую очередь, используем полный бэкап (aw_full_ok1.bak):

В итоге, имеем:

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


Вроде бы все прошло успешно, запускаем DBCC CHECKDB и…

Восстановление прошло успешно.
Обратите внимание, что время простоя сокращается за счет того, что из полного бэкапа мы восстанавливаем не всю БД, а только поврежденные страницы (если бы я восстанавливал бэкап целиком — бэкап восстановился бы за 8,5 секунд, но, чем больше размер БД — тем больше будет разница во времени). Счастливчики с SQL Server Enterprise Edition, использующие on-line восстановление, так же сэкономят время на восстановлении из бэкапов лога, а при off-line восстановлении, увы, журналы будут обрабатываться целиком.
Стоит так же добавить, что в SQL Server 2005, 2008, 2008 R2 восстановление отдельной страницы возможно только с помощью T-SQL, в Denali появилась возможность делать это через GUI.

А если все-таки DBCC CHECKDB?

На всякий случай я решил проверить что сделает SQL Server, если я запущу DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Все та же ошибка:

Сначала переводим БД в режим SINGLE_USER:
А затем, запускаем восстановление:
В итоге:
Repair: The page (1:20455) has been deallocated from object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data).
Ага, SQL Server удалил «испорченную» страницу. Переводим БД в режим MULTI_USER, чтобы она стала доступной для всех и проверяем что пропало:

Учитывая, что размер страницы в SQL Server 8КБ, а для пользовательских данных доступно чуть меньше — то все закономерно, таблица «похудела» на 7 записей (в начале их было 99999). Поскольку на этой таблице не было кластерного индекса, данные могли храниться в произвольном порядке, т.е. мы даже не могли узнать какие данные будут потеряны.

Полезные команды для проверки работы MySql

Собрал список, который занимал у меня штук 30 открытых вкладок. Когда я понял, что сил по ним бегать нет, то решил собрать такой материал, в котором будут все необходимые команды для проверки работы базы данных Mysql и тестирования различных параметров. Теперь постараюсь всё это собрать воедино и сохранить. Кто читал предыдущую мою статью про настройки my.cnf тот уже видел, что я активно занимаюсь оптимизацией базы данных.

Mysqltuner команды проверки и реагирования

Название конечно звучит странно, но в этой части статьи именно все команды для проверки работы Mysql с помощью mysqltuner и соответственно необходимые команды для того, чтобы устранить некоторые проблемы.

В ТЕМУСТАТЬИ

Плагины и темы WordPress, экономика создания сайта на премиум уровне

Как в Mysql и MariaDB установить оптимальный параметр innodb_log_file_size

Что такое mysqltuner думаю обьяснять не надо, как и его задачу – проверку Mysql параметров. Зачастую кстати он выдаёт одинаковые рекомендации, но чтобы запустить его надо просто в командной строке набрать

Читать еще:  Метод шелла паскаль

Оптимизация всех баз данных

После этого начнется проверка параметров Mysql и появится вывод информации. Как правило в самом начале выходят данные о фрагментации баз данных, их необходимо оптимизировать. Для этого вводим в командную строку следующую команду:

Восстановление & Оптимизация
mysqlcheck -Aor -p
Только воcстановление
mysqlcheck -Ar -p
Только оптимизация
mysqlcheck -Ao -p

Описание аргументов:
-A – Проверить на ошибки все Mysql базы данных
-r – Отремонтировать все Mysql базы данных
-o – Оптимизировать все Mysql базы данных
-p – Для доступа к базе используется пароль

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

Вывод данных состояния MYSQL

Теперь следующий блок запросов, которые вводятся в Mysql для вывода данных о состоянии переменных

show status LIKE «Key%»; – выводит данные о состояние буфера ключей

show status LIKE «Opened_tables%»; – выводит данные об открытых таблицах

show status LIKE «Threads_running%» – вывод данных исходя из параметров умножения количества threads на параметры sort_buffer

show status LIKE «Max_used_connections%»; – данные о максимальном количестве одновременных подключений к базе. Помогает настроить максимальное количество подключений.

SHOW STATUS LIKE ‘Qcache%’; – выводит данные о работе кеша определенного query_cache_limit и query_cache_size.

show processlist; – данные о процессах Mysql

FLUSH QUERY CACHE – дефрагментировать кэш Mysql

Оптимизация медленных запросов Mysql

Следующая часть посвящена тому, как определить медленные запросы к Mysql и анализировать их.

Проверка базы sql на ошибки

В моменты бедствия проверка согласованности базы данных (DBCC), может оказаться вашим самый ценным другом. Здесь приводится краткий обзор того, что DBCC может сделать для Вас, в частности:

· Проверить целостность ваших таблиц и связанных с ними индексов.

· Проверить всю базу данных.

· Проверить целостность страниц базы данных.

· Восстановить индексы на заданной таблице.

Почему Вы должны дружить с DBCC

Если Вы задаетесь вопросом, почему использование DBCC является даже необходимым, то вот причины:

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

· Индексы могут испортиться или просто стать неэффективными.

· Движок Сервера SQL может иногда неправильно понять ваши намерения.

· В ситуациях, когда нормой является большое число обновлений, можно обрасти (помните, что каждое обновление — это фактически удаление и вставка).

· Отдельные страницы, хотя все еще «звучат», могут потерять свое оптимальное место хранения.

Как использовать DBCC

Вы можете запустить DBCC двумя способами: от командной строки и из окна Query Analyzer. Вы можете выполнять эти операции по расписанию, если считаете это необходимым. (Я никогда не чувствовал в этом потребности, поскольку из всех продуктов Microsoft я более всего уверен в стабильности SQL Server. Я полагаю, что это самый замечательный продукт, который когда-либо появлялся из Редмонда. Но не всегда все идет так, как надо.)

Команда DBCC имеет следующие расширения:

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

· CheckTable: проверяет заданную таблицу на наличие проблем.

· CheckAlloc: проверяет отдельные страницы данных в базе, занятые как таблицами, так и индексами.

· Reindex: восстанавливает индексы на указанной таблице.

· CacheStats: сообщает об объектах, в настоящее время находящихся в кэше памяти.

· DropCleanBuffers: Удаляет все данные, находящиеся в настоящее время в буфере, для того, чтобы Вы могли продолжить тестирование, не используя предыдущие результаты.

· Errorlog: стирает (усекает) текущий журнал. Вы могли бы задать расписание для выполнения джоба, содержащего эту команду, чтобы выполнять ее, например, один раз в неделю.

· FlushProcInDB: Очищает процедурный кэш для заданной базы данных (используйте ее dbid, а не имя). Вот так можно определить используемое id:

SELECT dbid FROM master.dbo.sysdatabases
WHERE name = ‘ ‘

· IndexDefrag: уменьшает фрагментацию в индексах, не накладывая блокировок на файлы, так что пользователи могут продолжать работу с базой данных.

· CheckCatalog: проверяет указанную базу данных на согласованность в таблицах и между ними (последнее означает внешние ключи и т.д.).

Как использовать пять из этих расширений

DBCC сначала создает снимок вашей базы данных (за исключением определенных специфических обстоятельств, например, работы с Master, TempDB или базой данных только для чтения). Условие: Чтобы использовать DBCC, ваша база данных должна находиться в однопользовательском режиме.

Использование DBCC CheckDB

Эта команда гарантирует, что: · Страницы данных и индексов правильно связаны.
· Индексы отсортированы правильно и актуальны.
· Указатели согласованы.
· Данные на каждой странице актуальны.
· Смещения страниц актуальны.

Ниже три самых общих способа использоватния CheckDB:

DBCC CHECKDB (‘AdventureWorks’, REPAIR_FAST)

DBCC CHECKDB (‘AdventureWorks’, REPAIR_REBUILD)

DBCC CHECKDB (‘AdventureWorks’, REPAIR_ALLOW_DATA_LOSS)

Использование DBCC CheckTable

Любые проблемы, с которыми Вы сталкиваетесь, чаще всего будут связаны с одной или более таблицами базы данных, а не всей базы данных. В таких случаях, запускайте DBCC CheckTable. Сначала перейдите в требуемую базу данных, а затем выполните команду DBCC CheckTable. Вот два примера:

DBCC CheckTable (‘Sales,SalesOrderHeader’)

DBCC CheckTable (‘Sales,SalesOrderHeader’, REPAIR_REBUILD)

Использование DBCC CheckAlloc

Эта команда проверяет согласованность страниц данных и их индексов. Ниже два примера:

DBCC CHECKALLOC (‘Sales.SalesOrderDetails’)

DBCC CHECKALLOC (‘Sales.SalesOrderDetails’, REPAIR_REBUILD)

Использование DBCC CheckCatalog

Используйте эту команду для проверки согласованности системных таблиц базы данных. Вы задаете имя базы данных, которую требуется проверить и необязательный аргумент WITH NO_INFOMSGS. Например:

DBCC CHECKCATALOG (‘AdventureWorks’)

Использование DBCC ReIndex

Эта команда вызывает перестройку одного или более индексов на заданной таблице или представлении. Вы можете также задать имя конкретного индекса, а также коэффициент заполнения (fill factor). Ниже два примера.

DBCC REINDEX (‘AdventureWorks.Sales.SalesOrderHeader’, PK_SalesOrderHeader_SalesOrderID’

DBCC REINDEX (‘AdventureWorks.Sales.SalesOrderHeader’, PK_SalesOrderHeader_SalesOrderID’, 90)

Третий аргумент указывает, что я хочу получить коэффициент заполнения 90 % на перестроенном индексе.

Дополнительная информация Теперь, когда Вы знаете самые общие примеры использования DBCC, обратитесь к Books Online за информацией о дополнительных аргументах и опциях для каждого варианта команды.

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