WEB开发网      濠电姷鏁告繛鈧繛浣冲洤纾瑰┑鐘宠壘閻ょ偓銇勯幇鍫曟闁稿鍠愰妵鍕冀閵娧佲偓鎺楁⒒閸曨偄顏柡宀嬬畱铻e〒姘煎灡绗戦梻浣筋嚙濮橈箓顢氳濠€浣糕攽閻樿宸ュΔ鐘叉啞缁傚秹宕滆绾惧ジ寮堕崼娑樺缂佹宀搁弻鐔风暋閻楀牆娈楅梺璇″枓閺呯姴鐣疯ぐ鎺濇晝闁靛牆妫欓蹇旂節閻㈤潧浠﹂柛銊ョ埣楠炴劙骞橀鑲╋紱闂佽宕樼粔顔裤亹閹烘挸浜归梺缁樺灦閿曗晛螞閸曨垱鈷戦柟鑲╁仜婵″ジ鎮楀☉鎺撴珖缂侇喖顑呴鍏煎緞濡粯娅囬梻浣瑰缁诲倿寮绘繝鍥ㄦ櫇闁稿本绋撻崢鐢告煟鎼淬垻鈯曢柨姘舵煟韫囥儳绋荤紒缁樼箖缁绘繈宕橀妸褌绱濋梻浣筋嚃閸ㄤ即宕弶鎴犳殾闁绘梻鈷堥弫鍌炴煕閳锯偓閺呮瑧妲愬Ο琛℃斀闁绘劕妯婇崵鐔封攽椤旇棄鍔ら摶鐐烘煕閺囥劌澧柛娆忕箻閺屽秹宕崟顒€娅g紓浣插亾濠㈣泛顑囩粻楣冩煙鐎涙ḿ绠橀柨娑樼У椤ㄣ儵鎮欓鍕紙闂佽鍠栫紞濠傜暦閹偊妲诲┑鈩冨絻椤兘寮诲☉銏犖╅柕澶堝労閸斿绱撴担绋库偓鍝ョ矓瑜版帒鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘 ---闂傚倸鍊烽悞锔锯偓绗涘厾娲煛閸涱厾顔嗛梺璺ㄥ櫐閹凤拷
开发学院数据库DB2 针对基础设计、性能和可管理性的DB2最佳实践 阅读

针对基础设计、性能和可管理性的DB2最佳实践

 2010-05-14 15:00:37 来源:WEB开发网 闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�闂傚倸鍊风粈渚€骞夐敓鐘插瀭闁汇垹鐏氬畷鏌ユ煙閹殿喖顣奸柛搴$У閵囧嫰骞掗幋婵冨亾閻㈢ǹ纾婚柟鐐灱濡插牊绻涢崱妤冃℃繛宀婁簽缁辨捇宕掑鎵佹瀸闂佺懓鍤栭幏锟�濠电姷鏁告慨顓㈠箯閸愵喖宸濇い鎾寸箘閹规洟姊绘笟鈧ḿ褍煤閵堝悿娲Ω閳轰胶鍔﹀銈嗗笂閼冲爼鍩婇弴銏$厪闁搞儮鏅涙禒褏绱掓潏鈺佷槐闁轰焦鎹囬弫鎾绘晸閿燂拷闂傚倸鍊风欢姘缚瑜嶈灋闁圭虎鍠栫粻顖炴煥閻曞倹瀚�  闂傚倸鍊烽懗鑸电仚缂備胶绮〃鍛村煝瀹ュ鍗抽柕蹇曞У閻庮剟姊虹紒妯哄闁诲繑姘ㄩ埀顒佸嚬閸撶喎顫忓ú顏勫瀭妞ゆ洖鎳庨崜浼存⒑闁偛鑻晶顔剧磼婢跺﹦绉虹€殿喖顭锋俊姝岊槷闁稿鎹囧Λ鍐ㄢ槈濞嗗繑娈橀梻浣风串缂嶁偓濞存粠鍓熼崺鈧い鎺戝€归弳顒勬煕鐎n亷韬€规洑鍗冲鍊燁槾闁哄棴绠撻弻銊╂偆閸屾稑顏�
核心提示:数据库配置从 AUTOCONFIGURE 开始:配置数据库的一个好起点是使用 Configuration Advisor 或者 AUTOCONFIGURE 命令,决定配置参数时,针对基础设计、性能和可管理性的DB2最佳实践(2),必须了解如何使用数据库,以及与正在配置的数据库相关的应用程序有什么样的性能需求,请谨慎使用

数据库配置

从 AUTOCONFIGURE 开始:配置数据库的一个好起点是使用 Configuration Advisor 或者 AUTOCONFIGURE 命令。决定配置参数时,必须了解如何使用数据库,以及与正在配置的数据库相关的应用程序有什么样的性能需求。

尽可能使用自动设置:许多配置参数都可以设置为自动。当设置为自动时,DB2 自动调整这些参数,以满足系统当前的资源需求。

根据需要调整重要参数:根据特定系统的需求,当决定调整初始数据库配置时,有一些重要因素需要考虑:

