eygle.com   eygle.com
eygle.com  
 

« February 24, 2006 | Blog首页 | February 26, 2006 »



February 25, 2006

逻辑严谨与数据安全

作者:eygle

出处:http://blog.eygle.com

这几天,一则消息在网上广为流传:黑客侵入北京移动充值中心,盗取密码谋利370万.主要内容说的是:

    UT斯达康有限公司深圳分公司某工程师利用互联网,多次侵入中国移动充值中心数据库修改密码后进行销售。自2005年3月以来,造成北京移动通信有限责任公司损害共计价值人民币370余万元。

据更详细报道称:

该工程师利用他为西藏移动做技术时使用的密码(此密码自其离开后一直没有更改),轻松进入了西藏移动的服务器。通过西藏移动的服务器,...又跳转到了北京移动数据库,取得了数据库的最高权限,并通过读取数据库日志文件,反推破译出密码。

我们看到,此次安全事件最主要的原因是因为工程密码从来就没有修改过,从而带来了安全漏洞.说这是黑客攻击,其实还算不上.只能说是因为管理不擅的人为原因导致了这次入侵及损失.

在这次事件中,我想说的是,也许受损失更大的并不是中国移动,而是UT斯达康的这位工程师.移动的损失可以被追回被弥补,可是这次事件给这位工程师带来的伤害可能是一生的.

如果大家不幸看过《无极》或者幸运的看过《一个馒头引发的血案》,你可能就可以理解:当陈满神拿一生的荣华富贵来引诱只有一个馒头的小女孩的时候,可怜的孩子上当了;当中国移动把保险箱的大门向这位工程师开放的时候,他犹豫了,他同样做出了错误的选择。

我并非为这个孩子开脱,只是我们可不可以责备一下呢:中国移动你为什么不把大门锁好?

话题扯远了,我其实想说说数据安全。

同以前我在DBA生存守则里表达的一样,8/2法则在这个领域同样适用,其实80%的安全问题全是由于人为的疏忽,原本可以轻易避免的,在疏忽之下就被无限放大。在任何时候我们都不能心存侥幸.

在关于数据库备份的文章中,我曾经提到:

备份重于一切
          系统总是要崩溃的,没有有效的备份只是等哪一天死!

在安全领域也是同样,如果你心里没有安全意识和忧患意识,那么系统被攻破或遭受损失只是早晚而已。

提高系统的安全性通常可以来自两个方面:

1.严谨的个人以及严谨的执行
2.可靠的制度和严格的执行

我们知道,可靠的制度通常来自严谨的思考和不断的探索,在未有制度之前,我们需要人才,他们可以通过自身的严密思考和稳健逻辑构建高效安全的系统;在系统逐渐成熟的过程中,制度得以建立。有了制度以后,后来人只需要贯彻执行就不会出太大的问题。汉代的约法三章萧规曹随;美国的大陆会议、独立宣言,莫不为一国奠定了立国之本。可见好的先行者和良好制度以及严格执行是多么的重要。

我相信中国移动的各项制度恐怕都是有的,只不过没有被有效的执行而已。形同虚设的制度有等若无。

在缺少天才的时代,我们需要规则来维持秩序。

 

Posted by eygle at 2:21 PM | Comments (7)


如何使用ordered提示改变SQL执行计划

作者:eygle

出处:http://blog.eygle.com

ORDERED提示强制Oracle按照From子句中表出现的顺序进行表连接。

通过ordered提示,可以避免CBO SQL解析过程中的表连接评估,从而避免Oracle产生错误的执行计划,或者强制Oracle按照我们指定的方式执行。

在很多时候,当我们清楚地了解数据结构和数据分布之后,就可以通过ORDERED提示来提高SQL性能。

通过以下例子我们来说明一下Ordered提示的作用.

1.不加Hints时SQL的执行计划

SQL> set autotrace trace explain
SQL>  SELECT COUNT (*)
  2    FROM t_small, t_max, t_middle
  3   WHERE t_small.object_id = t_middle.object_id
  4   AND t_middle.object_id = t_max.object_id;
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=194 Card=1 Bytes=12)
   1    0   SORT (AGGREGATE)
   2    1     HASH JOIN (Cost=194 Card=400 Bytes=4800)
   3    2       HASH JOIN (Cost=42 Card=100 Bytes=800)
   4    3         TABLE ACCESS (FULL) OF 'T_SMALL' (Cost=2 Card=100 Bytes=400)
   5    3         TABLE ACCESS (FULL) OF 'T_MIDDLE' (Cost=39 Card=28447 Bytes=113788)
   6    2       TABLE ACCESS (FULL) OF 'T_MAX' (Cost=151 Card=113792 Bytes=455168)
 

我们可以通过10053事件跟踪一下该SQL的解析:

SQL> alter session set events='10053 trace name context forever,level 1';
Session altered.
SQL> explain plan for
  2  SELECT COUNT (*)
  3    FROM t_small, t_max, t_middle
  4  WHERE t_small.object_id = t_middle.object_id
  5  AND t_middle.object_id = t_max.object_id;   
Explained. 

查看Trace文件可以看到,Oracle需要进行3! (6)次表连接顺序的评估:

bash-2.03$ cat testora9_ora_10862.trc |grep "Join order"
Join order[1]: T_SMALL [T_SMALL] T_MIDDLE [T_MIDDLE] T_MAX [T_MAX]
Join order[2]: T_SMALL [T_SMALL] T_MAX [T_MAX] T_MIDDLE [T_MIDDLE]
Join order[3]: T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL] T_MAX [T_MAX]
Join order[4]: T_MIDDLE [T_MIDDLE] T_MAX [T_MAX] T_SMALL [T_SMALL]
Join order[5]: T_MAX [T_MAX] T_SMALL [T_SMALL] T_MIDDLE [T_MIDDLE]
Join order[6]: T_MAX [T_MAX] T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL]  

2.当我们使用Ordered提示之后

SQL的执行计划如下(from子句后的表顺序作了调整):

SQL> SELECT /*+ ordered */ COUNT (*)
  2    FROM t_middle, t_small, t_max
  3  WHERE t_small.object_id = t_middle.object_id
  4  AND t_middle.object_id = t_max.object_id; 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=197 Card=1 Bytes=12)
   1    0   SORT (AGGREGATE)
   2    1     HASH JOIN (Cost=197 Card=400 Bytes=4800)
   3    2       HASH JOIN (Cost=45 Card=100 Bytes=800)
   4    3         TABLE ACCESS (FULL) OF 'T_MIDDLE' (Cost=39 Card=28447 Bytes=113788)
   5    3         TABLE ACCESS (FULL) OF 'T_SMALL' (Cost=2 Card=100 Bytes=400)
   6    2       TABLE ACCESS (FULL) OF 'T_MAX' (Cost=151 Card=113792 Bytes=455168) 

再看10053的跟踪Trace文件:

bash-2.03$ grep "Join order" testora9_ora_10918.trc
Join order[1]: T_MIDDLE [T_MIDDLE] T_SMALL [T_SMALL] T_MAX [T_MAX]  

Oracle只需要按照表在From子句中的出现顺序进行连接,从而按照我们的意图进行解析或执行.

这就是Ordered提示的基本作用,本例只是一个示范说明,后者的执行计划使得Cost激增,在实际应用中,我们当然是不希望看到此类增长的.

 

Posted by eygle at 12:28 PM | Comments (0)



CopyRight © 2004-2008 eygle.com, All rights reserved.