จำกัด ระดับของการขนาน (DOP) ที่มีให้กับแบบสอบถาม

ใน Oracle Exadata (11gR2) เรามีฐานข้อมูลที่ค่อนข้างอ้วน

• cpu_count คือ 24
• parallel_server_instances คือ 2
• parallel_threads_per_cpu คือ 2

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

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

ระบบมีการเปลี่ยนแปลงเพื่อเปิด parallelisation:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

สิ่งนี้ส่งผลให้มีประสิทธิภาพที่ดีขึ้น แต่บางครั้งเราสังเกตเห็นใน OEM ว่าแบบสอบถามเดียวจะผูก DOP จาก 96 (ทรัพยากรที่มีอยู่ทั้งหมด) สิ่งนี้ทำให้เคียวรีลำดับต่อมาถูกลดระดับเป็น DOP เป็น 1 (ไม่มีการขนาน) ส่งผลให้ประสิทธิภาพต่ำจนกว่าแบบสอบถาม hogging จะเสร็จสมบูรณ์

ในการแก้ไขปัญหานี้เราได้พยายาม จำกัด DOP ที่สามารถใช้ได้กับแบบสอบถามใด ๆ ด้วย:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

สิ่งนี้ไม่มีผลกระทบ เรามักสังเกตการสืบค้นที่จะใช้เกินขีด จำกัด (โดยทั่วไปคือ 48 หรือ 96 แต่ไม่มีรูปแบบจริง)

เราจะป้องกันไม่ให้แบบสอบถามใด ๆ จากแหล่งข้อมูลที่มีอยู่ทั้งหมดได้อย่างไร

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

คำแนะนำแบบขนาน: PARALLEL_DEGREE_LIMIT จะใช้กับข้อความที่ใช้ระดับความเท่าเทียมอัตโนมัติเท่านั้น ข้อความใด ๆ ที่ใช้ระดับฮาร์ดโค้ดหรือแม้แต่คำใบ้ขนานระดับวัตถุใด ๆ ก็จะไม่สนใจขีด จำกัด นั้น หากคุณมีคำใบ้เหล่านั้นนั่นอาจอธิบายได้ว่าทำไมคุณถึงเห็น 96 ครั้ง

Calibrate IO: DOP อัตโนมัติอาจจะไม่ได้ถูกนำมาใช้และทำให้วงเงินที่ไม่ได้ถูกตามเพราะ IO ไม่ได้สอบเทียบ แบบสอบถามนี้จะบอกคุณว่ามีการปรับเทียบ IO:

select * from V$IO_CALIBRATION_STATUS;

ฉันเคยเห็นปัญหานี้มาก่อน แต่ระบบปัจจุบันของฉันไม่ได้ปรับเทียบและ DOP อัตโนมัติดูเหมือนว่าจะทำงานได้ดี คุณสามารถบอกได้ว่านี่เป็นปัญหาจริงหรือไม่โดยดูที่ส่วนหมายเหตุของแผนอธิบาย ถ้าคุณเห็นบางสิ่งบางอย่างเช่น- automatic DOP: Computed Degree of Parallelism is 2คุณกำลังดี automatic DOP: skipped because of IO calibrate statistics are missingแต่คุณไม่ต้องการที่จะเห็น

เพิ่ม PARALLEL_MAX_SERVERS: แทนที่จะกังวลเกี่ยวกับการหมดเซิร์ฟเวอร์แบบขนานฉันขอแนะนำให้คุณเพิ่ม PARALLEL_MAX_SERVERS อย่างมีนัยสำคัญ อย่างน้อยคุณควรลองกลับไปที่ค่าเริ่มต้น PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5 ระหว่าง 240 ถึง 960 ขึ้นอยู่กับการตั้งค่าหน่วยความจำของคุณ

ตัวเลขที่สูงเหล่านั้นฟังดูไร้สาระสำหรับ DBA หลาย ๆ อัน แต่จริง ๆ แล้วมันสมเหตุสมผลมากด้วยเหตุผลดังต่อไปนี้:

• เซิร์ฟเวอร์แบบขนานของ Oracle นั้นมีน้ำหนักเบากว่าที่คนทั่วไปคิดเอาไว้ (และแทบจะไม่มีใครเคยทดสอบเลยพวกเขาแค่พบสถานการณ์หนึ่งที่ DOP ขนาดใหญ่ทำให้เกิดปัญหาและคิดว่า DOP สูงนั้นไม่ดีอยู่เสมอ)
• เป็นเรื่องปกติที่จะเรียกใช้คิวรี adhoc ในเครื่องมือ GUI ที่ดึงเฉพาะแถว 50 แถวแรก แต่ยังคงใช้เซิร์ฟเวอร์แบบขนานจำนวนมาก ข้อความค้นหาเหล่านี้ไม่ได้ใช้ทรัพยากรที่สำคัญใด ๆ เว้นแต่ว่า PARALLEL_MAX_SERVERS จะต่ำเกินไป จากนั้นผู้คนตะโกนเรียกใช้คำสั่งที่สมเหตุสมผลอย่างสมบูรณ์ซึ่งอาจนำไปสู่สถานการณ์ที่น่าเกลียด
• DOP ที่มีขนาดใหญ่มากสำหรับแบบสอบถามเดียวไม่ได้เลวร้ายเสมอไป ทุกคนคิดว่าถ้าคุณเพิ่ม DOP อยู่เรื่อย ๆ ค่าใช้จ่ายจะสูงเกินไปและประสิทธิภาพจะลดลงอย่างมาก แต่ในหลาย ๆ ระบบฉันพบว่าแม้ DOP ที่สูงอย่างน่าขันจะนำไปสู่ประสิทธิภาพที่ดีขึ้นแม้ว่าจะมีผลตอบแทนที่ลดลงอย่างแน่นอนและมันอาจไม่เป็นธรรมต่อเซสชันอื่น ๆ แต่อย่าเพิ่งลองทดสอบดู ทำแบบสอบถามและเรียกใช้กับ DOP ทุกชนิดจนถึง 1,000 คุณอาจแปลกใจ
• ใช่การขนานกันมากเกินไปอาจไม่ดี แต่สิ่งที่เลวร้ายกว่าสำหรับระบบการมีมากกว่าจำนวนเซสชันที่เหมาะสมเล็กน้อยหรือบังคับให้เคียวรีต่อเนื่องและฆ่างานสำคัญโดยทั่วไป? คุณควรตรวจสอบระบบก่อนที่จะแนะนำข้อ จำกัด โดยพลการ