الفكرة السائدة تقول أنه لا يمكن لأكثر من مستخدم في قاعدة البيانات تعديل نفس الصف في نفس الجدول في نفس الوقت.

هذا غير مقبول منطقيًا، وقاعدة البيانات تمنع ذلك عن طريق منع أكثر من مستخدم من العمل على نفس الصف في نفس الوقت، وهي آلية تعرف بالـ Lock.

بالطبع، عملية الاستعلام (SELECT) تستطيع العمل حتى لو كان ذلك الصف المستخدم عنه مقفل عن طريق مستخدم آخر، وذلك لأنها ستعرض لك القيم من الـ Undo Information.

ما دام أن ذلك الحقل لم يُحرر بعد عن طريق تثبيت التعديل أو التراجع عنه، والحقيقة أن هناك نوعان من الأقفال (Exclusive و Shared Locks)،

فلحظة إجراء عملية DML على حقل معين يتم تمكين نوعين من الأقفال: Exclusive Lock على مستوى الحقل أو الصف لمنع أي مستخدم آخر أو بمعنى أدق أي Session آخر من الوصول

لنفس الحقل، والنوع الآخر هو Shared Lock للجدول لمنع أي عملية DDL على مستوى الجدول كتعديل تركيبة الجدول أو حذفه، يتم ذلك بشكل آلي عن طريق الأوراكل.

إذاً، يتم استخدام الـ Exclusive Lock لمنع الوصول للحقل أو الجدول أثناء انشغاله بSession آخر، وSession واحدة هي التي تقوم بعمل الـ Exclusive Lock على مستوى الحقول أو الجدول،

أما الـ Shared Lock فعَدَد من الـ Sessions يمكن أن تتشارك في عمل Shared Lock لنفس الجدول لمنع أي Session أخرى من عمل Exclusive Lock على الجدول.

عمومًا تدعم الأوراكل عمل الـ Lock بشكل آلي ويمكن أن يتم ذلك بطريقة يدوية. إذاً، إذا كنت لا تستطيع عمل Exclusive Lock لجدول هو في الحقيقة في الوضع Shared Lock.

بكل بساطة نستطيع القول أنه في حالة عمل تعديل لبعض الحقول في جدول معين فإنه يتم عمل Exclusive Lock لتلك الحقول حتى لا تستطيع Session أخرى الكتابة في هذه الحقول

حتى تنتهي Session الأولى من عملها؛ مع العلم أن عملية القراءة فقط متاحة حتى في حالة الـ Exclusive Lock وذلك لأن القراءة تتم من الـ Undo Data،

وأيضًا أثناء عمل التعديل في حقول معينة يتم عمل Shared Lock للجدول وذلك لمنع عمل Exclusive Lock للجدول التي يتمكن من خلالها المستخدم إنجاز عمليات الـ DDL كعمليات الحذف

وتغيير هيكلة الجدول.

إذاً لإنجاز عمليات الـ DDL على جدول معين يجب عمل Exclusive Lock على مستوى الجدول أي Session أخرى من التعامل مع الجدول، ولا نستطيع عمل Exclusive Lock على مستوى الجدول

حتى تتم جميع عمليات الـ DML على الجدول أو بمعنى آخر حتى يتم إنهاء الـ Exclusive Lock على مستوى الحقول وكذلك الـ Shared Lock على مستوى الجدول،

إذاً الهدف من الـ Shared Lock هو منع عمليات الـ DDL على الجدول أو بمعنى آخر منع الـ Exclusive Lock على مستوى الجدول.

لنفرض الآن أن مستخدم قاعدة البيانات قام بفتح Session عن طريق SQL*PLUS وقام بإنشاء جدول يسمى TEST وقام بإضافة سجل واحد للجدول.

CREATE TABLE TEST (NO NUMBER(5));

INSERT INTO TEST VALUES(1);

SELECT * FROM TEST; 

ثم قام نفس المستخدم بفتح Session أخرى وقام بعمل استعلام على الجدول TEST.

SELECT * FROM TEST; 

لاحظ أن الإضافة في الجدول لم تظهر من خلال هذه الSession لأن هذه العملية لم يتم تثبيتها بعد.

الآن لو تم تثبيت هذه البيانات من خلال الSession الأول عن طريق الأمر Commit وقمت بإعادة الاستعلام من خلال الSession الثانية فإن البيانات ستظهر.

وذلك لأنه لحظة عمل الCommit يتم تثبيت البيانات وإطلاق الLock.

لاحظ أنه لو تم عمل تعديل من خلال الSession الأول ولم يتم تثبيت البيانات ثم من خلال الSession الثانية قمت بعمل استعلام فإن الاستعلام سوف يأتي لك بالقيمة القديمة من الUndo Data.

الآن لو قمنا بعمل تعديل للحقل في الجدول TEST من خلال الSession الأول ولم نقم بتثبيت التعديل.

UPDATE TEST SET NO=2 WHERE NO=1; 

ثم من خلال الSession الثانية لو قمنا بعمل تغيير في هيكلة الجدول من خلال الأمر ALTER وهي تدخل ضمن عمليات الـDDL.

ALTER TABLE TEST ADD (NAME VARCHAR2(40)); 

هل تعرف لماذا لم تستطع فعل ذلك؟

الرسالة تقول لك إن الجدول مشغول بعملية أخرى وهذا صحيح لأنه لم يتم بعد تثبيت عملية التعديل من خلال الSession الأول، إذ ما زال الـExclusive Lock قائماً على حقل الجدول ولا تستطيع إجراء عمليات الـDDL حتى يتم إنهاء الـExclusive Lock من على مستوى الحقل وأيضاً إنهاء الـShared Lock من على الجدول.

ذلك لأن عمليات الـDDL تحتاج لعمل الـExclusive Lock على مستوى الجدول والـShared Lock يمنع ذلك.

الآن لو قمت بتثبيت البيانات أو التراجع عنها من خلال الSession الأول وأعدت عملية الـALTER، فإن العملية ستنجح.

بالطبع جميع عمليات الـLock التي تحدثنا عنها سابقاً تحدث بشكل آلي عن طريق الأوراكل،

لكن قد يقوم مدير قاعدة البيانات بعمل Lock للجدول يدوياً عندما يحتاج لذلك كمنع المستخدمين من التعديل في بعض الجدول أحياناً.