اوږد 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';

تاریخ د هر ګام پایله او وخت ښیي، چې د یوې بریا بیرغ څخه ډېر ګټور دی. د هغو دندو لپاره چې ډاټا بدلوي، د اپلیکیشن خپله تصدیق هم ورزیات کړئ: د کرښو شمیر، چکسم یا د کار لخوا لیکل شوې حالت کرښه. دوه خپلواک ثبتونه هغه څه دي چې بیا هڅه خوندي کوي، او ثبت شوی کاري تاریخ د دوی لومړی دی.

د بیا لیږلو دمخه سره برابر کړئ

کله چې د څارنې اړیکه ورک شي، د بل پیلولو دمخه موجوده چلند ومومئ. د هغې د ګامونو پایلې ولولئ او پرېکړه وکړئ چې کار تایید شو، په برخه کې بشپړ شو، که هېڅکله پیل نه شو. یوازې بیا د کاري بهیر لخوا تعریف شوی بیا هڅې قاعده پلي کړئ، ځکه ړوند بیا لیږل کولای شي یوه بار دوه چنده کړي یا دوهم ځل په نیمه لار کې ناکام شي.

تلپاتې مالک او د کتنې وړ پایله وساتئ، نو لنډه لاسرسی ناکامي د اټکل پرځای ناخواله کیږي. دا ټول د ډیزاین هدف دی: کار باید د هغه اړیکې څخه اوږد ژوند وکړي چې غوښتنه یې کړې.