MySQL और PostgreSQL में गतिरोध को समझना

डेटाबेस के साथ काम करना, समवर्ती नियंत्रण वह अवधारणा है जो यह सुनिश्चित करती है कि डेटा अखंडता का उल्लंघन किए बिना डेटाबेस लेनदेन समवर्ती रूप से किया जाता है।

इस अवधारणा के आसपास बहुत सारे सिद्धांत और विभिन्न दृष्टिकोण हैं और इसे कैसे पूरा किया जाए, लेकिन हम संक्षेप में उस तरीके का उल्लेख करेंगे जो PostgreSQL और MySQL (InnoDB का उपयोग करते समय) इसे संभालते हैं, और एक सामान्य समस्या जो अत्यधिक समवर्ती प्रणालियों में उत्पन्न हो सकती है:गतिरोध।

ये इंजन एमवीसीसी (मल्टीवर्सन कंसुरेंसी कंट्रोल) नामक विधि का उपयोग करके समवर्ती नियंत्रण लागू करते हैं। इस पद्धति में, जब कोई आइटम अपडेट किया जा रहा है, तो परिवर्तन मूल डेटा को अधिलेखित नहीं करेंगे, बल्कि इसके बजाय, आइटम का एक नया संस्करण (परिवर्तनों के साथ) बनाया जाएगा। इस प्रकार हमारे पास संग्रहीत आइटम के कई संस्करण होंगे।

इस मॉडल के मुख्य लाभों में से एक यह है कि डेटा को क्वेरी करने (पढ़ने) के लिए प्राप्त किए गए ताले डेटा लिखने के लिए प्राप्त किए गए ताले के साथ संघर्ष नहीं करते हैं, और इसलिए पढ़ना कभी भी लेखन को अवरुद्ध नहीं करता है, और लेखन कभी भी पढ़ने को अवरुद्ध नहीं करता है।

लेकिन, यदि एक ही आइटम के कई संस्करण संग्रहीत किए जाते हैं, तो लेन-देन का कौन सा संस्करण दिखाई देगा? उस प्रश्न का उत्तर देने के लिए हमें लेन-देन अलगाव की अवधारणा की समीक्षा करने की आवश्यकता है। लेन-देन एक अलगाव स्तर निर्दिष्ट करते हैं, जो उस डिग्री को परिभाषित करता है जिसमें एक लेनदेन को अन्य लेनदेन द्वारा किए गए संसाधन या डेटा संशोधनों से अलग किया जाना चाहिए। यह डिग्री सीधे लेन-देन द्वारा उत्पन्न लॉकिंग से संबंधित है, और इसलिए, जैसा कि इसे लेनदेन स्तर पर निर्दिष्ट किया जा सकता है, यह उस प्रभाव को निर्धारित कर सकता है जो चल रहे लेनदेन का अन्य चल रहे लेनदेन पर हो सकता है।

यह एक बहुत ही रोचक और लंबा विषय है, हालांकि हम इस ब्लॉग में बहुत अधिक विवरण में नहीं जाएंगे। हम इस विषय पर आगे पढ़ने के लिए PostgreSQL और MySQL आधिकारिक दस्तावेज़ीकरण की अनुशंसा करते हैं।

तो, गतिरोध से निपटने के दौरान हम उपरोक्त विषयों पर क्यों जा रहे हैं? क्योंकि MVCC व्यवहार सुनिश्चित करने के लिए sql कमांड स्वचालित रूप से ताले प्राप्त कर लेगा, और प्राप्त लॉक प्रकार परिभाषित लेनदेन अलगाव पर निर्भर करता है।

कई प्रकार के ताले हैं (फिर से PostgreSQL और MySQL के लिए समीक्षा करने के लिए एक और लंबा और दिलचस्प विषय) लेकिन, उनके बारे में महत्वपूर्ण बात यह है कि वे एक दूसरे के साथ कैसे बातचीत करते हैं (सबसे सटीक, वे कैसे संघर्ष करते हैं)। ऐसा क्यों है? क्योंकि दो लेन-देन एक ही समय में एक ही वस्तु पर परस्पर विरोधी मोड के ताले नहीं रख सकते। और एक गैर-मामूली विवरण, एक बार प्राप्त करने के बाद, लेन-देन के अंत तक सामान्य रूप से एक ताला लगा रहता है।

