a

ABLY مقالات و مطالب مجموعه

آموزش SQL Server 2014

آموزش SQL Server 2014

بسم الله الرحمن الرحیم

آموزش SQL Server 2014

انشالله سعی خواهیم کرد در این دوره آموزشی برخی از مفاهیم و امکانات جدید SQL Server 2014 را بررسی کنیم.

در ابتدا برخی از مفاهیم پایه را بررسی خواهیم کرد و سپس در خصوص تغییرات ایجاد شده در نسخه جدید SQL Server بحث خواهیم کرد.


delayed durability

SQL Server 2014 ویژگی های زیادی را معرفی کرده است یکی از این ویژگی ها Delayed Transaction Durability که در  performance و یا همان عملکرد SQL Server تاثیر بسزایی دارد. برای درک بهتر این ویژگی باید ابتدا Full Transaction Durability را بررسی کنیم. به صورت پیش فرض در حال حاضر SQL Server به صورت Full Transaction Durability عمل می کند. سوالی که بسیار مطرح می شود این هست چه نیازی است که ما از حالت پیش فرض به سمت delayed durability حرکت کنیم. جواب این پرسش را می توان اینگونه بیان کرد که اولویت با کارایی است نه با اتمام انجام یک عملیات.

وقتی در حال نوشتن این مقاله بودم نیاز بود تا چند مبحث مقدماتی را مطرح کنم و از همین رو این مباحث را جستجو کردم اما هیچ منبع فارسی پیدا نشد! واقعا عجیب است که همه بر ادعای خود در خصوص DBA پا فشاری می کنیم اما هیچ یک به مباحث پایه اساس بانک های اطلاعاتی اشراف

بسم الله الرحمن الرحیم

آموزش SQL Server 2014

انشالله سعی خواهیم کرد در این دوره آموزشی برخی از مفاهیم و امکانات جدید SQL Server 2014 را بررسی کنیم.

در ابتدا برخی از مفاهیم پایه را بررسی خواهیم کرد و سپس در خصوص تغییرات ایجاد شده در نسخه جدید SQL Server بحث خواهیم کرد.


delayed durability

SQL Server 2014 ویژگی های زیادی را معرفی کرده است یکی از این ویژگی ها Delayed Transaction Durability که در  performance و یا همان عملکرد SQL Server تاثیر بسزایی دارد. برای درک بهتر این ویژگی باید ابتدا Full Transaction Durability را بررسی کنیم. به صورت پیش فرض در حال حاضر SQL Server به صورت Full Transaction Durability عمل می کند. سوالی که بسیار مطرح می شود این هست چه نیازی است که ما از حالت پیش فرض به سمت delayed durability حرکت کنیم. جواب این پرسش را می توان اینگونه بیان کرد که اولویت با کارایی است نه با اتمام انجام یک عملیات.

وقتی در حال نوشتن این مقاله بودم نیاز بود تا چند مبحث مقدماتی را مطرح کنم و از همین رو این مباحث را جستجو کردم اما هیچ منبع فارسی پیدا نشد! واقعا عجیب است که همه بر ادعای خود در خصوص DBA پا فشاری می کنیم اما هیچ یک به مباحث پایه اساس بانک های اطلاعاتی اشراف نداریم، انشالله که دوستان لطف کنند و اینگونه مباحث را برای دیگران نیز مکتوب کنند.
قبل از ادامه دادن باید چند مبحث را بررسی کنیم تا ابتدا بدانیم در گذشته در بانک های اطلاعاتی چه اتفاقی می افتاده و هم اکنون چه اتفاقی می افتد.
در علم رایانه (پارسی را پاس داشتم) چهار مفهوم اصلی Atomicity, Consistency, Isolation, Durability وجود دارد که به صورت اختصار آن را ACID معرفی می کنند.


