Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › flush dirty block时发生crash导致的split block可以恢 ...
发新帖
clevernby

157

积分

0

好友

14

主题

[Exadata硬件] flush dirty block时发生crash导致的split block可以恢复吗？

1#
发表于 2013-5-17 10:21:40 | 查看: 4787| 回复: 9
最近在研究MySQL时发现其一种保护数据安全的名为doublewrite buffer机制，遂结合Oracle Database机制引出如下问题。

假设数据库block_size=8192字节，OS为linux IO基本单位为512字节。Oracle的DBWR写出dirty block，在写到1024字节时发生OS crash或者power outage，那么磁盘上的这个块将是inconsistent的，数据库重启时的redo apply可以修复这一问题吗？

我觉得不行，可从alter xxx begin backup的实现机制中推出，该备份机制中为解决split block需要在redo中记录完整的block image，似乎只有纯物理日志才能修复split block。而在我的例子中redo中记录的是标准的半物理半逻辑日志，是不包含完整的block image的，应该不能修复split block，该块之后会被标记为坏块。

是这样的吗？请包括刘老师在内的高手给予指点。谢谢
2#
发表于 2013-5-17 10:27:49
从增量检查点开始恢复，恢复到崩溃时间点，然后回滚未提交的。

回复 只看该作者 道具 举报

3#
发表于 2013-5-17 10:28:51
可以理解为写 丢失吗？

默认 Oracle识别不了写丢失的 Lost Write

回复 只看该作者 道具 举报

