การปรับประสิทธิภาพของฐานข้อมูล

การปรับประสิทธิภาพฐานข้อมูลของคุณเป็นกิจกรรมทั่วไปและที่สำคัญที่สุดอย่างหนึ่งที่ผู้ดูแลระบบฐานข้อมูล (DBA) ทุกคนต้องดำเนินการอย่างต่อเนื่องและสม่ำเสมอ ผู้เชี่ยวชาญแนะนำให้คุณปรับแต่งฐานข้อมูลอย่างสม่ำเสมอเพื่อเพิ่มประสิทธิภาพ การปรับแต่งอย่างละเอียดจะช่วยให้ผู้ใช้เรียกใช้รายงานและคิวรีได้รวดเร็วขึ้นและได้ผลลัพธ์เร็วขึ้น โพสต์นี้แชร์เทคนิคในการแก้ปัญหาและปรับแต่งฐานข้อมูล Oracle®

ขั้นตอนการจูน

ในการเริ่มต้น คุณต้องระบุพื้นที่ที่เกิดปัญหา พื้นที่ที่เป็นไปได้ที่อาจก่อให้เกิดปัญหา ได้แก่ ระบบปฏิบัติการ ฐานข้อมูล หน่วยความจำไม่เพียงพอ และอื่นๆ หลังจากที่คุณระบุพื้นที่ที่มีปัญหาแล้ว คุณสามารถดำเนินการปรับพื้นที่เพื่อประโยชน์สูงสุด บล็อกนี้เน้นเฉพาะการปรับแต่งประสิทธิภาพเท่านั้น

Oracle ได้มอบเครื่องมือบางอย่างให้กับ DBA เพื่อช่วยในการวินิจฉัยปัญหาและแก้ไขปัญหาด้านประสิทธิภาพ เครื่องมือเหล่านี้รวมถึงรายงาน Automatic DatabaseDiagnostic Monitor (ADDM) และรายงาน Automatic Workload Repository (AWR) ซึ่งคุณสามารถสร้างสำหรับช่วงเวลาที่มีปัญหาและใช้ในการวิเคราะห์ของคุณ คุณควรใช้เครื่องมือเพื่อค้นหาส่วนประกอบที่เอียงหรือปรับได้

เหตุการณ์ที่มีกำหนดเวลาสูงสุดในรายงาน AWR

AWR เป็นเครื่องมือที่คุณสามารถสร้างรายงานที่สรุปการใช้หน่วยความจำในรูปแบบสถิติโดยอินสแตนซ์เฉพาะ ในการสร้างรายงาน AWR ให้เรียกใช้ไฟล์ต่อไปนี้ในพรอมต์ sqlplus:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

สิ่งนี้จะสร้างรายงาน AWR ในรูปแบบ HTML โดยใช้เทมเพลตที่จัดเก็บไว้ล่วงหน้า หลังจากที่คุณสร้างรายงาน AWR แล้ว คุณสามารถดู Top TimedEvents ได้อย่างรวดเร็ว ในรายงาน AWR ซึ่งระบุพื้นที่ที่มีปัญหาดังแสดงในภาพต่อไปนี้:

เซสชันการปรับแต่ง ADDM

โดยปกติ เมื่อมีการรายงานปัญหา DBA อาจแก้ไขปัญหาเฉพาะพื้นที่นั้นหรือแก้ไขปัญหาเฉพาะนั้น อย่างไรก็ตาม หากปัญหาไม่ได้รับการระบุและแก้ไขอย่างถูกต้อง อาจนำไปสู่ปัญหาที่ใหญ่ขึ้นในอนาคต DBAcan พลาดภาพใหญ่ที่นี่ เพื่อช่วยให้ DBA มีขนาดใหญ่ขึ้นและเห็นภาพที่สมบูรณ์เกี่ยวกับปัญหาฐานข้อมูล Oracle ได้จัดเตรียมเครื่องมืออื่นสำหรับ DBA นั่นคือ ADDM เซสชันการปรับแต่ง ADDM เป็นไปตามขั้นตอนที่คล้ายกับเซสชันการปรับแต่งด้วยตนเอง รูปภาพต่อไปนี้แสดงการเปรียบเทียบ:

แหล่งที่มาของรูปภาพ:คู่มือการฝึกอบรม Oracle 11G Performance Tuning

