请问oracle的DEFAULT_MAINTENANCE_PLAN是干什么用的？

Question

如题。这个对oracle的性能会有影响吗？作用原理是怎么的？各位高手不吝赐教啊！

Answer 1

这个缺省资源计划起来的时候，是否可能会使一个查询任务挂住？遇到一个问题，在oracle上执行一个查询语句的时候挂住了，一直持续了10个小时左右才提示查询失败，返回的错误时ORA-01555 "Snapshot too old".百思不解啊！后来发现当天是周六，oracle的缺省资源计划打开了。请问各位是否可能是资源计划造成的问题。

Answer 2

/*
一般导致ORA-01555的原因是：
1. 回滚段数量不足，导致回滚段Transaction Slot被overwrite
2. 回滚段剩余空间不足，导致回滚段被overwrite
3. undo_retention(要大于执行运行时间最长的事务所需的时间)设置太小，导致expired回滚段被overwriteOracle9i以后，rollback segment一般采用自动回滚段管理，涉及的参数有：
undo_management                      string      AUTO
undo_retention                            integer     3600
undo_suppress_errors                 boolean     FALSE
undo_tablespace                         string      undotbs1
在自动回滚段管理中，回滚段的数量是由系统来决定的。
回滚段的扩展则要取决于undo tablespace的设置
undo_retention的实现是要取决于undo tablespace的大小，即使undo_retention设置很大，但是undo tablespace的大小不足以支持，还是会出现unexpired回滚段信息被overwrite，从而导致ORA-01555。
回滚段一般有3种状态：active（未提交的事务），expired（已经提交的事务，超过undo_retention)，unexpired(已经提交的事务，超过undo_retention)。expired回滚段有可能在后续的应用中被系统overwrite。undo tablespace的大小可以根据公式来计算：
SELECT ((ur * (ups * dbs)) + (dbs * 24)) / 1024 / 1024 AS "Bytes"
  FROM (SELECT VALUE AS ur
          FROM v$parameter
         WHERE NAME = 'undo_retention'),
       (SELECT MAX (undoblks / ((end_time - begin_time) * 86400)) AS ups
          FROM v$undostat),
       (SELECT block_size AS dbs
          FROM dba_tablespaces
         WHERE tablespace_name = UPPER ((SELECT VALUE
                                           FROM v$parameter
                                          WHERE NAME = 'undo_tablespace')))可能的解决办法：
1. 合理设置undo tablespace大小和undo_retention大小
2. 对于涉及到大数据量的update/delete操作，要分批Commit，减少对回滚段的冲击。
3. 对于查询SQL，要调整执行规划，增加合适的索引来缩短查询时间。
*/

Answer 3

快照过久有可能是你的undo段太小造成的。

Answer 4

其实我是想问，oralce的资源计划是否会造成查询任务长时间挂住：）