2013年（350）
分类： Oracle
2013-04-25 11:10:10
5、 Query的制约因素
制约该特性应用的有三方面的因素，
5.1 自动撤销表空间
这个是前面也提到了，要使用flashback的相关特性，必须启用自动撤销管理表空间，不仅是flashback query,也包括flashback table和flashback database，而对于后两项还会有些其它的附加条件，比如flashback table需要启用了recycle bin(回收站)，flashback database还要求必须启用了flashback area(区)。
附A：
提示：什么是Automatic Undo Management(自动撤销管理表空间)
提到自动撤销管理表空间，就不得不提手动管理的回滚段，接触过9i之前版本的朋友对此一定有所了解(就俺看来，已经可以将其划归到历史的行列中了)。在9i之前，回滚段的管理和监控是需要dba手工介入的，创建合适的回滚段是件非常耗费dba精力的事情，你可能需要不断关注oracle运行状况很长一阵子时间后，通过不断的调整才能基本确认一段时期内回滚段的大小，一旦回滚段创建的不合适，就极有可能引起性能问题甚至错误，比如ora-1555就是典型的回滚段设置不合适触发的。
9i之后呢(含9i)，oracle为了清晰它的整个概念，取消了回滚段这个说法(实际上并未取消回滚段)，而完全以undo来代替，这也它正好与redo相对应，一个重做，一个撤销，对于新接触oracle的朋友来说也更加容易理解。回滚段可以不再由dba手工介入，而是完全由它自己在运行时自动分配，这在一定程度上即解放了dba，也确实起到了提高性能的作用，比如采用自动管理表空间就可以最大程序的降低ora-1555发生的机率(注意是降低，不是避免，我们不可能创建一个无限大的回滚段，ora-1555也并不完全是回滚段造成的，关于ora-1555的问题这里就不深入讨论了，互联网上已经有太多文章描述和介绍该问题及解决方案)
是否起用自动管理的撤销表空间由二个初始化参数决定：
UNDO_MANAGEMENT：值为AUTO表示使用了自动撤销管理表空间，MANUAL则表示手动管理
UNDO_TABLESPACE：当UNDO_MANAGEMENT值为AUTO时，该参数用来指定当前的undo表空间名称。
undo表空间的大小，直接影响到flashback query的查询能力，因为多版本查询所依赖的undo数据都存储在undo表空间中，该表空间越大，所能够存储的undo数据自然也越多，如果该表空间可用空间非常小，别说flashback了，恐怕正常查询都有可能触发ora-1555吧。
5.2 初始化参数
初始化参数UNDO_RETENTION的设置严格说起来也是与undo表空间有关系，但是思量再三，我觉着还是有必要单拎出来详细介绍。
该参数用来指定undo记录保存的最长时间，以秒为单位，是个动态参数，完全可以在实例运行时随时修改通常默认是900秒，也就是15分钟。
一定要注意，undo_retention只是指定undo数据的过期时间，并不是说，undo中的数据一定会在undo表空间中保存15分钟，比如说刚一个新事务开始的时候，如果undo表空间已经被写满，则新事务的数据会自动覆盖已提交事务的数据，而不管这些数据是否已过期，因此呢，这就又关联回了第一点，当你创建一个自动管理的undo表空间时，还要注意其空间大小，要尽可能保证undo表空间有足够的存储空间。
同时还要注意，也并不是说，undo_retention中指定的时间一过，已经提交事务中的数据就立刻无法访问，它只是失效，只要不被别的事务覆盖，它会仍然存在，并可随时被flashback特性引用。如果你的undo表空间足够大，而又不是那么繁忙，那么其实undo_retention参数的值并不会影响到你，哪怕你设置成1(这么说好像绝对了点，大家一定要注意理解，表钻牛角尖)，只要没有事务去覆盖undo数据，它就会持续有效。因此呢，这里还是那句话，要注意undo表空间的大小，保证其有足够的存储空间。
提示：
只有在一种情况下，undo表空间能够确保undo中的数据在undo_retention指定时间过期前一定有效，就是为undo表空间指定Retention Guarantee，指定之后，oracle对于undo表空间中未过期的undo数据不会覆盖，例如：
SQL> Alter tablespace undotbs1 retention guarantee;
如果想禁止undo表空间retention guarantee，如例：
SQL> Alter tablespace undotbs1 retention noguarantee;
转了一圈，问题又回来了，既然它看起来有用又像没有用，为什么还要设置它呢，黑黑，就我理解，其存在的真实用途，就是提醒你undo表空间很重要，给它指定分配一个合适的大小，更重要哟。
5.3 DDL操作的影响
第三个就是修改并提交过数据之后，对表做过DDL操作，包括：
drop/modify列, move表, drop分区(如果有的话), truncate table/partition，这些操作会另undo表空间中的撤销数据失效，对于执行过这些操作的表应用flashback query会触发ORA-01466错误。另外一些表结构修改语句虽然并不会影响到undo表空间中的撤销记录，但有可能因表结构修改导致undo中重做记录无法应用的情况，比如对于增加了约束，而flashback query查询出的undo记录已经不符合新建的约束条件，这个时候直接恢复显然不可能成功，你要么暂时disable约束，要么通过适当逻辑，对要恢复的数据进行处理之后，再执行恢复。
另外，flashback query对v$tables,x$tables等动态性能视图无效，不过对于dba_*,all_*,user_*等数据字典是有效的。同时该特性也完全支持访问远端数据库，比如select * from tbl@dblink as of scn 360;的形式。
===================================
