Sybase数据性能调优.docx

Sybase数据性能调优.docx

《Sybase数据性能调优.docx》由会员分享，可在线阅读，更多相关《Sybase数据性能调优.docx（20页珍藏版）》请在冰豆网上搜索。

Sybase数据性能调优

Sybase数据库性能调优

广铁集团电算信息中心王奇成，张南飞

引言

铁路客票系统经过多次的技术改进，版本已经升级到4.0，现已能够比较全面充分地满足和适应客票发售和预订的需求，是铁路运输管理信息系统中的重点。

客票系统结构上分成铁道部、地区中心和车站三级，技术上采用Sybase数据库，Unix操作系统，前台应用采用PB和BO等开发，是典型的Client-Server应用，但又采用了自行开发的中间件作连接交易处理和数据库通信，具有较强的复杂性。

对于遍及全路大小车站，统管全路客票发售的这样一个庞大生产系统，影响举足轻重。

尤其是节假日铁路售票高峰期里，大到地区中心，小到车站，只要客票主机一有故障，造成停机，便会直接影响售票，极大地减少铁路运输收入。

在多年的客票系统建设和维护中，深深体会到客票系统对Sybase数据库资源的方方面面的要求，Sybase数据库性能对客票系统至关重要的影响。

现在，全路的客票系统出现一种数据集中的趋势，大站带小站，多站合并，票额集中到地区中心，这样，数据库的规模便越来越大，可用性要求越来越强。

如何深入调整Sybase数据库的性能，保证数据库的高可用性，来满足日益增长的客票网络的需求，尤其在过年过节等客运高峰期之需要，是每一个地区中心和每一个车站的数据库管理员的重要课题。

本文结合客票系统，对如何调整优化Sybase数据库的性能做个较深入的论述。

1概述

1．1性能指标

数据库性能一般用两个方面的指标来衡量：

响应时间和吞吐量。

响应越快，吞吐量越大，数据库性能越好。

响应时间和吞吐量有些情况下不能一起得到改善。

1．2调优级别

对Sybase数据库性能调优，可以从四个方面进行：

一）操作系统级：

对网络性能、操作系统参数、硬件性能等作改进。

二）SQLServer级：

调整存取方法，改善内存管理和锁管理等。

三）数据库设计级：

采用降范式设计，合理设计索引，分布存放数据等。

四）应用程序级：

采用高效SQL语句，合理安排事务，应用游标，处理锁。

本文对第一方面的内容不做讨论，第二方面提到的概念只适用于Sybase数据库，但第三、第四方面讨论的问题同样适用于Sybase外的其他数据库。

以上各个方面的措施是相互牵连的，具体到解决一个性能问题，有时候要综合应用。

1．3调优工具

在分析Sybase数据库的性能时，要用到一些数据库系统本身提供的性能调优工具，包括几个系统存储过程：

名称

功能简要介绍

sp_sysmon

企业级系统性能报告工具

sp_lock

查看锁的情况

sp_who

查看线程的活动情况

sp_procqmode

存储过程的查询处理模式

sp_configure

配置SQLServer系统级参数

sp_estspace

估计创建一个表需要的空间和时间

sp_spaceused

估计表的总行数及表和索引占用的空间

sp_monitor

监视CPU、I/O的统计活动情况

在利用isql等一些工具时，还可以设置查询会话中的几个选项，来显示SQL语句执行时的各种统计分析结果：

指令

On的含义

setnoexecon/off

分析SQL语句后，还要执行

setstatisticsioon/off

统计SQL执行所需I/O

setstatisticstimeon/off

统计SQL语句执行耗时

setshowplanon/off

显示查询计划

1．4sp_sysmon的使用

企业级性能报告工具、系统存储过程sp_sysmon的使用方法：

在isql下，首先输入sp_sysmon'begin_sample'启动一个报告采样

过一段时间后，再输入sp_sysmon'end_sample'结束上次报告采样

或者紧跟一参数sp_sysmon'end_sample',"dcache"结束上次报告采样，但只显示数据缓冲（DataCacheManagement）这一部分的情况。

能替换dcache的可选参数如下表所示：

参数

参数全称，内容范围解释

