SQL Server 置疑、可疑、正在恢复等情况分析_MsSql

一、出错情况
有些时候当你重启了数据库服务,会发现有些数据库变成了正在恢复、置疑、可疑等情况,这个时候DBA就会很紧张了,下面是一些在实践中得到证明的方法。
在一次重启数据库服务后,数据库显示正在恢复,过了很久还是这个状态,离线时间不能太长,所以就想起了一个方法,就是把数据库服务停止了,把数据文件mdf和ldf拷贝出来,删除了ldf文件,按照之前的经验,好像是在没有ldf的情况下可以使用mdf来恢复数据库。创建了一个同名的数据库,停止数据库服务,覆盖mdf文件,再启动数据库服务,这个时候还是处于可疑的状态。
其中使用mdf来附加数据库是附加不了的,一直报错。

二、解决步骤

方法一:使用脚本进行数据库恢复。

复制代码 代码如下:

--DataBaseName为修复的数据名
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
ALTER DATABASE [DataBaseName] SET EMERGENCY
GO
sp_dboption 'DataBaseName', 'single user', 'true'
GO
DBCC CHECKDB('DataBaseName','REPAIR_ALLOW_DATA_LOSS')
GO
ALTER DATABASE [DataBaseName] SET ONLINE
GO
sp_configure 'allow updates', 0 reconfigure with override
GO
sp_dboption 'DataBaseName', 'single user', 'false'
GO

SQL讲解:
1) 使用指定值强制重新配置:(1、0表示为真假)
sp_configure 'allow updates', 1 reconfigure with override
2) 设置为紧急状态:
alter database DataBaseName set emergency
3) 设置为单用户模式:
alter database [DataBaseName] set single_user
或者:Sp_dboption 'DataBaseName', 'single user', 'true'
4) 修复发现的错误:
DBCC CHECKDB('DataBaseName','REPAIR_ALLOW_DATA_LOSS')
5) 设置为联机、在线:
ALTER DATABASE [DataBaseName] SET ONLINE

方法二:这个方法还没尝试过,大家可以试试看。

复制代码 代码如下:

CREATE DATABASE DataBaseName
ON (FILENAME = 'D:\DataBase\Name.mdf')
FOR ATTACH_REBUILD_LOG ;
GO

时间: 2025-01-27 08:36:17

SQL Server 置疑、可疑、正在恢复等情况分析_MsSql的相关文章

SQL Server内存遭遇操作系统进程压榨案例分析_MsSql

场景: 最近一台DB服务器偶尔出现CPU报警,我的邮件报警阈(请读yù)值设置的是15%,开始时没当回事,以为是有什么统计类的查询,后来越来越频繁. 探索: 我决定来查一下,究竟是什么在作怪,我排查的顺序如下: 1.首先打开Cacti监控,发现最近CPU均值在某天之后骤然上升,并且可以看到System\Processor Queue Length 和 sqlservr\%ProcessorTime 也在显著的变化. 2.从最容易入手的低效SQL开始,考虑是不是最近业务做了什么修改?连接到该SQL

浅谈SQL Server中统计对于查询的影响分析_MsSql

而每次查询分析器寻找路径时,并不会每一次都去统计索引中包含的行数,值的范围等,而是根据一定条件创建和更新这些信息后保存到数据库中,这也就是所谓的统计信息. 如何查看统计信息 查看SQL Server的统计信息非常简单,使用如下指令: DBCC SHOW_STATISTICS('表名','索引名') 所得到的结果如图1所示.         图1.统计信息 统计信息如何影响查询     下面我们通过一个简单的例子来看统计信息是如何影响查询分析器.我建立一个测试表,有两个INT值的列,其中id为自增

SQL Server 数据页缓冲区的内存瓶颈分析_MsSql

