因为某个项目的原因,要对sybase的iq进行一些性能的测试.邀请到sybase公司的人来我们这一起进行测试,我要准备的,就是一个机器,然后一些测试数据.
ok,还是先说说我们的测试环境吧.
硬件环境 :HP DL 380 G4 3.0GHz CPU1颗,内存3GB(但是上面还挂了3个oracle的instance,大概占用了偶1.8GB的内存,可以给IQ试用的内存不足1.2GB),硬盘为本机上的SCSI硬盘两块.
软件环境:windows 2000 server ,Sybase Iq 12.6 Read the rest of this entry »
上午上班,现场兄弟说hacmp的服务器上要修改ip地址,换网段.hacmp是肯定要改了,等我接手的时候,现场已经很混乱的说.
我算了下,基本上每步都碰到问题.
1:远程登陆后发现,同步ha的时候有warnning,无error,启动ha后,系统无反应.
2:重新配置hosts和rhosts文件
3:将ha配置全部删除,重新配置,报JYGRDB1上无datavg
4:将2号几上的datavg同步到1号机上,同步ha,报major number冲突
5:修改1号机的major number后,再次同步,报warnning后,同步失败
6:重启小机,强制同步,同步成功;
7:启动ha,启动成功,但数据库无法启动,报master设备无访问权限
8:停止ha,修改master属主,再次启动ha,报user_ldata02无法启动
9:停止ha,修改user_ldata02权限,再次启动,数据库启动正常
10:修改2号机的设备的属主
11:修改1号机和2号机的interfaces文件,修改相应的ip信息
差不多每个步骤都碰到问题,看来这hacmp5.2很久没有动,和现在搞的hacmp5.3还是有点区别的.不过今天又锻炼了下.
这两天开发的人向我抱怨,在Sybase中写的procedure无法捕获异常,所以很多应用都出现了问题.昨天搞定了Oracle 8i中的xml的问题后,今天开始搞这玩意.
这种问题,首先当然是去google了下,发现没有啥收获,然后只能去sybase官方网站查手册,发现手册中也没有太多记载(不知道是不是不能实现的就不记载).
实在没有办法,只能call无言这小子,看看他有啥办法.没想到,他的结果是,在sybase12.5.2的procedure中无法进行异常捕获,我发了段测试代码给他,他也调试不出来这种东西.
既然如此,就call 800了(最后才call 800,是因为客户的服务已经过期了,不知道是不是我的声音比较有磁性,居然通过了接线员,到达工程师那里了),工程师要求我将测试代码以及环境发给他,发过去以后,工程师回了个邮件,内容大致如下:
@@error 的用法不正确,在事务中要使用局部变量保存@@error,再作处理!
稍候就这个问题写个程序给您!
我等,等呀等,等了2小时,没程序过来,我再次call 800,并找到刚才的工程师,开口就告诉我,不好意思,比想像的复杂,Sybase没有办法进行异常处理,而且procedure中的任何错误,会导致整个procedure直接退出,我靠,ft,简直是惊喜.
再看看我们的程序,这样的话,应用的更改还不知道多大.直接问Sybase的800,这个东西比较土的吗,没oracle好,他也直接说,是的,是不好,这个没处理好.唉.
俺又开始怀念Oracle了.没办法,只能修改所有的应用,先try,然后do,可是,正确的方法只有一种,错误的方法千千万,我该如何去try列,呵呵.这个问题,还是留给开发吧.我只能对开发说,sorry,sybase这个玩意不支持在procedure中进行异常捕获,你还是把程序的健壮性搞的更强吧.
上文提到,在sybase中配合我们的开发一起来弄sybase的insert的速度问题,我们将问题定位在客户端.
经过我们开发的辛苦工作,发现在使用ADO的时候,是有区别的.
原来我们的ADO的做法如下:
提交部分关键代码如下:
if FADOCofCommRecordSave.Connected=true then
begin
sZDLJDZ:=’91010001’;
try
FADOQ_ExecSql_SX.Close;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘LYDZ’).Value:=’172.19.74.74:1024’;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘MBDZ’).Value:=’172.19.74.74:1024’;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘TXFS’).Value:=40;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘TXSJ’).Value:=Now;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘XTDM’).Value:=’‘;
sSJNR:=trim(‘6891010000000B68823900040406231805010205000000000000EE00EEE
EEEEEEEEE00EEEEEEEEEEEE00EEEEEEEEEEEE00EEEEEEEEEEEE00E
EEEEEEEEEEE00EEEEEEEEEEF616’);
////sSJNR:=Edit_SJNR.Text;
if length(sSJNR)>2048 then
sSJNR:=copy(sSJNR,1,2048);
FADOQ_ExecSql_SX.Parameters.ParamByName(‘TXNR’).Value:=sSJNR;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘CLJG’).Value:=0; //表示处理成功
FADOQ_ExecSql_SX.Parameters.ParamByName(‘ZDLJDZ’).Value:=sZDLJDZ;
FADOQ_ExecSql_SX.Parameters.ParamByName(‘JYQCD’).Value:=length(sSJNR) div 2; //存的是字节数
FADOQ_ExecSql_SX.Parameters.ParamByName(‘JYHCD’).Value:=Length(sSJNR) div 2;
FADOQ_ExecSql_SX.ExecSQL;
FADOQ_ExecSql_SX.Close;
Result:=True;
except
on E:Exception do
begin
Memo1.Lines.Add(‘保有存原始通讯记录出错,错误信息:’+E.ClassName+’_’+E.Message);
FADOCofCommRecordSave.Connected:=False;
end;
end;
end;
现在的做法如下:
提交部分关键代码:
if FADOCofCommRecordSave.Connected=true then
begin
sTemp:=’Insert into RUN_SXTXJL(LYDZ,MBDZ,TXFS,TXNR,CLJG,XTDM,ZDLJDZ,JYQCD,JYHCD) values(‘’172.19.74.74:1024’‘,’‘172.19.74.74:1024’‘,40, ‘+
‘’‘6891010000000B68823900040406231805010205000000000000EE00EEE
EEEEEEEEE00EEEEEEEEEEEE00EEEEEEEEEEEE00EEEEEEEEEE
EE00EEEEEEEEEEEE00EEEEEEEEEEF616’‘’+
‘,10,’‘1’‘,’‘99998888’‘,10,10)’;
sSQL.Add(sTemp);
FInsertCount:=FInsertCount+1;
if FInsertCount>=FCommitCount then
begin
FADOQ_SQLBatch_SX.SQL.AddStrings(sSQL);
FADOQ_SQLBatch_SX.ExecSQL;
FADOQ_SQLBatch_SX.SQL.Clear;
sSQL.Clear;
FInsertCount:=0;
end;
end;
从两段代码,可以看出,原来的做法,是每提交一条记录到ADO中,都执行下ADO,最后在作一次提交;
而在后面的方法中,是批量提交sql给ADO最后执行一次.
通过这种做法,速度得到了提高,不知道是不是ADO对于Sybase的特殊用法.
感谢无言对我们的大力支持
感谢开发人员pengzhonghua的艰辛开发以及测试
最近刚从天津回来,就被老板的老板找去训话了,主要意思就是一个:广东的Sybase系统性能低下,无法满足实用化验收的要求.既然是大老板亲自发话了,就有点麻烦了.
还没吃午饭列,老板就再次提到这个问题,并且说必须配合开发人员找到问题所在,本周必须出报告,指明问题所在.事实上,目前系统的慢,主要反映在我们的系统向数据库中插入数据的时候,无法满足需求,现在的业务,在0,30分这两个时间点上插入的数据很多,大概达到30000条记录左右,而我们的入库操作需要超过15分钟.平均每秒才能入库大约60条记录左右,这对于一个中型的系统,速度上是绝对不够的.而且,整个系统的cpu负载基本上都是在70%左右,基本上没有空闲.
为了解决这个问题,首先我们作了测试,使用Rapid SQL这个工具,向服务器中插入数据,采用批量提交,每100条记录提交一次,根据测试结果,发现每提交1000条记录,需要的时间,不会超过1000ms,也就是每秒可以插入数据1000条左右.
既然如此,我们开始怀疑是client的问题.由于我们的提交的程序是用Delphi 6.0来作的,使用的是Delphi自带的ADO控件来实现的,这个时候,我开始怀疑是ADO的控件出现了问题.
由于我的Sybase的水平不高,只能找我的私家顾问了,在msn上抓到无言(其实每次Sybase的重大问题,俺都是找他的)和他交流了下,他认为可能是Sybase自带的OLEDB Driver出现了问题,或者说是有bug.查了下Sybase官方网站的文档,确实是有类似的bug.下载安装了EBF13644以后,似乎没有太大的改观.为了测试确认问题是在这里,继续找无言,要了个java写的JDBC的代码,并请我们的开发写了个应用,使用batch的方法,发现每秒的插入能提高到700条左右.这样一来就可以肯定问题是出在Delphi的控件上了.
现在的问题是如何去改变这个问题,不过我想既然问题找到了,那么解决问题,这是一个时间问题了.我也将继续关注这个问题.
这两天,现场的应用作了改动,刚好在改动前后,都出现过原始数据无法插入到系统中的情况,不过升级前应用没有具体错误出来,只是说保存失败,升级后,应用将错误抛出,错误就是得到的自动编号重复,导致违反主键,插入失败,我们得到自动编号的方法,是调用了一个存储过程,其语句为
select nextvalue=nestvalue+1
update set nextvalue=nextvlue+1
commit
看起来,语句很简单,也不会有逻辑的错误,这个时候,我们开始怀疑是否程序中调用这个存储过程出错?程序继续更改,将每次获得自动编号前和后的值打印出来,这个时候发现,在出错的时候,中间会漏一个值,然后得到两个重复的值,例如,应该得到0,1,2,3,4,5这样的序列,他实际得到的是0,1,2,4,4,5这样的序列,当然会报错.
这个时候应用中怀疑可能是线程的同步出现了问题,如是,应用中将所有的线程同步到主线程中,这个时候,发现出现问题的概率确实少了很多,但是问题依然没有得到解决.
网络上google,没有找到相应的信息,这个时候已经晚上23点了,居然在qq上碰到了无言,和他聊了下,他居然以前也碰到过,并且已经指导过他们的开发商作过类似的事情,具体原因,居然是因为Sybase的自动提交引起的,也就是我们的存储过程中,本来select和update应该是在同一个事务中,但是我们没有明确的作,这样在高并发的环境中,就会出现问题.
在这样的情况下,我将存储过程修改为如下的情况
beging tran
update set nextvalue=nextvalue
select nextvalue=nestvalue+1
update set nextvalue=nextvlue+1
commit
这样的写法中,首先将整个获得流水号的过程作为一个事务处理,其次在begin tran后面的第一句话,其实是对要更新的对象作了一个锁定,锁定了这个数据,这样,再高的并发度也不会获得的流水号重复.
观察了一个晚上,原来每小时有近100条记录的重复,现在都没有了.这或许也是Sybase在高并发系统中获得流水号的一个方法.
这次我和bachelor两个人都到广东江门,因为现场的兄弟反映我们的系统在整点和半点的时候,client端容易出现问题,就是点击界面上的按钮,应用就挂死在那里.
服务器是IBM P630,2cpu,2gb内存,HA双机,带磁盘阵列,磁盘是光纤磁盘,主机和磁盘阵列间光纤直连;
topas察看系统性能,cpu使用40%多点,内存正常,io最繁忙的时候30%busy多点,网络流量正常,按照常理,系统不应该慢才对.
但是在半点和整点就是会挂死,现象我也看到很多次了,这个时间点,后天有好几个job会启动执行,而前台也是数据插入最多的时候.发现了系统挂死的现象后,从这个现象开始,在client执行相同的应用,我在后台监测数据库的状况,我发现,如果一个界面挂死20s的话,在sybase java central中,只是在最后的2s数据库的进程才会running,但是datasrv进程的cpu使用,一般都是在40%多,最高的时候,50.4%,从来没有超过这个值,反复多次均是如此.
sybase的mda表也装上了,察看了系统的后台,似乎没有什么不妥的地方,sysmon也察看过,没有什么太有用的信息,系统看起来似乎正常,就是会挂死.
这个时候,突然想到,为什么我的系统的cpu从来不会超过50.4%?对于一个系统来说,在最繁忙的时候,cpu可能会很高,比如达到80%以上,但是我这个系统从来不会超过50.4%,联想到我的系统是双cpu,大胆猜测下,如果数据库只使用了一个cpu,那岂不是刚好,数据库系统永远无法使用多于50%的cpu资源吗?
为这个想法高兴下,赶紧到sybase的参数配置中看看,发现有参数max online engines这个参数,察看sybase官方文档,对这个参数的解释,发现对于我的双cpu的机器,这个参数可以增大到2,但是系统默认是1,而且这个参数也从来没有更改过,难道是这里有问题?
继续仔细的看文档,文档中建议,在系统繁忙的时候,这个参数可以设置到和cpu数目一样,但是不要超过可用cpu数目,那么,增大这个参数到2,静态参数,需要重新启动sybase ASE,启动后,再观察,topas,发现在进程中,启动了两个datasrv进程,也就是说,现在有两个datasrv进程了,观察系统的运行情况先.
果然,在系统繁忙的时候,现在两个datasrv的cpu使用率加起来,可以达到95%,这才象一个系统在繁忙的时候应该表现出来的现象吗,系统的cpu怎么能使用从来不能突破50%列.
现在在最繁忙的时候,系统两个datasrv的cpu使用率加起来,超过95%,而应用卡死的现象,由原来的很频繁,到现在的每个小时中,不会超过1分钟,这1分钟,系统最繁忙.
问题由此得到了极大的缓解,看来sybase和oracle还是有区别的,对于cpu,如果不指定使用多个cpu,那么就是再繁忙,他也不使用另外的cpu,sybase这种做法,说实话,有点土呀. 当然,也和咋学艺不精有关系,看来还是得多看书才对.
这两天一个比较大的数据库要作测试,整个bcp out过来的数据有30多个G,在进行bcp in的时候,没有使用快速bcp,结果列,导致为了能将数据导入进去,不断的增加syslogs的设备和segment,加到最后,一个120GB的数据库,居然syslogs一共有46GB,在数据导入完成后,就得把这些设备都删除了,否则服务器抗不住的了,这个真是比较郁闷的事情.
找遍Sybase的官方教材,不知道该如何去删除syslogs,只能问无言独上西楼了.
以下就开始折腾这个数据库了.
首先,把数据库服务停下来,不想作备份,不过这个库是windows下的,我们的主要目标是操作那个master表,所以,先把master设备备份下.
然后更新系统表,让我可以直接来操作系统表中的数据,更新系统表用如下的语句
use master
go
sp_configure “allow update”,1
go
checkpoint
go
好了,现在可以更新系统表了,直接去删除sysusages和sysdevices中的记录.
用如下的语句:
begin tran—这个非常重要,在进行系统表更新的时候,最好是维护在一个手工的事务中,免得被系统自动提交了
delete from sysusages where xxxxxx
go
commit
go
delete from sysdevices where xxxxxx
go
commit
go
checkpoint
go
重新启动数据库,很不幸,这个方法不幸,我删除了6个logs devices,但是启动的时候,用户数据库报错,在errorlog中可以看到,数据库起来的时候,作recovery失败.
这个时候就看出备份的好处了,把原来的备份的master设备拷贝回去,覆盖,重新启动sybase,成功,但是这个时候等于是要删除的东西还是没有删除,等于啥都没作.呵呵
下午继续弄,半年多没有动sybase了,命令也有些生疏.
想想应该可以从sybase java central中来作这个事情,嗯,不会的时候,还是借助下工具:)
在工具中,直接删除logsegments中的设备,报错,说要数据库到单用户模式.
在命令行下
sp_dboption GRDATA,”single user”,true
go
checkpoint
go
把数据库设置到单用户模式
重新在sybase java central中删除logsegments中的devices,成功.
sp_helpdb GRDATA
go
这个时候,系统显示数据库的syslogs只有10G了,但是其他的一些logs还是都在的,只是下面写的是没有任何segment在这个上面.
直接在sybase java central中删除devices.报错,说当前段正在被数据库使用,我ft,不是吧.
想起无言独上西楼的方法,嗯,继续直接在sysusages中删除,成功,爽
然后想想,还是不要直接从sysdevices中删除会比较安全的,那就用sp_dropsegment来作,一个一个的删除syslogs下的那些不要的segments,成功,爽
赶快个数据库作一个checkpoint.
好,现在把那些设备改个名字(为什么不删除,怕出错后没得恢复呵呵),然后重新启动数据库,成功
现在要作的就只有从操作系统中删除这些物理文件了.
到此,整个过程完成.记录之,希望对自己和别人有点帮助.
今天开发的兄弟告诉我,一个应用,在公司作测试的时候,每秒能向数据库中插入数据200条,在生产系统的小型机上,也只有这个速度,为了看看到底系统在干吗,我就在公司的服务器上安装了MDA表,希望能看看Sybase的性能到底慢在那里.
在Sybase上安装MDA表的步骤如下:
首先配置cis参数为1
sp_configure ‘enable cis’, 1
go
其次,在servers中增加一个loopback服务,其实也就是指向自己的一个服务了
use master
go
sp_addserver loopback, null, @@servername
go
可以使用下面的语句来测试这个服务是否配置正确
set cis_rpc_handling on
go
这个如果返回是0,或者是执行正确,就表示刚才的配置正确了.
当然,也可以通过下面的方法来测试
exec loopback…sp_who
go
下面就是安装了,这一步非常重要:
isql -U sa -P yourpassword -S YOURSERVER
-i $SYBASE/$SYBASE_ASE/scripts/installmontables
看看屏幕的输出,如果有错误,就要想办法去排除了.
现在,得授予sa一个mon_role的权限了
use master
go
grant role mon_role to sa
go
用下面的语句来测试授权是否成功
select * from master..monState
go
这里返回正常的话,就可以继续下面的操作了
将下面的动态参数进行修改
sp_configure “enable monitoring”, 1
go
sp_configure “sql text pipe active”, 1
go
sp_configure “sql text pipe max messages”, 100
go
sp_configure “plan text pipe active”, 1
go
sp_configure “plan text pipe max messages”, 100
go
sp_configure “statement pipe active”, 1
go
sp_configure “statement pipe max messages”, 100
go
sp_configure “errorlog pipe active”, 1
go
sp_configure “errorlog pipe max messages”, 100
go
sp_configure “deadlock pipe active”, 1
go
sp_configure “deadlock pipe max messages”, 100
go
sp_configure “wait event timing”, 1
go
sp_configure “process wait events”, 1
go
sp_configure “object lockwait timing”, 1
go
sp_configure “SQL batch capture”, 1
go
sp_configure “statement statistics active”, 1
go
sp_configure “per object statistics active”, 1
go
然后,需要修改一个静态参数
sp_configure “max SQL text monitored”, 2048
go
现在,你要作的就是重新启动Sybase数据库服务器,然后你就可以使用MDA表来监测Sybase数据库的系统性能了.
具体如何使用MDA表,可以参考这里.