作者文章: Fenng

图形工具是 DBA 的敌人?

最近 AnySQL 在 ITPub 上发了一个帖子: 多少DBA能离开OEM/TOAD/PLSQL Dev来工作? , 引来了很多人的讨论. 整理一下大家的观点,大致分为如下几类:

工具能提高效率, 为啥不用?
坚决不用;
用不用都成; 解决问题就成;
用来学习; 查看一些 SQL 很方便;

真是个仁者见仁,智者见智的问题. 图形化工具对于一个合格的 DBA 来说, 很多时候还是有缺点的,

一个图形化工具慢慢把 DBA 工作大众化了.这样作为一个DBA用图形化工具被人家看到了，显得不那么专业: 都是图形化的工具，普通开发人员随便点击几下子鼠标，不也成了 DBA 了? Oracle 10g 大大加强了 OEM 的功能, 很多人惊呼 Oracle 数据库管理员下岗的日子快到了. 在我看来，这恰恰是一个好消息。图形化工具上手容易，不可避免的很多人会浅尝辄止不去研究系统细节的问题，正是真正的 DBA 提高身价的好时候 :)

二是, 对图形化工具一旦产生依赖性, 应付突发事件的时候会有些局促感, 直观的东西隐藏了太多细节,而作为一个 DBA 更多的时候是要主动发现细节内容体现出来的问题; 这一点在讨论中很多人也提到了，一看没有安装 Toad ,就没法子上手了。

问题可能还有其他的，但是不是说 GUI 工具一无是处了，也不能说有这些问题就坚决不用 GUI 了。有的时候，开发人员依赖于 IDE 的, 就遇到的问题咨询 DBA ,不显得自己 IDE 用的很熟练的样子还真的说不过去; 再比如，抽取 DDL 语句这样的日常操作, GUI 工具的便利性还是有一些的。

还是针对图形化工具可能给我们带来的问题来说吧。”工具善其事，必先利其器”, 这个”器”可不是 GUI 工具哦. 建立一套针对自己的跨平台工具包是必须的，很多 DBA 都有一套适合自己的工具包. 当然，光有工具没有用，适当的提高一下记忆力也有必要，至少，再参加面试的时候可以唬主考官一下。

参见 AnySQL 的Blog上的PR

—
一句题外话：作为一个 DBA ，你是希望合格的 DBA 多一些还是少一些好呢?

用 Statspack 收集 SQL 执行计划历史信息

小技巧一个:在一个开发环境中,可以考虑把用户的SQL执行计划历史也收集进来.很简单,但是对开发 DBA 会很有帮助, 根据 HASH_VALUE 查询相关过去某个时间段内的 SQL 执行计划.一共两步:
1 Statspack 的 level 6 收集所有的统计和执行计划. 用 level 6 收集快照(Snap)信息:

SQL> execute statspack.snap (i_snap_level=>6);

2 运行 $ORACLE_HOME/rdbms/admin/sprepsql.sql 脚本抽取特定 HASH_VALUE 的 SQL 信息:

继续阅读 →

Oracle Raptor 更名为 Oracle SQL Developer

Oracle 最近喜欢上了对产品项目改名字, 继 Oracle HTML DB 更名为 Oracle Application Express 之后, Raptor 项目也更名为 Oracle SQL Developer .
Raptor 项目发展迅速, 不到三个月时间的时间内, 已经从 Early Adopter release 1 发展到了 Early Adopter release 4 .
Oracle 承诺在 06 年第一季度发布正式版本.并且,该软件将一直免费. 这样 Oracle SQL Developer + Oracle Database 10g Express Edition 构成了一套免费的 Oracle 开发环境.

继续阅读 →

Statspack使用中存在的几个误区

Statspack 是 Oracle 提供的一个实例级的Tuning工具。很多DBA都喜欢用这个工具来进行数据库的优化调
整。不过在交流中发现很多朋友对这个工具的的运用还有一些问题。下面就其中比较容易出问题的几个方面进
行一下简单的分析。

快照的采样时间间隔问题

我们知道，Statspack的report实际上也就是对比两个快照 (Snapshot，也就是数据库当前状态 ) 得出的结
果。

一般情况下，专家建议生成Statspack报告的快照时间间隔为15-30分钟。

试想，一个人去医院看病，医生对其测量体温，一般也就是5-10分钟左右就可以了，为什么是这麽长的时间？
因为5-10分钟这段时间基本可以近似的得到你的体温。如果时间过短，可能达不到既定的目的，测到的体温会
偏低，时间过长，甚至长达几个小时的话(假设有这种情况)，病人可能都昏迷几次了 ;) 。

对生成Statspack报告的快照时间间隔也是这样，如果两个Snap Time时间过短，数据库的一些主要周期性
事务可能还没有运行，信息收集不完全。如果间隔过长，数据一样会有偏差。

假设如下的情况：系统一直正常，但是最近几天有用户反映，在A时间段应用程序执行很慢。B时间段正常，而
A时间段有一个主要的事务X运行（也是用户使用到的事务）。 B时间段有另外一个比较消耗资源的事务Y在运
行。A和B时间段的跨度比较大。本来你的快照如果覆盖A时间段内就已经能够的收集到比较准确的数据了，但
不巧的是，你的Report 所用的两个Snap ID的时间跨度太长，从而把B时间段内的统计数据也收集了进来。
Statspack 经过比较，“认为”事务Y是对系统有主要影响(这也会在Report上体现出来)，而你，经过分析，认
为Y才是罪魁祸首，接下来，你不遗余力的对Y进行了tuning……

问题出现了！调整了B之后，用户继续报告，A时间段内系统不但没有变快，反而变得更慢，甚至不可忍受。这
种情况是很危险的，可能会对系统造成不同程序的损害。在比较严格的环境中，这已经构成了一次比较严重的
事故。

或许你也要承认，Statspack的快照的采样时间间隔还真需要重视呢……

这是一个Oracle　8.1.7.0.1　版本下的Statspack报告：

                      Snap Id          Snap Time Sessions
------- ------------------ --------
Begin Snap:            637 04-Aug-03 11:59:33       25
End Snap:              646 04-Aug-03 16:29:06       25
Elapsed:                        269.55 (mins)

从中可以看到快照637和快照646之间为269.55 (mins)。这么长的时间跨度，即使数据库在一定时间间隔内
有问题，在这里的体现也会有偏差。
下面的这个Statspack 报告的时间有点不靠谱了：

	                                                                Snap Length
Start Id  End Id              Start Time  End Time                (Minutes)
--------  --------  --------------------  --------------------  -----------
314  1053        11-Dec-03 18:07:13  19-Dec-03 10:53:02      11,085.82

11,085.82分钟? 这么长时间内的数据采集分析，怕是绝大部分内容都是不能相信的了。

还要注意的是，我们说的时间间隔，是Begin Snap和End Snap之间的间隔，而不是相邻两个Snap 之间的
间隔。对于Snap收集的间隔，建议以不要影响性能为准，收集的太过于频繁，会对性能和存储都造成压力。
对于所谓的15-30分钟，不能墨守成规。具体的环境下应该加以调整。

以偏概全

Statspack从本质上说，是对系统的性能统计数据进行采样，然后进行分析，采样，就会有偏差。如何消除偏
差？统计学指出差值随样品个数的增加而降低。所以，只凭借一个Report文档就断定数据库的性能问题出
在某处，是比较武断的做法（个别情况除外）。需要DBA创建多个Report，包括不同时间段，对比进行分析，
这样才会起到很好的效果。在寻求技术支持的时候也最好能够多提交几份Report，便于支持人员迅速帮助解决问题。

继续阅读 →