使用2000数据库时,由于D盘空间不足,要保证数据库的运行,所以在E盘增加了日志文件,使数据库有2个日志文件
在分离数据库后,删除日志文件,附加时,无法点击确定,新建数据库,分离,覆盖MDF文件后,出现质疑,请问各位大神,现在该怎么办啊?
在分离数据库后,删除日志文件,附加时,无法点击确定,新建数据库,分离,覆盖MDF文件后,出现质疑,请问各位大神,现在该怎么办啊?
解决方案 »
- SQL項目開發流程
- 如何用SQL调用系统参数创建文件夹?
- 一条SQL语句的求助 ( 急 !!)
- SQL查询语句问题!!!!!!!!!
- 【请教】 为什么这个游标不断输出sysobjects???我要在存储过程中循环取sysobjects中的记录该怎么做?
- 请问我自己的机子连我自己的sql server,是否也需要通过网卡,
- [问]一条SQL语句,谢了
- 本人吉林大学本科三年级,计算机专业,很缺钱,想在长春找个兼职,急~~
- ^_^ 如何让数据只输出两位小数 ^_^
- MSSQL中截取字符串
- 安装SQL Server08时提示需要安装.NET3.5框架,安装后还是报错
- 问个查询优化的问题,是关于时间查询的。
, [ @physname= ] 'physical_name'
MS SQL SERVER数据库置疑后恢复步骤
--SQL SERVER数据库置疑后恢复步骤
--1. 恢复步骤:
--a.将smlog_log.ldf文件备份到其它目录下;
--b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf;
--c.执行以下语句修改数据库的状态:
use Master
go
update sysdatabases set status=32768 where name='数据库名称' --修改状态,設為緊急狀態
go
shutdown with nowait --停止数据库服务器
go
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码重新启动SQL:
sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER
--e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态:
select Name,Status from sysdatabases where Name='数据库名稱'
--f.执行以下代码新建日志文件:
dbcc traceon(3604)--跟踪
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名要有全路径和扩展名
--dbcc rebuild_log('prs_msc','d:\mscsql\mssql\data\prs_msc_log.ldf
--g.将数据库置回正常状态:
update sysdatabases set status=0 where name='数据库名称'
--h.重新启动数据库后执行以下语句检查数据库:
DBCC CHECKDB --如果执行完有错误用以下语句修复
--i.要修复数据库必需将数据库改为单用户模式:
Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)
--j.执行以下语句修复数据库:
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比较高级的修复方式
REPAIR_FAST:是简单快速的修复方式
/*
處理状态就为"置疑"的數據庫
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名','single user','true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status=28 where name='置疑的数据库名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user','false'
Go /*
只有mdf文件的恢复技术
由于种种原因,我们如果当时仅仅备份了mdf文件,那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的,那么很侥幸,也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库,但是会出现类似下面的提示信息
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是,如果您的数据库文件是从其他计算机上复制过来的,那么很不幸,也许上述办法就行不通了。你也许会得到类似下面的错误信息
服务器: 消息 1813,级别 16,状态 2,行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢?别着急,下面我们举例说明恢复办法。
*/
--A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
--B.停掉数据库服务器。
--C.将刚才生成的数据库的日志文件test_log.ldf删除,用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
--D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
--E.设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器,按右--键,选择“属性”,在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--F.设置test为紧急修复模式
--在查询管理器里设置如下命令:
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表,但是仅仅有系统表
--G.下面执行真正的恢复操作,重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
/*
执行过程中,如果遇到下列提示信息:
服务器: 消息 5030,级别 16,状态 1,行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
说明您的其他程序正在使用该数据库,如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表,那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于:
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项,并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
*/
--H.验证数据库一致性(可省略)
dbcc checkdb('test')
/*一般执行结果如下:
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。*/
--I.设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
--如果没有出错,那么恭喜,现在就可以正常的使用恢复后的数据库啦。
--J.最后一步,我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然,我们可以在SQL Server Enterprise Manager里面恢复,也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
--日志文件出现问题(丢失或文件格式非法),怎么使数据库恢复正常
--如果用sp_attach_single_file 'TEST','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.mdf'失败则需要用下列步骤完成
--1.将置疑的数据库分离,将mdf文件移走或改名!
sp_detach_db 'TEST'
--2.重新在原来目录下建立同名的数据库TEST
--3.停掉SQL Service,将先前的mdf文件拷贝回来覆盖(或改名),删除原来的log文件(或改名)
--4.启动SQL Service(否则下面的语句没办法运行)
--5.将数据库设成紧急模式(status=32768)
sp_configure 'allow updates',1
reconfigure with override
update sysdatabases set status=32768 where name='TEST'
--重新建立日志文件
DBCC traceon(3604)
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
Go
--6.重新启动SQL Service
--7.将数据库设置成单用户模式(下面三个语句均可)
--sp_dboption 'TEST','single user','true'
update sysdatabases set status=4096 where name='TEST'
--alter database TEST set Single_user
--8.检查数据库的完整性和一致性,OK了就可以用了
DBCC CheckDB(TEST)
--9.将数据的访问权限设置成多用户模式
sp_dboption 'TEST','single user','false'
--或alter database TEST set multi_user
--10.关闭高级选项
sp_configure 'allow updates',0
reconfigure with override --结束 SQL Server安装挂起在安装sql server时出现“以前的某个程序安装已在安装计算机上创建挂起的文件操作。运行安装程序之前必须重新启动计算机”错误。无法进行下去。 参考有关资料后,以下步骤基本可以解决: 1)添加/删除程序中彻底删除sql server。 2)将没有删除的sql server目录也删除掉。 3)打开注册表编辑器,在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager中找到PendingFileRenameOperations项目,并删除它。这样就可以清除安装暂挂项目。 4)删除注册表中跟sql server相关的键 注意:
要是不想重新启动就顺利安装,一般来说按照第三步就可以解决……
先得恢复吧
参考如下:无数据库日志文件恢复数据库方法两则方法一1.新建一个同名的数据库2.再停掉sql server(注意不要分离数据库)3.用原数据库的数据文件覆盖掉这个新建的数据库4.再重启sql server5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.USE MASTER
GOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Gosp_dboption '置疑的数据库名', 'single user', 'true'
GoDBCC CHECKDB('置疑的数据库名')
Goupdate sysdatabases set status =28 where name='置疑的数据库名'
Gosp_configure 'allow updates', 0 reconfigure with override
Gosp_dboption '置疑的数据库名', 'single user', 'false'
Go方法二事情的起因:昨天,系统管理员告诉我,我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB,于是我决意缩小这个日志文件。经过收缩数据库等操作未果后,我犯了一个自进入行业以来的最大最愚蠢的错误:竟然误删除了这个日志文件!后来我看到所有论及数据库恢复的文章上都说道:“无论如何都要保证数据库日志文件存在,它至关重要”,甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的?!这下子坏了!这个数据库连不上了,企业管理器在它的旁边写着“(置疑)”。而且最要命的,这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器,应用倒是能用了,但是少了许多记录、表和存储过程。最终成功恢复的全部步骤如下:设置数据库为紧急模式
停掉SQL Server服务;把应用数据库的数据文件XXX_Data.mdf移走;重新建立一个同名的数据库XXX;停掉SQL服务;把原来的数据文件再覆盖回来;运行以下语句,把该数据库设置为紧急模式;运行“Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo”执行结果:DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。接着运行“update sysdatabases set status = 32768 where name = 'XXX'”执行结果:(所影响的行数为 1 行)重启SQL Server服务;运行以下语句,把应用数据库设置为Single User模式;运行“sp_dboption 'XXX', 'single user', 'true'”执行结果:命令已成功完成。做DBCC CHECKDB;运行“DBCC CHECKDB('XXX')”执行结果:'XXX' 的 DBCC 结果。'sysobjects' 的 DBCC 结果。对象 'sysobjects' 有 273 行,这些行位于 5 页中。'sysindexes' 的 DBCC 结果。对象 'sysindexes' 有 202 行,这些行位于 7 页中。'syscolumns' 的 DBCC 结果。………运行以下语句把系统表的修改选项关掉;运行“sp_resetstatus "XXX"gosp_configure 'allow updates', 0reconfigure with overrideGo”执行结果:在 sysdatabases 中更新数据库 'XXX' 的条目之前,模式 = 0,状态 = 28(状态 suspect_bit = 0),没有更新 sysdatabases 中的任何行,因为已正确地重置了模式和状态。没有错误,未进行任何更改。DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。重新建立另外一个数据库XXX.Lost;DTS导出向导
运行DTS导出向导;复制源选择EmergencyMode的数据库XXX,导入到XXX.Lost;选择“在SQL Server数据库之间复制对象和数据”,试了多次,好像不行,只是复制过来了所有表结构,但是没有数据,也没有视图和存储过程,而且DTS向导最后报告复制失败;所以最后选择“从源数据库复制表和视图”,但是后来发现,这样总是只能复制一部分表记录;于是选择“用一条查询指定要传输的数据”,缺哪个表记录,就导哪个;视图和存储过程是执行SQL语句添加的。这样,XXX.Lost数据库就可以替换原来的应用数据库了。
2.停sqlserver服务。
3.复制数据库 mdf 文件到刚建立的目录中进行覆盖。
4.启动sqlserver服务,刷新后看到数据库置疑。
然后
USE MASTER
GOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Gosp_dboption '置疑的数据库名', 'single user', 'true'
GoDBCC CHECKDB('置疑的数据库名')
Goupdate sysdatabases set status =28 where name='置疑的数据库名'
Gosp_configure 'allow updates', 0 reconfigure with override
Gosp_dboption '置疑的数据库名', 'single user', 'false'
Go最后再新建个库,把数据导入,备份、再还原就OK了