重置SQL Remote消息
2006-05-08 23:11:38 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁绘劦鍓欓崝銈囩磽瀹ュ拑韬€殿喖顭烽幃銏ゅ礂鐏忔牗瀚介梺璇查叄濞佳勭珶婵犲伣锝夘敊閸撗咃紲闂佺粯鍔﹂崜娆撳礉閵堝洨纾界€广儱鎷戦煬顒傗偓娈垮枛椤兘骞冮姀銈呯閻忓繑鐗楃€氫粙姊虹拠鏌ュ弰婵炰匠鍕彾濠电姴浼i敐澶樻晩闁告挆鍜冪床闂備胶绮崝锕傚礈濞嗘挸绀夐柕鍫濇川绾剧晫鈧箍鍎遍幏鎴︾叕椤掑倵鍋撳▓鍨灈妞ゎ厾鍏橀獮鍐閵堝懐顦ч柣蹇撶箲閻楁鈧矮绮欏铏规嫚閺屻儱寮板┑鐐板尃閸曨厾褰炬繝鐢靛Т娴硷綁鏁愭径妯绘櫓闂佸憡鎸嗛崪鍐簥闂傚倷鑳剁划顖炲礉閿曞倸绀堟繛鍡樻尭缁€澶愭煏閸繃宸濈痪鍓ф櫕閳ь剙绠嶉崕閬嶅箯閹达妇鍙曟い鎺戝€甸崑鎾斥枔閸喗鐏堝銈庡幘閸忔﹢鐛崘顔碱潊闁靛牆鎳愰ˇ褔鏌h箛鎾剁闁绘顨堥埀顒佺煯缁瑥顫忛搹瑙勫珰闁哄被鍎卞鏉库攽閻愭澘灏冮柛鏇ㄥ幘瑜扮偓绻濋悽闈浶㈠ù纭风秮閺佹劖寰勫Ο缁樻珦闂備礁鎲¢幐鍡涘椽閸愵亜绨ラ梻鍌氬€烽懗鍓佸垝椤栫偛绀夐柨鏇炲€哥粈鍫熺箾閸℃ɑ灏紒鈧径鎰厪闁割偅绻冨婵堢棯閸撗勬珪闁逞屽墮缁犲秹宕曢柆宥呯闁硅揪濡囬崣鏇熴亜閹烘垵鈧敻宕戦幘鏂ユ灁闁割煈鍠楅悘鍫濐渻閵堝骸骞橀柛蹇旓耿閻涱噣宕橀纰辨綂闂侀潧鐗嗛幊鎰八囪閺岋綀绠涢幘鍓侇唹闂佺粯顨嗛〃鍫ュ焵椤掍胶鐓紒顔界懃椤繘鎼圭憴鍕彴闂佸搫琚崕鍗烆嚕閺夊簱鏀介柣鎰緲鐏忓啴鏌涢弴銊ュ箻鐟滄壆鍋撶换婵嬫偨闂堟刀銏犆圭涵椋庣М闁轰焦鍔栧鍕熺紒妯荤彟闂傚倷绀侀幉锟犲箰閸℃稑妞介柛鎰典簻缁ㄣ儵姊婚崒姘偓宄懊归崶顒夋晪闁哄稁鍘奸崹鍌炲箹濞n剙濡肩紒鈧崘顔界叆婵犻潧妫欓ˉ婊堟煟閿曞倷鎲炬慨濠傤煼瀹曟帒鈻庨幒鎴濆腐婵$偑鍊戦崹褰掓晝閵堝鐓濈€广儱顦崡鎶芥煏韫囨洖啸妞ゆ柨顦靛娲箹閻愭彃濮堕梺鍛婃尰閻熲晠骞冨鈧獮搴ㄦ嚍閵壯冨箰闂備礁鎲¢崝鎴﹀礉鎼淬垺娅犻柡鍥╁Х绾惧ジ鏌嶈閸撶喎鐣峰鈧崺鐐村緞閸濄儳娉块梻鍌氣看閸嬪嫬煤閵堝悿褰掓倻閸撳灝娲弫鍐焵椤掑嫭绠掓繝鐢靛Т閿曘倝鎮ц箛娑欏仼婵炲樊浜濋悡娑㈡倶閻愰鍤欏┑鈥炽偢閺屽秶鎲撮崟顐や紝閻庤娲栧畷顒勫煝鎼淬倗鐤€闁规儳顕Σ妤冪磽閸屾艾鈧悂宕愰悜鑺モ挃鐎广儱顦粈澶愬箹鏉堝墽鍒伴柛銊︾箖閵囧嫰寮介顫捕婵℃鎳樺娲川婵犲啫顦╅梺鎼炲妽婢瑰棛鍒掓繝姘闁兼亽鍎遍埀顒傛暬閺屻劌鈹戦崱娆忓毈缂備降鍔忓Λ鍕箒闂佺粯枪瀹曠敻鎮鹃悜妯诲弿濠电姴鍟妵婵囦繆椤愩垹鏆欓柍钘夘槸閳诲酣骞囬鐐╁亾閻戣姤鈷戦悹鍥ㄥ絻椤掋垽鏌i褍娅嶇€规洩绻濋獮搴ㄦ嚍閵夈儰绮ф俊鐐€栧ú宥夊磻閹惧灈鍋撶憴鍕闁绘牕銈搁妴浣肝旀担鍝ョ獮闁诲函缍嗛崑鍛存偟椤愨懇鏀介柣妯诲墯閸熷繘鏌涢敐搴$仯鐎垫澘锕畷婊嗩槷闁稿鎸剧划顓炩槈濡粯鎮欑紓浣哄У閻擄繝寮诲☉銏犖ㄦい鏃傚帶椤晠姊洪挊澶婃殶闁哥姵鐗犲濠氭晲婢跺﹥顥濋梺鍦圭€涒晠宕伴幇鐗堚拺闁煎鍊曢弸搴g磽瀹ュ拑韬€殿喛顕ч埥澶愬煑閳规儳浜鹃柨鏇炲€哥粻锝嗙節闂堟稒宸濆ù婊庝簼娣囧﹪鎮欓鍕ㄥ亾閵堝绀堟繛鍡樻尰閸嬪鏌涢埄鍐枔闁逞屽墯濡啫鐣峰鈧、娆撳床婢诡垰娲ょ粻鍦磼椤旂厧甯ㄩ柛瀣崌閹崇娀顢楅埀顒勫吹椤掑倻纾介柛灞捐壘閳ь剟顥撳▎銏ゆ晸閻樿尙鐛ュ┑掳鍊曢幊搴g不娴煎瓨鐓欓梻鍌氼嚟閸斿秹鏌涚€Q勬珚闁哄矉缍侀獮瀣晲閸♀晜顥夌紓浣鸿檸閸樻悂宕戦幘缁樷拻濞达綀娅g敮娑㈡煕閺冣偓濞叉粎鍒掗弮鍫燁棃婵炵娅曢惄顖氱暦濮椻偓椤㈡瑩宕楅崗澶规岸姊绘笟鈧埀顒傚仜閼活垱鏅堕鐐寸厪闁搞儜鍐句純濡ょ姷鍋炵敮锟犵嵁鐎n亖鏀介柟閭︿簽绾惧姊虹拠鍙夊攭妞ゎ偄顦甸獮鎰槹鎼达絿鐒兼繛鎾村焹閸嬫捇鏌涢埡鍐ㄤ槐妤犵偛顑夐弫鍌炴寠婢跺鐫忛梻鍌欑濠€杈╁垝椤栨粍鏆滈柍鍝勫€搁閬嶆煃瑜滈崜娑氭閹惧瓨濯撮柣鐔告緲婵垽鎮峰⿰鍕棆闁稿鍠栧畷姘跺箳閹存梹鐎婚梺瑙勫劤閻ゅ洭骞楅弴鐐╂斀闁绘劖娼欓悘锕傛煟椤撗冩灈闁宠绮欓、鏃堝醇閻斿搫骞嶉梺鑽ゅ枑閻熴儳鈧凹鍓氶幈銊╁炊閵婏絼绨婚梺闈涱檧婵″洨绮婚悙瀛樺弿濠电姴鍟妵婵嬫煛鐏炶姤鍤囬柟顔界懇閹崇姷鎹勬笟顖欑磾婵犵數濮幏鍐磼濮橆剛銈梻浣告惈閻ジ宕伴弽顓炵鐟滅増甯╅弫鍐煥濠靛棙鍣介柨娑欐崌濮婄粯鎷呴悷閭﹀殝缂備浇顕х€氭澘鐣烽幋婵冩闁靛繒濮烽崢鎾⒑閻熼偊鍤熷┑顕呭弮瀹曟垿骞樼紒妯绘珳闁圭厧鐡ㄩ敋濞存粎鍋撻妵鍕箻鐎电硶濮囧┑鐐叉噹閿曨亪寮婚敍鍕勃闁伙絽鐫楅敐鍡欑缁炬澘褰夐柇顖涱殽閻愯尙绠冲ù鐙呯畵閹稿﹥寰勬繝鍛缚闂傚倸鍊搁崐鐑芥倿閿曞倹鍎戠憸鐗堝笒绾惧綊鏌¢崶銉ョ仼缂佺姷濞€閺岀喖鏌囬敃鈧弸鐔搞亜椤愶絾绀嬮柡宀€鍠栭獮鍡氼槾闁圭晫濮撮埞鎴︻敍濞戞瑥鍞夐梺鍝勬湰閻╊垶鐛鈧鍫曞箣閻樼偣鍋¢梻鍌欑閹诧繝骞愮粙璺ㄦ殾妞ゆ帒瀚ч埀顒佹瀹曟﹢顢欓崲澹洦鐓曢柍鈺佸枤濞堟ê霉閻樿櫕鍊愭慨濠冩そ閹筹繝濡堕崨顔界槪闂備礁鎼幊蹇涙儎椤栫偛绠栧Δ锝呭暞閸婂鏌﹀Ο鐚寸礆闁靛ě鍕瀾婵犮垼鍩栭崝鏇犲婵犳碍鐓欓柛鎾楀懎绗¢梺鍝勬噺閻擄繝鐛弽顐㈠灊闁荤喐婢橀埛澶愭⒑鐠囪尙绠扮紒澶屾嚀椤繘鎼归崷顓狅紲濠碘槅鍨甸褔妫勫鍛斀闁绘劖褰冪痪褔鏌ㄩ弴妯虹仾濞e洤锕幃鐣岀矙鐠侯煈妲规俊鐐€栭悧妤€顫濋妸鈺傚仾闁逞屽墴濮婂宕掑顑藉亾閹间焦鍋嬪┑鐘插閻瑩鏌熼柇锕€鏋﹀┑顔藉▕閺屻倕霉鐎n偅鐝栫紒鐐礃濡嫰婀侀梺鎸庣箓閻楀﹪藟婢舵劖鐓熼柟鐐綑婵牓鏌熸笟鍨閾伙絿绱掔€n亞浠㈡い顒€顑呴埞鎴﹀灳閸愯尙楠囬梺鍛婃⒐閻熲晠鎮伴鍢夌喖宕楅悡搴e酱闂備浇鍋愰埛鍫ュ礈閿曗偓鍗卞ù鐓庣摠閳锋帒霉閿濆毥褰掑汲闁秵鐓欑痪鏉垮船娴滄壆鈧娲橀崝鏍崲濠靛柊鎺旂矙閹稿骸鏋犻悗娈垮枦閸╂牠骞嗛弮鍫濈閻庢稒蓱濠㈡垵鈹戦敍鍕杭闁稿﹥鐗曢~蹇旂節濮橆儵銉╂倵閿濆簼鎲鹃柛鐔锋嚇閺屾洘寰勫☉婊咁槹婵炲瓨绮嶇划宥夊Φ閸曨垰绠婚悹楦挎〃缁泛鈹戦埄鍐ㄧ祷妞ゎ厾鍏樺濠氭晲婢跺娅滈梺鎼炲劀閸愩劎顓哄┑掳鍊楁慨鐑藉磻閻愬灚鏆滈柨鐔哄Х瀹撲線鎮楅敐搴℃灈缂侇偄绉归弻宥堫檨闁告挾鍠栭獮鍐ㄎ旀担铏圭槇濠殿喗锕╅崢鎼佸箯濞差亝鐓熼柣鏂挎憸閹冲啴鎮楀鐓庡籍鐎规洘娲栬灃闁告侗鍠氶崢鍗炩攽閳藉棗鐏ラ柕鍡忓亾闂佺ǹ顑嗛幑鍥箖閵忋倕绠甸柟鐑樺灩闂冣偓濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴f閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣閿濆棭妫勯梺鍝勵儎缁舵岸寮诲☉妯锋婵鐗婇弫楣冩⒑閸涘﹦鎳冪紒缁樺灴婵$敻宕熼姘鳖啋闂佸憡顨堥崑鐔哥閼测晝纾奸柣鎰靛墮閸斻倖銇勯鐘插幋鐎殿喖顭烽幃銏ゆ偂鎼达綆妲堕柣鐔哥矊缁绘帡寮灏栨闁靛骏绱曢崢鎾绘⒒娴e摜浠㈡い鎴濇嚇閹﹢鏁冮崒娑氬帾闂佹悶鍎滈崘鍙ョ磾婵°倗濮烽崑鐐垫暜閳ュ磭鏆﹂柛妤冨剱濞撳鏌熼鍡楁湰椤ワ紕绱撻崒姘偓鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕闁芥ɑ绻堝娲敆閳ь剛绮旈幘顔煎嚑濞达絿纭堕弨浠嬫煟濡寧鐝柣銊﹀灩閳ь剝顫夐幐椋庢濮樿泛钃熸繛鎴欏灩閻掓椽鏌涢幇鍏哥按濠殿喖娲铏圭矙閸栤€冲闂佺ǹ绻戦敃銏狀嚕鐠囨祴妲堟俊顖炴敱閺傗偓闂備胶纭堕崜婵嬨€冭箛鏂款嚤闁逞屽墯娣囧﹪鎮欓鍕ㄥ亾閺嵮屾綎鐟滅増甯掔粈澶愭煛閸ャ儱鐏╅柣鎾达耿閺岀喐娼忔ィ鍐╊€嶉梺绋匡工椤兘寮诲☉銏犖ㄩ柕蹇婂墲閻濇牠鏌″蹇曠瘈婵﹦绮幏鍛村川婵犲倹娈橀梻浣告贡鏋い顓犲厴楠炲啴鎮滈懞銉︽珕闂佷紮绲芥径鍥绩閾忣偆绡€闁汇垽娼у瓭濠电偠顕滅粻鎾崇暦閻㈢ǹ绀冩い鏃傛櫕閸樻捇姊洪崨濠勭畵閻庢凹鍓熷鎶芥偄閸忚偐鍙嗗┑鐐村灦閻熝囨儗閹烘挻鍙忓┑鐘叉川缁变即鏌曢崶銊ュ妤犵偞甯¢獮瀣堪閸愨晝鈧娊姊婚崒娆戭槮闁硅绻濋幃鐑藉Ψ閿旂粯顔旈梺褰掓?缁€渚€鎮″┑瀣厵闁绘劦鍓氶悘閬嶆煕椤愵偂閭柡灞剧洴椤㈡洟濡堕崨顔句簴闂備礁鎲¤摫闁诡喖鍊垮濠氭晲閸垻鏉搁梺鍝勬川閸嬫﹢骞嬫搴g<缂備降鍨归獮鏍煟閺嶎偄甯堕柣锝囧厴楠炲鏁冮埀顒傜不婵犳碍鍋i柛銉簻閻ㄦ椽鏌i妶鍌氫壕濠电姷鏁搁崑鐘诲箵椤忓棗绶ゅù鐘差儏缁犵喖鏌ㄩ悢鍝勑㈢痪鎹愵潐閵囧嫰寮介顫勃闂佹娊鏀遍崹褰掓儉椤忓牜鏁囬柣鎰綑濞咃絾绻涚€涙ḿ鐭婄紓宥咃躬楠炲啰鎹勭悰鈩冾潔闂佸搫璇為崘銊愭洟姊绘担铏广€婇柡鍌欑窔瀹曟垿骞橀幇浣瑰瘜闂侀潧鐗嗗Λ妤冪箔閹烘鐓曢柣鏇氱娴滀即鏌熼姘殭閻撱倖銇勮箛鎾村櫧闁告ê鎲$换娑欐綇閸撗冨煂濠电姭鍋撻弶鍫涘妽濞呯姵銇勮箛鎾跺闁绘挸鍟撮幃宄扳枎韫囨搩浠奸梺璇茬箲閹告娊寮婚悢纰辨晩闁伙絽鏈崳浼存倵濞堝灝鏋涢柣鏍с偢閻涱喚鈧綆鍠楅崑鎰板级閸偆鍘涢柡浣告喘濮婂宕掑顑藉亾妞嬪海鐭嗗ù锝夋交閼板潡寮堕崼娑樺濞寸姵宀稿缁樻媴娓氼垱鏁繝娈垮枔閸婃宕氶幒鎾村劅闁靛ǹ鍎抽ˇ顐︽⒑閸︻厼鍔嬫い銊ユ噽閻氭儳顓兼径瀣幈濡炪倖鍔戦崐鏇㈠几鎼粹埗褰掓偐閻戞﹩浠╃紓浣介哺閹稿骞忛崨鏉戠闁圭粯甯掓竟宥嗕繆閻愵亜鈧牕煤濡崵绠惧┑鐘叉搐閺嬩線鏌涢幇闈涙灈缁炬儳鍚嬬换娑㈠箣閻愯泛顥濆Δ鐘靛仜閻楁挸顫忕紒妯诲闁告稑锕ラ崕鎾斥攽閻愯尙婀撮柛銊ㄦ閻e嘲鈹戦崱娆愭畷闂佸憡娲﹂崜娆撳焵椤掆偓閻栧ジ寮婚敐鍛傜喖鎳栭埡浣侯偧闂備胶绮幐璇裁洪悢鐓庤摕闁绘柨鍚嬮崵瀣亜閹哄棗浜炬繝纰夌磿閸樠囨箒濠电姴锕ょ€氼剟宕濋妶澶嬬厓閻熸瑥瀚悘鎾煛娴e摜效鐎规洜鍠栭、鏇㈠焺閸愨晝绐旈梻鍌氬€烽懗鑸电仚闂佹寧娲忛崕鐢稿箖瑜旈幃鈺呮嚑椤掍焦顔曟繝鐢靛█濞佳囶敄閸℃稑鐤炬繝闈涱儐閻撳啰鎲稿⿰鍫濈闁绘梻鍘ч悘鎶芥煥閺囩偛鈧悂鏌ㄩ妶鍡曠箚闁靛牆鍊告禍楣冩⒑缂佹ê绗掗柣蹇斿哺婵$敻宕熼姘鳖唺閻庡箍鍎遍悧鍡涘储閿涘嫮纾藉ù锝呮惈瀛濇繝鈷€鍌滅煓闁糕斁鍋撳銈嗗坊閸嬫捇鏌涘Ο鑽ょ煉鐎规洘鍨块獮姗€寮妷锔芥澑闂備胶绮灙濞存粠鍓涚划锝夊籍閸喓鍘遍柣搴秵閸嬫帒鈻撻弮鍫熺厓閻熸瑥瀚悘瀛樸亜閵忥紕鎳呮繛鎴犳暬閹粓鎮剧仦钘夊唨婵犵數濮烽弫鎼佸磻濞戙垹绠柟瀵稿Т缁躲倝鏌涢…鎴濇殠闁挎繂顦粻娑㈡煛婢跺孩纭舵い鏂匡躬濮婃椽鎮烽弶鎸庢瘣缂佸墽铏庨崣鍐ㄧ暦娴兼潙绠婚悹鍥皺椤斿棝姊虹紒妯剁細缂侇噮鍨跺畷鐢稿箣閿旂晫鍘剧紓浣割儓濞夋洘绂掑☉娆愬弿闁挎繂妫楁慨宥嗘叏婵犲偆鐓肩€规洘甯掗~婵嬵敄閽樺澹曢梺缁樺灱婵倝宕甸崟顖涚厾闁告縿鍎查弳鈺伱归悩宕囶暡缂佺粯绻堥幃浠嬫濞戞鎹曟俊鐐€栧ú锕傚矗閸愩劎鏆︽俊銈傚亾閾伙絽銆掑鐓庣仩婵炲牄鍔岄—鍐Χ閸℃顫囬梺绋匡攻閻楁粓鍩€椤掍胶顣叉慨妯稿姂閸┾偓妞ゆ帒鍊归崵鈧繝銏㈡嚀閿曨亜鐣锋导鏉戝唨鐟滃寮搁弮鍫熺厪濠电姴绻愰々顒傜磼閳锯偓閸嬫捇姊绘担鍦菇闁搞劏妫勫玻鑳槼闁绘娴风槐鎾存媴閸濆嫪澹曞┑鐘灪宀h法鍒掗弮鍫熷仭闂侇叏绠戝▓銊╂⒑閸濆嫯顫﹂柛搴や含缁鎮介崨濠勫幍闂佺粯鍨跺玻璺ㄧ不濮椻偓閺屾盯鎮欓崹顐f瘓闂佸搫鐭夌紞渚€骞冮埡鍛€绘慨妤€妫旈崫妤呮⒑鐠囪尙绠扮紒璇茬墦瀹曟繂鐣濋崟鍨櫓闂婎偄娲︾粙鎴濇暜闁荤喐绮岄ˇ闈涚暦閹达箑绠婚柤鎼佹涧閺嬪倿姊洪崨濠冨闁告挻鐟ч崰濠傤吋閸涱亝鏂€闂佸疇妫勫Λ妤佺濠靛牏纾奸悹鍥ㄥ絻閳ь剙娼¢弫鎰版倷閸撲胶鏉稿┑鐐村灦閻燂箓宕曢鍫熲拺闂傚牃鏅涢惁婊堟煕濮椻偓缁犳牠寮鍛牚闁告劧绲鹃弬鈧梻浣哥枃濡嫬螞濡ゅ懏鍊堕柣妯肩帛閻撴瑧鐥弶鍨埞濞存粈鍗抽弻銊モ攽閸繀绮跺銈嗘尭閵堢ǹ鐣烽崼鏇炵厸闁告劘娉曢梻顖涚節閻㈤潧浠╅柟娲讳簽缁辩偞绗熼埀顒冩"闂佽宕橀褏绮堟径灞稿亾楠炲灝鍔氭い锔垮嵆閹€斥枎閹寸姷锛滈柣搴秵娴滅偞绂掗姀銈嗙厸闁糕剝绋愰幉楣冩煛瀹€瀣М闁轰焦鍔欏畷鎯邦槻妤犵偛顑呰灃闁绘﹢娼ф禒婊勩亜閹存繍妯€鐎殿噮鍋婂畷姗€顢欓懖鈺佸Е婵$偑鍊栫敮鎺楀磹缂佹ḿ鈻旂€广儱鎳夐弨浠嬫煟濡櫣锛嶆い锝嗙叀閺屾稓鈧絽澧庣粔顕€鏌$仦鍓ф创濠碉紕鍏橀獮瀣攽閸℃ɑ顔嶅┑掳鍊楁慨鏉懨洪銏犵畺婵°倕鍟崰鍡涙煕閺囥劌澧痪鏉跨Ф缁辨挻鎷呴崜鍙壭ч梺鐟版啞婵炲﹪宕规ィ鍐ㄧ睄闁割偅绻勯ˇ銊ヮ渻閵堝棙鐓ユ俊鎻掔墣椤﹀綊鏌$仦鍓ф创闁糕晛瀚板畷妤呮偑閳ь剚绂嶉鍕庢盯宕熼顐㈡倯闂佹悶鍎弲婵嬫晬濠靛洨绠鹃弶鍫濆⒔閸掓澘顭块悷甯含鐎规洘娲熼獮鍥偋閸垹骞堥梻渚€娼ф灙闁稿酣浜堕妴鍌氱暦閸モ晝锛滃銈嗘⒒閳峰牓宕曡箛鏂讳簻闁规儳鍟块幃鎴犫偓鍨緲鐎氼噣鍩€椤掑﹦绉靛ù婊勭墵瀹曟垿骞樼紒妯煎弳闁诲函绲婚崝瀣姳婵犳碍鈷戦柣鐔哄閹牏绱掓径濠勫煟閽樻繈鏌ㄩ弮鍫熸殰闁稿鎸搁埢鎾诲垂椤旂晫浜梻浣筋嚙缁绘垹鎹㈤崼銉ユ槬闁绘劕鎼粻锝夋煥閺囨浜鹃梺缁樻惈缁绘繈寮诲☉銏犵労闁告劗鍋撻悾鍏肩箾鐎电ǹ顎岄柛銊ㄦ硾椤繐煤椤忓嫬绐涙繝鐢靛Т濞寸兘宕濋崼鏇熲拺闁告稑锕ユ径鍕煕濞嗗繘顎楅悡銈夋煕濞戞﹫姊楃紒璇叉閺屾洟宕煎┑鍫㈩唺闂佸憡甯婇崡鎶藉蓟濞戙垺鍋嗗ù锝呮憸娴犳悂鎮楃憴鍕闁告梹鐟ラ悾鐤亹閹烘繃鏅濋梺鎸庣箓閹冲孩瀵兼惔銏㈢瘈缁剧増蓱椤﹪鏌涢妸锕€鈻曠€规洏鍨奸ˇ宕囩磼閸屾氨校闁靛牞缍佸畷姗€鍩℃担鎻掍壕闁割煈鍋呴崣蹇斾繆椤栨粌甯跺ù婊堢畺閹顫濋悙顒€顏�

