คำถามติดแท็ก system-tables

8
วิธีสอบถามฐานข้อมูลสำหรับตารางว่าง
เนื่องจาก 'นักพัฒนา' บางคนเราทำงานกับระบบของเราเรามีปัญหากับตารางที่ว่างเปล่า เราพบว่าระหว่างการถ่ายโอนไปยังคลาวด์มีการคัดลอกหลายตาราง แต่ข้อมูลในนั้นไม่ได้ ฉันต้องการเรียกใช้แบบสอบถามตารางระบบเพื่อค้นหาว่าตารางผู้ใช้ว่างเปล่า เรากำลังใช้ MS SQL 2008 R2 ขอบคุณสำหรับความช่วยเหลือ

2
มุมมองระบบอ้างอิงใน SSDT?
ฉันได้นำเข้าฐานข้อมูลไปยัง SSDT ที่มีการอ้างอิงถึงมุมมองระบบ (โดยเฉพาะ sys.columns) ปัญหาคือว่าฉันได้รับคำเตือนเกี่ยวกับการอ้างอิงที่ยังไม่ได้แก้ไขเมื่อฉันสร้างโครงการ จากสิ่งที่ฉันเห็นในฟอรัม MSDN ดูเหมือนว่าอาจเป็นปัญหาที่ทราบ: http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/5a7026bd-0602-42e6-a639- d73bed903c26 ตอนนี้ฉันรู้ว่าฉันสามารถปิดการเตือนหรือเพิกเฉยได้ แต่ไม่มีใครรู้วิธีการแก้ปัญหาที่เกิดขึ้นจริง? ขอบคุณ

2
ตารางระบบ SQL Server สามารถจัดระเบียบได้หรือไม่?
เรามีฐานข้อมูลหลายแห่งที่สร้างและวางตารางจำนวนมาก จากสิ่งที่เราสามารถบอกได้ SQL Server จะไม่ทำการบำรุงรักษาภายในใด ๆ บนตารางฐานของระบบซึ่งหมายความว่าพวกเขาสามารถแยกส่วนกันมากในช่วงเวลาและขนาด bloated สิ่งนี้ทำให้เกิดความกดดันที่ไม่จำเป็นในบัฟเฟอร์พูลและยังส่งผลเสียต่อประสิทธิภาพการทำงานเช่นการคำนวณขนาดของตารางทั้งหมดในฐานข้อมูล ไม่มีใครมีคำแนะนำสำหรับการลดการกระจายตัวของบนตารางหลักภายในเหล่านี้หรือไม่ วิธีแก้ปัญหาที่ชัดเจนวิธีหนึ่งสามารถหลีกเลี่ยงการสร้างตารางจำนวนมาก (หรือสร้างตารางชั่วคราวทั้งหมดใน tempdb) แต่สำหรับจุดประสงค์ของคำถามนี้สมมติว่าแอปพลิเคชันไม่มีความยืดหยุ่นนั้น แก้ไข: การวิจัยเพิ่มเติมแสดงคำถามที่ยังไม่ได้ตอบซึ่งมีความเกี่ยวข้องอย่างใกล้ชิดและระบุว่าการบำรุงรักษาด้วยตนเองบางรูปแบบผ่านทางALTER INDEX...REORGANIZEอาจเป็นตัวเลือก การวิจัยเบื้องต้น ข้อมูลเมตาเกี่ยวกับตารางเหล่านี้สามารถดูได้ในsys.dm_db_partition_stats: -- The system base table that contains one row for every column in the system SELECT row_count, (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, reserved_page_count/128. AS space_mb FROM sys.dm_db_partition_stats …

1
ฉันสามารถปรับปรุงประสิทธิภาพบนตารางระบบ Bloated ได้หรือไม่
ความเป็นมา: ฉันมีฐานข้อมูลจำนวนมากที่มี VIEW จำนวนมากและ SYNONYM จำนวนมาก ตัวอย่างเช่นหนึ่งฐานข้อมูลมีมากกว่า 10k VIEW และ 2+ ล้าน SYNONYM ปัญหาทั่วไป: ข้อความค้นหาที่เกี่ยวข้องsys.objects(และตารางระบบโดยทั่วไป) มีแนวโน้มที่จะช้า ข้อความค้นหาที่เกี่ยวข้องsys.synonymsเป็นน้ำแข็ง ฉันสงสัยว่าฉันจะทำอย่างไรเพื่อปรับปรุงประสิทธิภาพ ตัวอย่างที่เฉพาะเจาะจง คำสั่งนี้ดำเนินการโดยเครื่องมือของบุคคลที่สาม มันช้าทั้งในแอพและใน SSMS: exec sp_tables_rowset;2 NULL,NULL คำถามของฉัน : ฉันจะทำให้การทำงานนี้เร็วขึ้นได้อย่างไร สิ่งที่ฉันได้ลอง : ถ้าSET STATISTICS IO ONฉันได้รับสิ่งนี้: (2201538 แถวที่ได้รับผลกระทบ) ตาราง 'sysobjrdb' จำนวนการสแกน 1, การอ่านเชิงตรรกะ 28, การอ่านทางกายภาพ 0, การอ่านล่วงหน้าอ่าน 0, การอ่านตรรกะล่วงหน้า lob 0, lob …

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.