一、快照太老例子：
1、创建一个很小的undo表空间，并且不自动扩展。
create undo tablespace undo_small
datafile ‘/u01/app/oracle/oradata/prod/undo_small01.dbf‘ size 2m
autoextend off;
2、让系统使用该undo表空间
alter system set undo_tablespace = undo_small;
3、用普通用户创建一张表，我们将建立表T 来查询和修改。注意我们在这个表中随机地对数据排序。CREATE TABLE AS
SELECT 力图按查询获取的顺序将行放在块中。我们的目的只是把行弄乱，使它们不至于认为有某种顺序，
从而得到随机的分布：：
create table t
as
select *
from all_objects
order by dbms_random.random;
4、创建一个主键约束，目的是创建一个索引：
alter table t add constraint t_pk primary key(object_id);
5、收集表的统计信息，目的是让优化器使用索引：
exec dbms_stats.gather_table_stats( user, ‘T‘, cascade=> true );
6、现在开始修改表：
begin
for x in ( select rowid rid from t )
loop
update t set object_name = lower(object_name) where rowid = x.rid;
commit;
end loop;
end;
7、在运行这个修改的同时，我们在另一个会话中运行一个查询。这个查询要读表T，并处理每个记录。
获取下一个记录之前处理每个记录所花的时间大约为1/100 秒（使用DBMS_LOCK.SLEEP(0.01)来模拟）。在
查询中使用了FIRST_ROWS 提示，使之使用前面创建的索引，从而通过索引（按OBJECT_ID 排序）来读出表
中的行。由于数据是随机地插入到表中的，我们可能会相当随机地查询表中的块。这个查询只运行几秒就
会失败：
declare
cursor c is
select /*+ first_rows */ object_name
from t
order by object_id;
l_object_name t.object_name%type;
l_rowcnt number := 0;
begin
open c;
loop
fetch c into l_object_name;
exit when c%notfound;
dbms_lock.sleep( 0.1 );
l_rowcnt := l_rowcnt+1;
end loop;
close c;
exception
when others then
dbms_output.put_line( ‘rows fetched = ‘ || l_rowcnt );
raise;
end;
8、解决办法：
可以看到，在遭遇ORA-01555:snapshot too old 错误而失败之前，它只处理了253 个记录。要修正
这个错误，我们要保证做到两点：
1、数据库中UNDO_RETENTION 要设置得足够长，以保证这个读进程完成。这样数据库就能扩大undo 表空间来保留足够的undo，使我们能够完成工作。
2、undo 表空间可以增长，或者为之手动分配更多的磁盘空间。
对于这个例子，我认为这个长时间运行的进程需要大约600 秒才能完成。我的UNDO_RETENTION 设置
为900（单位是秒，所以undo 保持大约15 分钟）。我修改了undo 表空间的数据文件，使之一次扩大1MB，
直到最大达到2GB：
这里没有收到错误，我们成功地完成了工作，而且undo 扩大得足够大，可以满足我们的需要。
在这个例子中，之所以会得到错误只是因为我们通过索引来读表T，而且在全表上执行随机读。如果不是
这样，而是执行全表扫描，在这个特例中很可能不会遇到ORA-01555 错误。原因是SELECT 和UPDATE 都要
对T 执行全表扫描，而SELECT 扫描很可能在UPDATE 之前进行（SELECT 只需要读，而UPDATE 不仅要读还
有更新，因此可能更慢一些）。如果执行随机读，SELECT 就更有可能要读已修改的块（即块中的多行已经
被UPDATE 修改而且已经提交）。这就展示了ORA-01555 的“阴险”，这个错误的出现取决于并发会话如何访
问和管理底层表。