Sybase 安装及系统管理(下)
2007-07-20 21:26:35 来源:WEB开发网五.内存使用
充裕的内存可以减少磁盘IO,在数据库系统中磁盘IO是极其昂贵的开销。当用户访问资料时如果在缓存中能够找到的话称之为“逻辑IO“,否则从磁盘读取称之为“物理IO“....
五.内存使用
充裕的内存可以减少磁盘IO,在数据库系统中磁盘IO是极其昂贵的开销。当用户访问资料时如果在缓存中能够找到的话称之为“逻辑IO“,否则从磁盘读取称之为“物理IO“
内存问题大致是以下几个方面:
1.总的数据高速缓存太小。
2.过程高速缓存太小。
3.在SMP系统中只配置了缺省高速缓存,导致对高速缓存的争用。
4.高速缓存大小不适用于特殊的应用。
5.IO大小不适用于特定的应用。
高速缓存分类:
1. 数据高速缓存。用于数据,索引和日志页
2. 过程高速缓存。用于存储过程和触发器以满足短期内存需求。
确定过程高速缓存的大小可用以下办法实现:
过程高速缓存大小=最大用户并发数目*最大的计划大小*1.25
具体如下:在使用一段时间的服务器上用dbcctraceon(3604)将信息写到屏幕,然后运行dbcc memusage确定最大的查询计划的大小,然后根据应用确定并发用户数量就可以大约得到高速缓存的大小了。其实在我们的ERP应用中最大的计划所需内存在450K左右,所以,一般来说,过程高速缓存的大小到100M肯定是够用的,并且当过程高速缓存不够时会有701的错误发生。
Sybasedefault只有”default data cache”,并且只有一个2K的缓冲池,对于大多数的情况这都是不适合的,我们需要建立命名高速缓存并将对象绑定到高速缓存。
Sybase支持的缓冲池大小有2K,4K,8K,16K。给tempdb建立单独的命名高速缓存,并合理分配缓冲池,一般4K的logIO的大小能够得到比较好的性能。在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并不能提供完全正确的资料,例如采样时间太长或者太短。
DataCache 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 prefetchlimit所影响)
APF Reused overloads (由于页链扭结或因APF引入的缓冲区在被使用前换出而使APF被拒绝)
APF buffers found incache (报告在资料高速缓存中找到的来自APF预先设置的缓冲区数量。异步预取使用快速扫描在资料高速缓存中尝试查找其需要的页,而不持有高速缓存螺旋锁。如果此操作不成功,则持有螺旋锁全面扫描)
Other asynchronousprefetch statistics
APF used (报告由异步预取引入高速缓存并在采样期间使用的页数)
APF wait for I/O (一个进程被迫等待异步预取完成的次数。这表示欲取未能及时发生,从而使页未能在查询前位于高速缓存中。此值有一定百分比是合理的,原因如下:
1. 第一个预取请求肯定需要等待
2. 顺序扫描到新的分配单元并发出预取请求是,查询需要等待直到第一个I/O完成
3. 每次费集群索引扫描找到一组限定行并发出预取请求时,需等待第一页返回。其它可能的影响包括每页上需要完成的处理数量及I/O系统速度。
APF Discard (异步预取读入并在使用他们之前放弃的页数。如果此值较大可能表示增加缓冲池大小能有助于提升性能。也可能表示APF正将页引入到查询不需要的高速缓存中)
Cache Management by Cache
Cache search , hitand miss information (缓存命中次数基本等于statistics io的逻辑读次数,未命中次数等于物理读次数。但sp_sysmon输出的值总是大于statisticsio的次数,因为其包含系统表io,日志页和OAM页同其它系统开销。如果命中率很高添加内存可能对性能提升没有太大作用)
Found in wash (在高速缓存中的清洗部分找到所需要的页的次数。如果清洗部分高速缓存命中百分比很高,可能意味着清洗区过大。对于只读或写操作次数较低的高速缓存并不是问题)
(较大的清洗部分会导致物理IO的增加,因为在他们通过清洗标记时ASE启动所有脏页中的写操作。如果清洗区中的页写到磁盘并进行第二次更新则是浪费io。如果必要,可更改清洗区大小。如果减小清洗区大小,可在完全负载的情况下再次sp_sysmon并检查值大于0的”Grabbeddirty“的输出。)
Cache misses (报告在一个高速缓存中未找到所需页而从磁盘读取的次数)
Pool turnover (缓冲区周转。报告从高速缓存中每个池替换缓冲区的次数,此信息可帮助确定池和高速缓存大小是否合适)
LRU buffers Grab(LRU缓存争夺。”LRU buffers grab”仅在一页代替另一页时才替增。如果内存池对吞吐量来说太小,则可能会有这样的结果:池中周转率很高,高速缓存命中率降低及I/O增加。如果某些池中周转率很高而其它池中却很低,也许希望将活动性低的池中的空间移动到活动性高的池中,尤其在能够提高缓存命中率的情况下。)
(如果池中有1000个池而ASE每秒替换100个缓冲区,则每秒有10%的缓冲区在周转。这也许说明缓冲区在高速缓存中停留的时间不足以使对象有机会使用此高速缓存)
Grabbed dirty ( 写入磁盘前到达LRU的脏缓冲区数量的统计信息。当ASE需要从高速缓存的LRU端争夺一个缓冲区用以从磁盘读取一页,却找到一个脏缓冲区而不是干净缓冲区时他必须等待脏缓冲区I/O完成。)
(如果grabbeddirty非0,表示对于池中的吞吐量来说池的清洗区太小。补救措施取决于池的配置和使用情况:
1. 如果池很大且用于大量资料更新操作则应增加清洗区大小
2. 如果有几个对象使用此高速缓存,将其中一些对象移动到其它高速缓存中能够有所帮助
3. 如果高速缓存正由create index使用则高I/O率可引起脏缓冲区争夺,尤其在较小的16K池中。此情况下,可将其清洗区设置尽可能大,可达池中缓冲区的80%
4. 如果池非常小且周转率非常高则应考虑增加池和清洗区大小
5. 高速缓存已分区的话应减少分区数量
6. 检查查询计划和对象I/O统计信息,此对象使用高速缓存进行能够在池中执行许多物理I/O的查询。通过添加索引尽可能对查询进行优化。在“bufferwash behavior”部分检查“buffers already I/O”和”buffers washed dirty”的”per second”值。清洗区应足够大以允许I/O在到达LRU前能够在脏缓冲区完成。需要I/O的时间取决于磁盘驱动器完成的每秒时既物理写操作次数。也要检查“diskI/O management”以确认I/O争用是否减慢磁盘写操作。另外增加“housekeeper free write percent”也会有所帮助。
Buffer wash behavior (缓存清洗行为。报告缓冲区在到达池的清洗标记时的状
态信息。但缓冲区到达清洗标志时可能是以下三种情形之一:
1.“buffers passed clean”报告通过清洗标记的缓冲区数量。
缓冲区在高速缓存中是不进行修改,或进行了修改而且已经有管家任务或检查点写入到磁盘。“% oftotal”报告清理干净缓冲区占通过清洗标记的缓冲区总数的百分比。
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(报告使用读取和放弃此略的情况下放置在清洗标记区处的缓冲区数量)
如果希望整张表进行高速缓存,但“discaredbuffers”的值很高,可使用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总数是否减少。当16KI/O被拒绝是并不检查8K和4K池,但使用2K池。
可使用这个部分和”Pool turnover”帮助判断正确的池大小。)
Large I/O detail (大I/O详情。例如:查询执行一个16K的I/O并读取整个单个资料页,则“pagescache”为8,“pages used”为1)
Pages by LRG I/Ocached (读入高速缓存的页总数)
Pages by LRG I/Oused (在高速缓存中时由查询使用的页数)
Dirty read behavior (在隔离级别0时请求的平均页数。“dirty read page request”的”%of total”报告脏读数相对于页读总次数的百分比)
Procedure cache management (过程高速缓存管理)
Procedure requests(报告存储过程执行的次数。包括
1. 内存中存在查询计划空闲副本,因此可复制和使用。
2. 内存中无过程副本,或内存中计划的所有副本都在用,因此必须从磁盘读取。)
procedure readsfrom disk (存储过程从磁盘读取的次数而不是在过程高速缓存中找到和复制的次数)
procedure writesto disk (报告采样期间创建的过程数量,如果应用程序生成过程此值会很大。)
procedureremovals (报告高速缓存中老化的次数。)
Recovery management (显示常规检查点进程引起的检查点数量,由管家任务启动的检查点数量和每个类型的时间平均长度。此信息有助于正确设定恢复参数和管家参数。)
Checkpoints (检查点将脏页写入到数据库设备中,ASE的常规检查点机制运行以保持最小恢复间隔。通过从执行最后的检查点开始跟踪事务日志中的日志纪录数,可估计出恢复事务需要的时间是否超出恢复间隔。如果这样,检查点进程扫描所有数据高速缓存并写出所有已更改的数据页。
ASE没有要处理的用户任务时,管家任务开始将脏缓冲区写入磁盘。这些写操作在服务器空闲周期内执行,所以称之为“freewrites”。他提高CPU利用率并降低了事务处理中清洗缓冲区的要求。
如果管家进程完成了将所有脏页写入磁盘的操作,则检查点事务日志中起始于最后检查点的行数。如果日志纪录超过100行,则发出一个检查点,称之为“freecheckpoints”。因此它只需要很小的开销。另外也减少了常规检查点未来的开销。)
Normal of freecheckpoints (报告常规检查点进程执行的检查点数量。如果常规检查点执行大多数工作,特别是如果要很长时间,可考虑增加由管家任务执行的写操作次数。)
Number of freecheckpoints (报告由管家任务执行的检查点数量。管家任务仅在完成从所有配置的高速缓存中清除所有脏页后才执行检查点。可用”housekeeperfree write percent”参数配置最大百分比,如此管家任务可增加数据库的写操作。)
Total checkpoints(采样期间发生的常规和自由检查点的总数量。)
Average time pernormal checkpoint(报告常规检查点持续的平均时间。)
Average time perfree checkpoint(自由检查点持续的平均时间)
Increasing thehousekeeper batch limit(管家任务就有内置批处理限制以避免单个设备磁盘I/O过载。缺省情况下,管家任务操作批处理大小设置为3。管家检测到已发出3个I/O到单个设备后立即停止当前缓冲池的写操作,并开始检查其它池中的脏页。如果写操作从下一池转到相同设备,则移动到另一池。检查晚所有吃后开始等待直到由他发出的最后的I/O完成,然后再开始下一循环。
缺省批处理限制是为了速度较慢的磁盘提供较好的I/O特性而设计。通过加快磁盘驱动器的批量大小会获得较好的性能。可为服务器上的所有设备进行全局设定次限制或为单个不同速度的磁盘设置不同的限制值。每次ASE重启后需要重新设定此限制。
单个设备设置批处理限制“dbcc tune(deviochar,vdevno,”10”)
更改所有设备的批处理大小,可用-l代替设备号“dbcctune (deviocha,-l,”10”)
批量大小合法值为1-255,对于速度较快的磁盘,将批量大小设定为50可在测试过程中提高性能。
以下情况可尝试设定批量大小:
1. 常规检查点的平均时间很长
2. 超过I/O配置限制或出现对设备信号的争用不会出现任何问题。
Disk I/O management(报告磁盘I/O。描述服务器磁盘I/O活动并报告每个逻辑设备的读写与信号争用。)
Maximum outstandingI/Os。(报告ASE整体上待执行I/O的最大数量,以及Ase引擎在采样期间在任一点上待执行的I/O最大数量。)
I/Os delayed by (I/O 延迟原因)
Disk I/Ostructures (报告因达到磁盘I/O结构限制而延迟的I/O数量。当超出可用磁盘I/O控制块数量时,I/O被延迟。因ASE要求任务应在启动I/O请求前获得I/O控制块。“diski/o structures”改善。)
Server configurationlimit (ASE超出异步磁盘I/O请求数量的限制,而这些请求对于整个ASE来说可能同时处于未完成状态。可用”max async I/O perserver”改善。)
Engine configurationlimit(引擎超出未完成异步I/O请求的限制。使用”max async I/Os per engine”参数改善。)
Operation systemlimit (报告在采样间隔期间超出对未完成异步I/O的操作系统限制的次数。OS内核限制,进程或者整个系统在任何同一时间内处于待执行状态的异步I/O最大数目。)
Total request disk I/Os和total completedI/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 receivedper packet (采样期间接收的所有信息包平均大小。)
Average bytes sent perpacket (发送信息包平均大小。)
关于减少信息包开销:应用使用存储过程可通过关闭某种TDS的消息提高吞吐量,该TDS消息是在存储过程中执行的每个select语句之后发送的消息。此消息(donein proc)用于某些客户端产品。在某些情况下,关闭(done in proc)也关闭“rows returned”消息。这些消息可能在某些client-library程序中出现,但许多客户端只是简单放弃了这些结果。测试客户端产品和openclient程序的设置,以便在生产系统中禁用此消息之前确定是否有影响。
关闭(done in proc)可在某些环境中略微提高吞吐量,特别是速度较慢或过载网络中,但在其它环境也可能没有任何效果。
关闭消息:dbcctune (doneinproc,0)
开启消息:dbcc tune (doneinproc,1)此命令必须在每次重启时发出。
七.用户数据库的完整性和性能管理:
数据库完整性:
1页级和行级的页链和资料指针用dbcc checkstorage,dbcc checktable,
dbcc checkdb
dbcc checkdb (dbname) 数据库级检测
dbcc checktable (tablename) 表级检测
2.检查页分配用 dbcc checkstorag, dbcccheckalloc, dbcc checkverif, dbcc tablealloc, dbcc indexalloc
3.dbcccheckcatalog (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_addumpdevicetape,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’ withinit,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 fromtape
\.\tape0为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
UNIX:
3. 从硬盘恢复load database dbname from ‘/path/filename’
4. 从磁带恢复 load database dbname from ‘/dev/rmt/cxbxtxlx’或load database dbnamefrom tape
/dev/rmt/cxbxtxlx为未添加到sybase的备份设备名
tape为添加到sybase的备份设备名
九.一些可能出现的问题及相应措施
1. Dbcc在数据库活动频繁时执行可能会报告索引损坏。此时并不一定真是索引有问题,可能只是因为checkpoint未执行导致缓存中的页同磁盘页不一致,先checkpoint看能否解决问题,如果不行的话再执行dbccreindex (table_name)一般来说就可以解决的。如果还不行的话看是否需要将索引删除再重建。还有一个办法就是将表中的资料bcp out后再创建table将资料bcp进去。