คำถามติดแท็ก columnstore

1
ตัวดำเนินการสปูลกระตือรือร้นมีประโยชน์สำหรับการลบนี้จากคอลัมน์ในคลัสเตอร์หรือไม่
ฉันกำลังทดสอบการลบข้อมูลจากดัชนี columnstore แบบคลัสเตอร์ ฉันสังเกตเห็นว่ามีตัวดำเนินการเก็บพักขนาดใหญ่ที่กระตือรือร้นในแผนการดำเนินการ: สิ่งนี้เสร็จสมบูรณ์ด้วยคุณสมบัติดังต่อไปนี้: ลบ 60 ล้านแถว 1.9 GiB TempDB ใช้แล้ว เวลาดำเนินการ 14 นาที แผนอนุกรม 1 rebind บนสปูล ค่าใช้จ่ายโดยประมาณสำหรับการสแกน: 364.821 หากฉันหลอกผู้ประมาณค่าให้ดูถูกดูแคลนฉันจะได้รับแผนการที่เร็วกว่าและหลีกเลี่ยงการใช้ TempDB: ค่าใช้จ่ายโดยประมาณของการสแกน: 56.901 (นี่เป็นแผนโดยประมาณ แต่ตัวเลขในความคิดเห็นถูกต้อง) ที่น่าสนใจที่เก็บพักหายไปอีกครั้งถ้าฉันล้างร้านค้าเดลต้าโดยเรียกใช้ต่อไปนี้: ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON); สปูลจะปรากฏขึ้นเฉพาะเมื่อมีจำนวนหน้ามากกว่าเกณฑ์ในร้านเดลต้า หากต้องการตรวจสอบขนาดของร้านค้าเดลต้าฉันกำลังเรียกใช้คิวรีต่อไปนี้เพื่อตรวจสอบหน้าในแถวสำหรับตาราง: SELECT SUM([in_row_used_page_count]) AS in_row_used_pages, SUM(in_row_data_page_count) AS in_row_data_pages FROM sys.[dm_db_partition_stats] as …

1
สิ่งใดที่ SQL Server 2014 สามารถใช้งานได้ในโหมดแบตช์
เมื่อมีการใช้ดัชนี columnstore ในแบบสอบถาม SQL Server จะสามารถใช้โหมดแบตช์ เอกสารมีความบางในสิ่งที่สามารถทำงานในโหมดแบทช์และสิ่งที่ไม่สามารถทำได้ โปรดดูแผนแบบสอบถาม (สร้างแรงบันดาลใจ) ต่อไปนี้ซึ่งมีสิ่งน่าแปลกใจจำนวนหนึ่งที่ดำเนินการในโหมดแบทช์ (สีเขียว) (นี่เป็นแผนโดยประมาณฉันใช้แผนจริงเพื่อตรวจสอบว่าโหมดการปฏิบัติจริงเป็นแบทช์จริง ๆ ) โปรดทราบว่าเฉพาะด้านบิลด์ของ T1 เท่านั้นที่ใช้ดัชนี columnstore โพรบอินพุตทั้งหมด (T2 และ T3) เป็นแถว ข้อมูลของพวกเขาดูเหมือนจะเปลี่ยนเป็นโหมดแบทช์ ฉันคิดเสมอว่ามีการใช้งานโหมดแบตช์สำหรับกระแสข้อมูลที่ไหลผ่านด้านโพรบเท่านั้น ดูเหมือนว่าข้อมูลสามารถเปลี่ยนเป็นโหมดแบตช์แม้ว่าจะไม่ได้มาจากดัชนีของคอลัมน์ นั่นทำให้เกิดคำถาม: ทำไม SQL Server ถึงไม่ใช้โหมดแบตช์สำหรับการสืบค้นแบบแถวเรียงเท่านั้นเช่นกัน อาจเป็นประโยชน์สำหรับบางคน การใช้ดัชนี columnstore เป็นข้อกำหนดอย่างเป็นทางการที่จำเป็นเพื่อให้ SQL Server พิจารณาโหมดแบตช์หรือไม่ เราอาจจะเพิ่มตารางดัมมี่แถวศูนย์ด้วยดัชนีแบบคอลัมน์เพื่อกระตุ้นโหมดแบทช์และรับประสิทธิภาพที่เพิ่มขึ้นได้หรือไม่? สิ่งที่สามารถทำงานในโหมดแบตช์ในฐานะของ SQL Server 2014 ได้อย่างแน่นอน

