sql база suspect что делать
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) в зависимости от нашей версии сервера.
Выводим из suspect базу 1С 7.7 на sql server 2000, а также «Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach»
Что делать, если информационная база 1С7.7 на SQL Server 2000 перешла в состояние suspect (подозрительная)? Данную информацию нашел с большим трудом, поэтому опубликовал её сам. Статья //infostart.ru/public/59520/ на версию SQL 2000 не рассчитана, она не подходит.
Прежде всего надо принять решение, есть ли в Вашей базе повреждения.
Есть целый ряд проблем, которые могут привети к suspect:
Неправильные разрешения NTFS: Учетная запись службы, службы входа в систему должны иметь разрешение на доступ к базе данных на диске.
Поврежденные файлы на диске: жесткие диски имеют движущиеся части, и они хранят информация магнитным способом, что означает, что они со временем могут выйти из строя, это приведет к повреждению данных. Если поврежденный сектор содержит часть файл базы данных, он может быть помечен suspect. Поэтому, как правило, необходио использовать резервное копирование базы данных.
Удаленные файлы: Если кто-то случайно или намеренно, удаляет один из файлов, связанных с базой данных, то база данных будет помечена suspect.
Переименованные файлы: Если файл был переименован, SQL Server не сможет читать его, и база данных будет помечена подозреваемого.
После того, как причина проблемы с файлами базы устранена, вы можете перезапустить службу SQL Server, и если возможно произойдет автоматическое восстановление. Однако если база данных по-прежнему помечается suspect после ремонта файлов, нужно использовать хранимую процедуру sp_resetstatus.
Не помогло? Пробуем сделать 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:
При этом необходимо иметь исключительный доступ к перемещаемой базе данных. Если при перемещении возникли ошибки и если после перемещения не удается запустить SQL Server или получить доступ к перемещенной базе данных, для получения сведений об ошибках ознакомьтесь с журналом ошибок SQL Server и интерактивным руководством SQL Server Books Online.
Перемещение пользовательских баз данных
В следующем примере выполняется перемещение базы данных mydb. Эта база данных содержит один файл данных Mydb.mdf и один файл журнала, Mydblog.ldf. Если подлежащая перемещению база данных состоит из нескольких файлов данных и журналов, необходимо перечислить все эти файлы в списке, передаваемом хранимой процедуре sp_attach_db Элементы списка разделяются запятыми. Поскольку процедуре sp_detach_db список перемещаемых файлов не передается, то вызов данной процедуры sp_detach_db не зависит от количества файлов в базе данных.
Отключите базу данных, как показано ниже:
Скопируйте файлы журналов и данных из текущего местоположения (D:\Mssql7\Data) в новое (E:\Sqldata).
Повторно подключите базу данных. Укажите новое местоположение файлов:
Проверьте изменение местоположения файлов с помощью хранимой процедуры sp_helpfile:
В стобце 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:
Далее, если не помогло, проводим ребилд базы данных
— указать серверу, следует ли разрешить обновления системных таблиц непосредственно
— метод применяет изменения конфигурации SQL Server
— узнаем статус базы данных, в интернет можно найти значения флагов статусов
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.
— эта процедура пытается изменить базу данных обратно в пригодное состояние.
Evgeniy Korshunov
четверг, 31 октября 2013 г.
MS SQL. Состояние базы данных SUSPECT
База данных может войти в состояние SUSPECT по многим причинам: неисправность оборудования, «битый» LOG или MDF файл, заполнено дисковое пространство, ограничения по линии файловой системы FAT32 и т.д.
Если обратиться в BOL, то там можно узнать, что состояние SUSPECT означает повреждение файла (находится в подозрительном состоянии) и он может быть восстановлен или удален. Также отмечается, что базу данных можно восстановить из резервной копии.
Со словом «удален» все понятно. Попробуем восстановить базу данных. Для простоты будем рассматривать случай, когда повреждена пользовательская база данных.
1. Останавливаем MS SQL SERVER;
2. Копируем файлы mdf и ldf аварийной базы данных в безопасное место;
3. Стартуем сервер и удаляем аварийную базу данных. В этом пункте в некоторых случаях, когда невозможно удалить базу данных, придется подкорректировать системную таблицу sysdatabases;
4. Создаем новую базу данных с таким же именем и местоположением как и аварийная база данных;
5. Останавливаем сервер и подменяем mdf файл;
6. Стартуем сервер. В данный момент состояние аварийной базы данных для нас не актуально.
7. Из QA выполняем скрипт, который позволит нам редактировать системные таблицы
Use master
go
sp_configure ‘allow updates’, 1
reconfigure with override
go
Use master
go
sp_dboption », ‘single user’, ‘true’
go
USE
GO
DBCC CHECKDB(», REPAIR_ALLOW_DATA_LOSS)
go
sp_dboption », ‘single user’, ‘false’
go
Use master
go
sp_configure ‘allow updates’, 0
go
How to Recover MS SQL Database from Suspect Mode?
Updated on August 16, 2021
Summary: Read this post to find solutions to recover MS SQL database marked as suspect. It describes step-wise instructions to fix the ‘SQL server suspect database’ issue by running Transact-SQL (T-SQL) commands in SQL Server Management Studio (SSMS). Also, it provides an alternative solution to restore the database using a SQL Recovery tool.
When SQL database goes into suspect mode, it becomes inaccessible. In such a situation, you will neither be able to connect to the database nor recover it during server startup.
Figure 1: Database in Suspect Mode
Check out the Infographic below for quick solutions to recover database from suspect mode in SQL Server 2008, and higher versions.
When does SQL database goes to suspect mode?
When SQL server suspects the primary filegroup of the database to be damaged or if the database file is missing, the database status is set to ‘Suspect’.
Also, there are a wide range of errors that could result in SQL database in suspect mode. Some of them are listed as below:
How to get SQL database out of suspect mode?
NOTE: You can try restoring the database in suspect mode from a good known backup. If the backup is not available, proceed with the following steps.
Follow the steps in sequence given below to recover MS SQL database from suspect mode:
Step 1: Open SSMS and connect to the database.
Figure 2: Connect to Database
Step 2: Select the New Query option.
Figure 3: Select New Query
Step 3: In the Query editor window, enter the following code to turn off the suspect flag on the database and set it to EMERGENCY:
Figure 4: Set Database in Emergency Mode
NOTE: If you cannot set the database in emergency mode, skip to the next solution.
Step 4: A suspect database might not be corrupted. You can determine if the database is corrupted or not by running the following DBCC CHECKDB command.
This statement will report any consistency errors (if found) in the database and will recommend running the minimum level of repair option to fix corruption.
Before initiating the repair process, you must first set the database into ‘Single User Mode.’ Doing so will prevent other users from making any changes to the database during the repair process.
Figure 5: Check Database Consistency
Step 5: Now, let’s bring the database into the Single User mode and roll back the previous transactions by executing the below command:
Figure 6: Set Database to Single_User Mode
Step 6: Take a complete backup of the corrupted files to avoid chances of data loss.
Step 7: After putting the db in SINGLE USER mode, try to fix the consistency errors using the REPAIR_REBUILD option of DBCC CHECKDB. This option can quickly repair missing rows in nonclustered indexes. In addition, you can use it for more time-consuming repair operation, such as rebuilding an index.
DBCC CHECKDB (‘database_name’, REPAIR_REBUILD)
However, if REPAIR_ALLOW_DATA_LOSS is suggested as minimum level of repair, then run DBCC CHECKDB with the suggested repair option. The syntax is as follows:
Figure 7: Repair Database with DBCC CHECKDB
Step 8: Bring the database into the Multi-User mode:
Figure 8: Set Database to Multi-User Mode
Step 9: Refresh the database server.
After completing these steps, you should be able to connect to the database. In case of any data loss, you’ll have the db backup to restore from (Step 6).
What if this solution doesn’t work?
If your server database file has turned severely corrupt, the above-mentioned steps may fail to revive the database. At this point, try restoring the database by using Stellar Repair for MS SQL.
The software can fix common SQL database corruption errors that occur due to reasons such as the database in suspect mode and several others. The software uses advanced algorithms to repair and restore SQL db from suspect mode to normal state (online).
How to Recover SQL Database from Suspect Mode with the Stellar SQL Recovery Tool?
NOTE: Make sure to close the server instance before running Stellar Repair for MS SQL software.
Step 1: Download, install, and run Stellar Repair for MS SQL software.
Step 2: From the Select Database window, choose Browse or Search to select the SQL database file (.mdf) of the suspect database.
Figure 9: Select Database File
Step 3: Once the file is selected, hit Repair.
Figure 10- Repair Selected File
NOTE: Make sure to uncheck the ‘Include Deleted Records’ checkbox if you don’t want the deleted records to be recovered.
Step 4: Preview the repaired MDF file for recoverable SQL server database objects.
Figure 11: Preview window
Step 5: Click Save on File menu to save the repaired file.
Figure 12: File menu
Step 6: From Save Database window, perform the following:
Step 7: Click Save.
Open SSMS and attach the db (containing the repaired MDF file). You will be able to access the database.
Additional features of the software
The software is trusted by Microsoft MVPs
Conclusion
This post discussed methods on ‘How to recover MS SQL database from suspect mode’. The best approach is to restore the database from a healthy backup. If you don’t have backup, use the EMERGENCY mode to access the database and repair it. However, you may fail to rollback the transactions that were active when database went into suspect mode. Also, using the REPAIR_ALLOW_DATA_LOSS option as the minimum repair level can lead to data loss. A better alternative is to use a specialized SQL database repair software that helps repair and restore the database from suspect to a normal state.
About The Author
Jyoti Prakash
Problem solver and Data recovery specialist. Usually share informative articles on data recovery, database corruption and ways to recover lost data.
Best Selling Products
Stellar Repair for MS SQL is an enterprise-grade database repair softw.
3-in-1 software package, recommended by Microsoft MVPs and SQL adminis.
Stellar Converter for Database is an efficient database interconversio.
Powerful tool, widely trusted by users & admins worldwide, to repair c.
Sql база suspect что делать
После загрузки сервера некоторые БД оказались помеченными как suspect. Что случилось и как можно вернуть эти БД?
| Состояние базы данных suspect: что это такое и как с этим бороться. |
