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

โดยทั่วไปแล้วการสำรองข้อมูลเต็มรูปแบบรายสัปดาห์ของเราจะเสร็จสิ้นในเวลาประมาณ 35 นาทีโดยมีการสำรองข้อมูลต่าง ๆ รายวันเสร็จใน ~ 5 นาที ตั้งแต่วันอังคารหนังสือพิมพ์รายวันใช้เวลาเกือบ 4 ชั่วโมงจึงจะเสร็จสมบูรณ์ บังเอิญสิ่งนี้เริ่มเกิดขึ้นทันทีหลังจากที่เราได้ SAN / disk config ใหม่ โปรดทราบว่าเซิร์ฟเวอร์กำลังทำงานในการผลิตและเราไม่มีปัญหาโดยรวมก็ทำงานได้อย่างราบรื่น - ยกเว้นปัญหา IO ที่ปรากฏตัวเป็นหลักในการสำรองข้อมูล ดูที่ dm_exec_requests ระหว่างการสำรองข้อมูลการสำรองข้อมูลกำลังรอ ASYNC_IO_COMPLETION อยู่ตลอดเวลา อ๊ะเรามีข้อขัดแย้งของดิสก์! อย่างไรก็ตามทั้ง MDF (บันทึกจะถูกเก็บไว้ในโลคัลดิสก์) หรือไดรฟ์สำรองไม่มีกิจกรรมใด ๆ (IOPS ~ = 0 - เรามีหน่วยความจำมากมาย) ความยาวคิวของดิสก์ ~ = 0 เช่นกัน CPU วนเวียนอยู่ประมาณ 2-3% ไม่มีปัญหาเช่นกัน SAN เป็น …

31 sql-server-2008-r2  backup  network  san 

เซิร์ฟเวอร์ SQL ของเราใช้งาน SAN มันมีฐานข้อมูล OLTP หลายสิบบางตัวมีหลายตารางที่มีมากกว่า 1m บันทึก เรารันสคริปต์บำรุงรักษาดัชนีของ Ola Hallengrenทุกสัปดาห์และทำงานเป็นเวลาหลายชั่วโมงในแต่ละครั้ง ขึ้นอยู่กับเกณฑ์การกระจายตัวของสคริปต์จะจัดระเบียบใหม่หรือดัชนีดัชนีใหม่ เราสังเกตว่าในระหว่างการทำดัชนีใหม่ไฟล์บันทึกจะมีขนาดใหญ่ซึ่งนำไปสู่การสิ้นเปลืองแบนด์วิธที่มากเกินไปในระหว่างการจัดส่งบันทึก จากนั้นบทความจาก Brent Ozar ซึ่งเขาบอกว่าจะหยุดกังวลเกี่ยวกับดัชนี SQL : ฮาร์ดไดรฟ์ของคุณแชร์กับเซิร์ฟเวอร์อื่น ๆ ที่กำลังส่งคำขอไดรฟ์ในเวลาเดียวกันดังนั้นไดรฟ์จะกระโดดไปทั่วเพื่อรับข้อมูล การดีแฟรกดัชนีของคุณเป็นงานยุ่งที่ไร้ความหมาย Googling คำถามนี้นำไปสู่ความคิดเห็นที่แตกต่างกันส่วนใหญ่สนับสนุนด้วยการขัดแย้งที่ดูเหมือนสั้นหรืออ่อนแอเกินไป แผนเบื้องต้นของเราคือการปรับเปลี่ยนเกณฑ์การแตกแฟรกเมนต์ในสคริปต์การบำรุงรักษาของเราเพื่อให้การจัดระเบียบใหม่บ่อยกว่าการจัดทำดัชนีใหม่ คำตัดสินสุดท้ายคืออะไร? มันคุ้มค่าหรือไม่ที่จะจัดเรียงดัชนี SQL บน SAN โดยพิจารณาภาระที่เกี่ยวข้องกับการรันงานบำรุงรักษารายสัปดาห์

16 sql-server  sql-server-2008-r2  index  database-recommendation  san