Oracle数据库的经典问题 snapshot too old是什么原因引起的
ORACLE经典错误求解:ORA-1555错误(Snapshot too old ) - ...
书上说是因为the rollback image need for read consistency has prbably been overwriteten by an active transaction. 我就奇怪了，如果一个transaction占用了一些回滚段，直到它commit前，这些回滚段空间应该被锁定了呀，怎么会被其他transaction覆盖了呢？
--------------------------
rollback segment 太小
--------------------------
snapshot too old 就是指你commit，前镜像被覆盖以后 如果有查询需要访问这个前镜像构建一致性读，就会导致ORA-01555错误
-----------------------------
加大你的undo segment 的 initial extents 值, 尽量减少warp，当然undo file 要够大：） -------------------------
A. 回滾段太少/太小 導致這個錯誤,可以 創建更多的回滾段, 為回滾段設置較大的EXTENT以及較大的MINEXTENTS B.由於回滾段被破壞, 造成事務無法將修改前的內容(read-consistent snapshot) 放入回滾段, 也會產生此錯誤. 可以將被破壞的回滾段OFFLINE, 刪除重建. C. 當一個進程打開一個CURSOR, 然後迴圈執行FETCH, UPDATE, COMMIT, 如果更新的表與FETCH的是同一個表, 就很可能發生此錯誤. 解決方法: a. 使用大的回滾段 ,b. 減少提交頻率c. 建立一個臨時表, 存放要更新的表的查詢列(如主鍵及相關的條件列), 從臨時表FETCH, 更新原來的表. D. 不適當的OPTIMAL參數: 太小的OPTIMAL參數會使回滾段很快被SHRINK, 造成後續讀取操作訪問時, 先前的內容已丟失. 仔細設計OPTIMAL參數, 不要讓回滾段過於頻繁的EXTEND/SHRINK有助於問題的解決. E. DB BLOCK BUFFER太小: 如果讀一致性所請求的塊的先前內容在緩衝區中, 那麼就不用去訪問回滾段. 而如果緩衝區太小, 使得先前版本的內容在CACHE中的可能性變小, 從而必須頻繁的訪問回滾段來獲取先前的內容, 這將大大增大此錯誤發生的可能.
----------------------------
假设你的emp表很大，你在18：00运行
select * from emp;
这个语句的输出结果应该只取决于18:00的时候emp表的数据状态，但事实上，由于emp表很大，你这个语句可能要运行10分钟，然后才看到输出结果
在18:01，有人在emp表上做了一个update，update直接做到表上了，怎样使你18：00运行的select还能看到之前的数据呢？oracle用的是查询前映的办法，即把update之前的数据放到回滚段里保存，使你的select在查询到那个block的时候，会跳转去找前映，这样可以使你的select能正确运行下去。
但可能发生这种情况，就是做update的人commit了，于是前映就有可能在被你的select访问到之前被覆盖，假如真的发生了这种情况，snapshot too old的错误就出现了 ------------------------
这也说明了你的SQL执行得太慢了，需要调整，在9i中有一个undo_retention参数，假设期指定1小时，那么超过1小时的SQL就容易出现snapshot too old的错误了。 -----------------------------
----------------------------
MySQL不会出现这种问题