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

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

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

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

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

Проверка базы данных 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.

После успешного запуска 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 вновь будут присутствовать строчки, выделенные красным цветом.
Заявки необходимо обрабатывать последовательно, строчка за строчкой, а не все вместе;

Восстановление БД MS SQL из статуса Suspect

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

Итак, во-первых останавливаем службу SQL Server и копируем файлы базы данных (*.mdf и *.ldf) в другую папку, чтобы можно было восстановить их в случае неудачи.

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

Для всех версий SQL Server подойдет следующий вариант: делаем Detach database (отсоединить базу данных), удаляем журнал транзакций (файл с расширением ldf) и делаем Attach database(присоединить базу данных). В мастере выбираем наш mdf файл и жмем ОК.

Если mdf файл не поврежден, то он успешно присоединится и мы увидим нашу базу в диспетчере объектов целую и невредимую.

Радуемся успешному восстановлению. (Этот вариант сработает только если mdf файл не поврежден, поэтому срабатывает не всегда). Если не получилось, то создаем новую базу данных с таким же именем, останавливаем сервер. Подменяем файл mdf файлом от нашей базы, стартуем службу SQL Server и открываем Query analyzer(SQL 2000) или Management studio(SQL 2005/2008) в зависимости от нашей версии сервера.

USE master
GO
sp_configure ‘allow updates’, 1
reconfigure WITH override
GO

Если у вас SQL 2000, то далее пишем:

UPDATE sysdatabases SET STATUS= 32768 WHERE name = ‘db_name’
GO

Если SQL 2005 или 2008, то пишем:

ALTER DATABASE db_name SET EMERGENCY, SINGLE_USER
GO

где вместо db_name пишем имя своей БД

Жмем F5. После этого наша БД должна быть видна в статусе EMERGENCY.

В особо тяжелых случаях возникают проблемы с переходом в EMERGENCY, возможны даже проблемы с detach, в таких случаях поврежденная база удаляется, а далее происходит хитрая подмена файлов данных. Для начала создадим новую базу, имена файлов mdf и ldf должны совпадать с именами файлов поврежденной базы. Новую базу переводим в режим EMERGENCY, останавливаем службу MSSQL и подменяем файлы поврежденными. Таким образом мы получим рабочий инстанс в статусе EMERGENCY с поврежденными файлами.

Отлично, приступаем к восстановлению.

Выполним следующие SQL команды.

DBCC REBUILD_LOG(‘db_name’, ‘Полный путь к новому файлу ldf’)
GO

Жмем F5, если все нормально, сервер скажет: Warning: The log for database ‘db_name’ has been rebuilt.

Стираем и пишем:

USE master
GO
sp_dboption ‘db_name’, ‘single user’, ‘true’
GO
USE db_name
GO
DBCC CHECKDB(‘db_name’, REPAIR_REBUILD)
GO

Если база не хочет в single mode можно попробовать такую команду

USE db_name
ALTER database db_name set SINGLE_USER with rollback immediate
GO

если DBCC не хочет выполняться, то вместо REPAIR_REBUILD нужно подставить REPAIR_ALLOW_DATA_LOSS

Жмем F5, ждем некоторое время. Сервер вернет кучу сообщений. Если там будут содержаться ошибки, то лучше еще раз выполнить DBCC CHECKDB с параметром REPAIR_REBUILD, пока все ошибки не будут устранены.

Для SQL 2005/2008 действия несколько иные:

DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)
GO

Тут без вариантов. В SQL 2005 и выше нет инструкции REBUILD_LOG, вместо этого выполняется CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS.

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

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

USE master
GO
sp_dboption ‘db_name’, ‘single user’, ‘false’
GO

Для SQL 2005/2008:

ALTER DATABASE db_name SET ONLINE, MULTI_USER
GO

Все. База онлайн и готова к работе. Радуемся и не забываем делать бэкапы.

Проверка, восстановление и оптимизация баз 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, если этот пользователь в данное время не является активным.

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

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