بررسی گزینه‌های پیکربندی پیشرفته پایگاه‌های داده

در این درس پیرامون تنظیمات پیشرفته و گزینه‌های اضافه‌ای که در حین کار با پایگاه داده نرم افزار اس کیو ال سرور مشاهده می‌شود توضیح داده شده است.

تنظیمات پیشرفته پایگاه داده

بنابراین، الان اجازه بدهید که درمورد بعضی از گزینه‌های اضافی که برای ایجاد پایگاه داده نیاز دارید بحث کنیم.
دوباره، در محیط SQL Server Management Studio، روی پایگاه داده‌ها یا databases کلیک راست می‌کنم و new database را انتخاب می‌کنم.
در سمت چپ یک صفحه باز می‌شود، زیر قسمت select a page، روی گزینه Options کلیک می‌کنیم، تقریباً optionهایی که هنگام ایجاد پایگاه داده دیدیم را می‌توانیم اینجا هم ببینیم. خیلی از مواقع همین مقادیر پیشفرض خوب هستند. اما اجازه بدهید که پیش برویم و در مورد یک تعدادی از آنها صحبت کنیم.

گزینه Collation

در قسمت بالا، گزینه Collation وجود دارد که یک منو کشویی نسبتاً بزرگی دارد و ما در آن انتخاب‌های متفاوتی می‌توانیم داشته باشیم. Collation تقریباً این را ترجمه می‌کند که ما چطور چیزها را در دستور قرار بدهیم. از اینرو، زمانی که ما یک database را query می‌کنیم، می‌توانیم آن را به ترتیب حروف الفبا بدست بیاوریم. ترتیب حروف الفبا در زبان‎های مختلف، متفاوت است. بنابراین، شما اگر به این لیست توجه کنید، تعداد زیادی از زبانهای مختلف را می‌بینید.
یک چیز تعجب آور این است که شما در این لیست، زبان انگلیسی را نخواهید دید. انگلیسی در لیست نیست.
در عوض، برای زبان انگلیسی پایگاه داده معمولاً ما با لاتین کار می‌کنیم. به این معنی که از الفبای لاتین استفاده می‌کنیم.
در اینجا تعدادی از گزینه‌های مختلف را برای زبان لاتین می‌بینیم. اگر شما می‌خواهید جزئیات دقیق‌تری از هر یک از آنها داشته باشید، می‌توانید به document یا هلپ مرجع مایکروسافت، مراجعه کنید.
اگر به آنها توجه کنید، می‎‌بینید که اکثراً از دو حرف تشکیل شدند، مانند CI یا CS.
CI بمعنای غیر حساس و CS به معنای حساس به حروف کوچک و بزرگ است. به عبارت دیگر، زمانی شما به لیست کلمات نگاه می‌کنید که قصد دارید ترتیب حروف الفبا را در QUERYهای خود در نظر بگیرید، تا به حال شده که به حروف بزرگ توجه کنیم؟ آیا توجه به این داشتیم که، حروف ما بزرگ است یا کوچک؟
case insensitive یا CI این موارد را برای حروف الفبا نادیده می‌گیرد، ولی case sensitive یا CS به این موارد توجه دارد، به طور مشابه شما AI به معنی غیرحساس به لهجه، و AS به معنی حساس به لهجه را هم می‌بینید.
بنابراین آن کنترل می‌کند که آیا برای کلمات الفبایی علایم لهجه در نظر گرفته شود یا نه.

گزینه Recovery model

برای recovery model شما سه option می‌بینید. full، bulk logged و simple.
Full recovery model مقادیر زیادی از اطلاعات را در LOG قرار می‌دهد، که در زمان ریکاوری بیشترین optionها را به ما می‌دهد. در واقع در زمان ریکاوری بیشترین اطلاعات را به ما برمی‌گرداند. اگر ما یک نسخه back up را restore کنیم، می‌توانیم در هر زمانی و هر نقطه‌ای که می‌خواهیم LOG را دوباره داشته باشیم. (همان طور که می‌دانیم تفاوت back up با restore در این است که در back up می‌توانیم یک نسخه از کل اطلاعات را روی یک حافظه دیگر ذخیره کنیم که اگر در آینده مشکلی برای اطلاعات پیش اومد یک نسخه دیگر داشته باشیم. اما restore به این معنی است که فایل را به آخرین تغییراتی که در هر ساعت و روز انجام دادی باز می‌گرداند.) بنابراین اگر ما یک back up را restore کنیم، می‌توانیم هر زمانی که خواستیم LOG را بازپخش و فراخوانی کنیم . بنابراین شما می‌توانید بازیابی‌های زیادی داشته باشید. هنگامی که شما database را restore می‌کنید، نیاز به این ندارید که دقیقاً در همان زمان یک back up بگیرید. اگر به تنظیمات تراکنش LOG دسترسی داشته باشید، می‌توانید تراکنش آنرا تنظیم کنید. یعنی با تراکنش LOG بالا بتوانید RESTORE های خود را خیلی زود زود ایجاد کنید، و در نتیجه فراخونی، اطلاعات زیادی را داشته باشید. و با تراکنش LOG پایین دیرتر عملیات RESTORE انجام بشود و نهایتاً بازیابی اطلاعات کمتری را خواهید داشت.
درمقابل full، simple است. simple حداقل اطلاعات را در LOG قرار می‌دهد و بنابراین زمانی که ما یک restore را انجام می‌دهیم، تنها در همان زمان قادر به restore هستیم که back up گرفته باشیم. پس simple، چون که اطلاعات خیلی کمی را در LOG می‌نویسد، عملکرد مفید آن پایین است.
و bulk logged یک حد میانه است، آن اطلاعات بیشتری از simple و کمتر از full را در log می‌نویسد. full recovery model اغلب به صورت پیشفرض قرار داده می‌شود، و مایکروسافت توصیه می‌کند که همه تولیدات database در تنظیم full recovery model انجام شود.
اما من اغلب برای توسعه و تست database از گزینه simple استفاده می‌کنم.

