rose的专栏

dbms_stats包分析表，no_invalidate参数有3个选项：TRUE : 不让相关游标失效 FALSE: 立即让相关游标失效 AUTO_INVALIDATE(default):让Oracle自己决定何时让游标失效。 10G后如果不指

场景1:执行计划走错了，你重新分析了表，发现ORACLE依然在用之前错误的执行计划，新的统计信息没有起作用。场景2:有一条SQL占用的共享池内存过大，你想把这个游标清理出去通常有以下几种办法：1）对表做一个grant ,revoke操作，这样的话，表上的所有游标都会失

目前所负责的数据库压力过大，要把其中一个比较核心的SCHEMA迁移到另一套环境里来降低压力。迁移前后的版本是一样的，都是11.1.0.7.统计信息也是通过DBMS_STATS包导出导入的，按理说，执行计划变化的可能性不大。但是为了确保执行计划不出错，打算还是折腾一把，通过11G的

shrink space分两个阶段：1）通过把segment后面的数据delete，然后insert到segment的前面，来把表里的块变得更加紧凑。这个操作的事务单位比较小，操作过程中，会在表上加模式为3的表锁，这种锁的等级跟DML事务在表上加的锁等级一样，一般比较安全，不会阻塞这个表上的DML操作。在这个过程中即使把当前会话取消掉，也不会有风险。下次可以继续上一次的操作。而不是很多人理解的