MSSQL2008数据库备份还原和数据恢复

简介: 原文:MSSQL2008数据库备份还原和数据恢复  序言 一直想写一篇关于数据库备份与恢复的文章,但基于能力的有限对数据库认知的有限怕不足以准确的表达,最后思考很久还是决定把自己的一些理解写出来供大家参考,也是为了回报自己;出于能力及语言表达能力的有限还望大家包含,如果里面有说的不对的地方还望大家及时提出、好及时修改不至于错误的引导他人。
原文: MSSQL2008数据库备份还原和数据恢复

 

序言

一直想写一篇关于数据库备份与恢复的文章,但基于能力的有限对数据库认知的有限怕不足以准确的表达,最后思考很久还是决定把自己的一些理解写出来供大家参考,也是为了回报自己;出于能力及语言表达能力的有限还望大家包含,如果里面有说的不对的地方还望大家及时提出、好及时修改不至于错误的引导他人。

认识数据库备份和事务日志备份

数据库备份与日志备份是数据库维护的日常工作,备份的目的是在于当数据库出现故障或者遭到破坏时可以根据备份的数据库及事务日志文件还原到最近的时间点将损失降到最低点。

 

数据库备份

数据库备份可以手动备份和语句备份

一.手动备份数据库

1.鼠标右键选择你要进行备份的数据库-任务-备份

可以在常规选项页面你可以选择备份类型是进行完整数据库备份还是差异数据库备份

2.点击添加选项,选择数据库文件的存放路径

注意文件名记得加后缀.bak,便于恢复时的查找

3.你还可以在选项页面是追加到现有的备份集,还是覆盖所有的现有备份集,还可以选择备份验证完整性(建议选择),还可以选择是否压缩备份等。

二.语句备份数据库

use master 
go
BACKUP DATABASE [test] TO  DISK = N'D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Backup\test.bak' WITH NOFORMAT, NOINIT,  NAME = N'test-完整 数据库 备份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

数据库日志备份

      首先需要注意,数据库日志的备份是基于数据库完整备份,也就是说你备份数据库日志之前你首先要先对数据库进行一次完整的备份,因为之间会涉及到坚持到检查点lsn这也是本文接下来要讲的重点。

一.手动备份数据库日志

1.右键数据库-任务-备份-选择备份类型(事务日志)

2.点添加,添加日志文件备份存储路径

3.同数据库完整备份一样,你也可以选择覆盖现有备份集或者追加到现有备份集,这里现在覆盖现有备份集、验证完整性,然后确认备份

二.语句备份数据库事务日志

BACKUP LOG [test] TO  DISK = N'D:\test.trn' WITH NOFORMAT, INIT,  NAME = N'test-事务日志  备份', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

数据库还原

右键数据库-还原数据库-添加需要进行还原的数据库文件路径

在还原源选项中你可以选择‘源数据库’,‘源设备’。1.选择源数据库工具会自动显示该数据库之前的一些备份,然后直接选择需要还原的数据库备份集。

2.选择源设备点击后面的...,添加需要还原的数据库文件

2.点击确认还原数据库

数据库恢复

数据库恢复的前提是1.一个完整的数据库备份2.包含这个完整数据库备份的事务日志备份3.完整备份之间也可以存在数个差异备份

对于数据库维护空间始终是一个比较头疼的问题,特别是对于大型数据库而言,每天的日志文件增长是庞大的,很多数据库管理员会定时对数据库日志文件进行收缩,但是经常收缩会存在收缩完日志文件还是不能减少,这是因为存在很多活动的日志无法收缩可以用

