开发学院数据库 DB2 DB2通用数据库的并发性阅读

DB2通用数据库的并发性

　2008-09-09 16:30:20　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亜顒㈡い鎰Г閹便劌顫滈崱妤€骞婄紓鍌氬€瑰銊╁箟缁嬫鍚嬮柛顐線缂冩洟姊婚崒娆戭槮婵犫偓闁秵鎯為幖娣妼缁愭鏌″搴′簽濞戞挸绉甸妵鍕冀椤愵澀娌梺缁樻尪閸庣敻寮婚敐澶婂嵆闁绘劖绁撮崑鎾诲捶椤撴稑浜炬慨妯煎亾鐎氾拷

闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亝鎹ｉ柣顓炴閵嗘帒顫濋敐鍛婵°倗濮烽崑娑⑺囬悽绋挎瀬闁瑰墽绮崑鎰版煙缂佹ê绗ч柍褜鍓﹂崣鍐潖閸濆嫅褔宕惰娴犲ジ姊虹拠鑼闁煎綊绠栭幃楣冩倻閽樺鎽曢梺闈涱檧婵″洭宕㈤悽鍛娾拺閻熸瑥瀚烽崯蹇涙煕閻樺磭澧甸柕鍡楀€圭缓浠嬪川婵犲嫬骞堥梺纭呭閹活亞妲愰弴鐔哄ⅰ闂傚倷绶氬ḿ褍煤閵堝洠鍋撳顐㈠祮闁绘侗鍣ｉ獮鎺懳旈埀顒傜不閿濆棛绡€闂傚牊绋戦弳娆徝瑰⿰鍫㈢暫闁哄矉缍佹慨鈧柍鎯版硾濠€杈ㄧ珶閺囩喓绡€婵﹩鍘鹃崢鐢告⒑缂佹ê濮﹂柛鎾村哺閹ɑ娼忛妸銈囩畾闂佸湱绮敮鐐存櫠濞戞氨纾肩紓浣贯缚濞插鈧娲栧畷顒冪亙闂佸憡鍔曢崯鐘诲礈濠靛牊宕叉繛鎴炨缚閺嗗棗鈹戦悩杈厡闁轰焦鐗滅槐鎾存媴娴犲鎽甸梺鍦嚀濞层倝鎮鹃悜钘夌闁规惌鍘介崓鐢告⒑閻熸澘鎮侀柣鎺炵畵閹骞栨担鍏夋嫽婵炶揪绲块崕銈夊吹閳ь剟姊洪幖鐐测偓鏍偋閻樿崵宓侀煫鍥ㄧ⊕閺呮悂鏌ㄩ悤鍌涘

濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻戦妵鍕箻閸楃偟浠肩紓浣哄閸ㄥ爼寮诲☉銏犵疀闂傚牊绋掗悘鍫ユ倵閻熺増鍟炵紒璇插暣婵＄敻宕熼姘鳖啋闁诲酣娼ч幗婊堟偩婵傚憡鈷戠痪顓炴媼濞兼劖绻涢懠顒€鏋庢い顐㈢箳缁辨帒螣閼测晜鍤岄梻渚€鈧偛鑻晶顔肩暆閿濆牆鍔垫い锔界叀閹繝濡舵径瀣帾闂佸壊鍋呯换鍐磻椤忓懐绠剧€瑰壊鍠曠花濠氬箚閻斿吋鈷戦悗鍦У閵嗗啴鏌ら崘鑼煟鐎规洘绻堥弫鍐焵椤掑嫧鈧棃宕橀鍢壯囨煕閳╁喚娈橀柣鐔稿姍濮婃椽鎮℃惔鈩冩瘣闂佺粯鐗曢妶绋跨暦閻戞ḿ绡€闁搞儜鍐ㄧギ闂備線娼ф蹇曟閺囥垹鍌ㄦい蹇撶墛閳锋垿鏌熼懖鈺佷粶闁告梹顨婇弻锟犲川椤旈敮濮囩紓浣稿€圭敮鐔妓囩€靛摜纾奸弶鍫涘妼缁楁碍绻涢悡搴ｇ闁糕斁鍓濋幏鍛存煥鐎ｅ灚缍楅梻鍌氬€峰ù鍥ь浖閵娾晜鍊块柨鏇炲€哥粻鏌ユ煕閵夘喖澧柡瀣╃窔閺岀喖宕滆鐢盯鏌￠崨顔藉€愰柡灞诲姂閹倝宕掑☉姗嗕紦闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾剧懓顪冪€ｎ亜顒㈡い鎰Г閹便劌顫滈崱妤€骞婄紓鍌氬€瑰銊╁箟缁嬫鍚嬮柛顐線缂冩洟姊婚崒娆戭槮婵犫偓闁秵鎯為幖娣妼缁愭鏌″搴′簽濞戞挸绉甸妵鍕冀椤愵澀娌梺缁樻尪閸庣敻寮婚敐澶婂嵆闁绘劖绁撮崑鎾诲捶椤撴稑浜炬慨妯煎亾鐎氾拷　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌ｉ幋锝呅撻柛銈呭閺屻倝宕妷锔芥瘎婵炲濮靛銊ф閹捐纾兼繛鍡樺笒閸橈紕绱撴笟鍥ф珮闁搞劌鐖兼俊鎾礃椤旂厧绐涢梺鍝勵槹閸ㄥ綊宕㈠ú顏呭€垫鐐茬仢閸旀碍銇勯敂璇茬仸鐎规洩绻濋獮搴ㄦ嚍閵壯冨妇闂傚⿴鍋勫ú锕€煤閺嶃劎澧￠梻鍌欐祰椤曆呪偓鍨浮瀹曟粓鎮㈡總澶嬬稁闂佹儳绻愬﹢杈╁閸忛棿绻嗘い鏍ㄧ閹牊銇勯銏⑿㈡い顏勫暣婵″爼宕卞Δ鈧～搴ㄦ⒑閸涘⿴鐒奸柛銉戝懎寮ㄥ┑鐘灱濞夋稖鐧岄梺缁樻煥閸氬鎮￠妷鈺傚€甸柨婵嗛閸樻挳鏌涚€ｎ偅灏扮紒缁樼箓椤繈顢樺☉娆忣伖闂佽崵鍠愮划搴㈡櫠濡ゅ啯鏆滈柟鐑樻尵椤╂彃霉閻撳海鎽犻柣鎾存礋閺岀喖骞嗚閸ょ喖鏌嶉挊澶樻█闁哄苯绉剁槐鎺懳熼懡銈呭汲婵＄偑鍊ら崑鍛崲閸儱绠犳繝濠傛噹閺嬪牊淇婇婵愬殭妞ゅ繐缍婂濠氬磼濞嗘埈妲梺纭咁嚋缁辨洜鍒掑▎鎾崇闁挎柨鎼禍濂告⒑閸濆嫷妲归柛銊у枛瀵悂寮崼鐔哄幐闂佸憡鍔х徊鑺ョ閸撗呯＝濞达綀娅ｇ敮娑氱磼鐎ｎ偅灏扮紒鍌涘浮閺佸啴宕掑鎲嬬床婵犳鍠楅敃鈺呭礈閿曞倹鍊甸柟鎯板Г閳锋帒霉閿濆懏鎲搁柨娑樼Ф缁辨帡顢氶崨顓犱桓濡ょ姷鍋為崹鍨暦閸洦鏁嗛柛灞炬皑閵堬箓姊虹拠鎻掑毐缂傚秴妫欑粋宥夊冀椤撶偟鍝楁繛瀵稿Т椤戝棝鎮″▎鎾粹拺妞ゆ挶鍔庨悾鍗烆熆瑜滈崹閬嶅Φ閸曨垰妫橀柛顭戝枓閸嬫挾鎲撮崟顓涙敵婵犵數濮村ú锕傚磹闁垮浜滈煫鍥ㄦ尭椤忋倝鏌涚€ｎ偅宕岀€殿喖鈧噥妾ㄥ┑鐐插悑閻楁洟鍩為幋锔藉亹閻庡湱濮撮ˉ婵嬫⒑缁嬭儻顫﹂柛鏂块叄楠炲顫㈠畝鈧悿鈧┑鐐村灦宀ｅ潡鎮块崨瀛樷拺闁革富鍙€濡炬悂鏌涢悩鎰佹疁鐎殿喗鐓￠獮鏍ㄦ媴閸︻厼寮抽梻浣虹帛濞叉牠宕愰崷顓涘亾濮樼偓瀚�

