sybase性能优化的建议
- 格式:doc
- 大小:28.00 KB
- 文档页数:1
sybase数据库慢的请留意数据库系统在当今的信息技术领域中发挥着重要作用,为各种应用程序的数据存储和管理提供支持。
然而,有时候我们可能会遇到Sybase数据库运行缓慢的问题。
本文将讨论一些可能导致Sybase数据库变慢的原因,并提供一些解决方案和优化策略。
一、索引设计不合理索引在数据库中起到加速查询操作的作用。
然而,当索引设计不合理时,可能会导致数据库查询变慢。
比如,过多的索引会增加数据库维护的负担,而过少的索引则会导致查询性能下降。
解决方案:对数据库进行分析,评估每个表的查询模式和频率,并根据这些信息,合理地设计索引。
避免创建过多冗余的索引,以免影响数据库性能。
二、存储空间不足Sybase数据库的存储空间管理对数据库的性能和稳定运行至关重要。
当存储空间不足时,数据库的读写操作会变慢。
此外,如果没有进行定期的空间清理,数据库中存储的日志文件会不断增长,进一步导致数据库性能下降。
解决方案:定期监控数据库的存储空间使用情况,合理规划并扩展存储空间。
同时,设置定期的空间清理任务,删除过期的日志文件等。
三、查询语句不优化编写高效的查询语句是提高数据库性能的关键。
当查询语句没有经过充分优化时,可能会导致数据库响应变慢。
解决方案:对于复杂的查询语句,使用Sybase提供的查询优化工具(如Explain Plan)进行分析,找出影响查询性能的因素,并进行优化。
避免使用不必要的子查询或者多次嵌套的查询操作。
四、硬件性能问题数据库的性能受到硬件的限制。
如果数据库运行在低配置的硬件环境下,可能会导致数据库响应变慢。
解决方案:评估数据库运行所在的硬件环境,确保硬件配置满足数据库的需要。
如果硬件配置有限,可以考虑升级硬件或者将数据库迁移到更高配置的服务器上。
五、数据库统计信息不准确数据库需要根据统计信息来优化查询执行计划。
如果数据库的统计信息不准确或者过期,会导致数据库查询慢。
解决方案:定期更新数据库的统计信息,以提高查询的准确性和效率。
SYBASE系统参数调整1. max memory:此参数用于指定SYBASE数据库服务器在计算机中使用的最大内存量。
通过将此参数设置为较大的值,可以提高该数据库服务器的性能。
如果可用的内存较少,则应适当减小此值。
2. number of engines:此参数用于指定SYBASE数据库服务器使用的引擎数量。
增加此参数的值可以提高并发访问性能。
然而,将该值设置得太高可能会浪费资源。
一般来说,使用与服务器CPU数量相同的值是安全的做法。
3. max scan parallel degree:此参数用于指定SYBASE数据库服务器执行并行扫描时使用的最大并行度。
通过将此参数设置为较大的值,可以提高并行扫描的性能。
4. sys statistics:此参数用于指定数据库服务器在自动生成查询计划时使用的统计信息的有效期限。
适当设置此参数的值可以提高查询性能。
默认情况下,此参数的值设置为30天。
5. max degree of parallelism:此参数用于指定SYBASE数据库服务器在执行并行查询时使用的最大并行度。
增加此参数的值可以提高查询性能。
然而,将该值设置得太高可能会增加系统负载。
6. max worker processes:此参数用于指定SYBASE数据库服务器使用的最大工作进程数量。
适当增加此参数的值可以提高并发性能。
默认情况下,此参数的值设置为255,但在大型服务器上,可能需要适当增加此值。
7. tempdb设备数:tempdb是SYBASE数据库服务器用于处理临时数据的数据库。
将tempdb数据库分配到多个设备上可以提高临时数据处理的性能。
8. prefetch parallel degree:此参数用于指定SYBASE数据库服务器在执行预取操作时使用的并行度。
适当增加此参数的值可以提高查询性能。
9. max rows per stack:此参数用于指定SYBASE数据库服务器在语句执行期间允许的最大行数。
ASE性能调优简易实验手册1,实验环境准备确定已经安装ASE15.01)安装实验文件;edb553 setup.exe解压到目标路径2)进入目标文件夹: cd C:\Sybase Courses\edb553\scripts\windows,查看对应文件:.bat; .bcp, .sql 三种类型文件3)执行文件:ptconfig150_setup.bat,初始化相关的设备,创建调优的实验数据库pubtune_db4)登录到server,查看所安装设备,数据库 sp_helpdevice , sp_helpdb3,调优工具箱1)建立一个benchmark,熟悉各调优工具同时开两个命令行窗口,在其中一个查看并执行mixed_load.bat ,mixed_load.bat bench模拟多个客户端同时登录时的操作,同时使用sp_sysmon监控运行状态,各客户端记录和sp_sysmon报告分别输出到对应名称文件。
另一个用sa登录到server,使用sp_who查看客户端登录和事务执行情况。
等所有客户端都执行完之后,查看所有的输出文件。
其中sp_sysmon输出的文件即为调优使用的 benchmark.2) 熟悉其他的工具-- 工具类1) Isql –p 查看执行时间Use pubtune_dbGoSelect * from titlesGo 1002)optdiag 查看表和索引的统计信息Optdiag statistics pubtune_db..space_table1 -Usa -P---set命令1)set statistics io on 某个语句的读写操作数目统计Use pubtune_dbGoSelect * from authorsGo2) set statistics time on 查看执行时间goSelect * from authorsgo3)set showplan ,noexec on 查看查询计划Select * from authorsGo--系统过程类1)进程行为类Sp_who,查看当前进程活动情况Sp_lock 查看锁的情况Sp_showplan 查看当前在执行进程的查询计划2)空间使用情况Sp_spaceused authors 对于给定表查看空间使用情况Sp_helppartition 对于分区表查看相关信息Sp_estspace authors, 1000 预估表占用的空间Sp_helpsegment 产看段的信息Sp_helpcache 查看高速缓存结构和绑定的对象信息3)配置情况Sp_configure 查看修改系统配置参数Sp_cacheconfig 创建命名缓存Sp_poolconfig 在数据缓存中创建大的缓冲池4)任务行为Sp_sysmon 监控cpu忙碌状态,网络包收发情况,磁盘读写情况Sp_monitor 对系统行为按给定时间间隔采样,报告各方面行为指标4,锁机制查看配置的锁数目对事务的影响,以及各种模式的锁对事务的影响查看系统配置的锁个数(缺省5000)sp_configure "number of locks".Use pubtune_dbGo1)行锁创建行锁表create table x (c char(1)) lock datarowsgo开始事务begin transelect @@trancount (结果返回1证明事务已经开始)go向表中插入值,执行4000次insert x values ("a")go 4000同时在另外窗口查询锁的情况 Sp_lock再次插入2000行数据insert x values ("a")go 2000再次在另外窗口查询锁的情况sp_lock锁不够,事务自动回滚。
接下来的这些条目是INFOR MATICA 的高级调优建议。
请极其谨慎地处理,每次试用一条建议。
在没有试着使用初级和中级建议来提高INFORMATICA 的性能以前,不要尝试使用如下的高级建议。
这些建议的实施可能需要系统管理员(SA)、数据库管理员(DBA)以及网络管理员之类的专家级人物的配合才可以,所以要细心。
高级调优最重要的方面就是能够精确的查明瓶颈是什么,并且有能力定位这些瓶颈是如何引起的。
根据常理,这些高级建议放在最后,并且是在系统级上的建议。
还有其他的适用于数据仓库调优的高级建议,可以依据你的软硬件资源存在的问题去寻找相应的帮助。
1、将MAPPING 分解。
保留一个数据目标。
如果必要每个数据目标保留一个数据源。
为什么要这么做呢?在一个MAPPING 中减少数据目标的个数会大幅度的提高运行的速度。
基本的情况是这样的:每个MAPPING/TARGET 对应一个SESSION。
每个SESSION 都会建立它自己的数据库连接。
因为对每个目标表建立一个单独的数据库连接,数据库管理器(DBMS)能将插入、更新和删除等操作需求并行地处理。
在一个SESSION 中进行一个特定目的的操作也是很有帮助的(例如不在把以数据驱动地操作和直接插入操作混合地插入到同一个数据目标中)。
如果实际情况运行, 每个SESSION 可以被放置到标记为“CONCURRENT”的BATCH(译者注:旧版本的术语)中。
如果能够这样做,MAPPING和SESSION 的并行执行的情况就很显而易见了。
关于并行处理的研究一再地表明:与直接将原本的操作单元简单地顺序执行相比,同一时刻开始的并行执行有时只需花费一半的时间。
当一个MAPPING 中包含多个数据目标时,就会使得每个数据库连接去处理多个不同地数据库操作语句,有时会影响这个数据目标的性能,有时又是那个。
请想一下,在这情况下,INFORMATICA(包括其他的任何工具)都很难进行BULK(并行)操作,即使在SESSION中已经设定了BULK 属性。
最近优化了两个单位的数据库,通过跟踪后SYBASE都建议将命名Cache的cache replacement policy改为relaxed LRU replacement。
经过在这两个数据库的表现来看,的确获得了一定的效果,我觉得可能目前使用CACHE 的单位都会存在这么个问题,现将有关过程写一下与大家共享:
1、通过sp_sysmon ’00:05:00’得到连续5分钟内SYBASE 性能监控信息,分析SYBASE给出的
建议;
2、若有对命名Cache的优化建议,多数会建议使用relaxed LRU replacement;再有某些会
要求使用大I/O;修改方法可以是直接修改SYBASE.cfg文件中的相关内容,以ACCBJE_cache为例如下:
[Named Cache:ACCBJE_cache]
cache size = 16M
cache status = mixed cache
cache replacement policy = relaxed LRU replacement //直接将DEFAULT或其他任何内容为改为relaxed LRU replacement 即可
local cache partition number = DEFAULT
3、检查某些number of xxxx参数,有些设置的太大,可能没必要,比如锁,我认为几万可
能就能满足了,太大可能会占用太多内存(当然也可能是只有真正有那么多锁时才会占用,这点我没有确认),我所优化的这几个数据库开始都是几十万,可能完全没有必要。
另外,对于性能问题来说,通过sp_sysmon会得到很多信息,大家可以通过自己分析查找问题原因。
通过在wisql中,先执行dbcc traceon(3604)后,再执行dbcc sqltext(进程ID)可以得到该进程正在执行的SQL语句,对于查找问题也会有帮助,不过这个有时得到的SQL不全,不过可以作为参考了。