यह एक पोस्टग्रेएसक्यूएल उदाहरण है कि कैसे लॉकिंग प्रकार एक दूसरे के साथ संघर्ष करते हैं:

और MySQL के लिए:

तो क्या होता है जब मेरे पास दो चल रहे लेन-देन होते हैं जो एक ही वस्तु पर एक ही समय में परस्पर विरोधी ताले रखना चाहते हैं? उनमें से एक को लॉक मिलेगा और दूसरे को इंतजार करना होगा।

तो अब हम वास्तव में यह समझने की स्थिति में हैं कि गतिरोध के दौरान क्या हो रहा है।

फिर गतिरोध क्या है? जैसा कि आप कल्पना कर सकते हैं, डेटाबेस गतिरोध के लिए कई परिभाषाएं हैं, लेकिन मुझे इसकी सादगी के लिए निम्नलिखित पसंद हैं।

एक डेटाबेस गतिरोध एक ऐसी स्थिति है जिसमें दो या दो से अधिक लेन-देन एक दूसरे के लिए ताले छोड़ने की प्रतीक्षा कर रहे हैं।

तो उदाहरण के लिए, निम्न स्थिति हमें गतिरोध की ओर ले जाएगी:

यहां, एप्लिकेशन ए को अपडेट करने के लिए तालिका 1 पंक्ति 1 पर लॉक मिलता है।

उसी समय एप्लिकेशन बी को तालिका 2 पंक्ति 2 पर लॉक मिलता है।

अब एप्लिकेशन ए को निष्पादन जारी रखने और लेनदेन समाप्त करने के लिए तालिका 2 पंक्ति 2 पर लॉक प्राप्त करने की आवश्यकता है, लेकिन इसे लॉक नहीं मिल सकता है क्योंकि यह एप्लिकेशन बी द्वारा आयोजित किया जाता है। एप्लिकेशन ए को इसे जारी करने के लिए एप्लिकेशन बी की प्रतीक्षा करनी होगी। ।

लेकिन एप्लिकेशन बी को निष्पादन जारी रखने और लेनदेन समाप्त करने के लिए तालिका 1 पंक्ति 1 पर लॉक प्राप्त करने की आवश्यकता है, लेकिन इसे लॉक नहीं मिल सकता क्योंकि यह एप्लिकेशन ए द्वारा आयोजित किया जाता है।

इसलिए यहां हम गतिरोध की स्थिति में हैं। आवेदन ए समाप्त होने के लिए आवेदन बी द्वारा रखे गए संसाधन की प्रतीक्षा कर रहा है और आवेदन बी आवेदन ए द्वारा रखे गए संसाधन की प्रतीक्षा कर रहा है। तो, कैसे जारी रखें? डेटाबेस इंजन गतिरोध का पता लगाएगा और एक लेन-देन को समाप्त कर देगा, दूसरे को अनवरोधित कर देगा और मारे गए एक पर गतिरोध त्रुटि बढ़ा देगा।

आइए कुछ PostgreSQL और MySQL गतिरोध उदाहरणों की जाँच करें:

पोस्टग्रेएसक्यूएल

मान लीजिए कि हमारे पास दुनिया के देशों की जानकारी के साथ एक परीक्षण डेटाबेस है।

world=# SELECT code,region,population FROM country WHERE code IN ('NLD','AUS');
code |          region           | population
------+---------------------------+------------
NLD  | Western Europe            |   15864000
AUS  | Australia and New Zealand |   18886000
(2 rows)

हमारे पास दो सत्र हैं जो डेटाबेस में परिवर्तन करना चाहते हैं।

पहला सत्र NLD कोड के लिए क्षेत्र फ़ील्ड और AUS कोड के लिए जनसंख्या फ़ील्ड को संशोधित करेगा।

