sybase系统配置祥解

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环境更是如此）
四.关于性能优化
好的性能同优良的数据库设计及优秀的程序写法关系极大，可以这样说，如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。

在/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．检查是否存在并发问题。