SQL Server会把经常使用到的数据缓存在内存里(就是数据页缓存),用以提高数据访问速度.因为磁盘访问速度远远低于内存,所以减少磁盘访问量同样是数据库优化的重要方面. 当数据页缓存区出现内存不足,则会出现查询慢,磁盘忙等等问题. 分析方法:主要是用到性能计数器. 查看如下性能计数器: 1. SQL SERVER:Buffer Manager-Lazy Writes/sec:内存不足则会频繁调用Lazy Writer把数数据写入磁盘,此值会经常不为0. 2. SQL SERVER:Buffer

SQL Server 2005 创建简单的存储过程--总结分析_MsSql

最近由于工作需要,简单了解了下SQL Server 2005 数据库创建简单的在存储过程.一.首先说明如何创建存储过程: CREATE PROCEDUER my_pro @inputDate varchar ,//声明输入变量 @Result varchar(255) output //声明输出变量 AS declare @variable1 varchar(255)//声明varchar变量 declare @variable2 int //声明整形变量 BEGIN IF ...(条件) BE

SQL Server内存遭遇操作系统进程压榨案例分析

场景: 最近一台DB服务器偶尔出现CPU报警,我的邮件报警阈(请读yù)值设置的是15%,开始时没当回事,以为是有什么统计类的查询,后来越来越频繁. 探索: 我决定来查一下,究竟是什么在作怪,我排查的顺序如下: 1.首先打开Cacti监控,发现最近CPU均值在某天之后骤然上升,并且可以看到System\Processor Queue Length 和 sqlservr\%ProcessorTime 也在显著的变化. 2.从最容易入手的低效SQL开始,考虑是不是最近业务做了什么修改?连接到该SQL

SQL Server数据库崩溃如何恢复

server|恢复|数据|数据库 任何数据库系统都无法避免崩溃的状况,即使你使用了Clustered,双机热备--仍然无法完全根除系统中的单点故障,何况对于大部分用户来说,无法承受这样昂贵的硬件投资. 所以,在系统崩溃的时候,如何恢复原有的宝贵数据就成为一个极其重要的问题了. 在恢复的时候,最理想的情况就是你的数据文件和日志文件都完好无损了,这样只需要sp_attach_db,把数据文件附加到新的数据库上即可,或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行,不

SQL Server置疑数据库解决方法

1.首先确认已经备份了.mdf和.ldf文件. 2. 在SQL Server中新建一个同名的数据库,然后停止SQL Server服务. 3. 用原有的.mdf和.ldf文件覆盖新建数据库对应的.mdf和.ldf文件. 4. 重新启动SQL Server服务,这是应该会看到这个数据库处于置疑(Suspect)状态. 5. 在SQL查询分析器中执行以下命令,以允许更新系统表: use mastergosp_configure 'allow updates',1reconfigure with ove

恢复整个SQL server数据库还是只恢复错误文件组

这有一个具体例子:如果你有一个单个的出现问题的文件.这个文件有50MB大小,而你的整个数据库 运行着大约有几十亿的字节,这样的话如果能恢复单个失败文件的话就显的非常有意义.这样的事情发生 的一个情景是当文件或者文件组在单独的驱动器上,而驱动器出现了问题.通常,仅仅恢复单个文件或者 文件组会使总的停止时间缩短,因为它明显减少了需要恢复的总的数据量. 现在,为什么你不选择这么做呢?这有一些原因: 你需要有事务日志备份.如果你想从备份中恢复一个文件或者文件组,你同时也需要恢复与它们一起 创建的事务记录

拷贝的SQL Server 7数据库的恢复方法

server|恢复|数据|数据库 在SQL Server 7中由于MS重新设计了数据库文件的存储方式,取消了新建设备再建数据库这一繁琐的过程.新的存储格式,一个数据库包括两个文件,mdf数据库文件和ldf日志文件.所以我们在重装机器备份时可以把你要备份的数据库的这两个文件拷贝出来,重新安装之后再恢复. 在SQL Server中提供了这种恢复方式的存储过程. 1.sp_attach_db [@dbname =] 'dbname',[@filename1 =] 'filename_n' 给系统添加一