㈠ 求助sql的问题无法打开数据库，恢复操作已将数据标记为suspect
msdb 是系统数据库，里面记录调度警报和作业以及操作员的信息，咐孙如梁腊果没有用到这些内容，直接用备份恢复衡渣链就可以的。 在单用户模式下，停掉SQL server服务，在另一台机装同版本sqlserver，把msdb覆盖过来，搞定。
㈡ SQL server2008本地数据库被删，怎么恢复
主要步骤如下：
1. 查询被标记的数据库
USE master
GO
SELECT NAME,STATE_DESC FROM SYS.DATABASES
WHERE STATE_DESC='SUSPECT'
GO
2. 设置为紧急状态EMERGENCY，此时数据库可以有一个用户连接。由于本次数据库比较大，就没有继续向下操作，我的做法是写了脚步，把数据逐个的导出到另外一个库。
有部分表，数据不全，查询失败，通过限制条件，逐步把可以查询出来的导出来。
USE master
GO
ALTER DATABASE BPO SET EMERGENCY
GO
3.检查数据库
DBCC CHECKDB (BPO)
GO
4. 设置用户
ALTER DATABASE BPO SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
5. 修复
DBCC CHECKDB (BPO, REPAIR_ALLOW_DATA_LOSS)
GO
6. 设置用户
ALTER DATABASE BPO SET MULTI_USER
GO
㈢ sql2000数据库置疑怎么处理
1、新建一同名数据库（文件名，文件组都和原来的一样），然后停止数据库服务，用原来文件替换新建的数据库文件，启动数据库，该数据库被设为suspect
2、把数据库改成紧急模式：
sp_configure
'allow',
1
reconfigure
with
override
update
sysdatabases
set
status
=
32768
where
name
=
'数据库名'
3、把LDF文件改名，再执行
DBCC
REBUILD_LOG
('数据库名',
'E:\fdzz\database\fdzz1204_Log.LDF'
)
4、恢复数据库紧急模式
update
sysdatabases
set
status
=
0
where
name
=
'数据库名'
如果不行,你就去看这篇文章.
http://www.flashmayi.com/article/show.php?id=8363&spn=1
㈣ 如何解决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",1reconfigurewithoverridego。
6. 将这个数据库置为紧急模式：update sysdatabases set status = 32768 where name="db_name"go。
7. 使用DBCC CHECKDB命令检查数据库中的错误：DBCC CHECKDB("db_name")GO。
8. 如果DBCC CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：sp_dboption "db_name","single
user","true"DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)GO
如果在执行DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话，则重新启动SQLServer服务，然后继续尝试。
9. 如果DBCCCHECKDB("db_name",REPAIR_ALLOW_DATA_LOSS)命令失败，请转至第10步，否则若成功修复了数据库中的错误：
重新执行DBCC CHECKDB("db_name")命令，确认数据库中已没有错误存在。
清除数据库的置疑状态：sp_resetstatus "db_name"
清除数据库的单用户模式状态：sp_dboption "db_name","single user","false"
重新启动SQL Server服务，如果一切正常的话，则数据库已经成功恢复。
10.如果以上步骤都不能解决问题的话，请参考附件中的文档尝试通过重建事务日志来恢复数据库中的数据。如果您只有MDF文件，问题就更加复杂一些，我们需要直接重建事务日志了:
1. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
2. 用原有的ldf文件覆盖新建数据库对应的.mdf文件，将其日志文件（.ldf）删除。
3. 启动SQL Server服务，并将数据库置为紧急模式（同上: 步骤5和步骤6）。
4. 停止并重新启动SQL Server服务。
5. 执行以下命令重建数据库日志文件：(下面是个示例，您要用您实际的数据库名)
DBCC REBUILD_LOG（"cas_db", "D:\cas_db\cas_db_Log.LDF"）
6. 重新将该数据库置为单用户模式。
7. 再次尝试使用DBCC CHECKTABLE或DBCC CHECKDB命令检查并修复数据库中。
㈤ SQL Server：无日志恢复数据库
事情的起因 昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等操作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的?!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!数据库日志文件的误删或别的原因引起数据库日志的损坏 方法一 新睁轮建一个同名的数据库 再停掉sql server(注意不要分离数据库) 用原数据库的数据文件覆盖掉这个新建的数据库 再重启sql server 此时打开企业管理器时会出现置疑 先不管 执行下面的语句(注意修改其中的数据库名) 完成后一般就可以访问数据库中的数据了 这时 数据库本身一般还要问题 解决办法是 利用数据库的脚本创建一个新的数据库 并将数据导进去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的数据库名 Gosp_dboption 置疑雀腊的数据库名 single user true GoDBCC CHECKDB( 置疑的数据库名 )Goupdate sysdatabases set status = where name= 置疑的数据库名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的数据库名 single user false Go 方法二 事情的起因昨天 系统管理员告诉我 我们一个内部应用数据库所在的磁盘空间不足了 我注意到数据库事件日志文件XXX_Data ldf文件已经增长到了 GB 于是我决意缩小这个日志文件 经过收缩数据库等操作未果后 我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道: 无论如何都要保证数据库日志文件存在 它至关重要 甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的 我真是不知道我那时候是怎么想的?!这下子坏了!这个数据库连不上了 企业管理器在它的旁边写着 (置疑) 而且最要命的 这个数据库从来没有备份了 我唯一找得到的是迁移半年前的另外一个数据库服务器 应用倒是能用了 但是少了许多记录 表和存储过程 真希望这只是一场噩梦!没有效果的恢复步骤附加数据库_Rambo讲过被删除日志文件中不存在活动日志时 可以这么做来恢复:悉岁信 分离被置疑的数据库 可以使用sp_detach_db 附加数据库 可以使用sp_attach_single_file_db但是 很遗憾 执行之后 SQL Server质疑数据文件和日志文件不符 所以无法附加数据库数据文件 DTS数据导出不行 无法读取XXX数据库 DTS Wizard报告说 初始化上下文发生错误 紧急模式怡红公子讲过没有日志用于恢复时 可以这么做: 把数据库设置为emergency mode 重新建立一个log文件 把SQL Server 重新启动一下 把应用数据库设置成单用户模式 做DBCC CHECKDB 如果没有什么大问题就可以把数据库状态改回去了 记得别忘了把系统表的修改选项关掉我实践了一下 把应用数据库的数据文件移走 重新建立一个同名的数据库XXX 然后停掉SQL服务 把原来的数据文件再覆盖回来 之后 按照怡红公子的步骤走 但是 也很遗憾 除了第 步之外 其他步骤执行非常成功 可惜 重启SQL Server之后 这个应用数据库仍然是置疑!不过 让我欣慰的是 这么做之后 倒是能够Select数据了 让我大出一口气 只不过 组件使用数据库时 报告说: 发生错误: 未能在数据库 XXX 中运行 BEGIN TRANSACTION 因为该数据库处于回避恢复模式 最终成功恢复的全部步骤设置数据库为紧急模式停掉SQL Server服务;把应用数据库的数据文件XXX_Data mdf移走;重新建立一个同名的数据库XXX;停掉SQL服务;把原来的数据文件再覆盖回来;运行以下语句 把该数据库设置为紧急模式;运行 Use MasterGosp_configure allow updates reconfigure with overrideGo 执行结果:DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 接着运行 update sysdatabases set status = where name = XXX 执行结果:(所影响的行数为 行)重启SQL Server服务;运行以下语句 把应用数据库设置为Single User模式;运行 sp_dboption XXX single user true 执行结果:命令已成功完成 ü 做DBCC CHECKDB;运行 DBCC CHECKDB( XXX ) 执行结果: XXX 的 DBCC 结果 sysobjects 的 DBCC 结果 对象 sysobjects 有 行 这些行位于 页中 sysindexes 的 DBCC 结果 对象 sysindexes 有 行 这些行位于 页中 syscolumns 的 DBCC 结果 ………ü 运行以下语句把系统表的修改选项关掉;运行 sp_resetstatus XXX gosp_configure allow updates reconfigure with overrideGo 执行结果:在 sysdatabases 中更新数据库 XXX 的条目之前 模式 = 状态 = (状态 suspect_bit = ) 没有更新 sysdatabases 中的任何行 因为已正确地重置了模式和状态 没有错误 未进行任何更改 DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系 已将配置选项 allow updates 从 改为 请运行 RECONFIGURE 语句以安装 重新建立另外一个数据库XXX Lost;DTS导出向导运行DTS导出向导;复制源选择EmergencyMode的数据库XXX 导入到XXX Lost;选择 在SQL Server数据库之间复制对象和数据 试了多次 好像不行 只是复制过来了所有表结构 但是没有数据 也没有视图和存储过程 而且DTS向导最后报告复制失败;所以最后选择 从源数据库复制表和视图 但是后来发现 这样总是只能复制一部分表记录;于是选择 用一条查询指定要传输的数据 缺哪个表记录 就导哪个;视图和存储过程是执行SQL语句添加的 维护Sql Server中表的索引在使用和创建数据库索引中经常会碰到一些问题 在这里可以采用一些另类的方法解决… 第一步:查看是否需要维护 查看扫描密度/Scan Density是否为 %declare @table_id intset @table_id=object_id( 表名 )dbcc showcontig(@table_id) 第二步:重构表索引dbcc dbreindex( 表名 pk_索引名 ) 重做第一步 如发现扫描密度/Scan Density还是小于 %则重构表的所有索引 并不一定能达 % dbcc dbreindex( 表名 ) lishixin/Article/program/SQLServer/201311/22169
㈥ 如何解决无法打开数据库，恢复操作已将数据标记为suspect
释放磁盘空间并且重新运行恢复操作,按照下面的步骤收缩日志。
sp_resetstatus 关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项。
为从根本上解决这样的问题,你可以按下面的操作配置SQLSERVER 2000:
a.如果不需要恢复到指定的时间点,你可以将数据库的恢复模式配置为简单,这样
UPDATE,DELETE,SELECT就不会记录日志,日志就不会增加的很大:
USE MASTER
GO
ALTER DATABASE DB_NAME SET RECOVERY SIMPLE
b.如果你的恢复模式是全部,你一定要配置日志字段收缩:
USE MASTER
GO
sp_dboption 'databasename','trunc. log on chkpt.',true
sp_dboption 'databasename','autoshrink',true
c.通过每日备份将日志收缩:
BACKUP DATABASE DATABASE_NAME TO BACKUP_DEVICES
BACKUP LOG DATABASE_NAME TO LOG_DEVICES
OR
BACKUP LOG DATABASE_NAME with truncate_only
**检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志并没有收缩!
d.每天在备份数据库完成之后,重新启动MS SQLSERVER SERVICE.
USE DATABASE_NAME
go
DBCC SHRINKFILE(2,truncateonly)
**检查日志的容量:DBCC SQLPERF (LOGSPACE) 这时日志已经收缩!
e.手动快速收缩日志:
/ *run below script,you will shrink you database log files
immediately, in my experience,you need to run the script for 3 or
4 minutes before stopping it manually */
use databasename
dbcc shrinkfile(2,notruncate)
dbcc shrinkfile(2,truncateonly)
create table t1(char1 char(4000))
go
declare @i int
select @i=0
while(1=1)
begin
while(@i<100)
begin
INSERT INTO T1 VALUES ('A')
SELECT @I=@I+1
END
TRUNCATE table T1
BACKUP LOG youdatabasename with truncate_only
end
GO