数据库恢复的基本原理是利用什么重建数据库

数据库恢复的基本原理是利用什么重建数据库,第1张

重建数据时压测环境没有备份,但是另一套测试环境的表结构与压测环境一致,只是数据有所差异,所以,获取表结构比较容易。导入表结构没有什么好说明的地方,注意导入 SQL 的权限和字符集。 重建表空间注:此小节对应恢复步骤的 。由于是整库恢复,数据库和表较多,所以使用脚本处理。大概的处理流程是,两层循环,外层循环数据库列表,内层循环对应数据库表列表。然后依次 DISCARD TABLESPACE、拷贝对应库对应表的 ibd 文件到对应目录并更改权限、IMPORT TABLESPACE。之前分析过,由于新旧的 ibd 文件表空间 id 不一致,导致不能正确导入。在 MySQL 错误日志中记录了表名、新旧表空间 id,接下来我们看看怎么分解。 分析 MySQL 错误日志注:此小节对应恢复步骤的和 。这一步很有意思。所有的数据库表累计,不可能使用人工处理,我们得想点取巧的办法。我们发现 MySQL 错误日志记录的表名、新旧表空间 id 很有规律,我们只需要依次取出这些值,问题就解决一大半了。

好久没玩了,也不知道说的对不对。说说自己的理解,互相学习学习。

1为什么需要全部控制文件的备份文件,只靠全部数据文件恢复表空间不行吗?

下面是一个假设的例子

上午9点,数据库正常,备份数据库

上午10点,错误删除了一个表空间

上午11点,发现错误删除了,需要恢复

这里 9点的时候,控制文件中,记录了你每个数据文件的信息。

10点的时候,误删了表空间,导致一个或多个数据文件,被删除掉,同时 控制文件中,不再记录该文件的信息。

11点的时候,你要恢复那个误删的表空间,那就必须要 定位到9点的那个时候的控制文件。 因为9点的时候,控制文件中记录了 每个表空间,由多少个数据文件组成,以及数据文件都叫啥名字

如果你只有一堆数据文件的话,Oracle 没法自动的识别这些文件,原来是属于哪一个表空间的。

2假如该例子不完全数据库恢复之后,那么是恢复到数据库之前的一个时间,尽然这样的话,那么的用来恢

复的控制文件和数据文件的SCN是往后推移的,那是不是日志文件和系统改变的SCN是往前的呢?SCN是否

可以往前。 或者是我对不完全数据库恢复还没有理解,请大家帮我解决下!!

SCN = SYSTEM CHANGE NUMBER

就是当数据库 COMMIT 之后,这个 SCN 会不断地从小到大递增。

还是前面那个例子

上午9点,数据库正常,备份数据库 假如这个时候数据库 SCN = 500

上午10点,错误删除了一个表空间 假如这个时候数据库 SCN = 600

上午11点,发现错误删除了,需要恢复 假如这个时候数据库 SCN = 700

那么上面的这种情况下,你需要把数据库恢复到删除表空间的前一个 SCN 之前, 也就是 SCN = 599 的情况下。

SQL Server中误删除数据的恢复本来不是件难事,从事务日志恢复即可。但是,这个恢复需要有两个前提条件:

1 至少有一个误删除之前的数据库完全备份。

2 数据库的恢复模式(Recovery mode)是“完整(Full)”。

针对这两个前提条件,会有三种情况:

情况一、如果这两个前提条件都存在,通过SQL语句只需三步就能恢复(参考文章),无需借助第三方工具。

a) 备份当前数据库的事务日志:BACKUP LOG [数据库名] TO disk= N'备份文件名' WITH NORECOVERY

b) 恢复一个误删除之前的完全备份:RESTORE DATABASE [数据库名] FROM DISK = N'完全备份文件名' WITH NORECOVERY, REPLACE

c) 将数据库恢复至误删除之前的时间点:RESTORE LOG [数据库] FROM DISK = N'第一步的日志备份文件名' WITH STOPAT = N'误删除之前的时间点' , RECOVERY

情况二、如果第1个前提条件不存在,第2个前提条件存在,需要借助第三方工具。

情况三、如果第2个前提条件不存在,无法恢复。所以,一定要将数据库恢复模式设置为“完整(Full)”。

