VPN വിച്ഛേദിച്ചതിന് ശേഷം SQL Server-ൽ നിന്ന് Oracle-ലേക്കുള്ള ലോഡ് വീണ്ടെടുക്കുക
VPN വിച്ഛേദിക്കുമ്പോൾ Oracle-ലെ commit പൂർത്തിയായോയെന്ന് വിളിക്കുന്നയാൾക്ക് ഉറപ്പില്ല. ഒരു ദീർഘകാല ബാച്ച് ID എക്സ്ട്രാക്ഷൻ, പ്രയോഗം, അനുരഞ്ജനം എന്നിവയ്ക്ക് ഓരോന്നായി ഉത്തരം നൽകാൻ അനുവദിക്കുന്നു.
VPN വിച്ഛേദിക്കുമ്പോൾ ഡാറ്റാബേസുകൾ തമ്മിലുള്ള കൈമാറ്റം മരിക്കുന്നു, «വീണ്ടും പ്രവർത്തിപ്പിക്കുക» എന്നത് വീണ്ടെടുപ്പ് പദ്ധതിയല്ല. ഉറവിടത്തിൽ നിന്നുള്ള എക്സ്ട്രാക്ഷൻ പൂർത്തിയായിരിക്കാം, ലക്ഷ്യം ഇതിനകം commit ചെയ്തിരിക്കാം, അല്ലെങ്കിൽ മറുപടി തിരികെ വരുന്ന വഴിയിൽ വെറുതെ നഷ്ടപ്പെട്ടിരിക്കാം. ഈ മൂന്ന് അവസ്ഥകൾക്ക് വ്യത്യസ്ത നടപടികൾ വേണം, «പിശക്» മാത്രം അറിയുന്ന ഒരു ക്ലയന്റിന് അവ തിരിച്ചറിയാനാവില്ല.
പരിഹാരം വാസ്തുവിദ്യാപരമാണ്: ഓരോ പ്രവർത്തനത്തിനും ദീർഘകാല ബാച്ച് ഐഡന്റിറ്റി നൽകി, ക്ലയന്റിനെ ഊഹിക്കാൻ അനുവദിക്കുന്നതിനുപകരം ഡാറ്റാബേസുകൾ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകട്ടെ.
ഡാറ്റാബേസ് യഥാർത്ഥത്തിൽ എന്താണ് ഉറപ്പുനൽകുന്നത്
SQL Server-ഉം Oracle-ഉം രണ്ടും ഒരു ഇടപാടിനുള്ളിൽ പരമാണുത്വം നൽകുന്നു. രണ്ടിനുമിടയിൽ പരമാണുത്വം ഒന്നും നൽകുന്നില്ല. നഷ്ടപ്പെട്ട കണക്ഷൻ ഡാറ്റാബേസ് നശിപ്പിക്കുന്നില്ല, കൈകൊണ്ട് റോൾബാക്ക് ചെയ്യാൻ നിർബന്ധിക്കുന്നുമില്ല, കാരണം സെർവർ നിങ്ങളില്ലാതെ സ്വന്തം ഇടപാട് തീർക്കുന്നു. തകരുന്നത് ഫലത്തെക്കുറിച്ചുള്ള വിളിക്കുന്നയാളുടെ അറിവാണ്.
വെവ്വേറെ commit ചെയ്തത് എന്നാൽ വെവ്വേറെ commit ചെയ്തത്. രണ്ട് കണക്ഷനുകളും വഹിക്കുന്ന VPN രണ്ട് commit-കളെ ഒരു പ്രവൃത്തി യൂണിറ്റിലേക്ക് ലയിപ്പിക്കുന്നില്ല.
നിങ്ങൾ ഒരിക്കലും കേൾക്കാത്ത commit
ഒരു പരാജയ മോഡ് നിഷ്കളങ്കമായ വീണ്ടും ശ്രമിക്കൽ യുക്തിയെ ശിക്ഷിക്കുന്നു: സെർവർ commit ചെയ്യുന്നു, സമ്മതം ഒരിക്കലും വിളിക്കുന്നയാളെ എത്തുന്നില്ല. Oracle ഇത് അജ്ഞാത ഫല പ്രശ്നമായി രേഖപ്പെടുത്തി അതിനായി ഇടപാട് ഡോക്യുമെന്റേഷനിൽ Transaction Guard നൽകുന്നു. ആശയവിനിമയ പിശക് അയച്ച commit പരാജയപ്പെട്ടു എന്നതിന് തെളിവല്ല, അതിനെ തെളിവായി കാണുന്നതാണ് ഒരു ബാച്ച് രണ്ടുതവണ പോസ്റ്റ് ചെയ്യപ്പെടാനുള്ള വഴി. ഈ വ്യത്യാസം വീണ്ടും ശ്രമിക്കൽ പാതയിൽ ഏറ്റവും പ്രധാനമാണ്, അവിടെ ഓപ്പറേറ്റർക്ക് പിശക് സന്ദേശം മാത്രമുണ്ട്, പ്രവർത്തിക്കാൻ മറ്റ് സൂചനയുമില്ല.
അതിനാൽ വീണ്ടെടുപ്പ് ഘട്ടം ഫലം പിശക് പാഠത്തിൽ നിന്ന് അനുമാനിക്കുന്നതിനുപകരം ലക്ഷ്യത്തിൽ നിന്ന് വായിക്കണം.
കൈമാറ്റത്തിന് ബാച്ച് ഐഡന്റിറ്റി നൽകുക
ഓരോ പ്രവർത്തനത്തിനും മാറ്റമില്ലാത്ത ബാച്ച് ID ലഭിക്കുന്നു, ലക്ഷ്യം ആ ID-യിൽ എന്ത് ചെയ്തുവെന്ന് രേഖപ്പെടുത്തുന്നു. ജീവിതചക്രം നാല് ഘട്ടമാണ്, വിൽപ്പനക്കാരൻ ആരായാലും അത് ഒരേപോലെ കാണപ്പെടുന്നു:
- എക്സ്ട്രാക്റ്റ് രേഖപ്പെടുത്തിയ സ്കീമയും അതിർത്തിയുമുള്ള, തിരിച്ചറിഞ്ഞ, മാറ്റമില്ലാത്ത ഉറവിട ബാച്ച്.
- കൈമാറുക അത് ലക്ഷ്യത്തിന്റെ സ്റ്റേജിംഗ് മേഖലയിലേക്ക്, തയ്യാർ എന്ന് പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് അപൂർണ്ണമോ വിരുദ്ധമോ ആയ ഉള്ളടക്കം കണ്ടെത്തുക.
- പ്രയോഗിക്കുക ലക്ഷ്യത്തിന്റെ സ്വന്തം അദ്വിതീയത അല്ലെങ്കിൽ ലോക്കിംഗ് നിയമങ്ങൾക്ക് കീഴിൽ, അതേ പ്രാദേശിക ഇടപാടിൽ പൂർത്തീകരണം രേഖപ്പെടുത്തുക.
- അനുരഞ്ജിപ്പിക്കുക ദീർഘകാല ഫലം പിന്തുണയുള്ള പ്രോട്ടോക്കോൾ വഴി, സമ്മതത്തിനോ വീണ്ടും ശ്രമത്തിനോ മുമ്പ്.
വീണ്ടും ശ്രമങ്ങൾ അതേ ID പുനരുപയോഗിക്കുന്നു. ഓരോ ശ്രമത്തിനും പുതിയ ID നിങ്ങൾ ഇപ്പോൾ നിർമ്മിച്ച തനിപ്പകർപ്പ് തടയിടുന്നതിനെ തകർക്കുന്നു, ഇത് ഒരു വീണ്ടും ശ്രമിക്കൽ റാപ്പർ സ്വയമേവ ഒന്ന് സൃഷ്ടിക്കുന്നതുവരെ വ്യക്തമായി തോന്നുന്നു.
ID നിങ്ങൾക്ക് പിന്നീട് അനുരഞ്ജിപ്പിക്കാൻ എന്തെങ്കിലും നൽകുന്നു, ക്ലയന്റ് പ്രക്രിയ വളരെ മുമ്പേ അപ്രത്യക്ഷമായതിന് ശേഷവും.
ബാച്ച് ക്ലെയിം ചെയ്യുക, തുടർന്ന് പ്രയോഗിക്കുക
പ്രയോഗ ഘട്ടം ബാച്ച് ID ക്ലെയിം ചെയ്യണം, ബിസിനസ് മാറ്റങ്ങൾ വരുത്തണം, ഒരു പ്രാദേശിക ഇടപാടിൽ പൂർത്തീകരണം രേഖപ്പെടുത്തണം. പരിശോധനയും ചേർക്കലും വെവ്വേറെ പ്രസ്താവനകളായി ചെയ്യുന്നത് നിങ്ങൾ ഒഴിവാക്കാൻ ശ്രമിച്ച ഓട്ടത്തെ തിരികെ കൊണ്ടുവരുന്നു. രണ്ട് തൊഴിലാളികൾ മത്സരിച്ചാൽ, കൃത്യമായി ഒരു ക്ലെയിം വിജയിക്കുന്നു, മറ്റൊരാൾക്ക് അത് അറിയിക്കുന്നു.
പൂർത്തീകരണ രേഖ ഇല്ലാതിരിക്കുന്നത് നടന്നുകൊണ്ടിരിക്കുന്ന ഇടപാട് ഒരിക്കലും commit ചെയ്യില്ല എന്നതിന് തെളിവല്ല. ക്ലെയിം മത്സരശ്രമങ്ങളെ ക്രമീകരിക്കണം, അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ ഏതെങ്കിലും തീരുമാനത്തിന് മുമ്പ് ദീർഘകാല ഫലം വായിക്കണം.
ആ ക്രമീകരണത്തിന് ആപ്ലിക്കേഷൻ കോഡിലെ പരിശോധിച്ച്-ആവർത്തിക്കൽ ലൂപ്പിനുപകരം ഡാറ്റാബേസിന്റെ പിന്തുണയുള്ള സംവിധാനം ഉപയോഗിക്കുക.
ഡിസൈനിന് ഇപ്പോഴും വാഗ്ദാനം ചെയ്യാനാവാത്തത്
സ്റ്റേജിംഗ് ജോലിയെ വീണ്ടും ആരംഭിക്കാവുന്നതാക്കി ഒരു ദീർഘകാല സെഷനെ ആശ്രയിക്കുന്നത് കുറയ്ക്കുന്നു. SQL Server, Oracle, ജോലി ചെയ്യുന്ന ഏതെങ്കിലും ബാഹ്യ പാർശ്വഫലം എന്നിവയിൽ ഒരൊറ്റ പരമാണു commit അത് സൃഷ്ടിക്കുന്നില്ല. ബിസിനസിന് അത് ശരിക്കും ആവശ്യമെങ്കിൽ, പിന്തുണയുള്ള വിതരണ ഇടപാടോ അനുരഞ്ജന പ്രക്രിയയോ രൂപകൽപ്പന ചെയ്ത് യോഗ്യമാക്കുക, അനിശ്ചിത ഫലമുള്ള ജോലി ആരുടേതെന്നതും ഉൾപ്പെടെ. അതിനേക്കാൾ ദുർബലമായത് കൈമാറ്റ കോഡിലല്ല, അനുരഞ്ജന റൺബുക്കിലാണ്.
മൂന്ന് സ്ഥലങ്ങളിൽ തടസ്സം സ്വീകരിക്കുക: കൈമാറ്റത്തിനിടയിൽ, പ്രയോഗത്തിനിടയിൽ, commit-ന് ശേഷം സമ്മതത്തിന് മുമ്പ്. തുടർന്ന് ക്ലയന്റിന്റെ സന്ദേശത്തിനുപകരം ബിസിനസ് ഫലം പരിശോധിക്കുക, ബാച്ച് ലെഡ്ജർ ജോലി അപൂർണ്ണമാണോ commit ചെയ്തതാണോ ഇപ്പോഴും പരിഹരിക്കാത്തതാണോ എന്ന് പറയട്ടെ.