لطفا به نکات زیر در هنگام خرید دانلود فایل پاورپوینت تراکنشها در SQL Server توجه فرمایید.

1-در این مطلب، متن اسلاید های اولیه دانلود فایل پاورپوینت تراکنشها در SQL Server قرار داده شده است 2-به علت اینکه امکان درج تصاویر استفاده شده در پاورپوینت وجود ندارد،در صورتی که مایل به دریافت  تصاویری از ان قبل از خرید هستید، می توانید با پشتیبانی تماس حاصل فرمایید 3-پس از پرداخت هزینه ، حداکثر طی 4 ساعت پاورپوینت خرید شده ، به ادرس ایمیل شما ارسال خواهد شد 4-در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل اسلاید ها میباشد ودر فایل اصلی این پاورپوینت،به هیچ وجه بهم ریختگی وجود ندارد 5-در صورتی که اسلاید ها داری جدول و یا عکس باشند در متون زیر قرار نخواهند گرفت

— پاورپوینت شامل تصاویر میباشد —-

اسلاید ۱ :

تراکنشها در SQL Server

به مجموعه ای از دستورات که می بایست یا همگی با هم با موفقیت اجرا شوند و یا هیچکدام اجرا نشوند ، تراکنش گفته می شود . تراکنش ها باعث حفظ جامعیت داده های ذخیره شده در بانک اطلاعاتی می شوند .

مزایای اصلی استفاده از تراکنشها در بانک های اطلاعاتی که مختصراً ACID نامیده می شوند ، به شرح زیر هستند :

Atomicity  (تجزیه ناپذیری) : تعریف دستورات در قالب یک فعالیت عملیاتی را به صورتیکه یا کلیه عملیات با هم اجرا شوند ویا هیچکدام اجرا نشوند را Atomicity می نامند .

Consistency (پایداری) : یک تراکنش ، پس از خاتمه ، می بایست داده ها را در یک وضعیت پایدار قرار دهد ، به عنوان مثال در یک بانک اطلاعاتی رابطه ای ، پس از خاتمه یک تراکنش  ، کلیه قوانین جامعیت داده ها ، بایستی به داده های تغییر یافته توسط تراکنش اعمال گردد و همجنین ساختارهای داخلی داده های ذخیره شده مانند Index ها بایستی پس از اعمال تغییرات بازسازی و به وضعیت پایدار برسند .

Isolation  (جدا سازی) : در هنگام کار با تراکنش ها ، یکی از مهمترین موارد ، امکان دسترسی همزمان یک یا چند کاربر به یک منبع داده مشترک است . تغییرات در یک تراکنش همزمان می بایست از  تغییرات در تراکنش همزمان دیگر ، جدا باشد .

اسلاید ۲ :

Durability (مقاومت یا دوام ) : یک تراکنش پس از خاتمه می بایست دارای تاثیرات دائمی و ماندگار باشد . این بدان معنی است که عدم سازگاری ناشی از خرابی سیستم مانند قطع Power  یا قطع شبکه و … توسط تراکنش قابل کنترل و تصمیم گیری باشد .

در SQL Server  سه دسته امکانات برای رسیدن به اهداف فوق وجود دارد :

