Oracle数据库的经典问题snapshottooold是什么原因引起的

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不会出现这种问题