2009-07-04 Sat
刚到昆明，23摄氏度的气温，再回想起3个小时前北京恐怖的37摄氏度高温，感觉仿佛进入了天堂一般。从头到脚都是舒服的感觉，刚刚在飞机上的困倦马上一扫而空了。
7、8月份正是云南野生菌上市的季节，于是有幸品尝云南的野生菌类，在机场不远的菌菇火锅一条街，自然是找老字号了，呵呵。
在北方一直迟到的野生蘑菇也就是有限的几种，大都是松菇。此次可真是见识了云南的蘑菇的种类，据说中国有900多种可以食用的菌类，云南就占了800多种。不仅仅是饱口福，而且还饱眼福。松茸、鸡枞、老人头、美味牛肝菌、竹荪、盐渍牛肝菌、白蘑菇、干巴菌、谷熟菌、块菌、虎掌菌……举不胜举啊，一个土鸡的锅底，炖了有近十种野生菌。据说其中一种是有轻微的毒性的蘑菇，要煮10分钟以上才可以清楚毒性，方可入口。不然晚上会有跳舞的美女在你眼前来回闪动。呵呵，听起来也有意思。北方对野生菌的吃法往往是肉多菇少，这里恰好相反。味道无法形容…… 呵呵！、
翌日下午，拜访有名的云南过桥米线，海碗加上各式各样的佐料小盘，让人一看就有食欲。
短暂的36个小时，还陶醉在昆明宜人的气候的时候，就要返程了，真期待下次能够找个机会再来昆明好好的玩玩。
回到家就凌晨快1点了，北京依然炽热，弄的毫无睡意。
Tags - 云南 , 昆明 , 过桥米线 , 野生菌
2009-06-30 Tue
这几天有几个分区表上的SQL执行计划不正常, 感觉上不应当, 已经设置了几个容易引起优化器选错执行计划的参数了.
ALTER SYSTEM SET OPTIMIZER_DYNAMIC_SAMPLING=0;
ALTER SYSTEM SET "_optim_peek_user_binds"=false;
按照现行的表分析原则, 只统计了表的全局索引, 不统计表分区上的索引, 因为分区会有增减操作, 不是每个分区都有数据, 也没有定下来要经常分析表, 而是分析后如果不出问题就不再分析. 现在SQL走错了, 可能的原因有什么呢? 重新分析一下不行, 看了一下执行计划, 发现全表扫描的COST值很底, 估计是用了分区上的统计信息了, 于是手动将全局的统计信息复制到每一个分区上得以解决.
为了得到原因, 回顾了一下当时的SQL, 发现有一个特征, 就是出问题的SQL都能定位到某个分区或某些分区, 今天就模拟了一下情况, 先只有全局统计信息. 首先用分区列范围查询, 去试了一下, 发现用的是分区级的统计信息.
SQL> select * from database_perf_statistics
2 where day > sysdate - 100 and day < sysdate + 300;
----------------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------------
| 0 | SELECT STATEMENT | 3 (0)| | |
|* 1 | FILTER | | | |
| 2 | PARTITION RANGE ITERATOR| 3 (0)| KEY | KEY |
|* 3 | TABLE ACCESS FULL | 3 (0)| KEY | KEY |
----------------------------------------------------------------
然后全表扫描, 涉及所有的分区时, 用的是全局的统计信息.
SQL> select * from database_perf_statistics;
----------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------
| 0 | SELECT STATEMENT | 2196 (1)| | |
| 1 | PARTITION RANGE ALL| 2196 (1)| 1 | 4 |
| 2 | TABLE ACCESS FULL | 2196 (1)| 1 | 4 |
----------------------------------------------------------
再测试一个开包的查询条件, 发现用的也是分区的统计信息.
SQL> select * from database_perf_statistics where day > sysdate - 100;
---------------------------------------------------------------
| Id | Operation | Cost (%CPU)| Pstart| Pstop |
---------------------------------------------------------------
| 0 | SELECT STATEMENT | 3 (0)| | |
| 1 | PARTITION RANGE ITERATOR| 3 (0)| KEY | 4 |
|* 2 | TABLE ACCESS FULL | 3 (0)| KEY | 4 |
---------------------------------------------------------------
重新设置了一下各分区的统计信息, 再验证一下上面的SQL的COST值, 就确定了是这个原因引起的, 需要更改一下我们的分析策略了.
Relative Posts:
2009-06-29 Mon
用oramon将数据库的主要负载信息收集到了性能数据库, 用DataReport去显示这些性能数据时, 发现要写很多个SQL语句, 要不同的列显示一次, 例如要显示三幅图片(平均Load值, 用户CPU消耗, SQL执行次数)就得执行三个SQL.
WEBCHART.QUERY_1=SELECT TIME, LOAD FROM DATABASE_LOAD ...
WEBCHART.QUERY_2=SELECT TIME, CPUUSR FROM DATABASE_LOAD ...
WEBCHART.QUERY_3=SELECT TIME, EXECS FROM DATABASE_LOAD ...
其实DATABASE_LOAD是一个宽表, 可以一次查询出多个列的数据来, 几个图片可以共享一次查询的结果, 就可以减少数据库的执行次数, 提高页面访问速度. 如下所示, 只需要指定某个查询的SQL语句为减号.
WEBCHART.XCOL=TIME
WEBCHART.QUERY_1=SELECT TIME, LOAD, CPUUSR, EXECS
FROM DATABASE LOAD ...
WEBCHART.YCOL_1=LOAD
WEBCHART.QUERY_2=-
WEBCHART.YCOL_2=CPUUSR
WEBCHART.QUERY_3=-
WEBCHART.YCOL_3=EXECS
最近做了一次大的数据库改造, 用DataReport分析性能数据比较繁烦, 因此才注意到这个方面的性能提升.
Relative Posts:
2009-06-26 Fri
Michael Joseph Jackson，1958年8月29日－2009年6月25日
他是一个传奇，他同时也创造了一个传奇。13首冠军单曲，13届葛莱美奖(中文维基有误)，7亿5千万的专辑销量，永远并且唯一的King of Pop。
在他走后人们为他同样创造了一个传奇，Twitter热榜前10几乎全是有关消息，Amazon上音乐销售排行前15名全是他的专辑，众多音像销售店内他的专辑售空，网络甚至因为相关消息而阻塞，众多电视台开始循环播放相关信息。
昨天是属于历史的，明天是属于未来的，今天是属于Michael Jackson的。
相关日志