我现在面临的是第二种情况,需要找第三方工具。

开始找的是Log Explorer for SQL Server,不支持SQL Server 2008。

后来找的是SQL Log Rescue,也不支持SQL Server 2008。

接着找到的是SysTools SQL Recovery,支持SQL Server 2008,但需要购买,Demo版并没有数据恢复功能。

最终在officerecoverycom上找到Recovery for SQL Server,虽然也是商业软件,需要购买,但Demo版可以恢复数据,只要数据库文件不超过24Gb。幸好朋友的数据库文件不大,用它完成了误删除数据的恢复。

下面分享一下用Recovery for SQL Server进行恢复的 *** 作步骤:

1 运行Recovery for SQL Server

2 点击菜单中的 File > Recover,选择要恢复的数据库的数据文件(mdf)

3 Next > Next,进入 Recovery Configuration 界面,选择Custom(选择了Custom才可以选择从日志中恢复误删除的数据)。

4 Next 进入 Recovery options 窗口,选中 Search for deleted records,并选择要恢复的数据库的日志文件路径(log file path)。

5 Next 并选择目标文件夹(Destination folder),用于存放恢复过程中生成的SQL语句与bat文件。

6 点击Start,开始恢复 *** 作(在上一步选择的目标文件夹中生成相应的SQL文件与Bat文件),然后,出现 SQL Server Database Creation Utility 窗口。

7 Next,选择被恢复数据存放的目标数据库。

8 Next, 选择 Import availiable data from both database and log files

9 Next, Next, 然后就完成数据的恢复!

可以采用以下方法Oracle数据导入导出imp/exp就相当于oracle数据还原与备份。exp命令可以把数据从远程数据库服务器导出到本地的dmp文件,imp命令可以把dmp文件从本地导入到远处的数据库服务器中。 利用这个功能可以构建两个相同的数据库,一个用来测试,一个用来正式使用。

执行环境:可以在SQLPLUSEXE或者DOS(命令行)中执行,

DOS中可以执行时由于 在oracle 8i 中 安装目录ora81BIN被设置为全局路径,

该目录下有EXPEXE与IMPEXE文件被用来执行导入导出。

oracle用java编写,SQLPLUSEXE、EXPEXE、IMPEXE这两个文件有可能是被包装后的类文件。

SQLPLUSEXE调用EXPEXE、IMPEXE所包裹的类,完成导入导出功能。

下面介绍的是导入导出的实例。

数据导出:

1 将数据库TEST完全导出,用户名system 密码manager 导出到D:daochudmp中

exp system/manager@TEST file=d:daochudmp full=y

2 将数据库中system用户与sys用户的表导出

exp system/manager@TEST file=d:daochudmp owner=(system,sys)

3 将数据库中的表inner_notify、notify_staff_relat导出

exp aichannel/aichannel@TESTDB2 file= d:datanewsmgntdmp tables=(inner_notify,notify_staff_relat) 4 将数据库中的表table1中的字段filed1以"00"打头的数据导出

exp system/manager@TEST file=d:daochudmp tables=(table1) query=" where filed1 like '00%'"

上面是常用的导出,对于压缩,既用winzip把dmp文件可以很好的压缩。

也可以在上面命令后面 加上 compress=y 来实现。数据的导入

1 将D:daochudmp 中的数据导入 TEST数据库中。

imp system/manager@TEST file=d:daochudmp

imp aichannel/aichannel@HUST full=y file=d:datanewsmgntdmp ignore=y

上面可能有点问题,因为有的表已经存在,然后它就报错,对该表就不进行导入。

在后面加上 ignore=y 就可以了。

2 将d:daochudmp中的表table1 导入

imp system/manager@TEST file=d:daochudmp tables=(table1)

你记得你的数据库文件(mdf)在哪个盘符么?sql系统文件没用的,主要是数据库文件。如果能找到数据库文件,用attachdb(附加数据库)就可以了,如果你的数据库文件找不到,就找备份吧。如果备份找不到,就没办法了。

以上就是关于数据库恢复的基本原理是利用什么重建数据库全部的内容,包括:数据库恢复的基本原理是利用什么重建数据库、oracle 中不完全数据库恢复的问题、sqlserver数据库数据被删除了怎么还原等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9788779.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存