oracle資料庫回滾

Ⅰ oracle資料庫中數據回滾的概念

commit-提交
rollback-回滾，即撤銷對數據的改動，不保存到資料庫

Ⅱ oracle 提交數據，怎麼回滾

execute執行後 可以回滾

commit提交後 不可以回滾

其實Oracle提交數據是分兩步操作的，第一步execute執行，第二步commit提交。對應的PL\sql也是要先點execute執行，執行後再點commit提交。
但是 commit提交後 可以用閃回查詢恢復原來的數據 因為oracle會將近期的數據保存到快照中 如:

SELECT * FROM TABLE_1 AS OF TIMESTAMP TO_TIMESTAMP('20080606 20:00:00','YYYYMMDD HH24:MI:SS');
這里'20080606 20:00:00'就是你想恢復數據到哪個時間狀態 TABLE_1是資料庫的表名 這樣查詢到的數據就是執行更新操作之前的數據

Ⅲ oracle資料庫引起自動回滾的原因

比如說你的事務未提交進程意外終止（
掉線
啊，點擊
叉叉
退出連接啊）未提交的數據全部
回滾
。或者在你的事務提交過程中，數據違反約束條件，事務內部出現錯誤被終止，則該事務中所有操作也被自動回滾。還有其他一些情況，這兩個是主要的。

Ⅳ oracle 刪除數據提交怎麼回滾

