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

ภายใต้ PostgreSQL 9.2.2 (Windows 32 บิต) ฉันมีpg_restoreคำสั่งที่ส่งผลให้เกิดคำเตือนเกี่ยวกับความถี่ของจุดตรวจสอบอย่างเป็นระบบเช่น: LOG: checkpoints are occurring too frequently (17 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". ฐานข้อมูลมีขนาดประมาณ 3.3 Gb โดยมี 112 tables / 160 views และเรียกคืนได้ในเวลาประมาณ 14 นาที เป็นเรื่องปกติpg_restoreหรือไม่ที่จะเกิดขึ้นในช่วง a ?

15 postgresql  restore  configuration  checkpoint 

เรื่องยาว แต่ที่ปรึกษาระยะยาวของเรา (อดีตพนักงาน) เขียนสคริปต์ที่กำหนดเองปีที่ผ่านมา (2006 หรือดังนั้น) เพื่อติดต่อกับ Tivoli Storage Manager และดูเหมือนว่ามันจะได้รับการตรวจสอบตัวเลือก SQL Server DB truncate log on checkpointชื่อ การเรียกร้องของพวกเขาคือมันป้องกันสคริปต์จากการทำงานและการสำรองข้อมูลในอินสแตนซ์ซึ่งเป็น SQL 2012 ฉันรู้สึกว่า BS นั้นสมบูรณ์เพราะฉันไม่พบตัวเลือกดังกล่าวผ่านทางsp_configureและการสำรองข้อมูลทำงานได้ทุกที่ยกเว้นกรณีเดียว อย่างไรก็ตามฉันต้องการที่จะลบทุ่นระเบิดถ้านั่นคือสิ่งที่มันเป็นและลบองค์ประกอบที่ล้าสมัยอื่น ๆ ฉันให้พวกเขาตรวจสอบกับผู้ขาย แต่ฉันไม่มีความมั่นใจในระดับสูงในสิ่งที่พวกเขาพูด การวิจัยที่ฉันได้รับกลับมายิ่งกว่านั้นอาจเป็นตัวเลือกสำหรับ SQL 2000 หรือตัวเลือก Sybase การอ้างสิทธิ์อีกอย่างคือมันถูกเรียก / ใช้โดยนัยในรุ่นที่ใหม่กว่า (2008 ขึ้นไป) เมื่อรูปแบบการกู้คืนเป็นSIMPLEและไม่มีตัวเลือกที่ชัดเจนในการเปิดหรือปิด เนื่องจากTRUNCATE LOGคำสั่งล้าสมัยเนื่องจากบันทึกการทำงานของธุรกรรมในปัจจุบันฉันคิดว่านี่ไม่ใช่ตัวเลือกที่สามารถสอบถามได้ที่จุดนี้ เนื่องจากฉันไม่มีอินสแตนซ์ของ SQL Server 2000 ฉันหวังว่าจะมีบางคนจำได้หรือสามารถตรวจสอบได้จากที่วางไว้ ฉันบอกพวกเขาว่ามันไม่มีอะไรจะแนะนำ ฉันก็หวังว่าบางคนสามารถยืนยันได้ว่านี่เป็นสิ่งล้าสมัย

11 sql-server  sql-server-2012  transaction  log  checkpoint 

เมื่อเราย้ายจากแฟลชอาร์เรย์ทั้งหมดที่เก่ากว่าไปเป็นแฟลชอาร์เรย์ทั้งหมดที่ใหม่กว่า (ต่างกัน แต่เป็นผู้จำหน่ายที่ได้รับการยอมรับ) เราเริ่มเห็นการรอคอยเพิ่มขึ้นใน SQL Sentry ระหว่างจุดตรวจ เวอร์ชัน: SQL Server 2012 Sp4 ในที่เก็บข้อมูลเก่าของเราการรอคอยของเราอยู่ที่ประมาณ 2k ด้วย "spikes" ถึง 2,500 ในระหว่างการตรวจสอบกับที่เก็บข้อมูลใหม่ spikes มักจะ 10k กับยอดใกล้ 50k ยามชี้ให้เราเห็นว่ามีความPAGEIOLATCHสุขมากขึ้น ทำการวิเคราะห์ของเราเองดูเหมือนว่าจะเป็นการรวมกันของPAGEIOLATCH and PAGELATCHรอ การใช้ Perfmon โดยทั่วไปเราสามารถพูดได้ว่ายิ่งมีด่านมากขึ้นเท่าไรเราก็ยิ่งได้รับมากขึ้นเท่านั้น ภาระงานของเราส่วนใหญ่จะเขียน (แทรก / ปรับปรุงเป็นหลัก) ผู้จำหน่ายอุปกรณ์จัดเก็บได้พิสูจน์ให้เราเห็นแล้วว่าอาร์เรย์ที่ต่อตรงกับ Fibre Channel นั้นตอบสนองย่อย 1 ms ในระหว่างเหตุการณ์จุดตรวจสอบเหล่านี้ HBA ยังยืนยันหมายเลขของอาเรย์ด้วย เรายังไม่เชื่อว่าเป็นปัญหาการเข้าคิว HBA เนื่องจากความลึกของคิวไม่เคยสูงกว่า 8 เราได้ลองใช้ HBA …

9 sql-server  sql-server-2012  storage  waits  checkpoint