核心提示： 但是，如果多个应用程序正以不同的顺序更新某一页上的相同行，DB2通用数据库的并发性(7)，那么行锁导致的竞争甚至可能比页面的还要多，这是因为，而无需操作人员从外部干涉或提供帮助，SQLCA 中的字段 SQLERRD(3) 返回一个理由码，通过页面锁，第二个以及随后的应用程序在访问该页面之前

但是，如果多个应用程序正以不同的顺序更新某一页上的相同行，那么行锁导致的竞争甚至可能比页面的还要多。这是因为，通过页面锁，第二个以及随后的应用程序在访问该页面之前，都必须等待第一个应用程序完成，而它们就可能超时。通过行锁，多个应用程序可以同时访问同一页上的行，但如果它们试图访问相同的行集，就可能死锁。

使用 LOCKSIZE TABLESPACE 或 LOCKSIZE TABLE 之前，用户必须相当确定没有其他重要的应用程序进程需要并发访问该对象。在任何表上指定 LOCKSIZE ROW 之前，极为明智的做法就是先对增加锁开销来提高并发性是否值得进行估计。

小型表

如果一个 DB2 UDB 表兼具尺寸小和高使用率的特点，那么就考虑使用 LOCKSIZE ROW，特别是每个页面中有许多行的时候。此外，因为表十分小，锁粒度将不会给锁开销带来较大的性能影响。

DB2 UDB 对象和授权的分组

通常总是将与同一应用程序逻辑相关的表分组到一个数据库中。理想情况是，每一个应用程序进程都引用尽可能少的 DB2 UDB 数据库。而且，要设法给用户不同的授权 ID 来使用不同的 DB2 UDB 数据库。实际上，这将增加可能应用程序进程的数目，同时可能减少每个应用程序进程可以访问的数据库数目。因此一般说来，“组合相似的事物”和“分开不同的事物”。

应用程序设计考虑

正如初始数据库设计一样，早在开发新的 DB2 UDB 应用程序之时就开始考虑并发性问题也很重要。更好的做法是，在实现之前，就将并发性原则包含到生产中去。然而，有时候并发性的提高可能取决于较新的 DB2 UDB 版本中的新功能以及与之接合的其他系统。在这些情况下，可能需要修改现有的应用程序，以便提高并发性水平。而在其他情况下，可能要等并发性问题发展和增长到一定的时候，才有必要对应用程序进行大量修改。以下是一些用以评估在某一时刻是开发新的 DB2 UDB 应用程序，还是修改现有的 DB2 UDB 应用程序的选项。

尽可能晚地访问关键资源

例如，设计和编写应用程序，以便 SQL 语句获取和更新 DB2 UDB 数据的时间尽可能地接近提交点。注意该问题将减少锁定数据的时间总量，从而减少其他应用程序进程无法使用该数据的时间。

尽可能快地提交工作

通常，在达到数据一致性临界点之后，尽快发出 COMMIT 语句是一种较好的 SQL 编程技术。该实践将有助于避免不必要的锁竞争，甚至在只读应用程序中也应该采用该实践。类似地，我们建议应用程序中一检测出 SQL 故障，就发出 ROLLBACK 语句。这将阻止未成功的 SQL 语句不必要地、过长时间地锁定 DB2 UDB 资源。

尽可能快地关闭游标

尽可能快地关闭游标是另一个可以帮助提高并发性的编程实践。通过尽快发出 CLOSE CURSOR 语句，应用程序将释放那些锁以及它们所持有的 DB2 UDB 资源。

应用程序重试逻辑

我建议应用程序中包含重试逻辑，即当程序接收死锁或超时状况的指示时，该应用程序代码应重试该操作，甚至允许重试多次。这就使得应用程序有可能从该状况中恢复，而无需操作人员从外部干涉或提供帮助。SQLCA 中的字段 SQLERRD(3) 返回一个理由码，指示是否发生了死锁或超时。

上一页 2 3 4 5 6 7