数据库事物
ref：http://www.cnblogs.com/quanweiru/archive/2013/05/24/3097367.html
undo 表空间
表空间的用途
保证读写一致性
ref：http://blog.itpub.net/29119536/viewspace-1136286/
回滚，闪回（redo？） 待查，不过以后是不是oracle会慢慢退出舞台啊。。。
表空间不足
表空间不足会导致上图中事物无法建立新的undo块，导致读写一致性问题
表空间超时
执行sql时 undo块失效，为了保证一致性 而禁止写入
结论：
写sql的时候要尽快提交以释放undo资源
sql优化，
一般来讲会有解析sql的过程。。。
要用关联
select a.xx,b.xx from xxx a,yyy b where a.pid=b.fid
而不要用
select a.xx,b.xx from xxx a,yyy b where b.fid in (select a.pid from xxx a)
说道优化，一半来讲就是索引，分区，join
分区 建立分区 搜索指定分区
索引一半来讲要走unic index（很快） 其次是其他索引
join要用小表（结果集）去关联大的结果集 以实现nest loop join，避免hash join
索引和join可以用hint指定
refactor 聚合系数和dbms 收集job会自动统计信息
手工调用
存储过程优化，
批量插入， 删除， 游标cusor的开关，
select bulk collect into
forall
注意可能引起的undo问题
savepoint不能被rollback 两次
excepiton handling
表锁，行锁
并未研究过，求案例
一半来讲是死锁，也就是之前有没commit的事物导致，一半逻辑代码很少有死锁的。。。如果有 说明逻辑。。。
索引建立，本人并未实际碰到过复杂索引问题：
ref：http://www.cnblogs.com/aspnethot/articles/1504082.html
其原因在于：
“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。
当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。
在范式设计能满足效率或适当反范式化能满足效率的前提下。。。也就不用过多复杂索引了
聚集索引
非聚集索引
一种索引，该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
| 动作描述 | 使用聚集索引 | 使用非聚集索引 |
| 列经常被分组排序 | 应 | 应 |
| 返回某范围内的数据 | 应 | 不应 |
| 一个或极少不同值 | 不应 | 不应 |
| 小数目的不同值 | 应 | 不应 |
| 大数目的不同值 | 不应 | 应 |
| 频繁更新的列 | 不应 | 应 |
| 外键列 | 应 | 应 |
| 主键列 | 应 | 应 |
| 频繁修改索引列 | 不应 | 应 |