4#
发表于 2013-5-17 10:31:48
本帖最后由 clevernby 于 2013-5-17 10:37 编辑
Maclean Liu(刘相兵 发表于 2013-5-17 10:28
可以理解为写 丢失吗？

默认 Oracle识别不了写丢失的 Lost Write


不算lost write
刘老师回复真快，非常感谢

回复 只看该作者 道具 举报

5#
发表于 2013-5-17 10:37:05
flush dirty block时发生crash，检查点未前进，数据重新启动后从上一次检查点开始恢复，split block也在恢复之内。问题是这个block可以被恢复吗？

回复 只看该作者 道具 举报

6#
发表于 2013-5-17 10:55:49
clevernby 发表于 2013-5-17 10:37
flush dirty block时发生crash，检查点未前进，数据重新启动后从上一次检查点开始恢复，split block也在恢 ...

这种场景一般 无需担忧， 怕就怕 是真的Lost Write

回复 只看该作者 道具 举报

7#
发表于 2013-5-17 10:56:32
ckpt是不知道 dbw写的情况的 dbw 提交IO请求， dbw其实也不知道 到底写的这么样

ckpt和dbw是2个 糊涂蛋， 他们都上os的当

11g之前 要确认写 的话 可以用_DB_WRITER_VERIFY_WRITES 写完之后 立即做物理读 确认写的情况 代价是 IO

回复 只看该作者 道具 举报

8#
发表于 2013-5-17 12:19:56
本帖最后由 clevernby 于 2013-8-8 10:16 编辑

请看图

1.JPG

图中蓝绿红分别代表块中的0-2行记录（实际块内Data部分是从tail往head写的，这里忽略方便画图）。一个块需要4次写出（分成了4格）。

做instance recovery时，apply 那条delete的redo record可以正确删除残留的蓝色记录吗？

回复 只看该作者 道具 举报

9#
发表于 2013-5-17 14:47:44
太高深了。

回复 只看该作者 道具 举报

10#
发表于 2013-8-8 09:42:30
本帖最后由 clevernby 于 2013-8-8 10:03 编辑

有其它同学因掉电发生了crash，地址如下
http://t.askmaclean.com/thread-2811-1-1.html
据此就本问题进一步展开如下讨论，下面是ORA-ALLSTARS Exadata用户组QQ群讨论的部分内容（有删减）

  2. 上海-神奇宝贝(156658196)  9:14:06
  3. 这个问题（指上述因掉电发生的crash）， 应该就是Oracle采用非严格物理redo引发的
  4. 上海-神奇宝贝(156658196)  9:14:30
  5. 掉电后数据库就容易坏掉
  6. 上海-神奇宝贝(156658196)  9:16:45
  7. mysql innodb 采用double write解决这个问题； 达梦7采用纯物理redo解决这个问题； Oracle采用鸵鸟政策解决这个问题
  8. 上海-神奇宝贝(156658196)  9:18:54
  9. 呵呵， Oracle如何解决这个问题我一直很困惑， 以前在这里也咨询过
  10. 上海-clevernby(313834644)  9:20:29
  11. 之前曾提供类似的疑问
  12. http://t.askmaclean.com/thread-2484-1-1.html
  13. 神奇宝贝来看看
  14. 上海-神奇宝贝(156658196)  9:21:38
  15. 这个问题有个名词，叫“页断裂"
  16. 上海-clevernby(313834644)  9:21:56
  17. 似乎当时我的假设是正确的，对于这类不一致，instance recovery是不能恢复的
  18. 上海-神奇宝贝(156658196)  9:22:19
  19. 如果页断裂发生在普通的数据块， 也许丢点数据， 标记为坏块，还能混过去
  20. 上海-clevernby(313834644)  9:22:46
  21. 和redo的格式有关，Physio-Logical
  22. 上海-神奇宝贝(156658196)  9:23:41
  23. 纯物理 redo就没有这个问题了
  24. 上海-神奇宝贝(156658196)  9:23:59
  25. 但是纯物理的缺点就是redo比较占空间
  26. 上海-Anderson Ling(153936828)  9:24:00
  27. 代价呢
  28. 上海-clevernby(313834644)  9:24:08
  29. 但纯物理也会引入其它问题吧，比如redo的量？
  30. 北京-龚佶敏(5409230)  9:24:12
  31. 原理都是一样的
  32. 计算机里面就这些东西
  33. 上海-神奇宝贝(156658196)  9:25:03
  34. 其实打开归档， 崩溃后从上一个完整地备份开始用归档，也可以规避这个页断裂问题
  35. 上海-clevernby(313834644)  9:25:40
  36. 是的
  37. 上海-神奇宝贝(156658196)  9:26:56
  38. 杀进程， 或者oracle 挂掉， 也不太会出现页断裂；
  39. 上海-神奇宝贝(156658196)  9:27:17
  40. 只有真正的掉电才有可能
  41. 北京-龚佶敏(5409230)  9:27:40
  42. 数据是按页提交给系统底层的，操作系统会确保页的完整性，除非断电
  43. 上海-clevernby(313834644)  9:29:57
  44. DM使用Physical Log，log记录的内容会很多，占用很大空间。
  45. 如B-Tree的分裂操作，要记录约一个完整Page的内容
  46. 上海-clevernby(313834644)  9:30:23
  47. 是这样吗？
  48. 北京-龚佶敏(5409230)  9:30:22
  49. log的内容不会因为是物理的还是逻辑的，有很大的空间需求差异吧
  50. 如果有的话，那会成为严重的性能问题
  51. 上海-神奇宝贝(156658196)  9:31:05
  52. 空间稍微大一点， 大得不多
  53. 北京-龚佶敏(5409230)  9:31:29
  54. 空间需求是数据结构设计导致的，不会因为是物理的还是逻辑的就不一样
  55. 上海-clevernby(313834644)  9:35:53
  56. 比如对一个B-Tree的页内插入一条记录，物理上来说要修改Page Header的内容，如页内的记录数要加1，要插入一行数据到某个位置，要修改相邻记录里的链表指针，要修改ITL等的属性。从逻辑上来说，就是在这个页内插入了一行记录。因此逻辑日志只记录："这是一个插入操作"和"这行数据的内容"。大小就区别在这里
  57. 上海-神奇宝贝(156658196)  9:37:52
  58. 正确！逻辑日志的前提是， 这个数据页是合法的， 如果断裂了就全乱了
  59. 上海-神奇宝贝(156658196) 9:50:20
  60. 下次和Oracle PK, 就找两台破PC,  跑TPCC, 然后拔电源， 看谁先重起不了
  61. 上海-clevernby(313834644) 9:53:02
  62. 无论是使用哪种格式日志，没有好坏之分，有的只是厂商的取舍，Oracle使用半物理半逻辑的格式，也是有其意义的
  63. 上海-clevernby(313834644) 9:55:26
  64. 毕竟掉电这种事在重要的生产服务器是不应该发生的，因以预防为主
  65. 北京Lunar-dm01cel01(5163721) 9:56:25
  66. 毕竟掉电这种事在重要的生产服务器是不应该发生的，因以预防为主----------》我替thomas说下：  没有完善的备份和灾备还强调自己系统重要，就是耍流氓
  67. 上海-clevernby(313834644) 9:57:09
  68. Oracle一定是认为这种事情发生的概率极低，没有必要为此使用纯物理日志进而或大或小地牺牲IO性能。
  69. 北京Lunar-dm01cel01(5163721) 9:57:21
  70. 否
  71. 北京Lunar-dm01cel01(5163721) 9:57:35
  72. 我认为O觉得重要的系统都应该有完善的规划
  73. 上海-clevernby(313834644) 9:58:26
  74. 我说的这种事情就是指“重要系统+没有备份+没有灾备+没有备用电源+其它也没有”
  75. 上海-clevernby(313834644) 9:58:57
  76. 显然上述1有N没有的概率是很低的，Oracle是以此作为前提来设计数据库的
  77. 北京Lunar-dm01cel01(5163721) 10:00:26
  78. 我个人感觉，O只是从应该怎么做去考虑的，并提供了各种可能的方案： bbed，dul，patch bootstrap$ ,and so on...
复制代码

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2025-1-1 09:56 , Processed in 0.051559 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569