Каталог решений - Выводим из suspect базу 1С 7.7 на sql server 2000, а также "Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach"

Что делать, если информационная база 1С7.7  на SQL Server 2000 перешла в состояние suspect (подозрительная)? Данную информацию нашел с большим трудом, поэтому опубликовал её сам. Статья //sale.itcity.ru/public/59520/ на версию SQL 2000 не рассчитана, она не подходит.

Прежде всего надо принять решение, есть ли в Вашей базе повреждения.

Есть целый ряд проблем, которые могут привети к suspect:

Неправильные разрешения NTFS: Учетная запись службы, службы входа в систему должны иметь разрешение на доступ к базе данных на диске.

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

Удаленные файлы: Если кто-то случайно или намеренно, удаляет один из файлов, связанных с базой данных, то база данных будет помечена suspect.

Переименованные файлы: Если файл был переименован, SQL Server не сможет читать его, и база данных будет помечена подозреваемого.

После того, как причина проблемы с файлами базы устранена, вы можете перезапустить службу SQL Server, и если возможно произойдет автоматическое восстановление. Однако если база данных по-прежнему помечается suspect после ремонта файлов, нужно использовать хранимую процедуру sp_resetstatus.

exec sp_resetstatus ‘sigmabuh’ — эта процедура пытается изменить базу данных обратно в пригодное состояние.

Не помогло? Пробуем сделать detach и attach

Если повреждений нет, то поможет статья https://support.microsoft.com/ru-ru/kb/224071. На случай, если вдруг эту статью сочтут устаревшей, я скопировал её фрагмент сюда:

=======================================

Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach

Аннотация

В статье описывается, как изменить местоположение файлов данных и журналов для баз данных серверов Microsoft SQL Server 2005, SQL Server 2000 или SQL Server 7.0.Дополнительные сведения о перемещении системных баз данных в SQL Server 2005 см. в разделе «Перемещение системных баз данных» электронной документации на SQL Server. Для просмотра раздела посетите веб-узел MSDN по следующему адресу: http://msdn2.microsoft.com/ru-ru/library/ms345408.aspx

Дополнительная информация

Действия, необходимые для изменения местоположения некоторых системных баз данных SQL Server, отличаются от действий для изменения местоположения пользовательских баз данных. Указания по перемещению подобных баз данных приводятся отдельно.Примечание. Системные базы данных SQL Server 7.0 несовместимы с SQL Server 2000. Не подключайте базы данных, поставляющиеся вместе с SQL Server, а также базы данных master, model и msdb SQL Server 7.0 к SQL Server 2000. При использовании SQL Server 2005 можно подключать к экземплярам программы только базы данных SQL Server 2005. Во всех примерах, приведенных в данной статье, предполагается, что программа SQL Server установлена в папку D:\Mssql7. Кроме того, в примерах принято, что все файлы данных и журналов расположены в папке по умолчанию D:\Mssql7\Data. В примерах все файлы журналов и данных перемещаются в папку E:\Sqldata для всех баз данных.

Необходимые условия

Создайте резервные копии всех баз данных, особенно — базы данных master из их текущего местоположения.

Необходимо иметь полномочия администратора системы (по умолчанию ими обладает учетная запись «sa»).

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

Примечание. Чтобы определить имена и местоположение всех файлов, используемых базой данных, воспользуйтесь хранимой процедурой sp_helpfile:

use <database_name>

go

sp_helpfile

go

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

Перемещение пользовательских баз данных

В следующем примере выполняется перемещение базы данных mydb. Эта база данных содержит один файл данных Mydb.mdf и один файл журнала, Mydblog.ldf. Если подлежащая перемещению база данных состоит из нескольких файлов данных и журналов, необходимо перечислить все эти файлы в списке, передаваемом хранимой процедуре sp_attach_db Элементы списка разделяются запятыми. Поскольку процедуре sp_detach_db список перемещаемых файлов не передается, то вызов данной процедуры sp_detach_db не зависит от количества файлов в базе данных.

Отключите базу данных, как показано ниже:

use master

go

sp_detach_db ‘mydb’

go

Скопируйте файлы журналов и данных из текущего местоположения (D:\Mssql7\Data) в новое (E:\Sqldata).

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

use master

go

sp_attach_db ‘mydb’,’E:\Sqldata\mydbdata.mdf’,’E:\Sqldata\mydblog.ldf’

go

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

use mydb

go

sp_helpfile

go

В стобце filename должно отображаться новое местоположение файлов.

Примечание. В статье 922804 базы знаний Майкрософт описана проблема с базами данных SQL Server 2005, расположенными на хранилище, подключенном к сети. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

922804 Исправление. После отключения базы данных Microsoft SQL Server 2005, хранящейся на устройстве хранения данных, подключенном к сети, ее не удается подключить (Эта ссылка может указывать на содержимое полностью или частично на английском языке)

Примите во внимание эту проблему. Кроме того, примите во внимание разрешения, применяемые к базе данных при отключении от SQL Server 2005. Для получения дополнительных сведений см. раздел «Detaching and Attaching a Database» статьи «Securing Data and Log Files» интерактивного руководства SQL Server Books Online. Для просмотра этой статьи посетите следующий веб-узел MSDN:

http://msdn2.microsoft.com/ru-ru/library/ms189128.aspx

=======================================

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

Use master

go

sp_configure 'allow updates', 1

— указать серверу, следует ли разрешить обновления системных таблиц непосредственно

go

---Execute---

reconfigure with override

— метод применяет изменения конфигурации SQL Server

---Execute---

select status from sysdatabases where name = 'DataBaseName'

— узнаем статус базы данных, в интернет можно найти значения флагов статусов

https://www.mssqltips.com/sqlservertip/1477/methods-to-determine-the-status-of-a-sql-server-database/

Status bits, some of which can be set by the user with sp_dboption (read only, dbo use only, single user, and so on):
1 = autoclose; set with sp_dboption.
4 = select into/bulkcopy; set with sp_dboption.
8 = trunc. log on chkpt; set with sp_dboption.
16 = torn page detection, set with sp_dboption.
32 = loading.
64 = pre recovery.
128 = recovering.
256 = not recovered.
512 = offline; set with sp_dboption.
1024 = read only; set with sp_dboption.
2048 = dbo use only; set with sp_dboption.
4096 = single user; set with sp_dboption.
32768 = emergency mode.
4194304 = autoshrink.
1073741824 = cleanly shutdown.

---Execute---

EXEC sp_resetstatus 'DataBaseName';

— эта процедура пытается изменить базу данных обратно в пригодное состояние.

---Execute---

update sysdatabases set status= 32768 where name = 'sigmabuh'
-- устанавливается статус EMERGENCY то есть  в процессе ремонта

---Execute---