用 DB2 创建的默认数据库拥有一个 4K 页面大小的表空间。最低限度情况下,应该创建一个 32K 页面大小的缓冲池,一个 32K 页面大小的系统临时表空间,以及一个 32K 页面大小的用户表空间。这样可以确保能够在 32K 页面大小的表空间中创建任何行大小超过 4K 字节的用户表。

对于一般的产品系统来说,缓冲池的初始配置值简直太小了。为缓冲池分配更多的内存空间在大多数情况下都是有好处的,DB2 的默认值只能当作最小值。在 DB2 9 中,借助自调优内存管理器(self tuning memory manager,STMM)(将会在 运行时和可管理性技巧 小节中介绍),DB2 可以决定最佳的缓冲池值。

对于 DB2 Version 8,默认的锁列表大小(用于锁的内存堆)为 100 个 4K 的缓冲区。即使对于只涉及少量连接和数据的低级测试,这都会引起从行锁到表锁的锁升级问题,从而导致锁定问题。对于 DB2 Version 8,应将锁列表大小至少增大到 1000,可以通过 db2 update db cfg for DBNAME 命令,将参数设置为 1000 来实现。对于 DB2 9,可以使用 STMM 将锁列表参数值设置为 AUTOMATIC,这将会避免大多数锁内存问题。

要获得关于缓冲池和表空间大小的详细讨论,请参考 “DB2 Basics: Table Spaces and Buffer Pools”(developerWorks,2003 年 10 月)。

选择、更新和插入效率的一般规则

尽可能使用 APPEND ON:要提高插入处理的效率,如果不需要物理集中表数据,那么在表定义中使用 APPEND ON。注意,删除活动或更新活动可以实现空间重用,这将改变行大小,并且在表重组之后才会发生。要获得更多的插入设计技巧,请参考 “Tips for improving INSERT performance”(developerWorks,2004 年 3 月)。

回顾 select * 的用法:一般情况下,建议避免使用 select *。这样做能够最小化针对指定列需要检索的数据量。此外,如果使用 select *,更改数据库模式和表定义可能需要更改应用程序代码,以处理新列和删除的列。

将频繁更新的列集中起来:当更新某一行时,DB2 会记录进行更改的所有列,因此将频繁更新的列放到一起可以减少 DB2 的记录工作。这只是一个有关性能的小建议,因此不应为实现它而进行重大的应用程序或数据库设计修改。

利用 SQL 存储过程降低网络开销

通过最小化到客户机的结果集通信量,SQL 存储过程能够降低网络开销,而且存储过程也能够改善静态(预准备的)SQL 的性能。存储过程的其他益处还包括减少客户端处理(通过更多地使用 DB 服务器资源)以及 DB2 的代码管理。使用存储过程的其他技巧还包括:

尽量保持存储过程小而简单。每个过程应该只做一件事。用单个过程处理多个类型的业务逻辑将会使调优、修改和理解更加困难。

如果可能,使用存储过程创建可重用的业务逻辑 “组件”。

“DB2 SQL PL: Essential Guide for DB2 UDB on Linux, UNIX, Windows, i5/OS, and z/OS, 2nd Edition” 包含针对 SQL 存储过程的有用的设计和编码信息。

最大化并发性

对于好的数据库性能来说,最大化并发性非常重要。下面列出了一些详细的建议:

有 3 个注册变量会影响到并发性。这些变量可以改善并发性,但是也会影响到应用程序的行为。建议在 DB2 开发流程的初期启用这些注册变量,从而在实现并发性增强后执行全面测试中的所有单元测试。要获得更多信息,请参考 “IBM DB2 Database for Linux, UNIX, and Windows Information Center” 中的 “Evaluate Uncommitted Data” 和 “Performance Variables” 部分。

DB2_EVALUNCOMMITTED=YES:对于 V8,从 V8.1 FP9(也即 V8.2 FP2)开始,最佳的设置是 =YES_DEFERISCANFETCH。对于 V9,只需指定 =YES。

DB2_SKIPDELETED=ON

DB2_SKIPINSERTED=ON

选择隔离级别可以为应用程序提供可接受的最佳并发性。有几种方式可用来指定隔离级别,比如对 SQL 语句(只应用于该语句)使用 CURRENT ISOLATION 专用寄存器(应用于连接),以及对 JDBC 连接对象进行指定(应用于连接)。

通过监控锁升级的发生(通过 DB2 状态监控器、db2diag.log、windows 事件浏览器或其他性能监控器,或者利用 DB2 STMM),确保锁列表和 maxlock DB 配置参数足够大。锁列表大小不足将会导致 DB2 尝试将大量行锁 “升级” 到单个表级别的锁。如果升级失败,就会导致死锁;如果升级成功,又会极大地影响到并发性。

最大化并发性的一个例外是,在已知某些时间内只有单个连接访问表的情况。可以考虑使用 ALTER TABLE <name> LOCKSIZE TABLE 来最小化锁定(和相关的内存或 CPU 使用)。请谨慎使用。

“Lock avoidance in DB2 UDB V8”(developerWorks,2005 年 9 月)介绍了大量相关概念。

上一页  1 2 3 4 5  下一页

Tags:针对 基础 设计

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接