ACID یک مجموعه از پراپرتی ها می باشد که به شما اطمینان می دهد تمامی تراکنش های پایگاه داده شما به صورت قابل اعتماد پردازش شود.
در پایگاه های داده یک تک عملیات منطقی بر روی داده ها را تراکنش و یا transaction می نامند. برای اینکه این مسئله را بهتر بیان کنم یک مثال می زنم (یکی از دوستانم فرمودند مدتی است مطالب را به خوبی بیان نمی کنم، انشالله سعی می کنم از این به بعد مطالب را مفصلتر بیان کنم). یک سیستم انتقال را در یک بانک در نظر بگیرید وقتی شما مبلغی را انتقال می دهید یک حساب باید کسر شود و حساب دیگر باید افزایش یابد این مجموعه عملیات ها یک تراکنش است ، که به صورت کامل باید اجرا شود.
این مفاهیم اواخر دهه 1970 تعریف شدند.


تعریف مفاهیم


Atomicity

یک atomic transaction بیان گر این مسئله است که تمامی عملیات های مربوط به یک کار باید یا همگی اتفاق بیافتند و یا کل عملیات ها لغو شود. این مجموعه از عملیات ها نمی توانند به بخش های کوچک تر تقسیم شوند و یا هر یک جداگانه اجرا شوند از همین رو نام آنها را غیرقابل تقسیم و یا indivisible می نامند. atomicity به شما اطمینان می دهد که از پایگاه داده شما در مقابل برروز رسانی هایی که ممکن است باعث ایجاد مشکل شود، محافظت کند طبیعتا با لغو یک تراکنش فقط یک مشکل کوچک رخ خواهد داد اما اگر این تراکنش به نادرستی اجرا شود ممکن است تمامیت سیستم شما دچار مشکل شود.
برای این مورد می توانیم سیستم رزرو بلیط هواپیما را مثال بزنیم. برای انجام رزور بلیط هوپیما باید دو عملیات خرید بلیط و رزرو صندلی صورت گیرد.
یک مسافر یا باید هزینه تهیه بلیط را پرداخت کند و یک صندلی را رزرو کند و یا کل قضیه لغو شود و هزینه ای اگر پرداخت شده به حساب مسافر باز گردد.
در این جا این دو عملیات یک واحد (Atomicity) هستند زیرا اگر در اجرای بخش پرداخت هزینه و یا رزرو صندلی سیستم دچار مشکل شود باید در هر دو صورت سیستم کل فرایند را لغو کند.
در مثال دیگر اگر سیستم بانکی را در نظر بگیریم وقتی شما مبلغی را از حسابی به حساب دیگر منتقل می کنید، یا باید از حساب اول مبلغ کسر و به حساب دوم افزوده شود و یا کل عملیات لغو شود، پس (Atomicity) از انجام کامل یک عملیات محافظت می کند.

Consistency

سازگاری و یا Consistency به این مفهوم اشاره می کند که در پایگاه های داده تنها تراکنش هایی باید انجام شوند که بر اساس محدودیت های تعریف شده در پایگاه داده اجازه انجام دارند. هر داده ای که می خواهد در پایگاه داده ذخیره شود باید بر اساس rules, including constraints, cascades,
مفهوم Consistency باعث می شود هر اشتباه برنامه نویسی که قوانین پایگاه داده را نقض می کند، نتواند انجام شود. مثلا در constraints ها ممکن است بر روی کلید های اصلی و خارجی شرطهایی گذاشته باشید که طبیعتا اگر این شرط ها رعایت نشود شما نمی توانید اطلاعاتی را در جداول مربوطه درج کنید.
Constraints در واقعه تضمین می کند که تراکنش ها بر اساس قوانین گذاشته شده بر روی پایگاه داده عمل کنند و تراکنش های خلاف قوانین نتوانند اجرا شوند، مثلا درجدول ثبت اطلاعات فرزندان قرار است کلید اصلی از جدول والدین را ثبت کنیم. حال اگر فرزندی را ثبت کنیم و ID پدر را اشتباه بزنیم خطایی برای ما نمایش داده می شود که چنین رکوردی در جدول والدین وجود ندارد.

Isolation

