Oracle日志(redo)机制探讨
oracle19c redolog 切换机制
![oracle19c redolog 切换机制](https://img.taocdn.com/s3/m/8080295da66e58fafab069dc5022aaea998f41ea.png)
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快照底层原理](https://img.taocdn.com/s3/m/e1aa3d25fe00bed5b9f3f90f76c66137ee064fe1.png)
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详解](https://img.taocdn.com/s3/m/738ea9795b8102d276a20029bd64783e08127d63.png)
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数据库日志文件
![深入分析Oracle数据库日志文件](https://img.taocdn.com/s3/m/be3a726a25c52cc58bd6be4e.png)
作为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日志问题
![oracle关于归档日志和redo日志问题](https://img.taocdn.com/s3/m/4d7d2d64571252d380eb6294dd88d0d233d43cf2.png)
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逻辑日志解析原理](https://img.taocdn.com/s3/m/b382a66ea4e9856a561252d380eb6294dc882256.png)
oracle逻辑日志解析原理
Oracle逻辑日志解析原理涉及到数据库的日志文件和恢复机制。
Oracle数据库采用了逻辑日志(Redo Log)来记录对数据库的所有
更改操作,以便在发生故障时进行恢复。
逻辑日志解析原理可以从
以下几个方面来解释:
1. Redo Log的作用,逻辑日志是一种物理结构,它记录了数
据库中发生的所有更改操作,包括插入、更新和删除操作。
当数据
库发生故障时,可以利用逻辑日志进行恢复,保证数据的一致性和
完整性。
2. 日志记录格式,逻辑日志中的记录采用了一种特定的格式,
包括操作类型、受影响的数据块、事务ID等信息。
解析逻辑日志需
要根据这些信息来还原出数据库的操作过程。
3. 日志解析过程,在数据库发生故障时,系统会首先将逻辑日
志中的记录应用到数据库中,以还原出故障发生前的数据库状态。
这个过程就是逻辑日志的解析过程,它需要按照一定的顺序和规则
来应用日志记录,以确保数据库的一致性。
4. 恢复机制,逻辑日志解析原理也涉及到数据库的恢复机制,包括崩溃恢复和介质恢复。
在崩溃恢复中,数据库会利用逻辑日志来还原出故障发生前的状态;在介质恢复中,数据库管理员可以利用逻辑日志来进行点对点的恢复操作。
总之,Oracle逻辑日志解析原理涉及到数据库的日志记录、格式、解析过程和恢复机制等多个方面,需要结合数据库的架构和运行机制来全面理解。
这些内容对于数据库管理员和开发人员来说都是非常重要的,可以帮助他们更好地理解数据库的运行原理和故障处理机制。
oracle redo日志详解
![oracle redo日志详解](https://img.taocdn.com/s3/m/2a1b5c50804d2b160b4ec046.png)
max_dump_file_size string UNLIMITED
shadow_core_dump string partial
user_dump_dest string /u01/app/oracle/admin/orcl/udump
由LGWR后台进程同时将日志内容写入到一个组的所有成员
LGWR的触发条件
在事务提交的时候(COMMIT)
Redo Log Buffer 三分之一满
Redo Log Buffer 多于一兆的变化记录
--=========================================
-- Oracle 联机重做日志文件(ONLINE LOG FILE)
--=========================================
转载位置: /robinson_0612/article/details/5749556
9.删除日志成员
不能删除组内的唯一一个成员
不能删除处于active 和current 状态组内的成员
删除处于active 和current 状态组内的成员,应使用日志切换使其处于INACTIVE状态后再删除
对于组内如果一个成员为NULL 值,一个为INVALID,且组处入INACTIVE,仅能删除INVALID状态成员
处于归档模式的联机日志,LSN号在归档时也被写入到归档日志之中
4.日志文件的工作方式
日志文件采用按顺序循环写的方式
当一组联机日志组写满,LGWR则将日志写入到下一组,当最后一组写满则从第一组开始写入
写入下一组的过程称为日志切换
user_dump_dest -->用户跟踪日志
oracle主从复制原理
![oracle主从复制原理](https://img.taocdn.com/s3/m/f2fd5f5c793e0912a21614791711cc7930b7785c.png)
oracle主从复制原理Oracle主从复制简介•什么是Oracle主从复制?•主从复制的作用和优点•本文将深入解析Oracle主从复制的相关原理原理解析主从复制的基本概念•主从复制是一种常见的数据库复制技术,它通过将一个数据库的变更复制到其他数据库中,实现数据的同步和备份。
主从复制的流程1.主库产生的变更日志被捕捉2.变更日志被传送到从库3.从库根据变更日志进行数据更新,实现数据库的同步主从复制的角色•主库 (Master)•从库 (Slave)主从复制的工作原理1.主库记录日志 (Redo Log):将所有对数据库的变更操作记录到日志中2.从库请求日志 (Archiver):从库通过请求主库的日志,将日志传送到自己的环境中3.从库重放日志 (Recovery):从库通过重放主库的日志,将日志中的操作在自己的数据库进行执行主从复制的数据同步方式•基于物理的主从复制•基于逻辑的主从复制物理复制 vs 逻辑复制•物理复制:基于数据库的物理备份和日志传输,将改变转发到从库进行执行•逻辑复制:通过逻辑日志记录和重放,将改变在从库上进行重演主从复制的数据一致性•强一致性:在所有从库上重演的操作是按照主库上的顺序依次进行的•弱一致性:不同从库上重演的操作可能出现顺序不同的情况总结•主从复制是一种常见的数据库同步和备份技术,通过将主库的变更复制到从库实现数据的同步。
•主从复制可以基于物理备份和日志传输,也可以基于逻辑日志记录和重放。
•主从复制可以保证数据一致性,但在多从库的情况下,可能出现弱一致性的情况。
以上是对Oracle主从复制的相关原理的深入解析,通过这篇文章的阅读,相信读者对于Oracle主从复制会有更深入的了解。
Oracleredo与undo
![Oracleredo与undo](https://img.taocdn.com/s3/m/554d1bbe68dc5022aaea998fcc22bcd126ff4294.png)
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 日志归档 原理](https://img.taocdn.com/s3/m/48dc1d4d78563c1ec5da50e2524de518964bd3fe.png)
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数据库)也是至关重要的。
redo日志
![redo日志](https://img.taocdn.com/s3/m/022b11edf605cc1755270722192e453611665b5d.png)
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⽣成/索引记录插⼊)。
Oracle导致Redo日志暴增的SQL语句排查
![Oracle导致Redo日志暴增的SQL语句排查](https://img.taocdn.com/s3/m/246d67c2250c844769eae009581b6bd97f19bc4b.png)
Oracle导致Redo⽇志暴增的SQL语句排查⼀、概述最近数据库频繁不定时的报出⼀些耗时长的SQL,甚⾄SQL执⾏时间过长,导致连接断开现象。
下⾯是⼀些排查思路。
⼆、查询⽇志的⼤⼩,⽇志组情况SELECT L.GROUP#,LF.MEMBER,L.ARCHIVED,L.BYTES /1024/1024 "SIZE(M)",L.MEMBERSFROM V$LOG L,V$LOGFILE LFWHERE L.GROUP# = LF.GROUP#;查询结果:从上图可以看出⽬前共分为10个⽇志组,每个⽇志组2个⽂件,每个⽂件⼤⼩为3G。
三、查询Oracle最近⼏天每⼩时归档⽇志产⽣数量SELECT SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5) Day,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '00', 1, 0)) H00,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '01', 1, 0)) H01,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '02', 1, 0)) H02,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '03', 1, 0)) H03,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '04', 1, 0)) H04,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '05', 1, 0)) H05,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '06', 1, 0)) H06,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '07', 1, 0)) H07,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '08', 1, 0)) H08,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '09', 1, 0)) H09,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '10', 1, 0)) H10,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '11', 1, 0)) H11,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '12', 1, 0)) H12,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '13', 1, 0)) H13,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '14', 1, 0)) H14,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '15', 1, 0)) H15,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '16', 1, 0)) H16,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '17', 1, 0)) H17,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '18', 1, 0)) H18,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '19', 1, 0)) H19,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '20', 1, 0)) H20,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '21', 1, 0)) H21,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '22', 1, 0)) H22,SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH24:MI:SS'), 10, 2), '23', 1, 0)) H23,COUNT(*) TOTALFROM v$log_history aWHERE first_time >= to_char(sysdate -10)GROUP BY SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5)ORDER BY SUBSTR(TO_CHAR(first_time, 'MM/DD/RR HH:MI:SS'), 1, 5) DESC;查询结果从上图可以看出业务⾼峰期每⼩时产⽣40个⽇志⽂件左右(⽬前设定的每个⽇志⽂件⼤⼩为3G),平均1.5分钟产⽣⼀个3G的⽇志⽂件。
oracle 归档日志概念解释
![oracle 归档日志概念解释](https://img.taocdn.com/s3/m/e7a84fd6dc88d0d233d4b14e852458fb770b38d4.png)
oracle 归档日志概念解释在Oracle数据库中,归档日志(Archived Logs)是一种重要的数据库日志,用于记录数据库发生的所有变更操作,以便在系统故障或数据损坏时进行数据库恢复。
以下是有关归档日志的一些关键概念和解释:1. 日志文件:Oracle数据库通过日志文件(Redo Log)记录所有对数据库的变更操作。
这包括插入、更新和删除操作。
日志文件的作用是保留数据库的变更历史,以便在需要时进行恢复。
2. 在线日志和归档日志:日志文件分为在线日志和归档日志两种类型。
在线日志包含当前正在进行的事务的日志信息,而归档日志包含已经完成的事务的日志信息。
当在线日志满了或发生特定的切换事件时,其中的日志会被归档到归档目录中。
3. 归档目录:归档日志被存储在一个被称为归档目录(Archive Destination)的特定位置。
这可以是本地磁盘、网络位置或远程服务器。
在配置归档目录时,确保有足够的磁盘空间存储归档日志,因为这对数据库的正常运行和故障恢复至关重要。
4. 日志切换:当在线日志文件满了或发生某些事件时,数据库会执行一个日志切换(Log Switch)。
这时,当前的在线日志文件会被标记为不可用,并且一个新的在线日志文件会开始记录新的变更。
同时,旧的在线日志文件会被归档。
5. 数据库恢复:归档日志对数据库的恢复非常关键。
如果数据库发生故障,系统可以利用归档日志中的信息,从最后一个完整备份以来的任何时间点将数据库还原到一致的状态。
这种恢复过程称为“介质恢复”(Media Recovery)。
总的来说,归档日志是Oracle数据库中一项关键的功能,它确保了数据库的可靠性和一致性,同时提供了故障恢复的能力。
oracle cdc 原理
![oracle cdc 原理](https://img.taocdn.com/s3/m/615fe18cba4cf7ec4afe04a1b0717fd5360cb2e4.png)
oracle cdc 原理Oracle CDC(Change Data Capture)是一种数据捕获技术,用于捕获数据库中的数据变化,并将这些变化应用于其他系统中。
它可以实时监控数据库的变化,并将这些变化记录下来,以便后续的分析和处理。
Oracle CDC的原理是通过在数据库中创建日志来实现的。
当数据库中的数据发生变化时,Oracle会将这些变化写入日志文件中。
CDC 通过解析这些日志文件来获取数据的变化,并将其应用于其他系统中,以保持数据的一致性。
为了实现CDC,Oracle会记录以下三种类型的日志:1. Redo Log:这是Oracle数据库中最重要的日志类型之一。
当数据发生变化时,Oracle会将变化前后的数据记录到Redo Log中。
CDC 通过解析Redo Log来获取数据的变化。
2. Undo Log:Undo Log记录了事务的撤销信息。
当数据库中的数据发生变化时,Oracle会将原始数据保存到Undo Log中。
CDC可以通过解析Undo Log来获取数据的变化。
3. Archive Log:Archive Log是将Redo Log保存到磁盘上的一种机制。
通过将Redo Log保存到磁盘上,可以确保即使数据库崩溃,数据的变化也不会丢失。
CDC可以通过解析Archive Log来获取数据的变化。
通过解析这些日志文件,CDC可以获取数据的变化信息,并将其应用于其他系统中。
它可以实时监控数据库的变化,并将这些变化同步到其他系统中,以保持数据的一致性。
使用Oracle CDC可以带来许多好处。
首先,它可以实现实时数据同步,确保数据在不同系统之间的一致性。
其次,它可以降低数据同步的延迟,使得数据可以更快地在系统之间流动。
此外,Oracle CDC还可以提供增量备份和恢复的功能,以及实时数据分析和报告的能力。
总结起来,Oracle CDC是一种通过解析数据库日志来捕获数据变化的技术。
它可以实时监控数据库的变化,并将这些变化应用于其他系统中。
oracle学习之redo
![oracle学习之redo](https://img.taocdn.com/s3/m/fe56ad5632687e21af45b307e87101f69e31fb7b.png)
oracle学习之redoOracle的重做⽇志基本概念及原理重做⽇志⽂件 redo log file 通常也称为⽇志⽂件,它是保证数据库安全和数据库备份与恢复的⽂件,是数据库安全和恢复的最基本的保障。
管理员可以根据⽇志⽂集和数据库备份⽂件,将崩溃的数据库恢复到最近⼀次记录⽇志时的状态。
所以在⽇常⼯作当中,管理员维护重做⽇志⽂件也是⼗分必要的。
1、概述重做⽇志⽂件⽤于记录事务操作所引起的数据的变化,包括回滚段事务表、回滚块、数据块上的事务槽、数据⾏的变化等,当执⾏DDL、DML操作时,有LGWR进程将⽇志缓冲区中与事务相关的重做记录写⼊到重做⽇志⽂件中。
当丢失或损坏数据库中的数据时,Oracle会根据redo⽂件中的记录恢复丢失的数据。
1.1史记讲解法来理解⽇志记录的原理buffercache⾥⾯有⼀堆的buffer,假设在buffercache上站着⼀个⼈,它能够看到buffercache⾥⾯所有的buffer,⽽且这个⼈眼睛特别快,对buffercache来讲⼤量的sql语句执⾏,在⼀个时间其中的某个buffercache中的块被改了,下⼀个时间另外⼀个buffercache中的块被改了,时间差了⼏毫秒,就是说在短时间内,⼤量的buffer被修改了,然后这个⼈就拿着⼀个本在记录,严格按照时间来记录buffer的⼀个改变过程,机上在这个时间点哪个buffer发⽣什么样的改变。
也就是说这个⼈,以极快的速度严格的按照时间顺序来记录buffer的⼀个改变过程,这些⽇志会记录到logbuffer⾥⾯去,最后logbuffer会通过LGWR这个进程写到磁盘上的redolog⾥⾯去。
也就是说,我们的⽇志记录的是BUFFER的改变,并且按照时间顺序记录的,所以说⽇志⾥⾯记录的就是buffer⾥严格的按照时间顺序记录的buffer的整个改变过程。
⽇志记录的是buffer的改变,⽇志是以buffer为单位来记录的,⼀个块的改变⾄少记录⼀条⽇志,安装改变的时间顺序来记录的。
oracle redolog大小设定规则
![oracle redolog大小设定规则](https://img.taocdn.com/s3/m/9c5192abe109581b6bd97f19227916888486b909.png)
oracle redolog大小设定规则Oracle Redo Log 大小设置规则Oracle数据库是一种强大而广泛使用的关系型数据库管理系统。
在Oracle数据库中,Redo Log是一组文件,用于记录对数据库所做的更改操作。
Redo Log 的创建和管理对于数据库的性能和稳定性至关重要。
在本文中,我们将探讨Oracle Redo Log的大小设置规则,以帮助您更好地优化数据库性能。
1. 了解Redo Log的基本概念在深入讨论Redo Log大小设置规则之前,首先需要了解Redo Log的基本概念。
Redo Log是Oracle数据库中唯一用于恢复和重做数据的手段。
它记录了数据库的所有更改操作,并将这些操作写入到磁盘上的Redo Log文件中。
当发生故障时,数据库可以使用Redo Log文件来重播这些操作,并将数据库恢复到故障之前的状态。
2. 确定Redo Log文件的大小在Oracle数据库中,Redo Log文件的大小是可以配置的。
通常,每个数据库都有一组Redo Log文件,其中包含一到多个成员。
为了确定Redo Log文件的大小,需要考虑以下几个方面:- 数据库负载:根据数据库的负载情况,可以确定Redo Log文件的大小。
如果数据库的负载较高,那么应该增加Redo Log文件的大小,以便更好地支持并发事务处理。
- 事务数量:还可以根据预计的事务数量来确定Redo Log文件的大小。
较大的事务数量可能意味着需要更大的Redo Log文件,以确保足够的空间来记录所有的更改操作。
- 历史Redo Log文件的使用情况:通过查看历史Redo Log文件的使用情况,可以评估当前Redo Log文件的大小是否足够。
如果历史Redo Log文件的使用率较高,那么可能需要增加Redo Log文件的大小。
3. 考虑性能和可用空间当设置Redo Log文件的大小时,需要平衡数据库性能和可用空间之间的需求。
oracle_重做日志文件--笔记
![oracle_重做日志文件--笔记](https://img.taocdn.com/s3/m/d4667dd48ad63186bceb19e8b8f67c1cfad6eee4.png)
oracle_重做⽇志⽂件--笔记重做⽇志⽂件(redo log file)⽬录重做⽇志⽂件相关。
重做⽇志⽂件简介。
查询重做⽇志⽂件的信息。
⽇志切换。
管理⽇志⽂件组增删⽇志⽂件组。
增删⽇志⽂件成员。
归档与⾮归档模式。
⼀.重做⽇志⽂件相关。
Oracle引⼊重做⽇志的⽬的:数据库的恢复。
Oracle相关进程:重做⽇志写进程(LGWR)。
重做⽇志性质:联机⽇志⽂件,oracle服务器运⾏时需要管理它们。
相关数据字典:v$log ; v$logfile。
操作者权限:具有sys⽤户或system⽤户权限。
1.1重做⽇志⽂件的规划。
(于⽹络上收集)联机⽇志⽂件的规划原则如下:1:分散放开,多路复⽤。
⼀般会将同⼀组的不同⽇志成员⽂件放到不同的磁盘或不同的裸设备上。
以提⾼安全性。
2:把重做⽇志放在速度最快的硬盘上(即:⽇志所在的磁盘应当具有较⾼的I/O),⼀般会将⽇志⽂件放在裸设备上。
3:把重做⽇志⽂件设为合理⼤⼩:例如,增⼤⽇志⽂件⼤⼩可以加快⼀些⼤型的INSERT、UPDATE、DELETE操作,也能降低⽇志⽂件切换频率。
减少⼀些⽇志等待事件。
⼀般根据具体业务情况有所不同。
⼀般⽇志组⼤⼩应满⾜⾃动切换间隔⾄少15-20分钟左右业务需求4:ORACLE推荐,同⼀个重做⽇值组下的所有重做⽇志⽂件⼤⼩、成员个数⼀致.⼆.重做⽇志⽂件简介。
2.1重做⽇志重做⽇志⽂件⼜叫联机⽇志⽂件,记录了对数据库修改的信息,包括⽤户对数据修改和数据库管理员对数据库结构的修改。
2.2重做⽇志的作⽤。
它主要⽤于在oracle发⽣故障的时候和数据库备份⽂件配合恢复数据库。
⼀般来说,数据库故障丢失数据,有两种情况。
⼀是,因为停电或死机,脏块未写⼊磁盘,造成该数据丢失。
⼆是,磁盘损坏,数据全完蛋。
对应第⼀种情况,oracle会使⽤实例恢复,使⽤重做⽇志⾃动恢复数据,不需要⽤户⼲预。
没错,实例恢复,它是⾃动的。
对应第⼆种情况,便需要DBA使⽤备份,重做⽇志,归档⽇志来恢复数据了。
oracle redolog解析
![oracle redolog解析](https://img.taocdn.com/s3/m/78b1d7eadc3383c4bb4cf7ec4afe04a1b171b049.png)
标题:Oracle Redo Log解析一、概述在Oracle数据库中,Redo Log是一个关键的概念,它记录了数据库中发生的所有变更操作,包括插入、更新、删除等操作,它是数据库恢复和数据持久性的重要保障。
本文将对Oracle Redo Log进行详细解析,包括其概念、结构、作用以及相关操作。
二、Redo Log的概念Redo Log是Oracle数据库中的一组文件,用来记录数据库中的所有更改操作,称为Redo记录。
Redo Log记录了数据库中的数据修改操作的详细信息,包括修改的对象、修改的语句以及修改的时间等。
Redo Log的作用在于保证数据库的恢复性和持久性,同时也是实现Oracle数据库的高可用性的重要手段。
三、Redo Log的结构Redo Log是由多个组成的,每个组成中有多个成员。
每个成员中记录了一段时间内数据库的更改操作,当一个成员记录满后,系统将在下一个成员中继续记录。
Redo Log的结构包括了多个组成以及每个组成中的成员,这种结构保证了Redo Log能够持续记录数据库的更改操作,并且保证了数据的一致性和恢复性。
四、Redo Log的作用Redo Log的主要作用在于保证数据库的恢复性和持久性。
当数据库发生意外故障或者因为其他原因造成数据丢失时,Redo Log能够帮助数据库进行恢复,保证数据的完整性和一致性。
Redo Log也是Oracle数据库实现高可用性的重要手段,它可以帮助数据库实现在线备份、热备份和数据保护等功能。
五、Redo Log的相关操作在Oracle数据库中,Redo Log是一个重要的组成部分,它需要进行一系列的管理和维护操作。
包括Redo Log文件的创建、删除、切换、清理等操作,同时还需要进行Redo Log的监控和性能调优等工作。
在实际的数据库管理工作中,对Redo Log的合理管理和操作是非常重要的,它直接影响着数据库的性能和稳定性。
结论通过对Oracle Redo Log的详细解析,我们可以了解到Redo Log作为Oracle数据库中重要的组成部分,对数据库的恢复性和持久性起着至关重要的作用。
Oracle日志介绍
![Oracle日志介绍](https://img.taocdn.com/s3/m/88f501122bf90242a8956bec0975f46526d3a76a.png)
Oracle日志介绍Oracle的日志是一种记录数据库操作和事件的机制,它可以帮助数据库管理员进行故障排除、恢复数据以及进行性能优化等工作。
Oracle的日志包括事务日志(Redo Log)、归档日志(Archive Log)和警告日志。
事务日志是Oracle数据库最重要的日志,它记录了数据库中每个事务所做的修改。
当用户在数据库执行更新、插入或删除操作时,事务日志会将这些操作以一种逻辑的方式记录下来。
这样即使数据库崩溃或者非正常关闭,管理员仍然可以通过重放事务日志来恢复数据库到崩溃前的状态,保证数据的一致性。
事务日志还可以用于数据库的恢复、数据迁移和数据库备份等操作。
归档日志是在数据库中启用归档模式后,产生的一种备份。
当事务日志已经满时,归档日志会被创建并存储到归档目录中。
归档日志的主要作用是保证数据的持久性,即使系统发生故障或者备份失败,通过归档日志可以保证丢失的数据可以从归档中进行恢复。
通过应用归档日志,可以将数据库恢复到任意时间点,以实现精确的数据恢复。
警告日志记录了Oracle数据库中的错误信息、警告信息和一些其他的重要事件。
警告日志可以帮助管理员及时发现和解决数据库的健康和性能问题。
警告日志也包含了数据库的启动和关闭过程,以及数据库网络连接问题的信息。
同时,警告日志还能记录数据库的配置变更、数据库资源的使用情况以及一些特殊功能的启用和禁用,这些信息都对于诊断和调优数据库非常有用。
在日常的运维工作中,管理员需要定期查看Oracle的日志以监控数据库的健康状况和及时发现问题。
可以通过查看事务日志来判断数据库的工作负载和事务处理情况,通过分析归档日志可以确定数据库备份的完整性和执行效果,通过检查警告日志可以找到数据库运行中的一些异常,并及时进行修复。
同时,管理员还需要根据实际需求和线上的问题,使用参数文件和跟踪文件进行相关的配置和分析工作。
总之,Oracle的日志是数据库运行和维护的重要组成部分,它们扮演着记录、恢复、诊断和优化数据库的重要角色。
理解REDO LOG(3)LOG BUFFER 和LGWR
![理解REDO LOG(3)LOG BUFFER 和LGWR](https://img.taocdn.com/s3/m/e0eb2b02a6c30c2259019eff.png)
理解REDO LOG(3)LOG BUFFER 和LGWRREDO LOG的产生十分频繁,几乎每秒钟都有几百K到几M的RED LOG产生,甚至某些大型数据库每秒钟产生的REDO LOG量达到了10M以上。
不过前台进程每次产生的RE DO量却不大,一般在几百字节到几K,而一般来所一个事务产生的REDO 量也不过几K 到几十K。
基于REDO产生的这个特点,如果每次REDO产生后就必须写入REDO LOG 文件,那么就会存在两个问题,一个是REDO LOG文件写入的频率过高,会导致REDO LOG文件的IO存在问题,第二个是如果由前台进程来完成REDO LOG的写入,那么会导致大量并发的前台进程产生REDO LOG文件的争用。
为了解决这两个问题,Oracle在RE DO LOG机制中引入了LGWR后台进程和LOG BUFFER。
LOG BUFFER是Oracle用来缓存前台进程产生的REDO LOG信息的,有了LOG BUFF ER,前台进程就可以将产生的REDO LOG信息写入LOG BUFFER,而不需要直接写入RE DO LOG文件,这样就大大提高了REDO LOG产生和保存的时间,从而提高数据库在高并发情况下的性能。
既然前台进程不将REDO LOG信息写入REDO LOG文件了,那么就必须要有一个后台进程来完成这个工作。
这个后台进程就是LGWR,LGWR进程的主要工作就是将LOG BUFFER中的数据批量写入到REDO LOG文件中。
对于Oracle数据库中,只要对数据库的改变写入到REDO LOG文件中了,那么就可以确保相关的事务不会丢失了。
引入LOG BUFFER后,提高了整个数据库RDMBS写日志的性能,但是如何确保一个已经提交的事务确确实实的被保存在数据库中,不会因为之后数据库发生故障而丢失呢?实际上在前面两节中我们介绍的REDO LOG的一些基本的算法确保了这一点。
首先WRITE AHEAD LOG协议确保了只要保存到REDO LOG文件中的数据库变化一定能够被重演,不会丢失,也不会产生二义性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
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机制是一个非常有特色的技术亮点,对数据库的性能也影响非常大。
掌握这个机制并根据系统的实际情况加以利用对数据库管理员来说非常具有实用价值。