Conflict در بانک اطلاعاتی SQL [بایگانی]

ZonLine

دوشنبه 19 خرداد 1393, 09:48 صبح

خودم یه چیزایی پیدا کردم
اینجا هم میذارم شاید به درد کسی بخوره

ناسازگاری داده ها (Data Conflicts)در تمام محیط هایی که امکان پردازش توزیع شده تراکنش ها وجود دارد ممکن است به ناسازگاری داده ها بر بخوریم. وقتی می توان یک داده را در مکان های مختلف تغییر داد، مکانیسمی باید طراحی شود تا پردازش تغییرات را مدیریت کند.
برنامه هایی که تغییرات یک پایگاه داده را پردازش می کنند روشی برای پردازش تغییرات ناسازگار دارند
· یا تمام تغییرات را با اخرین تغییر رونویسی (overwrite) می کنند
· یا با رد کردن تغییرات به کاربر اطلاع می دهند که داده از اخرین زمان دستیابی ، تغییر کرده است.
هر چند این فرایند ها در سطح برنامه های کاربردی عملی اند ولی در محیط های توزیع شده کمکی نمی کنند چون هر برنامه روی یک کپی محلی (local) از داده ها کار می کند. ناسازگاری داده ها فقط زمانی رخ می دهد که موتور Replication سعی می کند تمام تغییرات را سنکرون کند.
ناسازگاری داده ها تنها بین چرخه های عامل Replication رخ می دهد، بنابراین احتمال رخداد ان مینیمم است. بعد از اتمام یک چرخه عامل، می توان از مکانیسم های آشکار ساز (Detection Mechanisms) عادی درون برنامه های کاربردی استفاده کرد، چون تمام مجموعه داده ها برای برنامه به شکل محلی (local) است.
ناسازگاری داده ها در Merge Replication وTransactional Replication رخ می دهد، چون در این حالات، تغییرات را می توان هم روی ناشر و هم روی مشترکین پردازش کرد.
انواع ناسازگاری ها1. افزودن کلید اصلی (Primary Key) تکراری:
زمانی رخ می دهد که دو کاربر روی ناشر و مشترک ، یک کلید اصلی را وارد می کنند.
2. آپدیت ناسازگار:
زمانی رخ می دهد که دو کاربر یک سطر داده را ، یکی از روی ناشر و دیگری از روی مشترک تغییر می دهند.
3. بروز رسانی سطری که وجود ندارد:
زمانی رخ می دهد که یک کاربر یک سطر داده را از یک طرف ناشر بروزرسانی و دیگری همان سطر را از طرف مشترک دیگر حذف می کند.
حلال ناسازگاری هاموتور Replication موظف است یک کپی سازگار و منسجم از داده ها را بین ناشر و مشترک نگه داری کند. ناسازگاری داده ها مانع بزرگی بر سر نگهداری انسجام و سازگاری داده ها است Merge Replication وTransactional Replication دارای مکانیسمی برای کشف و حل ناسازگاری ها هستند.
بخشی که کار حل ناسازگاری ها را انجام می دهد را حلال ناسازگاری ها(Conflict Resolver) می گویند.
SQL Serverدارای چندین حلال ناسازگاری است که دو نمونه متداول، که برای Merge Replication وTransactional Replication قابل استفاده است، عبارتند از:
1. ناشر همیشه برنده است.
2. مشترک همیشه برنده است
اگر طوری حلال ناسازگاری را تنظیم کنید که همیشه ناشر برنده باشد، تغییرات روی ناشر همواره تغییرات روی مشترک را override می کند. در این حالت، تغییری که روی مشترک رخ داده، در ناشر دور انداخته شده و در یک جدول ناسازگاری ها ثبت (log) می شود و تغییری که روی ناشر رخ داده به مشترک ارسال می شود. این، تغییرات رخ داده روی مشترک را بی اثر می کند.
اگر طوری حلال ناسازگاری را تنظیم کنید که همیشه مشترک برنده باشد، تغییرات روی مشترک همواره تغییرات روی ناشر را override می کند.
استفاده از هر روش تضمین می کند که یک کپی سازگار و منسجم از داده ها در معماری Replication نگهداری می شود. با این حال، یک وضعیت خطیر ممکن است پیش بیاید. تغییراتی که روی ناشر و مشترک انجام شده بود تراکنش هایی معتبر بوده و Commit شده بودند. ممکن است یک کاربر دیگر اطلاعات را گرفته و بر اساس ان داده ها تصمیم تجاری مهمی گرفته باشد. سپس موتور Replication داده ها را مبادله می کند، یک ناسازگاری کشف و داده ها overwrite می شود. از دید تجاری، تصمیم ان کاربر ممکن است الان نامعتبر باشد.
برای اینکه بتوانیم یک کپی منسجم و سازگار از داده ها را در معماری مان نگهداری کنیم، این ناسازگاری ها باید کشف و حل شوند. با این حال، به عهده طراح برنامه است که برای حفظ جامعیت (Integrity) تصمیم های تجاری، تضمین کند تضاد و ناسازگاری در محیط های با پردازش توزیعی رخ نمی دهد. تضاد و ناسازگاری داده ها باید در شرکت شما نامتعارف و غیر قابل قبول باشد.
تذکر: تراکنش هایی که تا کمترین حد ثبت (log) می شوند
اگر پایگاه داده در یک Replication شرکت دارد، باید به شدت مواظب مدل های Bulk-logged و Simple recovery باشید. وقتی یک پایگاه داده در مدل های Bulk-logged و Simple recovery قرار داده می شود، تراکنش هایی اجرا می شود که به کمترین حد ثبت می شوند. این نوع تراکنش ها فقط تخصیص و آزادسازی صفحه را در log تراکنش ثبت می کنند؛ انها Trigger ها را فعال نمی کنند.
5 تراکنش از این نوع عبارتند از:
1. CREATE INDEX
2. TRUNCATE TABLE
3. BULK INSERT
4. BCP
5. SELECT…INTO
رپلیکیشن فقط با 3 مورد از اینها برخورد دارد
· TRUNCATE TABLE
· BULK INSERT
· BCP
چون آنها بر داده جدول ها تاثیر می گذارند. اگر یک پایگاه داده در مدل های Bulk-logged و Simple recovery قرار داده شود و یکی از این دستور ها اجرا شود، موتور Replication نمی تواند تغییرات را بیابد چون Replication تراکنشی به تراکنش های ثبت شده در Log تراکنش ها، و Replication ادغامی به Trigger ها متکی اند.