ثبات معاملات در خط تعادل

پدیده هایی که در سطوح مختلف ممنوع است عبارتند از:

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

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

یک معامله دوباره پرس و جو را برای بازگشت مجموعه ای از ردیف ها که شرایط جستجو را برآورده می کند ، مجدداً مورد استفاده قرار می دهد و می یابد که مجموعه ای از ردیف های رضایت از این وضعیت به دلیل معامله اخیراً واجد شرایط تغییر کرده است.

نتیجه انجام موفقیت آمیز گروهی از معاملات با کلیه ترتیبات احتمالی اجرای آن معاملات یک بار مغایر است.

سطح SQL Standard و PostgreSQL Impraction سطح جداسازی در جدول 13. 1 شرح داده شده است.

جدول 13. 1. سطح جداسازی معامله

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

جدول همچنین نشان می دهد که اجرای قابل تکرار قابل تکرار PostgreSQL اجازه خواندن فانتوم را نمی دهد. این امر طبق استاندارد SQL قابل قبول است زیرا استاندارد مشخص می کند که ناهنجاری ها در سطوح خاص انزوا وجود ندارد. ضمانت های بالاتر قابل قبول است. رفتار سطح انزوا موجود در زیر بخش های زیر به تفصیل شرح داده شده است.

برای تنظیم سطح جداسازی معامله از یک معامله ، از معامله مجموعه فرمان استفاده کنید.

مهم

برخی از انواع و کارکردهای داده PostgreSQL در مورد رفتار معامله ای قوانین ویژه ای دارند. به طور خاص ، تغییراتی که در یک توالی ایجاد شده است (و بنابراین پیشخوان ستون اعلام شده با استفاده از سریال) بلافاصله برای سایر معاملات قابل مشاهده است و در صورت معامله ای که باعث ایجاد تغییرات می شود ، به عقب برگردانده نمی شوند. به بخش 9. 17 و بخش 8. 1. 4 مراجعه کنید.

13. 2. 1. سطح انزوا متعهد را بخوانید

خواندن متعهد ، سطح جداسازی پیش فرض در PostgreSQL است. هنگامی که یک معامله از این سطح جداسازی استفاده می کند ، یک پرس و جو انتخاب (بدون بند به روزرسانی/اشتراک) فقط داده های متعهد شده قبل از شروع پرس و جو را می بیند. این هرگز داده های غیرقابل قبول را مشاهده نمی کند یا تغییراتی که در هنگام اجرای پرس و جو توسط معاملات همزمان انجام می شود. در واقع ، یک پرس و جو انتخابی ، عکس فوری از پایگاه داده را از لحظه شروع به کار می کند. با این حال ، SELECT اثرات به روزرسانی های قبلی را که در معامله خود اجرا شده است ، مشاهده می کند ، حتی اگر هنوز متعهد نباشند. همچنین توجه داشته باشید که دو دستور انتخاب پی در پی می توانند داده های مختلفی را مشاهده کنند ، حتی اگر در یک معامله واحد قرار داشته باشند ، اگر سایر معاملات پس از شروع انتخاب اول و قبل از شروع انتخاب دوم ، تغییر می کنند.

به روزرسانی ، حذف ، انتخاب برای به روزرسانی ، و انتخاب برای دستورات اشتراک ، مانند انتخاب از نظر جستجو برای ردیف های هدف رفتار می کنند: آنها فقط ردیف های هدف را که از زمان شروع فرمان مرتکب شده اند ، پیدا می کنند. با این حال ، چنین ردیف هدف ممکن است قبلاً توسط یک معامله همزمان دیگر تا زمانی که پیدا می شود ، به روز شده باشد (یا حذف یا قفل شده باشد). در این حالت ، به روزرسانی مورد نیاز منتظر اولین معامله به روزرسانی برای تعهد یا بازگشت مجدد خواهد بود (اگر هنوز در حال انجام است). اگر اولین بروزرسانی به عقب برگردد ، اثرات آن نفی می شود و دومین بار به روزرسانی می تواند با به روزرسانی ردیف در ابتدا یافت شود. اگر اولین بروزرسانی تعهد کند ، اگر اولین به روزرسانی آن را حذف کند ، ردیف دوم ردیف را نادیده می گیرد ، در غیر این صورت سعی می کند عملکرد خود را در نسخه به روز شده ردیف اعمال کند. شرایط جستجوی دستور (بند Where Where) مجدداً مورد ارزیابی قرار می گیرد تا ببیند آیا نسخه به روز شده ردیف هنوز با شرایط جستجو مطابقت دارد یا خیر. در این صورت ، به روزرسانی دوم با استفاده از نسخه به روز شده ردیف ، عملکرد خود را ادامه می دهد. در مورد Select for Update و Select for Share ، این بدان معنی است که این نسخه به روز شده ردیف است که قفل شده و به مشتری بازگردانده شده است.

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

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

