晶晶的Oracle夜未眠：个人感悟篇

foxmile · 发表于 2008-2-19 14:29

我觉得，深入学习和不深入学习。关键在于社会对你所学的需要程度。
很多时候，老板或者社会需要的是能解决问题的人。
有人愿意做全面的人，有人愿意做深入研究的人，而结果就是在行业出现了不同的职业。
高级软件pm、首席dba，他们对于技术的研究就是两个极端，pm偏重于全面。他所涉及的范围很广，首席dba，偏重于技术，他们对技术的研究往往比较深刻，而pm对于某项专职技术研究不深刻，但是他能控制一个团队，五十、一百、两百、三百甚至更多人的团队，完成一个几千万、上亿的项目。至于他们的收入，我不敢妄猜，大家可以去自己调查。我认为，深入学习和不深入学习是一个人的选择，也许是工作，也许是生活。
能在老板需要的时候解决问题，就是牛人。至于他怎么解决的，有时候并不是那么重要了。

[ 本帖最后由 foxmile 于 2008-2-19 14:33 编辑 ]

fxyj2008 · 发表于 2008-2-19 14:31

当然，每个人的性格、发展方向都不一样。因此，每个人都有自己的选择。用不用学这些深入的东西，这样的争论在哪儿都有，就在我们办公室就有。我的一个同事，虽然干的是DBA，但闲睱时间总爱摆弄些其他方面的东西，从不去看Oracle中深入的东东。我俩以前就常伴嘴，去年他跳到了北京，还是DBA，月薪税后15K，小日子过的还不错。
当然，话又说过来，无论什么教材都要批判着看，比如DSI中关于闩的描述，讲到cache buffers chains闩是共享闩，读可以和读共享。我就有点奇怪了，套一句当前Oracle界某红人的话，“不是我不懂，还是这个世界变化快”，如果所有的读都可以共享Cache buffers chains闩，热点块问题不是就可以大大缓解了吗。但我在工作中有时还会碰到纯粹读时的热点块问题。自己作实验，仔细验证了一下（实验步骤在晶晶实验四：闩中），果然，在纯粹读时，当两个会话同时读一个块时，Cache buffers chains还是有少量的Misses。因此，我称Cache buffers chains为有限共享。

早期oracle 中　Cache buffers chains　确实是读和读不能共享得　，因为当时就是一个普通得变量嘛　，用机器指令实现得原子操作　，后来估计出现热点块问题　，所以oracle 为了减少热点快现象　，读和读可以是共享得　想想也对阿　，N个进程如果纯粹是读链表，根本就没有必要上锁得　，我想如果要实现　读和读共享　，oracle 应该使用了其实变量一起来辅助达到这个目的得　。

还有就是 library cache latch　，　即使软解析都要上一次锁　，然后再搜寻链表　，也是非常浪费时间得　，所以才出现了　session cache 得说法　，减少library cache latch 得争用　

结论：　oracle 现在越做越好了　，　很多时候就是在找各种技术得平衡点　，所以技术做得好　

我感觉现在很多得技术都在傻瓜化，用他们得话说　，　可以使开发人员着重于业务，应用得架构　，想想也有道理得　，这样可以加大软件开发得效率　。但背后得技术其实使越做越高级　，　我想是可能现在做软件得思想越来越成熟了　，可惜得只是使国内没有什么核心技术

晶晶小妹 · 发表于 2008-2-19 14:36

多谢大家那么支持新人，请大家在支持之余，多多指点．．

＾＿＾

[ 本帖最后由晶晶小妹于 2008-2-19 15:19 编辑 ]

晶晶小妹 · 发表于 2008-2-19 14:46

原帖由 fxyj2008 于 2008-2-19 14:31 发表

早期oracle 中　Cache buffers chains　确实是读和读不能共享得　，因为当时就是一个普通得变量嘛　，用机器指令实现得原子操作　，后来估计出现热点块问题　，所以oracle 为了减少热点快现象　，读和读可以是共享得　想想也对阿　，N个进程如果纯粹是读链表，根本就没有必要上锁得　，我想如果要实现　读和读共享　，oracle 应该使用了其实变量一起来辅助达到这个目的得　。

还有就是 library cache latch　，　即使软解析都要上一次锁　，然后再搜寻链表　，也是非常浪费时间得　，所以才出现了　session cache 得说法　，减少library cache latch 得争用　

结论：　oracle 现在越做越好了　，　很多时候就是在找各种技术得平衡点　，所以技术做得好　

我感觉现在很多得技术都在傻瓜化，用他们得话说　，　可以使开发人员着重于业务，应用得架构　，想想也有道理得　，这样可以加大软件开发得效率　。但背后得技术其实使越做越高级　，　我想是可能现在做软件得思想越来越成熟了　，可惜得只是使国内没有什么核心技术

大多数闩并没有共享　独占　这些模式，他只有持有和不持有．当一个进程持有闩时，别的进程并不知道他持有闩的目的是读还是写。又怎能够共享呢？ＣＢＣ闩的原理和其他闩应该不一样．但他和锁的实现方式也有很大区别．从我的实验中，ＣＢＣ闩只能实现有限共享　不能向锁一样真正的　读读共享．这是oracle非常内部的东西从外表的活动很难分析内部真正的运做机制．因此，对于ＣＢＣ闩我也只能用＂有限共象＂这四个字　来模糊的下一个结论咯．希望大家能有更好的实验．进一步证明ＣＢＣ闩的活动．

　