شما یک SQL Server Database Administrator هستید و سازمان شما قصد داره پروژه جدیدی رو شروع کنه، از شما به عنوان DBA درخواست میشه تا دیتابیس سرور جدید رو راه اندازی کنید در عین حال بهتون اعلام میشه که سرور جدید به همراه SQL Server نصب شده وجود داره. وقتی شما این موضوع رو می شنوید، قطعا باید مخالفت کنید و انتظار داشته باشید SQL Server توسط شما که متخصص اینکار هستید نصب بشه. در این مطلب چند نکته درمورد اینکه چرا باید راه اندازی سرور SQL Server توسط یک متخصص انجام بشه بیان میکنیم.
در طی سالها، SQL Server از یک پایگاه داده رابطه ای ساده به یک پلتفرم جامع دیتا تبدیل شده. 10 ، 12 سال پیش وجود سازمان هایی که بدون داشتن DBA از پایگاه داده SQL Server استفاده می کردند کاملا عادی بود.
این روزها من از برنامه نویس ها و مدیران سیستم میشنوم که میگن، ما اگر بخواهیم از سیستم با کارایی بالا استفاده کنیم میریم سراغ اوراکل و SQL Server رو برای سیستم های سادمون استفاده میکنیم. بله این حرف در زمان SQL Server 7 , اوراکل 8 درست بود چون اوراکل مزیت هایی داشت که البته بکارگیریش هم مشکلات خاص خودش رو داشت. اما امروزه هر دو سیستم قابلیت های یکسانی ارائه میدن با هزینه های متفاوت. تو دنیای آزاد با قوانین کپی رایت اگر شما بخواهید قابلیت های ارائه شده در SQL Server رو در اوراکل استفاده کنید باید هزینه بیشتری پرداخت کنید.
ما به عنوان DBA میدونیم که SQL Server چقدر تغییر کرده ولی همچنان تو دنیای IT تصور میشه که SQL Server تو سطح پایین تری از اوراکل قرار داره، به ویژه از دید کسانی که به لینوکس نزدیکتر هستند و همین این باعث شد که SQL Server نسخه لینوکسی خودش رو هم معرفی کنه.
اگر شما تجربه نصب SQL Server 2000 رو داشته باشین، میدونین که فرآیند نصب تو نسخه های جدید رفته رفته پیچیده تر شده. اما به همراه این پیچیدگی ماکروسافت سادگی فرآیند نصب رو برای شما فراهم کرده، منظورم اینکه هنوز هم میشه با چندتا کلیک Next پایگاه داده رو نصب و راه اندازی کنید چیزی که در اوراکل تقریبا غیر ممکنه. اما یادمون باشه نصب پایگاه داده SQL Server چیزی بیش از زدن چند کلیک و بالا آوردن Engine SQL Server هست.
یکی از بخش های مهم که تاثیر مستقیم تو کارایی و عملکرد پایگاه داده داره Storage هست. جدا از مساله فضای مورد نیاز برای نگهداری فایل های دیتابیس، فرد که مسئول نصب راه اندازی دیتابیس هست باید در مورد تعداد دیسک ها و نحوه صحیح کانفیگ کردن اونها تصمیم بگیره ، برای درک کامل این موضوع مطلب Hard Drive Configurations for SQL Server رو بخونین.
بعد از انتخاب درست دیسک ها، DBA باید دیسک ها رو با اندازه درست فرمت کنه - allocation unit size، این بستگی داره که اون دیسک قرار هست برای Data file ها استفاده بشه یا Log file ها . بحث کامل تر در این مورد رو از Format drives with correct allocation and offset for maximum SQL Server performance بخونین.
بعد از تمام مراحل بالا حالا وظیفه دارین که تست های Response time رو روی دیسک ها انجام بدین. برای اینکار ابزاری های مثل SQLIO وجود داره که میتونین با این لینک باهاش آشنا بشین : Benchmarking SQL Server IO with SQLIO.
آخرین مرحله برای تنظیم Storage، فعال کردن تنظیم Instant File Initialization هست، این قابلیت از نسخه های قبل هم در SQL وجود داشت اما در مراحل نصب اخیرا اضافه شده، اگه این قابلیت رو فعال نکنین وقتی که دیتابیس نیاز پیدا میکنه سایز فایل هاش رو افزایش بده زمان بیشتری صرف میکنه تا فضاهای خالی دیسک رو شناسایی کنه. درواقع SQL Server قبل از گرفتن فضا دیسک مورد نیازش، اول اون فضا رو با 0 پر میکنه. برای مثال وقتی نیاز به دیسک برای creating/restoring دیتابیس یا growing/allocating فایل های دیتا و لاگ داره. تنظیم این قابلیت از انجام اینکار جلوگیری میکنه و معمولا باعث بهبود زمان میشه. برای درک بهتر این موضوع مطالب Effect of Instant File Initialization within SQL Server و Configuring Windows Instant File Initialization for SQL Server 2005 رو بخونین.
همیشه این فکر رو کردیم که این بخش اصلا مهم نیست، اما اشتباهه. به ویژه برای سیستم ادمین هایی که دانش عمیقی از SQL Server ندارن. گاهی لازمه اینستنسی که نصب میکنید اسم مخصوص خودش رو داشته باشه، اگه گزینه پیش فرض رو انتخاب کنید در واقع اینستس SQL رو همنام با نام سرور قراردادین و این موقع راه اندازی اپلیکشن ها شمارو دچار مشکل میکنه. در اون صورت راهی وجود نداره جز نصب مجددا SQL Server. پس موقع نصب فقط کلید Next رو فشار ندید و اسم مناسبی برای اینستنسی که نصب میکنین انتخاب کنین.
کدوم یک از ما ندیدیم سازمانی رو که فقط از Database engine استفاده میکنه اما قابلیت های مثل Reporting Service ، Integration Service و حتی Analysis Service رو نصب کرده ؟ حتی وقتی یه متخصص SQL Server هم نصب رو انجام داده این اتفاق میوفته!
خب مشکل نصب سرویس هایی که هرگز ازشون استفاده نمیکنیم چیه ؟ این سرویس ها معمولا به صورت اتوماتیک اجرا میشن و منابع سیستم رو اشغال میکنن. پس توجه کنین وقتی دارین یه Production Server راه اندازی میکنین فقط باید سرویس های مورد نیاز رو نصب کنین که در اکثر مواقع فقط Database Engine مورد نیاز خواهد بود.
وقتی SQL Server رو با تنظیمات پیش فرض نصب میکنین، باعث میشه نصب با Service account انجام بشه، تو خیلی از سازمان های کوچیک و بزرگ از اکتیودارکتوری یا ابزاری شبیه به اون برای مدیریت اکانت های کاربری استفاده میشه، اگه SQL رو با اکانت لوکال نصب کنین در ادامه راه اندازی امکان شناسایی دامین اکانت برای اون وجود نخواهد داشت چون SQL نمیتونه SPN دامین رو شناسایی کنه.
از طرف دیگه، افرادی هم وجود دارن که ادمین دامین رو به عنوان سرویس اکانت استفاده میکنن تا خیالشون بابت داشتن دسترسی های لازم راحت باشه، اما برای مثال اگه xp_cmdshell فعال باشه یک کاربر براحتی میتونه سرویس رو به طور کامل shut down کنه.
پایگاه داده SQL دو روش authentication رو فراهم میکنه، Windows authentication که به شما امکان لاگین به SQL رو بصورت مستقیم با اکانت ویندوزتون میده و Mixed mode که امکان استفاده از SQL Server لاگین رو هم ایجاد میکنه.
به طور پیش فرض SQL Server از مدل اول استفاده میکنه، اما استفاده از این حالت قالبا با استفاده از کابر دامینی ویندوز همراهه که همونطور که بالا گفتیم نیمتونه امن باشه. اگه انتخاب کنید که از Mixed mode استفاده کنید، باید از نکات امنیت اون آگاه باشین، برای درک بهتر مطلب Best Practices to Secure the SQL Server sa Account and Different ways to secure the SQL Server SA Login رو بخونین.
نصب SQL Server از شما میخواد که کاربر یا گروه کاربری رو به عنوان ادمین اینستنس معرفی کنید، یعنی قرار تعیین کنید چه کسی دسترسی نامحدود به پایگاه داده داره، کسانی که اطلاعات درستی از امنیت SQL Server ندارن یک گروه ادمین تعریف میکنن و حتی بدتر یک گروه دامینی ادمین تعریف میکنن، برای اینکه بدونین چرا این اشتباهه مطلب Security Issues with the SQL Server BUILTIN Administrators Group رو بخونین.
این مرحله جایی که اگه رهاش کنین و درست تنظیمش نکنین تمام کارهای قبلیتون بی فایده میشه، هدف از انتخاب دیسک جدا، فرمت دیسک و تمام کارهایی که تاحالا کردیم، تنظیم محل قرارگیری فایل های mdf , ldf بود ، پس این بخش رو مطابق تقسیم دیسکی که انجام دادین پیش ببرین و محل قرارگیری لاگ فایل ها و دیتا فایل ها تفکیک کنین.
انتخاب محل درست قرارگیری TempDB برای SQL Server خیلی حیاتی هست.
تا نسخه SQL 2016 ، شما فقط میتونستین یه دیتا فایل برای TempDB ایجاد کنید، اما الان میتونین هر تعداد فایل مورد نیاز رو اضافه کنید. اینکه گفته میشه برای هر cpu core باید یه TempDB ایجاد بشه تصور غلطیه ، برای درک بهتر این موضوع SQL Server tempdb one or multiple data files و Tempdb Configuration Best Practices in SQL Server رو بخونین. موضوع کمی پیچیده تر از انتخاب یک فایل برای هر هسته CPU هست .
گفتیم که انتخاب نادرست درایوها تمام زحماتمون رو به باد میده، انتخاب درست Collation هم به همین میزان مهمه، چون داریم به Engine SQL قوانین sort کردن و همینطور Case و Accent Sensitivity رو میگیم. این خیلی به زبان مورد استفاده در پایگاه داده و رفتار اپلیکشن بستگی داره ، آیا کوچیک بزرگ بودن کارکترها مهمه ، املاء اونها مهمه ؟ و جدی تر از همه ترتیب مرتب کردن حروف اون زبان هست. مثل مشکل ی و ک که ما توی زبان فارسی داریم. جزئیات بیشتر در این مورد Changing SQL Server Collation After Installation and How to change server level collation for a SQL Server Instance
منبع :
