مقدمه
یکی از مهم ترین مباحث در حوضه نگهداری داده توسط DBMS ها ، پیاده سازی load Balancing و فرار از single Point of Failover می باشد.که DBA ها نیز از قدیم به دنبال پیاده سازی ساختاری برای رسیدن به این مهم بودند و بصورت ابتکاری طرح های ارئه شد تا ورژن 2008 که ماکروسافت رسما در این ضمینه ادعا کرد، و این ادعای خود را تا امروز یعنی SQL2017 کامل تر کرده و حتی ترکیبی از این Availabilityو Distributed Data Store را همزمان ارئه داد که البته برای پیاده سازی آن می بایست با مفاهیم شبکه 100 درصد آشنا بوده تا بتوان منطق کار متوجه و در شرایط خاص اقدام به troubleshooting کرد، در ادامه به معرفی متدهای موجود پرداخته و سپس وارد بحث AG شده و پیاده سازی multi subnet آن را تشریح خواهیم کرد.
در زیر هر روش به همراه مزایا و معایب آن لیست شده است:
Log Shipping بعدا Loading
Mirroring بعدا Loading
Replication بعدا Loading
SQL Server Failover Cluster بعدا Loading
SQL Server AvailabilityGroup بعدا Loading
SQL Server AvailabilityGroup in Multi Subnet بعدا Loading
Loading….
مختصری بر آنچه در راه اندازی AG در حالت multi net رخ می دهد
این قابلیت SQL مبتنی بر Failover Cluster ویندوز ماکروسافت است که از سال 2003 اضافه شد. بطوری که ابتدا یک کلاستر ویندوزی راه اندازی شده ، سپس role آن SQL انتخاب خواهد شد. دقیقا مشابه آنچه برای cluster دیگر سرویس ها نیز وجود دارد.پس آشنایی با این role از اهمیت بالایی برخوردار است. برای راه اندازی SQL Server Failover شاید داشتن اطلاعات مختصر از این Role کافی باشد ، اما برای راه اندازی AG و مخصوصا در حالت Multi Subnet می بایست اطلاعات دقیقی از این رول داشته باشیم که بتوان این ساختار را پیداه سازی کرد. پس در ابتدا یک نیم نگاهی به این role و کاربرد آن داشته باشیم.از طرفی با توجه به نیاز به اینکه ساختارهای enterprise مبتنی بر Domain بوده و ابزار authentication مورد نیاز domain Controller ها هستند، می بایست در حالت multi Subnet و استفاده از Wan ، دامین را نیز بصورت اینترپرایز راه اندازی کرده و از مفهوم Site استفاده شود، در ادامه بحث استفاده از DNS در دسترسی به کلاستر، بصورت round Robin و استفاده از Netmask Ordering در DDNS مطرح میشود که نیازمند تسلط کامل به مطالب DNS می باشد. با این مختصر پیشنهاد می شود ابتدا اطلاعات خود را کامل و سپس اقدام به طراحی این سناریو در محیط عملیاتی داشته باشید، چراکه حوزه دیتا، شوخی بردار نیست و هرگونه اشتباه ، مشکلات جبران ناپذیری را به دنبال خواهد داشت.
SQL Server Availability Group in Multi Subnet
این سناریو معمولا در جایی مورد استفاده قرار می گرد که ارتباط WAN وجود دارد، و هر کدام از نود های AG قرار است در یک Site باشند که به لحاظ فیزیکی از هم فاصله داشته و ارتباط بین site ها لایه 3 و امکان قطعی دور از انتطار نیست، از طرفی پهنای باند بین سایت ها محدود می باشد و باید به این نکات توجه ویژه داشته باشیم. اما دیده شده اکثرا در جایی که Wan نداریم و می توان ارتباط لایه 2 داشت، یک VLan جدا برای نود های AG و sync شدن آنها منظور شده است، اما در جایی که wan بصورت لایه 3 فراهم گردیده است، چنین امکانی وجود نداشته و باید دنبال یک نو آوری بود که نهایتا به این مبحث خواهیم رسید.
پیاده سازی این متد نیازمند توجه به یکسری نکات در سطح server Cluster سپس در سطح SQL Server AvailabilityGroup می باشد، اما برای درک بهتر یک سناریو فرضی مطرح کرده و بر اساس آن اقدام به بررسی و پیاده سازی خواهیم کرد، بطوری که دو سایت داریم که به لحاظ فیزیکی از هم جدا بود و از طریق لایه 3 با هم ارتباط ضعیفی داشته، بطوری که سایت ها رنج 192.168.10.0/24 و 192.168.11.0/24 را داشته ، قرار است در سایت اصلی دو سرور دیتابیس و در سایت مقابل یک سرور داشته که هم بتوان load Balancing را پشتیبانی کرده و هم auto Failover داشتیم باشیم، از طرفی از دید ADDS نیز دو سایت برای هر شبکه در نظر گرفته و در هر سایت یک DC قرار داده شده است و برای مدیریت ترافیک Replication برو روی Wan از مفهوم site در Active Directory استفاده خواهد شد، و مطابق site Link طراحی شده DC ها هر 20 دقیقه Replication خواهند داشت. نکته مهم در این است که برای مجموعه AG راه اندازی شده می خواهیم فقط یک connection String داشته باشیم تا در زمان Failover نیاز به هیچگونه تغییری در سطح application نباشیم.
تنظیمات ویژه Windows failover Cluster
نکته مهم در این خصوص بحث تفاوت در رنج IP ها می باشد، بدین ترتیب که تا قبل از این نودهای کلاستر و آدرس انتخاب شده برای کلاستر از یک رنج بوده اما در این سناریو نودها در subnet های مجزا بوده و این یک چالش بزرگ است.در دید اول شاید تصور کنیم همانند NLB ، که لایه 2 کار می کند، یک Mac جدید تولید شده و با آدرس جدید به هرکدام از Host های Cluster اضافه و یا overwrite می شود،(ادرسIP جدید NLB یا همان اصطلاحا لیسنر NLB ، به همراه Mac جدید ساخته شده براساس مبنای 16ی همان آدرس) اما بعد از کمی بررسی مشخص است که Server Cluster با NLB متفاوت است، چرا که در NLB دنبال این هستیم که همه Host ها همزمان پاسخ گو باشند اما در server Cluster اساس کار بر پایه Failover است، یعنی یک نود Active و دیگری Passive است ، پس دراین حالت آدرس کلاستر یا همان لیسنر در یک لحظه فقط به یکی از نود ها تخصیص داده خواهد شد و نود Active علاوه بر آدرس خودش، یک آدرس اضافه تر نیز دریافت خواهد کرد.پس با اعلام ادرس کلاستر به کاربران، بدون هیچکونه نیاز به تغییر در کلاینت در زمان Failover کلاستر ، کلاینت به سرویس دهنده وصل می شود، چرا که کلاینت فقط آدرس کلاستر را می شناسد و اینکه این آدرس در لحظه در اختیار کدامیک از Node ها است، از دید کلاینت مخفی خواهد بود. اما تا این قسمت همه Node ها در یک subnet بودند، و قطعا آدرس کلاستر انتخاب شده از همان subnet بوده و به راحتی قابل انتساب به نود Active خواهد بود ، اما زمانی که هر node در subnet متفاوت باشد، مسئله ای که مطرح میشود آدرس کلاستر خواهد بود، و این سوال مطرح میشود که آدرس انتخابی از کدام subnet باشد، و در صورتی که مثلا از subnet ، 192.168.10.x باشد، چگونه در زمان Failover به نود دوم در نتورک 192.168.11.x این آدرس را استفاده کنیم! می دانیم در صورت استفاده از آدرس 192.168.10.x در شبکه 192.168.11.0/24 ، این آدرس Routable نبوده و قابل دسترس نخواهد بود.
جواب این سوال فوت کوزه گری پیاده سازی کلاستر multi Subnet است، برای حل این مشکل به جای یک آدرس برای کلاستر به عنوان لیسنر کلاستر، از دو آدرس استفاده خواهد شد که هر کدام از یک subnet برگزیده شده است به عنوان مثال 192.168.10.100 و 192.168.11.100 ، حال با این روش اگر نود فعال کلاستر در شبکه 10 باشد، آدرس کلاستر 192.168.10.100 بوده و اگر نود فعال کلاستر به دلیل Failover به نود دیگر در شبکه 11 منتقل شود آدرس کلاستر به 192.168.11.100 تغییر خواهد کرد.
گرچه چالش اول مرتفع گردید، اما چالش دیگری بوجود می آید، که این تغییر IP کلاستر به کلاینت های آن می بایست اعلام و احتمالا connection String های آنها اصلاح شود، این چالش بدین صورت برطرف می شود که از سرویس DNS استفاده کرده و با معرفی یک نام برای کلاستر، بصورت خودکار یک A-Rec در DNS برای کلاستر با آدرس نود اکتیو ساخته می شود(مثلا myCluster با آدرس 192.168.10.100) و زمانی که Failover رخ می دهد، در صورت استفاده از DDNS ، Failover سریعا به DNS اعلام شده و A-Rec مربوطه سریعا اصلاح می شود به آدرس جدید کلاستر(در مثال فوق myCluster به آدرس 192.168.11.100 تغییر خواهد کرد). همانطور که اشاره شده لزوم استفاده از DDNS در این سناریو ضروری می باشد.
در آخر به ظاهر همه چیز برای اطمینان از صحت عملکرد Server Failover Cluster مساعد به نظر می آید، اما اگر وارد محیط عملی شویم، متوجه خواهیم شد، که بعد از Failover خودکار، کلاینت ها مدتی به کلاستر دسترسی نداشته و بعد از مدتی و بعضا با یک ریست مجدد می توانند به کلاستر متصل شوند، اما ریست و صرف زمان برای کلاینت ما که حکم IIS و Web Server ما را دارد،غیر ممکن است، پس می بایست این چالش برطرف گردد، بعد از بررسی این موضوع اولین نکته که مشخص می شود بررسی زمان انتظار است، این زمان در بیشترین مقدار یعنی در بدترین حالت 20 دقیقه است، که دقیقا دال بر زمان کش شدن جواب DNS برای آدرس کلاستر خواهد بود.از طرفی به دلیل استفاده از DDNS، مشخصا اشاره داشته به 20 دقیقه زمان اعلام کش A-Rec ها در Dynamic Zone ، که به راحتی قابل تغییر می باشد و با انتخاب 1 ثانیه به جای 20 دقیقه ، در لحظه Failover ، کلاینت ها با اولین سوال از DNS (به دلیل خالی بودن کش برای این رکورد) برای تبدیل نام Cluster به IP ، آدرس جدید را ریزالو کرده و با نود جدید ارتباط برقرار خواهد کرد.
تنظیمات ویژهArability Group
هانطور که می دانیم مکانیزم ag از کلاستر ویندوز استفاده می کند اما با کمی تغییر در الگوریتم کار بصورت Active به Active فعالیت خواهد کرد،بدین ترتیب که تمامی نودها در ارائه سرویس نقش داشته و load Balancing را با تقسیم بار بین نود ها برای ما فراهم میکند.این هدف با استفاده از یکlistener پیاده سازی می شود، بدین ترتیب که کلاستر مربوط به SQL یک listener Name مشخص خواهد داشت که بر روی Port دلخواه ما که عموما 1433 می باشد،ارائه سرویس خواهد کرد، اگر فرض کنید این نام را MYAG به نامیم ،مشخصا می بایست یکIP برای آن مشخص شود که چالش اصلی multi subnet انتخاب این IP است، شاید به نظر روش استفاده شده در Cluster پاسخ گو باشد،اما ذکر این نکته ضرروی است که مکانیزم AG بدین صورت است که کلاینت ها به آدرس کلاستر متصل می شوند و ان کلاستر است که تصمیم میگیرد کدام نود Primary بود و باید Write ها را پاسخ دهد و کدام نود Secondary بوده و Read ها را پاسخ خواهد داد.در تکمیل این موضوع بعد از بررسی مشخص خواهد شد با توجه به اینکه در این الگوریتم توزیع کننده ای وجود ندارد، پس آدرس کلاستر به نود Primary انتساب داده خواهد شد و درخواست ها بر روی IP کلاستر به نود Primary خواهد رسید،حال این نود Write ها را خود پاسخ داده و Read ها را به Secondary ها از طریق IP ارسال خواهد کرد.البته این رفتار AG در SQL بصورت پیش فرض بوده و می توان با استفاده از Read Only Routing List تغییراتی در آن اعمال کرد.اصل ماجرا از آنجا شروع میشود که زمانی که نود Primary بصورت خودکار یا دستی Failover کند، در این حالت IP انتساب داده شده به Listener به نود Primary جدید منتقل خواهد شد. با توجه به این توضیحات چالش بر سر انتخاب IP به عنوان Listener این Ag می باشد، آدرس IP انتخابی در صورتی که تمامی نودهای SQL در یک شبکه باشند، قطعا از رنج همان شبکه خواهد بود و در زمان Failover به راحتی و بدون هیچ نگرانی IP میتواند بین نودهای کلاستر جابجا گردد،اما زمانی که نودهای ما آدرس از sub net ها متفاوت داشته باشد، به راحتی قبل نمی توان آدرس ها را جابجا کرد.(به عنوان مثال اگر آدرس Listener ،192.168.10.200 باشد این ادرس در زمان Failover در شبکه 192.168.11.0/24 غیر قابل استفاده خواهد بود) لذا می بایست دنبال راهکاری بود و روش انتخابی استفاده از چند آدرس IP است، بدین ترتیب که از هر Sub net یک آدرس انتخاب و به Listener انتساب خواهیم داد،(در سناریو اخیر به عنوان مثال دو آدرس 192.168.10.200 و 192.168.11.200 را انتخاب می کنیم) گرچه کلاستر همه آدرس ها را می پذیرد، اما مطابق آنچه مطرح شد فقط نود Primary آدرس کلاستر را میگیرد، پس بسته به این که کدام نود در کدام Sub net نقش Primary را بازی خواهد کرد، از بین آدرس های انتخاب شده برای کلاستر،آدرس هم رنج نود Primary به عنوان Listener انتخاب خواهد شد و بقیه IP های انتخاب شده جواب Arp را نخواهند داد. گرچه این رفتار خیلی هوشمندانه توسط ماکروسافت ارائه شده است،اما یک مسئله مطرح می شود که این تغییر IP ، Listener در زمان Failover چگونه به کلاینت ها اعلام گردد،چگونه در Client ها که همان IIS و وب سرویس ها و… هستند اقدام به اصلاح Connection String ها بصورت خودکار شود؟ جواب این سوال فوت کوزه گری پیاده سازی AG در حالت multi Sub Net بوده، بدین ترتیب که مشابه آنچه در کلاستر مطرح شد، از DNS کمک خواهیم گرفتیم و تمامی آدرس های انتساب داده شده به Listener را در DNS رجیستر کرده (در صورت استفاده ازDDNS این کار بصورت خودکار صورت خواهد گرفت) به عنوان مثال در سناریوی اخیر برای نام MYAG دو آدرس 192.168.10.200 و 192.168.11.200 را رجیستر کرده و Connection String ها را نیز در کلاینت های SQL بصورت Name Base طراحی می کنیم، اما مسئله مهم در این نکته است که DNS پاسخ سوال MYAG را با ارائه همه IP های رجیستر شده در DNS برای این نام پاسخ خواهد داد، اما فقط یک IP مربوط به Listener فعال خواهد بود.البته بصورت پیش فرض دارای دو خاصیت Load Balancing و Netmask Ordering می باشد، که مطابق آن اگر برای یک سوال بیش از یک پاسخ داشته باشد سعی میکند پاسخی به کلاینت ارائه شود که اختلاف بیت IP پاسخ با IP کلاینت کمتر باشد یا به عبارتی ذکر این نکته ضروری است که DNS در ماکروسافت پاسخی ارائه میشود که به کلاینت نزدیک تر است، از طرفی اگر مجدد چند پاسخ با توجه به اگوریتم بالا وجود داشت، یعنی پاسخ هایی بودند که فاصله یکسان با کلاینت داشتند، در پاسخ به کلاینت اقدام به Round robin خواهد کرد.در سناریوی اخیر DNS به کلاینت های هر سایت IP از رنج همان سایت را به عنوان پاسخ سوال MYAGخواهد داد. کاملا مشخص است این رفتار DNS به ما کمکی نخواهد کرد، چرا که DNS بصورت کورکورانه اقدام به پاسخ کرده و از Failover اطلاعی نداشته و به کلاینت های هر subnet آدرس از همان رنج را به کلاینت ارائه خواهد کرد ولو اینکه آدرس نود Primary نباشد و پاسخ ARP آن به کلاینت نرسد. پس چالش کماکان پابرجا هست و باید به سولوشن CLIENT SIDE مراجعه کرد، این راه کار که توسط ماکروسافت ارائه گریده است که شامل اکثر کلاینت های ماکروسافتی می باشد از جمله .NET ، بدین ترتیب خواهد بود که گرچه چندین پاسخ به کلاینت ها برای دسترسی به نام MYAG از DNS دریافت میشود،کلاینت مادامی که از سرویس دهنده پاسخی دریافت نکرده است به ترتیب به دنبال همه پاسخ های دریافتی از DNS خواهد رفت.(در مثال فوق اگر کلاینت از شبکه 192.168.11.0/24 اقدام به اتصال به SQL کرده باشد و MYAG را به عنوان Listener ، فراخوان کند، برای دسترسی به IP به DNS مراجعه خواهد کرد، و چون در DNS دو A-Rec با آدرس های 192.168.10.200 و 192.168.11.200 ثبت شده است DNS به ترتیب اول 192.168.11.200 و دوم 192.168.10.200 را به کلاینت ارائه خواهد کرد، حال اگر نود موجود در شبکه 192.168.11.0/24 به عنوان Primary باشد که آدرس کلاستر 192.168.11.200 بوده و کلاینت به درستی به MYAG متصل خواهد شد، اما اگر نود Primary در شبکه 192.168.10.0/24 باشد آنگاه آدرس کلاستر 192.168.10.200 خواهد بود، پس کلاسنت چون در ترتیب دوم از آنچه از DNS تحویل گرفته به این آدرس خواهد رسید، ابتدا مطابق ترتیب اول به دنبال 192.168.11.200 رفته و چون جواب ARP تحویل نمی گیرد بصورت خودکار به دنبال آدرس دوم تحویل گرفته شده از DNS خواهد رفت که همان 192.168.10.200 بوده و به SQL متصل خواهد شد)
با توجه به این توضیحات بدون هیچ دق دقه میتوان در iis ها و در connection string از نام کلاستر استفاده نماییم و بصورت لایه 3 در wan از این متد استفاده کرد.
نکته مهم:
بعد از راه اندازی این پروسه در محیط پروداکشن به یک مشکل اساسی بر خورد کردیم، که درادامه به جزئیات آن خواهیم پرداخت بدین ترتیب که، تصور این بود وقتی هر دو آدرس AG Listener در DDNS رجیستر میشود، کلاینت که همان Connection String را خوانده و به دنبال سرویس SQL در شبکه حرکت می کند، هر دو آدرس را با توجه به کورکورانه بودن پاسخ DNS دریافت کرده و به دنبال تک تک پاسخ ها رفته تا به آدرس فعال برسد، و اصطلاحا سعی شد، مشکل Client Side حل شود، اما در عمل این پروسه ممکن بود زمان بر بوده و هر نوع client ی آن را ساپورت نکند، به عنوان مثال گرچه .Net آن را ساپورت می کرد، اما کنسول SSMS آن را ساپورت نکرده و همواره دنبال آدرس اولی که DNS به عنوان پاسخ ارئه می داد رفته و لذا تا زمانی که DNS Cache خالی نشود، آن SSMS نمی توانست به کلاستر متصل شود و یا باید 20 دقیقه صبر میشد تا کش بصورت خودکار حل شود. خوب ما این ریسک را گرچه در دسترسی از طریق SSMS شاید بتوانیم بپذیریم، اما در محیط پروداکشن، این مهم قابل قبول نبود، لذا سعی شد دنبال راه کاری باشیم و نهایتا به سه روش که هر سه باهم می تواند مشکل را حل کند رسیدیم:
راه کار اول:
چه لزومی دارد، تمامی آدرس های AG Listener در DDNS ثبت شود؟ چرا باید DNS کورکورانه پاسخ دهد؟ پس این موضوع را هدف قرار داده و به این مهم رسیدیم که کاری کنیم آدرس فعال AG Listener در DNS ثبت شود و همه آدرس ها بی دلیل ثبت نشده در صورت Failover این آدرس بصورت خودکار تغییر کند:
- یافتن نام کلاستر
Get-ClusterResource -Cluster “NamavaDB” #Verify
- فعال سازی Multi Subnet
Get-ClusterResource “NamavaDB_NamavaDB” -Cluster “NamavaDB ” | set-clusterparameter RegisterAllProvidersIP 0 -Cluster “NamavaDB “
- فعال و غیر فعال کردن کلاستر
Stop-clusterresource “NamavaDB_NamavaDB” -Cluster “NamavaDB” #Take Offline
Start-clusterresource “NamavaDB_NamavaDB” -Cluster “NamavaDB” #Take Online + After ThisT maunuly start role in console cluadmin.msc
- فعال کردن کلاستر AG بعد از فعال شدن کلاستر
Start-clusterresource “NamavaDB” -Cluster “NamavaDB” #This step is important. The AAG is offline, must bring the AAG Back online
- بررسی نتیجه
Get-ClusterResource “NamavaDB_NamavaDB” -Cluster “NamavaDB” | get-clusterparameter -Cluster ” NamavaDB”
Get-ClusterResource -Cluster “NamavaDB” #Verify
راه کار دوم:
گرچه DNS با پیاده سازی راه کار اول همواره پاسخ صحیحی را خواهد داد، اما اصلاح رکورد در زمان Failover به گوش کلاینت ها نخواهد رسید، چرا که کلاینت ها پاسخ سوالات خود را از DDNS بصورت پیش فرض 20 دقیقه کش می کنند، پس این احتمال وجود دارد تا 20 دقیقه زمان ببرد تا Failover کلاستر به گوش کلاینت ها برسد. خوب راه کار این کار آپدیت زمان Cash به مقداری معقول است، اما این مقدار چه تایمی است؟ طیبعتا نباید خیلی کم باشد، چرا که لود سمت DNS خواهد بود و هر بار مراجعه به دیتابیس یک کویری DNS را به همراه خواهد داشت، پس با هماهنگی سازمان می توان به یک زمان استاندارد مثلا 5 دقیقه رسید، نه به آن معنا که 5 دقیقه زمان می برد تا Failover به اطلاع کلاینت برسد، بلکه حداکثر 5 دقیقه زمان خواهد برد! اما بعد از رسیدن به این زمان مسئله این است چگونه این زمان کش را اصلاح کنید، مگر کلاینت های DDNS خود هر 20 دقیقه یکبار رکورد های خود را Update نمی کنند، و در رکورد ساخته شده در DDNS زمانی کش 20 دقیقه است ، پس زمان کش تایین شده توسط ما را نیز Over Right خواهند کرد و 5 دقیقه ما بعد از 20 تا 30 دقیقه به 5 دقیقه تبدیل خواهد شد.
دو راه کار وجود دارد: راه اول ساخت رکورد های AG Listener بصورت Static و جلوگیری از Auto Update که با راه کار قبل سازگاری ندارد! راه دوم در تکمیل راه کار اول ، ما که کاری کردیم فقط آدرس اکتیو در DDNS رجیستر شود، حال برای این رجیستریسن یک زمان کش دلخواه نیز مشخص کنیم:
پیشنهاد می شود به دلیل نیاز به Offline و Online کردن کلاستر در همان مرحله قبل این کار صورت گیرد:
Get-ClusterResource “DBProvince_DBProvince” -Cluster “DBProvince” | set-clusterparameter HostRecordTTL 300 -Cluster “DBProvince”
راه کار سوم:
گل آخر داستان استفاده از یک سوییچ در ConnectionString است، بطوری که با استفاده از این سوییچ اگر دو راه کار قبلی نیز ازدست ما در رفته باشد، این سوییچ به داد ما خواهد رسید بطوری که این سوییج مزایای زیر را فراهم خواهد کرد:
MultiSubnetFailover=True
اولا: کلاینت متوجه سناریوی پشت داستان است، و در صورتی که از DNS چند پاسخ بگیرد، سعی می کند به تمام پاسخ ها سر بزند پس مشکل اشاره شده ” ….اما کنسول SSMS آن را ساپورت نکرده و همواره دنبال آدرس اولی که DNS به عنوان پاسخ ارئه می داد رفته ….” حل خواهد شد.
ثانیا: در صورت رعایت راه کار یک و دوم، اگر کلاستر فیلآور کرده باشد و رکورد ها در DNS آنی آپدیت شده باشند، وکش رکورد هم 5 دقیقه باشد، و کلاینت در فاصله این 5 دقیقه بوده، در زمان مراجعه به AG Listener وقتی به کش DNS مراجعه کرده و پاسخی دریافت نمیکند، به دلیل استفاده از این سوییچ ، بصورت خودکار کش را نادیده گرفته و بصورت مستقیم به دنبال DNS خواهد رفت و مشکل کش حل خواهد شد.
برای شرکت در دوره جامع sql server کندو از اینجا اقدام نمایید.