3
เหตุใดจึงใช้เวลาสูงสุด 30 วินาทีในการสร้างกลุ่มแถว CCI แบบง่าย
ฉันกำลังทำงานเกี่ยวกับการสาธิต CCIs เมื่อฉันสังเกตเห็นว่าเม็ดมีดบางรุ่นของฉันใช้เวลานานกว่าที่คาดหมาย คำจำกัดความของตารางที่จะทำซ้ำ: DROP TABLE IF EXISTS dbo.STG_1048576; CREATE TABLE dbo.STG_1048576 (ID BIGINT NOT NULL); INSERT INTO dbo.STG_1048576 SELECT TOP (1048576) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN FROM master..spt_values t1 CROSS JOIN master..spt_values t2; DROP TABLE IF EXISTS dbo.CCI_BIGINT; CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI …

1
อะไรคือกายวิภาคของดัชนีคอลัมน์
หนึ่งในคุณสมบัติใหม่ในชื่อรหัส SQL Server 2012 Denaliคือดัชนี Columnstore ฉันรู้ดีเกี่ยวกับดัชนีการจัดเก็บแถวเก่าทั่วไปเช่นโครงสร้าง b-tree ความแตกต่างในการจัดเก็บระหว่างระดับลีฟและเพจ b-tree ผลกระทบของฟิลด์ที่รวมไว้การปรับให้เหมาะสมเพื่อใช้งานลำดับของคีย์เป็นต้น ฉันมีปัญหาในการรับข้อมูลที่ดีเกี่ยวกับinternalsของดัชนี columnstore มันเป็นโครงสร้างอย่างไร มีต้นไม้ b หรือไม่? มีโครงสร้างอื่น ๆ ในสถานที่? มีการจัดระเบียบข้อมูลอย่างไร ตัวดำเนินการเฉพาะประเภทใดที่เหมาะสมที่สุดที่จะใช้ มีรูปแบบการต่อต้านแบบอื่นที่ควรหลีกเลี่ยงเมื่อใช้งาน? สิ่งที่ฉันสามารถค้นหาเกี่ยวกับพวกเขานั้นเป็นสิ่งที่ตรงกันข้ามกับดัชนี "ปกติ" คือไม่มีการเรียงลำดับของคีย์ไม่มีเขตข้อมูลที่รวมไม่รวมอยู่เท่านั้น ข้อมูลเชิงลึกใด ๆ ที่ชื่นชม

3
ดัชนีคอลัมน์แบบคลัสเตอร์และคีย์ต่างประเทศ
ฉันกำลังปรับแต่งคลังข้อมูลโดยใช้ดัชนี ฉันค่อนข้างใหม่กับ SQL Server 2014 Microsoft อธิบายต่อไปนี้: "เราดูดัชนี columnstore ของคลัสเตอร์เป็นมาตรฐานสำหรับการจัดเก็บตารางข้อมูลคลังข้อมูลขนาดใหญ่และคาดว่าจะใช้ในสถานการณ์จำลองคลังข้อมูลส่วนใหญ่เนื่องจากดัชนี columnstore ของคลัสเตอร์สามารถอัปเดตได้เวิร์กโหลดของคุณสามารถทำการแทรกจำนวนมาก และลบการทำงาน " http://msdn.microsoft.com/en-us/library/gg492088.aspx อย่างไรก็ตามหากคุณอ่านเพิ่มเติมในเอกสารคุณจะพบภายใต้ข้อ จำกัด และข้อ จำกัด : "ไม่สามารถมีข้อ จำกัด ที่ไม่ซ้ำกันข้อ จำกัด ของคีย์หลักหรือข้อ จำกัด ของ Foreign Key" ทำให้ฉันงงมาก! เป็นวิธีปฏิบัติที่ดี (ไม่บังคับ) ให้มีคีย์ต่างประเทศในคลังข้อมูลด้วยเหตุผลหลายประการ (ความสมบูรณ์ของข้อมูลความสัมพันธ์ที่มองเห็นได้สำหรับเลเยอร์ความหมาย ... ) ดังนั้นไมโครซอฟท์จึงสนับสนุนการจัดทำดัชนีคอลัมน์แบบจัดกลุ่มสำหรับสถานการณ์คลังข้อมูล แต่มันไม่สามารถจัดการกับความสัมพันธ์ที่สำคัญกับต่างประเทศได้! ฉันถูกต้องหรือไม่ วิธีอื่นใดที่คุณจะแนะนำ ในอดีตที่ผ่านมาฉันใช้ดัชนี columnstore ที่ไม่ใช่คลัสเตอร์ในสถานการณ์ data warehouse โดยมีการปล่อยและสร้างใหม่สำหรับการโหลดข้อมูล อย่างไรก็ตาม SQL Server 2014 …

