Bazaprogram.ru

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

Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке 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. Те, кто делают бэкапы логов журнала транзакций очень-очень часто, сюда заходить не будут. Единственное условие — нам потребуется резервная копия (будем надеяться, что по теории вероятности самые свежие данные мы спасли без повреждений и бэкапы хоть иногда делали).

Читать еще:  0xc004f074 как исправить

Как видим, все ошибки относятся к 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;

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

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

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

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

Тестирование и исправление базы 1С 8.3 — какие галочки ставить?

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

Перед выполнением тестирования и исправления необходимо сделать резервную копию базы. Если же вы не можете зайти в конфигуратор, то в папке с установленной программой 1С есть утилита для тестирования и исправления, которая не требует запуска программы в режиме конфигуратор. Обо всем этом поговорим ниже.

Рассмотрим этот инструмент и как с ним работать. Особенно подробно разберем какие флаги надо ставить в интерфейсе.

Если у вас нет времени читать, можете просто просмотреть наше видео:

Тестирование и исправление в конфигураторе

Запустим программу в режиме конфигуратор:

Выбираем из меню Администрирование пункт “Тестирование и исправление”:

Какие галочки ставить?

Существуют различные варианты настройки тестирования, рассмотрим эти галки:

  • Реиндексация таблиц информационной базы — это полное перестроение индексов для таблиц базы данных. Реиндексация повышает скорость работы информационной базы. Процедура длительная, но никогда не будет лишней.
  • Проверка логической целостности информационной базы — проверять логическую и структурную целостность БД, исправляет ошибки в данных;
  • Проверка ссылочной целостности информационной базы — проверка «битых ссылок» в базе данных. Такие ошибки могут возникать при непосредственном удалении объектов системы или сбоях. Существует 3 варианта действий для исправления таких ошибок:
    • Создавать объекты — система создает элементы-заглушки, которые можно потом заполнить необходимой информацией,
    • Очищать ссылки — «битые» ссылки будут очищены,
    • Не изменять — система только покажет вам ошибки.
  • Пересчет итогов. Итоги — таблица предварительно подсчитанных результатов в регистрах накопления, расчета и бухгалтерии. Пересчет итогов, также как реиндексация, никогда не будет вредна и даст плюс в скорости работы программы;
  • Сжатие таблиц информационной базы — при удалении данных 1С не удаляет строки таблиц, а лишь «помечает» их на удаление. Они не видны пользователю, но продолжат находится в БД. Сжатие базы данных удаляет эти данные безвозвратно. Так же такого же эффекта можно достичь выгрузкой и загрузкой файла информационной базы (*.dt);
  • Реструктуризация таблиц информационной базы — долгий процесс, с помощью которого система осуществляет пересоздание таблиц базы. Такая процедура происходит и при внесение изменений в структуру конфигурации.
Читать еще:  Fan error lenovo как исправить v580c

В нашем примере проставим все галочки как показано на рисунке и нажимаем “Выполнить”:

Этап выполнения операции мы можем наблюдать в левом нижнем углу окна конфигуратора 1С. Выявленные ошибки показываются в окне служебных сообщений.

После окончания тестирования нажимаем “Закрыть”:

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

Тестирование и исправление закончено.

Если конфигуратор не открывается: утилита chdbfl.exe

Если база повреждена настолько, что вы не можете зайти в конфигуратор, можно воспользоваться утилитой от 1С chdbfl.exe. Утилита устанавливается вместе с платформой 1С и найти ее можно в папке Bin каталога установки:

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

После того как нажали копировать, нажимаем правой кнопкой на пустом месте окна папки и нажимаем “Вставить”. Копия сделана, запускаем утилиту:

Появляется главное окно утилиты. Нам нужно указать имя файла базы данных. Нажимаем на три точки. Открывается окно выбора файла БД. Ищем каталог вашей базы и в нем указываем на файл 1Cv8.1CD. Нажимаем “Открыть”.

Ставим галочку “Исправлять обнаруженные ошибки” и нажимаем “Выполнить”.

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

После выполнения, если были исправлены ошибки они отобразятся в окне утилиты. В моем случае ошибок не обнаружено. Нажимаем “Закрыть” и пробуем зайти в программу. Если зайти все же не получается, вам необходимо обратиться к специалисту.

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

Материал из 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».
Читать еще:  Post error occurs как исправить

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

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