दूसरा सत्र AUS कोड के लिए क्षेत्र फ़ील्ड और NLD कोड के लिए जनसंख्या फ़ील्ड को संशोधित करेगा।

तालिका डेटा:

code: NLD
region: Western Europe
population: 15864000

code: AUS
region: Australia and New Zealand
population: 18886000

सत्र 1:

world=# BEGIN;
BEGIN
world=# UPDATE country SET region='Europe' WHERE code='NLD';
UPDATE 1

सत्र 2:

world=# BEGIN;
BEGIN
world=# UPDATE country SET region='Oceania' WHERE code='AUS';
UPDATE 1
world=# UPDATE country SET population=15864001 WHERE code='NLD';

सत्र 2 समाप्त होने की प्रतीक्षा में सत्र 2 लटका रहेगा।

सत्र 1:

world=# UPDATE country SET population=18886001 WHERE code='AUS';

ERROR:  deadlock detected
DETAIL:  Process 1181 waits for ShareLock on transaction 579; blocked by process 1148.
Process 1148 waits for ShareLock on transaction 578; blocked by process 1181.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (0,15) in relation "country"

यहां हमारा गतिरोध है। सिस्टम ने गतिरोध का पता लगाया और सत्र 1 को समाप्त कर दिया।

सत्र 2:

world=# BEGIN;
BEGIN
world=# UPDATE country SET region='Oceania' WHERE code='AUS';
UPDATE 1
world=# UPDATE country SET population=15864001 WHERE code='NLD';
UPDATE 1

और हम जांच सकते हैं कि गतिरोध का पता चलने के बाद दूसरा सत्र सही ढंग से समाप्त हुआ और सत्र 1 समाप्त हो गया (इस प्रकार, ताला जारी किया गया था)।

अधिक जानकारी के लिए हम अपने PostgreSQL सर्वर में लॉग देख सकते हैं:

2018-05-16 12:56:38.520 -03 [1181] ERROR:  deadlock detected
2018-05-16 12:56:38.520 -03 [1181] DETAIL:  Process 1181 waits for ShareLock on transaction 579; blocked by process 1148.
       Process 1148 waits for ShareLock on transaction 578; blocked by process 1181.
       Process 1181: UPDATE country SET population=18886001 WHERE code='AUS';
       Process 1148: UPDATE country SET population=15864001 WHERE code='NLD';
2018-05-16 12:56:38.520 -03 [1181] HINT:  See server log for query details.
2018-05-16 12:56:38.520 -03 [1181] CONTEXT:  while updating tuple (0,15) in relation "country"
2018-05-16 12:56:38.520 -03 [1181] STATEMENT:  UPDATE country SET population=18886001 WHERE code='AUS';
2018-05-16 12:59:50.568 -03 [1181] ERROR:  current transaction is aborted, commands ignored until end of transaction block

यहां हम उन वास्तविक आदेशों को देख पाएंगे जो गतिरोध पर पाए गए थे।

MySQL

MySQL में गतिरोध का अनुकरण करने के लिए हम निम्नलिखित कार्य कर सकते हैं।

PostgreSQL की तरह, मान लीजिए कि हमारे पास अन्य चीजों के अलावा अभिनेताओं और फिल्मों की जानकारी के साथ एक परीक्षण डेटाबेस है।

mysql> SELECT first_name,last_name FROM actor WHERE actor_id IN (1,7);
+------------+-----------+
| first_name | last_name |
+------------+-----------+
| PENELOPE   | GUINESS   |
| GRACE      | MOSTEL    |
+------------+-----------+
2 rows in set (0.00 sec)

हमारे पास दो प्रक्रियाएं हैं जो डेटाबेस में परिवर्तन करना चाहती हैं।

पहली प्रक्रिया अभिनेता_आईडी 1 के लिए first_name फ़ील्ड और अभिनेता_आईडी 7 के लिए last_name फ़ील्ड को संशोधित करेगी।

दूसरी प्रक्रिया अभिनेता_आईडी 7 के लिए first_name फ़ील्ड और अभिनेता_आईडी 1 के लिए last_name फ़ील्ड को संशोधित करेगी।

