DBRECOVER for MSSQL SQL Server是微软SQL SERVER数据库恢复软件。
支持如下场景:
- 直接读取恢复置疑suspect的数据库MDF中的数据
- 对Truncate Table,Delete SQL误操作后的数据库表进行恢复
- 对无法附加的数据库进行恢复
- 支持恢复数据库中的lob大对象
- 支持恢复数据库中的视图、存储过程
软件下载地址: https://zcdn.parnassusdata.com/dbrecover-for-sqlserver-2007.zip
DBRECOVER for MSSQL SQL Server是微软SQL SERVER数据库恢复软件。
支持如下场景:
SQL Server使用Windows平台的标准API例如 ReadFile, WriteFile, ReadFileScatter, WriteFileGather 来实施IO操作。 在实施IO的过程中,SQL SERVER服务器检测这些API的报错信息。若这些API因操作系统原因报错,则SQL SERVER会报错Error 823 Msg。
典型的报错信息如下:
Error: 823, Severity: 24, State: 2.
2010-03-06 22:41:19.55 spid58 The operating system returned error 1117 (The request could not be performed because of an I/O device error.) to SQL Server during a read at offset 0x0000002d460000 in file ‘e:\program files\Microsoft SQL Server\mssql\data\mydb.MDF’. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe, system-level error condition that threatens database integrity and must be corrected immediately. It is recommended to complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
若用户运行DBCC CHECKDB 检测数据库,则可能看到相关的数据文件有报错,但也有可能看不到。若执行该命令无任何报错,则可能遇到了一个系统临时发生的问题或磁盘问题。
原因:
823 报错通常说明存储子系统例如文件系统、驱动器或存储存在问题。当文件系统损坏导致数据文件损害时可能出现该问题。在读取数据时,SQL SERVER会在遇到823错误后再次发起读取请求,若再次读取成功,则查询不会失败;但是825告警会被写入到错误日志和事件日志中。
措施
可以检查MSDB里的suspect_pages表来发现存在问题的数据页面: SQLCMD.EXE -S localhost\sqlexpress 1> use msdb; 2> select * from suspect_pages; 3> go Changed database context to 'msdb'. database_id file_id page_id event_type error_count last_update_date ----------- ----------- -------------------- ----------- ----------- ----------------------- (0 rows affected) 使用DBCC CHECKDB 命令来检测位于同一个存储单元上的所有数据库 1> dbcc checkdb([china]) 2> go DBCC results for 'china'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0. DBCC results for 'sys.sysrscols'. There are 1229 rows in 15 pages for object "sys.sysrscols". DBCC results for 'sys.sysrowsets'. There are 164 rows in 3 pages for object "sys.sysrowsets". DBCC results for 'sys.sysclones'. There are 0 rows in 0 pages for object "sys.sysclones". DBCC results for 'sys.sysallocunits'. There are 195 rows in 3 pages for object "sys.sysallocunits". DBCC results for 'sys.sysfiles1'. There are 2 rows in 1 pages for object "sys.sysfiles1". DBCC results for 'sys.sysseobjvalues'. There are 0 rows in 0 pages for object "sys.sysseobjvalues". DBCC results for 'sys.syspriorities'. There are 0 rows in 0 pages for object "sys.syspriorities". DBCC results for 'sys.sysdbfrag'. There are 0 rows in 0 pages for object "sys.sysdbfrag". DBCC results for 'sys.sysfgfrag'. There are 0 rows in 0 pages for object "sys.sysfgfrag". DBCC results for 'sys.sysdbfiles'. There are 2 rows in 1 pages for object "sys.sysdbfiles". DBCC results for 'sys.syspru'. There are 0 rows in 0 pages for object "sys.syspru". DBCC results for 'sys.sysbrickfiles'. There are 0 rows in 0 pages for object "sys.sysbrickfiles". DBCC results for 'sys.sysphfg'. There are 1 rows in 1 pages for object "sys.sysphfg". DBCC results for 'sys.sysprufiles'. There are 2 rows in 1 pages for object "sys.sysprufiles". DBCC results for 'sys.sysftinds'. There are 0 rows in 0 pages for object "sys.sysftinds". DBCC results for 'sys.sysowners'. There are 14 rows in 1 pages for object "sys.sysowners". DBCC results for 'sys.sysdbreg'. There are 0 rows in 0 pages for object "sys.sysdbreg". DBCC results for 'sys.sysprivs'. There are 177 rows in 1 pages for object "sys.sysprivs". DBCC results for 'sys.sysschobjs'. There are 2428 rows in 33 pages for object "sys.sysschobjs". DBCC results for 'sys.syscsrowgroups'. There are 0 rows in 0 pages for object "sys.syscsrowgroups". DBCC results for 'sys.sysextsources'. There are 0 rows in 0 pages for object "sys.sysextsources". DBCC results for 'sys.sysexttables'. There are 0 rows in 0 pages for object "sys.sysexttables". DBCC results for 'sys.sysextfileformats'. There are 0 rows in 0 pages for object "sys.sysextfileformats". DBCC results for 'sys.sysmultiobjvalues'. There are 0 rows in 0 pages for object "sys.sysmultiobjvalues". DBCC results for 'sys.syscolpars'. There are 1015 rows in 18 pages for object "sys.syscolpars". DBCC results for 'sys.sysxlgns'. There are 0 rows in 0 pages for object "sys.sysxlgns". DBCC results for 'sys.sysxsrvs'. There are 0 rows in 0 pages for object "sys.sysxsrvs". DBCC results for 'sys.sysnsobjs'. There are 1 rows in 1 pages for object "sys.sysnsobjs". DBCC results for 'sys.sysusermsgs'. There are 0 rows in 0 pages for object "sys.sysusermsgs". DBCC results for 'sys.syscerts'. There are 0 rows in 0 pages for object "sys.syscerts". DBCC results for 'sys.sysrmtlgns'. There are 0 rows in 0 pages for object "sys.sysrmtlgns". DBCC results for 'sys.syslnklgns'. There are 0 rows in 0 pages for object "sys.syslnklgns". DBCC results for 'sys.sysxprops'. There are 0 rows in 0 pages for object "sys.sysxprops". DBCC results for 'sys.sysscalartypes'. There are 34 rows in 1 pages for object "sys.sysscalartypes". DBCC results for 'sys.systypedsubobjs'. There are 0 rows in 0 pages for object "sys.systypedsubobjs". DBCC results for 'sys.sysidxstats'. There are 224 rows in 5 pages for object "sys.sysidxstats". DBCC results for 'sys.sysiscols'. There are 425 rows in 3 pages for object "sys.sysiscols". DBCC results for 'sys.sysendpts'. There are 0 rows in 0 pages for object "sys.sysendpts". DBCC results for 'sys.syswebmethods'. There are 0 rows in 0 pages for object "sys.syswebmethods". DBCC results for 'sys.sysbinobjs'. There are 23 rows in 1 pages for object "sys.sysbinobjs". DBCC results for 'sys.sysaudacts'. There are 0 rows in 0 pages for object "sys.sysaudacts". DBCC results for 'sys.sysobjvalues'. There are 225 rows in 20 pages for object "sys.sysobjvalues". DBCC results for 'sys.syscscolsegments'. There are 0 rows in 0 pages for object "sys.syscscolsegments". DBCC results for 'sys.syscsdictionaries'. There are 0 rows in 0 pages for object "sys.syscsdictionaries". DBCC results for 'sys.sysclsobjs'. There are 16 rows in 1 pages for object "sys.sysclsobjs". DBCC results for 'sys.sysrowsetrefs'. There are 0 rows in 0 pages for object "sys.sysrowsetrefs". DBCC results for 'sys.sysremsvcbinds'. There are 0 rows in 0 pages for object "sys.sysremsvcbinds". DBCC results for 'sys.sysxmitqueue'. There are 0 rows in 0 pages for object "sys.sysxmitqueue". DBCC results for 'sys.sysrts'. There are 1 rows in 1 pages for object "sys.sysrts". DBCC results for 'sys.sysconvgroup'. There are 0 rows in 0 pages for object "sys.sysconvgroup". DBCC results for 'sys.sysdesend'. There are 0 rows in 0 pages for object "sys.sysdesend". DBCC results for 'sys.sysdercv'. There are 0 rows in 0 pages for object "sys.sysdercv". DBCC results for 'sys.syssingleobjrefs'. There are 179 rows in 1 pages for object "sys.syssingleobjrefs". DBCC results for 'sys.sysmultiobjrefs'. There are 113 rows in 1 pages for object "sys.sysmultiobjrefs". DBCC results for 'sys.sysguidrefs'. There are 0 rows in 0 pages for object "sys.sysguidrefs". DBCC results for 'sys.sysfoqueues'. There are 0 rows in 0 pages for object "sys.sysfoqueues". DBCC results for 'sys.syschildinsts'. There are 0 rows in 0 pages for object "sys.syschildinsts". DBCC results for 'sys.syscompfragments'. There are 0 rows in 0 pages for object "sys.syscompfragments". DBCC results for 'sys.sysftsemanticsdb'. There are 0 rows in 0 pages for object "sys.sysftsemanticsdb". DBCC results for 'sys.sysftstops'. There are 0 rows in 0 pages for object "sys.sysftstops". DBCC results for 'sys.sysftproperties'. There are 0 rows in 0 pages for object "sys.sysftproperties". DBCC results for 'sys.sysxmitbody'. There are 0 rows in 0 pages for object "sys.sysxmitbody". DBCC results for 'sys.sysfos'. There are 0 rows in 0 pages for object "sys.sysfos". DBCC results for 'sys.sysqnames'. There are 98 rows in 1 pages for object "sys.sysqnames". DBCC results for 'sys.sysxmlcomponent'. There are 100 rows in 1 pages for object "sys.sysxmlcomponent". DBCC results for 'sys.sysxmlfacet'. There are 112 rows in 1 pages for object "sys.sysxmlfacet". DBCC results for 'sys.sysxmlplacement'. There are 19 rows in 1 pages for object "sys.sysxmlplacement". DBCC results for 'sys.sysobjkeycrypts'. There are 0 rows in 0 pages for object "sys.sysobjkeycrypts". DBCC results for 'sys.sysasymkeys'. There are 0 rows in 0 pages for object "sys.sysasymkeys". DBCC results for 'sys.syssqlguides'. There are 0 rows in 0 pages for object "sys.syssqlguides". DBCC results for 'sys.sysbinsubobjs'. There are 3 rows in 1 pages for object "sys.sysbinsubobjs". DBCC results for 'sys.syssoftobjrefs'. There are 2 rows in 1 pages for object "sys.syssoftobjrefs". DBCC results for 'sys.sqlagent_jobs'. There are 0 rows in 0 pages for object "sys.sqlagent_jobs". DBCC results for 'sys.sqlagent_jobsteps'. There are 0 rows in 0 pages for object "sys.sqlagent_jobsteps". DBCC results for 'sys.sqlagent_job_history'. There are 0 rows in 0 pages for object "sys.sqlagent_job_history". DBCC results for 'sys.sqlagent_jobsteps_logs'. There are 0 rows in 0 pages for object "sys.sqlagent_jobsteps_logs". DBCC results for 'sys.plan_persist_query_text'. There are 0 rows in 0 pages for object "sys.plan_persist_query_text". DBCC results for 'sys.plan_persist_query'. There are 0 rows in 0 pages for object "sys.plan_persist_query". DBCC results for 'sys.plan_persist_plan'. There are 0 rows in 0 pages for object "sys.plan_persist_plan". DBCC results for 'sys.plan_persist_runtime_stats'. There are 0 rows in 0 pages for object "sys.plan_persist_runtime_stats". DBCC results for 'sys.plan_persist_runtime_stats_interval'. There are 0 rows in 0 pages for object "sys.plan_persist_runtime_stats_interval". DBCC results for 'sys.plan_persist_context_settings'. There are 0 rows in 0 pages for object "sys.plan_persist_context_settings". DBCC results for 'sys.plan_persist_query_hints'. There are 0 rows in 0 pages for object "sys.plan_persist_query_hints". DBCC results for 'sys.plan_persist_query_template_parameterization'. There are 0 rows in 0 pages for object "sys.plan_persist_query_template_parameterization". DBCC results for 'sys.plan_persist_wait_stats'. There are 0 rows in 0 pages for object "sys.plan_persist_wait_stats". DBCC results for 'sys.persistent_version_store'. There are 0 rows in 0 pages for object "sys.persistent_version_store". DBCC results for 'sys.persistent_version_store_long_term'. There are 0 rows in 0 pages for object "sys.persistent_version_store_long_term". DBCC results for 'sys.wpr_bucket_table'. There are 0 rows in 0 pages for object "sys.wpr_bucket_table". DBCC results for 'largetable'. There are 6291456 rows in 45924 pages for object "largetable". DBCC results for 'largetabl2'. There are 6291456 rows in 31937 pages for object "largetabl2". DBCC results for '??'. There are 0 rows in 0 pages for object "??". DBCC results for 'sys.queue_messages_1977058079'. There are 0 rows in 0 pages for object "sys.queue_messages_1977058079". DBCC results for 'sys.queue_messages_2009058193'. There are 0 rows in 0 pages for object "sys.queue_messages_2009058193". DBCC results for 'sys.queue_messages_2041058307'. There are 0 rows in 0 pages for object "sys.queue_messages_2041058307". DBCC results for 'sys.filestream_tombstone_2073058421'. There are 0 rows in 0 pages for object "sys.filestream_tombstone_2073058421". DBCC results for 'sys.syscommittab'. There are 0 rows in 0 pages for object "sys.syscommittab". DBCC results for 'sys.filetable_updates_2105058535'. There are 0 rows in 0 pages for object "sys.filetable_updates_2105058535". CHECKDB found 0 allocation errors and 0 consistency errors in database 'china'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. 检查Window的事件日志 看有无存储或IO子系统的报错,例如当你看到823报错时可能时间日志中也有 The driver detected a controller error on \Device\Harddisk4\DR4 这样的信息。基于这些信息确定出现问题的磁盘。
如何诊断SQL SERVER中的MSG 824错误
若用户在SQL SERVER的错误日志或Windows事件日志中发现以下信息,一般说明了当读取或写入一个数据页面时可能出现了逻辑检测错误:
2009-11-02 15:46:42.90 spid51 Error: 824, Severity: 24, State: 2. 2009-11-02 15:46:42.90 spid51 SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:43686; actual 0:0). It occurred during a read of page (1:43686) in database ID 23 at offset 0x0000001554c000 in file 'H:\MSSQL.SQL2008\MSSQL\DATA\my_db.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.
若一个应用程序在读取或修改数据时持续遇到上述错误,则会导致应用端报错且数据库连接会话会被中断。
Sql server使用Windows的API例如ReadFile,WriteFile,ReadFileScatter,WriteFileGather 来实施IO操作,在做些IO操作时,SQL Server检测这些API系统调用的相关错误条件。若这些API因为操作系统错误而失败,那么SQL SERVER的报错是Error 823。但有些场景中虽然Windows系统API实际上成功调用,但基于I/O操作的数据传送可能遇到逻辑检测问题。这些逻辑检测错误会以Error 824告警。
824错误包含下面的信息:
这些逻辑一致性检测是由SQL SERVER发起的额外的完整性检测,以保证数据传输过程中特点的数据键值在I/O操作中得到必要的维护和验证。这些检测包括checksum校验,页面分裂,部分传输更新,错误的PageID,读取到陈旧数据,页面设计失败等。具体做的检测内容取决于数据库和服务级别的设置。
824错误信息一般说明对应IO路径下的底层存储系统或者硬件或驱动器存在问题。例如文件系统损坏导致的数据文件损害。
建议用户检测文件系统、驱动器或存储;若发现都没有问题, 则考虑基于备份恢复数据。 同时可以设置PAGE_VERIFY 来验证数据库
ALTER DATABASE [PageVerifyTest] SET PAGE_VERIFY CHECKSUM GO
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 错误945 : Database cannot be opened due to inaccessible files or insufficient memory or disk space , 是常见的SQL数据库故障之一。可以尝试调式环境或使用SQL恢复工具DBRECOVER FOR SQL SERVER来恢复数据。
SQL Server错误945发生在当数据库处于isshutdown状态或尝试附加/卸载数据库MDF文件时必要的系统工作未完成从而导致恢复操作无法将数据库置于在线状态。其可能发生在以下的情况下:
以下是一些针对SQL Server 945错误的解决方法
根据用户经验,以下是一些行之有效的解决MSG 945错误的方案:
观察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错误。检查这些文件是否为只读:
在对象资源管理器点击数据库,右键=》属性,点击权限,查看权限是否为完全控制。
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数据库的损坏处理相比于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数据库时,不管它有多少其他问题,那些都可以看做小问题,检查你接受库的备份情况才能减少未来可能发生的损失。
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 |
以下列出近几年file header损坏的一些主要原因:
注意dbcc checkdb命令是对文件头损坏无效的。
最简单有效的方法,就是基于备份文件恢复,主要谈没备份的情况下:
因为是文件头受损,我们上面讲了0号page是文件头,但是我们可以基于重新建一个数据库来获得好的文件头,然后这个file header替换到坏的数据库上,来达到恢复目的,这个一般用windows平台上的dd或者bbcopy就能实现。
如果前几MB的文件头都被损坏了,那么这个时候方案1很难生效。我们可以利用一些恢复软件恢复,例如DBRECOVER FOR SQL SERVER。
目前现有的勒索病毒绝大部分针对Windows平台,且主要集中在Windows XP,7,server 2003 ,2008 等操作系统平台。绝大部分通过加密各种文件以达到勒索的目的;一般来说这种加密都是部分加密,这是因为加密大文件耗时长、CPU消耗大;例如给一个1GB大小的文件做全加密,需要消耗较多的CPU、内存和时间。所以即便SQL SERVER的MDF文件被加密了,只要文件本身比较大,一般用户数据不会被破坏。
因为目前主流版本的SQL SERVER仍存在于Windows平台上,所以主要是避免使用Window XP、7、Server 2003、Server 2008这些版本的操作系统。
Windows Server 2012 R2 entered mainstream support on November 25, 2013, though, but its end of mainstream is January 9, 2018, and end of extended is January 10, 2023.
Windows Server 2012 R2的扩展支持时间最晚到2023年1月,所以在选择操作系统时尽可能选择Windows Server 2016 以后的版本。
如果没法升级操作系统,那么至少:
其他的一些预防措施:
若你的SQL SERVER数据库出现Msg 5172, Level 16, State 15, Line 1报错信息,则一般说明要么是MDF数据文件头因此磁盘故障发生了损坏,要么是受到计算机病毒或勒索软件攻击导致MDF内容中部分数据被加密。
例如下面的报错信息:
1> alter database testn1 set emergency;
2> go
Msg 5172, Level 16, State 15, Server DESKTOP-L414PA5\SQLEXPRESS, Line 1
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.
可以使用如下的命令来检查MDF文件,当然你也可以利用16进制查看工具例如WINHEX来查看文件头。
Syntax:DBCC CHECKPRIMARYFILE ({'PhysicalFileName'} [,opt={0|1|2|3}]) PhysicalFileName is the full path for the primary database file. opt=0 - checks if the file a primary database file. opt=1 - returns name, size, maxsize, status and path of all files associated to the database. opt=2 - returns the database name, version and collation. opt=3 - returns name, status and path of all files associated with the database. CHECKPRIMARYFILE 可以被用来检查文件是否是一个主要数据库文件,并返回相关的信息,其中opt=0 用来判断这是不是一个MDF数据文件 2> DBCC CHECKPRIMARYFILE(N'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\bak3\xmltest.mdf',0); 3> go IsMDF ----------- 1 (1 rows affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. 1> 2> 3> DBCC CHECKPRIMARYFILE(N'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\bak3\testn1.mdf',0); 4> go IsMDF ----------- 0 (1 rows affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator.
返回1说明是MDF数据文件,而返回0说明不是MDF数据文件。
对于真的被勒索病毒破坏加密的数据文件头,主要有3种对应措施:
1、若破坏的文件头内容不多的话,可以通过重建文件头修复
2、如果破坏的勒索病毒使用了已知的加密密钥,则可以通过找到对应密钥来解密,可以访问id-ransomware和nomoreransom来获得一些信息。
3、如果以上2个方案都不行,可以考虑使用DBRECOVER FOR SQL SERVER工具来恢复数据。
Copyright © 2024 · Genesis Framework · WordPress · Log in