گزینه compatibility level

گزینه بعد compatibility level به معنی سطح سازگاری است.
به صورت پیش فرض روی sql server 2016 تنظیم شده و ما می‌توانیم آنرا به ورژن قبلی از sql server برگردانیم. زمانی که شما به یک database قدیمی که روی یک سرور قدیمی اجرا می‌شود نیاز داشته باشید، compatibility level یک ویژگی خوب محسوب می‌شود.
برای مثال یک sql server 2008 سرور باشد و شما بخواهید database را به سرور جدید خود منتقل کنید و نیاز داشته باشید که آن دقیقاً آنطور که قبل اجرا میشد، اجرا شود. شما می‌توانید فقط compatibility level را به هر سطح از server قبلی که خودتان می‌خواهید برگردانید. برای database جدید ما همیشه آنرا در جدیدترین سطح از compatibility قرار می‌دهیم، که sql server 2016 است.

گزینه containment type

آخرین حالت کشویی که وجود دارد containment type است.
حالت پیشفرض آن none است و برای اکثر تولیدات database مناسب است.
گزینه دیگری که برای آن وجود دارد، partial است و زمانی از partial استفاده می‌کنیم که شامل database باشد، بیشتر اطلاعات ورود بجای ذخیره در server level در database level ذخیره شده‌اند. این مورد زمانی استفاده می‌شود که شما نیاز داشته باشید به یک سرور جدید بروید.
اگر شما containment type را روی گزینه none تنظیم کنید، زمانی که بخواهید به یک پایگاه داده جدید حرکت کنید، باید بیش از چندین log-ins را کپی کنید. اما چون جابجایی از پایگاه داده خیلی نادر است و خیلی به ندرت برای ما اینکار پیش می‌آید که بخایم انجام بدهیم، پس من معمولاً این گزینه را خالی می‌گذارم.
اگر شما containment type را روی partial تنظیم کنید، احتمالاً نیاز پیدا نکنید که چیزهای زیادی را حرکت بدهید.

• ایجاد یک دیتابیس (پایگاه داده) جدید
• بررسی تخصصی ریبون و سربرگ های اکسس
• نحوه کار با ریبون اتوکد الکتریکال
• بررسی رابط کاربری یا user interface نرم افزار اتوکد الکتریکال
• جستجو و ویرایش کاتالوگ سازندگان Footprintهای پنلی موجود در دیتابیس با آپشن Footprint Database Editor و کادر محاوره‌ای footprint lookup

دیگر تنظیمات پایگاه داده

من همچنین دوست دارم که به optionهای اتوماتیک یک نگاه بیندازم.
خب، در اینجا چندین گزینه برای عملیات اتوماتیک وجود دارد، مثل
1- automatic statistics
2- automatic shrink
3- automatic close
من معمولاً اینها را هم به همان صورت پیشفرض رها می‌کنم، اما می‌خواهم، مختصر راجب به آنها صحبت کنم.
Automatically create statistics روی گزینه true تنظیم شده، این statisticsها برای دیتابیس‌ها به منظور بهینه کردن عملیات خاص استفاده می‌شود. به عبارت دیگر اگر یک جدول داشته باشیم که تنها دو سطر در آن باشد، مطمئناً وظایف خیلی متفاوت‌تر از این خواهد بود که چندین میلیون سطر در آن باشد، و با استفاده از automatically statistic ماشین همیشه می‌داند که سطرهای زیادی در هر جدول است. در واقع یک آماری از سطرها را به ماشین می‌دهد. من auto create statistics را روی همان true قرار می‌دهم
و auto update statistics را هم روی true.
ما همچنین auto close را هم داریم که روی false تنظیم شده و زمانی استفاده می‌شود که هیچ کس از دیتابیس استفاده نمی‌کند و دیتابیس در این حالت بصورت اتوماتیک بسته می‌شود و بعد از آن وقتی که درخواست بعدی برای استفاده از پایگاه داده می‌آید، آن به صورت اتوماتیک پایگاه داده را باز می‌کند. از آنجا که همیشه باید درگیر باز و بسته کردن یک پایگاه داده بشود، اکثراً آنرا به صورت false قرار می‌دهند، به این معنی که پایگاه داده ما تا زمانی که sql server در حال اجرا است، باز باشد.
Auto shrink به این معنی است که دستگاه به صورت دوره‌ای فایل را به کوچکترین اندازه ممکن کوچک کند، و زمانی که پایگاه داده رشد کرد، در صورت لزوم دوباره فایل‌ها رشد کنند. دوباره می‌گویم این یک سربرگ کلی در ارتباط با همه این کوچک و بزرگ شدن‌ها است. به طور معمول همه این auto shrink را به صورت false رها می‌کنند و بد نیست بدانید این ترافیک خیلی زیادتر از آن چیزی که ما می‌خواهیم بینیم را، در دیسک خود ما ایجاد می‌کند.
دوباره آپشن‌های متفاوت دیگری هم وجود دارد که ما در اینجا می‌توانیم انتخاب کنیم. برای تعداد زیادی از آنها، فقط حالت پیشفرض است که مناسب بوده و بهتر است که آنها را تغییر ندهیم و اگر شما جزئیات بیشتری در مورد هر کدام از این موارد می‌خواهید به دست بیاورید، مایکروسافت اطلاعاتی در این زمینه را به صورت داکیومنت در وب سایت خود قرار داده است که می‌توانید ببینید و از آنها استفاده کنید.