一个高级数据库工程师应具备什么才能?

biti_rainy

原帖由 oracledba 于 2008-6-18 13:40 发表
DBA就是一个职业一个工种，一个专业性很高的工种而已，没有别的什么，有时候甚至是体力活，有很多东西书上说的不是那么回事，自己很多的东西找不到书，oracle吹的跟花似的用久了就死，这些都是经验，还有很多基本的操作，思维的变化建立在一个正确的理解，以后再变也变不了哪去了，反正我到现在没发现自己有什么思考方式有什么变化的，思考问题方式变了，不知道的照样不知道，做技术的也就自己感觉自己是那么回事了

思考问题的方式，大家千差万别，但有的人明明一个问题存在，就是无法想到怎么构造一个试验来证实或者证伪
看过太多的这样的例子，很多人就是无法换个角度看过去

比如  lewis 构造一个20多层索引树的例子，其实相关的基本知识可能知道的人很多，但是能这么巧妙的用少量记录构造这样的例子的人非常非常的少。 有的人的思维习惯好，那自然觉得很多东西都正常，但是很多人怎么都不会突破自己已有的经验局限。我理解的思考问题的方式或者思维方式，就是如何有效地根据已有的知识和经验 去解决 未知的问题，去解决没有这方面经验的问题。  如果你觉得你的思维没什么变化，并且总是可以解决未知的问题，那说明你的思考问题的方式比较好。 但我谈论的是很多人不具备这种思考问题的方式，必须要通过一定的练习去尝试改变。否则只依靠固有的经验和知识，才能比较快解决碰到过的问题（就是无法迅速解决新问题，或者只能搜索然后慢慢去不断地实验尝试解决问题，并且在这个过程中不能有效的提高效率），那是无法突破一个层次的。

事情做的越多，后来就越发现是重复的劳动，从工作的角度来看自然是这样，这也是有的人做了5年经验足够丰富了，再做5年也没什么进展的原因。


我经常在思考，为什么有些东西人家可以想到但我就是想不到，也有些东西我可以想到，但是很多人就是想不到？这个差异到底在哪里？ 这不是经验和知识的差异问题，我用了 思考问题的方式  或者 思维方式 来表述。 如果你觉得这个表述不合适，可以探讨一下到底是怎么表述这个问题。  如果你觉得这个问题根本不是思考问题的方式或者思维方式，那又是什么原因呢？  说 聪明 或者擅长？ 还是别的？  我这个有点离题了，希望探讨的是 要让自己在某个层次之后还继续提高，到底最根本的因素是什么？

[ 本帖最后由 biti_rainy 于 2008-6-19 09:39 编辑 ]

old_bear

同意楼上的说法。
   作为一个好的数据库工程师，要了解操作系统的原理，数据库的原理，存储知识，加之将所有知识融会贯通。
问题是一个，但是解决问题的方法却是很多，关键能在最短时间、找到最佳的方法，来解决问题。
   所以，最终还是思考问题的方式方法，这也就是所说的悟性吧。

Yong Huang

biti_rainy's words remind me of an incident we had recently. One of our DBAs is very intelligent but does not have as much knowledge of Oracle as I. We were debugging some application code, generated by Oracle Designer. Imagine the complexity. The code works fine in current production. We exported and imported into another database, where one piece of code always raises the error that a column value does not fit into any partition. We used SQL trace to find that the value is missing or null (no wonder it doesn't fit in any partition). We spent quite a bit of time to find why it's null. The value is a package variable. Here's what we find. The table has multiple triggers of the same type (before insert). One trigger assigns a value to the package variable and another trigger picks it up. That DBA asked me if triggers' firing order is fixed in some order. I said "Absolutely not! It's completely random" because I know documentation says so and Tom Kyte says too. However, the code has been working since it was written about two years ago. Then the DBA said maybe the order is indeed fixed, perhaps by trigger creation time? We checked. Indeed the trigger that uses the package variable was created later and in the new database it was created slightly earlier by the import. So I did a small test, where each trigger writes a value to an external file (because the values in a heap table have no reliable order and the timestamps for the rows are exactly the same). Surprisinglyy, they *are* written in the *reverse* order of the trigger creation time! We then dropped and recreated the trigger that uses the variable and it works fine in the new database. But since documentation says we should not rely on trigger firing order (unless it's 11g and triggers have the new follows clause defined), we modify the code to include the variable assignment code into the trigger that uses the variable, although it seems the problem was already solved by creating the trigger later.

