分类归档: Database

关于 CBO 的文档

昨天我提到过, The Search for Intelligent Life in the Cost-Based Optimizer 是最经典的两篇关于 CBO 的文档之一. 有朋友问我, 另外一篇是什么?
其实我说的另一篇就是 Wolfgang BreitlingA Look under the Hood of CBO: The 10053 Event. 这篇文档最早出现在 2002 年,如同名字暗示的,内容重点在 10053 事件的解释上.反复阅读之后, 相信对 CBO 已经有所理解的朋友都能够利用这篇文档中的信息对跟踪文件的信息进行解释了.Wolfgang Breitling 还写了很多关于 Oracle 优化器的论文. 喜欢研究的朋友不妨找找这些文章的漏洞.

继续阅读

此文作者:, 位于 Database 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Statspack 的一些资源

“大家帮我看看这个Statspack吧!” — 如果你去一些中文的数据库论坛,你会发现这个请求出现的非常的频繁. 一些朋友可能知道通过 Statspack 来进行数据库优化,可面对报告的各项指标却不知如何下手.
在这里介绍一点关于 Statspack 的技术资源.
Performance Diagnostics using STATSPACK data 作者是:Mary Crystal 与 Tim Gorman . (Tim Gorman 就是 The Search for Intelligent Life in the Cost-Based Optimizer 这篇经典文章的作者.这是 关于 CBO 的两篇最优秀的论文之一.) 该文档覆盖了 Statspack 的大部分内容. 并且介绍了一些如何有效挖取 Statspack 信息的技巧.
Getting fast results from Statspack: How do you apply the YAPP method on a statspack report? 这个文档介绍了如何运用 YAPP(Yet Another Performance Profiling Method) 方法快速分析 Statspack. 在上面的连接中,还可以下载 YAPP 方法的 PDF 文档.

继续阅读

新的Oracle性能神话?

很多 DBA 应该都记得这篇文章吧 ? Myths & Folklore About Oracle8i Performance Tuning. 这篇文章的出现, 粉碎了当时的不少图书中标榜的实际上没有什么作用的优化”技巧”.

来自 OraPub 的 Craig A. Shallahamer 在一篇新的论文 Modern Performance Myths 试图定义新的 Oracle 性能神话.包括如下四条:

  • Myth #1. Decreasing wait event time will always decrease Oracle response time.
  • Myth #2. Decreasing wait event time will always decrease end-to-end response time.
  • Myth #3. Profiling sessions is the best way to diagnose performance problems.
  • Myth #4. Focusing on where most of the time is spent is always the best approach.

老实说, Craig 这篇论文写的非常”绕”.完全看明白要费点时间.因为第一条和第二条 Myth, 说的都是”always”, 只需要举出一个反面例子即可. 非常有趣的是第三条, Profiling sessions , 因为这是 Hotsos 的 Cary Millsap 在 Optimizing Oracle Performance 一书中 Method R 方法(参见:Oracle 数据库优化的R方法)所提倡的手段. 要反驳第三条 Myth 倒也不难, Profiling sessions 只能做到针对特定 Session(or User) 进行优化,这个优化能从全局的角度上看是否是成功的? 就不能简单的下判断. Craig 的建议是在系统级和会话级进行响应时间分析(RTA).

那么如何避免这些所谓的 Myth 呢? Craig 的答案是 The Holistic Problem Isolation Method (整体问题隔离方法,HPIM), 识别 Oracle,Application,OS (三环法)每个子系统的瓶颈,并且理解各个子系统之间的关系.

Cary Millsap 在Oracle 性能优化 一书中提出的 Method R 的时候应该是自信满满, 但是 Craig 的这篇文档无疑也说明了 Method R 的一些遗漏之处.方法论是一个不断进化的过程, 没有所谓完美的方法,随着对Oracle优化认识的不断深入,相信也会有号称更为优秀的方法出现.但是能否更有效用在实践中,这是一个主要问题.

—-
BTW:
小道消息:Craig A. Shallahamer 将在 07 年推出一本名为 Forecasting Oracle Performance 的 Oracle 图书.期待.

Oracle 用户授权需谨慎

看到 有人提问关于授权的问题. 不由得想多说几句. Oracle 9i 以及以下版本的数据库,默认的数据库角色有些不太合理的地方. DBA 管理的过程中,如果不太注意的话,可能会带来麻烦或者潜在的隐忧. 比如最常见的 CONNECT 角色.

User => FOO has been granted the following privileges
====================================================================
ROLE => CONNECT which contains =>
SYS PRIV => ALTER SESSION 		grantable => NO
SYS PRIV => CREATE CLUSTER 		grantable => NO
SYS PRIV => CREATE DATABASE LINK 	grantable => NO
SYS PRIV => CREATE SEQUENCE 		grantable => NO
SYS PRIV => CREATE SESSION 		grantable => NO
SYS PRIV => CREATE SYNONYM 		grantable => NO
SYS PRIV => CREATE TABLE 		grantable => NO
SYS PRIV => CREATE VIEW 		grantable => NO

这里面的 ALTER SESSION 就是一个问题. 恶意的用户很容易利用这个权限给系统带来麻烦.举两个例子,一个是 修改当前 Session 的 cursor_sharing 参数值为 FORCE ,然后提交可触发 Oracle Bug 的查询(cursor_sharing 在 FORCE 模式下 Bug 很多) , 很容易让数据库崩溃. 或者恶意用户提交 alter session set hash_area_size … 的修改语句, 给自己设定一个超大的 HASH_AREA_SIZE , 再提交一定的查询,也会给系统性能造成很糟糕的影响.
这个 CONNECT 角色在 Oracle 10g 中已经修改了,只有 create session 的权限.

继续阅读