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

สถิติสำหรับการปรับให้เหมาะสมของแบบสอบถามเป็นวัตถุที่มีข้อมูลสถิติเกี่ยวกับการกระจายของค่าในหนึ่งคอลัมน์ขึ้นไปของตารางหรือมุมมองที่จัดทำดัชนี

1
การประเมินภาวะเชิงหัวใจนอกฮิสโตแกรม
ติดตั้ง ฉันมีปัญหาในการทำความเข้าใจการประเมินความสำคัญเชิงหัวใจ นี่คือการตั้งค่าการทดสอบของฉัน: เวอร์ชัน 2010 ของฐานข้อมูล Stack Overflow SQL Server 2017 CU15 + GDR (KB4505225) - 14.0.3192.2 CE ใหม่ (ระดับความเข้ากันได้ 140) ฉันมี proc นี้: USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO ไม่มีดัชนีหรือสถิติที่ไม่ใช่คลัสเตอร์ในdbo.Postsตาราง …

1
การปรับปรุงดัชนีที่ไม่ซ้ำกันและเคาน์เตอร์แก้ไขแถวสถิติ
รับตารางต่อไปนี้ดัชนีคลัสเตอร์ที่ไม่ซ้ำกันและสถิติ: CREATE TABLE dbo.Banana ( pk integer NOT NULL, c1 char(1) NOT NULL, c2 char(1) NOT NULL ); CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk); CREATE STATISTICS c1 ON dbo.Banana (c1); CREATE STATISTICS c2 ON dbo.Banana (c2); INSERT dbo.Banana (pk, c1, c2) VALUES (1, 'A', 'W'), (2, 'B', 'X'), …

1
SQL Server สร้างแผนใหม่ในแต่ละวัน
เรามีปัญหานี้ในสภาพแวดล้อมการผลิตของเรา Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - รุ่นองค์กร (64 บิต) บน Windows NT 6.1 (รุ่น 7601: Service Pack 1) SQL Server กำลังวางแผนปฏิบัติการเกือบทั้งหมด (เกือบ 100%) และสร้างใหม่ทุกวันข้ามคืน (จาก 11:00 PM ถึง 8:00 AM) สิ่งนี้เกิดขึ้นเมื่อ 'สถิติการอัปเดตอัตโนมัติ' อยู่ในสถานะปิดใช้งาน เราได้เปิด 'สถิติการอัปเดตอัตโนมัติ' ในช่วง 2-3 สัปดาห์ที่ผ่านมา แต่มันก็ยังคงเกิดขึ้น เราไม่รู้จริง ๆ ว่าอะไรเป็นต้นเหตุของแผนยุคใหม่นี้ แต่เรามั่นใจว่าเราจะไม่ทำด้วยตนเอง สิ่งเดียวที่เกิดขึ้นจริงกับช่วงเวลาของแผนที่ถูกสร้างใหม่คืองานบำรุงรักษาฐานข้อมูลที่เรามี: ดัชนีรายวันปรับโครงสร้างองค์กรใหม่ …

2
stats_column_id และ index_column_id ไม่อัพเดตด้วยลำดับฟิสิคัลของดัชนีคลัสเตอร์ที่มีการเปลี่ยนแปลง
ยกเว้นว่าฉันเข้าใจผิดวัตถุประสงค์ของคอลัมน์รหัสต่อไปนี้บ่งชี้ว่าการเปลี่ยนแปลงโครงสร้างของดัชนีคลัสเตอร์จะไม่เปลี่ยนตำแหน่งอันดับ ( stats_column_id) ของคอลัมน์ในsys.stats_columns DMV (ทดสอบใน AdventureWorks2014, AdventureWorks2008R2) select i.name, c.name, ic.column_id, ic.index_column_id from sys.indexes i join sys.index_columns ic on i.object_id = ic.object_id and i.index_id = ic.index_id join sys.columns c on i.object_id = c.object_id and ic.column_id = c.column_id where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID' order by ic.key_ordinal; select sh.name,s.name, c.name, c.column_id, sc.column_id, …

3
การอัพเดตสถิติแบบขนาน
ใน SQL Server 2008 หรือใหม่กว่าUPDATE STATISTICS WITH FULLSCANการดำเนินการแบบเธรดเดียวหรือสามารถใช้การขนานได้หรือไม่ วิธีการเกี่ยวกับสถิติการปรับปรุงด้วยการสุ่มตัวอย่างเริ่มต้น - มันสามารถใช้ขนานกันได้อย่างไร ฉันไม่เห็นตัวเลือกที่ระบุMAXDOPด้วยสถิติการอัปเดต

