పొడవైన SQL పని: VPN తెగినప్పుడు దాన్ని అమలులో ఉంచండి

ఇండెక్స్ పునర్నిర్మాణం ప్రారంభమైన ఇరవై నిమిషాల తర్వాత VPN తెగిపోతుంది, మీ SQL క్లయింట్ విరిగిన కనెక్షన్ చూపిస్తుంది, మరియు ఆ లోపంలో స్పష్టమైన ప్రశ్నకు జవాబు లేదు. స్టేట్మెంట్ పూర్తయిందా, రోల్బ్యాక్ అయిందా, లేదా మీరు లేకుండా కొనసాగిందా? మళ్లీ కనెక్ట్ అవ్వడం మరియు మళ్లీ సమర్పించడం మూడు ఎంపికల్లో అత్యంత దుష్టం, ఎందుకంటే ఇది ఒక అనిశ్చిత ఫలితాన్ని రెండు సాధ్యమైన ఫలితాలుగా మారుస్తుంది. తదుపరి విండోకు ముందు పనిని శాశ్వత యజమాని ఉన్న దానికి మార్చండి.

కనెక్షన్ లోపం మీకు చెప్పనిది

క్లయింట్ వైపు లోపం క్లయింట్ను వివరిస్తుంది. సాకెట్ మూసివేయబడిందని అది నివేదిస్తుంది, సర్వర్ లావాదేవీతో ఏమి చేసిందో కాదు. స్టేట్మెంట్ ఇంకా అమలవుతూ ఉండవచ్చు, లింక్ మరణానికి కొద్ది క్షణాల ముందు కమిట్ అయి ఉండవచ్చు, లేదా దాని సెషన్ శుభ్రం చేయబడినప్పుడు రోల్బ్యాక్ అయి ఉండవచ్చు. మూడూ మీ ల్యాప్టాప్లో ఒకే సందేశాన్ని ఇస్తాయి.

సర్వర్ స్థితి మాత్రమే దీన్ని తీర్మానించగలదు. ఏదీ నిర్ణయించే ముందు అక్కడ చూడండి.

పనిని సర్వర్ వైపు యజమానికి అప్పగించండి

మనిషి పర్యవేక్షణ అవసరం లేని పనికి, డేటాబేస్ హోస్ట్ అమలును స్వంతం చేసుకోనివ్వండి. SQL Server Agent పనులను అభ్యర్థన మేరకు లేదా షెడ్యూల్ ప్రకారం నడిపిస్తుంది మరియు ప్రతి రన్ను నమోదు చేస్తుంది, కాబట్టి పని జీవిత చక్రం మీ VPN సెషన్ నుండి స్వతంత్రం. పని గుర్తింపుకు టాస్క్ కోరే సరైన అనుమతులు మాత్రమే కావాలి, నిర్వాహకుడి పూర్తి ఇంటరాక్టివ్ సందర్భం కాదు. అప్పుడు ల్యాప్టాప్ పనిని ప్రారంభించి ఫలితాలను చదుతుంది, పనిని సజీవంగా ఉంచే ప్రక్రియగా ఉండడం బదులు.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Agent లభ్యత మీరు అమలు చేసిన ఎడిషన్ మరియు సేవపై ఆధారపడి ఉంటుంది. ఇది ప్రతిచోటా ఉందని ఊహించడం బదులు మీ ప్లాట్ఫారమ్ నిజంగా అందించే యంత్రాంగాన్ని ఉపయోగించండి.

డేటాబేస్ దగ్గర ఉన్న జంప్ హోస్ట్ మార్గాన్ని కుదిస్తుంది మరియు ఉండటం మంచిది, కానీ అది యాజమాన్య ప్రశ్నను మార్చదు. నెట్వర్క్ ముగిసినప్పుడు సెషన్ కూడా ముగుస్తుంది. దాన్ని పర్యవేక్షణకు ఉపయోగించండి, పనిని సజీవంగా ఉంచే వస్తువుగా కాదు.

తదుపరి సెషన్ చదవగలిగే రికార్డును విడిచిపెట్టండి

పని పేరు లేదా గుర్తింపుదారు, లక్ష్య డేటాబేస్ మరియు మీరు ఆశించే ఫలితాన్ని నమోదు చేయండి. ఆ రికార్డే మరో సెషన్కు, లేదా మరో వ్యక్తికి, లోపం ఇవ్వలేని ప్రశ్నకు జవాబు ఇవ్వడానికి అనుమతిస్తుంది. అది లేకుండా నవీకరణ గురించి మసక జ్ఞాపకం మిగులుతుంది, తనిఖీ చేయడానికి మార్గం ఉండదు.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

చరిత్ర ప్రతి దశ ఫలితాన్ని మరియు సమయాన్ని చూపిస్తుంది, ఇది ఒక విజయ పతాకం కంటే ఉపయోగకరం. డేటాను మార్చే పనులకు అప్లికేషన్ స్వంత ధృవీకరణను కూడా జోడించండి: వరుసల సంఖ్య, చెక్సమ్ లేదా పని రాసే స్థితి వరుస. రెండు స్వతంత్ర రికార్డులే మళ్లీ ప్రయత్నించడాన్ని సురక్షితం చేస్తాయి, మరియు నమోదైన పని చరిత్ర వాటిలో మొదటిది.

మళ్లీ పంపే ముందు సరిపోల్చండి

పర్యవేక్షణ కనెక్షన్ మాయమైనప్పుడు, మరొకటి ప్రారంభించే ముందు ఉన్న రన్ను కనుగొనండి. దాని దశల ఫలితాలను చదివి, పని కమిట్ అయిందా, పాక్షికంగా పూర్తయిందా, లేదా ఎప్పుడూ ప్రారంభమవలేదా నిర్ణయించండి. అప్పుడే వర్క్ఫ్లో నిర్వచించే మళ్లీ ప్రయత్న నియమాన్ని వర్తించండి, ఎందుకంటే గుడ్డిగా మళ్లీ పంపడం లోడ్ను రెట్టింపు చేయవచ్చు లేదా రెండోసారి సగం దారిలో విఫలమవవచ్చు.

శాశ్వత యజమానిని మరియు తనిఖీ చేయగలిగే ఫలితాన్ని నిలుపుకోండి, అప్పుడు చిన్న యాక్సెస్ వైఫల్యం ఊహ కాకుండా ఇబ్బందిగా మారుతుంది. అదే మొత్తం రూపకల్పన లక్ష్యం: పని దాన్ని కోరిన కనెక్షన్ కంటే ఎక్కువ కాలం జీవించాలి.