1
ที่เก็บข้อมูลดัชนีแบบไม่คลัสเตอร์บนเสาหลักแบบคลัสเตอร์
ใน SQL Server ดัชนี nonclustered ที่ไม่ซ้ำกันในตารางrowstoreประกอบด้วยที่คั่นหน้าของวัตถุฐาน(RID หรือคีย์การทำคลัสเตอร์) ที่ทุกระดับของโครงสร้างดัชนีที่ไม่เป็นคลัสเตอร์ บุ๊กมาร์กจะถูกจัดเก็บเป็นส่วนหนึ่งของคีย์ดัชนีที่ไม่เป็นคลัสเตอร์ในทุกระดับดัชนี ในทางตรงกันข้ามถ้าดัชนี nonclustered เป็นที่ไม่ซ้ำกันที่คั่นเป็นปัจจุบันเท่านั้นที่ใบระดับของดัชนี - ไม่ได้เป็นส่วนหนึ่งของคีย์ (บุ๊กเป็นปัจจุบันเป็นหนึ่งหรือคอลัมน์รวมมากขึ้นในผล) ใน SQL Server 2016 เป็นไปได้ที่จะสร้างดัชนี b-tree แบบ nonclustered บนตารางเชิงคอลัมน์ (อันที่มีดัชนี columnstore แบบคลัสเตอร์) อะไรคือ 'บุ๊คมาร์ค' ที่ใช้สำหรับดัชนี b-tree แบบไม่คลัสเตอร์บนตาราง columnstore แบบคลัสเตอร์ ความแตกต่างระหว่างดัชนีที่ไม่ซ้ำแบบไม่เจาะจงและไม่ซ้ำแบบคลัสเตอร์ที่อธิบายไว้ข้างต้นยังคงมีผลอยู่หรือไม่?

2
ดัชนี Columnstore ในกลุ่มไฟล์ read_only ป้องกัน CheckDB
จะปรากฏการตั้งค่ากลุ่มไฟล์เพื่อread_onlyป้องกันdbcc checkdbฐานข้อมูลทั้งหมดหากกลุ่มไฟล์มีดัชนี columnstore เมื่อพยายามเรียกใช้checkdbหรือcheckfilegroup( สำหรับกลุ่มไฟล์ใด ๆในฐานข้อมูลรวมถึงการอ่านเขียนที่สองและ[PRIMARY] ) ข้อผิดพลาดด้านล่างจะถูกส่งกลับ ... Msg 8921, Level 16, State 1, Line 24 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. มีวิธีการที่รองรับการมีข้อมูล columnstore ในกลุ่มไฟล์แบบอ่านอย่างเดียวหรือไม่? หรือฉันถูกกีดกันจากการตรวจสอบความสมบูรณ์ในสถานการณ์นี้? Repro create database check_fg_ro go use …

1
วิธีการใช้ประโยชน์จากโหมดแบทช์ด้วย UNPIVOT (การเข้าร่วมแบบวนซ้ำ)
ฉันมีแบบสอบถามของแบบฟอร์มต่อไปนี้: SELECT ... FROM ColumnstoreTable cs CROSS APPLY ( SELECT * FROM (VALUES ('A', cs.DataA) , ('B', cs.DataB) , ('C', cs.DataC) ) x(Col0, Col1) ) someValues การดำเนินการนี้จะใช้ทุกแถวจากแบบสอบถามย่อยที่สำรองไว้ในคอลัมน์ ( ColumnstoreTable) และคูณแถวเหล่านั้น UNPIVOTนี้เป็นหลัก แบบสอบถามจริงมีขนาดใหญ่กว่านี้ ส่วนนี้ของแบบสอบถามจะดึงข้อมูลไปยังการประมวลผลอื่น ๆ ปัญหาที่นี่คือสิ่งนี้CROSS APPLYถูกนำไปใช้เป็นการเข้าร่วมแบบวนรอบซึ่งเป็นตัวเลือกที่สมเหตุสมผล น่าเสียดายที่การรวมลูปไม่สนับสนุนโหมดแบทช์ ส่วนหนึ่งของแบบสอบถามนี้มีประสิทธิภาพที่สำคัญมากและฉันสงสัยว่าการรันในโหมดแบตช์อาจเป็นประโยชน์อย่างมากต่อประสิทธิภาพ ฉันจะเขียนแบบสอบถามนี้ใหม่เพื่อที่ฉันจะไม่เปลี่ยนจากโหมดแบทช์ได้อย่างไร ฉันลองใช้ตารางชั่วคราวแทนVALUESแต่นั่นไม่ได้เปลี่ยนความจริงที่ว่าไม่มีเงื่อนไขการเข้าร่วมที่เท่าเทียมกันในการเข้าร่วมแฮช

4
ลำดับของคอลัมน์ในดัชนี columnstore สำคัญหรือไม่
ฉันมีตารางที่มี ~ 200 ล้านแถวและอีก 15 คอลัมน์ในนั้น ฉันวางแผนที่จะสร้างCOLUMNSTOREดัชนีบนโต๊ะของฉัน จะมีการเปลี่ยนแปลงใด ๆ เกี่ยวกับประสิทธิภาพขึ้นอยู่กับลำดับของคอลัมน์ที่ฉันใช้ในดัชนี columnstore หรือไม่ ถ้าใช่ตรรกะอะไรที่อยู่เบื้องหลัง

