sybase技术总结.docx
《sybase技术总结.docx》由会员分享，可在线阅读，更多相关《sybase技术总结.docx（24页珍藏版）》请在冰豆网上搜索。
sybase技术总结
这是我很久以前做的一个Sybase培训手册，大家可以看看！
Sybase安装及系统管理
一.关于设备：
RAWDevice（裸分区）VSFilesystemDevice
裸分区是指磁盘的一块物理分区，没有用作操作系统，其读写不通过操作系统缓冲。
传统的Unix安装ASE推荐使用RAWDevice确保资料的完整性和较好的IO性能。
但在新版的Unix和Linux中UFS和JFS在资料完整性和读写性能的差距相较于裸设备已经非常微弱。
还有就是裸设备的管理比较复杂。
从ASE12.0开始Sybase提供dsync的属性对数据库设备禁止write-cache（写回缓冲）以确保资料的完整性和可恢复性。
裸设备的使用出于安全和资料完整性方面的考虑比性能考虑多。
AsyncI/O（异步I/O）
异步IO是在一个IO动作未完成时同时可进行另外的动作。
异步IO对于数据库的IO性能有较大的影响。
在AIX和HP中都需要通过重新编译内核来支持。
二.关于内存：
首先确定可用的总的物理内存然后减去操作系统，Backup,Monitor等Sybase相关软件的开销即为Sybase总的可用内存。
（建议服务器只做单纯的ASE服务器并要删除不必要的服务以减少开销，例如xwindow）
在Unix及Linux中需要调整一些核心参数以支持较大的物理内存。
以下列出一些可能需要调整的参数：
shmmax（最大共享内存段大小,单位为字节），
shmall（可用内存的总数量，如果是字节同shmmax一样）。
其余的像shmmin等参数请参考操作系统手册。
Sybase利用maxmemory确定最大可用内存量，具体内存的分配方式取决于以下两个参数allocatemaxsharedmemory和dynamicallocationondemand。
Allocatemaxsharedmemory指定是否分配由maxmemory指定的最大内存，缺省不分配最大内存。
Dynamicallocationondemand指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配。
例如配置了用户连接数量只在用户连接到Sybase时才分配内存。
三.参数设定：
（分组并只对常用参数进行说明）
1．PhysicalMemory：
allocatemaxsharedmemory（指定是否分配由maxmemory指定的最大内存，缺省不分配最大内存）
dynamicallocationondemand（指定是否在请求时立即分配资源还是仅需要时分配，缺省是需要时分配）
maxmemory（确定Sybase最大可用内存）
totallogicalmemory（当前配置的逻辑内存，只读）
totalphysicalmemory（当前配置的物理内存，只读）
2．DiskI/O（磁盘IO）
allowsqlserverasynci/o（允许SQLServer进行异步IO，此参数对于设备的IO性能有极大影响，需要操作系统支持）
diski/ostructures（磁盘IO结构，启动时分配磁盘IO控制块的数目.。
将此值设定为操作系统允许的最大值以避免磁盘IO结构不够用的情况）
numberofdevices（Sybase所能使用的最大设备数目）
pageutilizationpercent（页利用率）
3．Meta-DataCaches（元资料缓存）
numberofopendatabases（可同时打开的数目库数目）
numberofopenindexes（可同时使用的索引数目）
numberofopenobjects（可同时使用的对象数目）
以上三个参数都可用sp_countmetadata来确定当前Sybase中三个参数的大小。
调整后可在实际的使用过程中利用sp_sysmon来确定是否设定合理）
4．ParallelQuery（并行查询）
numberofworkerprocesses（同时可使用的并行查询的可用的工作进程数目）
maxparalleldegree（最大的查询并行程度）
maxscanparalleldegree（最大的扫描并行程度，一般的磁盘控制器使用2~3个工作进程就可以充分利用其IO）
5.Processors（处理器）
maxonlineengines（最大的在线引擎数目，一个引擎可以理解为一个CPU的处理能力，不可大于操作系统可用的CPU个数）
numberofenginesatstartup（Sybase启动时需要联机的引擎数目）
6.LockManager（锁管理）
lockscheme（锁定方案,缺省为allpages,从ASE1192开始提供datarows的锁方案。
利用行锁可以大大提升并发性能，但需要更多的锁，并且会有资料页产生较多空页困扰）
numberoflocks（可用的锁数目，此参数可能需要在使用过程中进行调整以适用不同的应用环境）
printdeadlockinformation（打印死锁信息到日志，如果频繁发生死锁可打开此参数用来确定起因，但此参数会带来额外的开销，在SMP环境更是如此）
四.关于性能优化
好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。
在
对于系统管理所能够做的就是减少IO，缩短响应时间。
在性能优化方面程序员同DBA的工作有时是重叠的，例如，判断索引是否必须，索引类型是否正确。
监视数据库的运行判断是否优化!
总的来说，性能的提升就是缩短响应时间和提高吞吐量。
Sybase的查询优化是基于开销的计算的。
索引的使用可以：
1．避免表扫描。
2．点查询中定位包含特定资料的特定资料页。
3．范围查询确定上下限。
4．索引覆盖，完全避免存取数据页。
5．连接时避免排序。
建立索引的注意事项：
1．Unique和primarykey可以创建唯一索引，缺省情况下unique创建nonclustered，primarykey创建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．延迟死锁检测，”deadlockcheckingperiod”指定开始检查死锁前进程必须等待的毫秒数。
6．使用应用程序的最低锁定级。
只在必要时使用隔离级别2或3。
如果仅有几个查询需要级别3则在整个事物中使用holdlock或atisolotion，而不用settransactionisolotionat3。
如果绝大部分的查询需要级别3则使用settransactionisolotionat3，而可以在查询级别1的查询使用holdlock或atisolation。
7．如果需要大量的查询，更新和删除，可通过在存储过程中使用光标频繁提交来减少阻塞。
8．如果应用程序需要返回一行，等待用户反应然后更新该行，可考虑使用时间戳或者tsequal函数而不要使用holdlock。
9．检查是否存在并发问题。
五．内存使用
充裕的内存可以减少磁盘IO,在数据库系统中磁盘IO是极其昂贵的开销。
当用户访问资料时如果在缓存中能够找到的话称之为“逻辑IO“，否则从磁盘读取称之为“物理IO“内存问题大致是以下几个方面：
1．总的数据高速缓存太小。
2．过程高速缓存太小。
3．在SMP系统中只配置了缺省高速缓存，导致对高速缓存的争用。
4．高速缓存大小不适用于特殊的应用。
5．IO大小不适用于特定的应用。
高速缓存分类：
1．数据高速缓存。
用于数据，索引和日志页
2．过程高速缓存。
用于存储过程和触发器以满足短期内存需求。
确定过程高速缓存的大小可用以下办法实现：
过程高速缓存大小=最大用户并发数目*最大的计划大小*1.25
具体如下：
在使用一段时间的服务器上用dbcctraceon（3604）将信息写到屏幕，然后运行dbccmemusage确定最大的查询计划的大小，然后根据应用确定并发用户数量就可以大约得到高速缓存的大小了。
其实在我们的ERP应用中最大的计划所需内存在450K左右，所以，一般来说，过程高速缓存的大小到100M肯定是够用的，并且当过程高速缓存不够时会有701的错误发生。
Sybasedefault只有”defaultdatacache”，并且只有一个2K的缓冲池，对于大多数的情况这都是不适合的，我们需要建立命名高速缓存并将对象绑定到高速缓存。
Sybase支持的缓冲池大小有2K,4K,8K,16K。
给tempdb建立单独的命名高速缓存，并合理分配缓冲池，一般4K的logIO的大小能够得到比较好的性能。
在SMP的环境中还有一个问题就是螺旋锁的竞争，当用sp_sysmon观察到资料缓存螺旋锁争夺超过10%时就需要分区。
sp_cacheconfig‘cachename’,’cache_partition=X’就可以对缓存进行分区了。
六.sp_sysmon的使用
sp_sysmon是ASE用来监控服务器在特定采样期间内的数据库的活动。
在典型负载情况下能够提供服务器运行状况的描述，是性能调整的重要工具。
以下的一些信息不是同sp_sysmon的输出顺序一样，但需要重点注意，这些信息来自Sybase的性能调整手册，仔细看了后觉得说的很是简洁明白，也就没有加入什么自己的东西了。
其用法很简单，sp_sysmon“HH:
MM:
SS”即可，但sp_sysmon在运行时对性能有影响，特别是在SMP环境下。
还有有时sp_sysmon并不能提供完全正确的资料，例如采样时间太长或者太短。
DataCacheManagement
CacheStatisticsSummary（allcaches）
CacheTurnover（缓存周转）
BuffersGrabbed（缓存抢夺。
所有缓存中替换的缓冲区数量）
BuffersGrabbedDirty（缓存抢夺脏页。
如果此值不为0代表严重性能问题）
LargeI/OEffectiveness（大I/O效率）
PagebyLRGI/Ocached
PagebyLRGI/Oused（此两条信息报告由大I/O引入到高速缓存中及使用的页）
AsynchronousPrefecthActivity（异步预取活动）
APFissued（APF成功应用的次数）
APFDenieddueto（不被大I/O的原因）
APFI/Ooverloads（缺少磁盘I/O结构或者由于磁盘信号争用而被拒绝的次数。
如果因磁盘信号争用而引起检查高I/O发生处的对象物理放置）
APFLimitoverloads（超出可用于异步预取的缓冲池的百分比。
此值由globalasyncprefetchlimit所影响）
APFReusedoverloads（由于页链扭结或因APF引入的缓冲区在被使用前换出而使APF被拒绝）
APFbuffersfoundincache（报告在资料高速缓存中找到的来自APF预先设置的缓冲区数量。
异步预取使用快速扫描在资料高速缓存中尝试查找其需要的页，而不持有高速缓存螺旋锁。
如果此操作不成功，则持有螺旋锁全面扫描）
Otherasynchronousprefetchstatistics
APFused（报告由异步预取引入高速缓存并在采样期间使用的页数）
APFwaitforI/O（一个进程被迫等待异步预取完成的次数。
这表示欲取未能及时发生，从而使页未能在查询前位于高速缓存中。
此值有一定百分比是合理的，原因如下：
1．第一个预取请求肯定需要等待
2．顺序扫描到新的分配单元并发出预取请求是，查询需要等待直到第一个I/O完成
3．每次费集群索引扫描找到一组限定行并发出预取请求时，需等待第一页返回。
其它可能的影响包括每页上需要完成的处理数量及I/O系统速度。
APFDiscard（异步预取读入并在使用他们之前放弃的页数。
如果此值较大可能表示增加缓冲池大小能有助于提升性能。
也可能表示APF正将页引入到查询不需要的高速缓存中）
CacheManagementbyCache
Cachesearch,hitandmissinformation（缓存命中次数基本等于statisticsio的逻辑读次数，未命中次数等于物理读次数。
但sp_sysmon输出的值总是大于statisticsio的次数，因为其包含系统表io,日志页和OAM页同其它系统开销。
如果命中率很高添加内存可能对性能提升没有太大作用）
Foundinwash（在高速缓存中的清洗部分找到所需要的页的次数。
如果清洗部分高速缓存命中百分比很高，可能意味着清洗区过大。
对于只读或写操作次数较低的高速缓存并不是问题）
（较大的清洗部分会导致物理IO的增加，因为在他们通过清洗标记时ASE启动所有脏页中的写操作。
如果清洗区中的页写到磁盘并进行第二次更新则是浪费io。
如果必要，可更改清洗区大小。
如果减小清洗区大小，可在完全负载的情况下再次sp_sysmon并检查值大于0的”Grabbeddirty“的输出。
）
Cachemisses（报告在一个高速缓存中未找到所需页而从磁盘读取的次数）
Poolturnover（缓冲区周转。
报告从高速缓存中每个池替换缓冲区的次数，此信息可帮助确定池和高速缓存大小是否合适）
LRUbuffersGrab（LRU缓存争夺。
”LRUbuffersgrab”仅在一页代替另一页时才替增。
如果内存池对吞吐量来说太小，则可能会有这样的结果：
池中周转率很高，高速缓存命中率降低及I/O增加。
如果某些池中周转率很高而其它池中却很低，也许希望将活动性低的池中的空间移动到活动性高的池中，尤其在能够提高缓存命中率的情况下。
）
（如果池中有1000个池而ASE每秒替换100个缓冲区，则每秒有10%的缓冲区在周转。
这也许说明缓冲区在高速缓存中停留的时间不足以使对象有机会使用此高速缓存）
Grabbeddirty（写入磁盘前到达LRU的脏缓冲区数量的统计信息。
当ASE需要从高速缓存的LRU端争夺一个缓冲区用以从磁盘读取一页，却找到一个脏缓冲区而不是干净缓冲区时他必须等待脏缓冲区I/O完成。
）
（如果grabbeddirty非0，表示对于池中的吞吐量来说池的清洗区太小。
补救措施取决于池的配置和使用情况：
1．如果池很大且用于大量资料更新操作则应增加清洗区大小
2．如果有几个对象使用此高速缓存，将其中一些对象移动到其它高速缓存中能够有所帮助
3．如果高速缓存正由createindex使用则高I/O率可引起脏缓冲区争夺，尤其在较小的16K池中。
此情况下，可将其清洗区设置尽可能大，可达池中缓冲区的80%
4．如果池非常小且周转率非常高则应考虑增加池和清洗区大小
5．高速缓存已分区的话应减少分区数量
6．检查查询计划和对象I/O统计信息，此对象使用高速缓存进行能够在池中执行许多物理I/O的查询。
通过添加索引尽可能对查询进行优化。
在“bufferwashbehavior”部分检查“buffersalreadyI/O”和”bufferswasheddirty”的”persecond”值。
清洗区应足够大以允许I/O在到达LRU前能够在脏缓冲区完成。
需要I/O的时间取决于磁盘驱动器完成的每秒时既物理写操作次数。
也要检查“diskI/Omanagement”以确认I/O争用是否减慢磁盘写操作。
另外增加“housekeeperfreewritepercent”也会有所帮助。
Bufferwashbehavior（缓存清洗行为。
报告缓冲区在到达池的清洗标记时的状
态信息。
但缓冲区到达清洗标志时可能是以下三种情形之一：
1．“bufferspassedclean”报告通过清洗标记的缓冲区数量。
缓冲区在高速缓存中是不进行修改，或进行了修改而且已经有管家任务或检查点写入到磁盘。
“%oftotal”报告清理干净缓冲区占通过清洗标记的缓冲区总数的百分比。
2．“buffersalreadyinI/O“报告I/O在进入清洗区时在缓冲区中已经处于活动的次数。
处在高速缓存中时此页已脏。
管家或检查点已经启动该页中的I/O但I/O还未完成。
“%oftotal”报告已经在I/O中的缓冲区占进入清洗区总数的百分比。
3．“bufferswasheddirty”报告缓冲区进入已脏的清洗区且不在I/O中的次数。
缓冲区在高速缓存中时已修改且未写入磁盘。
异步I/O通过清洗标记时已在页中启动。
Cachestrategy（缓存策略。
报告遵循“读取和放弃“-MRU和常规”最近最少使用”-LRU策略的情况下放置在高速缓存中的缓冲区数目）
Cache（LRU）buffers（报告使用LRU并放置在高速缓存的MRU端的缓冲区数量。
包括直接在磁盘读取并放置在MRU端的所有缓冲区以及在高速缓存中找到的所有缓冲区。
逻辑I/O完成时将缓冲区放置在高速缓存的MRU端）
Discared（MRU）buffers（报告使用读取和放弃此略的情况下放置在清洗标记区处的缓冲区数量）
如果希望整张表进行高速缓存，但“discaredbuffers”的值很高，可使用showplan观察优化程序是否在应该使用LRU时却生成MRU策略。
LargeI/Ousage（大I/O使用）
LargeI/Osperformed（衡量执行的请求的大I/O次数）
LargeI/Osdenied（报告大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总数是否减少。
当16KI/O被拒绝是并不检查8K和4K池，但使用2K池。
可使用这个部分和”Poolturnover”帮助判断正确的池大小。
）
LargeI/Odetail（大I/O详情。
例如：
查询执行一个16K的I/O并读取整个单个资料页，则“pagescache”为8，“pagesused”为1）
PagesbyLRGI/Ocached（读入高速缓存的页总数）
PagesbyLRGI/Oused（在高速缓存中时由查询使用的页数）
Dirtyreadbehavior（在隔离级别0时请求的平均页数。
“dirtyreadpagerequest”的”%oftotal”报告脏读数相对于页读总次数的百分比）
Procedurecachemanagement（过程高速缓存管理）
Procedurerequests（报告存储过程执行的次数。
包括
1．内存中存在查询计划空闲副本，因此可复制和使用。
2．内存中无过程副本，或内存中计划的所有副本都在用，因此必须从磁盘读取。
）
procedurereadsfromdisk（存储过程从磁盘读取的次数而不是在过程高速缓存中找到和复制的次数）
procedurewritestodisk（报告采样期间创建的过程数量，如果应用程序生成过程此值会很大。
）
procedureremovals（报告高速缓存中老化的次数。
）
Recoverymanagement（显示常规检查点进程引起的检查点数量，由管家任务启动的检查点数量和每个类型的时间平均长度。
此信息有助于正确设定恢复参数和管家参数。
）
Checkpoints（检查点将脏页写入到数据库设备中，ASE的常规检查点机制运行以保持最小恢复间隔。
通过从执行最后的检查点开始跟踪事务日志中的日志纪录数，可估计出恢复事务需要的时间是否超出恢复间隔。
如果这样，检查点进程扫描所有数据高速缓存并写出所有已更改的数据页。
ASE没有要处理的用户任务时，管家任务开始将脏缓冲区写入磁盘。
这些写操作在服务器空闲周期内执行，所以称之为“freewrites”。
他提高CPU利用率并降低了事务处理中清洗缓冲区的要求。
如果管家进程完成了将所有脏页写入磁盘的操作，则检查点事务日志中起始于最后检查点的行数。
如果日志纪录超过100行，则发出一个检查点，称之为“freecheckpoints”。
因此它只需要很小的开销。
另外也减少了常规检查点未来的开销。
）
Normaloffreecheckpoints（报告常规检查点进程执行的检查点数量。
如果常规检查点执行大多数工作，特别是如果要很长时间，可考虑增加由管家任务执行的写操作次数。
）
Numberoffreecheckpoints（报告由管家任务执行的检查点数量。
管家任务仅在完成从所有配置的高速缓存中清除所有脏页后才执行检查点。
可用”housekeeperfreewritepercent”参数配置最大百分比，如此管家任务可增加数据库的写操作。
）
Totalcheckpoints（采样期间发生的常规和自由检查点的总数量。
）
Averagetimepernormalcheckpoint（报告常规检查点持续的平均时间。
）
Averagetimeperfreecheckpoint（自由检查点持续的平均时间）
Increasingthehousekeeperbatchlimit（管家任务就有内置批处理限制以避免单个设备磁盘I/O过载。
缺省情况下，管家任务操作批处理大小设置为3。
管家检测到已发出3个I/O到单个设备后立即停止当前缓冲池的写操作，并开始检查其它池中的脏页。
如果写操作从下一池转到相同设备，则移动到另一池。
检查晚所有吃后开始等待直到由他发出的最后的I/O完成，然后再开始下一循环。
缺省批处理限制是为了速度较慢的磁盘提供较好的I/O特性而设计。
通过加快磁盘驱动器的批量大小会获得较好的性能。
可为服务器上的所有设备进行全局设定次限制或为单个不同速度的磁盘设置不同的限制值。
每次ASE重启后需要重新设定此限制。
单个设备设置批处理限制“dbcctune（deviochar,vdevno,”10”）
更改所有设备的批处理大小，可用-l代替设备号“dbcctune（deviocha,-l,”10”）
批量大小合法值为1-255，对于速度较快的磁盘，将批量大小设定为50可在测试过程中提高性能。
以下情况可尝试设定批
升级会员 