(۱امکانات قفل گذاری (Locking) که محیط را برای رسیدن به Isolation مناسب ، مهیا می سازد .

(۲امکانات واقعه نگاری (logging) که در صورت هر نوع خرابی ناشی از سیستم عامل ، شبکه ، سخت افزار ، برق ، یا حتی نسخه بانک اطلاعاتی ، با شروع مجدد ، وضعیت داده ها را به حالت قبل از شروع تراکنش باز می گرداند و در جهت رسیدن به Durability بکار گرفته می شود .

(۳امکانات مدیریت تراکنشها  (Transaction Management)  که اصولاً جهت پیش برد اهداف Atomicity و Consistency بکار گرفته می شود . در واقع پس از آغاز ، یک تراکنش ، بایستی بطور موفقیت آمیزی خاتمه یاید ، یا اینکه نسخه جاری مدیریت بانک اطلاعاتی ، همه داده های تغییر یافته در طول تراکنش را به وضعیت قبل از شروع تراکنش باز گرداند .

اسلاید ۳ :

در هنگام بروز هر نوع خطا در هنگام اجرای یک تراکنش ، عملیاتی تحت عنوان Recovery آغاز می شود .

عملیات Recovery  معمولاً توسط SQL Server  مدیریت می شوند که Automatic Recovery نامیده می-شود . این عملیات خود سه دسته هستند :

۱- با شروع مجدد سرویس SQL Server

۲- با در خواست کاربر و اجرای دستور Rollback

۳- سرویس خودکار مدیریت تراکنشها

SQL Server هنگام شروع یک تراکنش ، وضعیت جاری را در فایل های Log ذخیره ، و چنانچه نیاز به بازیابی بود ، در هنگام Recovery ، اطلاعات مورد نظر را از فایلهای Log باز خوانی می نماید .

اسلاید ۴ :

انواع تراکنشها در SQL Server

دو دسته اصلی از تراکنشها در SQL Server  وجود دارند :

۱- Single Transactions

۲- Distributed Transactions

دسته اول تراکنشها ، فقط روی یک بانک اطلاعاتی قابل استفاده هستند . در صورتیکه حوزه عملیاتی یک تراکنش بیش از یک بانک اطلاعاتی باشد ، بایستی از دسته دوم تراکنشها ، استفاده شود . در این حالت حتی این امکان وجود دارد که تراکنشها بر روی دو Server نیز استفاده شوند . این امکان با استفاده از سرویس MSDTC (Microsoft Distributed Transaction Coordinator)  قابل انجام است .

اسلاید ۵ :

سه دسته اصلی از تراکنشهای Single Transactions در SQL Server وجود دارد :

۱- تراکنشهای خودکار  Auto commit Transactions

۲- تراکنشهای صریح  Explicit Transactions

۳- تراکنشهای ضمنی Implicit Transactions

دسته اول تراکنشهای خودکار :

این دسته از تراکنشها ، توسط SQL Server و در هنگام اجرای دستورات Insert ، Update و Delete آغاز می شوند . در صورت موفقیت آمیز بودن و عدم وجود خطا بصورت خودکار Commit می شوند و در غیر اینصورت عملیات آنها ، لغو می گردد .

این تراکنشها ، دارای مراحل مختلفی هستند که در  زیر می بینیم :

اسلاید ۶ :

دسته دوم تراکنشهای صریح :

این دسته از تراکنشها ، دارای نقطه شروع و خاتمه مشخصی هستند .

به شکل مقابل توجه کنید :

اسلاید ۷ :

انواع تراکنشها در SQL Server

دسته سوم تراکنشهای ضمنی:

این دسته از تراکنشها ، شباهت زیادی به تراکنشهای صریح دارند ، با این تفاوت که شروع تراکنش صریحاً توسط دستور Begin Transaction تصریح نمی شود و تراکنش های ضمنی با دستور زیر فعال یا غیر فعال می شوند :

Set  Implicit_Transactions  {On|Off}

به کد زیر توجه کنید :

اسلاید ۸ :

مثال :

Use [Lab-SimpleCMS]

Declare  @ID  Int

Begin  Transaction

    Begin Try

  Insert  Into [Content]

      Values  (۱,GetDate(),’SQL Server 2008 Released’)

  Set  @ID  =   SCOPE_IDENTITY()

  Insert  Into News

      Values  (@ID,

      ‘New Version of SQL Server Is Released ,…. ‘ ,

      GetDate() , 

      DateAdd(Month,1, GetDate()) ,

      ۱)

  Commit      Transaction

    End Try

    Begin   Catch

  Print Error_Message()

  RollBack    Transaction

    End      Catch

اسلاید ۹ :

کنترل دسترسی همزمان

عدم توجه به دسترسی همزمان تراکنشها به منابع داده ای مشترک اشکالات زیر  را به وجود می آورد :

Lost Update : در این حالت دو تراکنش A و B بصورت همزمان اقدام به خواندن و به روز رسانی یک منبع می کنند . با توجه به اینکه دسترسی به منبع در زمان نوشتن و یا خواندن بصورت پی در پی (Sequential) می باشد ، تغییرات ثبت شده در یکی از تراکنشها ، نادیده گرفته می شود ، چرا که تراکنشها در زمان دسترسی یک مقدار مشخص را خوانده و از اینکه تراکنش دیگری نیز جهت اعمال تغییرات آن منبع را می خواند مطلع نیستند . در این صورت تراکنشی که زودتر ثبت می شود ، تغییرات آن نادیده گرفته می شود .

راه حل :  

این ایراد می توانست اینگونه حل شود که هیچ تراکنش جدیدی در زمانی که تراکنش اول در حال خواندن و به روز رسانی اطلاعات است ، و تا زمانیکه عملیات خود را Commit نکرده است ، به منبع داده دسترسی نداشته باشد .

اسلاید ۱۰ :

کنترل دسترسی همزمان

Dirty Read (Uncommitted Dependency): در این حالت یک تراکنش ، رکوردی از اطلاعات را می خواند ، که تراکنش دیگری در حال به روز رسانی آن است و هنوز Commit نشده است  و ممکن است Commit  شود و یا تغییرات دیگری نماید و یا اصلاً RollBack  شود .

راه حل :

این ایراد می توانست اینگونه حل شود که هیچ تراکنش جدیدی در زمانی که تراکنش اول در حال به روز رسانی اطلاعات است ، و تا زمانیکه عملیات خود را Commit نکرده است ، به منبع داده دسترسی نداشته باشد .