Sybase Adaptive Server 管理手册
Sybase 安装及系统管理
一.关于设备：
RAW Device(裸分区) VS Filesystem Device
裸分区是指磁盘的一块物理分区，没有用作操作系统，其读写不通过操作系统缓冲。传统的Unix安装ASE推荐使用RAW Device确保资料的完整性和较好的IO性能。但在新版的Unix和Linux中UFS和JFS在资料完整性和读写性能的差距相较于裸设备已经非常微弱。还有就是裸设备的管理比较复杂。从ASE12.0开始Sybase提供dsync的属性对数据库设备禁止write-cache(写回缓冲)以确保资料的完整性和可恢复性。裸设备的使用出于安全和资料完整性方面的考虑比性能考虑多。
Async I/O (异步I/O)
异步IO是在一个IO动作未完成时同时可进行另外的动作。异步IO对于数据库的IO性能有较大的影响。在AIX和HP中都需要通过重新编译内核来支持。
二.关于内存：
首先确定可用的总的物理内存然后减去操作系统，Backup, Monitor等Sybase相关软件的开销即为Sybase总的可用内存。（建议服务器只做单纯的
ASE服务器并要删除不必要的服务以减少开销，例如xwindow）
在Unix及Linux中需要调整一些核心参数以支持较大的物理内存。以下列出一些可能需要调整的参数： shmmax(最大共享内存段大小,单位为字节)，shmall(可用内存的总数量，如果是字节同shmmax一样)。其余的像shmmin等参数请参考操作系统手册。
Sybase利用max memory确定最大可用内存量，具体内存的分配方式取决于以下两个参数allocate max shared memory和dynamic allocation on demand。Allocate max shared memory指定是否分配由max memory指定的最大内存，缺省不分配最大内存。Dynamic allocation on demand指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配。例如配置了用户连接数量只在用户连接到Sybase时才分配内存。
三.参数设定：（分组并只对常用参数进行说明）
1． Physical Memory：
allocate max shared memory （指定是否分配由max memory指定的最大内存，缺省不分配最大内存）
dynamic allocation on demand （指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配）
max memory (确定Sybase最大可用内存)
total logical memory (当前配置的逻辑内存，只读)
total physical memory（当前配置的物理内存，只读）
2． Disk I/O （磁盘IO）
allow sql server async i/o (允许SQL Server进行异步IO，此参数对于设备的IO性能有极大影响，需要操作系统支持)
disk i/o structures （磁盘IO结构，启动时分配磁盘IO控制块的数目.。将此值设定为操作系统允许的最大值以避免磁盘IO结构不够用的情况）
number of devices （Sybase所能使用的最大设备数目）
page utilization percent （页利用率）
3． Meta-Data Caches (元资料缓存)
number of open databases (可同时打开的数目库数目)
number of open indexes （可同时使用的索引数目）
number of open objects (可同时使用的对象数目)
以上三个参数都可用sp_countmetadata 来确定当前Sybase中三个参数的大小。调整后可在实际的使用过程中利用sp_sysmon 来确定是否设定合理）
4． Parallel Query （并行查询）
number of worker processes （同时可使用的并行查询的可用的工作进程数目）
max parallel degree （最大的查询并行程度）
max scan parallel degree (最大的扫描并行程度，一般的磁盘控制器使用2~3个工作进程就可以充分利用其IO)
5. Processors (处理器)
max online engines (最大的在线引擎数目，一个引擎可以理解为一个CPU的处理能力，不可大于操作系统可用的CPU个数)
number of engines at startup (Sybase启动时需要联机的引擎数目)
6. Lock Manager (锁管理)
lock scheme (锁定方案,缺省为allpages,从ASE 1192开始提供datarows的锁方案。利用行锁可以大大提升并发性能，但需要更多的锁，并且会有资料页产生较多空页困扰)
number of locks （可用的锁数目，此参数可能需要在使用过程中进行调整以适用不同的应用环境）
print deadlock information （打印死锁信息到日志，如果频繁发生死锁可打开此参数用来确定起因，但此参数会带来额外的开销，在SMP环境更是如此）
四.关于性能优化
好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。在 http://www.isug.com/Sybase_FAQ/ASE/section1.5.html中有说过客户端应用程序和数据库的物理设计决定了性能的80%。
对于系统管理所能够做的就是减少IO，缩短响应时间。在性能优化方面程序员同DBA的工作有时是重叠的，例如，判断索引是否必须，索引类型是否正确。监视数据库的运行判断是否优化!
总的来说，性能的提升就是缩短响应时间和提高吞吐量。Sybase的查询优化是基于开销的计算的。索引的使用可以：
1． 避免表扫描。
2． 点查询中定位包含特定资料的特定资料页。
3． 范围查询确定上下限。
4． 索引覆盖，完全避免存取数据页。
5． 连接时避免排序。
建立索引的注意事项：
1． Unique和primary key可以创建唯一索引，缺省情况下unique创建nonclustered，primary key创建clustered索引。
2． Allpages表一般都需要创建clustered索引或分区以减少最后一页的争夺。
3． 如果需要大量插入，不要将clustered索引建立在单调上升的字段上，如identity。对于dol表，此问题并不严重，但allpages却往往是锁争夺的根源。
4． 对allpages表，如有可能不要将clustered索引建立在频繁更新的字段上。
5． 使用索引覆盖来进行关键查询和不太频繁的查询。
6． 如果索引字段元唯一建立唯一索引，优化程序知道只有一行纪录匹配。
7． 索引键尽可能小，如果可能使用最小的数据类型。确保连接字段元数据类型相同，如果连接查询需要转换数据类型就不能使用索引。
8． 使用索引尽可能使用前导字段元能够提供良好的性能。
锁带来的性能冲突：
1． 一个事务等待另外的事务完成并释放锁影响响应时间和吞吐量。
2． 事务频繁死锁，累计CPU时间少的事务必须重新再来。并且会严重影响相应时间同吞吐量。
改善锁冲突的建议：
1． 添加索引减少争用。
2． 保持事务短小以减少持有锁的时间。
3． 避免热点。可通过表分区和clustered索引解决。
4． 应用以相同顺序获得所以减少死锁的发生。在使用大量表和更新几个表的事务中应确定一个由所有开发人员共享的锁定顺序。
5． 延迟死锁检测，”deadlock checking period”指定开始检查死锁前进程必须等待的毫秒数。
6． 使用应用程序的最低锁定级。只在必要时使用隔离级别2或3。如果仅有几个查询需要级别3则在整个事物中使用holdlock或at isolotion，而不用set transaction isolotion at 3。如果绝大部分的查询需要级别3则使用set transaction isolotion at 3，而可以在查询级别1的查询使用holdlock或at isolation。
7． 如果需要大量的查询，更新和删除，可通过在存储过程中使用光标频繁提交来减少阻塞。
8． 如果应用程序需要返回一行，等待用户反应然后更新该行，可考虑使用时间戳或者tsequal函数而不要使用holdlock。
9． 检查是否存在并发问题。
五．内存使用
充裕的内存可以减少磁盘IO,在数据库系统中磁盘IO是极其昂贵的开销。当用户访问资料时如果在缓存中能够找到的话称之为“逻辑IO“，否则从磁盘读取称之为“物理IO“
内存问题大致是以下几个方面：
1． 总的数据高速缓存太小。
2． 过程高速缓存太小。
3． 在SMP系统中只配置了缺省高速缓存，导致对高速缓存的争用。
4． 高速缓存大小不适用于特殊的应用。
5． IO大小不适用于特定的应用。
高速缓存分类：
1． 数据高速缓存。用于数据，索引和日志页
2． 过程高速缓存。用于存储过程和触发器以满足短期内存需求。
确定过程高速缓存的大小可用以下办法实现：
过程高速缓存大小=最大用户并发数目*最大的计划大小*1.25
具体如下：在使用一段时间的服务器上用dbcc traceon(3604)将信息写到屏幕，然后运行dbcc memusage确定最大的查询计划的大小，然后根据应用确定并发用户数量就可以大约得到高速缓存的大小了。其实在我们的ERP应用中最大的计划所需内存在450K左右，所以，一般来说，过程高速缓存的大小到100M肯定是够用的，并且当过程高速缓存不够时会有701的错误发生。
Sybase default只有”default data cache”，并且只有一个2K的缓冲池，对于大多数的情况这都是不适合的，我们需要建立命名高速缓存并将对象绑定到高速缓存。
Sybase支持的缓冲池大小有2K,4K,8K,16K。给tempdb建立单独的命名高速缓存，并合理分配缓冲池，一般4K的log IO的大小能够得到比较好的性能。在SMP的环境中还有一个问题就是螺旋锁的竞争，当用sp_sysmon观察到资料缓存螺旋锁争夺超过10%时就需要分区。sp_cacheconfig ‘cache name’,’cache_partition=X’就可以对缓存进行分区了。
六.sp_sysmon 的使用
sp_sysmon是ASE用来监控服务器在特定采样期间内的数据库的活动。在典型负载情况下能够提供服务器运行状况的描述，是性能调整的重要工具。以下的一些信息不是同sp_sysmon的输出顺序一样，但需要重点注意，这些信息来自Sybase的性能调整手册，仔细看了后觉得说的很是简洁明白，也就没有加入设么自己的东西了。其用法很简单，sp_sysmon “HH:MM:SS”即可，但sp_sysmon在运行时对性能有影响，特别是在SMP环境下。还有有时sp_sysmon并不能提供完全正确的资料，例如采样时间太长或者太短。
Data Cache Management
Cache Statistics Summary (all caches)
Cache Turnover (缓存周转)
Buffers Grabbed (缓存抢夺。所有缓存中替换的缓冲区数量)
Buffers Grabbed Dirty (缓存抢夺脏页。如果此值不为0代表严重性能问题)
Large I/O Effectiveness (大I/O效率)
Page by LRG I/O cached
Page by LRG I/O used (此两条信息报告由大I/O引入到高速缓存中及使用的页)
Asynchronous Prefecth Activity (异步预取活动)
APF issued (APF成功应用的次数)
APF Denied due to (不被大I/O的原因)
APF I/O overloads (缺少磁盘I/O结构或者由于磁盘信号争用而被拒绝的次数。如果因磁盘信号争用而引起检查高I/O发生处的对象物理放置)
APF Limit overloads (超出可用于异步预取的缓冲池的百分比。此值由global async prefetch limit所影响)
APF Reused overloads (由于页链扭结或因APF引入的缓冲区在被使用前换出而使APF被拒绝)
APF buffers found in cache (报告在资料高速缓存中找到的来自APF预先设置的缓冲区数量。异步预取使用快速扫描在资料高速缓存中尝试查找其需要的页，而不持有高速缓存螺旋锁。如果此操作不成功，则持有螺旋锁全面扫描)
Other asynchronous prefetch statistics
APF used （报告由异步预取引入高速缓存并在采样期间使用的页数）
APF wait for I/O （一个进程被迫等待异步预取完成的次数。这表示欲取未能及时发生，从而使页未能在查询前位于高速缓存中。此值有一定百分比是合理的，原因如下：
1． 第一个预取请求肯定需要等待
2． 顺序扫描到新的分配单元并发出预取请求是，查询需要等待直到第一个I/O完成
3． 每次费集群索引扫描找到一组限定行并发出预取请求时，需等待第一页返回。其它可能的影响包括每页上需要完成的处理数量及I/O系统速度。
APF Discard （异步预取读入并在使用他们之前放弃的页数。如果此值较大可能表示增加缓冲池大小能有助于提升性能。也可能表示APF正将页引入到查询不需要的高速缓存中）
Cache Management by Cache
Cache search , hit and miss information (缓存命中次数基本等于statistics io的逻辑读次数，未命中次数等于物理读次数。但sp_sysmon输出的值总是大于statistics io的次数，因为其包含系统表io,日志页和OAM页同其它系统开销。如果命中率很高添加内存可能对性能提升没有太大作用)
Found in wash (在高速缓存中的清洗部分找到所需要的页的次数。如果清洗部分高速缓存命中百分比很高，可能意味着清洗区过大。对于只读或写操作次数较低的高速缓存并不是问题)
（较大的清洗部分会导致物理IO的增加，因为在他们通过清洗标记时ASE启动所有脏页中的写操作。如果清洗区中的页写到磁盘并进行第二次更新则是浪费io。如果必要，可更改清洗区大小。如果减小清洗区大小，可在完全负载的情况下再次sp_sysmon并检查值大于0的”Grabbed dirty“的输出。）
Cache misses (报告在一个高速缓存中未找到所需页而从磁盘读取的次数)
Pool turnover （缓冲区周转。报告从高速缓存中每个池替换缓冲区的次数，此信息可帮助确定池和高速缓存大小是否合适）
LRU buffers Grab (LRU缓存争夺。”LRU buffers grab”仅在一页代替另一页时才替增。如果内存池对吞吐量来说太小，则可能会有这样的结果：池中周转率很高，高速缓存命中率降低及I/O增加。如果某些池中周转率很高而其它池中却很低，也许希望将活动性低的池中的空间移动到活动性高的池中，尤其在能够提高缓存命中率的情况下。)
（如果池中有1000个池而ASE每秒替换100个缓冲区，则每秒有10%的缓冲区在周转。这也许说明缓冲区在高速缓存中停留的时间不足以使对象有机会使用此高速缓存）
Grabbed dirty ( 写入磁盘前到达LRU的脏缓冲区数量的统计信息。当ASE需要从高速缓存的LRU端争夺一个缓冲区用以从磁盘读取一页，却找到一个脏缓冲区而不是干净缓冲区时他必须等待脏缓冲区I/O完成。)
（如果grabbed dirty非0，表示对于池中的吞吐量来说池的清洗区太小。补救措施取决于池的配置和使用情况：
1． 如果池很大且用于大量资料更新操作则应增加清洗区大小
2． 如果有几个对象使用此高速缓存，将其中一些对象移动到其它高速缓存中能够有所帮助
3． 如果高速缓存正由create index使用则高I/O率可引起脏缓冲区争夺，尤其在较小的16K池中。此情况下，可将其清洗区设置尽可能大，可达池中缓冲区的80%
4． 如果池非常小且周转率非常高则应考虑增加池和清洗区大小
5． 高速缓存已分区的话应减少分区数量
6． 检查查询计划和对象I/O统计信息，此对象使用高速缓存进行能够在池中执行许多物理I/O的查询。通过添加索引尽可能对查询进行优化。在“buffer wash behavior”部分检查“buffers already I/O”和”buffers washed dirty”的”per second”值。清洗区应足够大以允许I/O在到达LRU前能够在脏缓冲区完成。需要I/O的时间取决于磁盘驱动器完成的每秒时既物理写操作次数。也要检查“disk I/O management”以确认I/O争用是否减慢磁盘写操作。另外增加“housekeeper free write percent”也会有所帮助。
Buffer wash behavior (缓存清洗行为。报告缓冲区在到达池的清洗标记时的状
态信息。但缓冲区到达清洗标志时可能是以下三种情形之一：
1．“buffers passed clean”报告通过清洗标记的缓冲区数量。
缓冲区在高速缓存中是不进行修改，或进行了修改而且已经有管家任务或检查点写入到磁盘。“% of total”报告清理干净缓冲区占通过清洗标记的缓冲区总数的百分比。
2．“buffers already in I/O“报告I/O在进入清洗区时在缓冲区中已经处于活动的次数。处在高速缓存中时此页已脏。管家或检查点已经启动该页中的I/O但I/O还未完成。“% of total”报告已经在I/O中的缓冲区占进入清洗区总数的百分比。
3．“buffers washed dirty”报告缓冲区进入已脏的清洗区且不在I/O中的次数。缓冲区在高速缓存中时已修改且未写入磁盘。异步I/O通过清洗标记时已在页中启动。
Cache strategy (缓存策略。报告遵循“读取和放弃“-MRU和常规”最近最少使用”-LRU策略的情况下放置在高速缓存中的缓冲区数目)
Cache(LRU) buffers （报告使用LRU并放置在高速缓存的MRU端的缓冲区数量。包括直接在磁盘读取并放置在MRU端的所有缓冲区以及在高速缓存中找到的所有缓冲区。逻辑I/O完成时将缓冲区放置在高速缓存的MRU端）
Discared(MRU) buffers (报告使用读取和放弃此略的情况下放置在清洗标记区处的缓冲区数量)
如果希望整张表进行高速缓存，但“discared buffers”的值很高，可使用showplan观察优化程序是否在应该使用LRU时却生成MRU策略。
Large I/O usage (大I/O使用)
Large I/Os performed (衡量执行的请求的大I/O次数)
Large I/Os denied (报告大I/O不能执行的次数。大I/O不能执行的情况：
1． 如果缓冲区中任何页已经驻留在其它池中。
2． 请求的池中没有可用的缓冲区可用。
3． 在分配单元的第一个扩充页上，因为其包含分配页，该页被始终读入2K池中。
如果大I/O被拒的比例很高，说明大I/O没有获得预期的效果。如果高速缓存包含大I/O池，且查询对相同的对象执行2K和16K的I/O，则总会有一定比例的大I/O不能执行，因为页在2K池中。
如果被拒的大I/O超过半数，且在使用16K，应尝试将所有空间从16K的池中移动到8K池中。重新测试察看I/O总数是否减少。当16K I/O被拒绝是并不检查8K和4K池，但使用2K池。
可使用这个部分和”Pool turnover”帮助判断正确的池大小。）
Large I/O detail (大I/O详情。例如：查询执行一个16K的I/O并读取整个单个资料页，则“pages cache”为8，“pages used”为1)
Pages by LRG I/O cached (读入高速缓存的页总数)
Pages by LRG I/O used (在高速缓存中时由查询使用的页数)
Dirty read behavior (在隔离级别0时请求的平均页数。“dirty read page request”的”% of total”报告脏读数相对于页读总次数的百分比)
Procedure cache management (过程高速缓存管理)
Procedure requests (报告存储过程执行的次数。包括
1． 内存中存在查询计划空闲副本，因此可复制和使用。
2． 内存中无过程副本，或内存中计划的所有副本都在用，因此必须从磁盘读取。）
procedure reads from disk （存储过程从磁盘读取的次数而不是在过程高速缓存中找到和复制的次数）
procedure writes to disk (报告采样期间创建的过程数量，如果应用程序生成过程此值会很大。)
procedure removals (报告高速缓存中老化的次数。)
Recovery management (显示常规检查点进程引起的检查点数量，由管家任务启动的检查点数量和每个类型的时间平均长度。此信息有助于正确设定恢复参数和管家参数。)
Checkpoints (检查点将脏页写入到数据库设备中，ASE的常规检查点机制运行以保持最小恢复间隔。通过从执行最后的检查点开始跟踪事务日志中的日志纪录数，可估计出恢复事务需要的时间是否超出恢复间隔。如果这样，检查点进程扫描所有数据高速缓存并写出所有已更改的数据页。
ASE没有要处理的用户任务时，管家任务开始将脏缓冲区写入磁盘。这些写操作在服务器空闲周期内执行，所以称之为“free writes”。他提高CPU利用率并降低了事务处理中清洗缓冲区的要求。
如果管家进程完成了将所有脏页写入磁盘的操作，则检查点事务日志中起始于最后检查点的行数。如果日志纪录超过100行，则发出一个检查点，称之为“free checkpoints”。因此它只需要很小的开销。另外也减少了常规检查点未来的开销。）
Normal of free checkpoints （报告常规检查点进程执行的检查点数量。如果常规检查点执行大多数工作，特别是如果要很长时间，可考虑增加由管家任务执行的写操作次数。）
Number of free checkpoints (报告由管家任务执行的检查点数量。管家任务仅在完成从所有配置的高速缓存中清除所有脏页后才执行检查点。可用”housekeeper free write percent”参数配置最大百分比，如此管家任务可增加数据库的写操作。)
Total checkpoints (采样期间发生的常规和自由检查点的总数量。)
Average time per normal checkpoint(报告常规检查点持续的平均时间。)
Average time per free checkpoint（自由检查点持续的平均时间）
Increasing the housekeeper batch limit(管家任务就有内置批处理限制以避免单个设备磁盘I/O过载。缺省情况下，管家任务操作批处理大小设置为3。管家检测到已发出3个I/O到单个设备后立即停止当前缓冲池的写操作，并开始检查其它池中的脏页。如果写操作从下一池转到相同设备，则移动到另一池。检查晚所有吃后开始等待直到由他发出的最后的I/O完成，然后再开始下一循环。
缺省批处理限制是为了速度较慢的磁盘提供较好的I/O特性而设计。通过加快磁盘驱动器的批量大小会获得较好的性能。可为服务器上的所有设备进行全局设定次限制或为单个不同速度的磁盘设置不同的限制值。每次ASE重启后需要重新设定此限制。
单个设备设置批处理限制“dbcc tune (deviochar,vdevno,”10”)
更改所有设备的批处理大小，可用-l代替设备号“dbcc tune (deviocha,-l,”10”)
批量大小合法值为1-255，对于速度较快的磁盘，将批量大小设定为50可在测试过程中提高性能。
以下情况可尝试设定批量大小：
1． 常规检查点的平均时间很长
2． 超过I/O配置限制或出现对设备信号的争用不会出现任何问题。
Disk I/O management(报告磁盘I/O。描述服务器磁盘I/O活动并报告每个逻辑设备的读写与信号争用。)
Maximum outstanding I/Os。（报告ASE整体上待执行I/O的最大数量，以及Ase引擎在采样期间在任一点上待执行的I/O最大数量。）
I/Os delayed by (I/O 延迟原因)
Disk I/O structures (报告因达到磁盘I/O结构限制而延迟的I/O数量。当超出可用磁盘I/O控制块数量时，I/O被延迟。因ASE要求任务应在启动I/O请求前获得I/O控制块。“disk i/o structures”改善。)
Server configuration limit (ASE超出异步磁盘I/O请求数量的限制，而这些请求对于整个ASE来说可能同时处于未完成状态。可用”max async I/O per server”改善。)
Engine configuration limit(引擎超出未完成异步I/O请求的限制。使用”max async I/Os per engine”参数改善。)
Operation system limit (报告在采样间隔期间超出对未完成异步I/O的操作系统限制的次数。OS内核限制，进程或者整个系统在任何同一时间内处于待执行状态的异步I/O最大数目。)
Total request disk I/Os和total completed I/Os（请求和完成的I/O数量。两值应该相近，当然要排除次采样开始或采样结束时未完成的I/O数目。但相差过大，可能是操作系统瓶颈延迟了I/O。）
Device activity detail （报告个设备读写完成次数及占总I/O的百分比。可用来确定设备和对象分布是否合理。）
Device semaphore granted and waited (报告立即授予设备信号的次数及信号忙而任务被迫等待信号释放的次数。此资料只对SMP环境有意义。
对存在信号争用的设备解决办法之一是重新分配物理设备上的资料。）
Network I/O management (网络I/O管理)
无论I/O属于入站还是出站，ASE接收到一个大于信息报大小的命令则ASE将等待直到接收到完整命令才开始处理。因此需要多个信息包命令执行速度较慢且占用I/O资源较多。
如果每个信息包的平均字节数接近为服务器配置得缺省信息包大小，则需要为某些连接配置较大的信息包大小。可为所有连接配置网络信息包大小，或允许某种连接使用较大的信息包大小登陆。
Network I/Os delayed （报告I/O延迟次数。如此值始终为非0值应咨询网管。）
Average bytes received per packet (采样期间接收的所有信息包平均大小。)
Average bytes sent per packet (发送信息包平均大小。)
关于减少信息包开销：应用使用存储过程可通过关闭某种TDS的消息提高吞吐量，该TDS消息是在存储过程中执行的每个select语句之后发送的消息。此消息（done in proc）用于某些客户端产品。在某些情况下，关闭(done in proc)也关闭“rows returned”消息。这些消息可能在某些client-library程序中出现，但许多客户端只是简单放弃了这些结果。测试客户端产品和open client程序的设置，以便在生产系统中禁用此消息之前确定是否有影响。
关闭(done in proc)可在某些环境中略微提高吞吐量，特别是速度较慢或过载网络中，但在其它环境也可能没有任何效果。
关闭消息：dbcc tune (doneinproc,0)
开启消息: dbcc tune （doneinproc,1）此命令必须在每次重启时发出。
七.用户数据库的完整性和性能管理：
数据库完整性：
1页级和行级的页链和资料指针用dbcc checkstorage，dbcc checktable,
dbcc checkdb
dbcc checkdb (dbname) 数据库级检测
dbcc checktable (tablename) 表级检测
2.检查页分配用 dbcc checkstorag, dbcc checkalloc, dbcc checkverif, dbcc tablealloc, dbcc indexalloc
3.dbcc checkcatalog (dbname)
我们可在sql advantage中执行dbcc命令然后观察输出结果是否报错，如若有错采取相应措施。
注：dbcc 需要开销一定的磁盘等资源，请勿在服务器繁忙时执行。其它dbcc命令请参考sybase管理手册
性能管理：
表的更新活动会导致空间利用不充分及性能下降。reorg命令既用来重组表空间并提高性能。
1. reorg reclaim_space 回收因删除和行缩短更新操作产生的页上的未用空间。
reorg reclaim_space tablename回收表上的未用空间
2. reorg rebuild 撤消行转移及回收空间，重写所有行以便与表的聚簇索引一致，向数据页写入行以便与通过sp_chgattribute对空间管理设置所做的改变保持一致,删除并重建表的所有索引
reorg rebuild tablename 回收表空间，重建所有索引。
注：reorg同dbcc一样 需要开销一定的磁盘等资源，请勿在服务器繁忙时执行。其它dbcc命令请参考sybase管理手册。
3. update statistics,update all statistics 更新制定索引中键值分布信息和列信息。更新索引或表中所有列的信息。
Update statistics table 更新索引和表中的信息。
4．sp_recompile 让使用该表的存储过程和触发器在下次运行时重新编译。在添加索引或对数据库进行其它影响统计信息的更改时，表的存储过程和触发器可能会失效。通过重新编译可将查询优化到最有效的状态。
sp_recompile tablename 使用该表的存储过程和触发器在下次运行时重新编译。
八.数据库备份和恢复：
备份
添加备份设备：sp_addumpdevice tape, logicalname, physicalname,tapesize
假设添加unix下的备份设备容量为4G，磁带路径为/dev/rmt/c1b0t0l0n
sp_addumpdevice tape,tape,'/dev/rmt/c1b0t0l0n',4000
NT:
1.备份到硬盘 dump database dbname to ‘x:/path/filename’
2.备份到磁带 dump database dbname to ‘//./tape0’ with init,capacity=xxxxx
其中init参数为初始化磁带，capacity为容量。单位为K
3.备份到备份设备tape dump database dbname to tape with init
指定备份设备就不需指定绝对路径和容量
UNIX:
1.备份到硬盘 dump database dbname to ‘/path/filename’
2备份到磁带 dump database dbname to ‘/dev/rmt/tapedevie’ with init,capacity=xxxxx
其中/dev/rmt/tape为unix下磁带设备名。init参数为初始化磁带，capacity为容量。单位为K
恢复：
NT:
1. 从硬盘恢复load database dbname from ‘x:/path/filename’
2. 从磁带恢复 load database dbname from ‘//./tape0’或load database dbname from tape
//./tape0为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
UNIX:
3. 从硬盘恢复load database dbname from ‘/path/filename’
4. 从磁带恢复 load database dbname from ‘/dev/rmt/cxbxtxlx’或load database dbname from tape
/dev/rmt/cxbxtxlx 为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
九．一些可能出现的问题及相应措施
1． Dbcc在数据库活动频繁时执行可能会报告索引损坏。此时并不一定真是索引有问题，可能只是因为checkpoint未执行导致缓存中的页同磁盘页不一致，先checkpoint看能否解决问题，如果不行的话再执行dbcc reindex （table_name）一般来说就可以解决的。如果还不行的话看是否需要将索引删除再重建。还有一个办法就是将表中的资料bcp out后再创建table将资料bcp进去。
2． Sybase 12.0的backup好象有bug，在不同dbid的情况下load数据库可能在dbcc checkcatalog时报告12945的错误。一般来说不会真的有资料参照性错误只是一个假像而以。对于此错误请备份数据库后手动更新sysreferences将错误的参照关系修改过来再重新测试应用有否出错。
3． Sybase 12.5的版本可能会在前端程序执行时报告21的错误，在sybase errorlog中的错误号码为1265，这其实也是sybase的一个bug，可以在sybase启动时加上2808的traceflag来避免此问题。但traceflag 2808可能会引起轻微的性能下降。
十．其它的一些性能调整工具
1.optdiag 用来显示systabstats和systatistics的统计信息。
用optdiag可以观察表的统计信息例如大I/O效率，统计信息是否需要更新等等。
2．dbcc traceon(3604,310,302)可以报告优化程序对查询所作的最终决定不合适。例如索引的选择等等。
3．set statitstics (io,subquerycache,time) on 检查I/O，自查询缓存等等信息。
4．Set showplan,sp_showplan,dbcc sqltext 显示批处理中每个查询的执行步骤，查询所用的键和索引，连接顺序和特殊优化查询。
5. free,vmstat,iostat,sar等os工具分析系统状况。
参考<>,<>,<>,<>等。
一.关于设备：
RAW Device(裸分区) VS Filesystem Device
裸分区是指磁盘的一块物理分区，没有用作操作系统，其读写不通过操作系统缓冲。传统的Unix安装ASE推荐使用RAW Device确保资料的完整性和较好的IO性能。但在新版的Unix和Linux中UFS和JFS在资料完整性和读写性能的差距相较于裸设备已经非常微弱。还有就是裸设备的管理比较复杂。从ASE12.0开始Sybase提供dsync的属性对数据库设备禁止write-cache(写回缓冲)以确保资料的完整性和可恢复性。裸设备的使用出于安全和资料完整性方面的考虑比性能考虑多。
Async I/O (异步I/O)
异步IO是在一个IO动作未完成时同时可进行另外的动作。异步IO对于数据库的IO性能有较大的影响。在AIX和HP中都需要通过重新编译内核来支持。
二.关于内存：
首先确定可用的总的物理内存然后减去操作系统，Backup, Monitor等Sybase相关软件的开销即为Sybase总的可用内存。（建议服务器只做单纯的
ASE服务器并要删除不必要的服务以减少开销，例如xwindow）
在Unix及Linux中需要调整一些核心参数以支持较大的物理内存。以下列出一些可能需要调整的参数： shmmax(最大共享内存段大小,单位为字节)，shmall(可用内存的总数量，如果是字节同shmmax一样)。其余的像shmmin等参数请参考操作系统手册。
Sybase利用max memory确定最大可用内存量，具体内存的分配方式取决于以下两个参数allocate max shared memory和dynamic allocation on demand。Allocate max shared memory指定是否分配由max memory指定的最大内存，缺省不分配最大内存。Dynamic allocation on demand指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配。例如配置了用户连接数量只在用户连接到Sybase时才分配内存。
三.参数设定：（分组并只对常用参数进行说明）
1． Physical Memory：
allocate max shared memory （指定是否分配由max memory指定的最大内存，缺省不分配最大内存）
dynamic allocation on demand （指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配）
max memory (确定Sybase最大可用内存)
total logical memory (当前配置的逻辑内存，只读)
total physical memory（当前配置的物理内存，只读）
2． Disk I/O （磁盘IO）
allow sql server async i/o (允许SQL Server进行异步IO，此参数对于设备的IO性能有极大影响，需要操作系统支持)
disk i/o structures （磁盘IO结构，启动时分配磁盘IO控制块的数目.。将此值设定为操作系统允许的最大值以避免磁盘IO结构不够用的情况）
number of devices （Sybase所能使用的最大设备数目）
page utilization percent （页利用率）
3． Meta-Data Caches (元资料缓存)
number of open databases (可同时打开的数目库数目)
number of open indexes （可同时使用的索引数目）
number of open objects (可同时使用的对象数目)
以上三个参数都可用sp_countmetadata 来确定当前Sybase中三个参数的大小。调整后可在实际的使用过程中利用sp_sysmon 来确定是否设定合理）
4． Parallel Query （并行查询）
number of worker processes （同时可使用的并行查询的可用的工作进程数目）
max parallel degree （最大的查询并行程度）
max scan parallel degree (最大的扫描并行程度，一般的磁盘控制器使用2~3个工作进程就可以充分利用其IO)
5. Processors (处理器)
max online engines (最大的在线引擎数目，一个引擎可以理解为一个CPU的处理能力，不可大于操作系统可用的CPU个数)
number of engines at startup (Sybase启动时需要联机的引擎数目)
6. Lock Manager (锁管理)
lock scheme (锁定方案,缺省为allpages,从ASE 1192开始提供datarows的锁方案。利用行锁可以大大提升并发性能，但需要更多的锁，并且会有资料页产生较多空页困扰)
number of locks （可用的锁数目，此参数可能需要在使用过程中进行调整以适用不同的应用环境）
print deadlock information （打印死锁信息到日志，如果频繁发生死锁可打开此参数用来确定起因，但此参数会带来额外的开销，在SMP环境更是如此）
四.关于性能优化
好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。在 http://www.isug.com/Sybase_FAQ/ASE/section1.5.html中有说过客户端应用程序和数据库的物理设计决定了性能的80%。
对于系统管理所能够做的就是减少IO，缩短响应时间。在性能优化方面程序员同DBA的工作有时是重叠的，例如，判断索引是否必须，索引类型是否正确。监视数据库的运行判断是否优化!
总的来说，性能的提升就是缩短响应时间和提高吞吐量。Sybase的查询优化是基于开销的计算的。索引的使用可以：
1． 避免表扫描。
2． 点查询中定位包含特定资料的特定资料页。
3． 范围查询确定上下限。
4． 索引覆盖，完全避免存取数据页。
5． 连接时避免排序。
建立索引的注意事项：
1． Unique和primary key可以创建唯一索引，缺省情况下unique创建nonclustered，primary key创建clustered索引。
2． Allpages表一般都需要创建clustered索引或分区以减少最后一页的争夺。
3． 如果需要大量插入，不要将clustered索引建立在单调上升的字段上，如identity。对于dol表，此问题并不严重，但allpages却往往是锁争夺的根源。
4． 对allpages表，如有可能不要将clustered索引建立在频繁更新的字段上。
5． 使用索引覆盖来进行关键查询和不太频繁的查询。
6． 如果索引字段元唯一建立唯一索引，优化程序知道只有一行纪录匹配。
7． 索引键尽可能小，如果可能使用最小的数据类型。确保连接字段元数据类型相同，如果连接查询需要转换数据类型就不能使用索引。
8． 使用索引尽可能使用前导字段元能够提供良好的性能。
锁带来的性能冲突：
1． 一个事务等待另外的事务完成并释放锁影响响应时间和吞吐量。
2． 事务频繁死锁，累计CPU时间少的事务必须重新再来。并且会严重影响相应时间同吞吐量。
改善锁冲突的建议：
1． 添加索引减少争用。
2． 保持事务短小以减少持有锁的时间。
3． 避免热点。可通过表分区和clustered索引解决。
4． 应用以相同顺序获得所以减少死锁的发生。在使用大量表和更新几个表的事务中应确定一个由所有开发人员共享的锁定顺序。
5． 延迟死锁检测，”deadlock checking period”指定开始检查死锁前进程必须等待的毫秒数。
6． 使用应用程序的最低锁定级。只在必要时使用隔离级别2或3。如果仅有几个查询需要级别3则在整个事物中使用holdlock或at isolotion，而不用set transaction isolotion at 3。如果绝大部分的查询需要级别3则使用set transaction isolotion at 3，而可以在查询级别1的查询使用holdlock或at isolation。
7． 如果需要大量的查询，更新和删除，可通过在存储过程中使用光标频繁提交来减少阻塞。
8． 如果应用程序需要返回一行，等待用户反应然后更新该行，可考虑使用时间戳或者tsequal函数而不要使用holdlock。
9． 检查是否存在并发问题。
五．内存使用
充裕的内存可以减少磁盘IO,在数据库系统中磁盘IO是极其昂贵的开销。当用户访问资料时如果在缓存中能够找到的话称之为“逻辑IO“，否则从磁盘读取称之为“物理IO“
内存问题大致是以下几个方面：
1． 总的数据高速缓存太小。
2． 过程高速缓存太小。
3． 在SMP系统中只配置了缺省高速缓存，导致对高速缓存的争用。
4． 高速缓存大小不适用于特殊的应用。
5． IO大小不适用于特定的应用。
高速缓存分类：
1． 数据高速缓存。用于数据，索引和日志页
2． 过程高速缓存。用于存储过程和触发器以满足短期内存需求。
确定过程高速缓存的大小可用以下办法实现：
过程高速缓存大小=最大用户并发数目*最大的计划大小*1.25
具体如下：在使用一段时间的服务器上用dbcc traceon(3604)将信息写到屏幕，然后运行dbcc memusage确定最大的查询计划的大小，然后根据应用确定并发用户数量就可以大约得到高速缓存的大小了。其实在我们的ERP应用中最大的计划所需内存在450K左右，所以，一般来说，过程高速缓存的大小到100M肯定是够用的，并且当过程高速缓存不够时会有701的错误发生。
Sybase default只有”default data cache”，并且只有一个2K的缓冲池，对于大多数的情况这都是不适合的，我们需要建立命名高速缓存并将对象绑定到高速缓存。
Sybase支持的缓冲池大小有2K,4K,8K,16K。给tempdb建立单独的命名高速缓存，并合理分配缓冲池，一般4K的log IO的大小能够得到比较好的性能。在SMP的环境中还有一个问题就是螺旋锁的竞争，当用sp_sysmon观察到资料缓存螺旋锁争夺超过10%时就需要分区。sp_cacheconfig ‘cache name’,’cache_partition=X’就可以对缓存进行分区了。
六.sp_sysmon 的使用
sp_sysmon是ASE用来监控服务器在特定采样期间内的数据库的活动。在典型负载情况下能够提供服务器运行状况的描述，是性能调整的重要工具。以下的一些信息不是同sp_sysmon的输出顺序一样，但需要重点注意，这些信息来自Sybase的性能调整手册，仔细看了后觉得说的很是简洁明白，也就没有加入设么自己的东西了。其用法很简单，sp_sysmon “HH:MM:SS”即可，但sp_sysmon在运行时对性能有影响，特别是在SMP环境下。还有有时sp_sysmon并不能提供完全正确的资料，例如采样时间太长或者太短。
Data Cache Management
Cache Statistics Summary (all caches)
Cache Turnover (缓存周转)
Buffers Grabbed (缓存抢夺。所有缓存中替换的缓冲区数量)
Buffers Grabbed Dirty (缓存抢夺脏页。如果此值不为0代表严重性能问题)
Large I/O Effectiveness (大I/O效率)
Page by LRG I/O cached
Page by LRG I/O used (此两条信息报告由大I/O引入到高速缓存中及使用的页)
Asynchronous Prefecth Activity (异步预取活动)
APF issued (APF成功应用的次数)
APF Denied due to (不被大I/O的原因)
APF I/O overloads (缺少磁盘I/O结构或者由于磁盘信号争用而被拒绝的次数。如果因磁盘信号争用而引起检查高I/O发生处的对象物理放置)
APF Limit overloads (超出可用于异步预取的缓冲池的百分比。此值由global async prefetch limit所影响)
APF Reused overloads (由于页链扭结或因APF引入的缓冲区在被使用前换出而使APF被拒绝)
APF buffers found in cache (报告在资料高速缓存中找到的来自APF预先设置的缓冲区数量。异步预取使用快速扫描在资料高速缓存中尝试查找其需要的页，而不持有高速缓存螺旋锁。如果此操作不成功，则持有螺旋锁全面扫描)
Other asynchronous prefetch statistics
APF used （报告由异步预取引入高速缓存并在采样期间使用的页数）
APF wait for I/O （一个进程被迫等待异步预取完成的次数。这表示欲取未能及时发生，从而使页未能在查询前位于高速缓存中。此值有一定百分比是合理的，原因如下：
1． 第一个预取请求肯定需要等待
2． 顺序扫描到新的分配单元并发出预取请求是，查询需要等待直到第一个I/O完成
3． 每次费集群索引扫描找到一组限定行并发出预取请求时，需等待第一页返回。其它可能的影响包括每页上需要完成的处理数量及I/O系统速度。
APF Discard （异步预取读入并在使用他们之前放弃的页数。如果此值较大可能表示增加缓冲池大小能有助于提升性能。也可能表示APF正将页引入到查询不需要的高速缓存中）
Cache Management by Cache
Cache search , hit and miss information (缓存命中次数基本等于statistics io的逻辑读次数，未命中次数等于物理读次数。但sp_sysmon输出的值总是大于statistics io的次数，因为其包含系统表io,日志页和OAM页同其它系统开销。如果命中率很高添加内存可能对性能提升没有太大作用)
Found in wash (在高速缓存中的清洗部分找到所需要的页的次数。如果清洗部分高速缓存命中百分比很高，可能意味着清洗区过大。对于只读或写操作次数较低的高速缓存并不是问题)
（较大的清洗部分会导致物理IO的增加，因为在他们通过清洗标记时ASE启动所有脏页中的写操作。如果清洗区中的页写到磁盘并进行第二次更新则是浪费io。如果必要，可更改清洗区大小。如果减小清洗区大小，可在完全负载的情况下再次sp_sysmon并检查值大于0的”Grabbed dirty“的输出。）
Cache misses (报告在一个高速缓存中未找到所需页而从磁盘读取的次数)
Pool turnover （缓冲区周转。报告从高速缓存中每个池替换缓冲区的次数，此信息可帮助确定池和高速缓存大小是否合适）
LRU buffers Grab (LRU缓存争夺。”LRU buffers grab”仅在一页代替另一页时才替增。如果内存池对吞吐量来说太小，则可能会有这样的结果：池中周转率很高，高速缓存命中率降低及I/O增加。如果某些池中周转率很高而其它池中却很低，也许希望将活动性低的池中的空间移动到活动性高的池中，尤其在能够提高缓存命中率的情况下。)
（如果池中有1000个池而ASE每秒替换100个缓冲区，则每秒有10%的缓冲区在周转。这也许说明缓冲区在高速缓存中停留的时间不足以使对象有机会使用此高速缓存）
Grabbed dirty ( 写入磁盘前到达LRU的脏缓冲区数量的统计信息。当ASE需要从高速缓存的LRU端争夺一个缓冲区用以从磁盘读取一页，却找到一个脏缓冲区而不是干净缓冲区时他必须等待脏缓冲区I/O完成。)
（如果grabbed dirty非0，表示对于池中的吞吐量来说池的清洗区太小。补救措施取决于池的配置和使用情况：
1． 如果池很大且用于大量资料更新操作则应增加清洗区大小
2． 如果有几个对象使用此高速缓存，将其中一些对象移动到其它高速缓存中能够有所帮助
3． 如果高速缓存正由create index使用则高I/O率可引起脏缓冲区争夺，尤其在较小的16K池中。此情况下，可将其清洗区设置尽可能大，可达池中缓冲区的80%
4． 如果池非常小且周转率非常高则应考虑增加池和清洗区大小
5． 高速缓存已分区的话应减少分区数量
6． 检查查询计划和对象I/O统计信息，此对象使用高速缓存进行能够在池中执行许多物理I/O的查询。通过添加索引尽可能对查询进行优化。在“buffer wash behavior”部分检查“buffers already I/O”和”buffers washed dirty”的”per second”值。清洗区应足够大以允许I/O在到达LRU前能够在脏缓冲区完成。需要I/O的时间取决于磁盘驱动器完成的每秒时既物理写操作次数。也要检查“disk I/O management”以确认I/O争用是否减慢磁盘写操作。另外增加“housekeeper free write percent”也会有所帮助。
Buffer wash behavior (缓存清洗行为。报告缓冲区在到达池的清洗标记时的状
态信息。但缓冲区到达清洗标志时可能是以下三种情形之一：
1．“buffers passed clean”报告通过清洗标记的缓冲区数量。
缓冲区在高速缓存中是不进行修改，或进行了修改而且已经有管家任务或检查点写入到磁盘。“% of total”报告清理干净缓冲区占通过清洗标记的缓冲区总数的百分比。
2．“buffers already in I/O“报告I/O在进入清洗区时在缓冲区中已经处于活动的次数。处在高速缓存中时此页已脏。管家或检查点已经启动该页中的I/O但I/O还未完成。“% of total”报告已经在I/O中的缓冲区占进入清洗区总数的百分比。
3．“buffers washed dirty”报告缓冲区进入已脏的清洗区且不在I/O中的次数。缓冲区在高速缓存中时已修改且未写入磁盘。异步I/O通过清洗标记时已在页中启动。
Cache strategy (缓存策略。报告遵循“读取和放弃“-MRU和常规”最近最少使用”-LRU策略的情况下放置在高速缓存中的缓冲区数目)
Cache(LRU) buffers （报告使用LRU并放置在高速缓存的MRU端的缓冲区数量。包括直接在磁盘读取并放置在MRU端的所有缓冲区以及在高速缓存中找到的所有缓冲区。逻辑I/O完成时将缓冲区放置在高速缓存的MRU端）
Discared(MRU) buffers (报告使用读取和放弃此略的情况下放置在清洗标记区处的缓冲区数量)
如果希望整张表进行高速缓存，但“discared buffers”的值很高，可使用showplan观察优化程序是否在应该使用LRU时却生成MRU策略。
Large I/O usage (大I/O使用)
Large I/Os performed (衡量执行的请求的大I/O次数)
Large I/Os denied (报告大I/O不能执行的次数。大I/O不能执行的情况：
1． 如果缓冲区中任何页已经驻留在其它池中。
2． 请求的池中没有可用的缓冲区可用。
3． 在分配单元的第一个扩充页上，因为其包含分配页，该页被始终读入2K池中。
如果大I/O被拒的比例很高，说明大I/O没有获得预期的效果。如果高速缓存包含大I/O池，且查询对相同的对象执行2K和16K的I/O，则总会有一定比例的大I/O不能执行，因为页在2K池中。
如果被拒的大I/O超过半数，且在使用16K，应尝试将所有空间从16K的池中移动到8K池中。重新测试察看I/O总数是否减少。当16K I/O被拒绝是并不检查8K和4K池，但使用2K池。
可使用这个部分和”Pool turnover”帮助判断正确的池大小。）
Large I/O detail (大I/O详情。例如：查询执行一个16K的I/O并读取整个单个资料页，则“pages cache”为8，“pages used”为1)
Pages by LRG I/O cached (读入高速缓存的页总数)
Pages by LRG I/O used (在高速缓存中时由查询使用的页数)
Dirty read behavior (在隔离级别0时请求的平均页数。“dirty read page request”的”% of total”报告脏读数相对于页读总次数的百分比)
Procedure cache management (过程高速缓存管理)
Procedure requests (报告存储过程执行的次数。包括
1． 内存中存在查询计划空闲副本，因此可复制和使用。
2． 内存中无过程副本，或内存中计划的所有副本都在用，因此必须从磁盘读取。）
procedure reads from disk （存储过程从磁盘读取的次数而不是在过程高速缓存中找到和复制的次数）
procedure writes to disk (报告采样期间创建的过程数量，如果应用程序生成过程此值会很大。)
procedure removals (报告高速缓存中老化的次数。)
Recovery management (显示常规检查点进程引起的检查点数量，由管家任务启动的检查点数量和每个类型的时间平均长度。此信息有助于正确设定恢复参数和管家参数。)
Checkpoints (检查点将脏页写入到数据库设备中，ASE的常规检查点机制运行以保持最小恢复间隔。通过从执行最后的检查点开始跟踪事务日志中的日志纪录数，可估计出恢复事务需要的时间是否超出恢复间隔。如果这样，检查点进程扫描所有数据高速缓存并写出所有已更改的数据页。
ASE没有要处理的用户任务时，管家任务开始将脏缓冲区写入磁盘。这些写操作在服务器空闲周期内执行，所以称之为“free writes”。他提高CPU利用率并降低了事务处理中清洗缓冲区的要求。
如果管家进程完成了将所有脏页写入磁盘的操作，则检查点事务日志中起始于最后检查点的行数。如果日志纪录超过100行，则发出一个检查点，称之为“free checkpoints”。因此它只需要很小的开销。另外也减少了常规检查点未来的开销。）
Normal of free checkpoints （报告常规检查点进程执行的检查点数量。如果常规检查点执行大多数工作，特别是如果要很长时间，可考虑增加由管家任务执行的写操作次数。）
Number of free checkpoints (报告由管家任务执行的检查点数量。管家任务仅在完成从所有配置的高速缓存中清除所有脏页后才执行检查点。可用”housekeeper free write percent”参数配置最大百分比，如此管家任务可增加数据库的写操作。)
Total checkpoints (采样期间发生的常规和自由检查点的总数量。)
Average time per normal checkpoint(报告常规检查点持续的平均时间。)
Average time per free checkpoint（自由检查点持续的平均时间）
Increasing the housekeeper batch limit(管家任务就有内置批处理限制以避免单个设备磁盘I/O过载。缺省情况下，管家任务操作批处理大小设置为3。管家检测到已发出3个I/O到单个设备后立即停止当前缓冲池的写操作，并开始检查其它池中的脏页。如果写操作从下一池转到相同设备，则移动到另一池。检查晚所有吃后开始等待直到由他发出的最后的I/O完成，然后再开始下一循环。
缺省批处理限制是为了速度较慢的磁盘提供较好的I/O特性而设计。通过加快磁盘驱动器的批量大小会获得较好的性能。可为服务器上的所有设备进行全局设定次限制或为单个不同速度的磁盘设置不同的限制值。每次ASE重启后需要重新设定此限制。
单个设备设置批处理限制“dbcc tune (deviochar,vdevno,”10”)
更改所有设备的批处理大小，可用-l代替设备号“dbcc tune (deviocha,-l,”10”)
批量大小合法值为1-255，对于速度较快的磁盘，将批量大小设定为50可在测试过程中提高性能。
以下情况可尝试设定批量大小：
1． 常规检查点的平均时间很长
2． 超过I/O配置限制或出现对设备信号的争用不会出现任何问题。
Disk I/O management(报告磁盘I/O。描述服务器磁盘I/O活动并报告每个逻辑设备的读写与信号争用。)
Maximum outstanding I/Os。（报告ASE整体上待执行I/O的最大数量，以及Ase引擎在采样期间在任一点上待执行的I/O最大数量。）
I/Os delayed by (I/O 延迟原因)
Disk I/O structures (报告因达到磁盘I/O结构限制而延迟的I/O数量。当超出可用磁盘I/O控制块数量时，I/O被延迟。因ASE要求任务应在启动I/O请求前获得I/O控制块。“disk i/o structures”改善。)
Server configuration limit (ASE超出异步磁盘I/O请求数量的限制，而这些请求对于整个ASE来说可能同时处于未完成状态。可用”max async I/O per server”改善。)
Engine configuration limit(引擎超出未完成异步I/O请求的限制。使用”max async I/Os per engine”参数改善。)
Operation system limit (报告在采样间隔期间超出对未完成异步I/O的操作系统限制的次数。OS内核限制，进程或者整个系统在任何同一时间内处于待执行状态的异步I/O最大数目。)
Total request disk I/Os和total completed I/Os（请求和完成的I/O数量。两值应该相近，当然要排除次采样开始或采样结束时未完成的I/O数目。但相差过大，可能是操作系统瓶颈延迟了I/O。）
Device activity detail （报告个设备读写完成次数及占总I/O的百分比。可用来确定设备和对象分布是否合理。）
Device semaphore granted and waited (报告立即授予设备信号的次数及信号忙而任务被迫等待信号释放的次数。此资料只对SMP环境有意义。
对存在信号争用的设备解决办法之一是重新分配物理设备上的资料。）
Network I/O management (网络I/O管理)
无论I/O属于入站还是出站，ASE接收到一个大于信息报大小的命令则ASE将等待直到接收到完整命令才开始处理。因此需要多个信息包命令执行速度较慢且占用I/O资源较多。
如果每个信息包的平均字节数接近为服务器配置得缺省信息包大小，则需要为某些连接配置较大的信息包大小。可为所有连接配置网络信息包大小，或允许某种连接使用较大的信息包大小登陆。
Network I/Os delayed （报告I/O延迟次数。如此值始终为非0值应咨询网管。）
Average bytes received per packet (采样期间接收的所有信息包平均大小。)
Average bytes sent per packet (发送信息包平均大小。)
关于减少信息包开销：应用使用存储过程可通过关闭某种TDS的消息提高吞吐量，该TDS消息是在存储过程中执行的每个select语句之后发送的消息。此消息（done in proc）用于某些客户端产品。在某些情况下，关闭(done in proc)也关闭“rows returned”消息。这些消息可能在某些client-library程序中出现，但许多客户端只是简单放弃了这些结果。测试客户端产品和open client程序的设置，以便在生产系统中禁用此消息之前确定是否有影响。
关闭(done in proc)可在某些环境中略微提高吞吐量，特别是速度较慢或过载网络中，但在其它环境也可能没有任何效果。
关闭消息：dbcc tune (doneinproc,0)
开启消息: dbcc tune （doneinproc,1）此命令必须在每次重启时发出。
七.用户数据库的完整性和性能管理：
数据库完整性：
1页级和行级的页链和资料指针用dbcc checkstorage，dbcc checktable,
dbcc checkdb
dbcc checkdb (dbname) 数据库级检测
dbcc checktable (tablename) 表级检测
2.检查页分配用 dbcc checkstorag, dbcc checkalloc, dbcc checkverif, dbcc tablealloc, dbcc indexalloc
3.dbcc checkcatalog (dbname)
我们可在sql advantage中执行dbcc命令然后观察输出结果是否报错，如若有错采取相应措施。
注：dbcc 需要开销一定的磁盘等资源，请勿在服务器繁忙时执行。其它dbcc命令请参考sybase管理手册
性能管理：
表的更新活动会导致空间利用不充分及性能下降。reorg命令既用来重组表空间并提高性能。
1. reorg reclaim_space 回收因删除和行缩短更新操作产生的页上的未用空间。
reorg reclaim_space tablename回收表上的未用空间
2. reorg rebuild 撤消行转移及回收空间，重写所有行以便与表的聚簇索引一致，向数据页写入行以便与通过sp_chgattribute对空间管理设置所做的改变保持一致,删除并重建表的所有索引
reorg rebuild tablename 回收表空间，重建所有索引。
注：reorg同dbcc一样 需要开销一定的磁盘等资源，请勿在服务器繁忙时执行。其它dbcc命令请参考sybase管理手册。
3. update statistics,update all statistics 更新制定索引中键值分布信息和列信息。更新索引或表中所有列的信息。
Update statistics table 更新索引和表中的信息。
4．sp_recompile 让使用该表的存储过程和触发器在下次运行时重新编译。在添加索引或对数据库进行其它影响统计信息的更改时，表的存储过程和触发器可能会失效。通过重新编译可将查询优化到最有效的状态。
sp_recompile tablename 使用该表的存储过程和触发器在下次运行时重新编译。
八.数据库备份和恢复：
备份
添加备份设备：sp_addumpdevice tape, logicalname, physicalname,tapesize
假设添加unix下的备份设备容量为4G，磁带路径为/dev/rmt/c1b0t0l0n
sp_addumpdevice tape,tape,'/dev/rmt/c1b0t0l0n',4000
NT:
1.备份到硬盘 dump database dbname to ‘x:/path/filename’
2.备份到磁带 dump database dbname to ‘//./tape0’ with init,capacity=xxxxx
其中init参数为初始化磁带，capacity为容量。单位为K
3.备份到备份设备tape dump database dbname to tape with init
指定备份设备就不需指定绝对路径和容量
UNIX:
1.备份到硬盘 dump database dbname to ‘/path/filename’
2备份到磁带 dump database dbname to ‘/dev/rmt/tapedevie’ with init,capacity=xxxxx
其中/dev/rmt/tape为unix下磁带设备名。init参数为初始化磁带，capacity为容量。单位为K
恢复：
NT:
1. 从硬盘恢复load database dbname from ‘x:/path/filename’
2. 从磁带恢复 load database dbname from ‘//./tape0’或load database dbname from tape
//./tape0为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
UNIX:
3. 从硬盘恢复load database dbname from ‘/path/filename’
4. 从磁带恢复 load database dbname from ‘/dev/rmt/cxbxtxlx’或load database dbname from tape
/dev/rmt/cxbxtxlx 为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
九．一些可能出现的问题及相应措施
1． Dbcc在数据库活动频繁时执行可能会报告索引损坏。此时并不一定真是索引有问题，可能只是因为checkpoint未执行导致缓存中的页同磁盘页不一致，先checkpoint看能否解决问题，如果不行的话再执行dbcc reindex （table_name）一般来说就可以解决的。如果还不行的话看是否需要将索引删除再重建。还有一个办法就是将表中的资料bcp out后再创建table将资料bcp进去。
2． Sybase 12.0的backup好象有bug，在不同dbid的情况下load数据库可能在dbcc checkcatalog时报告12945的错误。一般来说不会真的有资料参照性错误只是一个假像而以。对于此错误请备份数据库后手动更新sysreferences将错误的参照关系修改过来再重新测试应用有否出错。
3． Sybase 12.5的版本可能会在前端程序执行时报告21的错误，在sybase errorlog中的错误号码为1265，这其实也是sybase的一个bug，可以在sybase启动时加上2808的traceflag来避免此问题。但traceflag 2808可能会引起轻微的性能下降。
十．其它的一些性能调整工具
1.optdiag 用来显示systabstats和systatistics的统计信息。
用optdiag可以观察表的统计信息例如大I/O效率，统计信息是否需要更新等等。
2．dbcc traceon(3604,310,302)可以报告优化程序对查询所作的最终决定不合适。例如索引的选择等等。
3．set statitstics (io,subquerycache,time) on 检查I/O，自查询缓存等等信息。
4．Set showplan,sp_showplan,dbcc sqltext 显示批处理中每个查询的执行步骤，查询所用的键和索引，连接顺序和特殊优化查询。
5. free,vmstat,iostat,sar等os工具分析系统状况。
参考<