2009-07-07 Tue
用Perl写了不少脚本, 例如收集数据的程序(gatherdata.pl), 需要在Crontab中进行任务设置, 这时就会发现原本在命令行下手工可以执行的Perl程序, 放到Crontab中就不能执行了, 原因是因为手工跑时, 已经设置了很多的环境变量, 而由Crontab启动程序时通常没有设置如下环境变量.
ORACLE_HOME=......
ORACLE_SID=......
LD_LIBRARY_PATH=$ORACLE_HOME/lib
NLS_LANG=.ZHS26GBK
为解决这个问题, 常常会写一个Shell脚本来调用Perl脚本, 在Shell脚本中进行环境变量设置. 其实这个工作可以放到Perl脚本中, 省去编写Shell脚本这一步. 在数据收集脚本中, 通过命令行传入ORACLE_SID, 然后Perl脚本从特定目录的配置文件中, 得到与ORACLE_SID相对应的ORACLE_HOME (getOracleHome函数), 然后在Perl打开数据库连接前进行环境变量设置.
$ENV{"ORACLE_SID"} = $sid;
$ENV{"ORACLE_HOME"} = getOracleHome($sid);
$ENV{"LD_LIBRARY_PATH"} = getOracleHome($sid)."/lib";
$ENV{"NLS_LANG"} = ".ZHS16GBK";
接下来就可以在Crontab中直接进行任务调度了.
1 1 * * * /home/oracle/admin/bin/gatherdata.pl -S test ......
据说有公司的解决方法是将Oracle的客户端库文件(libclntsh.so)复制到系统库目录(/usr/lib), 但我个人不是很喜欢这种做法, 所以去想出这个方法.
Relative Posts:
2009-07-06 Mon
阿里巴巴是电子商务公司，淘宝是电子商务公司，卓越、当当是电子商务公司，京东商城、红孩子、凡客是电子商务公司，你在淘宝开个小店都算电子商务……你真的这么认为？
其实，根本不存在所谓的电子商务公司，你要么是电子，要么是商务，要么是电子加商务。举例说，阿里巴巴（包括淘宝）是电子，或者说是提供商务基础设施的公司，它本身并不经营任何物理商品。京东商城是商务，凡客是商务，淘宝上的数百万卖家也都是商务，简单说，它们都是卖东西的。Amazon是电子加商务，它本身既卖东西，又提供商务基础设施。
我们所说的“电子商务公司”，其实彼此之间千差万别，核心竞争力各不相同。以阿里巴巴为例，作为中国最大的“电子商务公司”，阿里巴巴自身不出售任何商品，所以它从来不需要考虑诸如供应链、生产、仓储、物流、配送等基本商业问题。在马云心目中，所谓电子商务，就是电子部分归阿里巴巴，商务部分归社会，一言以蔽之，我电子，你商务。
马云的“大淘宝战略”，随着淘宝开放平台的推出，已经变得更加清晰，其核心就是，让一切商务活动“Powered by Taobao”。
由于“在线”将日益成为几乎所有商务公司的必选项，所以将来可能不存在不在线的商务公司。所谓的电子商务，将逐渐分化成两类公司，一类是商务公司，直接销售商品，一类是为商务公司提供电子支持的公司。你不能把这两类公司，统称为“电子商务公司”。
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值, 就确定了是这个原因引起的, 需要更改一下我们的分析策略了.