execute執行後
可以回滾
commit提交後
不可以回滾
其實oracle提交數據是分兩步操作的，第一步execute執行，第二步commit提交。對應的pl\sql也是要先點execute執行，執行後再點commit提交。
但是
commit提交後
可以用閃回查詢恢復原來的數據
因為oracle會將近期的數據保存到快照中
如:
select
*
from
table_1
as
of
timestamp
to_timestamp('20080606
20:00:00','yyyymmdd
hh24:mi:ss');
這里'20080606
20:00:00'就是你想恢復數據到哪個時間狀態
table_1是資料庫的表名
這樣查詢到的數據就是執行更新操作之前的數據

Ⅳ oracle 提交之後怎麼回滾

execute執行後
可以回滾
commit提交後
不可以回滾
其實Oracle提交數據是分兩步操作的，第一步execute執行，第二步commit提交。對應的PL\SQL也是要先點execute執行，執行後再點commit提交。
但是
commit提交後
可以用閃回查詢恢復原來的數據
因為oracle會將近期的數據保存到快照中
如:
SELECT
*
FROM
TABLE_1
AS
OF
TIMESTAMP
TO_TIMESTAMP('20080606
20:00:00','YYYYMMDD
HH24:MI:SS');
這里'20080606
20:00:00'就是你想恢復數據到哪個時間狀態
TABLE_1是資料庫的表名
這樣查詢到的數據就是執行更新操作之前的數據

Ⅵ oracle中數據是怎樣前滾和回滾的

保持數據一致性和完整性，是每一款成功商業資料庫軟體都必須要做到的基本要求。從故障中恢復，保證ACID原則，保證事務完整性，一直是Oracle資料庫核心功能組成部分。本篇主要介紹Oracle實例意外終止（斷電或者強制關閉）之後，重新啟動時發生的恢復過程，也可以稱作「前滾和回滾」。
基礎知識說明
為了更明確的說明問題，筆者首先介紹一下本文涉及到的一些重要知識。
資料庫實例失敗
我們經常說的資料庫伺服器failure是有多層含義的。Oracle資料庫是一個由多進程組件共同構成的結構體系。最重要的部分包括監聽器、Oracle資料庫實例兩個部分，當然還包括各類文件，更廣義的還有硬體和操作系統OS。不同部分的Failure現象和處理方法都有所不同。本文所闡述的過程是Oracle實例失敗後的自動恢復過程。
在實例失敗的時候，往往是突然性的終止。此時Oracle資料庫可能在進行一系列完成或者未完成的事務。實例失敗恢復，就是要將這些狀態進行還原，恢復到數據完整性的狀態。
寫日誌（RedoLog）在先機制
Oracle資料庫是採用「日誌在先」機制的。當我們對資料庫數據進行修改時，並不是立即將修改寫入到文件中，而是寫入到共享內存SGA空間中的BufferCache里。同時，將修改的日誌不斷的寫入到SGA中另一塊Log Buffer緩存中。有一個後台進程LGWR不斷的將LogBuffer緩存中的日誌內容寫入到online redo log文件中。
寫入LogBuffer緩存和LGWR寫入文件的過程是非同步進行的。那麼LGWR會在哪些情況下將日誌緩沖區(全部內容)轉儲到日誌文件呢？如下：--參考OCA認證考試指南(1Z0-052,P40)ü 用戶進行直接的commit操作；
ü RedoBuffer數據超過1/3；
ü DBWn啟動，將BufferCache中的臟數據寫入到文件中；ü 距離上次LGWR寫入操作超過三秒(三秒超時，DBWn每三秒鍾會對一些緩沖區清理一次，這個時候，剛好符合觸發LGWR的第三點)；而數據文件寫入進程DBWn工作的觸發點(此處注意：DBWn會將高速緩沖區的臟緩沖區,即臟數據塊寫入數據文件，而不是緩沖區里頭的全部內容---參考OCA認證考試指南(1Z0-052,P38))。
因為考慮到磁碟I/O會降低性能，DBWn採用的是極懶演算法執行寫入。如果對於經常變臟的緩沖區，即這邊緩沖區處於十分忙碌的狀態，那麼DBWn不會將緩沖區寫入磁碟的。反而一段時間來，任何會話都未曾關注的一些緩沖區，DBWn會將其寫入到磁碟。因此DBWn寫臟緩沖區比較平緩和低頻率。但如果出現檢查點的情況例外：DBWn會將所有臟緩沖區全部寫入磁碟。---參考OCA認證考試指南(1Z0-052,P38中，P39)。
ü 當BufferCache中沒有任何可用緩沖區；ü 臟緩沖區過多；
ü 遇到三秒超時(DBWn每三秒鍾會對一些緩沖區清理一次)ü 遇到檢查點
綜合DBWn和LGWR工作的特點，我們可以得到日誌文件的幾個特點：
首先，日誌文件的寫入是很頻繁的。LGWR會不斷將日誌信息從LogBuffer中寫入Online Redo Log；其次，在日誌文件上，可以有三個類型的事務事件。
1、事務結束，已經被commit，之後打過checkpoint檢查點。這種事務記錄在LogFile上，但是變化信息已經被DBWn寫入進數據文件；2、事務結束，已經被commit，之後沒有打入checkpint檢查點。這種情況下，LogFile已經寫入了日誌項目，數據文件可能包括臟數據，也可能沒有寫入臟數據；3、事務未結束，沒有commit。這種時候，數據塊DirtyBlock上面是有事務槽信息，表示未結束事務，是不會將數據寫入到數據文件中。但是，日誌LogBuffer可能將部分未提交的DML操作項目寫入到Log File中；檢查點Checkpoint
檢查點Checkpoint是資料庫一致性檢查的一個標記。簡單的說，就是在這個點上，Oracle保證各個文件（數據、控制、日誌等）是一致的。檢查點的作用就是在進行實例恢復的時候，告訴SMON進程，這個點之前的內容不需要進行恢復。
前滾和回滾介紹
「前滾和回滾」是Oracle資料庫實例發生意外崩潰，重新啟動的時候，由SMON進行的自動恢復過程。下面通過模擬實例和講解介紹這個過程。
失敗前場景說明
日誌中記錄過程如下：
1、事務A進行之後，結束commit。之後系統進行了一次checkpointA；2、Checkpoint之後，進行事務B，結束commit；3、進行事務C，C事務量較大，其中進行了一定量的RedoLog文件寫入。之後系統斷電；--按照LGWR的工作機制，C事務量比較大，所以應用程序將在幾分之一秒內的時間里生成足以填充1/3秒的重做內容，因此這會觸發LGWR將日誌緩沖區的內容轉儲到日誌文件，但始終得不到針對C事務的提交記錄，這是需要回滾的。
4、還有種可能，事務B和D，事務D所用的緩沖區處於高速緩沖區不活躍的位置，而且事務B已提交，但其所用的緩沖區處於高速緩沖區活躍的位置。因此DBWn會將D事務緩沖區數據寫入數據文件，而沒將B事務的數據寫入。此種情況需要回滾D事務，保留B事務。---參考OCP認證考試指南全冊（P358下半部分內容).
1、系統啟動過程，進入實例恢復階段
當實例意外中斷的時候，各類型文件，包括控制文件、數據文件和日誌文件上，會存在不一致的問題。這種不一致主要體現在SCN值的差異上。
實例在啟動的時候，經過三階段（nomount、mount和open）。在open之前，會進行這種不一致現象的檢查，如果出現不一致，要啟動SMON進程的恢復流程。
SMON是Oracle實例的一個後台進程，主要負責進行系統監控恢復。進行恢復的依據主要是RedoLog記錄。
2、前滾進程
SMON首先找到最後SCN記錄的Redo LogFile。尋找最後一個打入的Checkpoint。
順序找到CheckPointA之後，表示A之前的所有事務都是完全寫入到數據文件中，不存在不一致性問題。恢復過程從CheckpointA開始，Oracle開始依據重做日誌Redo Log的系列條目，進行推進。
首先遇到了事務B信息，由於事務B已經commit，所以事務B所有相關的Redo Log條目已經全都寫入到Redo LogFile中。所以，按照日誌繼續條目推進，完全可以重演replay，並且應用apply事務B的全部過程。
這樣，事務B全部實現，最終將通過DBWn完全寫入到數據文件中。所以，實例失敗之前提交commit的事務B，完全恢復。
進入事務C的范疇，由於一部分事務C的RedoLog條目已經進入Redo LogFile中(根據LGWR和DBWn的工作機制，事務C有可能將部分數據塊寫入日誌文件和數據文件，但這時候C事務始終沒提交，這是比較嚴重的訛誤，所以需要回滾)，所以在進行前滾的時候，一定會replay到這部分的內容。不過，這部分內容中不可能出現commit的標記。所以，前滾的結果一定是遇到實例突然中斷的那個時點。此時replay的結果是，事務C沒有提交。這樣結束了前滾過程，進入回滾階段。
3、回滾過程(與普通的回滾一樣（當事務執行失敗後自動回滾或者命令:ROLLBACK.）---參考OCP認證考試指南全冊)對事務C(針對DML的update，當然其他同理)，要進行回滾過程，釋放所有相關資源。在前滾中，利用日誌填充了的撤銷塊和表數據塊的值，然後在回滾的時候，會將撤銷塊的值復制回表數據塊中(因為此事務沒提交記錄)，以此來進行SGA中BufferCache數據塊恢復。
4、說說恢復過程的損耗
很多時候，由於我們事務規模較大，當出現實例崩潰的時候，重啟所需要的時間很多。有一種經驗說法是，事務有多長，前滾和回滾所消耗的時間有多長×2。而且，如果不能完成SMON恢復過程，資料庫是不能算作正常的Open的。
SMON的恢復過程是Oracle強制進行的一個過程，即使恢復中發生斷電或者其他中斷失敗事件。Oracle在下一次啟動的時候，還是會繼續這個過程，只有耐心等待。
通過檢查一些內部視圖（X$視圖），可以觀察到恢復進程和速度，但是絲毫不能影響到最終恢復的過程。
這個過程雖然可以保證數據一致性，但是也帶來了系統不能啟動，影響生產環境的問題。我們可以通過兩個方式進行緩解：
首先，我們在設計開發系統時，要保證事務規模的可控性，不要讓事務規模在技術層面上過大。避免一旦發生崩潰，大規模強制回滾的發生；其次，一旦出現了這個強制回滾，要注意對生產環境的影響。可以採用備庫standby進行頂替，讓主庫安靜的慢慢恢復；

Ⅶ Oracle資料庫中為什麼會產生回滾與前退

在一個transaction發生的過程中，online redo log首先記錄transaction中修改的數據塊相關信息，修改的數據塊會被緩存在database buffer cache中。由於database buffer cache寫滿或者checkpoint等等條件觸發dbwn進程，會導致這些緩存的數據塊寫入數據文件，但此時可能該transaction仍然還沒有提交。所以在數據文件中，可能會有commited 和 uncommited 的數據塊。而原有的數據塊鏡像會存放在undo segment。 IXDBA.NET社區論壇 然而，dbwn寫臟數據時不管這個要寫的transaction是否提交， 也沒有必要去管。 這樣就發生了所謂的已經提交的數據，但是還沒有寫入數據文件的現象。 還有一種情況，數據沒有提交，但是已經被寫入數據文件，此時發生回退，撤銷沒有提交的數據。 根本原因是commit後寫redo buffer和觸發lgwr寫 redo buffer的區別。 事務在執行完畢後，隨即會被寫入redo buffer和undo中，同時在redo buffer和undo中對該事務都有一個是否提交的標記。兩者的默認狀態都是active的，即沒有提交時刻處於激活狀態。 commit操作執行時刻把此前的所有事務操作全部寫入redo log file，commit成功後，redo buffer信息全部寫入redo file，同時修改兩者中的事務提交標識為inactive，表示此前事務已經遞交。 oracle的前滾和回退根據就是依據事務是否提交而進行的。 在觸發lgwr進程後，oracle同樣把此前的redo buffer信息寫入redo file，但是與commit觸發寫日誌不同的是，redo file本身對lgwr寫日誌操作不記錄任何信息標識，lgwr寫到那裡就是那裡，就算此時掉電也無妨，redo file就記錄到掉電時刻的信息。 lgwr是一個Oracle後台執行的進程，具體的日誌寫操作都有oracle去控制，這對於oracle來說是透明的，因此不用在redo file中寫入任何標記信息，這也是正常的。 於是，Oracle崩潰恢復步驟如下： 首先rolling forward 前滾：由於oracle failure，sga中的內存信息丟失了，但是online redo log中還是存儲了transaction信息，包括commited or uncommited data。可能這些修改信息並沒有被oracle正確的來處理，包含兩種情況：已經提交的還沒有寫入數據文件，或者沒有提交的卻被寫入了數據文件。針對已經提交的還沒有寫入數據文件就要發生前滾，在前滾過程中，smon會根據online redo log中的記錄來完成對datafile的修改。保證已經提交的數據已經寫入數據文件。 接下來，前滾結束後，資料庫正常open，此時用戶可以正常連接，可以訪問已經recover的commited data，但是對於那些屬於unrecoverable transaction的uncommited data，會被oracle 加鎖，是不可以訪問的。

Ⅷ oracle資料庫回滾

開沒開歸檔，如果沒開市回滾不了的

Ⅸ oracle資料庫庫刪除怎麼回滾

刪除表後，可以採用如下操作：
在 user_recyclebin中找到最近操作過的表名稱，然後用閃回（只能用於10G及以上版本）。
FLASH BACK TABLE TABLE_NAME TO BEFORE DROP;
如果是刪了或修改裡面的數據，可以先建立一個快表將刪除修改之前狀態的數據找回到這個表中：
CREATE TABLE QUICK_TABLE AS
SELECT * FROM TABLE_NAME AS OF TIMESTAMP SYSTEM-1/24 (一小時前的)，減去的時間可以自己定。如樓上F_253那位老兄的寫法就不錯，能自由定製時間