در سیستم های پایگاه داده Isolation مشخص می کند که اطلاعات چطور توسط سایر کاربران و سیستم ها قابل نمایش باشد، در سیستم های lower isolation level همزمانی بهتر رعایت می شود و کاربران زیادی می توانند در یک زمان به اطلاعات مشترکی دسترسی داشته باشند اما این روش مشکلات همزمانی را هم بیشتر می کند. در higher isolation level مشکلات همزمانی کاهش پیدا می کند اما به منابع سیستمی بیشتری نیاز داریم و همچنین میزان بلوکه شدن یک تراکنش توسط تراکنش دیگر افزایش پیدا می کند. اگر متوجه شده باشید با افزایش میزان همزمانی isolation کاهش پیدا می کند.
Isolation یا ایزوله کردن یعنی جدا سازی بخش های مختلف از یکدیگر برای جلوگیری از تاثیرات منفی آنها. ایزوله کردن در واقعه در مقالب همزمانی قرار دارد زیرا وقتی کاربران زیادی بخواهند به صورت همزمان به اطلاعات دسترسی داشته باشند طبیعتا ایزوله کردن آنها کار دشواری است اما اگر قرار باشد در هر لحظه فقط یک کاربر به اطلاعات دسترسی داشته باشد ایزوله کردن ساده تر خواهد شد.
isolation مفهوم گسترده ای است و به بخش های زیادی تقسیم می شود، انشالله در آینده در مورد آن به صورت کامل صحبت خواهیم کرد.


Durability

در سیستم های پایگاه داده، مفهوم durability یا همان پایداری و دوام، به شما اطمینان می دهد که اگر تراکنشی پایان یافت در آینده نیز وجود داشته باشد. مثلا در یک سیستم رزرو بلیط اگر شما بتوانید یک تراکنش رزرو را با موفقیت به پایان برسانید این تراکنش حتی در صورتی که سیستم crashes کند، باقی خواهد ماند.
بسیاری از DBMS ها durability را به وسیله نوشتن تراکنش ها در یک transaction log مدیریت می کنند این روش باعث می شود که DBMS ها بتوانند به وسیله پردازش مجدد عملیات های انجام شده قبل از عملیات ناموفقیت آمیز سیستم را به حالت صحت قبل هدایت کنند. یک تراکنش فقط زمانی تمام شده قلم داد می شود که در log ثبت شود.

ما در خصوص پایداری و انجام یک Transaction دو حالت متفاوت را می توانیم در نظر بگیریم.
Fully durable transaction و Delayed durable transaction این دو مفهوم، مفاهیم هستند که در حال حاضر درSQL Server  مورد استفاده قرار می گیرد. ابتدا گذشته را بررسی می کنیم و بعد به سراغ ویژگی جدید SQL Server 2014 می رویم.

Fully durable transaction

در این روش که به صورت همزمان (synchronous) تراکنش ها انجام می شوند با پابان یافتن یک تراکنش پیام موفقیت آمیز برگردانده می شود و تنها بعد از پایان یافتن تراکنش و ثبت log  برای تراکنش انجام شده کنترل به کلاینت داده می شود. چند پاراگراف بالاتر در خصوص نحوه کنتلر تراکنش ها و ثبت آنها به صورت log توضیح دادیم. در این جا نیز، به همان فرایند اشاره می کنیم، بدین معنا که تنها در زمانی یک تراکنش پایان یافته قلمداد می شود که آن تراکنش در Log تراکنش ها ثبت شود و تنها پس از این مرحله کلاینت می تواند کنترل برنامه را در اختیار بگیرد. طبیعی است که می توانید درک کنید اگر خطایی در این روش رخ دهد برنامه هنگ می کند و تمامی پردازش های برنامه ممکن است از کار بیافتند.
در این روش در واقع ابتدا داده ها به صورت مطمئن بر روی دیسک قرار می گیرند و سپس کار به پایان (commit) می رسد.
Delayed durable transaction
در این روش تراکنش ها به صورت ناهمزمان انجام می شوند و گزارش پایان یک تراکنش قبل از ثبت Log مربوط به آن اعلام می شود. طبیعتا در این روش سرعت اجرای فرایندها بیشتر خواهد بود و امکان هنگ کردن برنامه کمتر خواهد شد.

ادامه دارد...



