DBA notes

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，便于支持人员迅速帮助解决问题。

有关Timed_statistics参数

虽然这算是一个低级的错误，还是很遗憾，常常看到一些朋友对这个参数的忽略．如果在 Timed_statistics的 值设置为False的时候进行收集，可以说，收集到的东西用处不是很大 (我想你不会只想看一些实例名字、初始 化参数之类的信息吧)。甚至可以说，如果该参数不设置为True，性能分析无从说起。

你成了泄密者?

Statspack 报告会汇集到你的数据库系统比较全面的信息，如果不对报告加以"伪装"就随意发布到一些技术论坛上寻求支持，无疑给 一些黑客以可乘之机。你的数据库名字、实例名字、主机名、数据库版本号、兼容参数、关键的表名字、文件路径等等， 尤其是关键的SQL都是黑客们或是恶意入侵者的最好的参考信息。

商业竞争对手也可能正在对你的数据库虎视眈眈。

如果你有意积极配合这些恶意窥探者，那么就把你的Statspack公之于众吧 :-)

参考信息

旧版本:[Oracle] Statspack使用中存在的几个误区
日期：02-Jan-2004 　
出处：http://www.dbanotes.net
版本：0.94

迁移到 Blog 上,便于以后维护

Posted by Fenng at 9:14 PM | Permalink | Comments (3)

无数 Blogger 在向更多的人传递一个消息: Google 中国黑板报。但不知道给 Google 这个黑板报提意见的有多少? 我去了一封邮件建议提供留言评论功能,不到 1 秒种就收到了回信--自动回复的.不用激动，信是乱码! 当然我用的是 Gmail 发送的邮件. 现在我用 Gmail 还经常有这种乱码的现象发生.

作为 Google 的一个忠实用户,多么希望 Google 的一些产品能够快速改进阿.随便列举两个:

1 Gtalk 的文件传输功能。我曾经不止一次地和朋友说过,如果 Gtalk 能提供文件传输的功能，其他大部分 IM 都可以不用了.但是这个功能就是迟迟不见,怎么不让人着急?

2 Google Adsense 的收入用来做 Google Adwords 广告,或者广告收入可以直接汇入在线支付工具.对于一些小网站来说,这个"以网养网"更有效; 这样就节省了从银行走帐了,支票对广大用户来说太麻烦.

最近有不少传闻 Google 将推出 Gbuy , 个人觉得这对广大 Blogger 和中小网站来说, 是一个非常值得期待的产品, 如果这个产品的帐户和广告等业务捆绑起来, 方便多了. 估计到时候印着 Google Donate! 的按钮也会向 Google Adsense 一样迅速占领整个互联网.

期待虽然很多,但是 Google 的动作还是让人有些着急. 也难怪, Google现在也是庞然大物了呀! WikiWiki ,Google !

--
BTW: 杭州下雨.手痛.脾气不好

Posted by Fenng at 8:07 PM | Permalink | Comments (11)

注意到在 DBA Wiki 的 Apache Error Log 里面有这样一条信息频繁出现：

http:[Thu Feb 12 22:16:11 2006] [notice] cannot use a full URL in a 401 
ErrorDocument directive ---ignoring

在 bin 目录下的　.htaccess 我定义了 401 错误的重定向．检查了一下．原来 Apache 下不能用 URL 路径．必须要本地路径才可以．修改为如下：

# File to return on access control error (e.g. wrong password)
# By convention this is the TWikiRegistration page, that allows users
# to register with the TWiki. Apache requires this to be a *local* path.
ErrorDocument 401 /bin/view/TWiki/TWikiRegistration

修改之后该错误不再出现．记录一下．或许对别人也有用．

Posted by Fenng at 9:48 PM | Permalink | Comments (1)

有朋友问我在 DreamHost 上配置 TWiki 的情况．下面简单说说我的安装过程．

TWiki 最近发布了 4.01 版本．相对 4.0 有了性能上的改进． 首先通过 SSH 登录到自己的帐户上．准备好合适的目录之后，下载并解压缩文件．

$ wget http://twiki.org/p/pub/Codev/Release/TWiki-4.0.1.tgz
$ tar -zxvf TWiki-4.0.1.tgz 

进入该目录后．

$ cp bin/LocalLib.cfg.txt bin/LocalLib.cfg
$ vi bin/LocalLib.cfg

编辑该文件.把 $twikiLibPath 指向实际的路经(要绝对路径)．

然后

$ cp lib/LocalSite.cfg.txt lib/LocalSite.cfg
$ chmod +w lib/LocalSite.cfg
$ vi lib/LocalSite.cfg

编辑这个文件.修改对应的一些路径变量．都由英文说明．注意有的是相对路径．有的是绝对路径．这个地方写错了问题倒也不大，后面还有纠正的机会．

在 bin 目录下创建 .htaccess 文件．加入如下三行：

Options +ExecCGI
SetHandler cgi-script
Allow from all

然后在浏览器中输入　http://www.YourDomain.com/twiki/bin/configure 查看. 如果幸运的话．应该可以看到配置页面出现了．如果得到了一个 500 错误．很可能是你的 .htaccess 文件权限有问题，确保有读取权限．通过查看你的 Apache Error Log 应该可以看到更多的提示信息．比如：

tail -f /home/Your_User_Name/logs/Your_Domain_Name/http/access.log

如果先前的 LocalSite.cfg 文件配置有问题．这里会看到告警甚至是错误信息．输入正确的路径后点击 Next ，输入密码后重新回到该页面．如果配置不正确．还是会看到警告．经过几次尝试，应该会成功． 之后你可能会点击"browse to the TWiki Reference Manual" 去查看文档．但是你会发现该页面的图片信息显示不出来． Pub 目录下的一些文件权限有问题．这条命令可以简单的解决：

$ find pub -print | xargs chmod +r 

OK．一个基本可用的 TWiki 已经配置好了．是不是有些累了? 先看看 TWiki 的文档吧．毕竟有好多陌生的概念需要先熟悉一下才能继续进行．休息一下再进行安全配置和权限配置.

更多参考信息:

Installing TWiki on Dreamhost

TWiki DakarRelease安装备忘

我收藏的书签

BTW: 这里快成了非官方的 DreamHost 支持了．

情人节快乐!

Posted by Fenng at 9:28 PM | Permalink | Comments (9) | TrackBacks (1)