ดึงรายงาน ADDM โดยใช้ SQL หรือผ่าน Oracle Enterprise Manager (OEM) รูปภาพต่อไปนี้แสดงตัวอย่าง SQL:

SQL ไม่ถูกต้องและแผนการดำเนินการ

หลังจากที่รายงาน AWR หรือ ADDM ระบุส่วนของ SQL/SQLID ที่ไม่ถูกต้อง คุณสามารถใช้DBMS_XPLANเพื่อรวบรวมข้อมูลเพิ่มเติมเกี่ยวกับส่วนเหล่านี้ได้ แพ็คเกจ DBMS_XPLAN จัดหาฟังก์ชันตารางต่อไปนี้ที่คุณสามารถใช้เพื่อดึงและแสดงแผนการดำเนินการ (exec):

DISPLAY
DISPLAY_AWR
 select plan_table_output from table (DBMS_XPLAN.DISPLAY_AWR('fs22b3fgfh8xc'));
DISPLAY_CURSOR

รูปภาพต่อไปนี้แสดงตัวอย่างผลลัพธ์จาก EXPLAIN PLAN คำสั่งและระบุว่าแบบสอบถามกำลังใช้การสแกนตารางแบบเต็มหรือจำกัดข้อมูลให้แคบลงโดยใช้ดัชนีบางส่วน:

รายงาน ADDM สะท้อนให้เห็นว่าคุณสามารถบรรลุผลประโยชน์ด้านประสิทธิภาพโดยการสร้างดัชนีใหม่บางส่วนได้หรือไม่ คุณยังสามารถเรียกใช้ SQL Tuning Advisor จาก OEM เพื่อปรับแต่งการสืบค้นข้อมูลและอาจใช้แผนการดำเนินการที่ดีกว่า โดยส่วนใหญ่ การใช้แผนที่ดีกว่าสำหรับ SQL ที่มีปัญหาจะช่วยแก้ปัญหาด้านประสิทธิภาพที่สำคัญได้

SQL Tuning Advisor

SQL Tuning Advisor ช่วยวิเคราะห์คำสั่ง SQL และรับคำแนะนำด้านประสิทธิภาพโดยใช้ SQL Authorization ID (SQLID) เพื่อวิเคราะห์และแนะนำโซลูชัน SQL Tuning Advisor วิเคราะห์แหล่งที่มาต่อไปนี้:

• กิจกรรมยอดนิยม:วิเคราะห์คำสั่ง SQL อันดับต้นๆ ที่ใช้งานอยู่ในปัจจุบัน
• ชุดการปรับแต่ง SQL:วิเคราะห์ชุดคำสั่ง SQL ที่คุณระบุ
• Historical SQL (AWR):วิเคราะห์คำสั่ง SQL จากคำสั่งที่รวบรวมโดยสแนปชอต AWR

ภาพหน้าจอต่อไปนี้แสดงตัวอย่างบางส่วน:

คำขอที่ใช้เวลานาน

ในฐานข้อมูล Oracle eBusiness Suite ปัญหาของคำขอที่รันเป็นเวลานานส่วนใหญ่จะขยายผลโดยที่คำขอทำงานพร้อมกันสองสามรายการยังคงทำงานอยู่ ในการแก้ไขปัญหานี้ คุณต้องรวบรวมข้อมูลเพิ่มเติมเกี่ยวกับเซสชันฐานข้อมูลที่เกี่ยวข้องกับคำขอที่เกิดขึ้นพร้อมกัน รูปภาพต่อไปนี้แสดงขั้นตอนในการเก็บรวบรวมข้อมูลนี้

ข้อมูล:

พารามิเตอร์หน่วยความจำ Oracle Database

หลังจากตรวจทานรายงาน AWR แล้ว DBA สามารถระบุแคชที่ต้องการการปรับแต่งได้อย่างง่ายดาย เนื่องจากอัตราส่วนการเข้าถึงแคชนั้นต่ำกว่าสำหรับแคชอื่นๆ รูปภาพต่อไปนี้แสดงพารามิเตอร์ฐานข้อมูลระดับบนสุดบางส่วนที่คุณต้องพิจารณาสำหรับการปรับหน่วยความจำทั้งอินสแตนซ์

ที่มาของรูปภาพ: https://ora-performance-tuning.blogspot.com/2014/02/automatic-shared-memory-management.html

