由于长时间从事企业应用系统开发,前往用户现场升级.调试系统是比较常做的事情,但是就在周一,由于同事的失误在毫无知觉的情况下误删了生产数据库几乎所有的数据.当我发现的那一刻,感觉头发都立起来了,心想这他娘的是要领盒饭了. 为了迅速恢复系统的使用,在当时的情况下立即关闭相关系统的访问入口,前后共花费不到五分钟.经过思考,立即将最近的一次备份文件进行还原,从而保证了系统的正常运行,但是此举也不可避免的可能会丢掉某些数据. 另外事情已经发生,如何做才能为以后的数据恢复做准备呢,以下是自己的观点: 1.务

原文:sql2005,sql2008,sql2012清空日志语句 sql2005清空日志语句 Backup Log DbName WITH no_log GO DUMP TRANSACTION DbName WITH no_log GO USE DbName ) GO sql2008,sql2012清空日志语句 ALTER DATABASE DbName SET RECOVERY SIMPLE WITH NO_WAIT ALTER DATABASE DbName SET RECOVERY SIM

--1.先把数据库设置为简单模式(右击数据库名->点'属性'->点'选项'->恢复模式改成'简单'->点'确定'按钮,--2.再执行下面的语句(或者右击数据库点'任务'->'收缩'->'文件',文件件类型选'日志',再点'确定'按钮)use [dbname]checkpointDBCC SHRINKDATABASE([dbname])GO --3.操作完后按步骤1把‘恢复模式’ 改回‘完整理’)

--========================================= -- Oracle 联机重做日志文件(ONLINE LOG FILE) --========================================= 一.Oracle中的几类日志文件 Redo log files      -->联机重做日志 Archive log files   -->归档日志 Alert log files     -->告警日志 Trace files        

extundelete [root@xuegod63 ~]# lsof -p 43641 #一般用于查看木马进程,在读哪些文件 [root@xuegod63 ~]# lsof -i :22 #用于查看端口,或查看黑客开启的后门端口是哪个进程在使用 原理汇总电源-bios引导(硬件初始化)-MBR引导(读取分区信息)-grub2引导(加载内核)-内核(内核初始化)-systemd初始(守护进程选择启动级别) 默认启动级别systemctl set-default name.target 3syst

2005中遇到置疑.丢失日志时按照网上常见的MSSQL2000修复方法来做, 结果发现行不通,甚至连一步都做不下去.其实,在MSSQL2005在处理置疑问题的思 路与MSSQL2000是一致的,但具体到一些语句上MSSQL2005 有了很大的变动.我们以 一个被误删日志文件的数据库为例: 1．MSSQL2000在日志被误删除后会提示置疑(suspect),而在MSSQL2005中却没有特 殊标志,但图标前的”+”不见了当你查询数据库属性时会有Error:945提示: 2．顺着老思路,首先我们想到

第一步:   这个错误首先查看服务进程是否正常启动: 第二步:   一般情况下第一步都没问题,问题出在可能误删了日志文件: 当然可能不是你删除的,可能被某些清理软件删除的: 或者是其他情况导致日志出错的: 如果你认为你没有其他不当的操作,仅仅是觉得有可能是因为误删日志或日志出错导致的: 那么进入第三步 第三步:因本人数据库在win10系统 打开cmd 1:         sqlplus /NOLOG 2:        connect sys/change_on_install as sysd

1.查询日志是否开启 show variables like"log_"; 2.查询是用的哪个日志文件 show master status; 3.定位是在什么时间误删的 /usr/local/mysql/bin/mysqlbinlog /usr/local/mysql/var/mysql-bin.000075 show binlog events in 'mysql-bin.000075'; 也就是说,610是drop了数据表,那么恢复至能到505即可 4.恢复 /usr/local

SQL2008 SQL2012 SQL2014 的收缩日志 由于SQL2008对文件和日志管理进行了优化,所以以下语句在SQL2005中可以运行但在SQL2008中已经被取消:(SQL2005)BackupLog DNName with no_loggodumptransaction DNName with no_loggoUSE DNName DBCC SHRINKFILE (2)Go-------------------------------------------------------

解到: MySQL的binlog日志是什么?通常是用来干什么的? 模拟一次误删数据的操作,并且使用binlog日志恢复误删的数据. 写这篇文章的初衷,是有一次我真的险些把测试数据库的一张表给删除了,当时吓出一身冷汗.原因是由于Spring JPA的配置中,有一个spring.jpa.properties.hibernate.hbm2ddl.auto=create-drop,其用途是每次加载hibernate时根据model类生成表,但是sessionFactory一关闭,表就自动删除.,这个可不

