下载文档原格式
redolog和归档⽇志重做⽇志redo log file是LGWR进程从Oracle实例中的redo log buffer写⼊的，是循环利⽤的。
就是说⼀个redo log file(group) 写满后，才写下⼀个。
archive log是当数据库运⾏在归档模式下时，⼀个redo log file(group)写满后，由ARCn进程将重做⽇志的内容备份到⽂件下，然后这个redo log file(group)才能被下⼀次使⽤。
不管数据库是否是归档模式，重做⽇志是肯定要写的。
⽽只有数据库在归档模式下，重做⽇志才会备份，形成。
⼀般来说，归档⽇志结合全备份，⽤于数据库出现问题后的恢复使⽤。
重做⽇志是循环使⽤的。
⽐如说，有三个A、B、C。
那么，当A写满后，系统就调⽤ARCn进程，将A备份为归档⽇志，同时B已经开始使⽤了。
假设你只有两个组A、B，如果某种情况下，A正在备份，未结束，还不能继续使⽤，⽽B也写满了，这个时候，数据库就会出现挂起的情况。
所以⼀般情况下，重做⽇志最好是三个组或者再多⼀点，⽽且⼤⼩要适当。
实际上，⼀个满了后，就开始写⼊归档⽇志。
不是等ABC都写满了，再归档，这样肯定就是出现挂起的情况了，Oracle不是这样的，归档⽇志和重做⽇志都是物理上的⽂件，只是存放的⽬录不同，⽽且重做⽇志的⽂件名不变，⽽归档⽇志的⽂件名是备份时系统⽣成的。
重做⽇志备份为归档⽇志后，系统就会把重做⽇志的内容清空，但⽂件依然存在，准备下⼀次使⽤。
重做⽇志纪录了你所有做过的dml语句，重做⽇志循环使⽤，写满⼀轮后就要覆盖前⾯的。
如果你是⽤热备模式，当重做⽇志写满⼀个后就将内容写⼊归档⽇志，以备将来恢复数据⽤。
只有数据库运⾏在归档模式并且参数ARCHIVE_LOG_START等于TRUE时，ARCn进程才能被启动，进⾏⾃动归档。
如果数据库运⾏在归档模式但ARCHIVE_LOG_START等于FALSE时，需要DBA⼿⼯归档。
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日志的切换。
recover 数据恢复方法嘿，咱今儿就来说说这 recover 数据恢复方法！你可别小瞧了这事儿，有时候啊，数据就跟咱的宝贝似的，不小心丢了那可真叫一个抓心挠肝呐！想象一下，你精心写好的文档，存了好久的照片，还有那些重要的工作资料，突然有一天就找不着了，是不是感觉天都要塌了？这时候，要是能有办法把它们找回来，那可真是太好了！首先呢，咱得养成备份的好习惯。
就跟咱每天要吃饭睡觉一样，定期给数据整个备份，这就相当于给它们上了一道保险。
你可以把数据备份到云端啊，或者是移动硬盘之类的地方。
这样就算电脑出了啥问题，咱还有备份可以依靠。
要是真不小心弄丢了数据，也别慌。
可以先去电脑的回收站里找找看，说不定它们就乖乖躺在那儿等你带它们回家呢。
要是回收站里没有，那就得动真格的了。
有一些数据恢复软件可以派上用场啦！就像个神奇的小魔法师，能把那些看似消失不见的数据给变回来。
不过用这些软件的时候可得注意哦，要找那些靠谱的，可别随便找个来路不明的，不然弄不好数据没找回来，还惹了一身麻烦。
还有啊，如果是存储设备出了问题，比如硬盘坏了啥的，那可就有点棘手了。
这时候最好找专业的人来帮忙，他们有专业的工具和技术，就像医生给病人看病似的，能更准确地找到问题所在，把数据给救回来。
咱平时也得注意保护好自己的设备，别磕了碰了，也别让它们沾到水啊啥的。
就像咱爱护自己的宝贝一样爱护它们，这样它们才能好好地为咱服务，也不容易出问题。
说真的，数据恢复这事儿可大可小，关键时候真能救急呢！咱可不能不当回事儿。
平时多留意，多小心，真遇到问题了也别慌，总有办法解决的嘛！你说是不是？所以啊，大家可得把这些方法记好了，说不定哪天就能派上大用场呢！可别等到数据丢了才后悔莫及呀！。
仅仅丢失一个普通用户数据文件的恢复A(联机恢复)（例如，丢失D:\BACKUPDB\USERS01.DBF）准备工作, 通过下面的工作，如果完全恢复，应该可以看到；insert into test1 values(2);SQL> conn lunar/lunarSQL> select * from tab;TESTBACKUP3 TABLESQL> create table test1 (a number);SQL> insert into test1 values(1);SQL> alter system switch logfile;SQL> commit;SQL> alter system switch logfile;SQL> insert into test1 values(2);SQL> commit;SQL> alter system switch logfile;SQL> conn internalSQL> archive log list数据库日志模式存档模式自动存档启用存档终点d:\BACKUPDB\archive最早的概要信息日志序列3下一个存档日志序列5当前日志序列5shutdown abort关闭例程，模拟数据文件丢失SQL> shutdown abortORACLE 例程已经关闭。
Mount数据库SQL> startup mount数据库装载完毕。
使损坏的数据文件脱机SQL> alter database datafile 'D:\BACKUPDB\USERS01.DBF' offline;打开数据库SQL> alter database open;拷贝刚才热备的数据文件（USERS01.DBF）恢复损坏的数据文件SQL> recover datafile 'D:\BACKUPDB\USERS01.DBF';ORA-00279: ?? 424116 (? 10/20/2002 20:42:04 ??) ???? 1 ????ORA-00289: ??: D:\BACKUPDB\ARCHIVE\BACKUPT001S00001.ARCORA-00280: ?? 424116 ???? 1 ???? # 1 ???指定日志: {<RET>=suggested | filename | AUTO | CANCEL}autoORA-00279: ?? 424125 (? 10/20/2002 20:44:14 ??) ???? 1 ????ORA-00289: ??: D:\BACKUPDB\ARCHIVE\BACKUPT001S00002.ARCORA-00280: ?? 424125 ???? 1 ???? # 2 ???ORA-00278: ??????????? 'D:\BACKUPDB\ARCHIVE\BACKUPT001S00001.ARC' ……………………..已应用的日志。
MySQL系列之redolog、undolog和binlog详解事务的实现redo log保证事务的持久性，undo log⽤来帮助事务回滚及MVCC的功能。
InnoDB存储引擎体系结构redo logWrite Ahead Log策略事务提交时，先写重做⽇志再修改页；当由于发⽣宕机⽽导致数据丢失时，就可以通过重做⽇志来完成数据的恢复。
InnoDB⾸先将重做⽇志信息先放到重做⽇志缓存按⼀定频率刷新到重做⽇志⽂件重做⽇志⽂件：在默认情况，InnoDB存储引擎的数据⽬录下会有两个名为ib_logfile1和ib_logfile2的⽂件。
每个InnoDB存储引擎⾄少有1个重做⽇志⽂件组(group)，每个⽂件组下⾄少有2个重做⽇志⽂件。
下⾯图⼀，很好说明重做⽇志组以循环写⼊⽅式运⾏，InnoDB存储引擎先写ib_logfile1，当达到⽂件最后时，会切换⾄重做⽇志⽂件ib_logfile2.⽽图2，增加⼀个OS Buffer，有助于理解fsync过程。
关于log group，称为重做⽇志组，是⼀个逻辑上的概念。
InnoDB存储引擎实际只有⼀个log group。
log group中第⼀个redo log file，其前2KB部分保存4个512字节⼤⼩块：重做⽇志缓冲刷新到磁盘下⾯三种情况刷新：Master Thread每⼀秒将重做⽇志缓冲刷新到重做⽇志⽂件每个事务提交时会将重做⽇志缓冲刷新到重做⽇志⽂件当重做⽇志缓冲池剩余空间⼩于1/2时，重做⽇志刷新到重做⽇志⽂件补充上述三种情况第⼆种，触发写磁盘过程由参数innodb_flush_log_at_trx_commit控制，表⽰提交(commit)操作时，处理重做⽇志的⽅式。
参数innodb_flush_log_at_trx_commit有效值有0、1、20表⽰当提交事务时，并不将事务的重做⽇志写⼊磁盘上⽇志⽂件，⽽是等待主线程每秒刷新。
1表⽰在执⾏commit时将重做⽇志缓冲同步写到磁盘，即伴有fsync的调⽤2表⽰将重做⽇志异步写到磁盘，即写到⽂件系统的缓存中。
redo log的刷盘策略redo log是MySQL中用于保证数据的持久性和一致性的重要组成部分。
它记录了数据库中发生的所有修改操作，以便在系统崩溃或意外故障时进行恢复。
在MySQL中，redo log的刷盘策略是如何工作的呢？我们需要了解什么是redo log。
redo log是一组物理日志文件，用于记录在数据库中对数据进行的修改操作。
当用户执行一条修改数据的语句时，MySQL会先将修改操作记录到redo log中，然后再将修改操作应用到内存中的数据页中。
这样做的好处是，即使系统崩溃或意外故障，数据库也能通过redo log进行恢复，保证数据的一致性。
redo log的刷盘策略是指将redo log日志文件中的数据写入磁盘的策略。
在MySQL中，有两种刷盘策略：非延迟刷盘和延迟刷盘。
非延迟刷盘是指在每次事务提交时，都将redo log的数据立即刷写到磁盘中。
这种策略可以保证数据的持久性，即使系统崩溃或意外故障，也能通过redo log进行恢复。
但是，由于每次事务提交都需要进行磁盘IO操作，会导致性能降低。
因此，在高并发的数据库系统中，非延迟刷盘的性能可能会成为瓶颈。
延迟刷盘是指将redo log的数据写入磁盘的操作延迟到一定条件下再执行。
具体来说，当redo log缓冲区中的数据达到一定大小或者一定时间间隔时，才会将数据刷写到磁盘中。
这种策略可以提高性能，减少频繁的磁盘IO操作，但是也会增加数据丢失的风险。
因为在系统崩溃或意外故障时，尚未刷写到磁盘的redo log数据将会丢失，无法进行恢复。
在实际应用中，通常会根据数据库的性能需求和数据安全性要求来选择合适的刷盘策略。
如果对数据的一致性要求很高，可以选择非延迟刷盘策略；如果对性能要求很高，可以选择延迟刷盘策略。
另外，MySQL还提供了一种混合刷盘策略，即将redo log的数据先写入磁盘的缓存区，然后再由后台线程进行刷盘操作，以平衡性能和数据安全性。
InnoDB事务⽇志（redolog和undolog）详解数据库通常借助⽇志来实现事务，常见的有undo log、redo log，undo/redo log都能保证事务特性，undolog实现事务原⼦性，redolog实现事务的持久性。
为了最⼤程度避免数据写⼊时io瓶颈带来的性能问题，MySQL采⽤了这样⼀种缓存机制：当query修改数据库内数据时，InnoDB先将该数据从磁盘读取到内存中，修改内存中的数据拷贝，并将该修改⾏为持久化到磁盘上的事务⽇志（先写redo log buffer，再定期批量写⼊），⽽不是每次都直接将修改过的数据记录到硬盘内，等事务⽇志持久化完成之后，内存中的脏数据可以慢慢刷回磁盘，称之为Write-Ahead Logging。
事务⽇志采⽤的是追加写⼊，顺序io会带来更好的性能优势。
为了避免脏数据刷回磁盘过程中，掉电或系统故障带来的数据丢失问题，InnoDB采⽤事务⽇志（redo log）来解决该问题。
⼀、先简单了解⼏个概念数据库数据存放的⽂件称为data file；⽇志⽂件称为log file；数据库数据是有缓存的，如果没有缓存，每次都写或者读物理disk，那性能就太低下了。
数据库数据的缓存称为data buffer，⽇志（redo）缓存称为log buffer。
内存缓冲池buffer pool如果mysql不⽤内存缓冲池，每次读写数据时，都需要访问磁盘，必定会⼤⼤增加I/O请求，导致效率低下。
所以Innodb引擎在读写数据时，把相应的数据和索引载⼊到内存中的缓冲池(buffer pool)中，⼀定程度的提⾼了数据读写的速度。
buffer pool：占最⼤块内存，⽤来存放各种数据的缓存包括有索引页、数据页、undo页、插⼊缓冲、⾃适应哈希索引、innodb存储的锁信息、数据字典信息等。
⼯作⽅式总是将数据库⽂件按页(每页16k)读取到缓冲池，然后按最近最少使⽤(lru)的算法来保留在缓冲池中的缓存数据。
redo log数据恢复原理
Redo Log的恢复原理主要基于事务的原子性和持久性。
当数据库系统（例如MySQL）执行增删改操作时，会记录这些操作的redo log日志。
如果在数据库系统运行过程中出现宕机或者断电等故障，有些缓存页的数据可能还没有来得及写入磁盘。
在数据库系统重启时，系统会根据redo log日志进行数据重做，将数据恢复到宕机或者断电前的状态，从而保证了更新的数据不会丢失。
这个过程就是通过redo log进行数据恢复的过程。
以上内容仅供参考，建议查阅数据库相关书籍或咨询专业人士获取更多专业解答。
redo⽇志redo⽇志作⽤innoDB存储引擎中，需要在服务器故障重启后，能够准确的恢复所有已提交的数据，保证数据持久性；如某个事务在内存Buffer Pool中已被提交（脏页），但服务器突然故障，数据就丢失了；为了解决这个问题，可以采⽤修改页⾯刷新到磁盘，但因为可能只修改了⼀条记录，没必要实时刷新浪费时间，⽽且修改的记录并不⼀定是连续的，随机IO刷新较慢。
可以将已提交事务修改的记录记录下来，即某个表空间中某页的某个偏移量的值更新为多少，这个记录的⽂件就称为redo log。
相⽐刷新内存中的页⾯到磁盘，redo log刷新到磁盘的内容⼩了很多，⽽且是⼀个顺序写⼊磁盘的过程。
redo⽇志不⽌记录索引插⼊/更新记录等操作，还有执⾏这个操作影响到的其他动作，如页分裂新增⽬录项记录，修改页信息等对数据页做的任何修改等等。
和binlog区别：binlog记录的是页已经正式落盘的操作且是包含所有存储引擎，redo⽇志记录InnoDB引擎下仍然在buffer pool中的操作，⽤于系统奔溃时恢复脏页。
⽇志⽇志格式type：类型MLOG_1BYTE：1 ：表⽰在页⾯的某个偏移量处写⼊1个字节的redo⽇志类型。
MLOG_2BYTE：2MLOG_4BYTE：4MLOG_8BYTE：8MLOG_WRITE_STRING：30MLOG_REC_INSERT：9：表⽰插⼊⼀条使⽤⾮紧凑⾏格式记录时的redo⽇志类型（如redundant）MLOG_COMP_REC_INSERT：38：表⽰插⼊⼀条使⽤⾮紧凑⾏格式记录时的redo⽇志类型（如compact/dynamic/compressed）MLOG_COMP_REC_DELETE：42：表⽰删除⼀条使⽤紧凑⾏格式记录的redo⽇志类型MLOG_COMP_LIST_START_DELETE和MLOG_COMP_LIST_END_DELETE：批量删除，可以很⼤程度上减少redo⽇志的条数space id：表空间page number：页号data：真实数据（以MLOG_COMP_REC_INSERT为例）n_fileds：当前记录的字段数n_uniques：决定该记录的唯⼀字段列数量，如有主键的是主键数，唯⼀⼆级索引是索引列数+主键列数，普通⼆级索引⼀样；插⼊时可根据这个字段进⾏排序field1_len-fieldn_len：若⼲字段占⽤存储空间的⼤⼩offset：记录前⼀条记录在页⾯中的位置，⽅便修改页⾯中的记录链表，前⼀条记录维护的next_record属性end_seg_len：通过这个字段可得知当前记录占⽤存储空间⼤⼩len：类型为MLOG_WRITE_STRING时才有的，表⽰具体数据占⽤的字节数redo⽇志内存内操作Mini-TransactionMini-Transaction（mtr）是对底层页⾯中的⼀次原⼦访问的过程（如MAX_ROW_ID⽣成/索引记录插⼊）。
数据库的恢复策略事务故障的恢复事务故障是指事务在运⾏⾄正常终⽌点前被终⽌，这时恢复⼦系统应利⽤⽇志⽂件撤销（UNDO）此事务已对数据库进⾏的修改。
系统恢复的步骤：（1）反向扫描⽇志⽂件（即从最后向前扫描⽇志⽂件），查找该事物的更新操作。
（2）对该事务的更新操作执⾏逆操作。
即将⽇志记录中"更新前的值"写⼊数据库。
这样如果记录中是插⼊操作，则相当于做删除操作；若记录中是删除操作，则做插⼊操作；若是修改，则相当于修改前值代替修改后值。
（3）继续反向扫描⽇志⽂件，查找该事务的其他更新操作，并作同样处理。
（4）如此处理下去，直⾄读到此事务的开始标记，事务故障恢复就完成了。
系统故障系统故障的恢复是由系统在重新启动时候⾃动完成的，不需要⽤户⼲预。
系统的恢复步骤是：（1）正向扫描⽇志⽂件（即从头扫描⽇志⽂件），找出在故障发⽣前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记⼊重做（REDO）队列。
同时找出故障发⽣时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，⽆相应的COMMIT记录）,将其事务标识记⼊撤销队列。
（2）对撤销队列中的各个事务进⾏撤销（UNDO）处理。
进⾏UNDO处理的⽅法是，反向扫描⽇志⽂件，对每⼀个UNDO事务的更新操作执⾏逆操作，将将⽇志记录中"更新前的值"写⼊数据库（该⽅法和事务故障的解决⽅法⼀致）。
（3）对重做队列中的各个事务进⾏重做（REDO）处理。
进⾏REDO处理的⽅法是：正向扫描⽇志⽂件，对每⼀个REDO事务从新执⾏⽇志⽂件登记的操作。
即将⽇志记录中"更新后的值"写⼊数据库。
具有检查点的恢复技术利⽤⽇志技术进⾏数据库恢复时，恢复⼦系统必须搜索⽇志，确定哪些事务需要REDO,哪些事务需要UNDO。
⼀般来说，需要检查⼀是搜索整个⽇志将消耗⼤量的时间。
