Oracle核心技术 笔记（该书读得不细致，须要找时间再细读~~）

Oracle核心技术

跳转至： 导航、 搜索

文件夹

• 1
  開始
• 2
  redo和undo
• 3
  事务与一致性
• 4
  锁与闩
• 5
  缓存和复制
• 6
  写入和恢复
• 7
  解析与优化
• 8
  RAC及‘缺陷’
• 9
  附录A 转储与调试

開始

1. SGA/SCN
2. 真正须要理解的只3个进程：lgwr、dbwr、dbwN

redo和undo

1. Oracle v6：改变向量（change vector）
2. 两份存储：当前状态 + redo日志
3. 改变数据的方法：4步关键步骤（这使得数据改动是可逆的）
   1. 创建改变操作的描写叙述（redo change vector）
   2. undo描写叙述（插入到undo表空间的undo块中）
   3. undo描写叙述的描写叙述（此undo的redo change vector）
   4. 改变数据项
   • 实际的顺序变成3 1 2 4，2条redo被合并为一条日志记录，写入到redo缓冲区
   • 事务中的第一次改动包括一些特殊步骤*
   • （我的小结）理论上说来，redo日志写成功即意味着事务已经成功提交。这时假设数据库崩溃导致内存中的当前状态没有更新到数据库存储中时，就能够通过redo再做一次以确保事务完毕；另外一方面，因为一个嵌套事务的失败，导致已完毕的数据库更新须要回退。这时就须要undo，而undo本身有可能因存储于易失性区域崩溃而丢失。这时就须要把undo再通过undo的redo日志再做一遍以恢复数据到前一个一致状态

     从上面的描写叙述能够看到，事务的实现依赖于数据改动是可逆的这一点，否则状态易失（如赋值操作、文件写操作）就不可能做到一致性恢复

     而一致性恢复依赖于全局一致性快照（即MVCC）的创建。为此须要事务号、时间戳这些特殊的底层属性来实现。这能够參考CLojure语言中相关概念

4. why？undo记录阻止了其它用户查看我们正在改变的数据（中间暂时状态）
   1. 其它用户能够通过undo得到记录的之前的一个版本号（与他的事务视图相一
5. redo allocation latch：保护redo日志缓冲区（由于仅仅有一个lgwr进行着串行的写操作）
   1. 所谓的latch事实上就是Linux Kernel里类似spin_lock（自旋锁）的东西
6. p17 每一个人都做一点点“额外的”工作（协作的开销？），就意味着他们能够在不同的地方同一时候工作，而不必常常在同一个地方竞争(contention)
7. redo simplicity
8. undo complexity
   1. undo的存在可以让会话在不应该看到数据的最新版本号（未事务提交。）时去訪问更旧的版本号（与会话的一致性相符合）
   2. 读一致性：有限的ITL entries，超出的作为undo记录保存（往回倒带~）
   3. 回滚：将产生新的redo。（请对比代码管理系统里的revert操作。revert实际上产生一个新的commit）
      1. 消除回滚成本：全局暂时表

事务与一致性

1. 让提交尽可能快*，让回滚慢慢来
   1. *而且尽可能频繁？细粒度的提交对VCS而言有助于连续集成，对于DBMS呢？
2. 事务与undo
   1. undo段：段头、extent map、extent control header
   2. 事务表TRN TBL:，wrap#列？
      1. 事务表中条目，在v$transaction视图里称‘槽’（slot）
   3. x$ktuxe
   4. newing, & 闪回。。。
   5. 单个undo块可包括多个事务的undo记录
3. 数据块訪问与undo
   1. 本节包括的内容相当重要，但因为涉及大量细节，仅仅能等有时间的时间再细看了
4. 提交SCN
   1. 提交清除
   2. 延迟块清除：通过“均摊”的方式来‘隐藏’工作量
   3. 事务表回滚
      1. ORA-1555 “快照太旧”
   4. 大对象（LOB）
      1. 仅仅需关心索引的事务和读一致性处理，特例：ORA-22924
5. 小结
   1. 一个ITL条目：xid: uba: SCN

锁与闩

1. 锁和pin：FCFS。闩和Mutex（10g+，替换pin）：随机抢占策略
2. 闩：保护共享内存
   1. 可共享
   2. 本质上是一个内存位置和一个test-and-set的CPU原子操作的组合（#see Lock-Free数据结构）
   3. 相当于Linux内核里的spin_lock。spin_lock在单核CPU下不起作用
   4. 活动统计：v$latch_parent v$latch_children
      1. gets、misses、spin_gets、sleeps、sleepN、immediate_gets、immmediate_misses、wait_time
   5. 等待唤醒机制（相当于Linux内核里的信号量？）
   6. library cache latch
      1. 大部分闩锁在11g中取消了（仅仅剩library cache load lock）
3. 锁：保护对象（锁=排队？）
   1. 基础结构：x$ksqrs（v$resource，标记资源） x$ksqeq（设置锁模式）
   2. v$lock
      1. “锁定”某个对象：增加到等待队列某尾。直到等待队列和转换队列之间没有会话在你前面。这时附加自己到拥有者队列
   3. 死锁
      1. TX/4等待？
   4. 锁模式
      1. NL SS RS SX RX S SSX SRX X
   5. 保护锁的闩锁＊
   6. KGL锁（和pin）
   7. 锁和pin=〉11g后逐步被Mutex替代

缓存和复制

1. 内存管理
   1. 10g ASMM：db_cache_size/shared_pool_size ==> 固定大小的granule
2. 多个数据块缓存
   1. 8种类型：db_cache_size db_keep_cache_size db_recycle_cache_size db_2k_cache_size（这什么破命名） ...
   2. 更小的chunk
3. 工作集
   1. x$kcbwds
4. LRU/TCH算法
   1. 似乎比較重要，待有时间又一次细读
5. REPL_AUX
   1. --> REPL_MAIN？
6. 查找数据
   1. pin住缓存区
   2. 逻辑IO
   3. 更新
   4. 加载hash链
   5. 读一致性拷贝
   6. 物理IO
   7. 表扫描

写入和恢复

1. lgwr
   1. redo sync writes和log file sync
   2. 10g+ 新的commit选项
   3. 重做日志浪费（redo wastage）
   4. 私有重做（private redo threads）
2. dbwr
   1. 缓冲区头部
   2. 检查点队列
   3. 增量检查点
3. 写进程的交互
   1. ？相对文件号（）/绝对文件号（afn:）
4. 恢复

解析与优化

1. 数据字典缓存：v$sgastat
2. 8i+ cursor_sharing
3. parse活动和parse call？
4. 库缓存
5. 共享池
6. 解析和优化（略）
7. executing、locking和pinning

RAC及‘缺陷’

1. GRD
2. p178 虚拟IP和SCAN
3. p183 至少须要从4个实例開始
4. Master和Shadow
5. GCS和GES
6. 缓存融合

附录A 转储与调试