ادغام به کاربر اجازه می دهد تا ترکیب های مختلفی از زیرمجموعه های درج ، به روزرسانی و حذف را مشخص کند. یک دستور ادغام با هم درج و هم به روزرسانی Subcommands شبیه به Insert با بند بروزرسانی در Conflant Do Update است اما تضمین نمی کند که درج یا به روزرسانی رخ دهد. اگر ادغام به روزرسانی یا حذف شود و ردیف به طور همزمان به روز شود اما وضعیت پیوستن هنوز برای هدف فعلی و منبع فعلی Tuple منتقل می شود ، سپس ادغام مانند دستورات به روزرسانی یا حذف رفتار می کند و عملکرد خود را بر روی نسخه به روز شده انجام می دهدردیف. با این حال ، از آنجا که ادغام می تواند چندین عمل را مشخص کند و آنها می توانند مشروط باشند ، شرایط برای هر عمل در نسخه به روز شده ردیف دوباره ارزیابی می شود ، از اولین عمل ، حتی اگر عملی که در ابتدا با هم هماهنگ شده بود ، بعداً در لیست ظاهر می شوداقداماتاز طرف دیگر ، اگر ردیف به طور همزمان به روز شود یا حذف شود تا شرط پیوستن از بین برود ، آنگاه ادغام اقدامات بعدی را با هم مطابقت نمی دهد و اولین مورد را که موفق می شود ، انجام می دهد. اگر ادغام درج تلاش کند و یک شاخص منحصر به فرد موجود باشد و یک ردیف تکراری به طور همزمان درج شود ، یک خطای تخلف منحصر به فرد مطرح می شود. ادغام با شروع مجدد ارزیابی شرایط همسان ، سعی در جلوگیری از چنین خطاهایی نمی کند.

به دلیل قوانین فوق ، یک دستور به روزرسانی می تواند یک عکس فوری متناقض را ببیند: می تواند اثرات دستورات به روزرسانی همزمان را در همان ردیف هایی که در تلاش برای به روزرسانی است ، مشاهده کند ، اما اثرات آن دستورات را در ردیف های دیگر نمی بینددر پایگاه دادهاین رفتار باعث می شود حالت متعهد برای دستوراتی که شامل شرایط جستجوی پیچیده است ، نامناسب باشد. با این حال ، برای موارد ساده تر درست است. به عنوان مثال ، به روزرسانی مانده های بانکی را با معاملات مانند:

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

استفاده پیچیده تر می تواند نتایج نامطلوب را در حالت متعهد خواندن ایجاد کند. به عنوان مثال ، یک دستور حذف را در نظر بگیرید که بر روی داده هایی که هم اضافه شده و هم از معیارهای محدودیت آن توسط دستور دیگری حذف شده و از آن خارج شده است ، فرض کنید وب سایت یک جدول دو ردیف با وب سایت است. Hits برابر 9 و 10:

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

از آنجا که حالت متعهد ، هر دستور را با یک عکس فوری جدید شروع می کند که شامل کلیه معاملات انجام شده در آن لحظه است ، دستورات بعدی در همان معامله ، اثرات معامله همزمان متعهد را در هر صورت مشاهده می کنند. نکته مورد بحث این است که آیا یک دستور واحد دیدگاه کاملاً مداوم از پایگاه داده را مشاهده می کند یا خیر.

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

13. 2. 2. سطح جداسازی قابل تکرار

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

