用一个案例讲解Sybase的性能优化.docxVIP

用一个案例讲解Sybase的性能优化提 要　为了提高数据库系统的性能，本文针对资料入库，资料检索速度的提高进行了研究和探讨，并提出了相应的的技术措施。　关键词：性能提高 入库 检索　1．问题的提出　使用SYBASE商用数据库管理系统，但在应用中也发现一些性能问题，例如用户反映常规资料入库较慢、探空资料检索不够快等。针对这些情况，我们进行了分析、试验和探讨，在目前运行平台的环境下找到一些改进方法，取得了较好的效果。　2．库生成慢的原因分析和技术措施　2．1库生成慢的原因分析　在常规资料入库的整个过程中主要包括对报文的解码和数据插表两个大的步骤，因此应先分清究竟是解码过程慢还是数据插表过程慢。为此在主站的调试环境 IBM RS6000-59H的平台上做了测试，发现对一天常规资料只解码不入库只需4分钟，但整个库生成却需要4小时11分；显然绝大多数时间是花在数据入库上。而进入数据库的报类多种多样，插入的时间也有长有短。因此有必要在这所有的资料中，找出是哪几种资料入库的时间长。用一个时间统计程序分别对各类报的插入时间做了统计，结果发现地面要素报的插入时间最长，在总共4小时11分的插入时间中占1小时56分钟。　于是我们在测试库（IBMRS6000-H50 B系平台）中用SYBASE提供的监测程序过程sp_sysmon监测插入一天的地面要素（28239条记录，即28239个事务）的运行情况。在sp_sysmon的输出结果（见表1）中，　表1 插一天地面要素的运行情况　每秒收到客户端的字节数5681．9　每个事务所占用网包数3.0　每秒收到客户端的网包数14.7　插入时间（秒）5837　发现描述每个事务所占用网包数的参数（Total TDS Packets Received per xact）等于3，也就是说一条插入命令要分三次才能送到服务器端。这引起我们的深思，业务上已将Server的缺省网络包大小（default network packet size）、最大网络包大小（max network packet size）由512字节改为1024字节，为何一条插入命令要分三个网包，我们立即查证一条地面要素插入命令的长度，大部分在1100字节左右，最长的是 1174字节，超过了1024的长度，但仍然让人不解的是：一条长为1136字节插入语句用1024字节的网包发送，应该使用两个网包就够了，为什么会用到3个呢？除非512字节的网包才要用到这个数。这是什么原因呢？向SYBASE公司咨询，得到的答案是不仅要在Server端修改参数，还必须在客户端程序中用DBSETLPACKET()函数显式指定和default network packet size一样大小的网包值，改动才起作用。而以前并未在程序中作指定，因此服务器与客户端之间的通信仍采用SYBASE的缺省网包长度512字节。　在SYBASE的处理中是需接收一条完整的命令后才能进行处理。如果一条命令跨网包传送，Server在收到第一个网包时并不能立即对它进行处理，还必须等待下一个网包将完整的命令送过来，这就涉及到TCP协议的延迟确认问题。它的主要内容是：面向连接的传输协议要求对发送的每一个包都要进行确认，通常对所收到数据进行确认的包都很小，为了避免在网络上产生过多的短包，接收端在收到数据之后并不立即给发送方发送确认信息，而是要延迟一段时间，看本方是否有数据需要发送至对方，如果有则将数据连同对上次收到数据的确认消息一起发送给对方，这中间就有延迟时间。关于延迟时间的长短，不同的机器有不同的设置，TCP协议规定不超过500毫秒，有的机器取200毫秒，这是个相当长的时间。　我们从sp_sysmon的输出结果的另一参数，即 Server端每秒收到客户端的字节数的参数Total Bytes Received per sec的值仅为5681.9，这说明平均一秒中只有5个事务送到服务器端等待处理，即使忽略掉处理时间，一秒中也最多只能处理5个事务。实际的情况是插 28239个事务用了5837秒，平均每秒处理4.87个事务。当将网包长度改为1536后，同样的资料全部入库只需285秒的时间。可见网包长度不当是影响库生成的一个原因。　2．2 网包长度的试验和对比分析　SYBASE是基于客户机服务器体系结构的数据库系统，客户机和服务器之间的是网络通信，因此网包长度是SYBASE性能调优的一个重要参数，是一个很重要也很值得探讨的问题。不同的应用对网包大小有不同的需求，9210数据库接收的资料多种多样，有的数据的一条插入命令长达10多K字节（如公报），有的命令却只有100多个字节（如探空要素）。我们该如何综合考虑选取一个合适的网包长度呢？　为此我们针对一天的公报资料、探空资料、地面要素，采用不同的网包长度，利用单个进程和三个并发进