update的机制问题

zhang_yong88

最初由 biti_rainy 发布
[B]1: 是的，data  buffer 中有回滚段块
[/B]

請教﹕ Data buffer 中的回滾段塊 與 我在設立的表空間的回滾段
是一個什么樣的關系。
     
      這個回滾段塊是僅用于小量數據的更新嗎﹖

       我們在修改數據塊的時候﹐是先將原數據 放在 data buffer  中 的 回滾段塊 而后再寫往 回滾段 表空間嗎﹖如是這樣﹐是出于什么目的。

zhang_yong88

最初由 biti_rainy 发布
[B]

整个物理行全部迁移到块的最上面（不一定是pctfree部分）紧贴最上面一条记录（不管块的中间是否有空隙） [/B]

更新 時 為什么一定要將 這個物理行移到最上面 ﹖

請問當 塊的 中間沒 有 空隙時 在這 個塊內所進行的 物理行的 移動（可以說位置的交換嗎） 我想一定是要借助于第三方的數據塊 ---- 是臨時段 數據塊嗎﹖

zhang_yong88

謝謝 BT!!
真要仔細看 一下你的文章了﹐以前你亦有提到要我讀﹐可是一直沒有很好的理解。
看過后 再向你請教。

zhang_yong88

在 日志文件中存放 數據修改前與修改后 的 兩種 數據 ﹐那么在 進行介質 恢復時
Oracle 是如 何進行 區分 是 更新前 或是更新后的 數據呢﹖ 根據 SCN ﹖

恢復時  Oracle  是怎么 將 更新 前與 更新 后的數據 分流到 回滾段 與數據文件中的
它是否 是﹕ 將 日志文件  的 更新 前﹑后的兩種 數據  分別存放在 回滾段 與數據
文件中 ﹐而當 這個事件 沒有提交成功時 則利用 存在 回滾段的 數據 來寫入 數據文件
中 ﹖﹖

zhang_yong88

最初由 biti_rainy 发布
[B]

写在文件是为了保证数据不丢失
而放在内存 是为了 读取  快啊

回滚段在data  buffer 中占的数量可能很大
但到底里面的规则是怎样，不清楚 [/B]

不好意思﹐BT ,還想請教 一下﹕
  那當更新 的數據 沒有提交時﹐更新前的數據 是存放在
data buffer 中的回滾段塊 還是 回滾段文件中呢﹖還是說﹕
先通過 存放在 data buffer 回滾段塊﹐而后通過 dbwr來寫到回滾段
數據文件嗎﹖

我一直以為 非 當前會話來保持讀一致性的來源數據是從回滾段
文件中讀取出來的。如是這樣﹐"放在内存 是为了 读取  快啊 "
請問這是供給誰來讀取的（當沒commit時﹐來提高其它會話的命中率嗎﹖）。如 是你所講﹐當一個批量的更新時
那么data buffer 几乎亦會全部給回滾段塊所占據。

  而"快照太舊"這個錯誤 又是由哪 一個 觸發的呢﹖按照
﹐"放在内存 是为了 读取  快啊 " 來講 ﹐這個也會引發這個
經典錯誤喲﹖

謝謝﹗﹗﹗

zhang_yong88

請教 回滾段存放 數據的原則是什么 ﹕
是存放在 修改前的 數據  ﹖還是存 恢復 到修改前的數據的指令。
  
  如是前者﹐那數據 回滾時 是怎么進行處理。
  如是后者﹐那當數據沒有提交時﹐非當前會話所取的數據 怎么來﹐是對這條指令
  進行分析﹐而后擷取其數據。謝謝﹗﹗﹗

biti_rainy

1： 修改前的数据
2：UNDO 操作(也就是你的所谓指令)
3：关联的block
4:  其他

数据回滚的时候，根据回滚段内容(指令+数据+block)去做修改block


关于指令也好，数据也好，在回滚段中不过是数据结构的一部分而已！
你可以看做一个结构 st
st.v1   = update
st.v2  =  数据
当然还有其他很多内容

数据库当然知道，如果是非 当前会话来获取数据的时候就返回 st.v2 不就结了，干吗有分析一说

如果你有兴趣研究，可以去dump  undo  block

顺便给点  consistent  read 的提示：

：
    1. Read the Data Block.

2. Read the Row Header.

3. Check the Lock Byte to determine whether there's an ITL entry.

4. Read the ITL entry to determine the Transaction ID (Xid).

5. Read the Transaction Table using the Transaction ID. If the transaction has been committed and has a System Commit Number less than the query's System Change Number, update the status of the block (block cleanout) and start over at step 1.

6. Read the last undo block (Uba).

7. Compare the block transaction ID with the transaction table transaction ID. If the Transaction ID in the undo block doesn't equal the Transaction ID from the Transaction Table, then issue ORA-1555, Snapshot Too Old.

8. If the Transaction IDs are identical, make a copy of the data block in memory. Starting with the head undo entry, apply the changes to the copied data block.

9. If the tail undo entry (the actual first undo entry in the chain, or the last in the chain going backwards!) indicates another data block address, read the indicated undo block into memory and repeat steps 7 and 8 until the undo entries don't contain a value for the data block address.

10. When there's no "previous data block address," the transaction has been completely undone.

11. If the undo entry contains:

a. a pointer to a previous transaction undo block address, read the Transaction ID in the previous transaction undo block header and read the appropriate Transaction Table entry. Return to step 5.

b. an ITL record, restore the ITL record to the data block. Return to step 4.

biti_rainy

有兴趣自己慢慢研究吧

Fenng

顺着Biti_Rainy的文档找到了不少东西.谢了

收集了这么多的站点,居然没有去过作者的这个站点.有一些遗憾了

idler

biti对x$bh表是不是又有新的研究发现了，谈一谈吧。