数据库系统恢复

数据库系统恢复姓名:莫金博班级:2008级计算机1班学号:20086789摘要：本文主要介绍了数据库恢复的相关概念与SQL数据库恢复技术ORACLE数据库恢复技术关键字:数据库崩溃恢复、文件系统缓存和数据库恢复、备份恢复数据库、数据库恢复层次、SQL数据库恢复技术、ORACLE数据库恢复技术一、 数据库崩溃恢复一个运行着数据库系统的计算机随时都可能宕机。然而“已借未贷”或“已贷未借”的情况都可能出现。当系统崩溃后重启时，数据库管理系统必须允许这种可能性的发生，也就是说，在磁盘数据文件中可能包含一些部分完成的事务，在应用能够访问数据库数据之前，这些必须全部被检出。防止上述情况发生的基本技术就是保存一份连续日志，记录将做的和完成的操作。当需要修复损坏的数据库时，数据库系统重新应用这些日志，寻找那些将要执行但未完成的任务。如果任何类似的事务的已经在数据库中反映，这一定是颠倒的，并且数据库必须回滚。使用这种日志重新应用的技术，数据库系统可以避免宕机所带来的已接受事务（应用已确认执行完毕的事务）的丢失。数据修复时，那些在宕机时处理结果还存在缓存中的已接受事务，结果会存放到磁盘文件中。未接受事务（还没有被应用确认的事务）会被回滚，消除它所带来的对其他数据的影响。二、 文件系统缓存和数据库恢复如果使用文件作为数据库的数据存储方式会给我们的讨论增加一些额外的复杂性，因为文件管理系统有它自己的缓存。如果一个数据库系统在宕机后立刻重新启动，那么它所包含的文件可能并没有实时刷新到存储中，这是由于在系统宕机时，文件系统的缓存没有写入到存储的原因。在这种情况下，数据库恢复进程必须重新应用数据日志刷新。也就是说，在系统宕机的情况下已接受事务也不会丢失。从备份恢复数据库通过正规备份，并且快速的将备份介质运送到安全的地方，数据库就能够在大多数的灾难中得到恢复。恢复是文件的使用是从一个基点的数据库映像开始，到一些综合的备份和日志。由于不可预知的物理灾难，一个完全的数据库恢复（重应用日志）可以使数据库映像恢复到尽可能接近灾难发生的时间点的状态。对于逻辑灾难，如：人为破坏或者应用故障等，数据库映像应该恢复到错误发生前的那一点。在一个数据库的完全恢复过程中，基点后所有日志中的事务被重新应用，所以结果就是一个数据库映像反映所有在灾难前已接受的事务，而没有被接受的事务则不被反映。为了恢复数据库误操作等错误，完全的恢复时不合适的，因为如果重新应用所有事务，错误就会重复。数据库恢复应用程序允许管理员停止日志前滚在错误发生前一点。数据库恢复可以恢复到错误发生前的最后一个时刻。三、数据库恢复层次下面列出的数据库恢复技术是按照他们所能够提供的保护能力的顺序列出的，也同时是使用他们所需要的资金，方便程度，和技术复杂性的排列顺序。每一种技术都必须与他前面的技术共同使用。例如，磁盘镜像必须伴随着数据库备份和日志归档。1、正规数据库备份和日志归档磁盘镜像本地群集数据库复制2全局群集对于希望恢复时间（RTO）时间在几个小的内的企业，正规的数据库备份和日志归档也许就能满足。数据库备份和归档日志应该被保存在离数据中心有一定距离的地方。高级的备份软件的特性，如自动的定期的块增量备份可以减少管理成本，缩短备份窗口，以及最小化恢复时间。通过简单的镜像硬件和网络，镜像数据库存储dada减少了因为硬件故障所引起的数据库停机。也可以通过剥离镜像的备份提高数据库的可用性。可以通过群集技术提高数据库级信息服务的可用性。一个本地群集可以使由于系统的单点而出现故障的可能降到最小。当错误引起临时的损耗，服务恢复时自动的。在共享数据的群集中，损耗窗口可以为零。在群集中，备份可以运行在导入了数据库服务器镜像数据的辅助服务器上。为防止站点实效而进行的灾难恢复中，数据库必须复制到远程站点。数据库复制的最简单方法就是将归档日志传送到远端，然后在备用服务器上重新应用。这种技术丢失的数据数量是固定的。不能容忍在灾难中丢失数据的企业应该使用数据库或存储复制。最高的数据库可用性应该使用全局群集来完成，它在多个互相连接的站点中调整数据库和应用的可用程度。弹性数据库通过不同方法使用冗余拷贝。数据库可以通过额外的拷贝提高访问性能。存储数据库数据的磁盘可以被镜像来提高弹性。实时备份可以用来避免灾难和故障。事务日志可以使导致数据错误的时间前滚。最后，完全的数据镜像可以在远端保存一份数据来避免灾难。高级的数据库管理器可以自行分发它们所管理的数据以提高数据库弹性和性能。四、SQL数据库恢复技术SQLServer数据库备份有两种方式，一种是使用BACKUPDATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式。下面将主要讨论一下后者的备份与恢复。假定您能熟练使用SQLServerEnterpriseManager（SQLServer企业管理器）和SQLServerQuweyAnalyser（SQLServer查询分析器）1、正常的备份、SQL数据库恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。卸下数据库的命令：Sp_detach_db数据库名连接数据库的命令：Sp_attach_db或者sp_attach_single_file_dbs_attach_db[@dbname=]'dbname',[@filename1=]'filename_n‘[,...16]sp_attach_single_file_db[@dbname=]'dbnamez,[@physname=]'physical_namez使用此方法可以正确恢复SQLSever7.0和SQLServer2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。例子：假设数据库为test，其数据文件为test_data.mdf,日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。卸下数据库：sp_detach_db'test'连接数据库：sp_attach_db'test','C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_data.mdf','C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_log.ldf'sp_attach_single_file_db'test','C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_data.mdf'么只有mdf文件的恢复技术由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息设备激活错误。物理文件名'C:\ProgramFiles\MicrosoftSQLServer\MSSQL\data\test_Log.LDF'可能有误。已创建名为'C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_log.LDF'的新日志文件。但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器：消息1813，级别16,状态2,行1未能打开新数据库'test'。CREATEDATABASE将终止。设备激活错误。物理文件名’d:\test_log.LDF'可能有误。怎么办呢？别着急，下面我们举例说明恢复办法。A.我们使用默认方式建立一个供恢复使用的数据库 （如test）。可以在SQLServerEnterpriseManager里面建立。停掉数据库服务器。将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。设置数据库允许直接操作系统表。此操作可以在SQLServerEnterpriseManager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。usemastergosp_configure'allowupdates',1goreconfigurewithoverridegoF.设置test为紧急修复模式updatesysdatabasessetstatus=-32768wheredbid=DB_ID('test')此时可以在SQLServerEnterpriseManager里面看到该数据库处于“只读\置疑\脱机'紧急模式”可以看到数据库里面的表，但是仅仅有系统表G.下面执行真正的恢复操作，重建数据库日志文件dbccrebuild_log('test','C:\ProgramFiles\MicrosoftSQLServer\MSSQL\Data\test_log.ldf')执行过程中，如果遇到下列提示信息：服务器：消息5030，级别16，状态1，行1未能排它地锁定数据库以执行该操作。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQLServerEnterpriseManager打开了test库的系统表，那么退出SQLServerEnterpriseManager就可以了。正确执行完成的提示应该类似于：(警告：数据库'test'的日志已重建。已失去事务的一致性。应运行DBCCCHECKDB以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。此时打开在SQLServerEnterpriseManagerM面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。H.验证数据库一致性(可省略)dbcccheckdb('test')一般执行结果如下：CHECKDB发现了0个分配错误和0个一致性错误(在数据库'test'中)。DBCC执行完毕。如果DBCC输出了错误信息，请与系统管理员联系。I.设置数据库为正常状态sp_dboption'test','dbouseonly','false'如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQLServerEnterpriseManagerM面恢复，也可以使用如下语句完成sp_configure'allowupdates',0goreconfigurewithoverridego五、ORACLE数据库恢复技术1、 恢复的意义当我们使用一个数据库时，总希望数据库的内容是可靠的、正确的，但由于计算机系统的故障（硬件故障、网络故障、进程故障和系统故障）影响数据库系统的操作，影响数据库中数据的正确性，甚至破坏数据库，使数据库中全部或部分数据丢失。因此当发生上述故障后，希望能重新建立一个完整的数据库，该处理称为数据库恢复。恢复子系统是数据库管理系统的一个重要组成部分。恢复处理随所发生的故障类型所影响的结构而变化。2、 恢复的方法°1、IMPORT方法：利用IMPORT，将最后一次EXPORT出来的数据文件IMPORT到新的数据库中，这种方式可以将任何数据库对象恢复到它被导出时的状态，此后的变化将无法挽回。IMPORT的命令可以交互式进行，各参数的具体含义见ORACLEEXP/IMP参数详解。这种方式适用于没有采用archive模式的环境。Q、安全的恢复方法：如果数据库运行在archive模式下，那么一旦数据库损坏则可以通过冷备份（热备份）和归档备份将数据库恢复到断点状态。数据库控制文件恢复（假设所有控制文件均被破坏）：数据库基于文件系统：利用操作系统的tar、cp等命令即可。数据库基于裸设备：ddif=$ORACLE_BASE/con.bakof=/dev/rdrd/drd1seek=12数据库数据文件恢复数据及索引表空间、系统表空间的恢复：回拷相关的数据库文件和该数据文件备份以来所有生成的所有逻辑日志文件并执行如下命令：svrmgrl>startupmountsvrmgrl>alterdatabaserecoverautomatic如果控制文件被破坏，则：svrmgrl>alterdatabaserecoverusingbackupcontrofile;按照提示输入log文件名和redolog文件名svrmgrl>alterdatabaseopenresetlogs;数据库临时文件和回滚表空间的恢复：简单地offlinedrop并重建即可注意：如果数据库不运行在archive模式