DBA ARABIC

ﻓﻠﺤﻅﺔ ﺇﺠﺭﺍﺀ ﻋﻤﻠﻴﺔ 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 ﻟﻠﺠﺩﺍﻭل ﻴﺩﻭﻴﺎﹰ ﻋﻨﺩﻤﺎ ﻴﺤﺘﺎﺝ ﻟﺫﻟﻙ ﻜﻤﻨﻊ ﺍﻟﻤﺴﺘﺨﺩﻤﻴﻥ ﻤﻥ ﺍﻟﺘﻌﺩﻴل ﻓﻲ ﺒﻌﺽ ﺍﻟﺠﺩﻭل ﺃﺤﻴﺎﻨﺎﹰ.

----------------------------------------------

DATABASE

SQL

VIDEOS

Orcale Tutorial Content

Dealing with Locking

Shared & Exclusive Locks