გრძელი 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';

ისტორია აჩვენებს შედეგს და დროს თითოეული ნაბიჯისთვის, რაც უფრო სასარგებლოა, ვიდრე ერთი წარმატების დროშა. მონაცემების შემცვლელი დავალებებისთვის დაამატეთ აგრეთვე აპლიკაციის საკუთარი შემოწმება: მწკრივების რაოდენობა, საკონტროლო ჯამი ან დავალების მიერ დაწერილი სტატუსის მწკრივი. ორი დამოუკიდებელი ჩანაწერია ის, რაც კვლავ ცდას უსაფრთხოს ხდის, და ჩაწერილი დავალების ისტორია მათგან პირველია.

შეადარეთ ხელახლა გაგზავნამდე

როცა დამკვირვებელი კავშირი ქრება, იპოვეთ არსებული გაშვება, სანამ სხვას დაიწყებთ. წაიკითხეთ მისი ნაბიჯების შედეგები და გადაწყვიტეთ, დადასტურდა სამუშაო, ნაწილობრივ დასრულდა თუ საერთოდ არ დაწყებულა. მხოლოდ ამის შემდეგ გამოიყენეთ განმეორებითი ცდის წესი, რომელსაც სამუშაო პროცესი განსაზღვრავს, რადგან ბრმა ხელახალი გაგზავნა შეიძლება გააორმაგოს ჩატვირთვა ან მეორედ ჩავარდეს შუა გზაზე.

შეინარჩუნეთ მუდმივი მფლობელი და შესამოწმებელი შედეგი, და ხანმოკლე წვდომის ჩავარდნა ხდება უხერხულობა და არა ვარაუდი. ეს არის მთელი დიზაინის მიზანი: სამუშაო უნდა გადაიცოცხლოს იმ კავშირზე, რომელმაც ის მოითხოვა.