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

有关Timed_statistics参数

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

你成了泄密者?

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

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

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12137615/viewspace-548862/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/12137615/viewspace-548862/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Go语言(也称为Golang)是由Google开发的一种静态强类型、编译型的编程语言。它旨在成为一门简单、高效、安全和并发的编程语言,特别适用于构建高性能的服务器和分布式系统。以下是Go语言的一些主要特点和优势: 简洁性:Go语言的语法简单直观,易于学习和使用。它避免了复杂的语法特性,如继承、重载等,转而采用组合和接口来实现代码的复用和扩展。 高性能:Go语言具有出色的性能,可以媲美C和C++。它使用静态类型系统和编译型语言的优势,能够生成高效的机器码。 并发性:Go语言内置了对并发的支持,通过轻量级的goroutine和channel机制,可以轻松实现并发编程。这使得Go语言在构建高性能的服务器和分布式系统时具有天然的优势。 安全性:Go语言具有强大的类型系统和内存管理机制,能够减少运行时错误和内存泄漏等问题。它还支持编译时检查,可以在编译阶段就发现潜在的问题。 标准库:Go语言的标准库非常丰富,包含了大量的实用功能和工具,如网络编程、文件操作、加密解密等。这使得开发者可以更加专注于业务逻辑的实现,而无需花费太多时间在底层功能的实现上。 跨平台:Go语言支持多种操作系统和平台,包括Windows、Linux、macOS等。它使用统一的构建系统(如Go Modules),可以轻松地跨平台编译和运行代码。 开源和社区支持:Go语言是开源的,具有庞大的社区支持和丰富的资源。开发者可以通过社区获取帮助、分享经验和学习资料。 总之,Go语言是一种简单、高效、安全、并发的编程语言,特别适用于构建高性能的服务器和分布式系统。如果你正在寻找一种易于学习和使用的编程语言,并且需要处理大量的并发请求和数据,那么Go语言可能是一个不错的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值