این سطح با خواندن مرتکب شده متفاوت است که یک پرس و جو در یک معامله قابل تکرار قابل تکرار ، از شروع اولین بیانیه کنترل عدم تحرک در معامله ، عکس فوری را مشاهده می کند ، نه از آغاز بیانیه فعلی در معامله. بنابراین ، دستورات منتخب پیاپی در یک معامله واحد ، همان داده ها را مشاهده می کنند ، یعنی آنها تغییراتی را که توسط سایر معاملات انجام شده است که پس از شروع معامله خود انجام شده اند ، مشاهده نمی کنند.

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

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

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

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

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

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

سطح انزوا قابل تکرار با استفاده از تکنیکی که در ادبیات پایگاه داده دانشگاهی و در برخی دیگر از محصولات پایگاه داده به عنوان جداسازی عکس فوری شناخته می شود ، پیاده سازی می شود. تفاوت در رفتار و عملکرد ممکن است در مقایسه با سیستمهایی که از یک روش قفل سنتی استفاده می کنند که باعث کاهش همزمانی می شود ، مشاهده شود. برخی از سیستم های دیگر حتی ممکن است به عنوان سطح انزوا مجزا با رفتارهای مختلف ، انزوا و عکس فوری قابل تکرار را ارائه دهند. پدیده های مجاز که این دو تکنیک را متمایز می کند ، توسط محققان پایگاه داده تا زمان توسعه استاندارد SQL رسمیت نیافته و خارج از محدوده این دفترچه راهنما هستند. برای یک درمان کامل ، لطفاً به [Berenson95] مراجعه کنید.

قبل از نسخه 9. 1 PostgreSQL ، درخواستی برای سطح جداسازی معاملات سریال قابل ارائه دقیقاً همان رفتار توصیف شده در اینجا را ارائه داد. برای حفظ رفتار سریال قابل سریال میراث ، اکنون باید از خواندن قابل تکرار درخواست شود.

13. 2. 3. سطح انزوا قابل سریال

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

به عنوان نمونه ، یک جدول MyTAB را در نظر بگیرید که در ابتدا حاوی:

فرض کنید آن معامله سریال قابل محاسبه:

و سپس نتیجه (30) را به عنوان مقدار در یک ردیف جدید با کلاس = 2 وارد می کند. به طور هم زمان ، معاملات Serializable B محاسبه می کند:

و نتیجه 300 را که در یک ردیف جدید با کلاس = 1 وارد می کند ، بدست می آورد. سپس هر دو معاملات سعی می کنند مرتکب شوند. اگر هر یک از معامله ها در سطح انزوا قابل تکرار در حال اجرا باشند ، هر دو مجاز به انجام هستند. اما از آنجا که هیچ ترتیب سریال اجرای مطابق با نتیجه وجود ندارد ، استفاده از معاملات سریال قابل انجام به یک معامله امکان می دهد تا مرتکب شود و دیگری را با این پیام بازگرداند:

این امر به این دلیل است که اگر قبل از B اجرا شده بود ، B مبلغ 330 را محاسبه می کرد ، نه 300 ، و به همین ترتیب ترتیب دیگر منجر به مبلغ دیگری می شد که توسط A محاسبه می شود.

هنگام تکیه بر معاملات سریال برای جلوگیری از ناهنجاری ها ، مهم است که هرگونه داده ای که از جدول کاربر دائمی خوانده شود تا زمانی که معامله ای که خوانده شده با موفقیت انجام داده است معتبر نباشد. این حتی برای معاملات فقط خواندنی صادق است ، به جز این که داده های خوانده شده در یک معامله قابل خواندن فقط به محض خواندن معتبر هستند ، زیرا چنین معامله ای منتظر می ماند تا بتواند یک عکس فوری بدست آورد که تضمین می شود از چنین مواردی عاری باشدمشکلات قبل از شروع به خواندن هرگونه داده. در همه موارد دیگر برنامه های کاربردی نباید به نتایج خوانده شده در طی معامله ای که بعداً سقط شده است بستگی داشته باشد. در عوض ، آنها باید معامله را دوباره امتحان کنند تا موفق شود.