तालिका डेटा:

actor_id: 1
first_name: PENELOPE
last_name: GUINESS

actor_id: 7
first_name: GRACE
last_name: MOSTEL

सत्र 1:

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE actor SET first_name='GUINESS' WHERE actor_id='1';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

सत्र 2:

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE actor SET first_name='MOSTEL' WHERE actor_id='7';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE actor SET last_name='PENELOPE' WHERE actor_id='1';

सत्र 2 समाप्त होने की प्रतीक्षा में सत्र 2 लटका रहेगा।

सत्र 1:

mysql> UPDATE actor SET last_name='GRACE' WHERE actor_id='7';

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

यहां हमारा गतिरोध है। सिस्टम ने गतिरोध का पता लगाया और सत्र 1 को समाप्त कर दिया।

सत्र 2:

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE actor SET first_name='MOSTEL' WHERE actor_id='7';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE actor SET last_name='PENELOPE' WHERE actor_id='1';
Query OK, 1 row affected (8.52 sec)
Rows matched: 1  Changed: 1  Warnings: 0

जैसा कि हम त्रुटि में देख सकते हैं, जैसा कि हमने PostgreSQL के लिए देखा, दोनों प्रक्रियाओं के बीच एक गतिरोध है।

अधिक जानकारी के लिए हम SHOW ENGINE INNODB STATUS\G कमांड का उपयोग कर सकते हैं:

mysql> SHOW ENGINE INNODB STATUS\G
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-05-16 18:55:46 0x7f4c34128700
*** (1) TRANSACTION:
TRANSACTION 1456, ACTIVE 33 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 54, OS thread handle 139965388506880, query id 15876 localhost root updating
UPDATE actor SET last_name='PENELOPE' WHERE actor_id='1'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1456 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0001; asc   ;;
1: len 6; hex 0000000005af; asc       ;;
2: len 7; hex 2d000001690110; asc -   i  ;;
3: len 7; hex 4755494e455353; asc GUINESS;;
4: len 7; hex 4755494e455353; asc GUINESS;;
5: len 4; hex 5afca8b3; asc Z   ;;

*** (2) TRANSACTION:
TRANSACTION 1455, ACTIVE 47 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 53, OS thread handle 139965267871488, query id 16013 localhost root updating
UPDATE actor SET last_name='GRACE' WHERE actor_id='7'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1455 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0001; asc   ;;
1: len 6; hex 0000000005af; asc       ;;
2: len 7; hex 2d000001690110; asc -   i  ;;
3: len 7; hex 4755494e455353; asc GUINESS;;
4: len 7; hex 4755494e455353; asc GUINESS;;
5: len 4; hex 5afca8b3; asc Z   ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1455 lock_mode X locks rec but not gap waiting
Record lock, heap no 202 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0007; asc   ;;
1: len 6; hex 0000000005b0; asc       ;;
2: len 7; hex 2e0000016a0110; asc .   j  ;;
3: len 6; hex 4d4f5354454c; asc MOSTEL;;
4: len 6; hex 4d4f5354454c; asc MOSTEL;;
5: len 4; hex 5afca8c1; asc Z   ;;

*** WE ROLL BACK TRANSACTION (2)

"LATEST DETECTED DEADLOCK" शीर्षक के तहत, हम अपने गतिरोध का विवरण देख सकते हैं।

mysql त्रुटि लॉग में गतिरोध का विवरण देखने के लिए, हमें अपने डेटाबेस में विकल्प innodb_print_all_deadlocks को सक्षम करना होगा।

mysql> set global innodb_print_all_deadlocks=1;
Query OK, 0 rows affected (0.00 sec)

MySQL लॉग त्रुटि:

2018-05-17T18:36:58.341835Z 12 [Note] InnoDB: Transactions deadlock detected, dumping detailed information.
2018-05-17T18:36:58.341869Z 12 [Note] InnoDB:
*** (1) TRANSACTION:
 
