持续更新...)
第8章
1.在过程性循环中提交更新容易产生ora-01555:snapshot too old错误.P257
(这种情况我觉得应该是在高并发的情况下才会产生)
假设的一个场景是系统一边读取表,一边在修改这个表,就会同时生成查询所需要的undo信息.update生成了undo信息,你的查询可能会利用这些undo信息来得到待更新数据的读一致视图.如果提交了所做的更新,就会允许系统重用刚刚填写的undo段空间.如果系统确实重用了undo段空间,擦除了旧的undo数据(查询随后会用到这些undo信息),你就有大麻烦了.select会失败，update也会中途停止。
反过来讲，在过程性循环中如果提交不那么频繁也可能会造成undo表空间被占满的情况，发生ora-30036错误，不能扩展undo表空间段。 v$undostat
2.在JDBC连接中关闭自动提交。P261
Connection con = DriverManager.getConnection("jdbc:oracle:oci:@database","scott","tiger");
conn.setAutoCommit(false);
3.分布式事务2PC协议。P262
oracle为实现分布式事务的提交，使用了一个2pc协议(two-phase commit protocol,二段提交协议)来做到这一点。2pc是一个分布式协议，如果一个修改影响到多个不同过的数据库，2pc允许原子性的提交这个修改。它会在提交之前尽可能的关闭分布式失败窗口。在多个数据库之间的一个2pc事务中，其中一个数据库（通常是客户最初登录的那个数据库）会成为分布式事务的协调器。这个站点会询问其他站点是否已经准备好提交。实际上，这个站点会转向其他站点，问他们是否准备就绪。其他的每个站点会报告它的“就续状态”（Yes或NO），如果只要有一个站点投票No，整个事务就会回滚。如果所有站点都投票Yes，站点协调器会广播一条消息，使每个站点上的提交成为永久性的。
在2Pc投票之前，任何分布式错误都会导致所有站点回滚。
第9章
1.撤销操作是逻辑恢复到原来的样子 P271
通常来说对undo有一个误解,认为undo用于将数据库物理地恢复到执行语句或事物之前的样子,但实际上并非如此.数据库只是逻辑地恢复到原来的样子,所有修改都被逻辑地取消,但是数据结构以及数据库快本身在回滚后可能大不相同.原因在于:在所有多用户系统中,可能会有数十 数百甚至上千千个并发事务。数据库的主要功能之一就是协调对数据的并发访问。也许我们的事物在修改一些块，而一般来讲往往会有许多其他事务也在修改这些块。因此，不能简单地将一个块放回到事务开始前的样子，这样会撤销其他人（其他事务）的工作。
注意：直接路径操作会绕过表上的undo生成
2.11G新特性 延迟段创建 P272
11G下创建表，在没有插入数据之前表都是没有分配空间的。（deferred segment creating）
在执行create table 时不会分配任何存储空间，一个区段都不会分配。要延时到insert发生时才会真正创建段，回滚时，段将持久存储（段不会被删除）。
3.undo与redo 关系 P273
有意思的是，尽管undo信息存储在undo表空间或undo段中，但也会受到redo的保护。换句话来说，会把undo数据当成是表数据或索引数据一样，对undo的修改会生成一些redo,这些redo将记入日志。
4.回滚过程中从不涉及重做日志 P276
回滚过程中从不涉及重做日志。只有恢复和归档才会读取重做日志。这对于调优是一个很重要的概念：重做日志是用来写的（而不是用于读）。Oracle不会在正常的处理中读取重做日志。只要你有足够的设备，使得ARCH读取文件时，LGWR能够写到另一个不同的设备（也是redo文件放在不同位置盘），就不存在重做日志竞争。许多其他数据库（非Oracle）都把日志文件处理为“事务日志”，这些数据库没有把redo和undo分开，对于这些系统，回滚可能是灾难性的，回滚进程必须读取日志，而日志写入器正在试图写这个日志，这就像系统中最薄弱的环节引入了竞争。Oracle的目标是：可以顺序地写日志，而且在写日志时别人不会读日志。
5.必须非常谨慎地使用NOLOGGING模式 P287
必须非常谨慎地使用NOLOGGING模式，而且要与负责备份和恢复的人沟通之后才能使用。下面假设你创建了一个非日志模式的表，并作为应用的一部分（例如，升级脚本中使用了create table as select nologging)。用户白天修改了这个表。那天晚上，表所在的磁盘出了故障。"没关系，"DBA说，"数据库在用ARCHIVELOG模式运行，我们可以执行介质恢复。"不过问题是，现在无法从归档重做日志恢复最初的创建的表，因为根本没有生成日志。这个表将无法恢复。由此可以看出使用NOLOGGING操作最重要的一点是：必须与DBA和整个系统协调。如果你使用了NOLOGGING操作，而其他人不知道这一点，你可能就会拖DBA的后腿，使得出现介质失败后DBA无法全面恢复数据库。必须谨慎而且小心地使用这些NOLOGGING操作。
6.NOARCHIVELOG 模式下create index和rebuild index操作不会记录到操作日志中 P288
7.提交清除是怎么发生的 P291
在与我们的事务相关的提交列表中，Oracle会记录已修改的块列表。这些列表都有20个块，Oracle会根据需要分配多个这样的列表，直至达到某个临界点。如果我们修改iade块加起来超过了块缓冲区缓存大小的10%，Oracle会停止为我们分配新的列表。例如，如果缓冲区缓存设置为可以缓存3000个块，Oracle会为我们维护最多300个块(3000的10%).COMMIT作业时，Oracle会处理这些包含20个块指针的列表，如果块仍可用，它会执行一个很快的清理。所以，只要我们修改的块数没有超过缓存中总块数的10%，而且块仍在缓存中并且是可用的，Oracle就会在提交的时清理这些块。否则，它只会将其忽略（也就是说不清理）。
8.临时表也会生成redo P296 对于临时表只会为undo生成日志
第10章
1.表对应的段 P314
2.在手动段空间管理下freelists的设置 P319
3.pctfree/pctused
4.索引所占用的空间 P336
5.临时表的限制 P370
6.BTREE索引的扫描顺序
第11章 索引
1.索引的高度 P387
2.聚簇因子 P403
4.位图索引的一些缺点