本 文以“某大型商业银行的网上银行系统”这一很具有典型意义的企业级大型Sybase数据库应用系统为例，涉及了数据库应用系统调优的五大领域：压力测试、 应用端调优、服务器端调优、系统平台层的优化、应用架构的优化，详细介绍了作者在项目开发过程中曾经遇到的各种问题及其解决办法。本文通过对“企业级 Sybase数据库应用系统的性能调优的最佳实践”的探讨，从而为这类性质的工作提供了具有普遍指导意义的参考。

1.项目背景与特点

该应用系统是在总结前一代网银系统的经验教训的基础上，于2008年开始彻底重新设计、开发的。

技术上，它从J2EE技术架构转向.NET架构，大幅度提高了应用程序的开发效率、运行效率，改善了最终用户的实际体验 （UserExperience）；业务上，同时推出了“个人网银”、“企业网银”、“手机银行”等，使该行在非传统业务渠道上实现了跨越式发展，迅速赶 上并超越了同行；产品上，从SybaseASE12系列产品升级到15系列产品，以便充分利用其高性能、高可靠性特征。

2.系统逻辑架构

如图所示，该系统共分3个层次，有数个关键组件——

接入层（AccessLayer）：包括防火墙（Firewall）、网络负载均衡设备（LoadBalancer）等；

应用及管理层（Application&ManagementLayer）：包括静态网页服务器 （StaticPagesHTTPServers）、面向不同业务的多组应用服务器（GroupedApplicationServers）、证书管理服 务器（CA&LDAP）、Sybase数据库服务器、各种系统管理监控工具等；

后台接入：主要是接入各种后台系统的网关（BackendGateways），如主机交易网关等。

点击此处查看全部新闻图片

3.系统的业务量

在衡量网上银行的业务交易量时，通常用两类业务指标：一类是账户类交易，即涉及用户账户核心信息（特别是账户余额）的交易，如“交 易明细查询”、“转账”、“缴费”等；另一类是辅助交易，如“常用关联账户/收款方管理”、“证书/口令管理”、“理财产品信息”、“用户定制菜单管理” 等等。

在本项目中，我们用如下的系数关系描述系统的业务量：如果“账户类交易量”为１，则“辅助交易量”为0.6，SybaseASE数据库系统的总业务交易量为1.6。如果不特别指明，本文主要使用“账户类交易量”（“总业务交易量”）的表达方式。

该项目的几个关键点列示如下：

2009年7月刚刚上线时，其业务交易量约为300万笔/天（480万笔/天）；

2009年年底时，其业务交易量增长到600万笔/天（960万笔/天）；

2010年5月初，达到1000万笔/天（1600万笔/天）；

2010年10月初，达到1500万笔/天（2400万笔/天）；

未来2年内的业务压力预计是每天3000万笔（4800万笔/天），该目标很可能在2011年底提前达到。

4．Sybase数据库应用系统调优的五大领域

（1）压力测试领域

从笔者观察到的行业现状看，在应用系统上线前，通常会有不同形式的功能测试；但压力测试的普及度很低，即使有压力测试，也通常不能 很好地预测未来的系统表现。其造成的客观后果是：大多数大型数据库应用系统一定会在实际运行过程中发生性能问题，并且这种性能瓶颈通常过早地出现，没有能 够充分发挥系统软硬件资源的潜能。

究其原因，除了要强调压力测试对于大型系统的必要性，还要改进压力测试的方法。我认为，在压力测试领域应该注意３个关键问题，即“业务指标的确定策略”、“业务压力的模拟策略”、“性能评测指标的选取策略”。

(2)数据库应用端的调优

要进行数据库应用系统的调优，最好的着力点是从数据库应用端出发，找出实际运行效率低下的应用模块/ＳＱＬ。

传统的定位方法是：在应用逻辑中、或在应用模块调度/总控程序中加入“测控模块/语句”，衡量每个模块/语句的“入/出时间点”， 从而得到其执行时长。这种方法容易理解，常在系统调试阶段使用，也常用于层次化应用（LayeredApplication）环境中的层间隔离。但其缺点 是，这种方法会加重应用开发团队的负担，不容易运用于已经上线的生产系统中。