TRANSACTION 1812, ACTIVE 42 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 11, OS thread handle 140515492943616, query id 8467 localhost root updating
UPDATE actor SET last_name='PENELOPE' WHERE actor_id='1'
2018-05-17T18:36:58.341945Z 12 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
 
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1812 lock_mode X locks rec but not gap waiting
Record lock, heap no 204 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0001; asc   ;;
1: len 6; hex 000000000713; asc       ;;
2: len 7; hex 330000016b0110; asc 3   k  ;;
3: len 7; hex 4755494e455353; asc GUINESS;;
4: len 7; hex 4755494e455353; asc GUINESS;;
5: len 4; hex 5afdcb89; asc Z   ;;
 
2018-05-17T18:36:58.342347Z 12 [Note] InnoDB: *** (2) TRANSACTION:
 
TRANSACTION 1811, ACTIVE 65 sec starting index read, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 12, OS thread handle 140515492677376, query id 9075 localhost root updating
UPDATE actor SET last_name='GRACE' WHERE actor_id='7'
2018-05-17T18:36:58.342409Z 12 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):
 
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1811 lock_mode X locks rec but not gap
Record lock, heap no 204 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0001; asc   ;;
1: len 6; hex 000000000713; asc       ;;
2: len 7; hex 330000016b0110; asc 3   k  ;;
3: len 7; hex 4755494e455353; asc GUINESS;;
4: len 7; hex 4755494e455353; asc GUINESS;;
5: len 4; hex 5afdcb89; asc Z   ;;
 
2018-05-17T18:36:58.342793Z 12 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
 
RECORD LOCKS space id 23 page no 3 n bits 272 index PRIMARY of table `sakila`.`actor` trx id 1811 lock_mode X locks rec but not gap waiting
Record lock, heap no 205 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 2; hex 0007; asc   ;;
1: len 6; hex 000000000714; asc       ;;
2: len 7; hex 340000016c0110; asc 4   l  ;;
3: len 6; hex 4d4f5354454c; asc MOSTEL;;
4: len 6; hex 4d4f5354454c; asc MOSTEL;;
5: len 4; hex 5afdcba0; asc Z   ;;
 
2018-05-17T18:36:58.343105Z 12 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (2)

गतिरोध क्यों होता है, इस बारे में हमने ऊपर जो सीखा है, उसे ध्यान में रखते हुए, आप देख सकते हैं कि डेटाबेस की तरफ से उनसे बचने के लिए हम बहुत कुछ नहीं कर सकते हैं। वैसे भी, डीबीए के रूप में यह हमारा कर्तव्य है कि हम वास्तव में उन्हें पकड़ें, उनका विश्लेषण करें और डेवलपर्स को प्रतिक्रिया दें।

वास्तविकता यह है कि ये त्रुटियां प्रत्येक एप्लिकेशन के लिए विशेष हैं, इसलिए आपको उन्हें एक-एक करके जांचना होगा और आपको यह बताने के लिए कोई गाइड नहीं है कि इसका निवारण कैसे किया जाए। इसे ध्यान में रखते हुए, कुछ चीजें हैं जिन्हें आप ढूंढ सकते हैं।

जांच और गतिरोध से बचने के लिए युक्तियाँ

लंबे समय से चल रहे लेनदेन की खोज करें। चूंकि आमतौर पर लेन-देन के अंत तक ताले लगाए जाते हैं, लेन-देन जितना लंबा होगा, संसाधनों पर ताले उतने ही लंबे होंगे। यदि संभव हो, तो लंबे समय से चल रहे लेन-देन को छोटे/तेज़ लेन-देन में विभाजित करने का प्रयास करें।

कभी-कभी लेनदेन को वास्तव में विभाजित करना संभव नहीं होता है, इसलिए काम को हर बार एक सुसंगत क्रम में उन कार्यों को निष्पादित करने के प्रयास पर ध्यान केंद्रित करना चाहिए, इसलिए लेनदेन अच्छी तरह से परिभाषित कतार बनाते हैं और गतिरोध नहीं करते हैं।