When should you refer to this document?
You should refer to this document when the following 3 conditions exist:
1) You have lost the log file and mirror log file for a database participating in a SQL Remote replication set up. If you are not using a mirror log file, then loss of the log file is sufficient.
AND
2) You have not been running dbremote with the "-u" switch to "Process only backed up transactions", or if you have been running dbremote with the "-u" switch, you do not have a valid backup available.
3) You are using SQL Remote for Adaptive Server Anywhere
What is the importance of the log file to the SQL Remote message tracking system?
The SQL Remote message tracking system tracks messages based on the log offset from the transaction log, of the sending database, that corresponds to the operations contained in the messages. When a log file is lost, a gap is introduced into the sequence of transaction log offsets. Since the SQL Remote message tracking system relies on the sequence of log offsets being contiguous, the introduction of a gap breaks the system. The log offsets required by the message tracking system are maintained in the sys.sysremoteuser table.
For more detailed information on the SQL Remote message tracking system, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. SQL Remote
CHAPTER 18. SQL Remote Administration
The message tracking system
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
What are the consequences of a lost log file to data movement?
SQL Remote generates and sends messages based on the contents of the transaction log(s). When a log file is lost, the information required to replicate transactions that had been recorded in that log file is also lost. This means that when you lose a log file there are row values, or transactions, in that database which have not yet been replicated and which do not exist at any other node in the replicating system. Given this, resetting the SQL Remote message tracking system consists of two principle tasks:
1) Reconciliation of the data between the consolidated database and the remote databases
2) Resetting of the log offsets contained in the sys.sysremoteuser table
Reconciliation of the Data
We will consider 3 scenarios under which the requirements to reconcile data differ. These scenarios are:
1) One-way publication of data from the consolidated database down to the remote databases
2) One-way publication of data from the remote databases up to the consolidated database
3) Bi-directional publication between the consolidated and remote databases
One-way publication of data from the consolidated database down to the remote databases
If your replication environment consists entirely of one-way publications moving data down from the consolidated database to the remote databases, then all of the data in the system will be contained in the consolidated database. In this scenario, the remote databases can be re-extracted without risk of data loss. For guidelines on how best to perform a re-extraction of an existing remote database, please refer to "Appendix A - Recommendations for Re-extracting Remote Databases" in this document.
One-way publication of data from the remote database up to the consolidated database
In this scenario, data exists on the remote sites which does not exist on the consolidated site. Re-extraction of a database without first reconciling the data would result in the loss of any data that had not yet replicated. Since the data flow is from the remote database up to the consolidated database, the version of the data on the remote database can be taken as correct.
One possible technique for reconciling the data is presented in "Appendix B - Data Reconciliation Using Proxy Tables".
Bi-directional publication between the consolidated and remote databases
This scenario is very similar to the one-way publication in which data moves from the remotes up to the consolidated database. However, this is a more complicated situation since it is possible for a given row to exist on both the consolidated and the remote database but with different values for some columns. Since the data flow is in both directions, the values neither at the consolidated nor at the remote can arbitrarily be considered to be correct. The data owners will be required to make a decision as to the correct values of the data. The business rules that are implemented in the conflict resolution triggers of the consolidated database can be used as a guideline for deciding which version of the data should be considered correct.
For more information on how SQL Remote would handle conflicts during normal operation, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. SQL Remote
CHAPTER 15. SQL Remote Design for Adaptive Server Anywhere
Managing conflicts
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
·Note that the conflict resolution triggers themselves will not fire during the reconciliation process. Their value to the reconciliation process is as documentation of the business rules for resolving conflicts.
One possible technique for reconciling the data is presented in "Appendix B - Data Reconciliation Using Proxy Tables".
Resetting of the log offsets
You can reset the SQL Remote message tracking system either by re-extracting a given remote database or by manually issuing a REMOTE RESET command. For guidelines on how best to perform a re-extraction of an existing remote database, please refer to "Appendix A - Recommendations for Re-extracting Remote Databases" in this document.
The REMOTE RESET command reinitializes the values in the sys.sysremoteuser table for the user specified in the command. If you choose to use this command, then it must be executed at both the consolidated and the remote databases. The next time you run dbremote after you have executed the REMOTE RESET command, new instances of the "0" message will be generated and exchanged between the remote and the consolidated database. For more information on the "0" message, please refer to "Appendix A - Recommendations for Re-extracting Remote Databases" in this document.
It is important to note that the REMOTE RESET command does not recover data. Rather, it introduces a gap in the data by forcing dbremote to ignore all transactions in the log file prior to point at which the REMOTE RESET command was issued. Issuing the REMOTE RESET command is a safe and effective method of resetting the message tracking system without having to re-extract a remote database when:
1) the databases involved are completely up to date
AND
2) the sections of the log files, at both ends, that will be skipped do not contain transactions to be replicated
On the other hand, if you are not satisfied that the databases involved are up to date, or if you know that the databases are definitely out of synch, then issuing the REMOTE RESET command will increase rather than decrease the gap in data between the consolidated and remote databases. Even in this situation, you may choose to issue the REMOTE RESET commands to reset the message tracking system and allow transactions to be replicated while a new database is being extracted and deployed.
For more information on the REMOTE RESET command, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. Reference
CHAPTER 25. Command Reference for Adaptive Server Anywhere
REMOTE RESET statement
URL:
http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
Appendix A - Recommendations for Re-extracting Remote Databases
The Prima(最完善的虚拟主机管理系统)ry difference between the re-extraction of an existing remote database and the extraction of a new remote database is that messages may currently be in transit to the consolidated database in the event of a re-extraction. Any messages that are in transit likely contain valid data. In order to ensure that the most data possible is recovered, the re-extraction process should ensure that valid messages are not rejected as a result of the re-extract.
The 2 basic techniques for ensuring that all valid messages are received and applied are:
1) Wait out the message transport layers latency period
This option is suitable when it is known that messages are typically received within a given time period. As an example, file based messages are present in the inbox of the receiving end as soon as dbremote completes sending them. In contrast, MAPI or SMTP based messages will have some latency as the mail servers forward them from the sending node to the receiving node.
To wait out the latency period, the following process would be used:
i) Run dbremote for the last time on the remote database that is about to be re-extracted
ii) Wait until the latency period has expired
iii) Run dbremote for the last time on the consolidated database to apply any messages that were sent from the remote
iv) Re-extract the remote database at this point
*Note that since the point of the re-extraction was the loss of a log file, step (i) will not be applicable if the log file was lost on the remote database
2) Extract the new remote database under a different remote user id.
This option is suitable when the latency period is not known, or if the remote database is going to continue to generate messages while the replacement database is re-extracted and deployed to the remote site. Under this option, a new remote user will be created with the same subscriptions as the existing remote user. Typically the 'generation' of this new remote user would be reflected in the remote user id. Since this approach does not overwrite the information in the sys.sysremoteuser table for the existing remote user id, messages from that user can continue to be received and applied.
It is important to remember that in this scenario messages may also be in transit from the consolidated database to a remote database, the data represented by transactions contained in those messages will already exist at the consolidated site and will be included in the remote database that gets extracted.
A typical implementation of this process would be:
i) For an existing remote user (i.e. "user1", create a new remote user with a higher generation id reflected in its name (i.e. "user1a")
-this new remote user will require its own unique message address
-you will need to create subscriptions for the new user that correspond to the subscriptions for the existing user
ii) Extract and deploy a database for the new remote user ("user1a")
iii) Once the new database has been received and is in use at the remote site, wait out the latency period and then drop the old remote user ("user1")
The "0-0000000-00" Message as a Special Case
The first message that is sent from each of the consolidated and the new remote database is the "0" message. This message contains information that is required to initialize the sys.sysremoteuser table with the log offsets required by the message tracking system. Since this message is a special case, any instance of this message can be applied by any newly extracted database that has not previously applied a message of this type. Given the following series of events, the special case "0" message could be incorrectly applied to a newly extracted database:
1) Extract a remote database using the extraction utility
2) Run dbremote to send the "0" message
3) Extract the same remote database a second time while the first instance of the "0" message is still sitting in that remotes inbox
4) Run dbremote and apply the first instance of the "0" message.
- this message is now out of context since it contains log offset information from prior to the second extraction of this database
- the sys.sysremoteuser table of this remote database will now contain incorrect log offset information
- running dbremote to apply further messages to this remote database will likely result in the reporting of the error "Missing message ..."
*Note: not all instances of this error/warning are due to this behavior. In many cases, the "Missing message ..." error is a sign that the SQL Remote message tracking system is working as expected.
Due to this behavior, it is strongly recommended that the inbox for a remote database be emptied out before the new database is deployed. Two techniques for ensuring that an incorrect "0" message does not get applied to a newly extracted remote database are:
1) Exchange the first set of messages at the consolidated site before deploying the new remote database.
- it is possible to change the message type of a database after it is extracted
- this means that you can use the file message type to perform a full cycle of replication after extracting the remote database and before deploying it
- a full cycle of replication is:
a)dbremote on the consolidated to generate the "0" message
b)dbremote on the remote to receive and apply the "0" message from the consolidated, and generate its own "0" message to send to the consolidated
c)dbremote on the consolidated to receive and apply the "0" message from the remote
2) Perform an initial run of dbremote with the "-r", "-a" and "-b" switches after deploying the new remote database.
- the "-r" and "-a" switches tell dbremote to receive but not apply any messages currently waiting for the database
- the "-b" switch tells dbremote/sssremote to run in batch mode
- performing a single iteration of dbremote with these switches will have the effect of cleaning out the message directory
- the negative side effect of this approach is that it will likely force a resend cycle
For more information on the dbremote switches mentioned above, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. Reference
CHAPTER 22. Utilities and Options Reference
The Message Agent
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
The Extraction Utility
For instructions on using the extraction utility, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. SQL Remote Administration
CHAPTER 17. Deploying and Synchronizing Databases
Using the extraction utility
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
Appendix B - Data Reconciliation Using Proxy Tables
The purpose of reconciling data is to provide a fixed point in time at which the data content in a consolidated database agrees with the data content in a remote database. Once this fixed point in time is defined, replication can be initiated. The choice of a reconciliation method needs to be made considering the completeness of the reconciliation and the effort that is required to complete the process. One possible approach to reconciling the data is to use proxy tables. It should be emphasized that this is not the only possible technique for reconciling data between replicated databases. Any procedure that creates a consistent image of the data, on both the consolidated and remote database(s), is valid.
In order to reconcile the data using proxy tables, you must have a usable copy of the databases from both the remote and consolidated nodes. This technique does not require that you have a copy of the log file from either node. The drawback of using this technique is that you need to reconcile inserts, updates, and deletes independently. You will also require the involvement of the data owner(s) to determine which rows and/or column values should be considered correct.
A proxy table allows a table in a separate database to be viewed and manipulated as if it was part of the database you were currently connected to. By defining proxy tables to connect your copy of the remote database to the consolidated database, you can use SQL statements to compare the rows that in remote and consolidated databases.
For more information on proxy tables, please refer to the following section of the documentation:
ASA User's Guide
PART 5. Database Administration and Advanced Use
CHAPTER 29. Accessing Remote Data
Basic concepts
Remote table mappings
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbugen7/@Generic__BookView
Identifying Rows to be Reconciled
Once you have defined the proxy tables linking the two databases, you can perform select statements to compare the Prima(最完善的虚拟主机管理系统)ry keys of rows in the remote database to the rows in the consolidated database. Consider the following example:
Consolidated Database
Table_1 |
Row_ID Row_Text |
1 Value1 |
2 Value2_cons |
4 Value4 |
Remote Database
Table_1 |
Row_ID Row_Text |
1 Value1 |
2 Value2_remote |
3 Value3 |
If Table_1 in the Remote Database is configured, on the consolidated database, as a proxy table with the name Proxy_Table_1, then a select statement to identify the rows that exist in the remote database but not the consolidated database would be:
SELECT PT1.Row_ID FROM Proxy_Table_1 PT1
WHERE PT1.Row_ID NOT IN (SELECT T1.Row_ID FROM Table_1 T1);
A similar select statement to identify the rows that exist in the consolidated database but not the remote database would be:
SELECT T1.Row_ID FROM Table_1 T1
WHERE T1.Row_ID NOT IN (SELECT PT1.Row_ID FROM Proxy_Table_1 PT1);
Select statements such as the two shown above allow you do identify rows which exist at one but not both of the nodes that you are reconciling. This provides you with the basic information that you need to reconcile inserts and deletes between the two nodes. The final set of rows that you need to identify is the set of rows which have been updated at one node or other and for which the updates had not yet replicated. Using the data in the sample tables above a select statement to determine which rows require reconciliation of updates would be:
SELECT T1.Row_ID, T1.Row_Text AS cons_row_text, PT1.Row_Text AS remote_row_text
FROM Table_1 T1, Proxy_Table_1 PT1
WHERE T1.Row_ID = PT1.Row_ID
AND T1.Row_Text != PT1.Row_Text;
*Note that in practice, you will have to include restriction criteria based on your publication and subscription definitions when performing the comparisons. In the above example, the publication specified the entire table for simplicity.
At this point you are able to identify all of the rows that require some form of reconciliation. You still need to determine the correct action to be taken with each row. If a row exists at the remote node and the not the consolidated node then there are 2 possible scenarios:
1) The row was recently inserted at the remote node and the insert has not yet replicated up to the consolidated node.
OR
2) The row was recently deleted at the consolidated node and the delete has not yet replicated down to the remote node.
Similarly, there is no arbitrarily correct way to reconcile updates.
The correct reconciliation will depend on the business rules of your SQL Remote set up. When reconciling inserts and deletes it is important to know at which nodes users are allowed to insert and delete rows from each table. One common scenario would be for rows in specific tables to be inserted only at the consolidated node or only at the remote nodes. If the business rules governing data manipulation and movement are understood, then you will be able to determine which differences represent inserts as opposed to updates.
One source of information on the existing business rules for handling updates is your conflict resolution triggers. Conflict resolution triggers only fire when update conflicts are detected while SQL Remote is applying updates. They will not automatically resolve conflicts in a recovery situation. Keep in mind that if you have not defined a conflict resolution trigger then the default behavior is that the last operation to be executed on the consolidated database "wins". The translation of this behavior is that if you have not defined a conflict resolution trigger, then you do not have a preference as to which version of a row is kept.
For more information on how SQL Remote would handle conflicts during normal operation, please refer to the following section of the documentation:
Replication and Syncronization Guide
PART 3. Replication Design for SQL Remote
CHAPTER 15. SQL Remote Design for Adaptive Server Anywhere
Managing conflicts
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrsen7/@Generic__BookView
Applying the Inserts/Updates/Deletes
Once you have identified the rows which need to be moved or modified, you can execute SQL statements involving the proxy tables to modify the rows. When performing the required inserts, Syntax 2 of the INSERT statement allows an insert statement to use a SELECT subquery to generate the rows to be inserted.
For more information on Syntax 2 of the INSERT statement, please refer to the following section of the documentation:
ASA Reference Manual
CHAPTER 9. SQL Statements
INSERT statement
URL: http://manuals.sybase.com:80/onlinebooks/group-sas/awg0700e/dbrfen7/@Generic__BookView
Glossary
One-way Publication
-a one-way publication is a publication which exists at either a consolidated or a remote node in a replicating system
-since the publication only exists on one side, data moves in one direction only
Bi-directional Publication
-a bi-directional publication is a publication which exists at both the consolidated and remote node(s) along with corresponding subscriptions
-since the publication exists on both sides, data moves in both directions
-this is the default behavior when you use the Extraction utility to generate your remote databases
- ››SQL Server 2008 R2 下如何清理数据库日志文件
- ››sqlite 存取中文的解决方法
- ››SQL2005、2008、2000 清空删除日志
- ››SQL Server 2005和SQL Server 2000数据的相互导入...
- ››sql server 2008 在安装了活动目录以后无法启动服...
- ››sqlserver 每30分自动生成一次
- ››sqlite 数据库 对 BOOL型 数据的插入处理正确用法...
- ››sql server自动生成批量执行SQL脚本的批处理
- ››sql server 2008亿万数据性能优化
- ››SQL Server 2008清空数据库日志方法
- ››sqlserver安装和简单的使用
- ››SQL Sever 2008 R2 数据库管理
更多精彩
赞助商链接