The moral of the story is not that the more knowledge the worse, but that sometimes we need to think out of the box in troubleshooting a problem. If we had insisted on Oracle's claim and hadn't even bothered to check the trigger creation time, we wouldn't have been able to find out why the old code works and new code does not.

Yong Huang

[ 本帖最后由 Yong Huang 于 2008-6-19 20:20 编辑 ]

sqysl

基础和经验很重要，你遇到了就会去想，去深挖，就会有发现，但做这些是需要一定的基础的，否则，即使遇到了，也没办法去实现这些。

oracledba

原帖由 Yong Huang 于 2008-6-19 12:07 发表

Yong Huang

做了sql trace看不到执行的顺序吗，如果是我而且版本好我会看v$sql.last_active_time把赋值的语句抓到而且版本好都可以从字典看见赋值，不用sql_trace，再看应用schema别的跑的东西，版本不好也可以看last_load_time和loads也能看出来，赋不到值就看取值的，两个语句放一起看吧，这个思维和ORACLE应该没关吧，稍微再有点ORACLE的知识就能找到原因。

Yong Huang

原帖由 oracledba 于 2008-6-19 12:25 发表

做了sql trace看不到执行的顺序吗，如果是我而且版本好我会看v$sql.last_active_time把赋值的语句抓到而且版本好都可以从字典看见赋值，不用sql_trace，再看应用schema别的跑的东西，版本不好也可以看last_load_time和loads也能看出来，赋不到值就看取值的，两个语句放一起看吧，这个思维和ORACLE应该没关吧，稍微再有点ORACLE的知识就能找到原因。

The times the rows are inserted into the logging table are exactly the same. I didn't check v$sql* views but the times are likely the same too. When one trigger is fired, the other one is immediately fired. So the times are too close. However, if the trigger logic has long running SQLs or sleep, then you may be able to see the time difference. I didn't check that.

I uploaded the testing code here:
http://yong321.freeshell.org/oranotes/TriggerFiringOrder.txt

Yong Huang

netbanker

原帖由 oracledba 于 2008-6-20 02:25 发表

做了sql trace看不到执行的顺序吗，如果是我而且版本好我会看v$sql.last_active_time把赋值的语句抓到而且版本好都可以从字典看见赋值，不用sql_trace，再看应用schema别的跑的东西，版本不好也可以看last_load_time和loads也能看出来，赋不到值就看取值的，两个语句放一起看吧，这个思维和ORACLE应该没关吧，稍微再有点ORACLE的知识就能找到原因。

你这个稍微再有点ORACLE的知识也得2-3年至少实战，别把oracle dba 说的太简单了，老dba同志

oracledba

原帖由 Yong Huang 于 2008-6-20 05:41 发表


The times the rows are inserted into the logging table are exactly the same. I didn't check v$sql* views but the times are likely the same too. When one trigger is fired, the other one is immediately fired. So the times are too close. However, if the trigger logic has long running SQLs or sleep, then you may be able to see the time difference. I didn't check that.

I uploaded the testing code here:
http://yong321.freeshell.org/oranotes/TriggerFiringOrder.txt

Yong Huang

没错，如果我看到的last_active_一样，下一步再做sql_trace，找hashvalue看tim，其实我觉得肯定在字典还能找到，就是不想做trace，我想说的就是方法，其实还是思维的定式，DBA是应该具有思维的定式而且是非常强的思维定势

晶晶小妹

在解决问题时，有时只有想不到的问题，没有碰不到的问题。我来说一种情况，对于初学者绝对很困惑：
有两个表T1和T2，可以假设T1存放姓名、ID这些基本信息，每行较短，而T2也有ID列和一些说明、备注类信息，每行长的可能有一两千个字节。对于这两个表，使用嵌套循环连接，T1表占的块数比较少，是小表。而T2表占的块数几倍于T1，是大表。那么，应该T1做驱动表更好一些，但实际却是T2大表做驱动表更好。
一个不知道DBA还是开发，不知道这一点，为了强制小表T1做驱动表，写了类如下语句：
select /*+ use_nl(t1,t2) ordered */* from t1,t2 where t1.id=t2.id;
后来这个语句造成了一些性能问题。通过了解嵌套循环的工作方式，发现这里的确是大表做驱动表好一些。
这里就说明了一个问题，都说嵌套循环要小表做驱动表，如果不知道这是为什么，这很容易造成人云亦云。这样只知其表，而不知其里，很容易影响以后在某些问题上做出的判断。

sqysl

有道理，所以我们遇到问题或看书时，不但要知其然，更要知道其所以然，只有理解了，掌握了事物的内在机制，才能站到一个高层面上去看问题，解决问题，以不变应万变，否则，生搬硬套是不行的。。