1
เหตุใดหน้าต่างโหมดแบตช์จึงรวมการคำนวณทางคณิตศาสตร์มากเกินไป
แบบสอบถามต่อไปนี้ดำเนินการแบบหน้าต่างSUMเหนือตาราง columnstore ด้วย1500 total rowsซึ่งแต่ละอันมีค่า 0 หรือ 1 และมัน overflows INTชนิดข้อมูล ทำไมสิ่งนี้จึงเกิดขึ้น SELECT a, p, s, v, m, n, SUM(CASE WHEN n IS NULL THEN 0 ELSE 1 END) OVER (PARTITION BY s, v, a ORDER BY p) AS lastNonNullPartition FROM ( SELECT a, p, s, v, m, n, RANK() …

3
เงื่อนไขการกรองไม่ถูกต้องนำไปใช้กับดัชนีคอลัมน์ที่เก็บแบบคลัสเตอร์
จากตัวอย่างด้านล่างเพรดิเคตจะเหมือนกันอย่างไรก็ตามคำสั่ง top (ถูกต้อง) ส่งคืน 0 แถวคำสั่งด้านล่างส่งคืน 1 - แม้ว่าเพรดิเคตจะไม่ตรงกัน: declare @barcode nchar(22)=N'RECB012ZUKI449M1VBJZ' declare @tableId int = null declare @total decimal(10, 2) = 5.17 SELECT 1 FROM [dbo].[transaction] WITH (INDEX([IX_Transaction_TransactionID_PaymentStatus_DeviceID_DateTime_All])) WHERE Barcode = @barcode AND StatusID = 1 AND TableID = @tableID AND @total <= Total SELECT 1 FROM [dbo].[transaction] WHERE …

2
วิธีการป้องกัน Deadlocks ของคอลัมน์ที่แบ่งพาร์ติชันบน SELECT
ฉันมีตารางดัชนีคอลัมน์หลัก (CCI) สามตารางใน SQL Server 2016 CCI ทั้งหมดเหล่านี้อยู่ในรูปแบบการแบ่งพาร์ติชันเดียวกันโดยยึดตาม ID ผู้เช่า เมื่อเร็ว ๆ นี้และไม่สอดคล้องกันฉันได้รับการหยุดชะงักในงบเลือกง่าย ๆ จากการเข้าร่วมตารางเหล่านี้ ตัวอย่างแบบสอบถามที่ deadlocks: SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 ข้อความผิดพลาด: ทรานแซคชัน …

2
คอลัมน์รหัสประจำตัวในดัชนี columnstore
ฉันมีตาราง IMO ที่มีขนาดใหญ่มาก (~ 137 ล้านแถว) ที่มีข้อมูลซ้ำจำนวนมากNULLคอลัมน์จำนวนมากและเช่นนั้น ฉันกำลังพิจารณาการสำรวจนี้โดยใช้ตารางที่มีCOLUMNSTORE INDEXและฉันมีIDENTITYคอลัมน์ในตารางเดิมซึ่งเป็นคอลัมน์เดียวของฉันที่ทุกแถวไม่ซ้ำกัน ฉันควรปล่อยคอลัมน์นี้ออกหรือรวมไว้หรือไม่ ฉันได้อ่านแล้วว่าคุณต้องการรวมแถวทั้งหมดของตารางลงในCOLUMNSTORE INDEXแต่ฉันได้อ่านด้วยว่าผู้สมัครที่ดีที่สุดคือคอลัมน์ที่มีแถวที่ไม่ซ้ำจำนวนมาก นี่เป็นเพียงผู้สมัครที่ไม่ดีสำหรับCOLUMNSTORE INDEX? ฉันใช้ SQL Server 2012 ดังนั้นจึงเป็นคอลัมน์ที่ไม่ใช่คลัสเตอร์ ฉันแค่สำรวจวิธีที่เป็นไปได้ที่ดีกว่าในการจัดเก็บข้อมูลนี้ การปรับปรุงไม่มีอยู่แม้ว่าจะมีการเพิ่มแถวใหม่เป็นระยะ ๆ ผ่านกระบวนการ ELT ดังนั้นฉันคาดว่าจะมีงานบางอย่างเกิดขึ้นที่นั่น ผู้ใช้บางคนขุดข้อมูลนี้และสร้างรายงานจำนวนมากสแกนแถวจำนวนมากนำเซิร์ฟเวอร์ไปสู่การรวบรวมข้อมูลในบางครั้งซึ่งบังคับให้เราถ่ายสำเนาทุกวันไปยังเซิร์ฟเวอร์รอง
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.