قاعدة بيانات أوراكل / الأساسي: أسس العلاقات والمعاملات / الدرس 6
المعاملات ونقاط الحفظ وحدود DDL
صمّم تغيير الشحنة كوحدة عمل صريحة وافهم التثبيت الضمني في أوراكل.
في هذه الصفحة
أهداف الدرس
- اشرح الرؤية وCOMMIT وROLLBACK ونقاط الحفظ.
- افصل تغييرات المخطط عن حدود التراجع المفترضة لـDML.
تحمي المعاملة انتقالاً تجارياً
قد يتطلب حجز شحنة صفاً أباً وسعة محجوزة وحدث تدقيق. إذا وجب اتفاق هذه الحقائق، تنتمي إلى وحدة عمل صريحة واحدة. لا تعادل المعاملة تلقائياً طلب HTTP أو ملف SQL؛ فقد تغيّر التثبيتَ التلقائي وإعادة استخدام الاتصال والدوال المساعدة حدودُها. وثّق من يبدأ المعاملة وينهيها وكيف تنتهي المسارات الاستثنائية. لا تترك القرار لإغلاق الاتصال لأن الأدوات والمشغلات تختلف، ولأن الإنهاء غير الطبيعي ليس بروتوكول عمل موثوقاً.
تختلف تغييراتك عن رؤيتها لدى الآخرين
ترى الجلسة عادة تغييراتها غير المثبتة، ولا تقرأها الجلسات الأخرى. في مستوى READ COMMITTED الافتراضي يرى كل استعلام عادي صورة متسقة مثبتة خاصة بالعبارة، لذلك قد يرى استعلامان في المعاملة نفسها أعمالاً مثبتة مختلفة من جلسات أخرى. لا يبرر هذا سباق القراءة ثم التعديل ثم الكتابة. استخدم تحديثاً شرطياً أو بروتوكول قفل مراجعاً إذا وُجد قيد للسعة. لذا لا تثبت لقطة جلسة الكاتب أن جلسة التطبيق الأخرى ترى الحجز الجديد.
تراجع عن فرع دون فقدان العمل السابق
تحدد نقطة الحفظ موضعاً داخل المعاملة الحالية. يتراجع ROLLBACK TO عما بعدها مع حفظ السابق دون تثبيته. يبدأ الأثر التعليمي بسعة عشرة، ويحجز وحدتين ثم يعكس تعديلاً لاحقاً بوحدة. يبقى الحجز معلقاً حتى COMMIT النهائي. يجب تضمين فحص الصفوف المتأثرة في منطق التطبيق، خصوصاً عند غياب المعرّف. تنتمي أسماء نقاط الحفظ إلى معاملة واحدة ويمحوها التثبيت أو التراجع الكامل.
UPDATE capacity SET free_units = free_units - 2 WHERE slot_id = 7;
SAVEPOINT after_reservation;
UPDATE capacity SET free_units = free_units - 1 WHERE slot_id = 7;
ROLLBACK TO after_reservation;
COMMIT;بافتراض أن الخانة 7 تبدأ بـ10 وأن كل تحديث يطابق صفاً واحداً، تصبح free_units المثبتة 8. هذا أثر مستنتج ولم يُنفذ.
قد ينهي DDL تغييرات DML السابقة دون توقع
تجري أوراكل تثبيتاً ضمنياً قبل DDL صحيح صياغياً حتى إذا فشل لاحقاً، وبعد DDL الناجح. لذلك قد يثبّت CREATE TABLE حجزاً سابقاً غير مثبت قبل محاولة الإنشاء. ولا يستطيع ROLLBACK لاحق إلغاء العمل المثبت. لا تنقل استراتيجية ترحيل من PostgreSQL بافتراض أن تغييرات المخطط والبيانات كلها معاملة قابلة للعكس. خطّط لتطور المخطط بمراحل مراجعَة ونقاط تحقق وأفعال تعويض. التسلسل هنا توضيحي فقط ولا يُنفّذ على قاعدة مهيأة.
INSERT INTO booking_log (booking_id, note) VALUES (501, 'lab booking');
CREATE TABLE booking_probe (probe_id NUMBER);
ROLLBACK;قد يكون INSERT قد ثُبّت بالفعل عند حد DDL؛ ولا يعيد ROLLBACK النهائي المخطط والبيانات إلى البداية.
فقدان الاستجابة يخلق حالة عدم يقين
لا يثبت إخفاق الشبكة بعد إرسال COMMIT حدوث تراجع؛ فقد ثبّت الخادم المعاملة قبل فقدان الإقرار. قد يكرر إدراج بلا مفتاح طلب العملية التجارية. صمّم معرّف طلب فريداً واستعلام مطابقة ليكتشف التطبيق وجود الحجز المقصود. ضع الآثار الخارجية كالبريد خلف صندوق صادر موثوق أو بروتوكول منسق؛ لا يسحب تراجع القاعدة رسالة سُلّمت بالفعل. تشمل صحة المعاملة معرفة العميل بالنتيجة، لا حالة المحرك الداخلية وحدها.
الأخطاء الشائعة وإصلاحها
ORA-01086
- لماذا يحدث؟
- لم تعد نقطة الحفظ صالحة بعد تثبيت أو تراجع أو تغيير سياق المعاملة.
- كيف تصلحه؟
- راجع حدود المعاملة الفعلية بما فيها تثبيت الدوال المساعدة وDDL.
- كيف تتجنب تكراره؟
- اجعل ملكية المعاملة صريحة في طبقة الخدمة.
لم يُلغِ ROLLBACK إدراجاً سابقاً
- لماذا يحدث؟
- ثبّت DDL متداخل تغييرات DML السابقة ضمنياً.
- كيف تصلحه؟
- طابق البيانات المثبتة واستخدم تغييراً تعويضياً مراجعاً عند الحاجة.
- كيف تتجنب تكراره؟
- افصل مراحل الترحيل عن أمثلة معاملات التطبيق.
تنشئ الإعادة حجزاً ثانياً
- لماذا يحدث؟
- افترض العميل أن فقدان استجابة التثبيت يعني الفشل.
- كيف تصلحه؟
- تحقق من معرّف الطلب قبل إعادة العملية.
- كيف تتجنب تكراره؟
- افرض عدم التكرار بمفتاح طلب أعمال فريد مخزن.
اختبر فهمك
1. تأتي نقطة حفظ بعد الحجز وقبل ملاحظة اختيارية. ماذا يبقى بعد ROLLBACK TO؟
اعرض الحل المشروح
يبقى الحجز غير مثبت داخل المعاملة وتُلغى الملاحظة اللاحقة. يجب أن يختار التطبيق COMMIT أو تراجعاً كاملاً لوحدة العمل، ويتحقق من أعداد الصفوف المتأثرة ويتجنب التأكيدات الخارجية قبل معرفة النتيجة الدائمة.
2. يتبع INSERT أمر DDL صحيح صياغياً يفشل لوجود الاسم. هل يمحو التراجع اللاحق الإدراج بصورة موثوقة؟
اعرض الحل المشروح
لا؛ قد يكون التثبيت الضمني قبل DDL قد ثبّت INSERT. عامل الإدراج كعمل قد يكون دائماً، وافحص المفتاح المعروف بأدلة مصرح بها واتبع خطة استعادة الترحيل. فشل DDL لا يعيد حدود المعاملة السابقة.
أهم ما تعلمته
- تقسم نقاط الحفظ العمل المعلق ولا تنشئ معاملات متداخلة دائمة.
- يجب مراعاة التثبيت الضمني والإقرارات المجهولة في تصميم الاستعادة.