123
返回列表 发新帖
楼主: zhang_yong88

請教關于 父與子 latch 的理解.....

[复制链接]
论坛徽章:
3
授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34ITPUB元老
日期:2006-09-11 15:36:37
21#
 楼主| 发表于 2006-8-8 09:16 | 只看该作者
謝謝  Yong huang


我明白您的意思﹐以升序的規律 來申請 latch﹐以免有回溯現象﹐而出現死鎖...

我只是個人覺得擴大了 latch deaklock 的范圍﹐有點類似于 "悲觀鎖" 。

如以下情況﹐

session 1
heloing  latch ﹕enqueue hash chains  latch ﹐  level    4

request latch ﹕redo allocation   latch      ﹐    level   6


session 2﹕

helding ﹕parallel query alloc buffer latch      ,   level 6

request ﹕process queue reference   latch ﹐  level 4       (當然這是oracle 不允許)


當然﹐這里我不清楚這里的 latch 請求是否合理﹐我僅是來例示一下。

在 session 2 ﹐在持有 level 6 的 parallel query alloc buffer latch ﹐所以不允許請求  level 4 的process queue reference   latch 。

這樣以免 和 前面的 session 1 形成相互等待的 deadlock 。  只是我在覺得 ﹐如上面的示例﹐

即便是 session 持有 level 4﹐申請 level 6 ﹐而 session level 6﹐申請  level 4。這也不會有deadlock 發策

因為它們持有和申請的 latch 根本就毫不相干﹐同一 level 的 latch 應有多數﹐我想這樣的情況應也不在少數。

當然﹐ oracle  這樣控制應有原因﹐如您 所說﹐不能看到 更多的資料﹐呵.....

所以﹐以您對 latch 內部特性和  它操縱的對象來講如何解讀....

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表