对于数据库应用中的SQL模块/语句方面的性能问题，我们推荐具备网络嗅探（NetworkSniffing）机制的工具，如美国 WhiteSands公司的ProActiveDBA。它能够借助于网络监听，在毫不影响应用系统的情况下，计算出每个SQL语句/模块的“入/出时间 点”，从而得到其执行时长，找到有效率问题的部分。

但是，按照其实际执行时间来排序、筛选的上述方法，并不一定能找出所有可能构成系统瓶颈的SQL。还有另外一种情形需要注意——某 些SQL，由于各种原因（例如，其涉及的数据较少、逻辑简单等），其单独的执行时间并不很长、很不起眼，但是其执行频度/总次数特别多，其累计的内存I /O（Sybase称其为逻辑I/O）特别多，因此会消耗大量的CPU资源。这时系统通常会表现为CPU特别忙，整体吞吐量下降。

对于这种情形，传统的测控手段可能会失效。相应的补救手段是：充分利用SybaseASE中早就存在、且在15版本中更加完善的各 种监控用系统表（MonitoringTables），也叫MDA表（MonitoringandDiagnosticstables）。

（3）数据库服务器端的调优

数据库服务器端的调优是数据库管理员（DBA）最重要的工作，本文无法也无意去赘述SybaseASE服务器调优的方方面面，只根据在此网上银行项目中的经历，重点提示某些关键内容，特别是与ASE15相关的调优技巧。

3.1StatementCache调优（特别是traceflag757与CPU忙问题）

自12.5.2版本起，ASE增加了StatementCache机制。作为对传统存储过程（StotedProcedure）处 理机制的扩展，它被用于存放即席查询（adhocSQL）的SQL文本、执行计划，以便改善同类SQL的执行效率（减少了SQL的再编译 recompiling时间）。

其实际效果取决于应用系统的特点，有些系统对此机制根本不敏感，某些系统则能够得到几十个百分点甚至数倍的性能提升。

在启用该机制时，一般建议同时启用enableliteralautoparam参数，以便将语句主体相同、只是参数不同的相似 SQL归为同类，提高StatementCache的效率。本项目的最大教训来自于StatementCache的“大小配置”与“分配策略”，以及可能 由此引发的系统级性能问题——CPU使用率高企却原因不明。

3.2ProcedureCache调优

自12.5.2版本起，ASE引入了StatementCache机制，并且把它作为ProcedureCache的一部分。同时 缺省的ProcedureCache也不再是整个Cache的20%，而是通过单独的服务器参数procedurecachesize来设定。

相较于ASE12.5，ASE15需要更多的ProcedureCache。因为它采用了更大的内存分配单元，其重新设计的查询处 理引擎需要更多的内存来评估新添的数据访问算法，allrows_dss和allrows_mix的优化目标也比allrows_oltp消耗更多 ProcedureCache，更不用说索引统计直方图（histograms）、排序用空间（sortbuffers）等。

因此，ASE15的ProcedureCache虽然不必达到早期版本中的整个Cache的20%，但也通常是ASE12.5的ProcedureCache的２～６倍。

(4)系统平台层的调优

近些年来，硬件业的飞速发展让我们这些数据库管理员（DBA）越来越少地去操心内存大小、网络带宽、磁盘吞吐能力等等系统平台层要素，尤其是在数据库服务器专用的硬件环境中。

正是长时间的放松让我们在本项目的调优中走了弯路！

(4.1)SAN存储的调优（CPUSpikes问题）

在本项目的某个时期，发生了数次“间歇性的CPU利用率冲高（CPUspikes）”。这与前述的因为 StatementCache分配策略引发的CPU利用率高企现象有相同之处：都会使CPU利用率升高、影响整个系统的吞吐量。二者也有差异性：前者持续 时间长，伴随着很高的“ObjectManagerSpinlockContention”；后者持续时间 短，“ObjectManagerSpinlockContention”也没有那么高。

在逐一排除了前述的SQL问题、统计值问题、索引问题、数据类型匹配问题、StatementCache等等因素之后，我们才不得不扩大排查范围——同时对数据库服务器与磁盘系统采样，缩短采样周期，提高采样次数，比较正常时段、异常时段２系统的关键指标。

