क्या अक्षम्य स्थानिक सूचकांक भ्रष्टाचार सामान्य माना जाता है?


23

मेरे पास एक स्थानिक सूचकांक है जिसके लिए DBCC CHECKDBभ्रष्टाचार रिपोर्ट करता है:

DBCC CHECKDB(MyDB) 
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

स्थानिक सूचकांक, एक्सएमएल इंडेक्स या इंडेक्सेड व्यू 'sys.extended_index_xxx_384000' (ऑब्जेक्ट आईडी xxx) में वे सभी पंक्तियाँ नहीं होती हैं जो व्यू डेफिनेशन उत्पन्न करती हैं। यह आवश्यक रूप से इस डेटाबेस में डेटा के साथ एक अखंडता मुद्दे का प्रतिनिधित्व नहीं करता है।

स्थानिक सूचकांक, XML सूचकांक या अनुक्रमित दृश्य 'sys.extended_index_xxx_384000' (ऑब्जेक्ट आईडी xxx) में वे पंक्तियाँ होती हैं जो दृश्य परिभाषा द्वारा निर्मित नहीं थीं। यह आवश्यक रूप से इस डेटाबेस में डेटा के साथ एक अखंडता मुद्दे का प्रतिनिधित्व नहीं करता है।

CHECKDB को तालिका। Sys.extended_index_xxx_384000 ’(ऑब्जेक्ट आईडी xxx) में 0 आवंटन त्रुटियां और 2 संगतता त्रुटियां मिलीं।

मरम्मत के स्तर का है repair_rebuild

अनुक्रमणिका को छोड़ने और फिर से बनाने से इन भ्रष्टाचार रिपोर्टों को हटाया नहीं जाता है। बिना EXTENDED_LOGICAL_CHECKSलेकिन DATA_PURITYत्रुटि के साथ रिपोर्ट नहीं की गई है।

CHECKTABLEइस तालिका के लिए 45 मिनट लगते हैं , हालांकि इसका सीआई 30 एमबी आकार का है और लगभग 30k पंक्तियाँ हैं। उस तालिका का सभी डेटा बिंदु geographyडेटा है।

क्या यह व्यवहार किसी भी परिस्थिति में अपेक्षित है? यह कहता है "यह जरूरी नहीं कि एक अखंडता का प्रतिनिधित्व करता है"। मुझे क्या करना चाहिए? CHECKDBविफल हो रहा है जो एक समस्या है।

यह स्क्रिप्ट समस्या को पुन: पेश करती है:

CREATE TABLE dbo.Cities(
    ID int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

GO
INSERT dbo.Cities (ID, Position) VALUES (20171, 0xE6100000010C4E2B85402E424A40A07312A518C72A40)
GO
CREATE SPATIAL INDEX IX_Cities_Position ON dbo.Cities
(
    Position
)USING  GEOGRAPHY_AUTO_GRID 
WITH (
CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

यह संस्करण 12.0.4427.24 (SQL Server 2014 SP1 CU3) है।

मैंने स्कीमा और डेटा के साथ तालिका को स्क्रिप्ट किया, ताजा डीबी, निष्पादित करें। वही त्रुटि। CHECKDB में 45min का यह अविश्वसनीय रनटाइम भी है। मैंने SQL Profiler का उपयोग करके CHECKDB क्वेरी योजना पर कब्जा कर लिया। यह एक गुमराह पाश है जाहिर है अत्यधिक रनटाइम के कारण। योजना में तालिका की पंक्तियों की संख्या में द्विघात रनटाइम है! निस्संदेह नेस्टेड स्कैनिंग लूप जुड़ता है।

DBCC निष्पादन योजना

सभी गैर-स्थानिक अनुक्रमित समाशोधन से कुछ भी नहीं बदलता है।

जवाबों:


25

मैं तुरंत इसे 2014 - 12.0.4213.0 पर पुन: पेश नहीं कर सका, लेकिन इसे SQL सर्वर 2016 (CTP3.0) - 13.0.700.242 पर देखें।

2014 की बिल्ड (डीबीसीसी त्रुटियों के साथ) पर योजना निम्नानुसार है।

यहाँ छवि विवरण दर्ज करें

और 2016 में बिल्ड ( DBCC त्रुटियों के साथ रिपोर्ट) इस तरह से।

यहाँ छवि विवरण दर्ज करें

दूसरी योजना में मर्ज एंटी सेमी जॉइन से निकलने वाली एकल पंक्ति है, पहली योजना शून्य पंक्तियाँ हैं।

pk0स्थानिक इंडेक्स में कॉलम से मिलान किए जाने के संबंध में शामिल होने की भविष्यवाणी अलग है ।

यहाँ छवि विवरण दर्ज करें

पहला वाला इसे सही ढंग से टेबल पर रखता है प्राथमिक कुंजी, दूसरा मैप इसे Idटीवीएफ से लौटाए गए कॉलम पर।

SQL सर्वर 2012 इंटर्नल्स बुक के अनुसार यह सेल के हिल्बर्ट नंबर के लिए एक बाइनरी (5) मान है इसलिए यह निश्चित रूप से गलत है (यदि आधार तालिका में एकल पंक्ति की आईडी 20171 के बजाय 1052031049 पर सेट है) अब किसी भी DBCC त्रुटियों को देखें क्योंकि यह इस मूल्य के अनुरूप होता है 0xa03eb4b849)।


2014 पर - 12.0.4213.0 के बाद तालिका को फिर से बनाने के बाद मैं समस्या को पुन: पेश कर सका।

CREATE TABLE dbo.Cities(
    Id int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    Id ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

(नोट से परिवर्तन IDकरने के लिए Id)

मेरा 2014 का उदाहरण केस सेंसिटिव कॉलेशन के साथ स्थापित है। तो ऐसा लगता है कि इससे पहले स्तंभ भ्रम को रोका जा सकता है।

तो मुझे लगता है कि एक संभावित वैकल्पिक हल में स्तंभ का नाम बदलने का हो सकता है Citiesके रूप में CityIdउदाहरण के लिए।

कनेक्ट आइटम (Microsoft बग रिपोर्ट)


4
यह एक शानदार बग है :) पागल लूप जॉइन को भी समझा सकता है क्योंकि वे संभवतः इस उच्चतर कार्डिनैलिटी जॉइन कंडीशन के लिए एक अच्छा विकल्प हो सकते हैं।
boot4life

7
@ boot4life Idभ्रम भी कारण है कि स्कैन की तलाश में क्या होना चाहिए। शानदार कैच, मार्टिन। यह केवल AUTO_GRIDविकल्प को प्रभावित करता है। मैं असंवेदनशील टकराव के साथ 2014 SP1 CU4 पर बग को पुन: पेश कर सकता हूं। SQL सर्वर विस्तारित चेक क्वेरी को गलत तरीके से बनाता है।
पॉल व्हाइट GoFundMonica कहते
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.