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 అయిందా, లేదా ఇంకా పరిష్కరించబడలేదా అని చెప్పనివ్వండి.