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

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

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

晶晶小妹

把Yong Huang的英文翻译了一下，练练英文，顺便说一句。英语对一个高级数据工库师也是非常重要的。大家看我翻译的有没有错：

Biti的话让我想起了一个最近发生的事。我们的一个和我的ORACLE知识差不多的很会动脑子的DBA。我们正在调试一些由Oracle Desinger生成的应用程序代码。想像一些复杂性。在当前库中，代码工作的很好，我们导出并且导入到其他库，在那个库中，有一段代码总是报出错误，错误是列值没有适合的区。我们使用SQL Trace发现值是不可见的或空（不必惊讶它不适合任合区）。我们花了很多时间，想找出为什么它是空。值是一个包变量，这是我们所发现的，表有多个同样类型的触发器（Before insert），一个触发器为包变量赋一个值，而另一个触发器取出包变量的值。DBA问我触发器的顺序是否按某一种固定的顺序。我说“绝对不，它是完全随机的。”因为我看过文档如此说，而且Tom也这样说过。然而，代码自从两年前被生成后一直可以工作。DBA说可能顺序确实是固定的，有可能是触发器的创建顺序？我们检查了一下，确实使用包变量的触发器被更晚的创建，而在新的数据库中，它被导入命令创建的稍微早一些。于是，我作了一个小测试，让每一个触发器写一个值到外部文件（因为堆表中的值没有可靠的顺序并且行的时间戳是相同的）。邻人吃惊的是，它们按触发器的创建顺序被写进了文件中。我们然后删除并重建使用变量的触发器，然后在新的数据库中它工作的也很好。但是因为文档说我们不能依赖触发器的触发顺序（除非它是11g并且触发器有新的跟随子句），因此我们修改代码，使用变量的触发器包含为变量分配值的代码，尽管问题看上去已经通过在后来重建触器解决了。

这个案例的并不是为了说明更多知识是错的，有时，在解决问题时，我们需要超出条条框框的去思考。如果我们坚信ORACLE的声明，而没有费心去检查触发器的创建时间，我们可能发现不了为什么老的代码工作而新的代码不工作。

请教一下大家，我现在翻译东西，很多段落必须打下来，如果只是读着译，有些句子就译不出来。虽然我打字速度还算快，但是翻译速度还是慢了。大家对我进一步学英语有什么好建议！

[ 本帖最后由 晶晶小妹 于 2008-6-20 09:00 编辑 ]