نظرات

  • Hannah Martinez
    سارا
    دو شنبه 11 دی 1278 0:00

    سلام
    آیا اموزش زیر برای من که مبتدیم می تونه مفید باشه ؟
    http://pahnavar.com/644-sql-server-2014-training

    • Judith Bell
      پاسخ
      حسینبهزادی
      دو شنبه 11 دی 1278 0:00

      با عرض سلام


      به نظر می رسد سرفصل های بسیار کاملی دارد اما محتوا را من هم مثل شما بی اطلاع هستم.
      چند لینک مناسب به همراه اطلاعات تکمیلی را برای شما ایمیل خواهم کرد.

      موفق باشید




  • Hannah Martinez
    علی اکبری
    دو شنبه 11 دی 1278 0:00

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

    • Judith Bell
      پاسخ
      حسینبهزادی
      دو شنبه 11 دی 1278 0:00

      خواهش می کنم
      موفق باشید

  • Hannah Martinez
    علی اکبری
    دو شنبه 11 دی 1278 0:00

    وقت شما بخیر

    لطفا به آدرس زیر سری بزنید و در صورت تمایل بهترین سولوشن و استراتژی که در آن مورد بنظرتان میرسد را مطرح نمائید.

    • Judith Bell
      پاسخ
      حسینبهزادی
      دو شنبه 11 دی 1278 0:00

      بسم الله الرحمن الرحیم
      با عرض سلام

      سوال شما را خواندم، بنده هم نتوانستم منظور شما را کامل متوجه شوم.

      اما پیشنهاد بنده

      در ابتدا حتما از نسخه SQL Server 2014 استفاده کنید بخاطر بهینه سازی هایی که انجام شده است و از امکانات آن استفاده کنید.

      علاوه بر Relation در سطح Table در سطح Database هم می توان Relation زد
       شخصا این کار را برای پروژه های بزرگ انجام داده ام اما مدیریتش طبیعتا ساده نیست
      در شرایطی که چندین نرم افزار و محصول و شرکت قرار است بر روی یک پروژه واحد کار کنند باید نکات زیر را در نظر داشته باشید

      1- در ابتدا بهتر است یک پروتکل برای برقراری ارتباط بین بخش های مختلف تعریف شود
      2- دسترسی به اطلاعات و دیتابیس ها از طریق یک سرویس انجام شود (لایه بندی بخش ها)
      3- بخش های مختلف نرم افزار در دیتابیس های مختلف ثبت شوند
      4- جداول دیتابیس master به صورت lookup table طراحی شود
      5- ایندکس گذاری بر روی جدوال مشخص شود
      6- اطلاعات بر اساس معماری و نحوه و همچنین میزان واکشی دسته بندی شوند
      7- سطوح دسترسی در سطح نرم افزار باید پیاده سازی شود نه آی پی و سخت افزار (بهبود هزینه)
      8- شرکت های پیاده سازی کننده نرم افزار تنها بر اساس سطح دسترسی تعریف شده در پروتکل لایه سرویس می توانند با دیتابیس ها در ارتباط باشند.
      9- کلیدها تماما بر اساس Guid  باید در نظر گرفته شود
      10- در پروژه باید Error handling سطح پایگاه داده و سطح نرم افزار پیاده سازی شود.
      11- طبیهتا بهتر است فراخوانی ها به صورت asynchronous باشد.
      12- اطلاعات در سطح پایگاه داده باید بر اساس تاریخ ها به صورت دوره ای گروه بندی شوند تا سرعت واکشی افزایش یابد
      13- maintenance های لازم باید بر روی پایگاه داده تعریف شوند.
      14- در نهایت باید Plane های back Up و Script بر اساس تغییرات در هر بخش ثبت شود تا مشکلی ایجاد نشود 
      15- طبیعتا امکانت Cluster و Mirror می تواند مشکلات شما را کاهش دهد.

      اگر به دنبال مطلب خاصی بودید که بنده آن اشاره نکردم لطفا بفرمایید تا انشالله آن را کامل کنیم

      یاعلی

نظرات یا سوالات خودرا با ما درمیان بگذارید

0912 097 5516 :Phone Number
0713 625 1757 :Phone Number