Dcache

DataCacheManagement，数据缓冲

Kernel

KernelUtilization，有关引擎、网络和I/O等情况

Wpm

WorkerProcessManagement

Parallel

ParallelQueryManagement

Taskmgmt

TaskManagement

Appmgmt

ApplicationManagement

Esp

ESPManagement

Housekeeper

HousekeeperTaskActivity

Monaccess

MonitorAccesstoExecutingSQL

Xactsum

TransactionProfile

Xactmgmt

TransactionManagement

Indexmgmt

IndexManagement，索引管理

Mdcache

MetadataCacheManagement

Locks

LockManagement，锁管理

Pcache

ProcedureCacheManagement

Memory

MemoryManagement

Recovery

RecoveryManagement

Diskio

DiskI/OManagement，磁盘I/O管理

Netio

NetworkI/OManagement

1．5

用sp_sysmon可以得到数据库系统的性能基准报告，但要在比较稳定的状态下产生，方可作为参考和对照的依据。

1．6理解存储方法

只有清楚数据库存储数据的底层细节，如数据页、索引页的物理结构，每一行的大小计算，不同类型列占用的宽度等等问题，才能对各种调优措施有个深入领会。

关于这个问题，比较复杂和细致，请自行参阅有关书籍。

一般地，对于更改数据的操作，要尽量促进数据库进行直接更新（DirectUpdates），所以要遵守以下几条原则：

1）除非必要，避免使用允许null值的列和可变长度的列。

2）如果varchar和varbinary列填充得比较满，毫不犹豫转成char和binary列。

对于建表时指定的页填充率（pagefillfactor）参数，要权衡确定数值大小。

一般：

小值，适合于有许多随机插入的表，该表的数据经常被删除，又经常被增加；大值，适合于大多数的数据被增加到表末尾，如客票系统的售票存根和退票存根表。

2SQLServer级的调优

2．1管理共享内存

数据库性能优化的首要方面是最优管理内存。

数据库占用的共享内存分成数据缓冲（datacache）、存储过程缓冲（Procedurecache）等几块。

在isql下使用sp_configure'cache'可以看到存储过程缓冲所占百分比（procedurecachepercent），整个数据缓冲大小（totaldatacachesize）等参数。

2．1．1存储过程缓冲（Procedurecache）

存储过程缓冲保持以下对象的查询计划：

Procedures：

存储过程

Triggers：

触发器

Views：

视图

Rules：

规则

Defaults：

缺省

Cursors：

游标

存储过程不可重入，意即每个并发用户调用都会在内存中产生一个拷贝。

Procedure,triggers,andviews当它们被装载到procedurecache中时，被查询优化器优化，建立查询计划。

如果存储过程在缓冲中，被调用时就不需要重新编译。

如果procedurecache太小，存储过程就会经常被其他调入内存的存储过程冲洗掉，当再次被调用时，存储过程又被调入内存，再重新编译，用户请求因此不得不等待。

最严重的情况，如果procedurecache不够，存储过程甚至都不能运行。

所以在内存足够的情况下，procedurecachepercent参数尽可能大一些。

2．1．2数据缓冲（DataCache）

数据缓冲用来缓存数据页和索引页，是除去存储过程缓冲，系统其他占用的缓冲外的剩余内存空间。

通过给服务器增加物理内存扩大数据缓冲，是最有效的方法。

当然，如果不能加内存，就只能通过减少存储过程缓冲的比例等方法来扩大数据缓冲了。

通过sp_configure"extentI/Obuffers",20（可调）命令，在DataCache中保留一些页专用于创建索引时使用，可以显著提高创建索引的性能。

但要注意每开辟一个缓冲占用16K字节的系统内存。

2．1．3命名缓冲

通过如下的命令：

1>sp_helpcache

2>go

查看某客票数据库中命名缓冲，得到的结果如下：

CacheNameConfigSizeRunSizeOverhead

---------------------------------------------------------

DS30_Tran_Log20.00Mb20.00Mb2.05Mb

Systemtable20.00Mb20.00Mb2.05Mb

defaultdatacache0.00Mb4462.86Mb464.97Mb

