数据库的三种恢复方式？sql数据库还原

各位老铁们好，相信很多人对数据库的三种恢复方式都不是特别的了解，因此呢，今天就来为大家分享下关于数据库的三种恢复方式以及sql数据库还原的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

数据库恢复的数据库恢复的三种方式

数据库可能因为硬件或软件（或两者同时）的故障变得不可用，不同的故障情况需要不同的恢复操作。我们必须决定最适合业务环境的恢复方法。在数据库中恢复有3种类型或方法，即应急（crash）恢复、版本（version）恢复和前滚（rool forward）恢复。应急恢复用于防止数据库处于不一致或不可用状态。数据库执行的事务（也称工作单元）可能被意外中断，若在作为工作单位一部分的所有更改完成和提交之前发生故障，则该数据库就会处于不一致和不可用的状态。这时，需要将该数据库转化为一致和可用的状态。

为此，需要回滚未完成的事务，并完成当发生崩溃时仍在内存中的已提交事务。如在COMMIT语句之前发生了电源故障，则在下一次重新启动并再次访问该数据库时，需要回滚到执行COMMMIT语句前的状态。回滚语句的顺序与最初执行时的顺序相反。这种恢复技术是版本恢复的一个扩展，使用完整的数据库备份和日志相结合，可以使一个数据库或者被选择的表空间恢复到某个特定时间点。如果从备份时刻起到发生故障时的所有日志文件都可以获得的话，则可以恢复到日志上涵盖到的任意时间点。前滚恢复需要在配置中被明确激活才能生效。

数据库备份主要包括哪三种方式

全量备份是指对某一时间点上的所有数据进行全量备份，包括系统和所有数据。这种备份方式每次都需要对系统和所有数据进行一次全量备份。这种备份方式最大的好处就是在恢复丢失数据时，只需要对一个完整的备份进行操作就能够恢复丢失数据，大大加快了系统或数据恢复的时间。

增量备份即在第一次全量备份的基础上，分别记录每次的变化。由于增量备份在备份前会判断数据是否发生变化，并仅记录每次变化情况，所以相较于其他两种备份方式它最大的好处在于其所需存储空间最少的（相同的变化情况下），备份速度最快的。当然在数据还原上来说，它的恢复时间是最长的，效率较低。恢复数据时，需要在第一次完备的基础上，整合每次的一个变化情况。

差异备份就是在第一次全量备份的基础上，记录最新数据较第一次全量备份的差异。简单来说，差异备份就是一个积累变化的过程。因此，恢复系统或者数据时，只需要先恢复全量备份，然后恢复最后一次的差异备份即可完成。所以差异备份占用的储存空间和所需恢复时间介于全量备份和增量备份之间。

十大数据库备份和恢复方法

一般的文件型数据库，实际上对整个就是一个或者多个文件，所谓的备份就是把这些文件考虑到其它介质上，可能有一个打包的过程，或者刻录到DVD的过程。这是对文件型数据库备份和恢复的最好方法，效率最好，操作最简单。

有的大型数据库，它自己管理存储空间，是分区或者磁盘，不被操作系统识别。这类数据库一样可以用GHOST等工具备份磁盘。

可能许多人讲备份数据库是把数据库转换为SQL或者文本文件。其实这是另外一个概念，叫做数据迁移，目的是把数据库的数据移植到其它数据库管理系统。数据迁移不适合用来做数据库的日常备份，一般关键数据库不会平凡的做数据迁移。一般数据库系统会提供专门的数据迁移工具，当然这类工具也可能就是一系列的SQL语句，自己也能编写。

1.打开块检查(block checking)这样做的目的是为了及早的发现数据库中的坏块。会有些性能开销，但是可以发现由于底层磁盘、存储系统或I/O系统的问题导致的坏块。 SQL alter system set db_block_checking= true scope=both;

2.用rman备份时打开块跟踪(10g以上)块跟踪文件包含用于增量备份的位图。每一个位表示一个extent，因此仅仅那些被修改的extent才会被读取并备份。如果没打开块跟踪，那么所有的块必须都被读取，以确定是否已经上次备份后被修改过。 SQL alter database enable block change tracking using file'/u01/oradata/ora1/change_tracking.f';