برای تضمین واقعی بودن سریال PostgreSQL از قفل محمول استفاده می کند ، به این معنی که قفل هایی را نگه می دارد که به آن اجازه می دهد تا تعیین کند که چه زمانی نوشتن در نتیجه خواندن قبلی از یک معامله همزمان تأثیر داشته است ، در صورتی که ابتدا اجرا شود. در PostgreSQL این قفل ها هیچ مسدود کننده ای ایجاد نمی کنند و بنابراین نمی توانند هیچ نقشی در ایجاد بن بست داشته باشند. آنها برای شناسایی و پرچم وابستگی در بین معاملات سریال همزمان که در ترکیب های خاص می توانند منجر به ناهنجاری های سریال سازی شوند ، استفاده می شود. در مقابل ، یک تراکنش خواندن متعهد یا تکرار شونده که می خواهد از سازگاری داده اطمینان حاصل کند ممکن است نیاز به قفل در یک جدول کامل داشته باشد ، که می تواند سایر کاربرانی را که سعی در استفاده از آن جدول دارند ، مسدود کند ، یا ممکن است از انتخاب برای به روزرسانی یا انتخاب برای اشتراک استفاده کند. که نه تنها می تواند معاملات دیگر را مسدود کند بلکه باعث دسترسی به دیسک می شود.

قفل‌های گزاره‌ای در PostgreSQL، مانند اکثر سیستم‌های پایگاه داده دیگر، بر اساس داده‌هایی هستند که واقعاً توسط یک تراکنش به آنها دسترسی پیدا می‌کند. اینها در نمای سیستم pg_locks با حالت SIReadLock نشان داده می شوند. قفل‌های خاصی که در طول اجرای یک پرس‌وجو به دست می‌آیند، به طرح مورد استفاده در پرس‌وجو بستگی دارد، و چندین قفل با دانه‌ریزی (به عنوان مثال، قفل‌های چندگانه) ممکن است به قفل‌های درشت‌تر (مثلاً قفل صفحه) در طول دوره ترکیب شوند. تراکنش برای جلوگیری از فرسودگی حافظه مورد استفاده برای ردیابی قفل ها. یک تراکنش READ ONLY ممکن است بتواند قفل های SIRead خود را قبل از تکمیل آزاد کند، اگر تشخیص دهد که هنوز هیچ تضادی نمی تواند رخ دهد که می تواند منجر به ناهنجاری سریال سازی شود. در واقع، تراکنش‌های READ ONLY اغلب می‌توانند این واقعیت را در هنگام راه‌اندازی ثابت کنند و از هرگونه قفل محمول اجتناب کنند. اگر صریحاً یک تراکنش SRIALIZABLE READ ONLY DEFERRABLE درخواست کنید، تا زمانی که بتواند این واقعیت را ثابت کند مسدود می شود.(این تنها موردی است که تراکنش های Serializable مسدود می شوند اما تراکنش های Repeatable Read مسدود نمی شوند).

استفاده مداوم از معاملات Serializable می تواند توسعه را ساده کند. تضمین این که هر مجموعه ای از تراکنش های قابل سریال سازی همزمان با موفقیت انجام شده، همان اثری را خواهند داشت که اگر در یک زمان اجرا شوند، به این معنی است که اگر بتوانید نشان دهید که یک تراکنش، همانطور که نوشته شده است، وقتی به تنهایی اجرا شود، کار درست را انجام می دهد، شمامی‌تواند مطمئن باشد که در هر ترکیبی از تراکنش‌های قابل سریال‌سازی، کار درست را انجام می‌دهد، حتی بدون هیچ اطلاعاتی در مورد آنچه آن تراکنش‌های دیگر ممکن است انجام دهند، یا با موفقیت انجام نخواهد شد. مهم است که محیطی که از این تکنیک استفاده می‌کند، روشی کلی برای رسیدگی به خرابی‌های سریال‌سازی داشته باشد (که همیشه با مقدار SQLSTATE '40001' برمی‌گردند)، زیرا پیش‌بینی دقیق تراکنش‌هایی که ممکن است در خواندن/نوشتن نقش داشته باشند بسیار سخت خواهد بود. وابستگی ها و نیاز به عقب انداختن برای جلوگیری از ناهنجاری های سریال سازی. نظارت بر وابستگی‌های خواندن/نوشتن هزینه دارد، مانند شروع مجدد تراکنش‌هایی که با شکست سریال‌سازی خاتمه می‌یابند، اما در مقابل هزینه و مسدود کردن استفاده از قفل‌های صریح و SELECT FOR UPDATE یا SELECT FOR SHARE، تراکنش‌های قابل سریال‌سازی متعادل هستند. بهترین انتخاب عملکرد برای برخی از محیط ها.

