ولې ګړندی VPN لا هم همغږی SQL تصویب ورو کوي

په لومړني کې د پوښتنې ناسته پرانیزئ او وګورئ چې ساده لیکنه د څه انتظار کوي۔ که ډیټابیس د همغږی تصویب سره د لاسرسي ډلې غړی وي او دوهم پېوستلی وي، د دې انتظار یوه برخه ودانۍ پریږدي: د لاګ ریکارډونه کاپي ته ځي، هلته کلک کیږي، او د دې کلکیدو خبر د تصویب له بشپړیدو مخکې بیرته راځي۔ د بڼ پراخوالی هغه تګ راتګ لنډ نه کوي۔ لاندې توضیح د تصویب تعقیبوي له سکرین څخه تر لرې ډیسک او بیرته۔

د لومړني پر انتظار ډول پیل کړئ

په لرې کاپي کې انتظار کوونکې لیکنه د CPU یا لاک انتظار په څیر نه، بلکې د لاګ سره تړلي انتظار په څیر ښکاري، او د معاملې موده د کرښو شمیر نه، بلکې تګ راتګ تعقیبوي۔ ډېرې کوچنۍ تصویبونه دا څرګندوي، ځکه هر یو سفر جلا تادیه کوي۔ یو لوی کار د همدې لګښت په یو اوږد تصویب کې پټوي۔

د لینک په اړه له هرې پایلې مخکې خپله کاري بار د تصویب فریکونسۍ له مخې ترتیب کړئ۔

له شبکې لوستلو مخکې د کاپي حالت ولولئ۔ مهم شمېرونکي د لېږلو قطار، redo قطار او همغږۍ حالت دي، او یوځای ښیي چې دوهم مل دی یا شاته پاتې کیږي۔ د لېږلو زیاتیدونکی قطار لیږد ته اشاره کوي، پداسې حال کې چې زیاتیدونکی redo قطار د دوهم خپل کار یا ذخیره ته۔ دا بېلابېل ترمیمونه دي، او د بڼ پراخوالی زیاتول هیڅ یو نه ښه کوي۔

تایید تر دوهم پورې تعقیب کړئ

په همغږي تصویب کې لومړنی د تصویب د بشپړیدو اعلانولو مخکې د دې تایید انتظار کوي چې اړوند لاګ په دوهم کې کلک شوی۔ کلک مانا په لاګ کې دوامداره، نه په ډیټا پاڼو کې بیا چلول شوی۔ همدا توپیر توضیح کوي چې ولې همغږی دوهم کولی شي په redo کې شاته پاتې شي او بیا هم کلکیدل تایید کړي۔

لار په ترتیب سره ووهئ او د ټول پر ځای هر پړاو وڅکئ۔ د لاګ ریکارډونه د لیږد له لارې ځي، دوهم یې لیکي او فلش کوي، او تایید په همدې لار بیرته راځي۔ د لیږد ځنډ، د دوهم مهالوښتونه او د دوهم د لاګ ډیسک ځنډ ټول په مجموع کې راځي، او یوازې لومړی د شبکې مالک دی۔ کوم دوهم چې د لاګ حجم یې په بل څه ډک شوی وي، کولی شي هر تصویب اوږد کړي پداسې حال کې چې لینک بیکاره ولاړ وي۔

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

هغه انځور د یو ځل په آرامه ماسپښین کې نه، بلکې د یو نمایندګي لیکنې مخکې او وروسته واخلئ۔ توپیر هغه څه دی چې تاسو ته وایي کوم قطار هغه مهال وخوځېد چې تصویب انتظار کاوه۔

لار وڅکئ، نه لینک

د تیریدو ازموینه د دوو نقطو ترمنځ ظرفیت څکي چې ستاسو کاپي نه دي، د ستاسو د کار نه وي بار لاندې۔ د شبکې له مالک څخه د ریښتیني کاپي لار په اوږدو کې ځنډ او زیان وغواړئ پداسې حال کې چې ریښتینی ترافیک روان دی، په دواړو لورو۔ دلته زیان له ظرفیت څخه مهم دی، ځکه ورک شوی برخه بیا لېږلو ته اړتیا لري او هر تصویب د یو تایید انتظار کوي۔ کوم لینک چې په ډاونلوډ ازموینه کې غوره ښکاري، کولی شي د خبرو کوونکي تصویب نمونې لپاره نامناسب وي۔

د اندازې اخیستلو پر مهال د ډیټابیس د لیږد امنیت او د لاسرسي کنټرولونه نیمګړي مه پریږدئ۔ د لارې اندازه کول هیڅکله د هغوی د پرېښودلو سبب نه دی۔

وختونه له شمېرونکو سره تړئ نه له الهام سره۔ که د لېږلو قطار خالي پاتې شي او تصویب لا هم انتظار کوي، ځنډ په تایید یا د دوهم په فلش کې دی۔ که د لېږلو قطار په دوامداره توګه زیات شي، محدودیت لیږد یا ظرفیت دی۔ ولیکئ کومه مشاهده پایله تایید کړه، ترڅو بل کس د بحث پر ځای اندازه تکرار کړي۔

ناهمغږي حالت واقعا څه بدلوي

ناهمغږي تصویب د دوهم د کلکیدو تایید انتظار لرې کوي، نو ځکه لیکنې ګړندي کیږي او نو ځکه ستاسو د دوام دریځ بدلیږي۔ لومړنی معامله پرته له هغه لرې تایید تصویبوي۔ بیا دوهم ته اجازه ورکول کیږي چې شاته پاتې شي، او همدا شاته پاتې کیدل هغه خطر دی۔

که لومړنی مخکې له دې چې لاګ د کار وړ ناکامي لیږد هدف ته ورسیږي له لاسه ورکړ شي، په هغه کاپي باندې د خدمت جبری تګ هغه معاملې غورځوي چې اپلیکیشن ته دمخه تصویب شوي ویل شوي وو۔

دا د بیا رغونې نقطې پرېکړه ده او د ډیټابیس مالک ته اړه لري، نه د فعالیت بیاکتنې ته۔ لومړی د منلو وړ ډیټا زیان کړکۍ وټاکئ، هغه حالت غوره کړئ چې هغه پوره کوي، بیا په همدې حد کې اصلاح وکړئ۔ هغه انتخابونه چې همغږي ساتنه ساتي عبارت دي له: د اپلیکیشن اجازه ورکړې چېرې چې د تصویب د تګ راتګ مخنیوی وکړئ، د اندازه شوي لیږد یا ذخیرې بندونې سمول، او کاپي لېږدول ترڅو تایید لږ واټن ووهي۔ دوی د هغه دوام غوښتنې سره چې تاسو پیل کړې او نه ده بدله شوې اندازه کړئ۔