1
เหตุใด SQL Server จึงปฏิเสธที่จะอัปเดตสถิติเหล่านี้เป็นอย่างอื่นนอกจากสแกนแบบเต็ม
ฉันสังเกตเห็นการดำเนินการสถิติการอัปเดตอัตโนมัติ (20 นาที +) ที่ค่อนข้างใช้เวลานานในการสร้างคลังข้อมูลรายวัน ตารางที่เกี่ยวข้องคือ CREATE TABLE [dbo].[factWebAnalytics]( [WebAnalyticsId] [bigint] IDENTITY(1,1) NOT NULL, [MarketKey] [int] NOT NULL CONSTRAINT [DF_factWebAnalytics_MarketKey] DEFAULT ((-1)), /*Other columns removed*/ CONSTRAINT [PK_factWebAnalytics] PRIMARY KEY CLUSTERED ( [MarketKey] ASC, [WebAnalyticsId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = …


1
สถิติ. ฮิสโทแกรมหลายสีเป็นไปได้หรือไม่
ฉันกำลังคิดถึงสถานการณ์ที่ฉันมีสองคอลัมน์ที่มีความหนาแน่นสูง แต่คอลัมน์เหล่านี้ไม่ได้เป็นอิสระ คำนิยาม นี่คือคำจำกัดความของตารางที่ฉันสร้างขึ้นเพื่อวัตถุประสงค์ในการทดสอบ CREATE TABLE [dbo].[StatsTest]( [col1] [int] NOT NULL, --can take values 1 and 2 only [col2] [int] NOT NULL, --can take integer values from 1 to 4 only [col3] [int] NOT NULL, --integer. it has not relevance just to ensure that each row is different [col4] AS …

1
สถิติเป็นข้อมูลล่าสุด แต่การประมาณการไม่ถูกต้อง
เมื่อฉันฉันจะdbcc show_statistics ('Reports_Documents', PK_Reports_Documents)ได้รับผลลัพธ์ต่อไปนี้สำหรับรหัสรายงาน 18698: สำหรับการค้นหานี้: SELECT * FROM Reports_Documents WHERE ReportID = 18698 option (recompile) ฉันได้รับแผนคิวรีที่ทำให้ดัชนีเป็นกลุ่มค้นหาPK_Reports_Documentsตามที่คาดไว้ แต่สิ่งที่ทำให้ฉันยุ่งเหยิงคือค่าที่ไม่ถูกต้องสำหรับจำนวนแถวโดยประมาณ: ตามนี้ : เมื่อแบบสอบถามตัวอย่างค่า WHERE อนุประโยคเท่ากับค่าฮิสโตแกรม RANGE_HI_KEY ค่า SQL Server จะใช้คอลัมน์ EQ_ROWS ในฮิสโตแกรมเพื่อกำหนดจำนวนแถวที่เท่ากับ นี่เป็นวิธีที่ฉันคาดหวังไว้ว่าจะเป็นอย่างไรก็ตามในชีวิตจริงดูเหมือนจะไม่เป็นเช่นนั้น ฉันยังลองRANGE_HI_KEYค่าอื่น ๆที่มีอยู่ในฮิสโตแกรมที่จัดทำโดยshow_statisticsและประสบการณ์เดียวกัน ปัญหานี้ในกรณีของฉันดูเหมือนว่าจะทำให้แบบสอบถามบางอย่างใช้แผนการดำเนินการที่ไม่เหมาะสมมากทำให้เวลาดำเนินการไม่กี่นาทีในขณะที่ฉันสามารถเรียกใช้ใน 1 วินาทีพร้อมคำใบ้แบบสอบถาม สรุป: มีคนอธิบายได้ไหมว่าทำไมEQ_ROWSไม่ใช้ฮิสโตแกรมมาคำนวณหาจำนวนแถวและการประมาณการที่ไม่ถูกต้องมาจากไหน ข้อมูลอีกเล็กน้อย (อาจมีประโยชน์): เปิดใช้งานการสร้างสถิติอัตโนมัติและสถิติทั้งหมดเป็นข้อมูลล่าสุด ตารางที่สอบถามมีประมาณ 80 ล้านแถว PK_Reports_Documentsเป็นการรวมกันของ PK ประกอบด้วยReportID INTและDocumentID CHAR(8) ดูเหมือนว่าแบบสอบถามจะโหลดวัตถุสถิติที่แตกต่างกันทั้งหมด …

1
ฉันควรปิดการใช้งาน "สถิติการอัพเดทอัตโนมัติ" ในสถานการณ์จำลองคลังข้อมูลหรือไม่
ฉันมีคลังข้อมูล 200 GB ใน SQL Server ฉันประสบกับการดำเนินการช้ามากสำหรับบางข้อความค้นหา ตัวอย่างเช่น 12 ชั่วโมงเพื่อให้ง่ายแบบสอบถามกับdeleteinner join หลังจากทำการวิจัยด้วยแผนการดำเนินการฉันได้อัปเดตสถิติของตาราง 2 ตารางที่เกี่ยวข้องในแบบสอบถามโดยใช้WITH FULLSCANตัวเลือก ตอนนี้แบบสอบถามดำเนินการในเวลาน้อยกว่าหนึ่งวินาทีดังนั้นจึงปรากฏว่าสถิติไม่ทันสมัย ฉันกำลังพิจารณาปิดใช้งานauto update statisticsฐานข้อมูลและทำงานUPDATE STATISTICSด้วยตนเองหลังจากโหลดคลังข้อมูลแล้ว คลังข้อมูลจะถูกโหลดเพิ่มขึ้นจากระบบ ERP ต้นทางทุกวันในเวลากลางคืน ฉันถูกต้องในการสมมติว่าauto update statisticsในสถานการณ์คลังข้อมูลไม่ได้มีประโยชน์จริง ๆ ? จะเป็นการดีกว่าหรือที่จะอัปเดตสถิติด้วยตนเองหลังจากโหลดข้อมูลแล้ว

1
ขนาดตัวอย่างเริ่มต้นของสถิติใน SQL Server คืออะไร
จากMSDN : เมื่อไม่มีการ(SAMPLE, FULLSCAN, RESAMPLE)ระบุตัวเลือกตัวอย่างเครื่องมือเพิ่มประสิทธิภาพการสืบค้นจะสุ่มตัวอย่างข้อมูลและคำนวณขนาดตัวอย่างเป็นค่าเริ่มต้น จะระบุขนาดตัวอย่างเริ่มต้นของสถิติได้อย่างไร ฉันผ่าน MSDN แต่ไม่พบสูตรหรือวิธีการใด ๆ ในการระบุขนาดตัวอย่างเริ่มต้น ทุกที่มีเพียงสูตรที่แสดงเพื่อทริกเกอร์การอัปเดตสถิติอัตโนมัติ ตัวชี้ใด ๆ จะเป็นประโยชน์

1
เหตุใดดัชนีของฉันจึงสามารถค้นหาประมาณจำนวนแถวที่ถูกต้องและตัวดำเนินการเรียงลำดับไม่ได้
ฉันมีแบบสอบถามที่ใช้ฟังก์ชันในเพรดิเคตบางอย่างเช่นนี้: commentType = 'EL' AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0) ฉันมีดัชนีตัวกรองใน commentType ที่มีแถว 40K และเมื่อฉันเรียกใช้แบบสอบถามจำนวนแถวโดยประมาณสำหรับดัชนี Seek นั้นแม่นยำมาก (ประมาณ 11K) แต่สำหรับขั้นตอนต่อไป (ตัวดำเนินการเรียงลำดับ) จะไม่สนใจสถิติและ เพียงประมาณจำนวนแถวทั้งหมดในดัชนีที่กรอง ทำไมสิ่งนี้จึงเกิดขึ้น ฉันรู้พื้นฐานเกี่ยวกับการsargabilityและฉันทดสอบเพียงเพื่อความมีสติแทน dateadd ตามวันที่จริง (2014-01-01) และ voila ... การเรียงลำดับเริ่มเดาจำนวนแถวอย่างถูกต้อง ... เหตุใดสิ่งนี้จึงเกิดขึ้นและฉันจะแก้ไขได้อย่างไร ฉันไม่สามารถผ่านวันที่แน่นอน ...

2
ทำความเข้าใจเกี่ยวกับสถิติแผนการดำเนินการและ 'ปัญหาสำคัญน้อยไปมาก'
ฉันพยายามที่จะเข้าใจ (แนวคิด) ความสัมพันธ์ระหว่างสถิติแผนการดำเนินการการดำเนินการตามขั้นตอนที่เก็บไว้ ฉันถูกต้องหรือไม่ในการบอกว่าสถิติจะถูกใช้เมื่อสร้างแผนการดำเนินการสำหรับขั้นตอนการจัดเก็บเท่านั้นและไม่ได้ใช้ในบริบทการดำเนินการจริง กล่าวอีกนัยหนึ่งหากเป็นจริงเมื่อมีการสร้างแผน (และสมมติว่ามีการใช้ซ้ำอย่างถูกต้อง) สถิติ "ทันสมัย" มีความสำคัญเพียงใด ฉันได้รับแรงบันดาลใจเป็นพิเศษจากบทความที่ฉันอ่าน ( สถิติการประมาณแถวและคอลัมน์วันขึ้น ) ซึ่งอธิบายสถานการณ์ที่คล้ายกับที่ฉันเผชิญทุกวันกับฐานข้อมูลลูกค้าของเราหลายแห่ง เรามีคอลัมน์วันที่ / เวลาจากน้อยไปหามากในหนึ่งในตารางที่ใหญ่ที่สุดของเราที่เราทำการสืบค้นเป็นประจำโดยใช้ขั้นตอนการจัดเก็บเฉพาะ คุณจะป้องกันแผนการดำเนินการไม่ให้เพิ่มขึ้นได้อย่างไรเมื่อคุณเพิ่มหนึ่งแสนแถวต่อวัน? หากเรากำลังอัปเดตสถิติบ่อยครั้งเพื่อต่อสู้กับปัญหานี้มันจะสมเหตุสมผลหรือไม่ที่จะใช้คำแนะนำ OPTION (RECOMPILE) ในการสืบค้นของโพรซีเดอร์นี้ คำแนะนำหรือคำแนะนำใด ๆ ที่จะได้รับการชื่นชม อัปเดต : ฉันใช้ SQL Server 2012 (SP1)

1
จำนวนขั้นตอนฮิสโตแกรมมีการตัดสินใจในสถิติอย่างไร
จำนวนขั้นตอนฮิสโตแกรมมีการตัดสินใจในสถิติใน SQL Server อย่างไร ทำไมถึง จำกัด เพียง 200 ขั้นตอนถึงแม้ว่าคอลัมน์หลักของฉันมีค่าแตกต่างกันมากกว่า 200 ค่า มีปัจจัยในการตัดสินใจหรือไม่? การสาธิต นิยามสคีมา CREATE TABLE histogram_step ( id INT IDENTITY(1, 1), name VARCHAR(50), CONSTRAINT pk_histogram_step PRIMARY KEY (id) ) การแทรก 100 บันทึกลงในตารางของฉัน INSERT INTO histogram_step (name) SELECT TOP 100 name FROM sys.syscolumns การอัปเดตและตรวจสอบสถิติ UPDATE STATISTICS histogram_step WITH fullscan DBCC …

2
ไม่สิ้นสุดการค้นหาใน Query Store
ฉันจะบอกตั้งแต่ต้นว่าคำถาม / ปัญหาของฉันมีลักษณะคล้ายกับนี้ก่อนหน้านี้หนึ่ง แต่เนื่องจากผมไม่แน่ใจว่าถ้าสาเหตุหรือข้อมูลเริ่มต้นเหมือนกันฉันตัดสินใจที่จะโพสต์คำถามของฉันที่มีรายละเอียดบางอย่างมากขึ้น ปัญหาในมือ: ในเวลาไม่กี่ชั่วโมง (ใกล้ถึงสิ้นวันทำการ) ตัวอย่างการผลิตจะเริ่มทำงานผิดปกติ: CPU สูงสำหรับอินสแตนซ์ (จากพื้นฐานประมาณ 30% มันจะเพิ่มขึ้นเป็นสองเท่าและยังคงเติบโตอยู่) เพิ่มจำนวนธุรกรรม / วินาที (แม้ว่าการโหลดแอปจะไม่เห็นการเปลี่ยนแปลงใด ๆ ) เพิ่มจำนวนเซสชันว่าง เหตุการณ์การบล็อกแปลก ๆ ระหว่างเซสชันที่ไม่เคยแสดงพฤติกรรมนี้ (แม้จะอ่านเซสชันที่ไม่มีข้อผูกมัดก็ทำให้เกิดการบล็อก) การรอช่วงบนสุดเป็นช่วงที่ไม่ใช่การสลักหน้าในอันดับที่ 1 โดยมีการล็อกตำแหน่งที่ 2 การตรวจสอบเบื้องต้น: การใช้ sp_whoIsActive เราเห็นว่าการสืบค้นที่ดำเนินการโดยเครื่องมือตรวจสอบของเราตัดสินใจที่จะทำงานช้ามากและจับ CPU จำนวนมากสิ่งที่ไม่เคยเกิดขึ้นมาก่อน ระดับการแยกของมันถูกอ่านปราศจากข้อผูกมัด เราดูแผนที่เราเห็นตัวเลขที่แปลกประหลาด: StatementEstRows = "3.86846e + 010" โดยมีข้อมูลประมาณ 150 TB เพื่อส่งคืน เราสงสัยว่าคุณลักษณะการตรวจสอบข้อความค้นหาของเครื่องมือตรวจสอบนั้นเป็นสาเหตุดังนั้นเราจึงปิดการใช้งานคุณลักษณะนี้ (เราได้เปิดตั๋วกับผู้ให้บริการของเราเพื่อตรวจสอบว่าพวกเขาตระหนักถึงปัญหาใด ๆ หรือไม่) จากเหตุการณ์แรกนั้นมันเกิดขึ้นอีกสองสามครั้งทุกครั้งที่เราฆ่าเซสชันทุกอย่างกลับสู่ปกติ …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.