left_base_center16.00Mb16.00Mb1.57Mb

price_cache8.00Mb8.00Mb0.85Mb

可以看出有4个命名缓冲，分别绑定客票系统的应用日志表、一些重要且常用的系统表、余票表、票价系列表，另外1个是缺省数据缓冲。

这种配置还不是最合理，应该进一步把Systemtable这个命名缓冲细分成很多个，每一个单独存放一张系统表。

2．1．4缓冲策略

缓冲策略是指把数据提前读入内存的机制，分预取策略（PrefetchStrategy，即大I/O策略）和取后马上丢弃策略（Fetch-and-Discard）、提示策略（Hints）等几种。

可以在三个级别上设置表数据的预取策略（PrefetchStrategy，即大I/O策略）于：

对象级，会话级，查询级。

如果三个级别上都有设置，它们发生作用的优先顺序是：

对象级>会话级>查询级。

对于如何在查询级利用指定的缓冲池，可以查看下面例子（使用4K缓冲池）：

selectau_fname,au_lname

fromauthers（prefetch4）

whereau_idin（A372020631,...,A1887081515）

go

DSS应用往往得益于大的I/O，应该放开largeI/Ostrategy预取策略。

如果一个应用倾向于OLTP特征，用户能在会话级关掉Prefetch来提高性能。

对于OLTP应用，关闭largeI/Ostrategy预取策略。

对于所取到的页不会有重用的情况，放开fetch-and-discard策略。

客票系统对存根数据进行统计的应用，如财收日结账，营销分析数据整理模块和综合查询等，都可以利用这一结论。

查看几个操作频繁且较大的表上的缓冲策略，用如下命令：

sp_cachestrategycenter,seat_area

sp_cachestrategycenter,sale_record0505

2．2管理锁

2．2．1页锁升级阀限

优化锁的重要考虑是设置页级锁升级升级成表级锁的阀限。

要尽量避免页锁很快升级成表级锁。

在某客票数据库中，用sp_configure‘lock’可以看到如下结果：

deadlockcheckingperiod500010001000

numberoflocks500046875200000200000

pagelockpromotionHWM20001000010000

pagelockpromotionLWM2000200200

pagelockpromotionPCT10009090

可以看到页锁升级的阀限有三个：

HWM（最高点）为10000，LWM（最低点）为200，PCT为90。

Sybase数据库内部根据PCT值按公式PCT*TAB_SZ/100得出计算阀限，如果计算阀限

如果LWM<计算阀限

锁升级阀限设置分对象级和服务器级两种。

针对对象级设置（数据库上的表或表上的索引），配置命令是：

sp_setpglockpromote{"database"|"table"},objname,new_lwm,new_hwm,new_pct

针对服务器级设置，配置命令是：

sp_setpglockpromoteserver,NULL,new_lwm,new_hwm,new_pct。

如果要删除掉对象级上的页锁升级阀限，用：

sp_dropglockpromote{"database"|"table"},objname

2．2．2减少锁争夺的方法：

1）降范式设计数据库，创建冗余表。

2）把堆表（没有聚族索引的表）分区。

3）对于小表，使用fillfactor和max_rows_per_page来减少行密度，从而使各行数据分布到许多页（此方法适用于SQLServer11版，对于11.9.2版以后的Sybase数据，有了行级锁，此方法必要性不大）。

2．3管理临时库（tempdb）

管理临时库一个重要原则是要避免临时表跨多个设备，可以把tempdb从master设备中分离出来，放到一个单独的设备上去。

这样可以减少存取系统表时对I/O资源的争夺。

用sp_dropsegment存储过程从master设备中移除tempdb的default段和system段。

为了进一步提高tempdb的I/O速度，可以考虑把tempdb整个放在RAM驱动器或固态存储设备上，存取速度是一般磁盘的1000倍。

一般情况下，tempdb会非常频繁地争夺和占用缺省数据缓冲，因为查询会话中有许多临时表要创建、计算和删除。

所以推荐把tempdb绑定到它自己的命名缓冲，这样可以防止临时对象在内存中的活动冲洗掉缺省数据缓冲中的其他对象，利于在多个缓冲间展开I/O。

