هشت اشتباه بزرگ در SQL Server!

هشت اشتباه بزرگ در SQL Server!

نوشته شده توسط: حمید فرد
۳۱ مرداد ۱۳۹۴
زمان مطالعه: 7 دقیقه
۱
(۱)

مقدمه

نصب و راه اندازی SQL Server به واسطه وجود Wizard Installation توسط مایکروسافت در این سالها بسیار آسان شده است. به صورت پایه ای چند عملیات باید قبل و بعد از نصب SQL Server بر روی سیستم سخت افزاری و تنظیمات SQL Server توسط مدیران پایگاه داده انجام شود تا از نبود اشکالات پایه ای اطمینان حاصل نمایند. بر اساس تجربه کاری بنده برخی از مشکلات اساسی SQL Server از انجام ندادن این عملیات قبل و بعد از نصب و راه اندازی است.

هیچ وقت این اشتباهات را انجام ندهید. اشتباهات جدید دیگری هستند….

اشتباه ۱: نصب و راه اندازی SQL Server بدون انجام تست های سخت افزاری و نرم افزاری بر روی دیسک سخت.
اصولا مدیران پایگاه داده باید سیستم سخت افزاری اعم از دیسک سخت و قدرت پردازنده را برای استفاده در محیط SQL Server ارزیابی کنند و این ارزیابی باید دقیقأ به صورت باشد که SQL Server از این دو منابع استفاده می کند.

اشتباه ۲: استفاده از تنظیمات پیشفرض در SQL Server.
مدیران پایگاه داده در همه حال از تنظیمات پیشفرض در SQL Server استفاده میکنند. همیشه به یاد داشته باشید که تنظیمات در هر محیط سخت افزاری و طرز استفاده از SQL Server متفاوت است.

اشتباه ۳: استفاده از Primary Filegroup در پایگاه های داده
مدیران پایگاه داده اصولا باید تمامی داده های کاربران را از داده های سیستمی جدا کنند. این عمل چند فواید به همراه دارد.

اشتباه ۴: قرار دادن فایل داده و تراکنش در یک درایو.
قرار دادن این دو فایل بر کاهش سرعت تراکنش و استفاده از منابع سیستم تأثیر بسیاری دارد.

اشتباه ۵: کم حجم کردن فایل تراکنش.
این بدترین عملی است که یک مدیر پایگاه داده می تواند انجام دهد به این صورت که اول Recovery Model را به Simple تغییر داده و بعد فایل تراکنش را کاهش داده و بعد Recovery Model را به Full تغییر داده و در آخر بدون گرفتن Backup پایگاه داده را به امید خدا رها کند. این عمل زنجیره تراکنش را در پایگاه داده از بین میبرد و باعث می شود که در هنگام اختلال و خرابی دیگر نتوانیم داده ها را تا زمان قبل از خرابی بازیابی کنیم.

اشتباه ۶: فعال سازی Auto_Close در پایگاه داده
این تنظیمات استفاده از دیسک سخت را افزایش داده و سرعت کلی سیستم را پایین می آورد.

اشتباه ۷: استفاده و فعال سازی Auto_Growth در پایگاه داده.
این تنظیمات باعث میشود که فایل تراکنش به صورت اصولی و مرتب ساخته نشود.

اشتباه ۸: گرفتن فایل پشتیبان پایگاه داده بدون تست کردن.
گرفتن فایل پشتیبان بر اساس RTO و RPO به تصویب رسیده از طرف مدیریت سازمان بسیار کار پسندیده و عالی است اما در خیلی از موارد مدیران پایگاه داده فایل پشتیبان را تست نکرده و در هنگام بازیابی بعد از اختلال یا خرابی به خطا هایی همچون «فایل پشتیبان خراب است» برخورد می کنند که دیگر برای دانستن این موضوع خیلی دیر است.

چه رتبه ای می‌دهید؟

میانگین ۱ / ۵. از مجموع ۱

اولین نفر باش