เหตุการณ์รอที่สังเกตได้ทั่วไป

ตารางต่อไปนี้แสดงเหตุการณ์การรอโดยทั่วไปและสาเหตุที่เป็นไปได้:

(

ที่มาของตาราง:คู่มือการฝึกอบรม Oracle Performance Tuning 11G OCP บทที่ 20 หน้า 24

ปัญหาการปรับแต่ง 10 อันดับแรก

ลูกค้ามักประสบปัญหาการปรับแต่ง 10 อันดับแรกดังต่อไปนี้:

• การจัดการการเชื่อมต่อไม่ดี: นักพัฒนาเขียนโค้ดเพื่อเชื่อมต่อกับฐานข้อมูลในแอปพลิเคชันหรือเรียกใช้แบบสอบถามเพื่อดึงข้อมูลจากฐานข้อมูล หลังจากที่ดึงข้อมูลแล้วและไม่ต้องการอะไรเพิ่มเติมแล้ว รหัสควรปิดการเชื่อมต่อกับฐานข้อมูล อย่างไรก็ตาม สิ่งนี้มักจะไม่เกิดขึ้น ซึ่งทำให้เซสชันที่ไม่ได้ใช้งานในฐานข้อมูลมีจำนวนเพิ่มขึ้น เซสชันเหล่านี้ใช้ทรัพยากรอันมีค่าที่สามารถใช้สำหรับการเชื่อมต่ออื่นๆ ที่ใช้งานอยู่

• การใช้เคอร์เซอร์และพูลที่ใช้ร่วมกันในทางที่ผิด: เคอร์เซอร์เป็นเครื่องมือในคลังแสงของนักพัฒนาซึ่งส่วนใหญ่ใช้งานไม่ได้ หากไม่มีเคอร์เซอร์ Oracle ต้อง hardparse โค้ดทุกครั้งที่รัน สิ่งนี้ส่งผลกระทบอย่างมากต่อประสิทธิภาพของ SQLqueries ที่เรียกใช้ซ้ำๆ DBA สามารถระบุปัญหานี้ได้โดยดูที่ เปอร์เซ็นต์ประสิทธิภาพอินสแตนซ์ - ดำเนินการเพื่อแยกวิเคราะห์ % ส่วนรายงาน AWR

• SQL ไม่ถูกต้อง: วิธีเขียนแบบสอบถาม SQL (โดยมีเงื่อนไขการรวมเพื่อดึงข้อมูล) มีผลอย่างมากต่อประสิทธิภาพของ SQL นั้นหลังจากที่ดำเนินการแล้ว คุณควรหลีกเลี่ยงการสแกนตารางแบบเต็มสำหรับตารางขนาดใหญ่ หลังจากที่เตรียม SQL เรียบร้อยแล้ว นักพัฒนาและ DBA ควรรันแผนการอธิบายเกี่ยวกับ SQL นั้นเพื่อทำความเข้าใจค่าใช้จ่ายในการรันในฐานข้อมูล คุณสามารถเพิ่มประสิทธิภาพได้โดยใช้เคอร์เซอร์ ตัวแปร bindvariable และดัชนี

• การใช้พารามิเตอร์การเริ่มต้นที่ไม่เป็นมาตรฐาน: DBA ควรใช้เฉพาะพารามิเตอร์การเริ่มต้นมาตรฐานหรือที่แนะนำเท่านั้น ใช้พารามิเตอร์การเริ่มต้นที่ไม่ได้มาตรฐานเฉพาะเมื่อมีการแนะนำโดย Oracle Service Request (SR)

• รับฐานข้อมูล I/O ผิด: เมื่อ DBA เลือกฮาร์ดแวร์ฐานข้อมูล ควรพยายามกระจายฐานข้อมูลผ่านดิสก์หลายแผ่น และให้ทีมเครือข่ายมีส่วนร่วมในการอภิปรายเกี่ยวกับความเร็วที่ข้อมูลจะถูกส่งไปยังผู้ใช้ปลายทางจากเซิร์ฟเวอร์ฐานข้อมูลและย้อนกลับ DBA ควรคำนึงถึงความเร็วของสวิตช์เครือข่ายและเราเตอร์เพื่อหลีกเลี่ยงปัญหาคอขวดหรือประสิทธิภาพการทำงาน

• ทำซ้ำปัญหาการตั้งค่าบันทึก: บันทึกการทำซ้ำจะต้องเก็บข้อมูลจากบัฟเฟอร์ทำซ้ำเพื่อให้ Oracle สามารถทำซ้ำธุรกรรมในกรณีที่เกิดความผิดพลาด หากขนาดบันทึกการทำซ้ำไม่เพียงพอ อาจเกิดสวิตช์หลายตัวในฐานข้อมูลที่ทำให้เกิดปัญหาด้านประสิทธิภาพ นอกจากนี้ยังเพิ่มภาระในการสร้างไฟล์เก็บถาวรอีกด้วย

• การทำให้เป็นอนุกรมของบล็อคข้อมูลในบัฟเฟอร์แคช: สิ่งนี้เกิดขึ้นเนื่องจากการขาดแคลนกลุ่มรายการฟรีหรือเลิกทำกลุ่ม สถานการณ์นี้เกิดขึ้นจากการแทรกฐานข้อมูลจำนวนมากโดยมีฐานผู้ใช้ที่ใช้งานอยู่จำนวนมาก แต่มีกลุ่มที่เลิกทำน้อยลง ซึ่งท้ายที่สุดจะนำไปสู่ปัญหาด้านประสิทธิภาพ

• สแกนตารางแบบเต็ม: ตรวจสอบการสแกนตารางแบบเต็มในแบบสอบถามโดยเรียกใช้แผนอธิบาย โดยปกติ คิวรีที่ทำการสแกนตารางแบบเต็มจะสะท้อนการออกแบบ SQL ที่ไม่ดี ซึ่งสามารถแก้ไขได้โดยใช้ดัชนีและจำกัดข้อมูลที่ต้องการให้แคบลง ในบางกรณี การสแกนตารางแบบเต็มอาจเป็นประโยชน์ โดยเฉพาะอย่างยิ่งในกรณีที่เป็นโต๊ะขนาดเล็ก

• SQL แบบเรียกซ้ำ: SQL แบบเรียกซ้ำสามารถเป็นประโยชน์สำหรับนักพัฒนาหากใช้อย่างถูกต้อง แต่อาจเป็นดาบสองคม ทำถูกต้องให้ผลผลิตอย่างมีประสิทธิภาพ มิฉะนั้น จะส่งผลอย่างมากต่อประสิทธิภาพของฐานข้อมูล

• การเรียงลำดับในดิสก์: การเรียงลำดับในดิสก์เป็นงานที่มีราคาแพงมากสำหรับฐานข้อมูล ซึ่งบ่งชี้ถึงการออกแบบ SQL ที่ไม่ดีและการเพิ่มประสิทธิภาพที่ไม่ดี คุณสามารถระบุปัญหาได้ใน สถิติกิจกรรมอินสแตนซ์ – การเรียงลำดับ (ดิสก์) ส่วนรายงาน AWR

บทสรุป

แม้ว่า DBA จะต้องพิจารณาส่วนต่างๆ ของการปรับแต่งประสิทธิภาพ แต่ในฐานข้อมูลโลก การปรับแต่งประสิทธิภาพจะเริ่มต้นจากขั้นตอนการออกแบบฐานข้อมูลและแอปพลิเคชัน ฐานข้อมูลและแอปพลิเคชันที่ออกแบบโดยคำนึงถึงเปอร์สเปคทีฟในการปรับประสิทธิภาพนั้นสามารถปรับขนาดได้มากกว่าแอปพลิเคชันที่ออกแบบโดยไม่ได้คำนึงถึงการปรับประสิทธิภาพ

จุดปรับแต่งประสิทธิภาพที่กล่าวถึงในบล็อกนี้เป็นเพียงส่วนเล็กๆ ของภูเขาน้ำแข็ง ฉันขอแนะนำให้ DBA คนอื่นๆ คอยอ่านเพิ่มเติมในหัวข้อนี้เพื่อดูแลประสิทธิภาพของฐานข้อมูลโดยรวม

ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม

เรียนรู้เพิ่มเติมเกี่ยวกับบริการฐานข้อมูลของเรา

Rackspace มีความรู้กว้างขวางเกี่ยวกับผลิตภัณฑ์ของ Oracle เรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่เราสามารถเพิ่มการลงทุน Oracle ของคุณให้สูงสุด