如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

 

SQL Server中数据库置疑的几个原因

1. 操作系统找不到对应的数据库文件MDF/NDF
2. 无法打开或访问日志文件LDF
3. 由于异常重启导致损坏了MDF/NDF/LDF文件

 

数据库处于置疑状态中可能出现的一些报错：

Error: 9003, Severity: 20, State: 9 – The log scan number (178956:14:2) passed to log scan in database is not valid.

Error: 3414, Severity: 21, State: 1 – An error occurred during recovery, preventing the database (database ID 21) from restarting.

 

对于数据库置疑的恢复

以系统管理员权限登录sqlcmd或ssms找到置疑状态的数据库

重置数据库状态:

execute sp_resetstatus ‘数据库名’;

go

 

以上sp_resetstatus将重置置疑数据库的状态

将置疑数据库设置为紧急状态，此状态下数据库为只读，只有系统管理权限用户能访问该数据库

alter database ‘数据库名’ set emergency;

go

 

执行DBCC CHECKDB 对全库做物理和逻辑检测

DBCC CHECKDB ‘数据库名’;

go

 

将数据库切换到单用户模式

alter database ‘数据库名’ set_single_user with rollback immediate;

go

 

repair_allow_data_loss选项将允许丢失数据，从而绕过任何无法恢复的地方

DBCC CHECKDB ‘数据库名’ repair_allow_data_loss

 

最后将数据库切换到多用户模式

alter database ‘数据库名’   set MULTI_USER

go

执行完上述步骤后，建议对全库所有数据做应用和人工验证。 对于这种紧急模式的数据恢复而言，其能恢复的损坏程度是有效的，例如少量的数据页和日志损坏。

 

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

SQL 错误945 ： Database cannot be opened due to inaccessible files or insufficient memory or disk space  ， 是常见的SQL数据库故障之一。可以尝试调式环境或使用SQL恢复工具DBRECOVER FOR SQL SERVER来恢复数据。

 

什么是SQL Server 945错误？

 

SQL Server错误945发生在当数据库处于isshutdown状态或尝试附加/卸载数据库MDF文件时必要的系统工作未完成从而导致恢复操作无法将数据库置于在线状态。其可能发生在以下的情况下：

• 因为memory-optimized内存优化表而导致大量磁盘空间被消耗
• 因为丢失一些文件或页导致SQL数据库修复操作失败
• 使用了本来就损坏的备份文件
• 不当的数据库关闭操作
• 数据库文件被病毒攻击

 

以下是一些针对SQL Server 945错误的解决方法

 

解决方案

根据用户经验，以下是一些行之有效的解决MSG 945错误的方案：

 

1. 扩充硬件空间

观察windows下的所有盘符，确保每个盘符下至少有5GB的剩余空间。也可以检查Windows事件日志看看有无磁盘空间相关报错。

 

2. 确保自动扩展打开了

检查数据库的自动扩展功能是否确实打开了，可以使用sp_helpdb来查看数据库是否自动扩展：

 

3> sp_helpdb test3
4> go
name db_size owner dbid created status compatibility_level
-------------------------------------------------------------------------------------------------------------------------------- ------------- -------------------------------------------------------------------------------------------------------------------------------- ------ ----------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ -------------------
test3 16.00 MB DESKTOP-L414PA5\pcone 17 Feb 14 2020 Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=SIMPLE, Version=869, Collation=SQL_Latin1_General_CP1_CI_AS, SQLSortOrder=52, IsAutoCreateStatistics, IsAutoUpdateStatistics, IsFullTextEnabled 140

name fileid filename filegroup size maxsize growth usage
-------------------------------------------------------------------------------------------------------------------------------- ------ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ------------------ ------------------ ------------------ ---------
test3 1 E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\test3.mdf PRIMARY 8192 KB Unlimited 65536 KB data only
test3_log 2 E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\test3_log.ldf NULL 8192 KB 2147483648 KB 65536 KB log only

 

3. 检查windows账号是否有足够的权限

确认用来操作SQL SERVER的windows账号有足够的权限

 

4.检查MDF NDF文件

若MDF或NDF文件被标记为只读属性，那么也会遇到945错误。检查这些文件是否为只读：

在对象资源管理器点击数据库，右键=》属性，点击权限，查看权限是否为完全控制。

 

 

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

8646
Unable to find index entry in index ID %d, of table %d, in database '%.*ls'. 
The indicated index is corrupt or there is a problem with the current update plan. 
Run DBCC CHECKDB or DBCC CHECKTABLE. If the problem persists, contact product support.

 

从SQL SERVER 2008开始当使用NOLOCK选项运行复杂的update语句时，可能导致非簇索引的损坏。如下面的错误日志：

 

