innodb 为了提高磁盘I/O读写性能，存在一个 buffer pool 的内存空间，数据页读入会缓存到 buffer pool，事务的提交则实时更新到 buffer pool，而不实时同步到磁盘（innodb 是按 16KB 一页同步的，一事务可涉及多个数据页，实时同步会造成浪费，随机I/O）。事务暂存在内存，则存在一致性问题，为了解决系统崩溃，保证事务的持久性，我们只需把事务对应的 redo 日志持久化到磁盘即可（redo 日志占用空间小，顺序写入磁盘，顺序I/O）
sql 语句在执行的时候，可能会修改多个页面，还会更新聚簇索引和二级索引的页面，过程产生的redo会被分割成多个不可分割的组（Mini-Transaction）。MTR怎么理解呢？如一条 insert 语句可能会使得页分裂，新建叶子节点，原先页的数据需要复制到新数据页里，然后将新记录插入，再添加一个目录项指向新建的页子。这对应多条 redo 日志，它们需要在原子性的 MTR 内完成
MTR 产生的 redo 日志先会被复制到一个 log buffer 里(类似 buffer pool)。而同步到磁盘的时机如下：
事务需要保证原子性，也是说事务中的 *** 作要么全部完成，要么什么也不做。如果事务执行到一半，出错了怎么办-回滚。但是怎么回滚呢，靠 undo 日志。undo 日志就是我们执行sql的逆 *** 作
binlog有三种格式：Statement、Row以及Mixed。
redolog 中的事务如果经历了二阶段提交中的prepare阶段，则会打上 prepare 标识，如果经历commit阶段，则会打上commit标识（此时redolog和binlog均已落盘）。崩溃恢复逻辑如下：
Oracle的数据库日志称为Redo log 所有数据改变都记录Redo log 可以用于修复受损的数据库 Redo log 是用于恢复和一个高级特性的重要数据 一个redo条目包含了相应 *** 作导致的数据库变化的所有信息 所有redo条目最终都要被写入redo文件中去
Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存 一个redo条目首先在用户内存(PGA)中产生 然后由oracle服务进程拷贝到log buffer中 当满足一定条件时 再由LGWR进程写入redo文件 由于log buffer是一块 共享 内存 为了避免冲突 它是受到redo allocation latch保护的 每个服务进程需要先获取到该latch才能分配redo buffer 因此在高并发且数据修改频繁的oltp系统中 我们通常可以观察到redo allocation latch的等待 Redo写入redo buffer的整个过程如下
在PGA中生产Redo Enrey >服务进程获取Redo Copy latch(存在多个 CPU_COUNT* ) >服务进程获取redo allocation latch(仅 个) >分配log buffer >释放redo allocation latch >将Redo Entry写入Log Buffer >释放Redo Copy latch
shared strand
为了减少redo allocation latch等待 在oracle 中 引入了log buffer的并行机制 其基本原理就是 将log buffer划分为多个小的buffer 这些小的buffer被成为strand(为了和之后出现的private strand区别 它们被称之为shared strand) 每一个strand受到一个单独redo allocation latch的保护 多个shared strand的出现 使原来序列化的redo buffer分配变成了并行的过程 从而减少了redo allocation latch等待
shared strand的初始数据量是由参数log_paralleli *** 控制的在 g中 该参数成为隐含参数 并新增参数_log_paralleli *** _max控制shared strand的最大数量_log_paralleli *** _dynamic则控制是否允许shared strand数量在_log_paralleli *** 和_log_paralleli *** _max之间动态变化
HELLODBA >select nam ksppinm val KSPPSTVL nam ksppdesc
from sys x$ksppi nam
sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm LIKE _%
AND upper(nam ksppinm) LIKE %LOG_PARALLE%
KSPPINM KSPPSTVL KSPPDESC
_log_paralleli *** Number of log buffer strands
_log_paralleli *** _max Maximum number of log buffer strands
_log_paralleli *** _dynamic TRUE Enable dynamic strands
每一个shared strand的大小 = log_buffer/(shared strand数量) strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strand g以后存在)
HELLODBA >select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa !=
INDX STRAND_SIZE_KCRFA
HELLODBA >show parameter log_buffer
NAME TYPE VALUE
log_buffer integer
关于shared strand的数量设置 个cpu之内最大默认为 当系统中存在redo allocation latch等待时 每增加 个cpu可以考虑增加 个strand 最大不应该超过 并且_log_paralleli *** _max不允许大于cpu_count
注意 在 g中 参数_log_paralleli *** 被取消 shared strand数量由_log_paralleli *** _max _log_paralleli *** _dynamic和cpu_count控制
Private strand
为了进一步降低redo buffer冲突 在 g中引入了新的strand机制 Private strand Private strand不是从log buffer中划分的 而是在shared pool中分配的一块内存空间
HELLODBA >select * from V$sgastat where name like %strand%
POOL NAME BYTES
shared pool private strands
HELLODBA >select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa =
INDX STRAND_SIZE_KCRFA
Private strand的引入为Oracle的Redo/Undo机制带来很大的变化 每一个Private strand受到一个单独的redo allocation latch保护 每个Private strand作为 私有的 strand只会服务于一个活动事务 获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo 当flush private strand或者mit时 Private strand被批量写入log文件中 如果新事务申请不到Private strand的redo allocation latch 则会继续遵循旧的redo buffer机制 申请写入shared strand中 事务是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鉴定
HELLODBA >select decode(bitand(ktcxbflg ) ) used_private_strand count(*)
from x$ktcxb
where bitand(ksspaflg ) !=
and bitand(ktcxbflg ) !=
group by bitand(ktcxbflg )
USED_PRIVATE_STRAND COUNT(*)
对于使用Private strand的事务 无需先申请Redo Copy Latch 也无需申请Shared Strand的redo allocation latch 而是flush或mit是批量写入磁盘 因此减少了Redo Copy Latch和redo allocation latch申请/释放次数 也减少了这些latch的等待 从而降低了CPU的负荷 过程如下
事务开始 >申请Private strand的redo allocation latch (申请失败则申请Shared Strand的redo allocation latch) >在Private strand中生产Redo Enrey >Flush/Commit >申请Redo Copy Latch >服务进程将Redo Entry批量写入Log File >释放Redo Copy Latch >释放Private strand的redo allocation latch
注意 对于未能获取到Private strand的redo allocation latch的事务 在事务结束前 即使已经有其它事务释放了Private strand 也不会再申请Private strand了
每个Private strand的大小为 K g中 shared pool中的Private strands的大小就是活跃会话数乘以 K 而 g中 在shared pool中需要为每个Private strand额外分配 k的管理空间 即 数量* k
g:
SQL>select * from V$sgastat where name like %strand%
POOL NAME BYTES
shared pool private strands
HELLODBA >select trunc(value * KSPPSTVL / ) * *
from (select value from v$parameter where name = transactions ) a
(select val KSPPSTVL
from sys x$ksppi nam sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm = _log_private_paralleli *** _mul ) b
TRUNC(VALUE*KSPPSTVL/ )* *
g:
HELLODBA >select * from V$sgastat where name like %strand%
POOL NAME BYTES
shared pool private strands
HELLODBA >select trunc(value * KSPPSTVL / ) * ( + ) *
from (select value from v$parameter where name = transactions ) a
(select val KSPPSTVL
from sys x$ksppi nam sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm = _log_private_paralleli *** _mul ) b
TRUNC(VALUE*KSPPSTVL/ )*( + )*
Private strand的数量受到 个方面的影响 logfile的大小和活跃事务数量
参数_log_private_mul指定了使用多少logfile空间预分配给Private strand 默认为 我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand
HELLODBA >select bytes from v$log where status = CURRENT
BYTES
HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*
(select to_number(val KSPPSTVL)
from sys x$ksppi nam sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm = _log_private_mul ) / / )
as calculated private strands
from dual
calculated private strands
HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =
actual private strands
当logfile切换后(和checkpoint一样 切换之前必须要将所有Private strand的内容flush到logfile中 因此我们在alert log中可能会发现日志切换信息之前会有这样的信息 Private strand flush not plete 这是可以被忽略的) 会重新根据切换后的logfile的大小计算对Private strand的限制
HELLODBA >alter system switch logfile
System altered
HELLODBA >select bytes from v$log where status = CURRENT
BYTES
HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*
(select to_number(val KSPPSTVL)
from sys x$ksppi nam sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm = _log_private_mul ) / / )
as calculated private strands
from dual
calculated private strands
HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =
actual private strands
参数_log_private_paralleli *** _mul用于推算活跃事务数量在最大事务数量中的百分比 默认为 Private strand的数量不能大于活跃事务的数量
HELLODBA >show parameter transactions
NAME TYPE VALUE
transactions integer
transactions_per_rollback_segment integer
HELLODBA >select trunc((select to_number(value) from v$parameter where name = transactions ) *
(select to_number(val KSPPSTVL)
from sys x$ksppi nam sys x$ksppsv val
where nam indx = val indx
AND nam ksppinm = _log_private_paralleli *** _mul ) / )
as calculated private strands
from dual
calculated private strands
HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =
actual private strands
注 在预分配Private strand时 会选择上述 个条件限制下最小一个数量 但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的
lishixinzhi/Article/program/Oracle/201311/16501一个是撤销你之前的行为，另一个则是恢复 *** 作--redo
00 – Undo Log
Undo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。
- 事务的原子性(Atomicity)
事务中的所有 *** 作，要么全部完成，要么不做任何 *** 作，不能只做部分 *** 作。如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。
- 原理
Undo Log的原理很简单，为了满足事务的原子性，在 *** 作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。
- 事务的持久性(Durability)
事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。不能因为错误/重启/宕机而丢失已经COMMIT的数据。为了保证持久性，数据库系统需要将修改后的数据完全的记录到持久的存储上。
- 用Undo Log实现原子性和持久化的事务的简化过程
假设有A、B两个数据，值分别为1,2。
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.在内存中修改A=3.
D.记录B=2到undo log的内存buffer.
E.在内存中修改B=4.
F.将undo log的buffer写到磁盘。
G.将内存中修改后的数据写到磁盘。
H.事务提交
这里有一个前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。以上过程之所以能同时保证原子性和持久化，是因为以下特点：
A. 更新数据前记录Undo log。
B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
C. Undo log必须先于数据持久化到磁盘。如果在G,H之间系统崩溃，undo log是完整的，可以用来回滚事务。
D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。
缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化，即Redo Log.
01 – Redo Log
- 原理
和Undo Log相反，Redo Log记录的是新数据的备份。在事务提交时，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。
- Undo + Redo事务的简化过程
假设有A、B两个数据，值分别为1,2.
A.事务开始.
B.记录A=1到undo log的内存buffer.
C.内存中修改A=3.
D.记录A=3到redo log的内存buffer.
E.记录B=2到undo log的内存buffer.
F..内存中修改B=4.
G.记录B=4到redo log的内存buffer.
H.将redo log的内存buffer写入磁盘。
I.事务提交
- Undo + Redo事务的特点
A. 为了保证持久性，必须在事务提交时将Redo Log持久化。
B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。
C. Redo Log 保证事务的持久性。
D. Undo Log 保证事务的原子性。
E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。这是因为Recovery要依赖redo log. 如果redo log丢失了，系统需要保持事务的数据也没有被更新。
- IO性能
Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO. 但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：
A. 尽量保持Redo Log存储在一段连续的空间上。以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。因此在系统第一次启动时就会将日志文件的空间完全分配，从而保证Redo Log文件在存储上的空间有更好的连续性。
B. 批量写入日志。日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),才将许多日志一起写入磁盘，这样可以减少IO次数。
C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，以减少Redo Log的IO次数。例如,Redo Log中的记录内容可能是这样的：
记录1: <trx1, insert …>
记录2: <trx2, update …>
记录3: <trx1, delete …>
记录4: <trx3, update …>
记录5: <trx2, insert …>
D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。
E. Redo Log上只进行顺序追加的 *** 作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。InnoDB的做法时将回滚 *** 作也记入Redo Log(具体做法看下一节).
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）