3.镜像日志组成员。并且有1个以上的归档位置如果一个在线日志成员被删除或损坏，那么另一个成员可以用于恢复。如果归档日志文件损坏或丢失，那么其他归档位置的副本仍然可以使用。 SQL alter system set log_archive_dest_2='location=/new/location/archive2' scope=both;SQL alter database add logfile member'/new/location/redo21.log' to group 1;

4.备份时使用 check logical选项这会让rman检查块中的逻辑损坏以及头尾校验，这是获得良好备份的最好方式。 RMAN backup check logical database plus archivelog delete input;

5.测试你的备份做任何操作都不如实际恢复一次数据库。这是最好的确定你的备份在关键时刻是否良好可用的最佳方法。 RMAN restore validate database;

6.每个数据文件在一个单独的备份片中做部分恢复时rman必须读取整个备份片和必须的归档日志。备份片越小恢复越快。这对大型数据库的磁带备份或仅恢复单个(或几个)文件时特别重要。 RMAN backup database filesperset 1 plus archivelog delete input;

7.维护 rman的恢复目录和控制文件仔细选择你的保留政策。确保它涵盖了你的磁带系统保留策略以及备份恢复策略的需求。如果没使用恢复目录，确保参数control_file_record_keep_time匹配你的保留策略。 SQL alter system set control_file_record_keep_time=21;备份记录将保留21天。执行常规的恢复目录维护删除过期的内容将移走超过保留策略的备份，如果过期备份没被删除，恢复目录会增长直至性能出现问题。 RMAN delete obsolete;校验恢复目录或控制文件中内容与物理的备份匹配。如果备份片丢失，将被置为'EXPIRED'状态，恢复时它将没有资格，更早的备份将被使用。删除过期备份需要使用以下命令。 RMAN crosscheck backup;RMAN delete expired backup;

8.预防控制文件丢失这将确保您始终具备最新controlfile的可用。 RMAN configure controlfile autobackup on;保留备份日志。备份日志包含您的磁带访问的参数，控制文件备份的位置，如果数据库完全丢失时这些信息会很有用。

9.测试你的恢复在恢复场合，会让你知道恢复将怎样执行。并且能避免再次恢复原数据文件。 SQL recover database test;SQL RECOVER TABLESPACE sales TEST;

10.在备份归档时不要使用delete all input DELETE INPUT将从第一个归档位置删除日志。它也将删除从先前备份以来的第二个归档位置的日志。备份并删除指定位置的归档backup archivelog until time'sysdate-7' like'/u04/oracle/admin/TEST/arch/%' deleteinput;如果归档文件备份到多个目标位置，而且不同位置保留策略不同，可以如下操作：run{ backup archivelog all; delete archivelog until time'sysdate-1' like'/am3/oradata/arch/%';delete archivelog until time'sysdate-5' like'/am3/oradata/arch1/AM3P2/%';} rman备份和删除归档文件按数字顺序从_dest_1到_dest_10执行。如果存在闪回区，rman总是首先从闪回区进行备份和删除。在恢复过程中RMAN将检查所有的归档目的地，以确保需要的归档日志已经不存在。如果归档日志已经存在RMAN的目的地之一，将无法恢复该文件。恢复归档日志到asm中的闪回区RMAN run{ allocate channel c1 type'sbt_tape';set archivelog destination to'+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_13';restore archivelog from time"to_date('13/08/2010：00：00：00'，'dd/mm/yyyy：hh24：mi：ss')" until time"to_date('14/08/2010：00：00：00'，'dd/mm/yyyy：hh24：mi：ss')";}+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_13 ASMCMD ls-ltr Type Redund Striped Time Sys Name N 1_94528_708660567.dbf=+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94528.5341.727224533 N 1_94529_708660567.dbf=+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94529.3425.727224661 N 1_94530_708660567.dbf=+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94530.5644.727224779

关于数据库的三种恢复方式，sql数据库还原的介绍到此结束，希望对大家有所帮助。