title sign
برچسب ها
title sign
معرفی نویسنده
حمید فرد
مقالات
6 مقاله توسط این نویسنده
محصولات
0 دوره توسط این نویسنده
حمید فرد
پروفایل نویسنده
title sign
دیدگاه کاربران

    • سلام.
      از بابت مقاله ممنون. از این به بعد به نکات فوق توجه بیشتری می کنم.
      اگر امکان دارد مورد ۷ رو بیشتر توضیح دهید.
      ممنون.

      •  در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File (VLF) که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.

        • ممنون از توضیحات خوبتون.
          موفق باشد.

    •  مسعود طاهری: ممنون.

      مجتبی شهریور: باز کردن مسایلی از این قبیل در مقاله نمی گنجه. چون توضیحات تمام اشتباهات باید در قالب یک دوره آموزشی باشد. 
      تورج عزیزی:
      اصولا در حال حاضر ما دو شرکت سازنده پردازنده داریم Intel و AMD. به دلیل استفاده SQL Server از دستورات منتطقی بسیار سنگین Intel اولین و بهترین پیشنهاد است. دوم اینکه قدرت پردازنده به مقدار حافظه داخلی آن باید به نسبت خوبی باشد (البته این نکته فقط برای SQL Server نیست). سوم اینکه در سالهای گذشته پردازنده ها یک قابلیت جدیدی داشتند که هر هسته در یک لحظه ۲ عدد نخ را اجرا می کرد که این در SQL Server 2005  و  SQL Server 2008 باعث بروز Deadlock می شد. که در حال حاضر برطرف شده است.
      متاسفم اگر غلط املایی دارم!
      • جناب مهندس فرد سلام
        وقت شما بخیر.
        بابت مقاله ی خوبتون همانند سایر دوستان از شما تشکر میکنم. هرچند فقط در حد تلنگری بود تا کاربران استفاده کننده از SQL SERVER با دقت بیشتری موارد خاص را در نظر بگیرند. متاسفانه سایت شما (دراین آدرس) باز نمیشه، چنانچه کانال های ارتباطی وآموزشی دیگری از خود دارید لطفاً معرفی نموده تا کاربران داخل ایران هم از تجربه و تخصص به اشتراک گذاشته شده شما دوست عزیز استفاده کنند.
        با توجه به حوزه تخصصی شما، انشا… شاهد مقالات تخصصی تری در این زمینه ازتون باشیم.
        با آرزوی شادی و شادکامی برای شما دوست عزیز.
        •  ممنون از نظرتون. البته این تلنگر نه بلکه یک سیلی بود 🙂 به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته باید ببینیم آقای طاهری چی دستور می دن!

          اون وبسایت خیلی وقت هست که بسته شده. من دیگه در لینکداین مطالب میگذارم. 
    • سلام
      مقاله بسیار خوبی بود ولی بخشید نقد میکنم ولی فقط جهت بهتر شدن مقالات هست اونم اینکه ای کاش یه کم کمتر کلی گویی می فرمدین و بیشتر مسائل را باز می فرمودین

    •  حمید جان مقاله شما عالی بود

      در صورت امکان در آینده هر کدام از این موضوعات را در یک مقاله جداگانه ارائه دهید تا دوستان بتوانند استفاده کنند
    •  تورج جان سلام

      این کتاب دید خیلی خوبی در زمینه سخت افزار برای حوزه SQL Server به شما می دهد. مطالعه اون را به همه دوستان توصیه می کنم
    •  تورج جان سلام

      این کتاب دید خیلی خوبی در زمینه سخت افزار برای حوزه SQL Server به شما می دهد. مطالعه اون را به همه دوستان توصیه می کنم
      •  سلام

        بابت معرفی این کتاب ارزشمند بسیار ممنون از شما.
        موفق باشید.
    •  سلام

      با تشکر از مقاله مفیدتون،
      اگر امکانش هست بگید چرا برخی CPU های خاص برای SQL Server پیشنهاد می شود؟
    • تهیه نسخه 

      enterprise core license
      مستلزم پرداخت هزینه و… می باشد. (از نمایندگی های مایکروسافت در خارج از ایران تهیه کنید)
      در ضمن پس از تهیه لاینس باید مجدد SQL Server را Change کنید.
    •  بلی این دو دستور تفاوتی ندارد چون خود دستور Delete به تنهایی Autocommit Transaction است اما در برخی مواقع سناریوهایی دیده ام که داده های زیادی بنا به دلایلی از سیستم پاک می شود یا حتی Update می شود در این گونه مواقع می توان با انجام این نوع کارها تا حدودی از افزایش حجم لاگ جلوگیری کرد. (تهیه لاگ بکاپ یا Chekpoint با توجه به Recovery Model) 

      در تکمیل صحبت های حمید

      –نظارت بر فضای لاگ فایل
      DBCC SQLPERF(LOGSPACE)
      GO

      –مشاهده وی ال اف ها
      DBCC LOGINFO
      GO

      –مشاهده لاگ رکوردها
      SELECT * FROM fn_dblog(NULL,NULL)
      GO

    • جناب مهندس فرد سلام
      وقت شما بخیر.
      بابت مقاله ی خوبتون همانند سایر دوستان از شما تشکر میکنم. هرچند فقط در حد تلنگری بود تا کاربران استفاده کننده از SQL SERVER با دقت بیشتری موارد خاص را در نظر بگیرند. متاسفانه سایت شما (دراین آدرس) باز نمیشه، چنانچه کانال های ارتباطی وآموزشی دیگری از خود دارید لطفاً معرفی نموده تا کاربران داخل ایران هم از تجربه و تخصص به اشتراک گذاشته شده شما دوست عزیز استفاده کنند.
      با توجه به حوزه تخصصی شما، انشا… شاهد مقالات تخصصی تری در این زمینه ازتون باشیم.
      با آرزوی شادی و شادکامی برای شما دوست عزیز.
هر روز یک ایمیل، هر روز یک درس
آموزش SQL Server بصورت رایگان
همین حالا فرم زیر را تکمیل کنید
دانلود رایگان جلسه اول
نیک آموز علاوه بر آموزش، پروژه‌های بزرگ در حوزه هوش تجاری و دیتا انجام می‌دهد.
close-link
وبینار رایگان ۳ راهکار هک نشدن SQL Server  یک شنبه ۲۳ اردیبهشت ساعت ۱۱
ثبت نام رایگان
close-image