SQL Server日志文件因为误操作被删除,当附加数据库的时候提示:附加数据库失败. 解决办法如下: 1.新建一个同名数据库. 2.停止数据库服务,覆盖新建的数据库主文件(小技巧:最好放在同一个磁盘里面,把新建的数据库主文件删掉或移开,再把要恢复的数据库主文件剪切过去,这样就可以节省时间.) 3.启动数据库服务,数据库变为置疑或可疑状态.然后在查询分析器中运行: alter database 无日志文件的数据库名称 . set emergency 设置为紧急状态. 4.再运行: alter d

转载地址:https://www.cnblogs.com/mrzl/p/4043313.html

今天同事不小心将一个很重要的数据表中的数据删除了,找了很多人都没办法恢复.我在网上搜索了一下资料,发现有一个方法可以一试,具体如下 http://www.knowsky.com/616730.html  非常感谢这位仁兄,用这个方法果然恢复成功 SQL Server数据恢复--日志备份 SQL Server数据恢复--日志备份 太坑了,我把数据给删了 "大坑啊,数据被我误删了."从事数据库相关工作的过程中,我想应该很多人会有过和我一样的遭遇吧?尤其是在进行update或者delete操

Northwind 示例数据库下载:  NORTHWND.MDF   (PS:开始试过sql2012直接附加失败) 新建查询-执行下面代码 USE [master] GO CREATE DATABASE [NORTHWIND] ON ( FILENAME = N'E:\homework\NORTHWND.MDF' ) FOR ATTACH GO E:\homework\NORTHWND.MDF为下载时的路径(注意下载解压后,右击文件属性-解锁)执行结果 文件激活失败.物理文件名称'D:\Data

本文转载自桦仔的博客http://www.cnblogs.com/lyhabc/archive/2013/07/16/3194220.html 解释一下SQLSERVER事务日志记录 大家知道在完整恢复模式下,SQLSERVER会记录每个事务所做的操作,这些记录会存储在事务日志里,有些软件会利用事务日志来读取 操作记录恢复数据,例如:log explorer 那么事务日志记录怎麽查看,里面都记录了些什么? 打开可以利用下面SQL语句来查看所在数据库的事务日志记录 1 USE [GPOSDB] -

这个只能是试一下的方法,但不一定能成功,可以尝试如下几个方法: 1.登录远程桌面,然后以.登录SQL Server,并以Windows身份登录,然后再附加数据库时把日志文件删除. 2.试下这个脚本: .新建一个同名的数据库 .再停掉sql server(注意不要分离数据库) .用原数据库的数据文件覆盖掉这个新建的数据库 .再重启sql server .此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名) .完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要

解释一下SQLSERVER事务日志记录 大家知道在完整恢复模式下,SQLSERVER会记录每个事务所做的操作,这些记录会存储在事务日志里,有些软件会利用事务日志来读取 操作记录恢复数据,例如:log explorer 那么事务日志记录怎麽查看,里面都记录了些什么? 打开可以利用下面SQL语句来查看所在数据库的事务日志记录 USE [GPOSDB] --要查看事务日志记录的数据库 GO SELECT * FROM [sys].[fn_dblog](NULL,NULL) 事务日志记录里很多东西可以看

linux上定时执行某些脚本是管理服务器的时候比较常用的场景,比如定时检查进程是否存在,定时启动或关闭进程,定时检查日志删除日志等. 当我打开google百度crontab时长篇大论的一大堆,详细解释的一大堆,各种抄来抄去,现在觉得资源多了未必是好事. 假设是定时执行shell,来移动log文件 找到个网上的脚本: #!/bin/bash log_path="" #此处定义你的日志文件夹路径 expried_time= #此处定义你的日志过期时间,如7天 function mvLogs

        昨天 同事在本机清理数据库表时,连接到了生产机,误删了二十几张表,幸好是晚上加班的时候删除的,生产机上当时是一天一备份,还原备份是最后的策略,最关键的还是要找回数据.         生产机环境是server2008 R2. sqlserver2012,使用delete语句删除的表现在开始还原,还原可参考dudu的这篇文章(链接),其中使用Recovery for SQL Server工具还原,发现还原的数据字段值为demo,所以最后还是用sql命令去还原的,用sql命令,微软官

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这个标题有点用词不当,因为运行在大容量日志恢复模式里的数据库,我们通常是长期不管理日志.但是,DBA会考虑在大容量加载时,短期切换到大容量恢复模式.当数据库在大容量模式里运行时,一些其他例如索引重建的操作会最小化日志(minimally logged),因此在日

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这