13 همزمانی داده و قوام

در این فصل توضیح می دهد که چگونه اوراکل داده های مداوم را در یک محیط پایگاه داده چندرسانه ای حفظ می کند.

این فصل شامل موضوعات زیر است:

آشنایی با همزمانی داده ها و قوام در یک محیط چند منظوره

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

همزمانی داده به این معنی است که بسیاری از کاربران می توانند به طور همزمان به داده ها دسترسی پیدا کنند.

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

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

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

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

همچنین ببینید:

پدیده های قابل پیشگیری و سطح جداسازی معاملات

استاندارد ANSI/ISO SQL (SQL92) چهار سطح جداسازی معاملات را با درجه های مختلف تأثیر در توان پردازش معاملات تعریف می کند. این سطح جداسازی از نظر سه پدیده تعریف شده است که باید بین اجرای همزمان معاملات پیشگیری شود.

سه پدیده قابل پیشگیری عبارتند از:

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

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

Phantom می خواند (یا فانتوم): یک معامله مجدداً پرس و جو را بازگرداند و مجموعه ای از ردیف ها را برآورده می کند که یک وضعیت جستجو را برآورده می کند و می یابد که یک معامله متعهد دیگر ردیف های اضافی را درج کرده است که شرایط را برآورده می کند.

SQL92 چهار سطح انزوا را از نظر پدیده ای تعریف می کند که معامله ای که در یک سطح انزوا خاص انجام می شود مجاز به تجربه است. آنها در جدول 13-1 نشان داده شده اند:

جدول 13-1 پدیده های قابل پیشگیری از سطح انزوا

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

همچنین ببینید:

نمای کلی از مکانیسم های قفل

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

منابع شامل دو نوع کلی از اشیاء است:

اشیاء کاربر ، مانند جداول و ردیف (ساختار و داده)

اشیاء سیستم برای کاربران قابل مشاهده نیستند ، مانند ساختار داده های مشترک در ردیف های حافظه و دیکشنری داده

همچنین ببینید:

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

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

کنترل همزمانی چندگانه

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

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

شکل 13-1 معاملات و قوام را بخوانید

با ورود یک پرس و جو به مرحله اجرای ، شماره تغییر سیستم فعلی (SCN) تعیین می شود. در شکل 13-1 ، این شماره تغییر سیستم 10023 است. از آنجا که بلوک های داده از طرف پرس و جو خوانده می شوند ، فقط از بلوک های نوشته شده با SCN مشاهده شده استفاده می شود. بلوک هایی با داده های تغییر یافته (SCN های اخیر) از داده های موجود در بخش های برگشتی بازسازی می شوند و داده های بازسازی شده برای پرس و جو بازگردانده می شوند. بنابراین ، هر پرس و جو تمام داده های متعهد را با توجه به SCN ضبط شده در زمان شروع اجرای پرس و جو باز می گرداند. تغییر سایر معاملات که در هنگام اجرای یک پرس و جو مشاهده می شود ، مشاهده نمی شود و تضمین می کند که داده های مداوم برای هر پرس و جو بازگردانده می شوند.

قوام خواندن سطح بیانیه

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

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

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

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

قوام خواندن سطح معامله

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

قوام را با خوشه های برنامه واقعی بخوانید

خوشه های کاربردی واقعی (RAC) از مکانیسم انتقال بلوک حافظه نهان به حافظه پنهان استفاده می کنند تا به عنوان حافظه نهان برای انتقال تصاویر سازگار با خوانده شده از بلوک ها از یک نمونه به نمونه دیگر استفاده کنند. RAC این کار را با استفاده از سرعت بالا و اتصالات کم تأخیر برای برآورده کردن درخواست های از راه دور برای بلوک های داده انجام می دهد.

همچنین ببینید:

سطح انزوا اوراکل

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

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

سطح انزوا را تنظیم کنید

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