एक समाधान जिसे आप प्रस्तावित भी कर सकते हैं, वह यह है कि एप्लिकेशन में पुन:प्रयास तर्क जोड़ें (बेशक, पहले अंतर्निहित समस्या को हल करने का प्रयास करें) ताकि, यदि कोई गतिरोध होता है, तो एप्लिकेशन उसी कमांड को फिर से चलाएगा।

उपयोग किए गए अलगाव स्तरों की जाँच करें, कभी-कभी आप उन्हें बदलकर प्रयास करते हैं। अद्यतन के लिए चयन करें, और साझा करने के लिए चयन करें जैसे आदेशों की तलाश करें, क्योंकि वे स्पष्ट ताले उत्पन्न करते हैं, और मूल्यांकन करते हैं कि क्या उन्हें वास्तव में आवश्यकता है या आप डेटा के पुराने स्नैपशॉट के साथ काम कर सकते हैं। यदि आप इन आदेशों को हटा नहीं सकते हैं तो एक चीज आप आजमा सकते हैं, जैसे कि कम से कम अलगाव स्तर का उपयोग करना।

बेशक, हमेशा अपनी टेबल में अच्छी तरह से चुने गए इंडेक्स जोड़ें। फिर आपके प्रश्नों को कम अनुक्रमणिका रिकॉर्ड स्कैन करने और परिणामस्वरूप कम लॉक सेट करने की आवश्यकता होती है।

उच्च स्तर पर, डीबीए के रूप में आप सामान्य रूप से लॉकिंग को कम करने के लिए कुछ सावधानियां बरत सकते हैं। एक उदाहरण का नाम देने के लिए, इस मामले में PostgreSQL के लिए, आप उसी कमांड में एक डिफ़ॉल्ट मान जोड़ने से बच सकते हैं जिसमें आप एक कॉलम जोड़ेंगे। किसी तालिका को बदलने से वास्तव में एक आक्रामक लॉक मिलेगा, और इसके लिए एक डिफ़ॉल्ट मान सेट करने से वास्तव में मौजूदा पंक्तियों को अपडेट किया जाएगा जिनमें शून्य मान हैं, जिससे यह ऑपरेशन वास्तव में लंबा हो जाता है। इसलिए यदि आप इस ऑपरेशन को कई कमांड में विभाजित करते हैं, कॉलम जोड़ते हैं, डिफ़ॉल्ट जोड़ते हैं, शून्य मानों को अपडेट करते हैं, तो आप लॉकिंग प्रभाव को कम कर देंगे।

बेशक, इस तरह की कई युक्तियां हैं जो डीबीए को अभ्यास के साथ मिलती हैं (एक साथ इंडेक्स बनाना, पीके जोड़ने से पहले पीके इंडेक्स अलग से बनाना, और इसी तरह), लेकिन महत्वपूर्ण बात यह है कि इस "तरीके को सीखना और समझना" सोच" और हमेशा हमारे द्वारा किए जा रहे कार्यों के लॉक प्रभाव को कम करने के लिए।

सारांश

उम्मीद है, इस ब्लॉग ने आपको डेटाबेस गतिरोध और उन्हें दूर करने के बारे में उपयोगी जानकारी प्रदान की है। चूंकि गतिरोध से बचने का कोई निश्चित तरीका नहीं है, इसलिए यह जानना कि वे कैसे काम करते हैं, इससे पहले कि वे आपके डेटाबेस इंस्टेंस को नुकसान पहुंचाएं, आपको उन्हें पकड़ने में मदद मिल सकती है। ClusterControl जैसे सॉफ़्टवेयर समाधान यह सुनिश्चित करने में आपकी सहायता कर सकते हैं कि आपके डेटाबेस हमेशा आकार में रहें। ClusterControl पहले ही सैकड़ों उद्यमों की मदद कर चुका है - क्या आपका अगला होगा? यह देखने के लिए कि क्या यह आपके डेटाबेस की ज़रूरतों के लिए सही है या नहीं, आज ही ClusterControl का अपना निःशुल्क परीक्षण डाउनलोड करें।