在使用临时表的时候，还有一个原则：

尽量缩小表规模和行的宽度，每一行只包括必要的列。

例如在用select*into生成临时表时，如果只需要几个列的数值，就不要用这样的语句，而直接选取需要的列。

2．4使用多引擎（MultipleNetworkEngines）

如果操作系统使用了多个CPU，那么用sp_configure配置数据库的参数：

在线引擎数（maxonlineengines），可以扩展系统的网络I/O容量，分布网络I/O到各个引擎，从而提高性能，允许更多的用户连接。

在用户登录数据库时，总是先登录到引擎0，由引擎0在可用引擎队列中选择一个挂最少连接的引擎来传递socket描述符，从而重定向连接到那个引擎，由该引擎去处理跟此用户连接相关的所有网络活动。

对于多引擎SMP结构，SQLServer引入了自旋锁（spinlock）的一种数据结构，在多个引擎间共享。

对于不同类型的任务，在哈希表上分配不同的自旋锁，有页锁自旋锁、表锁自旋锁和地址自旋锁。

自旋锁的配置：

sp_configure"pagelockspinlockratio",newval

sp_configure"tablelockspinlockratio",newval

sp_configure"addresslockspinlockratio",newval

增大数值，可以减少碰撞，提高并发操作度。

但是每一个自旋锁结构要占用256字节的内存。

如果数据库发生1279错，可能原因：

1）不允许足够的锁，解决办法是用sp_configure调大numberoflocks数值

2）在enginefreelock缓冲中没有足够的锁，解决办法是用sp_configure调大maxenginefreelocks数值。

如果数据库系统使用了4个引擎，那么每个引擎的自由锁缓冲中包含：

eachengine-specificfreelockcache包含5000*.20/4=250个锁。

在平时，经常用sp_monitor和sp_sysmon监视CPU使用率，如果所有CPU的利用率高于85%，增加CPU，然后增大数据库的引擎数，可以改善性能。

2．5设备使用的优化

把最常插入的表分区，放在多个设备上，这样可以创建多个页链，从而改善多个并发插入时的性能，因为每一个插入都要找到页链，页链有多个，就允许多个插入同时进行。

这一点，尤其适用于客票系统的存根表和订票存根表（CG30_RRT），所带来的性能改善会非常明显。

物理I/O的代价远大于逻辑I/O，所以要尽量减少磁盘进行物理I/O的次数，尽量多进行内存中的逻辑I/O。

使用statisticsio工具和sp_sysmon，来观察磁盘I/O。

可以配置使用大的I/O来减少物理I/O的次数，方法有三个：

1）用更多的磁盘；

2）表和索引分开到不同的磁盘；

3）增加一次I/O系统参数值的大小。

SQLServer总是为I/O请求建立一个磁盘检查的调度环，用sp_configure"I/Opollingprocesscount"来提高数值，加长环，可以降低引擎的检查次数，提高吞吐量。

但较小的值一般有助于减少响应时间。

对于可用的磁盘I/O控制块，要查看操作系统文档，用sp_configure"diski/ostructures"配置，这个数值要尽可能高。

分离日志和数据，到不同的设备；给tempdb自己的设备；分离表和索引到不同的设备。

这些方法都可以减少I/O。

2．6对事务处理的调优

2．6．1事务类型

事务处理无外乎三种：

1,OLTP;2,DSS;3,OLTP+DSS的混合负载

OLTP（联机事务处理）的特点：

◆数据插入、修改和删除频繁。

◆经常操作的是单个记录。

◆当不适当设计时，倾向于碰撞和冲突。

DSS（决策支持系统）的特点：

◆数据修改不太频繁。

◆如果有插入和删除，是大批量的。

◆平时一般是只读操作。

◆表连接很常见。

◆有比较特别的查询。

OLTP+DSS混合负载的特点权衡：

◆在性能方面要比较，是要吞吐量还是响应时间。

◆在锁方面要比较，是要并发性强呢还是要数据一致性强。

2．6．2事务管理原则

一般的事务管理原则有：

1）分解大的事务成多个小的事务。

