Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1447306
  • 博文数量: 239
  • 博客积分: 5909
  • 博客等级: 大校
  • 技术积分: 2715
  • 用 户 组: 普通用户
  • 注册时间: 2010-07-24 20:19
文章分类

全部博文(239)

文章存档

2014年(4)

2013年(22)

2012年(140)

2011年(14)

2010年(59)

我的朋友

分类: Oracle

2012-10-30 17:12:06


点击(此处)折叠或打开

  1. Consider a transaction that updates a million
  2. row table. This obviously visits a large number of database blocks to make the change to
  3. the data. When the user commits the transaction Oracle does NOT go back and revisit these
  4. blocks to make the change permanent. It is left for the next transaction that visits any
  5. block affected by the update to 'tidy up' the block (hence the term 'delayed block
  6. cleanout').

  7. Whenever Oracle changes a database block (index, table, cluster) it stores a pointer in
  8. the header of the data block which identifies the rollback segment used to hold the
  9. rollback information for the changes made by the transaction. (This is required if the
  10. user later elects to not commit the changes and wishes to 'undo' the changes made.)

  11. Upon commit, the database simply marks the relevant rollback segment header entry as
  12. committed. Now, when one of the changed blocks is revisited Oracle examines the header of
  13. the data block which indicates that it has been changed at some point. The database needs
  14. to confirm whether the change has been committed or whether it is currently uncommitted.
  15. To do this, Oracle determines the rollback segment used for the previous transaction
  16. (from the block's header) and then determines whether the rollback header indicates
  17. whether it has been committed or not.

  18. If it is found that the block is committed then the header of the data block is updated
  19. so that subsequent accesses to the block do not incur this processing.

  20. This behaviour is illustrated in a very simplified way below. Here we walk through the
  21. stages involved in updating a data block.

  22. STAGE 1 - No changes made

  23. Description: This is the starting point. At the top of the
  24. data block we have an area used to link active
  25. transactions to a rollback
  26. segment (the 'tx' part), and the rollback segment
  27. header has a table that stores information upon
  28. all the latest transactions
  29. that have used that rollback segment.

  30. In our example, we have two active transaction
  31. slots (01 and 02)
  32. and the next free slot is slot 03. (Since we are
  33. free to overwrite committed transactions.)

  34. Data Block 500 Rollback Segment Header 5
  35. +----+--------------+ +----------------------+---------+
  36. | tx | None | | transaction entry 01 |ACTIVE |
  37. +----+--------------+ | transaction entry 02 |ACTIVE |
  38. | row 1 | | transaction entry 03 |COMMITTED|
  39. | row 2 | | transaction entry 04 |COMMITTED|
  40. | ... .. | | ... ... .. | ... |
  41. | row n | | transaction entry nn |COMMITTED|
  42. +-------------------+ +--------------------------------+

  43. STAGE 2 - Row 2 is updated

  44. Description: We have now updated row 2 of block 500. Note that
  45. the data block header is updated to point to the
  46. rollback segment 5, transaction
  47. slot 3 (5.3) and that it is marked uncommitted
  48. (Active).

  49. Data Block 500 Rollback Segment Header 5
  50. +----+--------------+ +----------------------+---------+
  51. | tx |5.3uncommitted|-+ | transaction entry 01 |ACTIVE |
  52. +----+--------------+ | | transaction entry 02 |ACTIVE |
  53. | row 1 | +-->| transaction entry 03 |ACTIVE |
  54. | row 2 *changed* | | transaction entry 04 |COMMITTED|
  55. | ... .. | | ... ... .. | ... |
  56. | row n | | transaction entry nn |COMMITTED|
  57. +------------------+ +--------------------------------+

  58. STAGE 3 - The user issues a commit

  59. Description: Next the user hits commit. Note that all that
  60. this does is it
  61. updates the rollback segment header's
  62. corresponding transaction
  63. slot as committed. It does *nothing* to the data
  64. block.

  65. Data Block 500 Rollback Segment Header 5
  66. +----+--------------+ +----------------------+---------+
  67. | tx |5.3uncommitted|--+ | transaction entry 01 |ACTIVE |
  68. +----+--------------+ | | transaction entry 02 |ACTIVE |
  69. | row 1 | +--->| transaction entry 03 |COMMITTED|
  70. | row 2 *changed* | | transaction entry 04 |COMMITTED|
  71. | ... .. | | ... ... .. | ... |
  72. | row n | | transaction entry nn |COMMITTED|
  73. +------------------+ +--------------------------------+

  74. STAGE 4 - Another user selects data block 500

  75. Description: Some time later another user (or the same user)
  76. revisits data block 500. We can see that there
  77. is an uncommitted change in the
  78. data block according to the data block's header.

  79. Oracle then uses the data block header to look up
  80. the corresponding rollback segment transaction
  81. table slot, sees that it has been committed, and
  82. changes data block 500 to reflect the
  83. true state of the datablock. (i.e. it performs
  84. delayed cleanout).

  85. Data Block 500 Rollback Segment Header 5
  86. +----+--------------+ +----------------------+---------+
  87. | tx | None | | transaction entry 01 |ACTIVE |
  88. +----+--------------+ | transaction entry 02 |ACTIVE |
  89. | row 1 | | transaction entry 03 |COMMITTED|
  90. | row 2 | | transaction entry 04 |COMMITTED|
  91. | ... .. | | ... ... .. | ... |
  92. | row n | | transaction entry nn |COMMITTED|
  93. +------------------+ +--------------------------------+



转自:
阅读(2705) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~