09.28.06
暂停更新blog 15天
理由:结婚.
09.27.06
重读SG系列之前言
最近荒废了很久没有看书了,看起来似乎是公司的事情很忙,实际上,只不过是我懒的借口,想当年,为了考过ocp,每天看书到12点,没有一天间断,如果那天间断了,自己都觉得内疚,那个时候,也是我oracle从不知道到了解的一个阶段吧,后来在公司积累了一些经验,但是还是十分的不够,现在人也懒了,基本上就没看啥书.
希望这次能坚持下来,把9i的sg好好的看一遍,我是考的8i,所以说实话,9i的sg还真的没有通读,所以这个系列,就是记录sg中已经有的内容,但是以前遗漏了,或者是以前没有理解的内容,希望对自己,对别人有所帮助吧.
重读SG系列之三 内存结构
oracle的内存结构,大家都知道,SGA+PGA,那么现在我们来看看oracle的SGA的组成.
SGA在instance启动的时候建立,是instance的基本组件,并且由shared pool,data buffer cache,redo log buffer以及其他部分组成,在9i开始,数据库支持动态内存管理,也就是说,在数据库中,可动态的调整shared pool,data buffer cache,以及large pool的大小,当然,其要求是所有sga的组件的总和不超过sga_max_size的限制.注意了,这里是不包括redo log buffer的,也就是说,你要修改redo log buffere的大小,就必须重启数据库,当然,我不知道这个是不是因为和redo log buffer的大小的调整非常少有关系,一般来说,通过调整redo log buffer来提高性能的情况确实也是十分少见的.
在oracle的内存结构中,还有一个关键的地方,sga分配的时候,是有一个最小粒度的,也就是说,每次最少要分配这个最小的粒度,那么,对于SGA小于128M的,这个数值是4M,其他的就都是16M了,也就是说,分配的时候,我们可以尽量是这两个数字的整数,那么理论上应该可以避免内存的浪费或者是碎片.
这里有个有趣的东西就出来了,一个oracle数据库,最小可以分配多少sga?12M,这个就是最小的了,不能比这个还小,理论依据是,首先,既然是讨论最小的sga,那么,他的最小的粒度是4M,而oracle最少要分配一个给fixed SGA,一个给data buffer cache ,一个给shared pool,也就是最少3个,那就是4M*3=12M了.
重读SG系列之二 文件类型
oracle数据库中,对oracle server的定义是oracle server由oracle database和oracle instance组成.并且oracle database是只报刊三种类型的文件,他们分别是data files,control files,redo logs.这也是oracle 数据库中,最关键的三种文件了,对于这三种文件的损坏,基本上都要求作恢复了,而且,可以看的出,这三种文件中,oracle对control file是默认作了镜像的,而对于redo logs也是推荐每个group中,应该包含多个文件在不同的磁盘甚至是控制器上.由此可见这三种文件地位的关键.
而且,虽然oracle数据库中,有很多其他非关键文件,例如archived redo logs,parameter files以及password files,但是,oracle严格的说明,oracle数据库的物理结构,仅仅包含data files,control files以及redo logs
09.26.06
现场数据库一次调优过程
今天在现场,开发的兄弟反映有一个sql语句跑的特别慢.
ok,把sql拿过来看看,
语句如下:
SELECT DISTINCT B.OBJECTID, B.OBJECTNAME, B.CLDBH, B.ZDLJDZ, B.CLDXH,
decode(B.CLDXZ, ‘40’, ‘总加组’, ‘测量点’) AS CLDXZ, D.MC AS SJLX,
decode(B.CLDXZ, ‘40’, ‘2’, ‘1’) AS XXDBS, D.DM AS BZSJLX,
to_char(A.SJSJ, ‘yyyymmdd’) AS SJSJ, C.DJLX, B.ZDGYH AS GYH
FROM RW_LDSJ A, V_MISSPOINT_CLD B, XT_SJRWDZB C, XT_BZDMB D
WHERE B.CLDBH = A.CLDBH
AND B.ZDGYH = C.GYH
AND A.RWH = C.RWH
AND C.SBLX = decode(B.SBSX, ‘01’, ‘10’, ‘02’, ‘10’, ‘03’, ‘20’, ‘04’, ‘30’, ‘05’, ‘30’, ‘10’)
AND C.BZSJLX = D.DM(+) AND D.DMLB = ‘BZSJLX’
AND A.SJSJ >= to_date(‘2006-9-25’,’yyyy-mm-dd’)
AND A.SJSJ < to_date(‘2006-9-25’,’yyyy-mm-dd’) + 1
AND C.SBLX = ‘20’
AND C.GYH = ‘100’
AND B.DXLX = 10
AND C.BZSJLX IN (21,22,23,24,25)
ORDER BY B.ZDLJDZ, D.DM
首先来分析使用到的表吧,表RW_LDSJ中有记录760万,v_misspoint_cldb是一个视图,xt_sjrwdzb数据量39条,xt_bzdmb有数据3600行.
rw_ldsj上有主键在字段cldbh,rwh,sjsj,gyh上,有另外一个索引在字段rwh,sjsj上.
首先简化这个sql,明显的,B.ZDGYH=C.GYH,而下面有C.GYH=’100’,那就是B.ZDGYH=’100’,其次,明显的C.SBLX=’20’,而上面的decode函数中,也过多了吗,另外,C.BZSJLX IN(21,22,23,24,25)这个用一个>=和< 不是很好吗,我是很反对随便用in的.
修改后的代码如下:
SELECT distinct B.OBJECTID, B.OBJECTNAME, B.CLDBH, B.ZDLJDZ, B.CLDXH,
decode(B.CLDXZ, ‘40’, ‘总加组’, ‘测量点’) AS CLDXZ, D.MC AS SJLX,
decode(B.CLDXZ, ‘40’, ‘2’, ‘1’) AS XXDBS, D.DM AS BZSJLX,
to_char(A.SJSJ, ‘yyyymmdd’) AS SJSJ, C.DJLX, B.ZDGYH AS GYH
FROM RW_LDSJ A, V_MISSPOINT_CLD B, XT_SJRWDZB C, XT_BZDMB D
WHERE B.CLDBH = A.CLDBH
AND B.ZDGYH = ‘100’
AND A.RWH = C.RWH
AND b.sbsx=’03’
AND C.BZSJLX = D.DM(+)
AND D.DMLB = ‘BZSJLX’
AND A.SJSJ >= to_date(‘2006-9-25’,’yyyy-mm-dd’)
AND A.SJSJ < to_date(‘2006-9-25’,’yyyy-mm-dd’) + 1
AND C.SBLX = ‘20’
AND C.GYH = ‘100’
AND B.DXLX = 10
AND C.BZSJLX >=21
AND c.BZSJLX<=25
ORDER BY B.ZDLJDZ, D.DM
看起来似乎要简单一点.
执行一把看看,需要260s,这个时候,系统居然既然除了jobq slave wait等待事件.
看执行计划,表rw_ldsj这个表确实走的索引,但是走的是非主键的.这就不对吧,如果走主键,事实上,rw_ldsj这个表中的所有主键字段都出现在where中了,应该要走主键才对.
这个时候,作一个强制使用pk索引的hint,看看,快多了吗,才3s就搞定了.提高了接近90倍.
这个时候想到后面的定时分析数据库中所有表的job,去看看,每一个月才一次,晕呀,这个不是要7天一次的吗(rw_ldsj中,每7天产生数据800万以上,然后把一周以前的删除,也就是insert前先删除过期数据),如果一个月才分析,显然会导致统计数据不准确
那么我分析下这个表,取样选择1,很快就分析完成,去掉hint,看执行计划,使用了pk,ok,应用上看看,果然快了,爽.
总结总结:如果要分析oracle的性能问题,一定要让sql语句在你的控制下使用你预先想到的执行计划,否则就该看看是为啥了.当然了,使用cbo,必须经常分析,特别是对于数据改动频繁的表,否则,你会得到你极其不希望得到的结果.
Sybase的字符集问题
今天完成了一个sybase开发库的迁移工作，中间碰到sybase的字符集问题，又学到一点东西，虽然是比较基础的东西。
通常sybase软件和数据库服务配置完成后，都需要修改default language和charset以满足你的应用需求。本例在windows下安装后，sybase server的default language 为english，charset为cp850，而应用需要采用的字符集eucgb，语言为chinse。
服务器端修改方法如下：
1、查看当前数据库字符集
sql>sp_helpsort
sql>go
2、安装字符集
$SYBASEcharsetseucgb> charset -Usa -Psa_pass -Sserver_name binary.srt eucgb
3.在SQL环境中
>select name,id from syscharsets
>go
找到name为cucgb对应的id(假设为170)
4.配置默认字符集
>sp_configure “default character set id”,170
>go
5、修改完成后重启两次（第一次重启数据库会down掉）
客户端：
在$SYBASElocaleslocales.dat中找到[NT]项下面的
locale = enu, us_english, iso_1
locale = fra, french, iso_1
locale = deu, german, iso_1
locale = japanese, japanese, sjis
locale = chs, chinese, eucgb
locale = cht, tchinese, big5
locale = kor, korean, eucksc
locale = us_english.utf8, us_english, utf8
locale = default, us_english, iso_1
直接修改最后一行default的language和charset即可。
当然用server config也同样能完成上面的功能
详细可参考：http://www.sybase.cn/cn/content/support/exp_jszc_ase_cj_031105.html
09.21.06
电梯惊魂
今天着实被吓到了,这已经是第二次了,第二次碰到电梯在上行过程中,突然下降,然后开门.
今天晚上吃完饭,因为老板过来,大家就一起,一共14个人.我们在现场的办公地点是在一个四星酒店的20楼,而这里的客梯到18楼是最高,我们只能走后面的员工电梯,也就是酒店的货梯.
电梯上写的是限定13人,1000kg,不过我们曾经在这个电梯中上了17个人,本以为没事,电梯顺利的上升,到了14楼,不好意思,不是我迷信,电梯上就是显示14层.
突然电梯剧烈下降,高度大概是1.5m左右(估计的),然后紧急停止,这个时候大家还没搞明白是怎么回事情,停止了大概3-5秒左右,电梯再次紧急下降,大概0.5m左右,再等待大约5-8秒左右,电梯门开了,大家蜂拥而出,很明显的看的出来,电梯的高度比楼层低了大概10厘米左右,也就是电梯门和地面间有一个坎,也就是说,可以肯定的,这个是电梯的问题了.
说实话,其实电梯下降的时候,我还没有啥害怕的感觉,那是啥感觉列,就象飞机起飞后,在爬坡的时候,一般都有一个失重感的过程,完全类似的感觉,所以下降的时候,没有啥害怕,但是出来后,再想想.还真有点害怕.虽然我也知道,电梯有保险系统,电梯基本上是安全的,十分安全,最起码比坐汽车安全.如果在以前,我一个人,我也就不怕了,但是现在,有了爱我的人,也是我爱的人,我答应过她,我要照顾她,我是真的怕了.
虽然我知道电梯是安全的,还是希望以后不要有这种经历,上次碰到这种事情,一段时间内坐电梯有点恐电梯,估计最近还是有点恐电梯了,可是不可能爬上去,那可是20楼.
或许回杭州,该去灵隐烧香了.
09.14.06
IBM P510启动直接进诊断模式
今天装了两P510的机器，AIX5.3的操作系统，我们先将这个机器的预安装的操作系统覆盖为AIX5.3的BOS，然后重启
这个时候就酷了，机器直接进诊断模式了。要我选择诊断的方式，无论我如何选择，最后都是以乱码界面以以及reboot结束。这就有点郁闷了，机器硬件都是正常的，从HMC连到机器的ASM上去看，也没有严重的故障出来，但是表现的就是机器不行，郁闷呀。
打电话给800，扯来扯去10多分钟，他们说是什么OS的版本不对，这个那个的，都瞎扯，可要知道，我两个机器是一样的，一样的装，现在说OS或者说别的，肯定是不对的了。
最后要我告诉他们液晶面板上的内容，我把液晶面板的内容告诉他们，其实我的面板显示的是：
01 M V=F
T
这个时候，800告诉我，是因为我的启动模式不对，我的启动模式表示的是手工启动，ok，在ASM中将Power/Restart Control下的Power On/Off System下的System operation mode修改为normal，然后再重新启动系统。
这个时候看液晶面板上，已经变成了
01 N V=F
T
这个时候，就能正常进操作系统。
看来unix还有的学，当然，ibm的老大们，这么多机器，就这一个把启动模式设置为手工，看来这样的大企业也不是很规范的说。
测试了下,当同时满足以下的条件,就会导致系统启动自动进入诊断模式:
1:系统的启动模式设置为manual
2:光驱中有启动盘(CD版本的AIX第一张或者是DVD版本的AIX)