در حالی که سطح جداسازی معاملات سریال PostgreSQL فقط به معاملات همزمان اجازه می دهد تا در صورتی که می تواند یک ترتیب سریال اعدام وجود داشته باشد که همان اثر را ایجاد کند ، مرتکب شود ، همیشه مانع از افزایش خطاها نمی شود که در اجرای سریال واقعی رخ نمی دهدوادبه طور خاص ، می توان نقض محدودیت های منحصر به فرد را ناشی از درگیری با معاملات سریال با هم همپوشانی مشاهده کرد ، حتی پس از بررسی صریح این که کلید قبل از تلاش برای درج آن وجود ندارد. این امر می تواند با اطمینان از اینكه تمام معاملات سریال قابل استفاده كه كلیدهای بالقوه متناقض را درج می كنند ، به صراحت بررسی كنید كه آیا ابتدا می توانند این كار را انجام دهند ، جلوگیری شود. به عنوان مثال ، برنامه ای را تصور کنید که از کاربر بخواهد یک کلید جدید را بخواهد و سپس با تلاش برای انتخاب آن ، در حال حاضر وجود ندارد ، یا با انتخاب حداکثر کلید موجود و اضافه کردن یک کلید جدید ، یک کلید جدید ایجاد می کند. اگر برخی از معاملات سریال قابل استفاده ، کلیدهای جدید را مستقیماً بدون پیروی از این پروتکل وارد کنید ، ممکن است نقض محدودیت های منحصر به فرد حتی در مواردی که در اجرای سریال معاملات همزمان رخ نمی دهند گزارش شود.

برای عملکرد بهینه هنگام تکیه بر معاملات سریال قابل کنترل برای کنترل همزمانی ، این موضوعات باید در نظر گرفته شود:

معاملات را فقط در صورت امکان بخوانید.

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

بیشتر از آنچه برای اهداف یکپارچگی مورد نیاز است ، در یک معامله واحد قرار ندهید.

اتصالات را بیش از حد لازم "بیکار در معامله" آویزان نکنید. پارامتر پیکربندی IDLE_IN_TRANSACTION_SESSION_TIMEOUT ممکن است برای قطع خودکار جلسات طولانی استفاده شود.

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

هنگامی که سیستم مجبور به ترکیب چندین قفل محمول در سطح صفحه در یک قفل محمول در سطح رابطه واحد می شود زیرا جدول قفل محمول کوتاه از حافظه است ، ممکن است افزایش میزان خرابی سریال سازی رخ دهد. شما می توانید با افزایش MAX_PRED_LOCKS_PER_TRANSACATION ، MAX_PRED_LOCKS_PER_RELATION ، و/یا MAX_PRED_LOCKS_PER_PAGE جلوگیری کنید.

یک اسکن متوالی همیشه به یک قفل محمول در سطح رابطه نیاز دارد. این می تواند منجر به افزایش نرخ شکست سریال شود. تشویق به استفاده از اسکن فهرست با کاهش هزینه_صفحه_ تصادفی و/یا افزایش cpu_tuple_cost ممکن است مفید باشد. اطمینان حاصل کنید که هر گونه کاهش در بازگشت تراکنش ها و راه اندازی مجدد را با هرگونه تغییر کلی در زمان اجرای پرس و جو سنجید.

سطح جداسازی Serializable با استفاده از تکنیکی که در ادبیات پایگاه داده دانشگاهی به نام Serializable Snapshot Isolation شناخته می‌شود، پیاده‌سازی می‌شود که بر اساس Snapshot Isolation با افزودن بررسی‌هایی برای ناهنجاری‌های سریال‌سازی ایجاد می‌شود. در مقایسه با سایر سیستم هایی که از تکنیک قفل سنتی استفاده می کنند، ممکن است برخی تفاوت ها در رفتار و عملکرد مشاهده شود. لطفاً برای اطلاعات دقیق به [ports12] مراجعه کنید.

تصحیح را ارسال کنید

اگر چیزی در اسناد می بینید که صحیح نیست، با تجربه شما با ویژگی خاص مطابقت ندارد یا نیاز به توضیح بیشتر دارد، لطفاً از این فرم برای گزارش یک مشکل مستند استفاده کنید.