如客票数据的备份操作中，要删除过期数据，如果设计小事务做循环，便不会影响应用，完全可以做到任何时候备份和删除，不一定非得等服务器闲的时候做。

2）避免在单个事务中更新或删除大量的数据行。

比如客票系统的席位库数据清理，即使在服务器闲的时候做这种操作，也会锁定整个表，影响售票。

3）尽量用可以接受的最低孤立级（isolationlevel），来提高并发度。

如在余票查询等功能的应用中，使用这种孤立级，便可以最大程度地降低对售票的影响。

4）提高事务吞吐量的措施包括：

避免延迟更新；尽可能使用存储过程等等。

2．6．3跟事务特征相关的数据库可调参数或特性

相对于OLTP应用，SQLServer有一些特性来满足要求。

1）命名缓冲（Namedcache）

对于命名缓冲，可以配置多个不同大小的内存池，来满足不同的应用需求。

对于多个引擎的情况，命名缓冲还有一项重要的功能是降低自旋锁的内部争夺。

2）日志I/O缓冲大小可配置

sp_logiosize["default"|"size"|"all"]

缺省值是4K，但如果4K内存池没有配置，SQLServer会使用2K大小的内存池

3）堆表可分区，分布插入操作到各个设备

适用于频繁插入的表和有并发BCP倒入数据的表，如客票系统的售票存根和退票存根表。

4）锁升级阀限可配置。

相对于DSS应用，SQLServer也有一些特性来满足要求

1）应用大的I/O缓冲池

用sp_poolconfig来配置。

2）绑定热表到命名缓冲

如sysindexes,syslogs,注意如果把syslogs放到单独的缓冲中，可以减少在缺省或其他命名缓冲上的自旋锁争夺。

对于客票系统的train_dir,stop_time,票价表,取票存储过程相关的表都可以放在单独的命名缓冲上。

3）取后丢弃缓冲策略（Fetch-and-discardcachestrategy）

不会冲洗掉缓冲中的常用对象，可以减少MRU链的争夺，较少对OLTP事务的干扰。

对于收入统计应用，统计过往存根表中的数据，可以应用这一策略。

2．7网络方面的调优

Sybase客户和服务器之建传递的是TDS包，缺省大小是512字节。

对于要传输大批量数据的应用，如BCP、文本/图像的取用、大结果集SQL语句，要用下面的配置命令配置大的TDS包大小。

sp_configure"defaultnetworkpacketsize",nnn

sp_configure"maximumnetworkpacketsize",nnn

对于isql和bcp，可以在应用级指定TDS包的大小：

isql-Usa-P–Annn，bcp-Usa-P–Annn。

注意在调大maximumnetworkpacketsize的参数后，要增大additionalnetworkmemory参数，来适应maximumnetworkpacketsize的要求。

3数据库设计级的调优

3．1降范式设计

数据库的基础理论中，倡导使用规范化数据库设计方法，简称范式设计。

用范式来设计数据库，可以减少数据冗余度，减少插入、更新和删除异常，也可以提高一般性能。

但是有时为了提高某些特定的性能，有意打破范式设计，为了达到最好的效果。

但这种情况下，一定要注意数据完整性维护的问题。

降范式设计这种方式一般可以提高检索速度，但略微降低数据修改性能。

对于应用开发来说，有些情况下，降范式设计还能简化应用程序编码。

3．2降范式设计的好处

降范式设计一般能带来如下好处：

✓减少表连接的需要。

✓减少外部键和索引。

✓减少表的数量。

✓聚合列可以预先计算。

3．3降范式设计的方法：

✓增加冗余列。

✓增加导出列，从一个或多个表的几个列中导出另外一个列。

✓收拢表，几个表合成一个表。

✓复制表，即制作表的副本。

✓劈开表，分垂直劈开和水平劈开两种。

如客票系统中存根表就进行了水平劈开，每天一张表，这样就避免了庞大的整张存根表上数据操作的锁资源、I/O资源的争夺，也利于备份和传输。

水平劈开可以考虑把表中不太活动的数据放置在一个表中，而把经常变动的数据放在另外一个表中。

垂直劈开是把多个列分成几组，每一组列成一个表。

3．4管理数据相关性

如何