DBCC LOGINFO('
数据库名称
')   
 
我们看到
status=0
的日志,代表已经备份到磁盘的日志文件;而
status=2
的日志还没有备份。当我们收缩日志文件时,收缩掉的空
间其实就是
status=0
的空间,如果日志物理文件无法减小,这里一
定能看到非常多
status=2
的记录

 

 解决办法:1.可以分离要收缩的数据库,然后手动删除日志文件,然后附加数据库,数据库就会产生一个很小的日志文件(不推荐使用这种方法)

2.右键要出来的数据库选择“属性”-"选项",将恢复模式改成"简单",然后利用收缩工具可以讲日志文件收缩到很小,收缩完记得讲恢复模式改成"完整"

也可以用语句进行处理(dbname是你要进行收缩的数据库名,dbname_log是你要进行收缩的数据库的逻辑日志名称)

USE [master]
    GO
    ALTER DATABASE [dbname] SET RECOVERY SIMPLE WITH NO_WAIT
    GO
    ALTER DATABASE [dbname] SET RECOVERY SIMPLE   --简单模式
    GO
    USE [dbname]
    GO
    DBCC SHRINKFILE (N'dbname_log' , 11, TRUNCATEONLY)
    GO
    USE [master]
    GO
    ALTER DATABASE [dbname] SET RECOVERY FULL WITH NO_WAIT
    ALTER DATABASE [dbname] SET RECOVERY FULL

对于第一种方法不赞同使用,首先对于数据库的分离与附加有时候会破坏数据库,造成数据库无法还原,还有就是对于在线数据库也不允许进行分离操作。

对于第二种方法是slq2008收缩日志文件的一种方法,但是此方法也不能使用过于频繁,因为进行数据库恢复模式的更改会截断事务日志文件,这样的话当时利用事务日志文件进行恢复的时候检查点不能包含数据库文件,而且当你要对事务日志进行备份的时候会重新提示你需要对数据库进行完整备份。

举个例子:比如你昨天晚上进行了一次完整备份,然后同时你也进行了一次日志备份(提前日志未被截断),然后你每个小时进行过一次差异备份,最近的差异备份时间点是14点,如果此时数据库错误修改了数据,你可以立马备份一个日志文件将数据库恢复到日志备份开始到日志备份终点前的任意时间点 。

如果此时你进行了修改数据库模式,截断日志进行了收缩,那么你的数据只能恢复到昨天晚上备份的那个日志备份时间前的任意时间点,也就是今天所做的数据库更改无法再恢复了,因为日志文件已经被截断了,不知道这样解释是否明白

因为日志文件的检查点(lsn)是连续的,每一次日志备份都是在上一次备份的基础上lsn往后增加的,lsn的范围也包括了数据库文件的lsn,也只有日志文件的lsn包括了数据库文件的lsn,才能将数据库文件进行回滚。

 

上图中总共有三个备份文件,一个完整备份、一个差异备份、一个日志备份。

大家可以注意观察完整备份的第一个lsn与最后一个lsn和检查点(从05700064到08500001)

第二个差异备份文件的的第一个lsn与最后一个lsn和检查点(从09300034到10800001)

最后的日志备份的第一个lsn和最后一个lsn包含了前面两个备份文件的lsn(从05700064到10800001),这种情况数据库就可以恢复到日志文件备份前的任意时间点,如果日志文件没有包含数据库文件的最后一个lsn也就无法恢复了。

 结语

在数据库维护过程中对数据库的日常备份是必须的,毕竟这是降低损失的最有效的办法,希望大家积极评论,希望我的一点见解能给大家带来帮助。

 

备注:

    作者:pursuer.chen

    博客:http://www.cnblogs.com/chenmh

本站点所有随笔都是原创,欢迎大家转载;但转载时必须注明文章来源,且在文章开头明显处给明链接,否则保留追究责任的权利。

《欢迎交流讨论》

目录
相关文章
|
5月前
|
数据库
数据库数据恢复—MSSQL报错“附加数据库错误823”的数据恢复案例
MSSQL Server数据库比较常见的报错是“附加数据库错误823”。如果数据库有备份,只需要还原备份即可;如果无备份或者备份不可用,则需要使用专业的数据恢复手段去恢复数据。 MSSQL Server数据库出现“823”的报错信息通常情况下有以下三种可能:1、由于数据库的物理页面出现了损坏。2、校验值被损坏导致的数据库页面无法被识别。3、异常断电、文件系统损坏导致的数据库页面丢失。
数据库数据恢复—MSSQL报错“附加数据库错误823”的数据恢复案例
|
4月前
|
SQL 弹性计算 关系型数据库
服务器数据恢复-华为ECS云服务器mysql数据库数据恢复案例
云服务器数据恢复环境: 华为ECS云服务器,linux操作系统,mysql数据库(innodb引擎)。作为网站服务器使用。 云服务器故障: 在执行mysql数据库版本更新测试时,误将本应该在测试库上执行的sql脚本执行在生产库上了,生产库上的部分表被truncate,部分表内有少量数据被delete。 需要恢复被truncate的表以及被少量数据被delete的表。
服务器数据恢复-华为ECS云服务器mysql数据库数据恢复案例
|
7天前
|
SQL 存储 数据挖掘
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
服务器数据恢复环境: 一台安装windows server操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。 在windows服务器内装有SqlServer数据库。存储空间LUN划分了两个逻辑分区。 服务器故障&初检: 由于未知原因,Sql Server数据库文件丢失,丢失数据涉及到3个库,表的数量有3000左右。数据库文件丢失原因还没有查清楚,也不能确定数据存储位置。 数据库文件丢失后服务器仍处于开机状态,所幸没有大量数据写入。 将raid5中所有磁盘编号后取出,经过硬件工程师检测,没有发现明显的硬件故障。以只读方式将所有磁盘进行扇区级的全盘镜像,镜像完成后将所
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
|
20天前
|
SQL 关系型数据库 MySQL
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)(一)
【MySQL技术专题】「问题实战系列」深入探索和分析MySQL数据库的数据备份和恢复实战开发指南(数据恢复补充篇)
29 0
|
1月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
北京某国企客户Oracle 11g R2数据库误truncate table CM_CHECK_ITEM_HIS,表数据丢失,业务查询到该表时报错,数据库的备份不可用,无法查询表数据。 Oracle数据库执行Truncate命令的原理:在执行Truncate命令后ORACLE会在数据字典和Segment Header中更新表的Data Object ID,但不会修改实际数据部分的块。由于数据字典与段头的DATA_OBJECT_ID与后续的数据块中的并不一致,所以ORACLE服务进程在读取全表数据时不会读取到已经被TRUNCATE的记录,但是实际数据未被覆盖。
Oracle数据恢复—Oracle数据库误truncate table的数据恢复案例
|
7月前
|
数据库
数据库update后的数据恢复
数据库update后的数据恢复
62 0
|
2月前
|
存储 Oracle 关系型数据库
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
oracle数据库ASM磁盘组掉线,ASM实例不能挂载。数据库管理员尝试修复数据库,但是没有成功。
【数据库数据恢复】Oracle数据库ASM磁盘组掉线的数据恢复案例
|
4月前
|
运维 Oracle 关系型数据库
服务器数据恢复-raid5故障导致上层oracle数据库故障的数据恢复案例
服务器数据恢复环境: 一台服务器中有一组由24块FC硬盘组建的raid5磁盘阵列,linux操作系统+ext3文件系统,服务器上层部署有oracle数据库。 服务器故障&检测: raid5阵列中有两块硬盘出现故障掉线,导致服务器上层卷无法挂载,oracle数据库无法正常使用。 通过管理后台查看服务器中硬盘的状态,显示有两块硬盘处于离线状态。
|
4月前
|
Oracle 关系型数据库 数据库
oracle数据恢复—服务器断电导致Oracle数据库报错的数据恢复案例
一台Windows server操作系统的服务器上部署Oracle数据库。 服务器意外断电导致oracle数据库报错,报错信息:“system01.dbf需要更多的恢复来保持一致性”。由于该oracle数据库并没有备份,仅有一些断断续续的归档日志,无法通过备份文件恢复oracle数据库的数据。管理员联系北亚企安数据恢复中心要求修复Oracle数据库。
oracle数据恢复—服务器断电导致Oracle数据库报错的数据恢复案例
|
4月前
|
SQL 关系型数据库 MySQL
数据库数据恢复—windows server下Mysql数据库数据恢复案例
mysql数据库数据恢复环境: 本地服务器,windows server操作系统 ,部署有mysql单实例,数据库引擎类型为innodb,独立表空间,无数据库备份,未开启binlog。 mysql数据库故障: 工作人员使用Delete命令删除数据时未添加where子句进行筛选,导致全表数据被删除,删除后未对该表进行任何操作。