自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Oracle數(shù)據(jù)庫中為什么會產(chǎn)生回滾與前退

數(shù)據(jù)庫 Oracle
Oracle數(shù)據(jù)庫操作中經(jīng)常會遇到一些故障問題,遇到問題時就要自己盡量解決,有時Oracle數(shù)據(jù)庫中會出現(xiàn)回滾與前退的問題,下面就為大家分析為什么Oracle數(shù)據(jù)庫中會出現(xiàn)回滾與前退的問題呢。

導(dǎo)讀:Oracle數(shù)據(jù)庫概念問題,假如數(shù)據(jù)沒有提交,但是卻被dbwn進(jìn)程寫入了數(shù)據(jù)文件,會怎么樣呢?下文中將通過案例分析,詳細(xì)的為大家解析問題。

案例分析:

  首先說明的是dbwn寫臟數(shù)據(jù)跟commit提交沒有關(guān)系!

  在一個transaction發(fā)生的過程中,online redo log首先記錄transaction中修改的數(shù)據(jù)塊相關(guān)信息,修改的數(shù)據(jù)塊會被緩存在database buffer cache中。由于database buffer cache寫滿或者checkpoint等等條件觸發(fā)dbwn進(jìn)程,會導(dǎo)致這些緩存的數(shù)據(jù)塊寫入數(shù)據(jù)文件,但此時可能該transaction仍然還沒有提交。所以在數(shù)據(jù)文件中,可能會有commited 和 uncommited 的數(shù)據(jù)塊。而原有的數(shù)據(jù)塊鏡像會存放在undo segment。

  IXDBA.NET社區(qū)論壇

  然而,dbwn寫臟數(shù)據(jù)時不管這個要寫的transaction是否提交,

  也沒有必要去管。

  這樣就發(fā)生了所謂的已經(jīng)提交的數(shù)據(jù),但是還沒有寫入數(shù)據(jù)文件的現(xiàn)象。

  還有一種情況,數(shù)據(jù)沒有提交,但是已經(jīng)被寫入數(shù)據(jù)文件,此時發(fā)生回退,撤銷沒有提交的數(shù)據(jù)。

  那么,引發(fā)Oracle前滾與回退的根本原因就是什么呢?

  根本原因是commit后寫redo buffer和觸發(fā)lgwr寫 redo buffer的區(qū)別。

  事務(wù)在執(zhí)行完畢后,隨即會被寫入redo buffer和undo中,同時在redo buffer和undo中對該事務(wù)都有一個是否提交的標(biāo)記。兩者的默認(rèn)狀態(tài)都是active的,即沒有提交時刻處于激活狀態(tài)。

  commit操作執(zhí)行時刻把此前的所有事務(wù)操作全部寫入redo log file,commit成功后,redo buffer信息全部寫入redo file,同時修改兩者中的事務(wù)提交標(biāo)識為inactive,表示此前事務(wù)已經(jīng)遞交。

  oracle的前滾和回退根據(jù)就是依據(jù)事務(wù)是否提交而進(jìn)行的。

  在觸發(fā)lgwr進(jìn)程后,oracle同樣把此前的redo buffer信息寫入redo file,但是與commit觸發(fā)寫日志不同的是,redo file本身對lgwr寫日志操作不記錄任何信息標(biāo)識,lgwr寫到那里就是那里,就算此時掉電也無妨,redo file就記錄到掉電時刻的信息。

  lgwr是一個Oracle后臺執(zhí)行的進(jìn)程,具體的日志寫操作都有oracle去控制,這對于oracle來說是透明的,因此不用在redo file中寫入任何標(biāo)記信息,這也是正常的。

  commit操作是唯一一個可以前臺操作與oracle后臺通信的指令,因此當(dāng)加入這個操作以后,oracle本身必須要了解各個事務(wù)的讀寫狀況,那么怎么了解整個狀況:在redo以及undo中加入是否遞交的標(biāo)識,對于已經(jīng)提交的操作,但是還沒有寫入數(shù)據(jù)文件,那么就要前滾,相反,對于沒有提交,執(zhí)行回退!

  于是,Oracle崩潰恢復(fù)步驟如下:

  首先rolling forward 前滾:由于oracle failure,sga中的內(nèi)存信息丟失了,但是online redo log中還是存儲了transaction信息,包括commited or uncommited data??赡苓@些修改信息并沒有被oracle正確的來處理,包含兩種情況:已經(jīng)提交的還沒有寫入數(shù)據(jù)文件,或者沒有提交的卻被寫入了數(shù)據(jù)文件。針對已經(jīng)提交的還沒有寫入數(shù)據(jù)文件就要發(fā)生前滾,在前滾過程中,smon會根據(jù)online redo log中的記錄來完成對datafile的修改。保證已經(jīng)提交的數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件。

  接下來,前滾結(jié)束后,數(shù)據(jù)庫正常open,此時用戶可以正常連接,可以訪問已經(jīng)recover的commited data,但是對于那些屬于unrecoverable transaction的uncommited data,會被oracle 加鎖,是不可以訪問的。

  rolling back:假如有進(jìn)程訪問這些加鎖的data,此時smon會對這些數(shù)據(jù)塊做rollback回滾,從數(shù)據(jù)文件中撤銷沒有提交卻被寫入數(shù)據(jù)文件的數(shù)據(jù)。
 

既然知道了Oracle數(shù)據(jù)庫中出現(xiàn)回滾與前退的原因,那么接下來我們就可以對癥下藥,有針對性的去解決問題,一保證我們的工作正常運(yùn)行。

【編輯推薦】

  1. Oracle數(shù)據(jù)庫共享連接和專用連接方式比較
  2. 入侵Oracle數(shù)據(jù)庫常用操作命令
  3. 輕松解決Oracle數(shù)據(jù)庫的服務(wù)啟動問題
責(zé)任編輯:迎迎 來源: 天極網(wǎng)
相關(guān)推薦

2011-07-29 16:21:21

Oracle數(shù)據(jù)庫回滾段

2020-03-27 16:05:49

數(shù)據(jù)庫數(shù)據(jù)MySQL

2017-11-24 11:59:18

數(shù)據(jù)庫OracleMySQL

2009-11-16 17:15:12

Oracle減少回滾段

2009-11-16 13:41:18

Oracle分離回滾段

2011-03-23 09:10:09

游標(biāo)數(shù)據(jù)檢索

2010-04-15 12:43:06

Oracle數(shù)據(jù)庫

2010-04-15 11:33:39

Oracle數(shù)據(jù)庫

2011-08-09 13:14:37

Oracle 10g數(shù)據(jù)庫閃回

2022-01-18 06:59:50

HashMap循環(huán)底層

2024-07-16 08:03:43

2025-04-08 06:00:00

2025-01-09 09:10:39

2010-05-13 09:59:50

MySQL數(shù)據(jù)庫

2010-04-16 17:31:22

ORACLE回滾段

2020-11-18 10:16:52

數(shù)據(jù)庫回滾事務(wù)

2011-05-26 13:36:40

Oracle數(shù)據(jù)庫時間處理

2016-02-25 14:33:38

華為華為企業(yè)業(yè)務(wù)

2020-11-18 08:32:07

數(shù)據(jù)庫

2020-02-19 15:01:30

數(shù)據(jù)庫SQL技術(shù)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號