برای صرفه جویی در هزینه شبکه و پردازش هر معامله با یک بیانیه معامله تنظیم شده ، می توانید از بیانیه Alter Session برای تعیین سطح جداسازی معامله برای کلیه معاملات بعدی استفاده کنید:

همچنین ببینید :

انزوا متعهد را بخوانید

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

انزوای قابل سریال

جداسازی سریال برای محیط ها مناسب است:

با پایگاه داده های بزرگ و معاملات کوتاه که فقط چند ردیف به روز می شود

جایی که احتمال اینکه دو معاملات همزمان همان ردیف ها را تغییر دهند نسبتاً کم است

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

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

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

در برخی شرایط ، اوراکل می تواند اطلاعات تاریخ کافی را برای تعیین اینکه آیا یک ردیف توسط یک معامله "خیلی اخیر" به روز شده است ، نداشته باشد. این می تواند زمانی اتفاق بیفتد که بسیاری از معاملات همزمان همان بلوک داده را تغییر دهند ، یا این کار را در یک دوره بسیار کوتاه انجام دهند. شما می توانید با تعیین مقادیر بالاتر از Initrans برای جداول که بسیاری از معاملات را به روزرسانی در همان بلوک ها تجربه می کنند ، از این وضعیت جلوگیری کنید. انجام این کار اوراکل را قادر می سازد تا ذخیره کافی در هر بلوک را برای ثبت تاریخ معاملات اخیر که به بلوک دسترسی داشتند ، اختصاص دهد.

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

هنگامی که یک معامله سریال با خطای "نمی توان سریال نمی شود" ، برنامه می تواند هر یک از چندین اقدام را انجام دهد:

مرتکب کارهایی که در آن نقطه اجرا شده است

اظهارات اضافی (اما متفاوت) را اجرا کنید (شاید پس از بازگشت به یک SavePoint که در ابتدا در معامله تعیین شده است)

کل معامله را خنثیسازی کنید

شکل 13-2 نمونه ای از برنامه ای را نشان می دهد که پس از عدم موفقیت با خطای "نمی توان سریال نمی شود" ، معامله را به عقب برگردانید و بازگرداند:

شکل 13-2 عدم موفقیت معاملات سریال

مقایسه انزوای متعهد و سریال قابل خواندن

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

قوام مجموعه معامله

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

اوراکل معاملات را در حالت متعهد خوانده شده با قوام تنظیم معامله برای هر بیانیه ارائه می دهد. Serializable Mode سازگاری مجموعه معامله را برای هر معامله فراهم می کند.

جدول 13-2 تفاوتهای کلیدی بین معاملات متعهد و سریال قابل خواندن در اوراکل را خلاصه می کند.

جدول 13-2 معاملات متعهد و سریال را بخوانید

قفل سطح ردیف

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

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

صداقت مرجع

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

همچنین ببینید:

توجه داشته باشید:

معاملات توزیع شده

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

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

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

همچنین ببینید:

انتخاب سطح انزوا

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

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

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

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

انزوا متعهد را بخوانید

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

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

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

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

انزوای قابل سریال

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

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

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

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

توجه داشته باشید:

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

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

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

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

اگرچه Oracle Serializable Mode با SQL92 سازگار است و در مقایسه با پیاده سازی های قفل خواندن ، مزایای بسیاری را ارائه می دهد ، اما معناشناسی یکسان با چنین سیستمهایی ارائه نمی دهد. طراحان برنامه باید این واقعیت را در نظر بگیرند که در اوراکل خوانده می شود ، نوشتن را مانند سایر سیستم ها مسدود نمی کند. معامله هایی که برای سازگاری پایگاه داده در سطح برنامه بررسی می کنند ، می توانند به تکنیک های برنامه نویسی مانند استفاده از Select for Update نیاز داشته باشند. این مسئله باید در نظر گرفته شود که برنامه های با استفاده از حالت Serializable از محیط های دیگر به اوراکل منتقل شوند.

