MSM 666 जब 80M- पंक्ति अनुक्रमित तालिका पर एक सम्मिलित क्वेरी चलाते हैं

Question

अजीब बात है, मेरी संग्रहीत प्रक्रिया कुछ इनपुट डेटा के लिए Msg 666 प्राप्त करने के लिए शुरू हुई।

निम्न प्रक्रिया के साथ तालिका में पंक्ति सम्मिलित करने का प्रयास करने पर अंतिम चरण में संग्रहीत प्रक्रिया विफल हो जाती है:

Columns:
A_Id: PK, int
B_Id: PK, FK, int
C_Id: PK, FK, int
D_Id: PK, smallint 

यह अनिवार्य रूप से एक तालिका है जो सभी संदर्भित संस्थाओं को एक साथ जोड़ती है।

Indexes:
IX_TableName_D_id - Clustered index on D_id column
PK_TableName - Unique non-clustered index on all columns (A_Id, B_Id, C_Id, D_Id)

दोनों अनुक्रमितों के लिए विखंडन कम है (<25%)। हालांकि PK_TableName विखंडन जल्दी बढ़ता है, क्योंकि मेज पर ऑपरेशन की मात्रा काफी तीव्र है।

तालिका का आकार:

Row count: ~80,000,000 rows

इसलिए, जब मैं D_Id के कुछ के लिए veeery सरल क्वेरी चलाने की कोशिश करता हूं, तो मुझे निम्न संदेश मिलता है:

Msg 666. एक डुप्लिकेट समूह के लिए अधिकतम सिस्टम-जनरेट किया गया अनन्य मान विभाजन ID 422223771074560 के साथ अनुक्रमणिका से अधिक हो गया था। अनुक्रमणिका को ड्रोप करना और पुनः बनाना इसका समाधान हो सकता है; अन्यथा, एक और क्लस्टरिंग कुंजी का उपयोग करें।

क्वेरी का उदाहरण:

INSERT INTO TableName
(A_Id,B_Id,C_Id,D_id)
VALUES (1,1,1,14)

उदाहरण के लिए, जब मैंने D_Id को कुछ मानों के लिए सेट किया है - यह विफल रहता है, उदाहरण के लिए '14'। यदि मैंने D_ID को अन्य मानों (1,2,3, ... 13, 15,16, ...) पर सेट किया है, तो क्वेरी ठीक चलती है।

मुझे संदेह है कि वास्तव में कुछ बुरा है जो अनुक्रमित के साथ चल रहा है ... लेकिन मैं इस के नीचे नहीं जा सकता ... :( यह विफल क्यों होता है?

Answer 1

रेमस द्वारा बताई गई कम चयनात्मकता समस्या उस आकार की मेज पर समस्या का कारण बनने के लिए पर्याप्त नहीं है।

यूनीकफायर की शुरुआत होती है 1और 2,147,483,646वास्तव में रेंज को ओवरफ्लो करने से पहले ऊपर जा सकती है ।

समस्या को देखने के लिए बार-बार डिलीट और आवेषण के सही पैटर्न की भी आवश्यकता होती है।

CREATE TABLE T
(
X SMALLINT,
Y INT IDENTITY PRIMARY KEY NONCLUSTERED
)

CREATE CLUSTERED INDEX IX ON T(X)

INSERT INTO T VALUES (1),(1),(1),(2),(2)

देता है

+---+---+-------------+
| X | Y | Uniqueifier |
+---+---+-------------+
| 1 | 1 |             |
| 1 | 2 |           1 |
| 1 | 3 |           2 |
| 2 | 4 |             |
| 2 | 5 |           1 |
+---+---+-------------+

फिर दौड़ रहा है

DELETE FROM T 
WHERE Y IN (2,3)

INSERT INTO T VALUES (1),(1)

देता है

+---+---+-------------+
| X | Y | Uniqueifier |
+---+---+-------------+
| 1 | 1 |             |
| 1 | 6 |           3 |
| 1 | 7 |           4 |
| 2 | 4 |             |
| 2 | 5 |           1 |
+---+---+-------------+

उस मामले में यह दिखाते हुए कि यूनीकफायर ने हटाई गई पंक्तियों से मूल्यों का पुन: उपयोग नहीं किया है।

हालाँकि तब चल रहा है

DELETE FROM T 
WHERE Y IN (6,7)
WAITFOR DELAY '00:00:10'
INSERT INTO T VALUES (1),(1)

देता है

+---+---+-------------+
| X | Y | Uniqueifier |
+---+---+-------------+
| 1 | 1 |             |
| 1 | 8 |           1 |
| 1 | 9 |           2 |
| 2 | 4 |             |
| 2 | 5 |           1 |
+---+---+-------------+

यह दिखाते हुए कि डुप्लिकेट को हटाने के बाद उच्चतम अद्वितीय मान के साथ उच्च जल चिह्न रीसेट किया जा सकता है। देरी भूत रिकॉर्ड सफाई प्रक्रिया को चलाने के लिए अनुमति देने के लिए किया गया था।

क्योंकि 2 बिलियन डुप्लिकेट सम्मिलित करने के लिए जीवन बहुत छोटा है, तब मैं DBCC WRITEPAGEमैन्युअल रूप से उच्चतम uniqueifier2,147,483,644 को समायोजित करता था

मैं फिर भागा

INSERT INTO T VALUES (1)

कई बार। यह दो बार सफल रहा और तीसरे प्रयास में 666 त्रुटि के साथ विफल रहा।

यह वास्तव में मेरे द्वारा ग्रहण किए जाने की तुलना में एक कम था। मतलब यह है कि डाला गया उच्चतम योजक 2,147,483,646 था जिसका अधिकतम अंतर 2,147,483,647 था।

Comments

सूचना के प्रयोजनों के लिए, क्या आप जांच कर सकते हैं TRUNCATE TABLEकि क्या यूनिकफायर रीसेट करता है?

— जॉन सिगेल

@JonSeigel - हाँ, लगता है। दौड़ने के INSERT INTO T VALUES (1),(1),(1),(2),(2);TRUNCATE TABLE T;INSERT INTO T VALUES (1),(1),(1),(2),(2)बाद सबसे ज्यादा अनोखा प्रदर्शन 2 मुझे लगता है कि यह उस उच्चतम योजक को देखता है जो पहले से ही उस कुंजी (भूत रिकॉर्ड सहित) के लिए मौजूद है

— मार्टिन स्मिथ