Foreversoft.ru

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

Проверка базы ms 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С и идём молиться настраивать планы обслуживания баз данных.

Исправление базы данных

Материал из Info

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

Содержание

Подготовка к изменению базы

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

  • Проверка свободного места на диске. Необходимо обратить внимание на папки, которые сохраняют базу данных, сам раздел с Windows и временные папки;
  • Ошибки MSDE , Microsoft SQL Server 2005/2008/2012/2014/2016 записываются в Event Log Windows (Start/Control panel/Administrative Tools/Event Viewer), откуда можно понять, где именно проблема: в диске, в базе данных или в самом SQL сервере;
  • Осуществляется проверка папок на наличие поврежденных секторов на диске;
  • Осуществляется проверка последней архивной копии базы данных, при условии, что обнаружено наличие архива, в котором установлено повреждение, и он не проходит проверку на целостность. Простейшим решением проблемы является восстановление базы данных из архива.

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

Access

При исправлении базы данных Access необходимо выполнить следующие действия:

  1. Обязательно создается архивная копия базы данных. Используются следующие методы:
    • Если есть возможность открыть базу данных при помощи самой программы, то резервная копия базы создается в меню Файл / Резервное копирование и восстановление. Имя и путь к базе данных проверяется в меню Файл / Активная база данных;
    • Если возникают проблемы с открытием базы данных при помощи программы, то осуществляется ее копирование вручную в другую, нерабочую папку. Папка базы данных описана в этой статье: Папка с продуктами.
  2. Открывается база данных в MS Access, версии 2003, 2007 или 2010. Для получения доступа к базе данных необходимо ввести инженерный пароль, который можно получить в отделе технической поддержки в Болгарии (Предоставляется только партнёрам Микринвест);
  3. Если при открытии базы данных Microsoft Access появляется сообщение, что файл не может быть использован, то возникает необходимость подключения дополнительного программного обеспечения для восстановления данных или поиска заархивированной копии базы данных;
  4. После открытия БД, в зависимости от версии MS Access, выбирается:
    • MS Access 2003 — из меню Tools->Database Utilities->Compact and Repair Database. ;
    • MS Access 2007 — выбирается кнопка Office Button, которая находится в верхнем левом углу, потом опция Manage и Compact and Repair Database;
    • MS Access 2010 — из меню File->Info->Compact & Repair;

Таким образом, изменение базы данных завершено.

MySQL

Для того чтобы произвести изменение базы данных сервера MySQL, необходимо наличие дополнительных инструментов:

После установки MySQL GUI Tools или MySQL Administrator, следует запустить MySQL Administrator, который запрашивает дополнительную информацию для соединения с сервером, содержащим базу данных.
Поля, необходимые для подключения к серверу:
Server Host — название или IP сервера, на котором находится база данных. Данные этого поля соответствуют аналогичным данным в настройке Microinvest Склад Pro;
Username — Имя пользователя для подключения к серверу. По умолчанию это root. Данные поля соответствуют аналогичным данным в настройке Microinvest Склад Pro;
Pasword — Пароль для подключения к серверу. Данные поля соответствуют аналогичным данным в настройке Microinvest Склад Pro.

Читать еще:  Ошибка chkdsk как исправить

После успешного запуска MySQL Administrator и осуществления подключения к базе данных, выполняются следующие шаги:

  1. Создаем архив базы данных:
    1. Используется Microinvest Архи Pro
    2. «MySQL Administrator» — содержит встроенные функции для создания архивов, выполняются следующие операции:
      • В верхнем левом меню выбирается Backup;
      • В нижнем правом углу нажимается кнопка New Project;
      • Левой кнопкой мыши выделяется база данных, которую хотите заархивировать (Schema);
      • Нажимается маленькая квадратная кнопка «>» для того, чтобы подтвердить выбор указанной базы данных. Она будет отражена в правой части приложения вместе с относящимися к ней таблицами (Backup Content);
      • Подтверждение происходит нажатием кнопки Execute Backup Now;
      • Открывается окошко Save As, в котором нужно указать, где будет сохранен архивный файл;
      • После выбора кнопки Save начинается процесс создания архива. Необходимо дождаться появления системного сообщения «The Backup was finished successfully». Операция по созданию архива заканчивается нажатием OK;
  2. В верхнем левом меню выбирается Catalogs. В нижнем левом меню появляются базы данных, которые расположены на данном сервере;
  3. Выбирается база данных и выделяется левой кнопкой мыши. В правой части программы появляется структура баз данных и относящиеся к ней таблицы (Schema Tables);
  4. В нижнем правом углу расположена кнопка Maintenance. Открываются опции задач, и там указывается Repair Tables. Подтверждается с «Next >>», выделяется уровень изменения Extended. Последним шагом является активация «Repair Tables».

На этом процесс изменения БД MySQL завершен.

MSDE и Microsoft SQL Server 2000