پایگاه داده

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

مدیران پایگاه داده می توانند اقدامات خاصی را در حالت سکونت انجام دهند که در صورت عدم پذیرش سیستم نمی توان با خیال راحت انجام داد. این اقدامات عبارتند از:

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

اقداماتی که اثر میانی آنها می تواند برای معاملات یا نمایش داده های همزمان کاربر مضر باشد. به عنوان مثال ، فرض کنید یک میز بزرگ T و یک بسته PL/SQL وجود دارد که روی آن کار می کند. می توانید جدول T را به دو جدول T1 و T2 تقسیم کرده و بسته PL/SQL را تغییر دهید تا به جای جدول قدیمی T ، به جداول جدید T1 و T2 مراجعه کنید.

هنگامی که پایگاه داده در حالت سکونت قرار دارد ، می توانید موارد زیر را انجام دهید:

سپس می توانید بسته قدیمی PL/SQL را رها کرده و دوباره ایجاد کنید.

برای سیستمهایی که باید به طور مداوم کار کنند ، امکان انجام چنین اقداماتی بدون خاموش کردن پایگاه داده بسیار مهم است.

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

چگونه یک بانک اطلاعاتی از آن خارج می شود

سرپرست پایگاه داده از بیانیه محدود سیستم Alter System استفاده می کند تا از پایگاه داده استفاده کند. فقط کاربران SYS و SYSTE می توانند بیانیه محدود سیستم ALTER SYSTEM را صادر کنند. برای همه موارد با پایگاه داده باز ، صدور این بیانیه تأثیر زیر دارد:

اوراکل در تمام موارد به مدیر منابع پایگاه داده دستور می دهد تا از فعال شدن همه جلسات غیرفعال (غیر از سیستم و سیستم) جلوگیری کند. هیچ کاربر دیگری به غیر از SYS و سیستم نمی تواند یک معامله جدید ، یک پرس و جو جدید ، یک واکشی جدید یا یک عمل جدید PL/SQL را آغاز کند.

اوراکل منتظر تمام معاملات موجود در تمام مواردی است که توسط یک کاربر غیر از SYS یا سیستم آغاز شده است (یا متعهد یا خاتمه یابد). اوراکل همچنین در تمام مواردی که توسط کاربران غیر از SYS یا سیستم آغاز شده و در معاملات آنها به پایان رسیده اند ، منتظر کلیه نمایش داده شدگان ، واکشی ها و PL/SQL است. اگر یک پرس و جو توسط چندین واسطه پی در پی OCI انجام شود ، اوراکل منتظر نیست تا همه واکشی ها تمام شوند. منتظر است تا واکشی فعلی تمام شود و سپس واکشی بعدی را مسدود کند. اوراکل همچنین منتظر همه جلسات (به غیر از برنامه های SYS یا سیستم) است که دارای منابع مشترک (مانند Enqueues) برای انتشار این منابع است. پس از اتمام همه این عملیات ، اوراکل پایگاه داده را در حالت سکونت قرار داده و اجرای بیانیه محدود را به پایان می رساند.

اگر نمونه ای در حالت سرور مشترک در حال اجرا باشد ، اوراکل به مدیر منبع بانک اطلاعاتی دستور می دهد تا در آن نمونه ورود به سیستم (غیر از سیستم یا سیستم) را مسدود کند. اگر نمونه ای در حالت غیر Server در حال اجرا باشد ، Oracle در این مورد هیچ محدودیتی در ورود به سیستم کاربر اعمال نمی کند.

در حین حالت سکونت ، شما نمی توانید برنامه مدیر منابع را به هر حال تغییر دهید.

بیانیه Alter System Unquiesce تمام نمونه های در حال اجرا را به حالت عادی باز می گرداند ، به طوری که تمام اقدامات مسدود شده می توانند ادامه یابد.