两个DBA的谈话记录

Fenng

所谓的这些Internal，我感觉有些像葵花宝典

“宝典在手，江山我有”

不过可能付出的负面的代价更大

hrb_qiuyb

哈哈，不讨论这个问题了，每个人心中还是有个度的，看个人的价值取向及业余的时间了。

Fenng违背了我的原则：不讨论Dba是否合格

所说的internal也不专指undocument这些参数。michael ault 在他的文章中指出了他最喜欢的14个非文档参数、不喜欢的几个参数及千万不能碰的几参数。虽这些为非文档参数，并不能代表它不好，只不过Oracle怕使用不当会出问题罢了。不知各位记不记得Ibm系统中mount时常用的mind这个option,它其实就是一个非文档的参数，在实际的应用中确发挥着良好的作用。

其实这是一个有差异的概念问题，每个人对于何为Oracle的internal的理解还不一样呢。

我们当然不能舍本逐末，但本做好了去逐逐末也不很不错的，还记得经济学中的28原则吧!

zhoubf725

A,B代表着dba的两个方向

无所谓应不应该或好与不好 全凭个人兴趣

Fenng

呵呵，这么晚了，原来都在

我说的也不过举例子而已，举例子最怕以偏概全

说着说着，快变成"关公战秦琼"了

D

swinger

[QUOTE]最初由 Kamus 发布
[B]CP和coolyl提到的时间和精力问题还是很重要的，其实也许都可以认同研究internal对于DBA本身的素质以及解决问题的能力绝对是有百利无一害的。但是问题在于中国目前的IT水平，没有人可以单靠DBA的工作就能维持对于各种欲望的追求。既然不能把所有的时间都放在Oracle上面，那么就要去学别的东西，那么就要找到一个能够应对的方法。这时候，往往internal的东西就显得不那么重要了，因为即使不了解internal我们仍然可以解决大部分的问题。这就是一个边际价值的问题。
所以我一直认为研究internal是在作学问，而不研究就只是在作工作。这个社会毕竟作工作的多，作学问的少，而作了学问的，再去作工作往往比单作工作的要更有远见。
说到这儿，其实意思也就是一个见仁见智的问题，如果有精力自然是研究的好，不研究也不是什么大问题。 这个社会毕竟作工作的多，作学问的少，而作了学问的，再去作工作往往比单作工作的要更有远见。[/COLOR]

       ---------------这句话说得很有道理！

ocp8i

我觉得现在做dba还是经验会比较重要，毕竟看文档都明白，真正出了个问题敢不敢动手，动手过程中会不会出错不好说，我就遇到过这样的人，说原理什么都很明白，头头是道，但是真正动手的时候就差多了，不是忘了这个就是忘了那个，出现了新的问题也不会解决了。


认同.

Pinocchio

K的有道理，精辟。学问是兴趣，饭碗是工作。

wuchl

不知道这里的DBA管理的oracle有没有买服务
如果没有服务，ORACLE才不会理你呢！怎么办？只有自己捣腾。

wangyuzhen

我严重同意做好日常维护工作的提法，用一些内部的方法解决问题只是亡羊补牢，最好是能够做好事前预防。如果数据库出了问题，你愿意去解决一个有完好备份的还是乱七八糟的呢？

allanliao

好热烈的讨论!
我也来凑热闹,呵呵.

我觉得A/B两个方向的选择,要考虑两个问题:
[一]是自己的目标;说是想法也好,说是理想也行,自己要认准自己想要(追求)的东西;
[二]是能获取的资源;如果没有强大的资源做后盾,光靠在公网上能获取的信息 去研究很internal的东西恐怕有些困难.

关于[一],我个人不过分追求很"高手"的东东,我的要求是:能解决工作中遇到的各类故障.
至于解决的途径,则不强求,有时甚至不是自己苦苦探求,而是依赖流程来解决.
"不管黑猫白猫,抓到老鼠就是好猫".
至于"干了2夜3天"这样的情况,我想只能说明该系统不重要 或者以前的方案设计就有问题.

说到底,我们大多数是做计算机应用的,不是计算机(包括软硬件)研制;
我们摸索的,都是别人在实验室早已经框定了的东西,我们的角色决定了我们不必太深入什么internal. 真是internal的东东,我们也获取不了.

我以前做系统集成时,就是用这一条要求自己的: 能解决问题!

至于[二],我想这是没法强求的事情. 曾经有幸见过某大公司的工程师解决问题:
不是自己思索,翻文档; 而是直接login到他们的内部网的知识库,一查,原来是特定硬件(一块卡)
在特定平台(OS版本)上的BUG, 打上某某补丁就OK.

这样的事情,如果依靠自己想,(就凭能看到的那点错误信息?) 恐怕没有办法,而且也是没有意义的.

我没有见过ORACLE的内部资源,但我想,我们能碰到的问题,恐怕别人早就碰到并且有结论了


一点拙见,班门弄斧.