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 થયું છે, કે હજી અનિર્ણિત છે.