Error: 8646, Severity: 21, State: 1.
Unable to find index entry in index ID XX, of table XX, in database ‘<DatabaseName>’. 
The indicated index is corrupt or there is a problem with the current update plan. 
Run DBCC CHECKDB or DBCC CHECKTABLE. If the problem persists, contact product support.
Using ‘dbghelp.dll’ version ‘4.0.5’
**Dump thread – spid = 0, EC = 0x0000000XX000000
***Stack Dump being sent to 
CPerIndexMetaQS::ErrorAbort – Index corruption

原因

其原因可能时因为使用了NOLOCK HINT导致查询读取表数据时读到的数据不正确从而导致索引损坏。

 

解决方案

可以通过打SQL SERVER补丁来避免再次发生此类问题。但是无法修复已经发生的问题。一般来说该类问题可以通过重建索引来解决：

 

直接重建rebuild index:

 

ALTER　INDEX  [INDEX_NAME] ON [TABLE_NAME]  rebuild

go

 

或者先把索引drop掉，然后再运行create index也是一种解决方案。

运行以上解决方案后建议 再次运行dbcc checkdb操作来检测全库。

 

SELECT message_id AS Error, severity AS Severity,  
[Event Logged] = CASE is_event_logged WHEN 0 THEN 'No' ELSE 'Yes' END,
text AS [Description]
FROM sys.messages
WHERE language_id = 
ORDER BY message_id

 

 

 

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

SQL Server数据库的损坏处理相比于oracle数据库而言是简单一些的，这个简单主要体现在微软或者说sybase提供了对损坏/置疑数据库的紧急EMERGENCY模式，以便用户能够从有问题而无备份的数据库中拯救出数据。而oracle则官方不提供这种方案。但对于连数据文件头都损失的场景在SQL Server的紧急模式也没法发挥作用，这是因为启动块等重要数据都在MDF文件头部。所以实际上即便不备份整个MDF文件，但备份其头部也是有意义的。这和我们在Oracle ASM中定期备份ASM disk header是类似的。但这种想法还是过于理想，没有备份就是没有备份计划或者备份计划不当的结果。

所以任何其他RDBMS(MYSQL Oracle)都会出现的问题，在SQL Server中也无从避免。数据文件头丢失也是类似的，与普通的数据块丢失不同。普通的数据块丢失可能只影响少数表或索引，用户也可以割舍这少部分数据。而数据文件头的丢失将导致数据库彻底不可用，这是有本质区别的。

4> alter database testn1 set emergency;
5> go
Msg 5172, Level 16, State 15, Server DESKTOP-L414PA5\SQLEXPRESS, Line 4
The header for file 'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\testn1.mdf' is not a valid database file header. The PageAudit property is incorrect.
Msg 5172, Level 16, State 15, Server DESKTOP-L414PA5\SQLEXPRESS, Line 4
The header for file 'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\testn1.mdf' is not a valid database file header. The PageAudit property is incorrect.

相对于oracle而言SQL Server的企业环境中，可能更加缺失DBA的角色。所以我们可以说当你接手一套SQL server数据库时，不管它有多少其他问题，那些都可以看做小问题，检查你接受库的备份情况才能减少未来可能发生的损失。

 

了解MDF文件头

 

SQL server中数据的最小存储单元是page，与之对应的是oracle中的block。page的ID从0开始数；0号page至关重要这是因为它存放了数据文件的重要信息。每一个mdf/ndf文件有一个自己的文件号FileID ，从1开始数。所以FileID+PageID可以定位一个page。下面是前8个page存放的信息：

 

Page No	Page Identify
Page 0	Header
Page 1	First PFS
Page 2	First GAM
Page 3	First SGAM
Page 4	Unused
Page 5	Unused
Page 6	First DCM
Page 7	First BCM

 

一些造成SQL SERVER MDF文件头损坏的原因

 

以下列出近几年file header损坏的一些主要原因：

1. 目前最主要的因素是勒索病毒损坏，因为勒索病毒一般都会优先损坏文件的前1~10MB，所以文件头必然被损坏
2. 磁盘故障占第二位，主要是多年运行的磁盘容易出该问题
3. 重启不当，其实这个原因是和磁盘故障结合的；已有的磁盘问题在数据库运行过程中不爆发，一旦重启就爆发。还是就是没有干净的关闭服务就重启，例如断电重启

 

 

对于SQL SERVER MDF文件头损坏的恢复手段

注意dbcc checkdb命令是对文件头损坏无效的。

最简单有效的方法，就是基于备份文件恢复，主要谈没备份的情况下：

因为是文件头受损，我们上面讲了0号page是文件头，但是我们可以基于重新建一个数据库来获得好的文件头，然后这个file header替换到坏的数据库上，来达到恢复目的，这个一般用windows平台上的dd或者bbcopy就能实现。

如果前几MB的文件头都被损坏了，那么这个时候方案1很难生效。我们可以利用一些恢复软件恢复，例如DBRECOVER FOR SQL SERVER。