下载文档原格式
oracle19c redolog 切换机制标题：Oracle 19c Redo日志切换机制：解析与实施步骤引言Redo日志是Oracle数据库系统中非常重要的组成部分，它记录了对数据库进行的重要操作，以便在发生故障时进行恢复。
在Oracle 19c版本中，改进了Redo 日志的性能和稳定性，并提供了一种新的Redo日志切换机制。
本文将逐步探讨Oracle 19c Redo日志切换机制的实施步骤，帮助读者更好地理解和使用这一功能。
1. Redo日志简介Redo日志是Oracle数据库的重要组成部分，它记录了数据库的变更操作，以便在发生故障时进行恢复。
Redo日志包含了数据库中发生的所有变更操作，例如插入、更新和删除操作，以及对索引和表空间的结构修改等。
通过不断地刷新Redo日志，Oracle数据库确保了数据的持久性和一致性。
2. Oracle 19c Redo日志切换机制的意义在之前的Oracle版本中，Redo日志切换是依靠日志组中的日志序列号的连续递增来实现的。
当当前日志组快要用完时，Oracle会自动切换到下一个可用的日志组并递增日志序列号。
然而，在高负载的数据库环境中，频繁的Redo日志切换可能导致性能下降，因为切换操作会引起额外的IO开销。
为了解决这个问题，Oracle 19c引入了新的Redo日志切换机制，该机制可以根据数据库的负载情况来进行切换，以最小化额外的IO开销。
这个新机制将在下面的步骤中详细解释。
3. 步骤一：启用自动切换在Oracle 19c中，需要先启用自动切换功能才能使用新的Redo日志切换机制。
可以通过以下命令启用自动切换：ALTER DATABASE ENABLE THREAD SPIN这个命令会开启一个线程监控数据库的负载情况，并在必要时触发Redo日志的切换。
4. 步骤二：配置自动切换的阈值在默认情况下，Oracle 19c使用了一组预定义的阈值来监控数据库的负载情况，然后触发Redo日志的切换。
oracle快照底层原理Oracle数据库中的快照（snapshot）是一种数据备份技术，它允许用户在一些时间点上创建数据库的一份完整副本，以便在需要时进行恢复或查询。
Oracle快照底层原理涉及到数据文件、redo日志和Undo段等核心组件，下面将详细介绍这些组件的作用和相互关系。
1. 数据文件（Data Files）：Oracle数据库将数据存储在数据文件中，其中包含表、索引等对象的数据和元信息。
数据文件是数据库的基本单位，每个表空间可以包含一个或多个数据文件。
快照的底层原理涉及到数据文件的备份和恢复。
2. Redo日志（Redo Log）：Redo日志是Oracle数据库中的一种事务日志，用于记录数据库的变化，包括数据修改操作和其他重要事件。
当数据库执行事务操作时，相关的变化会先写入Redo日志文件，然后再将修改写入数据文件。
通过Redo 日志，可以实现对数据库的完整恢复。
3. Undo段（Undo Segment）：Undo段是用于支持事务的回滚和数据一致性的关键组件。
当一个事务开始执行时，相关的变化会先写入Undo段。
如果事务需要回滚，数据库可以利用Undo段中的数据将变化恢复到事务开始之前的状态。
在Oracle数据库中，快照的底层原理可以分为两个主要过程：快照创建和快照恢复。
快照创建过程如下：1. 快照进程（Snapshot Process）：Oracle数据库通过一个后台进程来实现快照功能，该进程负责创建和管理快照。
2. 数据文件备份：快照创建时，Oracle会首先对数据文件进行备份，以保证快照的一致性和完整性。
这里的备份可以理解为创建数据文件的一个副本。
3. Redo日志备份：接下来，Oracle会备份Redo日志，以保证在需要恢复数据库时，可以使用快照创建时的Redo信息进行恢复操作。
4. Undo段备份：最后，Oracle会备份当前事务的Undo信息，这样在需要恢复数据时，可以使用保存的Undo段数据将相关事务的变化恢复到快照创建时的状态。
oracle redo详解标题，深入理解Oracle Redo日志。
Oracle数据库中的Redo日志是一个非常重要的概念，它对于数据库的持久性和恢复能力起着至关重要的作用。
在本文中，我们将深入探讨Oracle Redo日志的概念、作用以及相关的重要知识点。
Redo日志是Oracle数据库引擎中的一种重要的日志文件，它记录了数据库中发生的所有变更操作，如INSERT、UPDATE、DELETE 等。
它的作用主要有两个方面：1. 数据持久性，当数据库执行一条更新操作时，首先将变更记录到Redo日志中，然后再将变更应用到对应的数据文件中。
这样即使在数据库发生故障的情况下，可以通过Redo日志将丢失的数据重新应用到数据库中，从而保证数据的持久性。
2. 数据恢复，Redo日志还可以用于数据库的恢复操作。
当数据库发生故障需要进行恢复时，可以通过Redo日志中的记录来重新执行数据库中的变更操作，从而将数据库恢复到故障发生前的状态。
Redo日志的组成包括以下几个重要的组件：1. Redo日志文件，这是Redo日志的物理存储文件，通常位于数据库的数据目录中。
Redo日志文件的大小和数量可以通过数据库参数进行配置。
2. Redo日志缓冲区，这是一个内存区域，用于暂时存储待写入Redo日志文件的变更记录。
当数据库执行更新操作时，相关的变更记录首先被写入Redo日志缓冲区，然后由后台进程将其刷新到Redo日志文件中。
3. 日志切换，当Redo日志文件已满或者达到一定的时间间隔时，Oracle数据库会自动进行日志切换操作，即将当前正在写入的Redo日志文件切换为下一个可用的Redo日志文件。
这样可以保证Redo日志文件的循环使用，避免Redo日志文件无限增长导致存储空间不足。
总结来说，Oracle Redo日志是数据库中非常重要的一个组成部分，它对于数据库的持久性和恢复能力起着至关重要的作用。
通过深入理解Redo日志的概念、作用以及相关的重要知识点，可以更好地理解Oracle数据库引擎的工作原理，从而更好地管理和维护数据库系统。
作为Oracle DBA，我们有时候需要追踪数据误删除或用户的恶意操作情况，此时我们不仅需要查出执行这些操作的数据库账号，还需要知道操作是由哪台客户端（IP地址等）发出的。
针对这些问题，一个最有效实用而又低成本的方法就是分析Oracle数据库的日志文件。
本文将就Oracle日志分析技术做深入探讨。
一、如何分析即LogMiner解释从目前来看，分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行，Oracle数据库的所有更改都记录在日志中，但是原始的日志信息我们根本无法看懂，而LogMiner就是让我们看懂日志信息的工具。
从这一点上看，它和tkprof差不多，一个是用来分析日志信息，一个则是格式化跟踪文件。
通过对日志的分析我们可以实现下面的目的：1、查明数据库的逻辑更改；2、侦察并更正用户的误操作；3、执行事后审计；4、执行变化分析。
不仅如此，日志中记录的信息还包括：数据库的更改历史、更改类型（INSERT、UPDATE、DELETE、DDL等）、更改对应的SCN号、以及执行这些操作的用户信息等，LogMiner在分析日志时，将重构等价的SQL语句和UNDO语句（分别记录在V$LOGMNR_CONTENTS视图的SQL_REDO和SQL_UNDO中）。
这里需要注意的是等价语句，而并非原始SQL语句，例如：我们最初执行的是“delete a where c1 <>'cyx';”，而LogMiner重构的是等价的6条DELETE语句。
所以我们应该意识到V$LOGMNR_CONTENTS视图中显示的并非是原版的现实，从数据库角度来讲这是很容易理解的，它记录的是元操作，因为同样是“delete a where c1 <>'cyx';”语句，在不同的环境中，实际删除的记录数可能各不相同，因此记录这样的语句实际上并没有什么实际意义，LogMiner重构的是在实际情况下转化成元操作的多个单条语句。
oracle关于归档⽇志和redo⽇志问题
使⽤⽤友NC的软件，后台oracle数据库已经使⽤了2年多了，⼀直没有搞清楚redo，归档⽇志是怎么回事。
先来个理论性的知识学习，在深⼊学实际使⽤。
重做⽇志redo log file是LGWR进程从Oracle实例中的redo log buffer写⼊的，是循环利⽤的。
就是说⼀个redo log file(group) 写满后，才写下⼀个。
归档⽇志archive log是当数据库运⾏在归档模式下时，⼀个redo log file(group)写满后，由ARCn进程将重做⽇志的内容备份到归档⽇志⽂件下，然后这个redo log file(group)才能被下⼀次使⽤。
不管数据库是否是归档模式，重做⽇志是肯定要写的。
⽽只有数据库在归档模式下，重做⽇志才会备份，形成归档⽇志。
归档⽇志结合全备份，⽤于数据库出现问题后的恢复使⽤。
oracle逻辑日志解析原理
Oracle逻辑日志解析原理涉及到数据库的日志文件和恢复机制。
Oracle数据库采用了逻辑日志（Redo Log）来记录对数据库的所有
更改操作，以便在发生故障时进行恢复。
逻辑日志解析原理可以从
以下几个方面来解释：
1. Redo Log的作用，逻辑日志是一种物理结构，它记录了数
据库中发生的所有更改操作，包括插入、更新和删除操作。
当数据
库发生故障时，可以利用逻辑日志进行恢复，保证数据的一致性和
完整性。
2. 日志记录格式，逻辑日志中的记录采用了一种特定的格式，
包括操作类型、受影响的数据块、事务ID等信息。
解析逻辑日志需
要根据这些信息来还原出数据库的操作过程。
3. 日志解析过程，在数据库发生故障时，系统会首先将逻辑日
志中的记录应用到数据库中，以还原出故障发生前的数据库状态。
这个过程就是逻辑日志的解析过程，它需要按照一定的顺序和规则
来应用日志记录，以确保数据库的一致性。
4. 恢复机制，逻辑日志解析原理也涉及到数据库的恢复机制，包括崩溃恢复和介质恢复。
在崩溃恢复中，数据库会利用逻辑日志来还原出故障发生前的状态；在介质恢复中，数据库管理员可以利用逻辑日志来进行点对点的恢复操作。
总之，Oracle逻辑日志解析原理涉及到数据库的日志记录、格式、解析过程和恢复机制等多个方面，需要结合数据库的架构和运行机制来全面理解。
这些内容对于数据库管理员和开发人员来说都是非常重要的，可以帮助他们更好地理解数据库的运行原理和故障处理机制。
oracle主从复制原理Oracle主从复制简介•什么是Oracle主从复制?•主从复制的作用和优点•本文将深入解析Oracle主从复制的相关原理原理解析主从复制的基本概念•主从复制是一种常见的数据库复制技术，它通过将一个数据库的变更复制到其他数据库中，实现数据的同步和备份。
主从复制的流程1.主库产生的变更日志被捕捉2.变更日志被传送到从库3.从库根据变更日志进行数据更新，实现数据库的同步主从复制的角色•主库 (Master)•从库 (Slave)主从复制的工作原理1.主库记录日志 (Redo Log)：将所有对数据库的变更操作记录到日志中2.从库请求日志 (Archiver)：从库通过请求主库的日志，将日志传送到自己的环境中3.从库重放日志 (Recovery)：从库通过重放主库的日志，将日志中的操作在自己的数据库进行执行主从复制的数据同步方式•基于物理的主从复制•基于逻辑的主从复制物理复制 vs 逻辑复制•物理复制：基于数据库的物理备份和日志传输，将改变转发到从库进行执行•逻辑复制：通过逻辑日志记录和重放，将改变在从库上进行重演主从复制的数据一致性•强一致性：在所有从库上重演的操作是按照主库上的顺序依次进行的•弱一致性：不同从库上重演的操作可能出现顺序不同的情况总结•主从复制是一种常见的数据库同步和备份技术，通过将主库的变更复制到从库实现数据的同步。
•主从复制可以基于物理备份和日志传输，也可以基于逻辑日志记录和重放。
•主从复制可以保证数据一致性，但在多从库的情况下，可能出现弱一致性的情况。
以上是对Oracle主从复制的相关原理的深入解析，通过这篇文章的阅读，相信读者对于Oracle主从复制会有更深入的了解。
Oracleredo与undoUndo and redoOracle最重要的两部分数据，undo 与redo，redo（重做信息）是oracle在线（或归档）重做⽇志⽂件中记录的信息，可以利⽤redo重放事务信息，undo（撤销信息）是oracle在undo段中记录的信息，⽤于撤销或回滚事务。
1 redo重做⽇志⽂件redo log，是数据库的事务⽇志，oracle维护着2类重做⽇志，在线重做⽇志⽂件和归档重做⽇志⽂件，归档⽇志⽂件就是重做⽇志的副本，系统将⽇志⽂件填满时arch进程会在另⼀个位置建⽴⼀个在线重做⽇志的副本每个oracle数据库⾄少有2个重做⽇志组，以便切换⽇志，每个⽇志组⾄少有1个⽇志组成员，这些在线重做⽇志⽂件是以循环写的⽅式使⽤，2 undo你对数据库执⾏修改时，数据库会⽣成undo信息，以便回滚到更改前的状态，undo⽤于取消⼀条语句或⼀组语句的作⽤，undo在数据库内部存放在⼀组特殊的段中，为undo段（回滚段 rollback segment），利⽤undo，数据库只是逻辑的恢复到原来的样⼦，所有修改都逻辑的取消，但是数据结构以及数据块本⾝在回滚后可能不⼤相同，对于undo⽣成对于直接路径操作不适⽤，直接路径操作能够绕过表上的undo⽣成。
SQL>set autotrace traceonly statisticsSQL>select*from t;--not first executeno rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets3 consistent gets0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedSQL>insert into t select*from all_objects;49789 rows created.SQL>rollback;Rollback complete.SQL>select*from t;no rows selectedStatistics----------------------------------------------------------0 recursive calls0 db block gets689 consistent gets -----I/O0 physical reads0 redo size995 bytes sent via SQL*Net to client374 bytes received via SQL*Net from client1 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)0 rows processedInsert导致⼀些块增加到表的⾼⽔位线(HWM),这些块没有因为回滚⽽消失，select extent_id, bytes, blocks from user_extentswhere segment_name = 'X' order by extent_id; 分配给表的存储空间—这个表没有使⽤任何区段3 undo 跟redo如何协作尽管undo信息存储在undo表空间或undo段中，但也会受到redo保护，会把undo信息当成表数据或索引数据⼀样，对undo的修改会⽣成⼀些redo，将记⼊重做⽇志，将undo数据增加到undo段中，并像其他部分的数据⼀样，在缓冲区缓存中得到缓存Insert-update-delete场景3.1 insertInsert语句，都会⽣成redo跟undo信息，插⼊发⽣后，如下图缓存了⼀下已修改的undo块，索引块和表数据块，这些块得到重做⽇志缓冲区相应条⽬的保护1假象现在系统崩溃，sga全部被清空，但是我们不需要sga的中的任何内容，重启动时就好像这个事务就没发⽣过，没有将任何修改的块刷新输出到磁盘，也没有任何redo信息刷新输出到磁盘，我们不需要这些undo或redo信息来实现实例失败恢复2假象：缓冲区缓存已满Dbwr进程要把已修改的块从缓存输出到磁盘，⾸先要求lgwr进程将保护这些数据库的redo条⽬输出到磁盘，dbwr在将任何修改的块输出到磁盘之前，都必须要求lgwr进程先刷新输出到redo⽇志，3.2 updateUpdate所带来的⼯作与insert⼤体⼀样，不过undo信息量更⼤，update，要保存系统的前映像，缓冲区中会有更多的undo块，为了撤销update，如果必要，已修改的数据库表和索引都会存在缓存中，其中重做⽇志有的已经输出到磁盘，有的还在redo buffer 中1 系统崩溃：启动时，oracle会读取重做⽇志，给定系统的当前状态，利⽤重做⽇志⽂件中对应的插⼊的redo条⽬，并利⽤仍在缓冲区中对应的redo条⽬，oracle会前滚插⼊，连接断开，oracle发现事务从未提交，因此将其回滚，利⽤undo，2 应⽤回滚事务Oracle发现这个事务的undo信息可能缓存在undo段中，也肯能已经刷新输出到磁盘，会把und信息应⽤到缓存中的数据和索引上，不在缓存中，则先要读⼊到缓存，恢复其原来的⾏，并刷新输出数据⽂件，回滚过程不涉及重组⽇志，只有恢复和归档才会读取重做⽇志，重做⽇志是⽤来写的，不⽤于读，3 deleteDelete 会⽣成undo⽇志，块将被修改，并把redo⽇志发送到重做⽇志缓冲区，与update类似4 commit已经修改的块放在缓冲区缓存中，可能已经输出到磁盘，重做这个事务所需的全部redo都安全的存放在磁盘上，undo信息会⼀直存在，除⾮undo段回绕并重⽤了这些undo块，4 提交和回滚处理Commit：commit并没有做太多的⼯作，Commit开销，频繁提交，会增加与数据库的往返同学，如果每个记录都提交，⽣成的往返通信量会⼤得多，每次提交时，必须等待redo写到磁盘，这会导致等待在commit之前可能：已经在sga中⽣成了undo 块，已经在sga中⽣成了已修改的数据块，已经在sga中⽣成了对应的2想的redo信息，取决于前3项的⼤⼩，已经这些花费的时间，前⾯的数据可能已经输出到磁盘，已经得到全部锁需要的锁在实际commit时， 1为事务⽣成⼀个scn（系统改变号），scn⽤于保证事务的顺序，并⽀持失败恢复，scn还⽤于保证数据库中的读⼀致性和检查点，每次有⼈commit，scn都会增加1。
oracle 日志归档原理Oracle数据库日志归档（Archive Log Mode）是数据库管理系统中用于实现数据库可恢复性的重要机制。
在归档模式下，Oracle数据库会将已填满的联机重做日志文件的内容复制到单独的归档日志文件中，并且只有在当前的日志内容被安全地归档后，才会覆盖或重新使用这些联机重做日志。
以下是Oracle日志归档的基本原理：1.联机重做日志：•Oracle数据库运行时会产生一系列的联机重做日志文件（Online Redo Logs），这些文件按照日志组的方式组织，每个日志组内包含一个或多个日志成员。
•当数据库执行事务处理时，所有对数据库的修改都会以重做记录的形式写入当前活动的日志组中。
2.日志切换：•随着数据库操作的进行，当前日志组填满后，会触发日志切换（Log Switch），即系统开始往下一个日志组中写入新的重做记录。
•在非归档模式下，旧的日志组可以被覆盖和重复使用；而在归档模式下，必须先将旧日志组的内容归档才能进行切换。
3.归档过程：•归档是由后台进程ARCn (Archiver) 自动完成的，或者管理员可以通过手动方式将填满的联机重做日志文件复制到指定的归档位置。
•归档日志文件具有与原始联机日志相同的逻辑内容，并带有唯一的日志序列号（Log Sequence Number, LSN），以便在恢复过程中确定应用重做记录的顺序。
4.作用：•在发生故障需要恢复数据库时，通过应用归档日志中的重做记录，可以将数据库状态恢复到故障发生前的任意时间点（Point-in-Time Recovery, PITR）。
•对于数据库镜像、数据保护以及维护高可用性环境如Data Guard（物理/逻辑standby数据库）也是至关重要的。
Oracle日志(redo)机制探讨
【摘要】oracle数据库的redo机制是保障数据安全和故障恢复的至关重要的手段，也是对数据库性能影响非常巨大的关键因素。
通过对oracle日志机制的探讨可以帮助数据库管理员更好的理解、维护oracle数据库。
【关键词】redo checkpoint 事务恢复
一、redo原理
计算机系统中最容易出现瓶颈的就是磁盘的I/O操作。
Oracle通过批量方式将buffer cache（数据缓冲区）中发生变更的“脏”数据块写入数据文件。
这样减少了低效率的离散写磁盘操作，大大减轻了磁盘I/O的压力。
通过将buffer cache中的变更后的数据延迟写入数据文件，提升了数据库的性能，但也带来了数据丢失的风险。
为了保证buffer cache中的“脏”数据块在系统发生故障时不丢失，oracle要将这些数据块的变更记录下来，并及时写入日志。
即使系统发生故障，oracle通过日志中记录的redo信息可以将数据块发生的变化过程重演，这样就可以将数据库恢复到故障前的最后时刻。
二、日志文件
为了保证redo信息及时写入日志文件，oracle的lgwr（写
日志进程）非常活跃。
为了避免磁盘缓冲带来的滞后风险Lgwr采用了直接写磁盘（direct IO）的方式将redo信息直接写入文件。
触发lgwr的条件很多：每3秒钟；事务提交（commit）；redo log buffer（日志缓存区）1/3满或有1MB 数据；dbwr（写数据文件进程）启动时发现“脏”数据库对应的redo信息未写入日志。
Oracle的日志文件是循环使用的，所以至少要两个日志组。
为保障日志文件安全，每组日志可以有多个镜像（多镜像会增加lgwr的负担）。
当一个日志文件写满后，会切换到另一个日志文件（log switch）。
切换日志会触发检查点（checkpoint）事件，通知dbwr进程将写满的日志文件中保护的数据块写入数据文件。
在checkpoint完成之前，该日志文件是不能被覆盖重用的。
因此，日志文件通常会有current （当前）、active（checkpoint未完成）、inactive（checkpoint 已完成）三种状态。
如果是新添加的日志文件或者数据库resetlogs（重置），日志文件的状态为unused（未使用）。
当日志文件切换频繁时，就会发生因日志文件处于active状态而无法切换的问题，此时数据库处于“挂起”状态，等待checkpoint完成，Alert文件中会记录：checkpoint not complete。
发生这种问题对系统性能影响非常大，严重的甚至会导致业务中断。
通常数据库管理员会采取增加日志文件大小、增加日志组数这两种方法来应对。
日志文件对数据库的影响是非常巨大的，尤其是current 日志文件如果发生损坏，丢失数据就无法避免。
日志文件越大，就意味着越多的数据有丢失的风险。
因此，从保障数据安全、减少发生故障时的数据损失的角度来看，只要不发生checkpoint not complete，日志文件应越小越好。
所以，采用小日志文件、多日志组的方式可以较好的解决数据库系统的安全和性能的冲突。
但是日志文件的切换、归档也会消耗系统资源，小日志文件在业务高峰期会发生频繁切换，对系统性能的影响不可小觑。
因此，很多情况下数据库管理员会依据业务高峰时段的日志产生量来决定日志文件的大小。
但业务高峰期和空闲期的数据变更量差别非常大，满足业务高峰期的日志文件大小对业务空闲时段来说就显得太大了，会出现日志文件很长时间都不切换的现象。
而不切换、归档的日志就存在着损坏的风险，时间越长风险就越大。
针对此问题，笔者采用了通过设置archive_lag_target参数的手段来强制数据库进行日志切换。
archive_lag_target参数设定的是日志切换时间（单位为秒），默认值为0（不启用）。
启用该参数后，即使日志文件未写满，只要达到时间限制就强制切换日志。
通常建议archive_lag_target参数设定不小于20分钟，但过长也失去了保护数据的意义（笔者建议不超过90分钟）。
三、减少redo
Redo机制保障了oracle数据库的故障恢复能力，提高了
系统的稳定性。
所以，在正常情况下数据库发生变更都会产生redo。
但在某些特殊情况下，减少redo的产生可以极大的提高数据库的性能，对提升应用系统的工作效率具有重要意义。
笔者在这里对一些常用的减少redo产生的操作方式给予简单介绍。
（一）直接路径（direct path）批量insert数据
在SQL语句中增加/*+append*/提示，在非归档模式下运行的oracle数据库会不产生数据块变更的redo。
注意：这种方式对在归档模式下运行的数据库需要将插入数据的表的
模式改为nologging才有效。
举例insert /*+append*/ into test select * from t1
直接路径批量插入数据只是不产生insert的redo，但如果表上加有索引，insert数据的过程中系统会及时更新索引，这个操作会产生redo。
对此可以先将索引删除（drop），insert 数据完成后再创建索引。
如果采用nologging方式创建索引，则可以将创建索引的redo减少。
（二）nologging创建表和索引
创建表的同时采用直接路径append数据。
例如create table test nologging as select * from t1
创建索引的语句后面加上nologging即可。
（三）补充
不产生redo的操作方式如果对数据字典发生了修改仍
然会产生日志，这是Oracle为了保障数据库的安全和一致性采取的必要手段。
这也是在采用上述方式操作后，oracle有时仍然会产生少量日志的原因。
为保障数据安全，建议对nologging操作之后立即对数据库进行数据备份（不是日志备份）。
四、结束语
Oracle数据库的redo机制是一个非常有特色的技术亮点，对数据库的性能也影响非常大。
掌握这个机制并根据系统的实际情况加以利用对数据库管理员来说非常具有实用价值。
