附加没有日志文件的数据库方法

今天客户那边执行SQL报错，经查看是客户服务器数据库磁盘已被全部用完，日志文件达到500GB的程度，后来由于我的错误操作导致日志文件(.ldf)被删除，后来附加.mdf文件老是说没有日志文件附加不成功，后来经过一番折腾终于解决了，下面分享一下！

　　阅读目录

　　操作步骤

　　回到顶部

　　操作步骤

　　1.新建同名的数据库文件

　　2.暂停SQLSetver服务

　　3.将原先的mdf文件，覆盖新建的数据库，删除新数据库的ldf文件

　　4.重新启动SQLSetver服务，这时看到的数据库是这个样子的，打不开

　　5.执行以下SQL语句

1 --1.设置为紧急状态

2 alter database 数据库名称 set emergency

3 --2.设置为单用户模式

4 alter database 数据库名称 set single_user

5 --3.检查并重建日志文件

6 dbcc checkdb('数据库名称',REPAIR_ALLOW_DATA_LOSS)

7 --4.第3步操作如果有错误提示，运行第4步，没有错误则跳过

8 dbcc checkdb('数据库名称',REPAIR_REBUILD)

9 --5.恢复成多用户模式
10 alter database 数据库名称 set multi_user成

　　或者也可以采用手动附加（本方法参考@码道程工）

最新内容请见作者的GitHub页：http://qaseven.github.io/

时间： 2024-12-23 13:31:14

附加没有日志文件的数据库方法的相关文章

没有数据库日志文件恢复数据库方法两则

恢复|数据|数据库方法一 1.新建一个同名的数据库 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库 4.再重启sql server 5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名) 6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了. USE MASTERGOSP_CONFIGURE ALLOW UPDATES,1

无数据库日志文件恢复数据库方法两则

方法一 1.新建一个同名的数据库 2.再停掉sql server(注意不要分离数据库) 3.用原数据库的数据文件覆盖掉这个新建的数据库 4.再重启sql server 5.此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名) 6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了. USE MASTER GO SP_CONFIGURE 'ALLOW UPDATES',1 REC

mysql二进制日志文件恢复数据库_Mysql

二进制日志的文件的作用 mysql二进制日志文件用来记录所有用户对数据库操作,即记录用户对数据库操作的sql语句.如果有此文件,当数据库发生意外时,可以通过此文件查看到用户在此文件记录的时间段内用户所做的操作,再和数据库备份配合使用,即可再现用户操作,使数据库恢复. 二进制日志文件的弊端二进制日志文件开启后,所有对数据库操作的记录均会被记录到此文件, 所以,当长时间开启之后,日志文件会变得很大,占用磁盘空间. 使用二进制日志文件恢复数据库开启日志文件 mysql默认是不开启日志文件的

SQL Server日志文件庞大收缩方法（实测好用）

原文:SQL Server日志文件庞大收缩方法(实测好用) 这两个命令连续执行,间隔时间越少越明显(可多次运行),直到达到效果 --截断 BACKUP LOG CloudMonitor TO DISK='NUL' --收缩 DBCC SHRINKFILE('CloudMonitor_log') 以后就可以采用常规的定期备份日志(比如一小时一次)来防止日志文件无限增长. SQL Server日志文件庞大收缩并非易事, 文章中提到: 由于首日志.尾日志和空间重复利用的原因,当备份日志后产生了日志

windows服务器mysql日志文件清理简单方法

mysql-bin.0000x是什么文件 mysql-bin.000001.mysql-bin.000002等文件是数据库的操作日志,例如UPDATE一个表,或者DELETE一些数据,即使该语句没有匹配的数据,这个命令也会存储到日志文件中,还包括每个语句执行的时间,也会记录进去的. 使用是什么 mysql-bin.00000x日志文件就是一个非常简单的用来记录我们mysql日志文件了,我们可以利用它来保证mysql数据完整性,如果数据库出问题了,而你之前有过备份,那么可以看日志文件,找出是哪个命

MSSQL· 实现分析 · Extend Event日志文件的分析方法

背景在前两篇月报分享中,6月份月报我们分享了SQL Server实现审计日志功能的方法探索,最终从可靠性.对象级别.可维护性.开销和对数据库系统影响五个方面得出最佳选项Extend Event:7月份月报我们量化分析了使用Extend Event实现审计日志功能对SQL Server本身的性能和吞吐量的影响,结论是对系统性能和吞吐量影响均在0.01%左右:8月份的月报分享是SQL Server审计日志专题的最后一期,探讨Extend Event实现审计日志功能的分析方法汇总,以及这些方法的优缺

MSSQL 监控数据/日志文件增长实现方法

前几天,在所有数据库服务器部署了监控磁盘空间的存储过程和作业后(MS SQL 监控磁盘空间告警),今天突然收到了两封告警邮件,好吧,存储规划是一方面,但是,是不是要分析一下是什么原因造成磁盘空间不足的呢?会不会是因为突然暴增的日志文件,抑或是系统业务猛增导致数据量暴增,还是历史数据累计原因....分析总得有数据来支撑吧,但是现在只有那些数据文件的当前大小信息,没有数据文件的历史增长变化信息,所以,今天就想实现这么一个功能,每天(频率可以调整)去收集一下数据文件的信息,放到一个表里面,这样方便我们

log4j中配置日志文件相对路径方法分析

方法一. 解决的办法自然是用相对路径代替绝对路径,其实log4j的FileAppender本身就有这样的机制,如:log4j.appender.logfile.File=${WORKDIR}/logs/app.log其中"${WORKDIR}/"是个变量,会被System Property中的"WORKDIR"的值代替.这样,我们就可以在log4j加载配置文件之前,先用System.setProperty ("WORKDIR", WORKDI