ผู้ดูแลระบบ Microsoft หลายคน เซิร์ฟเวอร์ SQLประสบปัญหาขนาดทางกายภาพของฐานข้อมูลและไฟล์บันทึกธุรกรรมเพิ่มขึ้นอย่างมากและแน่นอนว่าพวกเขาต้องการลดขนาดนี้เพื่อไม่ให้ดำเนินการใด ๆ ที่เกี่ยวข้องกับการเพิ่มพื้นที่ว่างบนฮาร์ดไดรฟ์ วิธีลด ขนาดทางกายภาพฐานข้อมูลและไฟล์บันทึกธุรกรรมใน เซิร์ฟเวอร์ SQLมี - นี่คือ การบีบอัด.
การบีบอัดข้อมูลใน Microsoft SQL Server คืออะไร
การบีบอัดเป็นกระบวนการลบพื้นที่ที่ไม่ได้ใช้ในฐานข้อมูลและไฟล์บันทึกธุรกรรม
ขนาดทางกายภาพของไฟล์ฐานข้อมูลจะเพิ่มขึ้นเมื่อเวลาผ่านไป ซึ่งเกิดจากการเพิ่มข้อมูล แต่เมื่อถูกลบ ขนาดทางกายภาพของไฟล์จะยังคงไม่เปลี่ยนแปลง อย่างไรก็ตาม พื้นที่ว่างที่ไม่ได้ใช้เชิงตรรกะจะปรากฏในไฟล์เหล่านี้ ซึ่งสามารถลบได้
ผลกระทบที่ยิ่งใหญ่ที่สุดของการบีบอัดจะเกิดขึ้นได้เมื่อดำเนินการบีบอัดหลังจากการดำเนินการลบตารางออกจากฐานข้อมูลหรือลบข้อมูลออกจากตาราง
คุณควรแยกความแตกต่างระหว่างการบีบอัดบันทึกธุรกรรมและการตัดทอนบันทึกธุรกรรม การบีบอัดเป็นกระบวนการลดขนาดทางกายภาพของบันทึกโดยการลบพื้นที่ที่ไม่ได้ใช้ ในขณะที่การตัดทอนเป็นกระบวนการในการเพิ่มพื้นที่ในบันทึกลอจิคัลสำหรับ ใช้ซ้ำ (เหล่านั้น. พื้นที่ที่ไม่ได้ใช้ถูกสร้างขึ้น) บันทึกธุรกรรมพร้อมขนาด ไฟล์ฟิสิคัลไม่ลดลง
การตัดทอนบันทึกธุรกรรมเกิดขึ้นโดยอัตโนมัติ:
- ในรูปแบบการกู้คืนแบบง่าย ๆ - หลังจากบรรลุผลแล้ว จุดควบคุมซึ่งสามารถเกิดขึ้นได้ เช่น หลังจากนั้น กำลังสร้างการสำรองข้อมูลเมื่อมีการดำเนินการคำสั่ง CHECKPOINT ที่ชัดเจน หรือเมื่อขนาดของบันทึกธุรกรรมแบบลอจิคัลเต็ม 70 เปอร์เซ็นต์ ในทุกกรณีเหล่านี้ ทำความสะอาดอัตโนมัติส่วนที่ไม่ทำงานของบันทึก เช่น การตัดทอน;
- ในรูปแบบ ฟื้นตัวเต็มที่หรือในรูปแบบการกู้คืนที่บันทึกจำนวนมาก หลังจากสร้างการสำรองข้อมูลบันทึก โดยมีเงื่อนไขว่าถึงจุดตรวจสอบแล้วนับตั้งแต่สร้างการสำรองข้อมูลบันทึกครั้งล่าสุด
หากคุณใช้โมเดลการกู้คืนแบบเต็มหรือโมเดลการกู้คืนที่บันทึกจำนวนมาก และไฟล์บันทึกธุรกรรมของคุณมีขนาดใหญ่เกินไป เป็นไปได้มากว่าคุณไม่ได้สำรองข้อมูลมาเป็นเวลานาน ( สำเนาสำรอง) บันทึกการทำธุรกรรม ใน ในกรณีนี้คุณต้องสำรองข้อมูลบันทึกธุรกรรมก่อน จากนั้นจึงทำการบีบอัดบันทึกธุรกรรม ซึ่งเราจะดูด้านล่าง
อาจเป็นไปได้ว่าไฟล์บันทึกธุรกรรมมีขนาดใหญ่เกินไป ( สำหรับทั้งแบบจำลองการกู้คืนแบบง่ายและแบบเต็ม) เนื่องจากความล่าช้าของขั้นตอนการตัดทอน เช่น ขนาดบันทึกประกอบด้วยส่วนที่ใช้งานอยู่ของบันทึกเป็นส่วนใหญ่ และไม่สามารถตัดส่วนที่ใช้งานอยู่ได้ ดังนั้นขนาดทางกายภาพของบันทึกจึงเพิ่มขึ้น ปัจจัยที่ส่งผลต่อเวลาแฝงของขั้นตอนการตัดทอนได้แก่: ธุรกรรมที่ใช้เวลานานที่ใช้งานอยู่ ฐานข้อมูลมิเรอร์บางส่วนและสถานการณ์การแมปบันทึกธุรกรรม บางธุรกรรมและสถานการณ์จำลองล็อกธุรกรรม และการตัดทอนบันทึกไม่สามารถทำได้ในระหว่างการดำเนินงาน การสำรองข้อมูลและการกู้คืนข้อมูล ในกรณีนี้ คุณต้องกำจัดสาเหตุของความล่าช้า จากนั้นจึงตัด ( เหล่านั้น. เช่นสำหรับรุ่นเต็ม การสำรองข้อมูลการกู้คืนนิตยสาร) จากนั้นบีบอัดให้ได้ขนาดที่ยอมรับได้
ปกติถ้า อย่างต่อเนื่องกับ ในช่วงเวลาหนึ่งกำลังถูกสร้างขึ้น การสำรองข้อมูลบันทึกธุรกรรมหรือฐานข้อมูล ( ด้วยรูปแบบการกู้คืนแบบง่ายๆ) แฟ้มบันทึกธุรกรรมไม่ขยาย และไม่มีการบันทึกธุรกรรมล้นเกินเกิดขึ้น
วิธีการบีบอัดฐานข้อมูลใน MS SQL Server?
คุณยังสามารถบีบอัดฐานข้อมูลและไฟล์บันทึกธุรกรรมโดยใช้ กุย Management Studio และการใช้คำสั่ง Transact-SQL: DBCC ลดขนาดฐานข้อมูลและ DBCC SHRINKFILE- นอกจากนี้ยังสามารถกำหนดค่าฐานข้อมูลสำหรับการบีบอัดอัตโนมัติโดยการตั้งค่าพารามิเตอร์ฐานข้อมูล AUTO_SHRINK เป็น ON
บันทึก! ฉันจะพิจารณาการบีบอัดฐานข้อมูลโดยใช้ตัวอย่างของ Microsoft SQL Server 2016 Express.
การกระชับฐานข้อมูลโดยใช้ Management Studio
เรียกใช้ Management Studio และเปิดวัตถุในเบราว์เซอร์วัตถุ " ฐานข้อมูล- จากนั้นคลิก คลิกขวาเลื่อนเมาส์ไปเหนือฐานข้อมูลที่ต้องการบีบอัด จากนั้นเลือก “ งาน -> บีบอัด -> ฐานข้อมูล (หรือไฟล์ เช่น คุณจะต้องบีบอัดบันทึกธุรกรรมเท่านั้น)- เช่น ฉันเลือก “ ฐานข้อมูล».
ส่งผลให้หน้าต่าง” การบีบอัดฐานข้อมูล" ซึ่งคุณสามารถสังเกตขนาดของฐานข้อมูลรวมถึงขนาดที่มีอยู่ได้ พื้นที่ว่างซึ่งสามารถลบได้ ( เหล่านั้น. บีบอัด- คลิก " ตกลง».
หลังจากผ่านไปสักระยะหนึ่ง ขึ้นอยู่กับขนาดของฐานข้อมูล การบีบอัดจะเสร็จสมบูรณ์
เราบีบอัดฐานข้อมูลโดยใช้คำสั่ง SHRINKDATABASE และ SHRINKFILE
ใน MS SQL Server มีสองคำสั่ง SHRINKDATABASE และ SHRINKFILE เพื่อทำการบีบอัดฐานข้อมูลและไฟล์บันทึกธุรกรรม
- DBCC ลดขนาดฐานข้อมูล– เป็นคำสั่งบีบอัดฐานข้อมูล
- DBCC SHRINKFILE– การใช้คำสั่งนี้ทำให้คุณสามารถบีบอัดไฟล์ฐานข้อมูลบางไฟล์ได้ ( ตัวอย่างเช่น เฉพาะบันทึกธุรกรรมเท่านั้น).
เพื่อดำเนินการบีบอัดฐานข้อมูล ( เช่น TestBase) เช่นเดียวกับที่เราทำก่อนหน้านี้เล็กน้อยใน Management Studio ให้ทำตามคำแนะนำต่อไปนี้
DBCC SHRINKDATABASE(N "ฐานทดสอบ")
SHRINKDATABASE มีพารามิเตอร์ต่อไปนี้:
- Database_name หรือ Database_id - ชื่อหรือตัวระบุของฐานข้อมูลที่จำเป็นต้องบีบอัด หากคุณระบุค่าเป็น 0 ฐานข้อมูลปัจจุบันจะถูกนำมาใช้
- เป้าหมาย_เปอร์เซ็นต์ – พื้นที่ว่างเป็นเปอร์เซ็นต์ที่ควรยังคงอยู่ในฐานข้อมูลหลังการบีบอัด
- NOTRUNCATE - บีบอัดข้อมูลในไฟล์โดยการย้ายหน้าที่จัดสรรจากท้ายไฟล์ไปยังตำแหน่งของหน้าที่ไม่ได้จัดสรรที่จุดเริ่มต้นของไฟล์ หากระบุพารามิเตอร์นี้ ขนาดฟิสิคัลของไฟล์จะไม่เปลี่ยนแปลง
- TRUNCATEONLY - เพิ่มพื้นที่ว่างทั้งหมดที่ท้ายไฟล์ ระบบปฏิบัติการแต่ไม่ย้ายหน้าภายในไฟล์ ไฟล์ข้อมูลจะลดลงเหลือเฉพาะขอบเขตที่จัดสรรครั้งล่าสุดเท่านั้น หากระบุพารามิเตอร์นี้ พารามิเตอร์ target_percent จะไม่ถูกประมวลผล
- ด้วย NO_INFOMSGS - ระงับทุกอย่าง ข้อความข้อมูลโดยมีระดับความรุนแรงตั้งแต่ 0 ถึง 10
ไวยากรณ์ SHRINKDATABASE
DBCC SHRINKDATABASE (database_name | Database_id | 0 [ , target_percent ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ]) [ พร้อม NO_INFOMSGS ]
หากต้องการบีบอัดเฉพาะบันทึกธุรกรรมที่คุณสามารถใช้ได้ คำแนะนำ SHRINKFILE, ตัวอย่างเช่น.
DBCC SHRINKFILE (N "TestBase_log")
ในกรณีนี้ เราจะบีบอัดไฟล์บันทึก ( TestBase_log คือชื่อของไฟล์บันทึกธุรกรรม) เป็นค่าเริ่มต้นคือ เป็นค่าเริ่มต้น หากต้องการบีบอัดไฟล์ให้มีขนาดเฉพาะ ให้ระบุขนาดเป็นเมกะไบต์เป็นพารามิเตอร์ตัวที่สอง ตัวอย่างเช่น, โดยมีคำแนะนำดังต่อไปนี้เราจะลดขนาดไฟล์บันทึกธุรกรรมลงเหลือ 5 เมกะไบต์
DBCC SHRINKFILE (N "TestBase_log" , 5)
นอกจากนี้ยังจำเป็นต้องคำนึงด้วยว่าหากคุณระบุขนาดที่เล็กกว่าที่จำเป็นในการจัดเก็บข้อมูลในไฟล์ ไฟล์จะไม่ถูกบีบอัดขนาดนี้ ตัวอย่างเช่น สมมติว่าคุณระบุขนาด 5 เมกะไบต์ แต่ไฟล์ต้องการพื้นที่ 7 เมกะไบต์ในการจัดเก็บข้อมูล ไฟล์จะถูกบีบอัดเหลือเพียง 7 เมกะไบต์เท่านั้น
SHRINKFILE ยังมีตัวเลือก NOTRUNCATE และ TRUNCATEONLY
ไวยากรณ์ SHRINKFILE
DBCC SHRINKFILE (( file_name | file_id ) ( [ , EMPTYFILE ] | [ [ , target_size ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ] ] )) [ พร้อม NO_INFOMSGS ]
- การดำเนินการกระชับฐานข้อมูลอาจทำให้เกิดการกระจายตัวของดัชนี และทำให้ฐานข้อมูลช้าลง ดังนั้นจึงไม่แนะนำให้บีบอัดฐานข้อมูลบ่อยเกินไป
- เป็นการดีกว่าที่จะบีบอัดฐานข้อมูลก่อนการดำเนินการสร้างดัชนีใหม่ เช่น หลังจากการบีบอัด ให้เริ่มขั้นตอนการสร้างดัชนีใหม่
- พารามิเตอร์ฐานข้อมูล AUTO_SHRINK ( การบีบอัดอัตโนมัติ) จะดีกว่าที่จะไม่ตั้งค่าเป็น ON แต่ปล่อยให้เป็นค่าเริ่มต้นเช่น ปิด เว้นแต่คุณจะมีเหตุผลที่จริงจังเพียงพอสำหรับเรื่องนี้
- คำสั่ง SHRINKDATABASE ไม่อนุญาตให้คุณลดขนาดของฐานข้อมูลให้มีขนาดเล็กกว่าขนาดเริ่มต้น เช่น ขั้นต่ำ อย่างไรก็ตาม คำสั่ง SHRINKFILE สามารถทำได้ ( พารามิเตอร์ตัวที่สองระบุว่าขนาดน้อยกว่าค่าต่ำสุด). ขนาดขั้นต่ำขนาดฐานข้อมูลคือขนาดที่ระบุเมื่อมีการสร้างฐานข้อมูลหรือตั้งค่าอย่างชัดเจนโดยการดำเนินการปรับขนาดฐานข้อมูล เช่น DBCC SHRINKFILE หรือ ALTER DATABASE ตัวอย่างเช่น หากฐานข้อมูลถูกสร้างขึ้นด้วยขนาด 10 เมกะไบต์ จากนั้นขยายเป็น 100 เมกะไบต์ ฐานข้อมูลนั้นสามารถบีบอัดได้โดยใช้ SHRINKDATABASE เป็น 10 เมกะไบต์เริ่มต้นเท่านั้น แม้ว่าข้อมูลทั้งหมดจะถูกลบออกจากฐานข้อมูลแล้วก็ตาม
- ไฟล์บันทึกฐานข้อมูลและธุรกรรมไม่สามารถบีบอัดได้ในขณะที่กำลังสำรองข้อมูล ในทางกลับกัน คุณไม่สามารถสร้างสำเนาสำรองของฐานข้อมูลและบันทึกธุรกรรมในขณะที่กำลังถูกบีบอัดได้
- การรันคำสั่ง DBCC SHRINKDATABASE โดยไม่ระบุตัวเลือก NOTRUNCATE หรือ TRUNCATEONLY จะเหมือนกับการรันคำสั่ง DBCC SHRINKDATABASE ด้วยตัวเลือก NOTRUNCATE หลังจากการรันคำสั่ง DBCC SHRINKDATABASE ด้วยตัวเลือก TRUNCATEONLY
- ในขณะที่ฐานข้อมูลกำลังถูกบีบอัด ผู้ใช้สามารถทำงานในฐานข้อมูลได้ ( เหล่านั้น. ไม่จำเป็นต้องเปลี่ยนฐานข้อมูลเป็นโหมดผู้ใช้คนเดียว);
- คุณสามารถขัดจังหวะกระบวนการดำเนินการ SHRINKDATABASE และ SHRINKFILE ได้ตลอดเวลา ในขณะที่งานที่เสร็จสมบูรณ์ทั้งหมดจะถูกบันทึก
- ก่อนเริ่มขั้นตอนการบีบอัด ให้ตรวจสอบว่ามีพื้นที่ว่างสำหรับการลบในไฟล์ฐานข้อมูลหรือไม่ เช่น เป็นไปได้ไหมที่จะบีบอัดไฟล์เลยโดยการรันแบบสอบถามต่อไปนี้ ( มันจะแสดงเป็นเมกะไบต์ว่าคุณสามารถลดไฟล์ฐานข้อมูลได้เท่าใด).
นั่นคือทั้งหมดสำหรับฉัน ฉันหวังว่าบทความนี้จะเป็นประโยชน์กับคุณ โชคดี!
การบีบอัดข้อมูลใน SQL Server 2008
เมื่อเร็วๆ นี้ฉันต้องย้ายคลังข้อมูลของฉันจาก SQL Server 2005 ไปยัง SQL Server 2008 ดังที่คุณทราบ หนึ่งในนวัตกรรมใน SQL Server 2008 คือการบีบอัดข้อมูล คุณลักษณะนี้ได้รับการออกแบบมาเพื่อปรับปรุงประสิทธิภาพของฐานข้อมูลโดยการบีบอัดข้อมูลและดัชนีในตารางและมุมมองที่จัดทำดัชนี ส่งผลให้ I/O ลดลง นอกจากนี้ ต้องขอบคุณการบีบอัด ขนาดของฐานข้อมูลจึงลดลงอย่างมาก ซึ่งทำให้การดูแลระบบและการจัดการง่ายขึ้น ทั้งหมดนี้ฟังดูน่าดึงดูดใจ ดังนั้นฉันจึงตัดสินใจใช้ประโยชน์จากโอกาสนี้
เหตุผลที่กระตุ้นให้ฉันพิจารณาฟังก์ชันนี้ให้ละเอียดยิ่งขึ้นและในที่สุดก็เขียนบทความนี้ก็คือ ฉันได้รับผลลัพธ์ที่แตกต่างไปจากที่คาดไว้อย่างสิ้นเชิง :)
ฉันตัดสินใจบีบอัดตารางข้อเท็จจริงที่ใหญ่ที่สุดสามตาราง ซึ่งเป็นโครงสร้างที่มีคอลัมน์ที่มีขนาดกะทัดรัดที่สุดเท่าที่จะเป็นไปได้ โดยอ้างอิงการอ้างอิงมิติข้อมูล และมีตัวบ่งชี้จำนวนหนึ่งที่รวมอยู่ในรายงาน ด้านล่างนี้คือโครงสร้างทั่วไปของตารางข้อเท็จจริงและการสืบค้นทั่วไปของตารางนี้ในรูปแบบที่เรียบง่าย
แต่ที่น่าประหลาดใจของฉันคือ หลังจากการบีบอัด ไม่เพียงแต่ฉันไม่ได้รับประสิทธิภาพเพิ่มขึ้นเท่านั้น แต่ในทางกลับกัน การดำเนินการค้นหาก็ช้าลงอีกด้วย ในบางกรณี ประสิทธิภาพยังคงเหมือนเดิม
มีการตัดสินใจที่จะตรวจสอบผลกระทบของการบีบอัดข้อมูลและดำเนินการทดสอบเพื่อตอบคำถามเกี่ยวกับประสิทธิภาพที่ลดลง
การเตรียมการทดสอบ
จึงมีตารางหนึ่ง เรียกว่า ProductMMR ซึ่งมีข้อเท็จจริงบางอย่างในหลายส่วน
นี่คือโครงสร้างของมัน:
คลังสินค้า
ผลิตภัณฑ์
วันที่
ประเภทคลังสินค้า
ปริมาณ
ขนาดเริ่มต้นของตารางคือ 16 GB ดัชนีคือ 18 GB (ฉันใช้ระบบ HPsp_spaceused เพื่อกำหนดขนาดข้อมูลและดัชนี)
ตอนนี้เป็นเวลาตัดสินใจว่าเราจะใช้เกณฑ์ใดในการประเมินประสิทธิภาพการบีบอัด
เนื่องจากนักพัฒนาหรือผู้ดูแลระบบเกือบทุกคนใส่ใจกับประสิทธิภาพของเซิร์ฟเวอร์และแอปพลิเคชันของเขา จึงชัดเจนว่าเกณฑ์หลักในการประเมินประสิทธิภาพของการบีบอัดคือเวลาที่ใช้ในการดำเนินการค้นหา จำนวนการดำเนินการ I/O และจำนวน CPU เวลาที่ใช้ไป ว่างแล้ว พื้นที่ดิสก์อันเป็นผลมาจากการบีบอัด
ต่อไปนี้เป็นแบบสอบถามทดสอบเพื่อเลือกตารางนี้:
ตั้งค่าเวลาสถิติ -- เพื่อวัดเวลาดำเนินการแบบสอบถาม
ตั้งค่าสถิติ IO ON -- เพื่อวัดการดำเนินการ I/O แบบลอจิคัลและฟิสิคัล
ไป
เลือก
fact.DateID,
fact.StockID,
SUM(fact.Qty) ตามจำนวน
จากข้อเท็จจริงผลิตภัณฑ์ข้อเท็จจริง MMR
ที่ไหน (fact.DateID ระหว่าง @DateIDBegin และ @DateIDEnd)
จัดกลุ่มตาม fact.DateID, fact.StockID
ระบุช่วงเวลา 30 วัน (ในตารางข้อเท็จจริงนี้สอดคล้องกับบันทึกมากกว่า 150 ล้านรายการ)
คำจำกัดความของกลยุทธ์การบีบอัดและการนำไปปฏิบัติ
รายละเอียดเกี่ยวกับการดำเนินการบีบอัด คุณสามารถอ่านได้บน MSDN การดำเนินการบีบอัดสำหรับหน้า และสำหรับเส้น - ผลของการบีบอัดขึ้นอยู่กับข้อมูลในตาราง - มีค่าที่ซ้ำกันกี่ค่าและประเภทของข้อมูลคืออะไร
ตอนนี้เรามาดูการใช้การบีบอัดโดยกำหนดกลยุทธ์ไว้ก่อนหน้านี้
สุนิล อาการ์วัล ในตัวเขาบล็อก มีข้อแนะนำหลายประการในเรื่องนี้ ผมขอสรุปและนำเสนอไว้ ณ ที่นี้
1. การบีบอัดข้อมูลหรือดัชนีที่มีขนาดเล็กไม่สมเหตุสมผล หากตารางมีความยาว 10 หน้าและจะถูกบีบอัดเหลือ 1 หน้า สิ่งนี้จะไม่เป็นประโยชน์ในกรณีนี้ สิ่งสำคัญคือต้องจำไว้ว่าข้อมูลที่บีบอัดจะต้องถูกขยายทุกครั้งที่มีการเข้าถึง ก่อนที่จะใช้การบีบอัด คุณควรประมาณขนาดปัจจุบันของตาราง/ดัชนี และขนาดที่คาดการณ์ไว้หลังการบีบอัด
2.หากโต๊ะมีการใช้งานหนัก คำสั่ง DMLและ SELECT การบีบอัดอาจส่งผลให้ CPU โอเวอร์เฮดมากเกินไปจากการบีบอัดทุกครั้งที่มีการเข้าถึงข้อมูล ในกรณีนี้ คุณต้องระมัดระวังเป็นพิเศษเกี่ยวกับความเป็นไปได้ในการบีบอัดตาราง/ดัชนี
3. หากการประหยัดจากการบีบอัดต่ำ ก็ไม่แนะนำให้ทำการบีบอัด มีหลายกรณีที่ขนาดของข้อมูลที่บีบอัดมีขนาดใหญ่กว่าข้อมูลที่ไม่มีการบีบอัด นี่แสดงว่าตารางใช้มากที่สุด ประเภทกะทัดรัดข้อมูล.
4. หากคุณมีแอปพลิเคชัน OLTP ทั่วไป โดยทั่วไปคุณควรเลือกการบีบอัด ROW การบีบอัดประเภทนี้มีราคาถูกกว่าในแง่ของการบีบอัดข้อมูล อย่างไรก็ตาม ตามกฎแล้ว การบีบอัด PAGE จะมีประสิทธิภาพมากกว่าในแง่ของพื้นที่ว่างที่อาจเกิดขึ้น
คุณสามารถประเมินประโยชน์ของการบีบอัดในตัวช่วยสร้างหรือใช้ขั้นตอนการจัดเก็บsp_estimate_data_compression_savings
ในกรณีของฉัน ฉันได้รับผลลัพธ์เหล่านี้:
ตารางที่ 1.
ประสิทธิภาพการบีบอัดข้อมูล
ประเภทการบีบอัด | ขนาดก่อนอัด | ขนาดหลังการบีบอัด | การบีบอัด% |
แถว | 33.4GB | 22.7GB | 32 % |
หน้าหนังสือ | 33.4GB | 18.3GB | 45 % |
ดังที่เห็นจากตาราง เป็นไปได้ที่จะได้รับผลกระทบของการบีบอัดข้อมูล แม้ว่าในกรณีนี้จะไม่ใช่มากที่สุดก็ตาม ตัวบ่งชี้ที่ดีในหลายกรณี ข้อมูลถูกบีบอัด 70-80%
ในหลายกรณี อัตราส่วนกำลังอัดจะสูงกว่า และในบางกรณีก็สูงกว่าที่ฉันได้รับในการทดสอบนี้มาก ทุกอย่างขึ้นอยู่กับประเภทข้อมูลและจำนวนข้อมูลที่ซ้ำกันที่คุณมีในตาราง
คุณจะเห็นว่าในตารางทดสอบ การบีบอัดระดับแถวจะไม่มีประสิทธิภาพเท่ากับการบีบอัดหน้า โปรดทราบว่าการบีบอัด PAGE เป็นชุดที่เหนือกว่าของการบีบอัด ROW
คุณสามารถใช้การบีบอัดตาราง PAGE/ROW ได้โดยใช้วิซาร์ดการบีบอัด ซึ่งจะสร้างโค้ดดังนี้:
เปลี่ยนตาราง สร้างพาร์ติชันใหม่ = ทั้งหมด
กับ
(DATA_COMPRESSION = แถว
)
คุณสามารถใช้การบีบอัดชนิด PAGE ได้โดยใช้พารามิเตอร์ DATA_COMPRESSION = PAGE
โดยการระบุ DATA_COMPRESSION = NONE คุณสามารถยกเลิกการบีบอัดข้อมูลได้
ฉันจะไม่ให้ไวยากรณ์สำหรับการบีบอัดดัชนีและพาร์ติชันที่นี่ ใครก็ตามที่สนใจสามารถค้นหาพวกมันใน BOL ได้อย่างง่ายดาย
โปรดจำไว้ว่าก่อนที่คุณจะเปิดใช้งานหรือปิดใช้งานการบีบอัดแถวหรือเพจ คุณต้องมีเนื้อที่ดิสก์เท่ากันกับที่คุณต้องการสร้างหรือสร้างดัชนีใหม่
ผลการทดสอบ
ดังนั้นก่อนและหลังการบีบอัดโดยใช้ประเภท PAGE คำขอทดสอบจึงถูกดำเนินการ
นี่คือผลลัพธ์ในแคช "อุ่นเครื่อง":
ตารางที่ 2.
ผลการทดสอบหมายเลข 1*
ประเภทการบีบอัด | เวลาดำเนินการค้นหา (มิลลิวินาที) | การดำเนินการอ่านเชิงตรรกะ** | เวลา CPU ที่ใช้ (มิลลิวินาที) |
ไม่มีการบีบอัด | 26 147 | 1 419 113 | 308 736 |
การบีบอัดหน้า | 41 104 | 709 360 | 486 453 |
*คำขอดำเนินการบนเซิร์ฟเวอร์ที่มี 12 คอร์และ RAM ขนาด 32 GB, ระบบย่อยดิสก์ RAID 10 ตัว
** มีเพียงการดำเนินการอ่านแบบลอจิคัลเท่านั้นที่จะแสดง เนื่องจาก ไม่มีการอ่านทางกายภาพ - ข้อมูลอยู่ในแคช
เมื่อเห็นผลลัพธ์เหล่านี้ คุณอาจแปลกใจ เพราะท้ายที่สุดแล้ว การดำเนินการอ่านแบบลอจิคัลกับข้อมูลที่บีบอัดนั้นดำเนินการน้อยลงสองเท่า แต่เวลาในการดำเนินการแบบสอบถามนั้นนานขึ้น 36% และประเด็นทั้งหมดดูเหมือนว่าแม้ว่าจะมีการดำเนินการอ่านน้อยลงและทุกอย่างถูกอ่านจากหน่วยความจำ แต่ค่าใช้จ่ายในการแกะข้อมูลก็ยังสูง ท้ายที่สุดแล้ว ไม่ใช่ทั้งหน้าที่ถูกคลายแพ็ก แต่แต่ละบันทึกแยกกัน
สันนิษฐานได้ว่าหากข้อมูลไม่ได้ถูกแคช ในกรณีนี้ ประสิทธิภาพที่เพิ่มขึ้นสามารถทำได้โดยการลดจำนวนการดำเนินการอ่านทางกายภาพที่มีราคาแพงในกรณีของข้อมูลที่ถูกบีบอัด
ดังนั้นจึงมีการตัดสินใจที่จะทำการทดสอบอีกรอบ แต่คราวนี้เป็นแคชเย็น
คำขอทดสอบเดียวกันถูกดำเนินการ แต่ขั้นตอนแคชและบัฟเฟอร์ถูกล้างก่อนโดยใช้คำสั่งDBCC ฟรีโปรแคช และ DBCC DROPCLEANBUFFERS .
นี่คือผลลัพธ์ของคำขอทดสอบก่อนและหลังการบีบอัดบนแคช "เย็น":
1 419 105
1 420 868
235 266
การบีบอัดข้อมูลหน้า
48 887
707 495
710 105
416 689
ผลลัพธ์เหล่านี้ยืนยันสมมติฐานที่ระบุไว้ก่อนหน้านี้ อย่างที่คุณเห็น เวลาดำเนินการแตกต่างกัน 12% แทนที่จะเป็น 36% จากการทดสอบครั้งแรก
สถิติเกี่ยวกับการดำเนินการอ่านเชิงตรรกะจะเหมือนกัน แต่ใน การทดสอบนี้มีการอ่านทางกายภาพซึ่งส่งผลกระทบอย่างมากต่อประสิทธิภาพของแบบสอบถาม (เปรียบเทียบเวลาดำเนินการกับการทดสอบครั้งแรก) และเห็นได้ชัดว่าการบีบอัดข้อมูลจะมีผลในเชิงบวกในแง่ของประสิทธิภาพเมื่อมีการดำเนินการคิวรีกับอาร์เรย์ข้อมูลขนาดใหญ่ที่ไม่ค่อยได้ใช้ซึ่งการบีบอัดจะช่วยให้ประหยัดในการดำเนินงาน การอ่านทางกายภาพ เมื่อเปรียบเทียบกับการคลายแพ็กข้อมูลจากพูลบัฟเฟอร์ซึ่งมีต้นทุนต่ำกว่า เป็นตัวอย่างที่ดีนี่อาจเป็นการบีบอัดพาร์ติชันด้วยข้อมูลในช่วงเวลาแรกสุดในการจัดเก็บข้อมูลหรือการบีบอัดตารางขนาดใหญ่อื่นๆ ที่ไม่ค่อยได้ใช้ ฉันขอเตือนคุณว่าคุณสามารถบีบอัดข้อมูลได้ทั้งในระดับตารางและระดับพาร์ติชันและดัชนี ยิ่งกว่านั้นคุณสามารถรวมประเภทการบีบอัดได้
ฉันจัดการเพื่อให้แน่ใจว่าในตารางทดสอบ การสุ่มตัวอย่างข้อมูลที่บีบอัดเป็นระยะเวลานานเริ่มดำเนินการในระดับเดียวกับการสุ่มตัวอย่างข้อมูลที่ไม่มีการบีบอัดในช่วงเวลาเดียวกันโดยประมาณ นั่นคือ ยิ่งอาร์เรย์ข้อมูลที่เข้าถึงโดยการร้องขอมีขนาดใหญ่เท่าใด ผลเชิงบวกของการบีบอัดก็จะยิ่งมากขึ้นเท่านั้น เนื่องจาก เซิร์ฟเวอร์ต้องติดต่อกับข้อมูลจำนวนมากก่อน ระบบดิสก์และไม่ใช่พูลบัฟเฟอร์
แต่ส่วนใหญ่ เหตุผลหลักสาเหตุที่ประสิทธิภาพการสืบค้นลดลงในกรณีของฉันคืออัตราส่วนการบีบอัดที่ค่อนข้างต่ำ ซึ่งน้อยกว่า 50% ฉันรันการทดสอบเพิ่มเติมและพบว่าตารางที่ถูกบีบอัด 60-75% มีประสิทธิภาพการสืบค้นที่ดีขึ้น เมื่อเทียบกับตารางที่ไม่มีการบีบอัด
แน่นอนว่ายิ่งเปอร์เซ็นต์การบีบอัดสูงเท่าใด ผลกระทบต่อประสิทธิภาพที่เพิ่มขึ้นก็จะยิ่งมากขึ้นเท่านั้น
ไม่ว่าในกรณีใด ก่อนที่จะเริ่มการดำเนินการนี้ จำเป็นต้องทำการทดสอบและประเมินผลของการบีบอัดข้อมูล
เซอร์เกย์ คารีบิน เซิร์ฟเวอร์ MCTS SQL
I) ปัญหาที่เราพยายามแก้ไขด้วยการล่มสลายของฐานข้อมูล
1) การเพิ่มขนาดของฐานข้อมูล
2) ประสิทธิภาพต่ำการดำเนินการตามคำขอ
3) ปริมาณมาก"ข้อมูลที่ไม่จำเป็น" ที่รบกวนประสบการณ์ผู้ใช้
ก) การแบ่งฐานข้อมูลออกเป็นกลุ่มไฟล์
b) การวางฐานข้อมูลหรือส่วนหนึ่งส่วนใดของมัน ไดรฟ์เครือข่าย
c) การบีบอัดตารางฐานข้อมูล
d) การแบ่งพาร์ติชันตารางฐานข้อมูล
2) ปัญหาประสิทธิภาพการสืบค้นที่ไม่ดี
3) ปัญหา “ข้อมูลที่ไม่จำเป็น” จำนวนมากที่รบกวนประสบการณ์ผู้ใช้
ใน สภาพที่ทันสมัยบางครั้งก็แปลกมากที่ได้ยินว่า "เราต้องยุบฐานข้อมูล 1C - ปริมาตรของมันเกิน 50 GB" หากผู้ดูแลระบบ SAP R3 หรือ Oracle e Business Suite หรือแม้แต่ระบบ MS Dynamics Ax กำลังจะทำเช่นนี้ พวกเขาอาจถูกไล่ออก อย่างไรก็ตาม สำหรับ 1C นี่คือ "แนวปฏิบัติมาตรฐาน"
สำหรับ เวอร์ชันไฟล์เรื่องราวย้อนกลับไปในเวอร์ชัน 1C 7.7 โดยจำกัดขนาดฐานข้อมูลไว้ที่ 2GB ขณะนี้ขีดจำกัด 2GB อยู่ที่ขนาดตารางเท่านั้น ขนาดไฟล์อาจเล็กมากแล้ว จริงอยู่หากฐานข้อมูลของคุณขยายไปถึงขนาดนี้ก็แสดงว่าข้อมูลอาจถูกป้อนเข้าไปที่นั่น - บางทีคุณอาจต้องคิดถึงไคลเอนต์ - เซิร์ฟเวอร์?
จริงๆ แล้ว จุดประสงค์ของบทความนี้คือการ "ห้าม" ผู้ใช้จากการดำเนินการรวบรวมฐานข้อมูล เวอร์ชันไคลเอ็นต์-เซิร์ฟเวอร์ 1C เนื่องจากการใช้เทคโนโลยี "ขั้นสูง" ที่ค่อนข้างมากกว่า
I) ปัญหาที่เราพยายามแก้ไขด้วยการล่มสลายของฐานข้อมูล
1) การเพิ่มขนาดของฐานข้อมูล
จริงๆ แล้ว คำถามหลัก: ทำไมต้องลดขนาดฐานข้อมูล?
ลองใช้คณิตศาสตร์กันหน่อย:
เซิร์ฟเวอร์ ฮาร์ดไดรฟ์สำหรับ 500 GB มีราคาประมาณ 10,000 รูเบิล หากต้องการรวมเข้ากับ RAID 1 เพื่อความน่าเชื่อถือจะเป็น 20,000 รูเบิล
ตามธรรมชาติแล้วอาจมีปัญหาเรื่องการไม่มีพื้นที่สำหรับสิ่งใหม่ ฮาร์ดไดรฟ์ในเซิร์ฟเวอร์นั่นเอง...
แต่การซื้อดิสก์อาร์เรย์ภายนอกจะไม่ถูกนัก จะทำอย่างไร?
ใช่ทุกอย่างง่าย - วางไฟล์ฐานข้อมูลลงในไดรฟ์เครือข่าย แต่ทำอย่างไร? ข้อมูลเพิ่มเติมเกี่ยวกับบทความนี้ในภายหลัง
การเพิ่มพื้นที่ดิสก์สำหรับฐานข้อมูลจะทำให้เราต้องเสียเงิน 20,000 รูเบิล + 10 นาทีของงานผู้เชี่ยวชาญ ต้องใช้ผู้เชี่ยวชาญกี่ชั่วโมงในการสะสมฐานข้อมูล สามารถมีเวลาหยุดทำงานได้มากเพียงใด? ตามการประมาณการแบบอนุรักษ์นิยมที่สุดสำหรับการบิด UPP ที่มีปริมาณ 60 กิกะไบต์โดยมีจำนวนข้อผิดพลาดโดยเฉลี่ยการบัญชีแบทช์พร้อมการตรวจสอบผลลัพธ์ของการบิดการแก้ไขการบัญชีแบทช์เดียวกันจะมีราคา 30-40,000 .
การประมวลผลแบบสากลไม่น่าจะยุบทุกอย่างในคราวเดียว โดยเฉพาะอย่างยิ่งหากฐานของคุณ "ไม่เคยหยุดนิ่ง" การบัญชีพรรคควรได้รับการแก้ไขทุกกรณี โดยทั่วไปมีงานมากมายที่นั่น และที่สำคัญที่สุดคือการตรวจสอบขั้นสุดท้ายจะต้องละเอียดถี่ถ้วนและยังจะมีข้อผิดพลาดเกิดขึ้น...
นอกจากนี้หากฐานข้อมูลไม่มีขนาด 60 GB อีกต่อไป แต่เช่น 120 GB... ข้อผิดพลาดเพียงเล็กน้อยในรหัส 1C ระหว่างการบิดและนั่นคือทั้งหมด... ขั้นตอนจะสิ้นสุดลงไม่สำเร็จ และจะมีข้อผิดพลาดเกิดขึ้นอย่างแน่นอน เช่นเดียวกับ “หน่วยความจำไม่เพียงพอ” เมื่อทำงานกับข้อกำหนดทางเทคนิค และข้อผิดพลาดเช่น
ตัวเลขสุดท้ายคือ 30-40 ตันเทียบกับขั้นต่ำ 20-25 ตัน ช้อปปิ้งอย่างหนักดิสก์ และรับพื้นที่เพิ่มเติม 500 GB
นั่นเป็นสาเหตุที่ผลิตภัณฑ์เช่น [คุณต้องลงทะเบียนเพื่อดูลิงก์] จึงปรากฏขึ้น
พวกเขาอาจเป็นผลิตภัณฑ์ที่ดีและบรรลุเป้าหมาย เพียงแต่ว่าโครงสร้างของตารางเปลี่ยนจากเวอร์ชันหนึ่งไปอีกเวอร์ชันของแพลตฟอร์ม 1C บอกเราเกี่ยวกับเรื่องนี้มากกว่าหนึ่งครั้ง ตัวแยกข้อมูลปรากฏในรุ่นที่ 14 และนั่นก็คือ... เป็นไปได้มากว่าการประมวลผลนี้จะไม่เหมาะกับรุ่นที่ 14 อีกต่อไป และมันก็น่ากลัวไม่ต้องพูดถึงการละเมิดข้อตกลงใบอนุญาตด้วย
และแม้หลังจากนี้ ก็จะมีผู้ใช้ที่ "ต้องการอย่างกะทันหันโดยกะทันหัน" ลบข้อมูล ซึ่ง "เพียงต้องการแก้ไข" ตัวเลขบางส่วนที่ "ไม่ส่งผลกระทบต่อลำดับ" ในเอกสารในช่วงเวลาปิด และจะแย่กว่านั้นถ้าปรากฎว่ามีคนดูเอกสารเหล่านี้อยู่ตลอดเวลาเพื่อจุดประสงค์บางอย่างที่เขารู้เท่านั้น แน่นอนว่าทั้งหมดนี้เป็นเพียงข้อผิดพลาดในวิธีการใช้งาน แต่อย่างไรก็ตาม ผู้ใช้ก็อาจเกิดความไม่พอใจได้
2) ประสิทธิภาพการสืบค้นต่ำ
ใครบอกคุณว่า “ยิ่งเล็กยิ่งเร็ว”? สำหรับ IS ที่พัฒนาอย่างถูกต้อง ข้อความนี้ไม่เป็นความจริง
ภาพด้านล่างสั้นๆ และแสดงให้เห็น “ในภาษาของนก” ตัวอย่างที่ง่ายที่สุดการเลือกตามดัชนีประเภท B-Tree ของรายการในตารางที่อยู่:
ฉันไม่ต้องการเจาะลึกหัวข้อดัชนีโดยเฉพาะอย่างยิ่งเมื่อทุกอย่างค่อนข้างซับซ้อนกว่านั้น สิ่งที่สำคัญที่สุดคือการค้นหาไม่ได้เกิดขึ้น "แนวนอน" ทั่วทั้งตาราง แต่เกิดขึ้น "แนวตั้ง" ทั่วทั้ง "ระดับ" ของดัชนี
การเปรียบเทียบ - สมุดบันทึก: แต่ละหน้าเริ่มต้นด้วยตัวอักษรของตัวเอง เฉพาะในแต่ละหน้าเท่านั้นที่จะมีสมุดบันทึกเดียวกันซึ่งคุณสามารถเลือกตัวอักษรตัวที่สองในคำได้และต่อไปเรื่อย ๆ จนกว่าคุณจะเจอหน้าที่จะมีหนึ่งรายการขึ้นไป สะดวกสบาย? แน่นอนว่าจะสะดวกถ้าคุณมีผู้ติดต่อมากกว่าร้อยราย แล้วถ้าคุณมีแค่สิบอันล่ะ? มันไม่ง่ายกว่าหรือที่จะเขียนมันลงบนกระดาษแผ่นเดียวที่คุณสามารถมองด้วยตาเปล่าได้? เช่นเดียวกับดัชนี จะมีประสิทธิภาพหากมีหลายพันบันทึกในตาราง แต่ถ้ามีเพียงรายการเดียวจะไม่มีประสิทธิภาพมากนัก โชคดีที่ DBMS ได้เรียนรู้ที่จะเลือก “แผนการสืบค้น” อย่างอิสระ และตัดสินใจว่าจะใช้ดัชนีนี้หรือดัชนีนั้นหรือไม่ แต่ในกรณีของการ "นำ" แถวทั้งหมดของตารางโดยไม่มีดัชนี DBMS มักจะล็อกทั้งตารางนี้ และคุณสังเกตเห็น "การล็อกที่มาจากอย่างอธิบายไม่ได้" หลังจากที่ความปลอดภัยของข้อมูลล่มสลาย
เรามักจะยุบตารางยอดคงเหลือ ในตารางยอดคงเหลือ ฟิลด์แรกในดัชนีทั้งหมดจะเป็นช่วงเวลา นั่นคือสำหรับการร้องขอใด ๆ จริง ๆ แล้ว ระดับบนดัชนี ยอดคงเหลือที่คำนวณได้สำหรับระยะเวลาที่ต้องการจะถูกเลือกไว้แล้ว ดังนั้น การล่มสลายของฐานข้อมูลจะมีผลกระทบน้อยที่สุดต่อการสืบค้นยอดดุล ฉันขอย้ำอีกครั้งเมื่อใด องค์กรที่เหมาะสมระบบ
ขั้นแรกให้ส่งจดหมายข่าวถึงผู้ใช้ของคุณเกี่ยวกับเรื่องนี้ และคุณจะได้รับข้อความมากมายว่า “ข้อมูลไม่เคยไม่จำเป็น” อย่างไรก็ตาม หลายคนไม่ชอบที่จะ "ดูเอกสารทางประวัติศาสตร์" และ "ข้อมูลที่เก็บถาวร" แต่ไม่มีใครเห็นด้วยกับพวกเขา แต่การปรองดองช่วยแก้ปัญหาเหล่านี้ได้หรือไม่? มันจะลบรายการที่ไม่จำเป็นออกจากไดเร็กทอรีระบบการตั้งชื่อหรือไม่? คู่ค้าที่คุณจะไม่ทำงานอีกต่อไป? และดังที่แบบฝึกหัดแสดงให้เห็น นี่คือจุดที่ปัญหาส่วนใหญ่อยู่
II) การแก้ปัญหาด้วย "เทคโนโลยี"
1) ปัญหาการเพิ่มขนาดของฐานข้อมูล
ก) แบ่งฐานข้อมูลออกเป็นกลุ่มไฟล์
เปิด Management Studio ในรายการฐานข้อมูล เลือกฐานข้อมูลที่คุณต้องการ เปิดคุณสมบัติ
- ไปที่แท็บ “กลุ่มไฟล์” ดังแสดงในรูป และเพิ่มกลุ่มไฟล์อื่น (ในตัวอย่างนี้เรียกว่า SECONDARY
ไปที่แท็บ "ไฟล์" และเพิ่ม ไฟล์ใหม่ซึ่งเราเลือกกลุ่มไฟล์ที่สร้างขึ้น ไฟล์นี้ สามารถอยู่ในดิสก์อื่นได้
ตอนนี้ใช้การประมวลผลเช่น: http://infostart.ru/public/78049/ เรากำหนดว่าตารางใดที่เราสามารถ "บริจาค" ได้อย่างปลอดภัยให้กับสื่อที่ช้ากว่า (หรือในทางกลับกัน ทุกอย่างให้ช้าลง ส่วนที่เหลือเป็นสื่อที่เร็วกว่า) กฎ 80/20 ใช้ที่นี่ 80% ของการดำเนินงานดำเนินการโดยใช้ข้อมูล 20% ดังนั้นลองพิจารณาว่าเพลตใดที่คุณต้องการอย่างรวดเร็วและเพลตใดที่ไม่มากนัก "พื้นที่จัดเก็บ" ข้อมูลเพิ่มเติม" เอกสารสำหรับการเข้าสู่ยอดคงเหลือเริ่มต้น เอกสารที่คุณไม่ได้ใช้อีกต่อไป ให้ระบุทันทีว่าเป็นเอกสารที่สามารถถ่ายโอนไปยังกลุ่มไฟล์ "ช้า"
เลือกตารางที่ต้องการย้ายไปยังกลุ่มไฟล์อื่น - เลือกเมนูสำหรับเปลี่ยนตาราง (โครงการ) และเปลี่ยนกลุ่มไฟล์ในคุณสมบัติ:
ดัชนีตารางจะถูกโอนไปยังกลุ่มไฟล์นี้ด้วย
กลไกที่ค่อนข้างสะดวกในการกระจายตารางไปทั่ว ดิสก์อาร์เรย์ ความเร็วที่แตกต่างกัน. ข้อตกลงใบอนุญาตสิ่งนี้ไม่ขัดแย้งเพราะว่า ในการแก้ปัญหาเราไม่ได้ใช้การเข้าถึงข้อมูลและ ฐานข้อมูลโดยวิธีการอื่นนอกเหนือจากแพลตฟอร์ม 1C เราจัดระเบียบการจัดเก็บข้อมูลนี้ในวิธีที่สะดวกเท่านั้น
b) บันทึกฐานข้อมูลบนไดรฟ์เครือข่าย
ดีบีซีซี เทรซออน (1807)
เราเขียน คำสั่งนี้ใน Management Studio เราดำเนินการและสามารถสร้างฐานข้อมูลผ่านเครือข่ายได้สำเร็จ แน่นอนว่ากรณีนี้ เซิร์ฟเวอร์ SQLจะต้องเปิดตัวในนามของโดเมน บัญชีและรายการนี้จะต้องมีสิทธิ์ตามที่ต้องการ โฟลเดอร์เครือข่าย.
แต่โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเมื่อใช้คำสั่งนี้ หากเครือข่ายของคุณล่มขณะทำงานกับฐานข้อมูล ฐานข้อมูลทั้งหมดจะไม่สามารถเข้าถึงได้ในระหว่างที่ฐานข้อมูลหายไป ไม่ใช่เพื่อสิ่งใดที่ Microsoft ปิดโอกาสนี้เพื่อการใช้งานจำนวนมาก โดยทั่วไปความเป็นไปได้นี้มีวัตถุประสงค์เพื่อสร้างฐานข้อมูลบน อุปกรณ์จัดเก็บข้อมูล NASซึ่งฉันขอแนะนำอย่างยิ่ง เหมาะสมตามความมั่นคงและเชื่อถือได้ ไฟล์เซิร์ฟเวอร์มี การเชื่อมต่อโดยตรงไปยังเซิร์ฟเวอร์ที่ใช้ MS SQL DBMS
คุณสามารถอ่านเพิ่มเติมเกี่ยวกับแฟล็กการติดตามอื่น ๆ ได้ในบทความ [คุณต้องลงทะเบียนเพื่อดูลิงก์]
เหล่านั้น. ส่วนหนึ่งของกลุ่มไฟล์สามารถจัดเก็บบนเครือข่ายได้และสามารถขยายพื้นที่ดิสก์ได้โดยไม่มีปัญหา
c) การบีบอัดตารางฐานข้อมูล
EXEC sp_MSforeachtable "แก้ไขดัชนีทั้งหมดบนหรือไม่ สร้างใหม่ด้วย (DATA_COMPRESSION = PAGE)" ไป
หลังจากรันโค้ดนี้แล้ว ตารางทั้งหมดในฐานข้อมูลจะถูกบีบอัด แน่นอนว่าคุณสามารถบีบอัดตารางทีละตารางได้... เป็นทางเลือกของคุณ การบีบอัดทำอะไร?
- ประหยัดพื้นที่ดิสก์
- ลดภาระในการ ระบบย่อยของดิสก์
กำลังบริโภคอะไรอยู่? - เวลาซีพียู
ดังนั้นหากโปรเซสเซอร์ของคุณโหลดที่ 70% หรือสูงกว่าตลอดเวลา คุณจะไม่สามารถใช้การบีบอัดได้ หากโหลดตัวประมวลผลอยู่ที่ 20-30% และคิวดิสก์เพิ่มขึ้นเป็น 3-4... การบีบอัดตารางก็เป็นเพียง "วิธีแก้ไข" สำหรับคุณ เรียนรู้เพิ่มเติมเกี่ยวกับการบีบอัดตารางฐานข้อมูล - [คุณต้องลงทะเบียนเพื่อดูลิงก์นี้]
หมายเหตุสำคัญ- ฟังก์ชั่นการบีบอัดตารางมีให้สำหรับเจ้าของ SQL Server เวอร์ชัน Enterprise เท่านั้น
d) การแบ่งพาร์ติชันตารางฐานข้อมูล
แน่นอนว่า การแบ่งตารางออกเป็นกลุ่มไฟล์ต่างๆ เป็นเรื่องดี...แต่คุณจะบอกว่ามีตารางสองสามตารางที่นี่...ซึ่งดำเนินมาตั้งแต่ปี 2548... และใช้พื้นที่ไปแล้วหลายสิบกิกะไบต์.. ฉันหวังว่าพวกเขาจะมีข้อมูลทั้งหมดอยู่ในนั้นและใส่ดิสก์แยกต่างหาก แต่คงเหลือดิสก์ปัจจุบันไว้
คุณจะไม่เชื่อ แต่ก็เป็นไปได้เช่นกันแม้ว่าจะไม่ง่ายนัก:
สร้างฟังก์ชันสำหรับการแบ่งพาร์ติชันตามวันที่:
สร้างฟังก์ชันพาร์ติชัน YearSection (วันที่และเวลา)
เป็นช่วงที่เหมาะสมสำหรับค่า ("20110101");
ทุกอย่างก่อนปี 2011 จะแบ่งออกเป็นส่วนเดียว ทุกอย่างหลังจากนั้นจะรวมเป็นอีกส่วนหนึ่ง
- สร้างรูปแบบการแบ่งพาร์ติชัน
สร้างแผนพาร์ติชัน YearScheme
เป็นพาร์ติชัน YearSection ถึง (SECONDARY, PRIMARY);
จากนี้เราบอกว่าข้อมูลทั้งหมดจนถึงปีที่ 11 จะจบลงในกลุ่มไฟล์ "รอง" และหลังจากนั้น - ในกลุ่ม "หลัก"
ตอนนี้สิ่งที่เหลืออยู่คือสร้างตารางใหม่โดยแบ่งออกเป็นส่วนต่างๆ วิธีที่ง่ายที่สุดในการทำเช่นนี้คือการใช้ สตูดิโอการจัดการเพราะกระบวนการมันไม่ง่ายเลย คุณต้องสร้างดัชนีคลัสเตอร์บนตารางใหม่ (ซึ่งโดยพื้นฐานแล้วคือตัวตารางเอง) โดยเลือกโครงร่างพาร์ติชันที่สร้างขึ้นสำหรับดัชนี:
ในรูปที่คุณเห็นว่าไม่มีตัวเลือก - ทุกอย่างถูกต้อง การแบ่งพาร์ติชันตารางทำได้เฉพาะใน MS SQL Server เวอร์ชัน Enterprise เท่านั้น ดัชนีคลัสเตอร์แยกแยะได้ง่าย - รูปภาพที่มีวงเล็บ มันถูกสร้างขึ้นสำหรับ RN และวัตถุ 1C ทั้งหมด สำหรับ RN จะมีดัชนีคลัสเตอร์ตามช่วงเวลาเสมอ สำหรับเอกสารและไดเร็กทอรี แน่นอนว่าจะสร้างอีกอันที่มีรายละเอียดที่จะใช้ในการแบ่งส่วน... แต่นี่จะเป็นการละเมิดข้อตกลงใบอนุญาตอยู่แล้ว
2) ประสิทธิภาพการสืบค้นต่ำ
การกระทำทั้งหมดที่อธิบายไว้ข้างต้นไม่ควรส่งผลต่อความเร็วของการดำเนินการคำสั่งพื้นฐาน นอกจากนี้ การใช้กลุ่มไฟล์และส่วนของตารางจะช่วยให้คุณสามารถวางข้อมูลที่ใช้บ่อยที่สุดบนดิสก์อาร์เรย์ที่รวดเร็ว ช่วยให้คุณสามารถเปลี่ยนการกำหนดค่าของดิสก์อาร์เรย์ และใช้ตัวเร่งความเร็ว i/o ขนาดเล็กได้ สิ่งนี้จะเพิ่มความเร็วของการดำเนินการค้นหาเท่านั้น และการบีบอัดตารางจะช่วยให้คุณสามารถบรรเทาระบบย่อยของดิสก์เพิ่มเติมได้หากเป็นปัญหาคอขวด โดยทั่วไป ถ้าเราพูดถึงความเร็วของการดำเนินการค้นหา การวิเคราะห์แผนการดำเนินการและเพิ่มประสิทธิภาพการสืบค้นสำหรับการใช้ดัชนีอย่างเหมาะสมจะทำให้ประสิทธิภาพเพิ่มขึ้นอย่างมีนัยสำคัญมากกว่า "เทคนิค" ทั้งหมดในระดับ MS SQL
3) “ข้อมูลที่ไม่จำเป็น” จำนวนมากที่รบกวนประสบการณ์ผู้ใช้
แต่ในการทำเช่นนี้ คุณไม่จำเป็นต้องยุบฐานข้อมูล แต่ให้ทำดังต่อไปนี้:
ก) อธิบายให้ทุกคนทราบถึงวิธีการใช้ตัวเลือก วิธีบันทึก วิธีใช้ช่วงเวลาบันทึก วิธีบันทึก
b) ทำเครื่องหมายข้อมูลที่ไม่จำเป็นสำหรับการลบหากไม่มีความหมายเชิงความหมาย (คู่สัญญาและรายการที่คุณไม่ได้ทำงานอีกต่อไป) - สิ่งนี้จะทำให้ผู้ใช้ ได้รับประโยชน์มากขึ้นกว่ามัด หากมีทรัพยากร ให้ตั้งค่าการทำเครื่องหมายอัตโนมัติสำหรับการลบออบเจ็กต์ที่ไม่ได้ใช้ และทำการเลือกเริ่มต้น รหัสโปรแกรมเพื่อไม่ให้แสดงเป็นค่าเริ่มต้น จำเป็นโดยผู้ใช้วัตถุ - ทำเครื่องหมายเพื่อลบ
c) ตั้งค่า "การเลือกเริ่มต้น" ที่เป็นประโยชน์อื่นๆ - ตัวอย่างเช่น เพื่อให้ผู้จัดการแต่ละคนเห็นเฉพาะเอกสารของตนเองตามค่าเริ่มต้น และถ้าเขาต้องการดูเอกสารของ “สหาย” เขาก็ต้องปิดการเลือก
สำหรับรายละเอียดทั้งหมดที่มีส่วนร่วมในการเลือกอย่าลืมทำเครื่องหมายที่ช่อง "ดัชนีพร้อมลำดับเพิ่มเติม" จากนั้น "ความสะดวก" ดังกล่าวจะไม่ส่งผลกระทบต่อประสิทธิภาพของระบบ
แท็ก: 1C, การเพิ่มประสิทธิภาพ 1C, sql, การบริหาร 1C, การฝึกอบรม, การเขียนโปรแกรม, เทคโนโลยี
[คุณต้องลงทะเบียนเพื่อดูลิงค์]
ในสภาวะปัจจุบัน บางครั้งก็เป็นเรื่องแปลกมากที่ได้ยินว่า "เราจำเป็นต้องยุบฐานข้อมูล 1C - ปริมาตรของมันเกิน 50 GB" หากผู้ดูแลระบบ SAP R3 หรือ Oracle e Business Suite หรือแม้แต่ระบบ MS Dynamics Ax กำลังจะทำเช่นนี้ พวกเขาอาจถูกไล่ออก อย่างไรก็ตาม สำหรับ 1C นี่คือ "แนวปฏิบัติมาตรฐาน"
สำหรับเวอร์ชันไฟล์ เรื่องราวจะย้อนกลับไปเป็นเวอร์ชัน 1C 7.7 โดยจำกัดขนาดฐานข้อมูลไว้ที่ 2GB ขณะนี้ขีดจำกัด 2GB อยู่ที่ขนาดตารางเท่านั้น ขนาดไฟล์อาจเล็กมากแล้ว จริงอยู่หากฐานข้อมูลของคุณขยายไปถึงขนาดนี้ก็แสดงว่าข้อมูลอาจถูกป้อนเข้าไปที่นั่น - บางทีคุณอาจต้องคิดถึงไคลเอนต์ - เซิร์ฟเวอร์?
ที่จริงแล้วจุดประสงค์ของบทความนี้คือเพื่อ "ห้าม" ผู้ใช้ 1C เวอร์ชันไคลเอ็นต์ - เซิร์ฟเวอร์จากการดำเนินการรวบรวมฐานข้อมูลผ่านการใช้เทคโนโลยี "ขั้นสูง" ที่ค่อนข้างมากกว่า
ตัวเลขสุดท้ายคือ 30-40 ตัน ขั้นต่ำเทียบกับ 20-25 ตันในกรณีที่ซื้อ ฮาร์ดไดรฟ์และรับพื้นที่เพิ่ม 500 GB
นั่นเป็นเหตุผลที่ผลิตภัณฑ์เช่น
พวกเขาอาจเป็นผลิตภัณฑ์ที่ดีและบรรลุเป้าหมาย เพียงแต่ว่าโครงสร้างของตารางเปลี่ยนจากเวอร์ชันหนึ่งไปอีกเวอร์ชันของแพลตฟอร์ม 1C บอกเราเกี่ยวกับเรื่องนี้มากกว่าหนึ่งครั้ง ตัวแยกข้อมูลปรากฏในรุ่นที่ 14 และนั่นก็คือ... เป็นไปได้มากว่าการประมวลผลนี้จะไม่เหมาะกับรุ่นที่ 14 อีกต่อไป และมันก็น่ากลัวไม่ต้องพูดถึงการละเมิดข้อตกลงใบอนุญาตด้วย
และแม้หลังจากนี้ ก็จะมีผู้ใช้ที่ "ต้องการอย่างกะทันหันโดยกะทันหัน" ลบข้อมูล ซึ่ง "เพียงต้องการแก้ไข" ตัวเลขบางส่วนที่ "ไม่ส่งผลกระทบต่อลำดับ" ในเอกสารในช่วงเวลาปิด และจะแย่กว่านั้นถ้าปรากฎว่ามีคนดูเอกสารเหล่านี้อยู่ตลอดเวลาเพื่อจุดประสงค์บางอย่างที่เขารู้เท่านั้น แน่นอนว่าทั้งหมดนี้เป็นเพียงข้อผิดพลาดในวิธีการใช้งาน แต่อย่างไรก็ตาม ผู้ใช้ก็อาจเกิดความไม่พอใจได้
-
เปิด Management Studio ในรายการฐานข้อมูล เลือกฐานข้อมูลที่คุณต้องการ เปิดคุณสมบัติ
- ไปที่แท็บ “กลุ่มไฟล์” ดังแสดงในรูป และเพิ่มกลุ่มไฟล์อื่น (ในตัวอย่างเรียกว่า SECONDARY)
- ไปที่แท็บ "ไฟล์" และเพิ่มไฟล์ใหม่ซึ่งเราเลือกกลุ่มไฟล์ที่สร้างขึ้น ไฟล์นี้ สามารถอยู่ในดิสก์อื่นได้
-
ในตอนนี้ โดยใช้การประมวลผล เช่น เรากำหนดว่าตารางใดที่เราสามารถ "บริจาค" ได้อย่างปลอดภัยให้กับอาหารที่ช้ากว่า (หรือกลับกัน ทุกอย่างให้ช้าลง ส่วนที่เหลือไปยังสื่อที่เร็วกว่า) กฎ 80/20 ใช้ที่นี่ 80% ของการดำเนินงานดำเนินการโดยใช้ข้อมูล 20% ดังนั้นลองพิจารณาว่าเพลตใดที่คุณต้องการอย่างรวดเร็วและเพลตใดที่ไม่มากนัก “การจัดเก็บข้อมูลเพิ่มเติม” เอกสารสำหรับการเข้าสู่ยอดคงเหลือเริ่มต้น เอกสารที่คุณไม่ได้ใช้อีกต่อไป ระบุทันทีว่าเป็นเอกสารที่สามารถถ่ายโอนไปยังกลุ่มไฟล์ที่ "ช้า"
เลือกตารางที่ต้องการย้ายไปยังกลุ่มไฟล์อื่น - เลือกเมนูสำหรับเปลี่ยนตาราง (โครงการ) และเปลี่ยนกลุ่มไฟล์ในคุณสมบัติ:
ดัชนีตารางจะถูกโอนไปยังกลุ่มไฟล์นี้ด้วย
กลไกที่ค่อนข้างสะดวกในการกระจายตารางผ่านดิสก์อาร์เรย์ที่มีความเร็วต่างกัน ซึ่งไม่ขัดแย้งกับข้อตกลงใบอนุญาตเพราะว่า ในการแก้ปัญหา เราไม่ใช้การเข้าถึงข้อมูลและฐานข้อมูลด้วยวิธีอื่นนอกเหนือจากแพลตฟอร์ม 1C เราจัดระเบียบการจัดเก็บข้อมูลนี้ในวิธีที่สะดวกเท่านั้น
ดีบีซีซี เทรซออน (1807)
เราเขียนคำสั่งนี้ใน Management Studio ดำเนินการและสามารถสร้างฐานข้อมูลผ่านเครือข่ายได้สำเร็จ แน่นอนว่าต้องเปิดใช้งานอินสแตนซ์ SQL Server ภายใต้บัญชีโดเมนและบัญชีนี้ต้องมีสิทธิ์ในโฟลเดอร์เครือข่ายที่ต้องการ
แต่โปรดใช้ความระมัดระวังเป็นอย่างยิ่งเมื่อใช้คำสั่งนี้ หากเครือข่ายของคุณล่มขณะทำงานกับฐานข้อมูล ฐานข้อมูลทั้งหมดจะไม่สามารถเข้าถึงได้ในระหว่างที่ฐานข้อมูลหายไป ไม่ใช่เพื่อสิ่งใดที่ Microsoft ปิดโอกาสนี้เพื่อการใช้งานจำนวนมาก โดยทั่วไปแล้ว คุณสมบัตินี้มีไว้สำหรับการสร้างฐานข้อมูลบนที่จัดเก็บข้อมูล NAS ซึ่งฉันขอแนะนำอย่างยิ่ง ไฟล์เซิร์ฟเวอร์ที่เสถียรและเชื่อถือได้ซึ่งมีการเชื่อมต่อโดยตรงกับเซิร์ฟเวอร์ที่ใช้ MS SQL DBMS ก็เหมาะสมเช่นกัน
คุณสามารถอ่านเพิ่มเติมเกี่ยวกับแฟล็กการติดตามอื่นๆ ได้ในบทความ http://msdn.microsoft.com/ru-ru/library/ms188396.aspx
เหล่านั้น. ส่วนหนึ่งของกลุ่มไฟล์สามารถจัดเก็บบนเครือข่ายได้และสามารถขยายพื้นที่ดิสก์ได้โดยไม่มีปัญหา
แน่นอนว่า การแบ่งตารางออกเป็นกลุ่มไฟล์ต่างๆ เป็นเรื่องดี...แต่คุณจะบอกว่ามีตารางสองสามตารางที่นี่...ซึ่งดำเนินมาตั้งแต่ปี 2548... และใช้พื้นที่ไปแล้วหลายสิบกิกะไบต์.. ฉันหวังว่าพวกเขาจะมีข้อมูลทั้งหมดอยู่ในนั้นและใส่ดิสก์แยกต่างหาก แต่คงเหลือดิสก์ปัจจุบันไว้
คุณจะไม่เชื่อ แต่ก็เป็นไปได้เช่นกันแม้ว่าจะไม่ง่ายนัก:
สร้างฟังก์ชันสำหรับการแบ่งพาร์ติชันตามวันที่:
สร้างฟังก์ชันพาร์ติชัน YearSection (วันที่และเวลา)
เป็นช่วงที่เหมาะสมสำหรับค่า ("20110101");
ทุกอย่างก่อนปี 2011 จะแบ่งออกเป็นส่วนเดียว ทุกอย่างหลังจากนั้นจะรวมเป็นอีกส่วนหนึ่ง
การสร้างโครงร่างการแบ่งพาร์ติชัน
สร้างแผนพาร์ติชัน YearScheme
เป็นพาร์ติชัน YearSection ถึง (SECONDARY, PRIMARY);
จากนี้เราบอกว่าข้อมูลทั้งหมดจนถึงปีที่ 11 จะจบลงในกลุ่มไฟล์ "รอง" และหลังจากนั้น - ในกลุ่ม "หลัก"
ตอนนี้สิ่งที่เหลืออยู่คือสร้างตารางใหม่โดยแบ่งออกเป็นส่วนต่างๆ วิธีที่ง่ายที่สุดในการทำเช่นนี้คือการใช้สตูดิโอการจัดการ เนื่องจากกระบวนการนี้ไม่ง่าย คุณต้องสร้างดัชนีคลัสเตอร์บนตารางใหม่ (ซึ่งโดยพื้นฐานแล้วคือตัวตารางเอง) โดยเลือกโครงร่างพาร์ติชันที่สร้างขึ้นสำหรับดัชนี:
ในภาพคุณเห็นว่าไม่มีตัวเลือก - ทุกอย่างถูกต้อง การแบ่งพาร์ติชันตารางสามารถทำได้ใน MS SQL Server เวอร์ชัน Enterprise เท่านั้น- ดัชนีคลัสเตอร์แยกแยะได้ง่าย - รูปภาพที่มีวงเล็บ มันถูกสร้างขึ้นสำหรับ RN และวัตถุ 1C ทั้งหมด สำหรับ RN จะมีดัชนีคลัสเตอร์ตามช่วงเวลาเสมอ สำหรับเอกสารและไดเร็กทอรี แน่นอนว่าจะสร้างอีกอันที่มีรายละเอียดที่จะใช้ในการแบ่งส่วน... แต่นี่จะเป็นการละเมิดข้อตกลงใบอนุญาตอยู่แล้ว
แต่ในการทำเช่นนี้ คุณไม่จำเป็นต้องยุบฐานข้อมูล แต่ให้ทำดังต่อไปนี้:
ก) อธิบายให้ทุกคนทราบถึงวิธีการใช้ตัวเลือก วิธีบันทึก วิธีใช้ช่วงเวลาบันทึก วิธีบันทึก
b) ทำเครื่องหมายข้อมูลที่ไม่จำเป็นสำหรับการลบหากไม่มีความหมายใด ๆ (คู่สัญญาและรายการที่คุณไม่ได้ทำงานด้วยอีกต่อไป) - สิ่งนี้จะเป็นประโยชน์ต่อผู้ใช้มากกว่าการลดลง หากมีทรัพยากร ให้ตั้งค่าการทำเครื่องหมายอัตโนมัติสำหรับการลบวัตถุที่ไม่ได้ใช้ และทำการเลือกเริ่มต้นในโค้ดโปรแกรม เพื่อให้วัตถุที่ผู้ใช้ไม่ต้องการ - วัตถุที่ทำเครื่องหมายไว้สำหรับการลบ - จะไม่แสดงตามค่าเริ่มต้น
c) ตั้งค่า "การเลือกเริ่มต้น" ที่เป็นประโยชน์อื่นๆ - ตัวอย่างเช่น เพื่อให้ผู้จัดการแต่ละคนเห็นเฉพาะเอกสารของตนเองตามค่าเริ่มต้น และถ้าเขาต้องการดูเอกสารของ “สหาย” เขาก็ต้องปิดการเลือก
สำหรับรายละเอียดทั้งหมดที่มีส่วนร่วมในการเลือกอย่าลืมทำเครื่องหมายที่ช่อง "ดัชนีพร้อมลำดับเพิ่มเติม" จากนั้น "ความสะดวก" ดังกล่าวจะไม่ส่งผลกระทบต่อประสิทธิภาพของระบบ