Для выполнения изменения базы данных необходимо наличие инструментов для управления самим сервером:

  1. Процедуры осуществляются с помощью Microsoft SQL Server Management Studio;
    • При условии, что версия Windows является 64-битной, скачать 64-битную версию можно по следующей ссылке: Microsoft SQL Server Management Studio;
    • Если на компьютере не установлен MSXML6.0, то этот компонент необходимо инсталлировать до начала установки Microsoft SQL Server Management Studio;
    • MSXML6.0 для 64-битной версии Windows доступен здесь;
  2. После успешной установки компонентов, запускается Microsoft SQL Server Management Studio и подключается к серверу MSDE путем указания имени и пароля пользователя для доступа к SQL серверу. Эти параметры настраиваются еще при установке MSDE и соответствуют параметрам для соединения с базой данных в программе;
  3. В Microsoft SQL Server Management Studio раскрывается папка Databases, выделяется база, которую необходимо восстановить, и при помощи правой кнопки мыши выбирается опция „New Query”. Аналогичный результат можно получить путем выделения левой кнопкой мыши базы данных, выбирая команду „New Query”;
  4. В открывшемся окне выписываются следующие команды:

где вместо db_name записывается имя базы, нуждающейся в восстановлении. Все заявки выполняются в окне путем нажатия клавиши F5 или кнопки Execute в Microsoft SQL Server Management Studio. В зависимости от величины базы данных и вида ошибок, время обработки заявки может варьировать от нескольких секунд до нескольких часов.

  1. Когда завершается обработка заявок, в Microsoft SQL Server Management Studio выводится информация по базе данных. Если в разделе Messages присутствуют строчки, выделенные красным цветом, это означает, что заявка обнаружила проблемы в БД. В большинстве случаев обнаруженные проблемы обработаны, и, соответственно, в разделе Messages следует описание о том, удалось ли устранить обнаруженные ошибки или нет.
  2. В том случае, если не удается установить, исправлена ли база данных, можно заново запустить заявки для проверки. При повторном запуске заявок не должно быть строк, выделенных красным цветом.

Microsoft SQL Server 2005+

Для выполнения исправления базы данных необходимо наличие инструментов для управления самим сервером:

  1. Процедуры осуществляются с помощью Microsoft SQL Server Management Studio 2005 или Microsoft SQL Server Management Studio 2008;
    • При условии, что версия Windows является 64-битной, скачать 64-битную версию можно по ссылке: Microsoft SQL Server Management Studio 2005 или Microsoft SQL Server Management Studio 2008;
    • Если на компьютере не установлен MSXML6.0, то этот компонент необходимо инсталлировать до начала установки Microsoft SQL Server Management Studio;
    • MSXML6.0 для 64-битной версии Windows доступен здесь;
  2. После успешной установки компонентов, запускается Microsoft SQL Server Management Studio и подключается к SQL Server. Имя пользователя и пароль соответствуют заданным при установке сервера и совпадают с логином и паролем программы;
  3. Раскрывается папка Databases, выделяется база, которую необходимо восстановить, и правой кнопкой мыши выбирается опция „New Query”. Аналогично базу данных можно выделить левой кнопкой мыши и выбрать „New Query”;
  4. В окне справа выводятся следующие команды:

где вместо db_name записывается имя базы, нуждающейся в исправлении. Все заявки выполняются в окне путем нажатия клавиши F5 или кнопки Execute в Microsoft SQL Server Management Studio. В зависимости от величины базы данных и вида ошибок, время обработки заявки может варьировать от нескольких секунд до нескольких часов;

  1. Когда завершается обработка заявок, в Microsoft SQL Server Management Studio выводится информация по базе данных. Если в разделе Messages присутствуют строчки, выделенные красным цветом, это означает, что заявка обнаружила и исправила ошибки в базе данных. В большинстве случаев эти проблемы устранены. В разделе Messages описано исправлены ли обнаруженные ошибки или нет;
  2. В том случае, если не удается установить, изменена ли база данных успешно, можно заново запустить заявки для проверки. При повторном запуске заявок не должно быть строк, выделенных красным цветом.

База в режиме Suspected

Иногда сам сервер сообщает, что определенная база является «сомнительной». В таком случае она отмечается как «Suspected», и появляется необходимость выполнения ряда команд.

Для Microsoft SQL Server 2005/2008/2008 R2/2012/2014/2016:

где вместо db_name пишется имя базы данных. В случае обнаружения ошибки, в разделе Messages будут присутствовать строчки, выделенные красным цветом. Необходимо выполнить все строки запроса. Строку DBCC CHECKDB ( ‘db_name’ , REPAIR_ALLOW_DATA_LOSS), возможно, придется выполнить несколько раз, до устранения всех ошибок.
Заявки необходимо обрабатывать последовательно, строчка за строчкой, а не все вместе.

Для MSDE и Microsoft SQL Server 2000 выполняются:

где вместо db_name пишется имя поврежденной базы данных. При наличии проблем, в разделе Messages вновь будут присутствовать строчки, выделенные красным цветом.
Заявки необходимо обрабатывать последовательно, строчка за строчкой, а не все вместе;

Читать еще:  Как в ворде включить исправление ошибок

Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www.microsoft.com/download

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

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

Читать еще:  Выделение ошибок в ворде

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

ALTER DATABASE Acc
SET MULTI_USER;

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

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

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

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

Проверка базы ms 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