延迟段创建： ?
create table的时候，并没有真正分配段，而已等真正需要insert的时候才进行分配空间。
?
?
Update+ Commit所做的工作：
update:
update:
- 生成undo信息
- 修改数据块
- 给数据块加锁标记，得到锁
- 生成Redo信息
commit:
- 为事务生成SCN，计数
- LGWR把Redo日志写入到磁盘 -- IO最花时间, ?PLSQL中的Commit不会等LGWR写入磁盘，立刻返回。而其他的调用则需等待
- V$Transaction中删除事务记录
- V$Lock中记录的锁释放
- 清除块上的锁信息
所以commit过程的工作确实不多。
?
?
Update + Rollback所做的工作：
?
update:
- 生成undo信息
- 修改数据块
- 给数据块加锁标记，得到锁
- 生成Redo信息
rollback:
- 从undo读取数据，应用到数据块
- V$Transaction中删除事务记录
- V$Lock中记录的锁释放
- 清除块上的锁信息
- 清除Redo的缓存
Redo的测量
Redo语句以测量， redo的数量越多，系统就越慢。从DB Trace里面可以跟踪到， Redo是DB中的一个串行点，
?
?
Nologging:
不使用日志的情况，也就是不需要恢复数据。 比如索引的创建，即使介质出问题，索引还是可以重建。
?
?
临时表：
oracle的临时表，不会生成redo, 但是会生成undo. ?所以他是不能恢复的。
临时表有支持多版本控制和并发，能够回滚，所以undo是必须的。
?
?
Truncate table和Delete Table：
我们都知道truncate table是很快，而delete table很慢。 一个主要原因是truncate是DDL，没有undo信息生成
?
?
?
Undo信息生成的DML排名
Insert语句生成很少的Undo，因为只为rowid生成Undo
update语句的Undo集中在被修改的字段上面， 而如果是带索引的字段修改，那么Undo是2.5倍
delete生成的Undo最多，整行的生成，所以开销是最大。 ?
?
所以避免在同步过程中执行delete的操作是一个好的编程习惯。
?
?
ORA-1555 Snapshot Too Old
这是一个经常见到的问题， 影响到查询语句，使收到这个错误的查询语句不能继续,它和数据破坏或者数据丢失完全没有关系，根本原因是提交得太过频繁。
由于读一致的存在，一个较长时间的查询访问到了一个undo块，但是由于undo的空间太少，这个undo块在后来的查询等待中，被其他的session所修改，那么这个查询就会返回这个错误。
?
为了避免这个问题，可以设置自动管理Undo ?UNDO_RETENTION，让DB内置的"DBA"根据动态的数据来管理空间分配。
?
