存档

2008年7月 的存档

第一个问题是bind peeking,很容易造成执行计划不稳定,SQL的执行计划可能会突然会变得很差,造成系统瞬间LOAD很高。
第二个问题是recost for order by,oracle往往会过高的估计排序的成本,从而忽略了索引的选择性,而选择一个避免排序的执行计划,通常这个执行计划都很差。
今天又碰到了这个问题,差点造成故障。由于应用的某个功能,需要对一个时间列gmt_create创建索引,当索引创建后(创建时带着compute statistics参数),一条sql的执行计划就发生了改变:
select * from
(select * from table where member_id=:1 order by member_id,gmt_create desc) where rownum<=100
oracle为了避免排序忽略了member_id上的索引,反而使用gmt_create时间列上的索引,走full index scan来避免排序。
我尝试对索引和列进行分析,都无法使这个sql走到正确的执行计划上,最终只好将这个索引删除。
相比较而言,9i的数据库几乎没有出现过这样的问题,应该是10g在CBO的计算上做了很多改变。
oracle提供了隐含参数,通过设置隐含参数_optim_peek_user_binds=FALSE,可以关掉bind peeking功能。
另外一个隐含参数,_sort_elimination_cost_ratio,描述是:cost ratio for sort eimination under first_rows mode.将这个参数修改为1,降低ORACLE计算order by的成本。这个参数默认是0。看解释有点恐怖:A value of 0 would mean that an execution plan with ORDER BY sort elimination be chosen even if it is more expensive than queries that [...]

7 19th, 2008 | Filed under 大话技术
标签:

我总结了一些看起来对我们有用的新特性
#PL/SQL
可直接定义序列变量 DECLARE n NUMBER := Seq.Nextval;
增强的正则表达式
PL/SQL CONTINUE statement:循环中,跳过本次循环,继续下次循环
#Availability
standby增强
Compression of Redo Traffic (Only for Gap Resolution) Over the Network in a Data Guard Configuration
压缩传递redo(仅在Gap Resolution的情况下)。
Real-Time Query Capability of Physical Standby Database
这是我觉得非常好的一个功能,就象mysql的复制特性一样,standby可以实时提供读的服务,这样只读的应用就可以部署在standby上了。
Snapshot Standby
可以打开standby进行读写操作,使用完成后,可以继续恢复。这个特性对于我们一些系统非常有用,比如ERP或者测试系统。
Flashback Transaction
可以flashback已经提交的事务(或其相关的事务)。
SMP Scalable Redo Apply
This feature enables faster performance of media recovery and also Data Guard Redo Apply (physical standby database)
DDL With the WAIT Option
在做DDL操作时,如果不能获得DDL_LOCK,可以等待(DDL_LOCK_TIMEOUT初始化参数)后再重试,而不是直接报错。
Enhanced [...]

7 8th, 2008 | Filed under 大话技术
标签:

1.自己得行
2.别人说你行
3.说你行的人必须得行
4.身体得行
–EOF–
American Pie

7 8th, 2008 | Filed under 一地鸡毛
标签: