تنظیم منابع حافظه می­تواند در وقت شما صرفه جویی کند و عملکرد SQL Server را بهبود ببخشد

کاری که اغلب در زمان تنظیم یک سیستم جدید یا برنامه کاربردی SQL Server نادیده گرفته می­شود، برنامه ریزی صحیح ظرفیت است. با وجود اینکه قیمت حافظه هر 4 ماه یکبار کاهش می­یابد، می­توانید به راحتی به مدیر ذخیره سازی خود بگویید که به 500 گیگابایت حافظه نیاز دارید، اما شما واقعاً به دنبال چه چیزی هستید؟ آیا 500 گیگابایت حافظه به مدت 6 ماه ، 3 سال یا 10 سال دوام خواهد داشت؟ بدون پاسخ به این سوال به نتیجه­ی درستی نخواهيد رسيد. همچنین باید به سرعت ذخیره سازی هم توجه کنید. برخی از حافظه­ها گرانتر از بقیه هستند. گرچه ممکن است سازمان شما زیر بار خریدن حافظه جدید نرود، اما به عنوان یکی از کارکنان IT ، وظیفه شماست تا درستی استفاده از منابع سازمان را تضمین کنید. حال نگاهی به نحوه تشخیص میزان حافظه مورد نیاز ، نحوه پیکربندی دیسک ها و انواع حافظه های موجود می­اندازیم.


برنامه ریزی ظرفیت
آسانترین بخش برنامه ریزی ظرفیت، تعیین میزان فضای ذخیره­سازی است که بانک اطلاعاتی شما نیاز دارد. باید مقدار کلی بایت­هایی را که برای استفاده­ی بیش از n ماه نیاز دارید، را بفهمید. گرچه محاسبه این مقدار بایت ممکن است اندکی ترس آور به نظر برسد، اگر این مقدار را در هر جدول تفکیک کنید، آنقدرها هم ترسناک نیست. ابتدا، اندازه تمام جدول­­های جستجوی ایستا را بیافزائید. اندازه این جدول­ها ماه به ماه تغییر نخواهد کرد، بنابراین اگر تغییری داشتید می­توانید این مقدار را در انتها اضافه نمائید. در مورد جدول هایی که هر روز/ ماه/ سال افزایش اندازه پیدا می­کنند، باید با برخی از اطلاعات کلیدی آشنا شوید.

شما باید تعداد متوسط سطرهایی که در هر چرخه افزوده می­شوند، را بدانید. یک چرخه می­تواند یک روز، یک ماه یا یک سال باشد، بهرحال اغلب، این داده­ها وارد سیستم خواهند شد. اگر این سیستم یک سیستم بلادرنگ، مانند سیستم ورود سفارش، سیستم برچسب گذاری یا سیستم امنیت شبکه باشد، چرخه روزانه بهترین فرضیه است. همچنین باید طول متوسط هر سطر را بدانید. تولیدکنندگان احتمالاً می­توانند به این پرسش شما پاسخ دهند. همچنین، باید بدانید سیاست نگهداری اسناد بایگانی سازمان شما چیست. آیا می­خواهید اطلاعات را ماهانه، سالانه یا برای همیشه حفظ کنید؟ همچنین به برخی از اعداد ثابت هم نیاز دارید، در این مورد، تعداد کلی بایت­ها در هر صفحه داده­­ای در دیسک، 8060 است.

برخی از محاسبات اولیه تعداد کلی بایت­ها را در اختیار شما قرار می­دهند. برای این مثال، ما چرخه­ی روزانه 20.000 سطر با متوسط طول سطر 187 بایت و دوره 3 ساله برای نگهداری اسناد بایگانی را در نظر می­گیریم. اولین محاسبه­ای که لازم است انجام دهید، دانستن تعداد سطرهایی است که در هر صفحه داده­ای جای می­گیرند. این محاسبه به این دلیل مهم است که SQL Server نمی­تواند یک سطر را بین دو صفحه داده­ای تقسیم کند. سپس، تعداد بایت­های هر صفحه را حساب کرده و آن را به تعداد بایت­های هر سطر(187/8060) تقسیم کنید، در این صورت 101/43 سطر بازای هر صفحه داده­ای ارائه می­گردد. شما باید این تعداد را رنُد کنید، چرا که SQL تقسیم صفحه را که 43 سطر در هر صفحه داده­ای ارائه می­دهد، انجام نمی­دهد. سپس تعداد سطرهای هر چرخه(روزانه)را حساب کنید و آن را به تعداد سطرهای هر صفحه داده­ای تقسیم(43/20000) نمایید، که در این صورت عدد 11/465 ارائه می­گردد که تعداد صفحات داده­ای است که برای جدول نیاز دارید، همانطور که در جدول وب 2 می­بینید. از آنجائیکه نمی­توانید بخشی از یک صفحه داده­ای را داشته باشید، این عدد را به 466 صفحه داده­ای رند نمائید. گرچه هر صفحه داده­ای می­تواند تنها 8060 بایت را نگه دارد، در واقع خود صفحه داده­ای KB8 است. حال 466 صفحه داده­ای را در نظر بگیرید و آن را در KB8 ضرب کنید تا روزانه مقدار کلی داده­های افزوده شده به جدول را بدست آورید، که طبق جدول وب 3 ، KB3728 یاMB 64/3 است. اگر این عدد را به یک ماه گسترش دهید(5/30 روز به طور متوسط) ، بازای هر ماه MB 02/111 را دریافت می­کنید. حالا این عدد را در مدت نگهداری(3 سال) ضرب کنید تا طبق جدول وب 4، پس از 3 سال MB 72/3996 یا GB 9/3را دریافت نمائید.

پس از آنکه معین کردید که هر جدول چقدر فضای خالی نیاز دارد، عددها را بیافزائید تا کل فضایی را که در مدت زمان نگه داری برای بانک اطلاعاتی نیاز است را بدست آورید. اگر مدت زمان نگهداری شامل انتقال داده­ها به یک بانک اطاعاتي آرشیو به قصد گزارش دادن باشد، اندازه واقعی داده­ها کوچکتر خواهد بود، چرا که برخی از داده­ها از جدول­ها حذف می­شوند. پس از اینکه فهمیدید که داده­های شما به چقدر فضا نیاز دارند، باید به فکر سرعت و افزونگی دیسک هایی باشید که میزبان داده­های شما خواهند بود.

پیکربندی آرایه ­های RAID
RAID10 دارای سریع­ترین واکنش نوشتن است و هیچگونه سربار محاسبه توازن هم وجود ندارد. بهرحال، وقتیکه کاربران در مورد حافظه صحبت می­کنند، معمولاً یک نکته مهم را فراموش می کنند و آن قیمت است. گرچه RAID10 بهترین عملکرد را به شما ارائه می­دهد، اما یک تراز RAID بسیار گرانقیمت برای مصرف است. در بسیاری موارد باید از RAID10 استفاده کرد، اما مستقر کردن آن در تمام بانک­های اطلاعاتی به طور پیش فرض، معمولاً استفاده ناکارآمد از منابع حافظه را به دنبال خواهد داشت. اکثر بانک­های اطلاعاتی که برای حافظه RAID10 پیکربندی می­شوند، احتمالاً به خوبی در حافظه RAID5 کار می­کنند.

قبل از اینکه تصمیم بگیرید از چه نوع RAIDای استفاده کنید، لازم است تفاوت بین RAID5 و RAID10 را بدانید. RAID5 را مجموعه نواره­ای با توازن هم می­گویند. هنگامیکه داده­ها در دیسک نوشته می­شوند، محاسبه توازن در هر صفحه داده­ای انجام می­شود. این محاسبه توازن به همراه صفحه داده­ای در دیسک نوشته می­شود و توسط آرایه­ در مواقع خرابی دیسک استفاده می­شود تا هنگام تعویض دیسک خراب، آرایه بتواند داده­ها را مجدداً بسازد.
برخی از فروشندگان SAN تمام اطلاعات توازن را در یک دیسک قرار می­دهند و برخی دیگر، اطلاعات توازن را در تمام دیسک­ها در آرایه RAID منتشر می­کنند. گرچه هر دو تکنیک،یک تراز محافظتی مشابه را ارائه می­دهند، اما منتشر کردن توازن در تمام دیسک­ها در آرایه، سرعت آرایه را افزایش خواهد داد؛ چرا که از دیسک اضافی برای خواندن­ها و
نوشتن­ها استفاده می­شود.
RAID10 را نواره قرینه سازی شده هم می­گویند، تعداد دیسک­ها در آرایه نصف می­شود، هر نیمه وارد یک نواره می­شود، سپس این دو نواره در برابر یکدیگر قرینه سازی می­شوند. در مواقع خرابی دیسک، نواره­ای که شامل آن دیسک است، تا زمانیکه دیسک تعویض شود، بلااستفاده می­باشد و داده­ها از نواره­ی سالم در نواره­ی تازه تعمیر شده، قرینه سازی می­شوند. از آنجائیکه هیچ توازنی برای هر نوشتن محاسبه نشده، نوشتن­ها می­توانند سریع تر اتفاق بیافتند، بهرحال، از آنجائیکه تنها نیمی از دیسک­ها در آرایه RAID10 برای خواندن و نوشتن داده­ها استفاده می­شوند، برای داشتن همین مقدار ظرفیت، دو برابر این تعداد دیسک لازم است. تصویر 1 و 2 روش مستقر شدن آرایه­های RAID5 و همچنین نحوه مستقر شدن آرایه RAID10 در دیسک­های فیزیکی را نشان می­دهد.

تنظیم کَش
از جمله مواردی که باید هنگام کار کردن در یک محیط SAN به خاطر داشته باشید این است که SAN ، دارای کش بسیار زیادی است. با تنظیم این کش، امکان کش شدن مقدار زیادی از نوشتن­ها فراهم می­گردد، به عبارت دیگر زمانیکه SQL Server در دیسک خالی می­شود (flush) ، در واقع عمل نوشتن بر روی دیسک­ها را انجام نمی­دهد. در عوض SAN ، آن نوشتن را در کَش خود، کَش می­کند تا دفعه­ی بعد در دیسک­های واقعی خالی شود. به خاطر همین کَش کردن، تراز RAID هیچ معنی برای SQL Server ندارد، چرا که SQL Server در دیسک نمی­نویسد، بلکه در کَش می­نویسد.

به طور پیش فرض، در اکثر سیستم­های SAN ، تنظیم کَش به صورت 50 درصد کَش خواندن و 50 درصد کَش نوشتن است، گرچه این تنظیم برای چیزهایی مانند سیستم­های انبار داده­ها به خوبی کار می کند، اما برای بانک های اطلاعاتی OLTP چندان مطلوب نیست. SAN ها پیشاپیش از خواندن استفاده می­کنند تا اطلاعاتی را که سیستم میزبان بدنبال آن است، پیش بینی و آزمایش کنند و این اطلاعات را قبل ازآنکه میزبان واقعاً آن­ها را درخواست کند، در بافر خواندن، می­خواند. به این ترتیب، داده­ها از دیسک خوانده می­شود و SAN به سادگی می­تواند داده­ها را از کَش خواندن پخش کند. بهرحال، در برنامه کاربردی OLTP (مانند بانک­های اطلاعاتی، Exchange، سرورهای فایل) بخش­هایی از دیسک که باید خواندن از آن صورت بگیرد، به ندرت به شکل متوالی هستند. آنها معمولاً به صورت تصادفی در درایو قرار می­گیرند.
خواندن پیشاپیش، ممکن است در مقایسه با مزیتی که ارائه می­دهد، لود بیشتری هم بدنبال داشته باشد. بهتر است نسبت کَش خواندن به کَش نوشتن را از 50/50 به 70/30 یا 80/20 کاهش دهید. کاهش این نسبت، به SQL Server اجازه می­دهد تا داده­های بیشتری را در کش بنویسد، جائیکه واقعاً به سرعت نیاز دارد.

این تغییر کَش وضعیت را برای دیسک­های RAID5 بهبود می­بخشد. از آنجائیکه SQL Server زمانیکه عمل خواندن از دیسک­ها را انجام می­دهد، فقط با آنها صحبت می­کند، لازم است در صورت امکان اکثر دیسک ها، خواندن را پردازش کنند. با RAID10 تنها نیمی از دیسک­ها برای خواندن داده­ها استفاده می­شوند و با RAID5 تمام دیسک ها (یا اینکه همه غیر از یکی، بسته به نحوه اداره کردن RAID5 توسط فروشنده SAN) استفاده می­شوند.

تنظیم ذخیره سازی
علاوه بر تنظیم کَش، می­توانید کارهای دیگری را در LUN(Logical Unit Number) و تراز دیسک انجام دهید تا عملکرد را افزایش دهید. ممکن است بخواهید غیر فعال کردن کَش خواندن را در خود LUN تجربه کنید. این کار مانع از هر گونه کش اطلاعات از LUN در کَش SAN می گردد. دلیل آن هم این است که SQL Server اطلاعات زیادی را در کش متعلق به خودش در داخل RAM سرور، کش می­کند. SQL Server به ندرت برای گرفتن داده­هایی که برای شروع نیاز دارد به دیسک می­رود، وقتیکه این کار را انجام می­دهد، داده­ها در کش موجود نخواهند بود. و هنگامیکه داده در کش SAN هستند، در کش سیستم SQL Server نیز هستند. هنگامیکه کش خواندن را در LUN بانک اطلاعاتی خود فعال می­کنید، موفقیت اندکی در عملکرد حاصل می­شود. زمانیکه SQL Server خواندن­ها را در دیسک انجام می­دهد تا داده­هایی را که SQL Server بدنبال آنهاست در کش در دسترس قرار دهد، SAN تلاش خواهد کرد تا پیشاپیش خواندن را انجام دهد، بنابراین SQL Server برای دسترسی به داده­هایش نباید منتظر فراخوانی به دیسک فیزیکی باشد. به خاطر ماهیت تصادفی بانک­های اطلاعاتی OLTP ، شانس اینکه SAN بتواند داده­های صحیح را به کَش بکشد، تقریباً صفر است.

در سیستم­های OLTP، که دیسک از قبل فشرده می­شود، ممکن است فعال کردن کش خواندن اندکی بر روی عملکرد اثر بگذارد. بهرحال در سيستم­هایی که دیسک از قبل فشرده نشده است، فعال گذاشتن کَش خوان، تاثیر منفی بر عملکرد نخواهد داشت.
در تراز دیسک، بخش تنظیم حافظه که اغلب نادیده گرفته می شود، به خوبی دیسک را هم تراز و مرتب می­کند. هنگامیکه مجموعه مشخصات مربوط به رکورد اصلی راه اندازی (MBR) نوشته می­شد، حافظه بسیار گرانقیمت بود. بنابراین MBR به گونه­ای تنظیم شد تا 63 بلوک در دیسک داشته باشد، بنابراین اولین بیت داده­ها به بلوک 64 می­رود. این تنظیم مشکل ساز است چرا که دیسک­ها دوست دارند همه کارها را در بلوک 64 انجام دهند. بنابراین از آنجاییکه داده­ها هم اکنون توسط بلوک 1 offset می­شوند، هر بار که SQL Server بخواهد بخواند یا بنویسد، دو برابر این عمل­ها باید انجام شود. در برنامه­های کاربردی مانند Microsoft Exchange یا Oracle ASM که تمام فعالیت دیسک در خواندن ها و نوشتن­های 8KB (بلوک 8) انجام می­شود، این اثر چندان هم مشهود نیست. اما SQL Server تمام دسترسی­های دیسک خود را در خواندن­های (بلوک 64) 64KB انجام می­دهد. اثر ویژه این است که هر عمل خواندن و نوشتن مستلزم دو برابر عمل فیزیکی در دیسک است.

اگر دیسک با استفاده از ابزار خط فرمان diskpart.exe در Windows Server2008 و Windows Server 2003 ساخته شود، این مشکل را می­توان نسبتاً حل کرد. پس از آنکه LUN به سرور نمایش داده شد، وارد (log on) سرور شوید و diskpart.exe را از پنجره خط فرمان اجرا نمائید. سپس فرمان

SELECT DISK 3

را اجرا نمائید. عدد 3، شماره دیسک است که به سرور اضافه کرده­اید. سپس فرمان زیر را اجرا نمایید
CREATE PARTITION PRIMARY ALIGN=64

این فرمان یک پارتیشن اصلی در دیسک می سازد، به همراه تنظیم تراز در بلوک 64 دیسک به جای بلوک 63 دیسک. این کار را برای هر LUN ای که به سرور نمایش داده می­شود، انجام دهید.
اگر LUN هایی دارید که به درستی تراز نشده­اند، انجام این تغییر چندان هم آسان نیست، چرا که ابزاری برای تصحیح این تراز پس از اینکه پارتیشن ساخته شد، وجود ندارد. ساده ترین روش، پشتیبان گیری از بانک اطلاعاتی و حذف این بانک اطلاعاتی از سرور است.

مرحله­ ی بعدی حذف پارتیشن و ساختن مجدد آن با تراز صحیح است. بعد بانک اطلاعاتی را روی دیسک کپی کنید. برخی از فروشندگان SAN دارای ابزارهای مهاجرت client-side هستند که می­توان از آنها برای انجام این فرآیند به شکل آنلاین استفاده کرد. یک نرم افزار شخص ثالث برای انجام این فرآیند وجود دارد. بهرحال، از ابزار مهاجرت خادم SAN استفاده کنید، چرا که این ابزار، تمام داده­ها از جمله اطلاعات پارتیشن نامرتب و تراز نشده را کپی خواهد کرد.

همه چیز مشترک، هیچ چیز مشترک
برای تنظیم حافظه، دو تکنیک اولیه وجود دارد: همه چیز مشترک و هیچ چیز مشترک. با تکنیک همه چیز مشترک، تمام دیسک­ها در SAN برای هر LUN استفاده می­شوند. اگر چه این تکنیک فوق العاده به نظر می­رسد، اما دارای ایرادهایی است. اگر هر یک از دیسک­ها در آرایه کند شود، هر LUN ای در آرایه تحت تاثیر قرار می گیرد.
روش همه چیز مشترک، در صورتی خوب است که مجری تمام وقت SAN نداشته باشید، چرا که به جز ساختن LUN ها و انتقال آنها به حافظه، کار چندانی وجود ندارد.
با روش هیچ چیز مشترک (یا بهتر بگوييم برخی چیزهای مشترک)، LUNها در گروه­های کوچکتر در SAN ساخته می­شوند. تعداد اندکی از دیسک­های فیزیکی در گروه­های RAID با پیکربندیها و سایزهای مختلف ساخته می­شوند. نکته خوب درباره این پيکربندي آن است که اگر یک دیسک یا LUN خاص موجب کندی شود، تنها LUN هایی که تحت تاثیر قرار می­گیرند آنهایی هستند که در گروه RAID آن LUN قرار دارند.

اشکال این سیستم آن است که مستلزم پیکربندی hands-on بیشتر و دانش بیشتر در مورد ترازهای I/O است که باید از آنها پشتیبانی کنید. نکته مثبت این است که اگر LUN به I/O بیشتری نیاز داشته باشد، می­توانید آن را به گروه RAID دیگر انتقال دهید یا اینکه آن را به بیش از یک گروه RAID گسترش دهید تا توان عملیاتی I/O بیشتری به آن اختصاص دهید.

SAN در مقابل DAS
امروزه، SAN پادشاه جهان حافظه است. SAN بسیار سریع و معمولاً متشکل از صدها درایو Fibre Channel است، تمام این درایوها از طریق کابل­های فیبر آخرین مدل، به سرور وصل می­شوند. بهرحال، راهکارهای SAN بسیار گران قميت هستند، و اغلب برای شروع صدها هزار دلار خرج بر می­دارند.
این موضوع ما را به DAS می­رساند. DAS یک راهکار فوق العاده است، در صورتیکه شرکت شما به راهکار مقیاس بالای SAN نیاز نداشته باشد، DAS تقریباً تمام قابلیت­های یک SAN را ، فقط در تراز کوچکتر و معمولاً با کش کمتر ارائه می­دهد. دستگاه­های DAS متشکل از 2 تا 45 درایو SCSI ، SAS یا SATA هستند، به همراه چند مگابایت کش تا چند گیگابایت کش.
تمام گزینه­های پیکربندی SAN معمولاً در DAS هم وجود دارند، از جمله توازن کش خواندن و کش نوشتن. درست مانند درایوهای SAN ، درایوهای DAS هم به تراز (مانند تمام آرایه RAID) نیاز دارند.

برخلاف SAN ، DAS معمولا امکان کنترل تنظیمات کش در یک تراز دیسک به دیسک را به شما نمی­دهد. همچنین، سیستم­های DAS به یک سرور خاص وصل می­شوند، بنابراین برخلاف SAN، نمی­توانید بیش از یک سرور متصل به DAS داشته باشید.
بزرگترین ایرادهای استفاده از DAS برای بانک­های اطلاعاتی، عدم پتانسیل رشد است، چرا که یک محدودیت فیزیکی در تعداد دیسک­هایی که می­توانید در یک DAS قرار دهید، وجود دارد؛ و این حقیقت که شما نمی­توانید منابع خود را با چندين سرور با دستگاه­های DAS شریک شوید. مشگل دیگر این است که ممکن است با دستگاههای DAS داشته باشید این است که شما نمی­توانید یک آرایه RAID را فراتر از تعداد دیسک­های موجود در یک قفسه درایو گسترش دهید. اکثر قفسه­های درایو DAS ، پانزده درایو را نگه می­دارند و هر قفسه درایو به یک کنترل کننده RAID وصل می­شود. از آنجائیکه کنترل کننده­های RAID با یک دیگر سخن نمی­گویند، نمی­توانید بین قفسه­های درایو از RAID استفاده کنید. بهرحال، این ایرادها از طریق هزینه­ بسیار جذاب ورودی، جبران می­شوند. حافظه DAS در مقایسه با هزینه خرید یک راهکار SAN ، ارزانقیمت است.

iSCSI و بانک اطلاعاتی
یک فن آوری جدیدتر حافظه که به تازگی وارد جهان بانک اطاعاتي شده است، iSCSI می­باشد. iSCSI از اِترنت موجود شما برای اتصال بانک اطلاعاتی به حافظه استفاده می­کند. بسیاری از فروشندگان SAN هم اکنون iSCSI را به عنوان بخشی از سيستم­های SAN به حساب می­آورند. مزیت iSCSI این است که شما کیفیت حافظه SAN را بدون هزینه اضافی Fibre Channel دریافت می­کنید و ایراد iSCSI این است که ترافیک حافظه شما باید برای پهنای باند با ترافیک معمول اِترنت رقابت کند. اگر دارای شبکه اِترنتی کُند یا بسیار مشغول هستید، احتمالاً iSCSI راه حل شما نیست. به دلیل آنکه ترافیک حافظه شما به شبکه TCP می رود، مشکل احتمالی دیگر iSCSI این است که باید به سراغ تنظیمات timeout ، TCP بروید.

اگر آرایه حافظه شما به دلایلی خراب شد، Fibre Channel به سرعت time out خواهد شد و مسیر دیگری را آزمایش می­کند. بهرحال، timeout مربوط به بسته­های TCP ، بسیار بالاتر است، که در بانک اطلاعاتی شما به شکل بلوکه شدن یا پردازش timeout نمایانگر می شود.
برای پرداختن به مسائل مربوط به پهنای باند شبکه، مهندسان شبکه از تکنیکی به نام VLANing برای جداسازی و ایزوله کردن ترافیک شبکه استفاده می­کنند.

VLANing خاطر نشان می کند که ترافیک شبکه iSCSI شما از بخش­­های دیگر شبکه شما جدا شود. این جداسازی یک جداسازی منطقی سگمنت­های شبکه در Visual LANها (VLANs) در لایه دوم Open Systems Interconnection(OSI)Refrence Model است. VLAN یک حوزه منطقی در سوئیچ شبکه است که فقط ترافیکی را مجاز می­داند که برای دسترسی به آن VLAN که شبکه سویچ می­کند، برچسب گذاری شده است. ترافیک داخل یک VLAN ، شامل ترافیک پخش، جداگانه در آن VLAN نگه داری می­شود. هر ترافیکی به مقصد VLAN دیگر، باید مسیریابی شود. این کار مانع از تاثیر گذاری ترافیک شبکه غیر iSCSI بر ترافیک iSCSI و مانع از تاثیر گذاری ترافیک iSCSI بر ترافیک غیر iSCSI می­گردد. VLANing در لایه 2 کار می کند و ترافیک را فقط در لایه جدا می­کند. برای جداسازی بیشتر ترافیک، در مورد برنامه­های کاربردی که مستلزم سوئیچ کردن و مسیریابی لایه 3 هستند، VLAN ها می توانند با یک زیر شبکه مسیریابی در ارتباط باشند و به این ترتیب به ترافیک حوزه­های منطقی (VLANs) اجازه می­دهند با VLANهای دیگر در ارتباط باشند.
بعلاوه، مسیریابی لایه 3 را می­توان با یک ACL پیکربندی کرد تا یا مانع از ارتباط ترافيک خاص در زیر شبکه­های خاص با یک دیگر شود یا اینکه این ارتباط را مجاز بداند. تکنیک­های دیگر در لایه 4 و لایه 5 هم موجود هستند، اما در مجال این مقاله نمی­گنجند.

کسب بهترین عملکرد از SQL Server
احتمالاً تنظیم و پیکربندی دیسک­های فیزیکی برای کسب بهترین عملکرد از سرور، کاری ضروریست. این مسئله در مورد SQL Server ( یا هر سرور بانک اطلاعاتی) صدق می­کند چراکه سرورهای بانک اطلاعاتی با سرعت و کمیت بسیار بالاتر در مقایسه با سرورهای موجود دیگر، داده­ها را از دیسک می­خوانند و یا بر روی دیسک می­نویسند. بنابراین شما می­خواهید مطمئن شوید که هنگام پیکربندی حافظه، به تمام مسائل پرداخته می­شود، بخصوص وقتیکه به زمان انجام گرفتن این تغییرات پس از اجرا توجه دارید.

برگردان : مهسا قنبری
منبع : مجله رایانه