我们终于发现，每一次“间歇性的CPU利用率冲高（CPUspikes）”都对应着磁盘系统 “AverageServiceTimes”的增加。即大部分磁盘明显变慢，约33％的设备慢2倍以上，11％的设备慢10倍以上！对应地，数据库的 “LogSemaphoreContention”跳升了20多倍，“PLCLatchContention”跳升了13倍！

由此说明，虽然SAN（StorageAreaNetwork）与LVM带来了很多益处，但也应当仔细规划。最常见的是那种 “StripeEverythingEverywhere”的存储设计模式，即把所有数据库对象都打散在逻辑卷（LV）上、LV打散 （stripping）在由数个PV组成的diskgroup上、一个SAN存储及其I/O通道为多个机器上的多个应用共享。这种模式的最大不足是：多个 机器上的多个应用系统之间通过共享的SAN相互影响，难以进行性能调优，难以实现灾难恢复（DisasterRecovery）。对于性能要求比较高的超 大型数据库应用系统，我们还是建议配置专用的硬件，无论是SAN、网络等等。

(4.2)NAS存储的调优

近年来，NAS（Network-AttachedStorage）存储被越来越广泛地使用，因为与SAN相比，它成本更低、文件共享更容易、对客户端要求更少。

本人曾经有一个难以忘怀的经历。某个工作日的下午４点，客户的Sybase数据库系统发生故障，6G的事务日志即将被用完且无法清除，所有数据修改交易即将被挂起！

事实说明，NAS不同于SAN、DAS（DirectAttachedStorage），它毕竟不是主机的直连存储设备，且通常没 有SAN那样的专用高速网络支撑，受网络连通性、稳定性、压力大小、网络性能的影响很大。在高可用、高性能的大型数据库应用系统中，我们不建议NAS空间 参与数据库的直接操作，无论是DUMP/LOAD、BCPIN/OUT，更不用说用作数据库设备。当然，可以变通地进行２阶段处理，如先将数据库DUMP 到本地或SAN上，再转存到NAS上。

（5）架构级调优

（5.1）数据库/应用级的拆分（理论上的多库结构与现实中的单库结构）

众所周知，Sybase不同于Oracle，从它诞生那天起，就可以在单个服务器中支持多个数据库。按照一个应用对应一个用户数据 库（UserDatabase）的惯例，Sybase服务器可以在理论上支撑多个数据库应用。伴随着硬件技术的飞速发展、集中式数据中心的再度流行，越来 越多的用户倾向于在一个ASE服务器上运行多个数据库应用，因为这样易于管理。

但事情总是存在着两面性，对于可靠性、性能要求都很高的大型数据库应用系统，单个服务器毕竟存在着可靠性方面的互相干扰和性能上的瓶颈（无论是CPU、内存、还是TEMPDB），不利于安排系统维护窗口、进一步提升性能。

事实上，对于现有各种面向OLTP的关系型数据库系统的多机系统，其可靠性方面的收益大于性能方面的收益。我们建议：为了达到最好 的性能扩展性，数据库应用系统应该首先在应用架构层面考虑多服务器/多数据库架构，即在必要时，单个应用系统应该能够很容易地拆分到多个服务器上，这是应 用架构级的真正可扩展性！

（5.2）数据（表）级的拆分（SybaseText/Image字段与LatchSleep问题）

本项目的另外一大收获是对ASELatchSleep现象的探究及其由此找到的提高SybaseText/Image字段修改效率的方法。这在以往的工作中并不多见，却是长久的疑惑，现总结如下。

Latch也叫Spinlock，是ASE针对“内部数据结构（如DataCache、 Object/IndexMetadataCache.）”的一种并发访问管理机制，以保持页面的物理一致性，只存在于SMP环境下。它是轻量级的、非事 务性的（lightweight&nontransactional）。

结语：

本文的意义在于：（１）该项目的客观实践再次证明了借助于Sybase/UNIX平台可以构造全国性的超大型数据库应用系统； （２）大型数据库应用系统往往需要经过全面的调优，甚至要为高性能而做必要的调整（如应用架构）；（３）大型数据库应用系统的调优工作不但需要理论知识， 更需要如本文所述的一些将理论综合运用于实践的经验——即国外通常所说的“最佳实践”。