ในโพสต์สั้นๆ นี้ ฉันอยากจะขจัดความเข้าใจผิดข้อหนึ่งที่เกี่ยวข้องกับการวิเคราะห์ฐานข้อมูล AWR ที่ทำงานบน Oracle Exadata เป็นเวลาเกือบ 10 ปีแล้วที่ฉันต้องเผชิญกับคำถามอย่างต่อเนื่องว่า ซอฟต์แวร์ Exadata มีส่วนช่วยในด้านประสิทธิภาพการทำงานอย่างไร หรือใช้คำที่บัญญัติขึ้นใหม่: “ผู้เชี่ยวชาญ” ทำงานของฐานข้อมูลเฉพาะอย่างไร?
ในความคิดของฉัน บ่อยครั้งที่คำถามที่ถูกต้องนี้ได้รับการตอบอย่างไม่ถูกต้องโดยอ้างอิงกับสถิติ AWR โดยนำเสนอวิธีการรอของระบบ ซึ่งถือว่าเวลาตอบสนองเป็นผลรวมของเวลาปฏิบัติการของโปรเซสเซอร์ (DB CPU) และเวลารอของคลาสต่างๆ
ด้วยการถือกำเนิดของ Exadata ความคาดหวังของระบบเฉพาะที่เกี่ยวข้องกับการทำงานของซอฟต์แวร์ Exadata ก็ปรากฏในสถิติ AWR ตามกฎแล้วชื่อของการรอดังกล่าวจะขึ้นต้นด้วยคำว่า "เซลล์" (เซิร์ฟเวอร์ Exadata Storage เรียกว่าเซลล์) ซึ่งชื่อที่พบบ่อยที่สุดคือการรอด้วยชื่อที่อธิบายตนเองว่า "การสแกนตารางอัจฉริยะของเซลล์", "เซลล์หลายบล็อก การอ่านทางกายภาพ" และ "การอ่านฟิสิคัลบล็อกเดียวของเซลล์"
ในกรณีส่วนใหญ่ ส่วนแบ่งของการรอ Exadata ในเวลาตอบสนองทั้งหมดนั้นมีน้อย ดังนั้นจึงไม่จัดอยู่ในส่วนเหตุการณ์เบื้องหน้า 10 อันดับแรกตามเวลารอทั้งหมดด้วยซ้ำ (ในกรณีนี้ คุณต้องค้นหาในส่วนการรอเบื้องหน้า ส่วนกิจกรรม) ด้วยความยากลำบากอย่างยิ่ง เราพบตัวอย่าง AWR รายวันจากลูกค้าของเรา ซึ่งความคาดหวังของ Exadata ถูกรวมไว้ในส่วน 10 อันดับแรก และรวมเป็นประมาณ 5%:
เหตุการณ์
รอ
เวลารอทั้งหมด (วินาที)
รอเฉลี่ย
%เวลาฐานข้อมูล
รอชั้น
ดีบี ซีพียู
115.2K
70.4
SQL*Net ข้อมูลเพิ่มเติมจาก dblink
670,196
5471.5
8.16ms
3.3
เครือข่าย
การอ่านฟิสิคัลบล็อกเดียวของเซลล์
5,661,452
3827.6
676.07us
2.3
ผู้ใช้ I/O
ซิงค์การปรับสมดุล ASM
4,350,012
3481.3
800.30us
2.1
อื่นๆ
การอ่านฟิสิคัลหลายบล็อกของเซลล์
759,885
2252
2.96ms
1.4
ผู้ใช้ I/O
อ่านเส้นทางตรง
374,368
1811.3
4.84ms
1.1
ผู้ใช้ I/O
ข้อความ SQL*Net จาก dblink
7,983
1725
216.08ms
1.1
เครือข่าย
การสแกนตารางอัจฉริยะของเซลล์
1,007,520
1260.7
1.25ms
0.8
ผู้ใช้ I/O
อุณหภูมิการอ่านเส้นทางโดยตรง
520,211
808.4
1.55ms
0.5
ผู้ใช้ I/O
enq: TM - การโต้แย้ง
652
795.8
1220.55ms
0.5
การใช้งาน
ข้อสรุปต่อไปนี้มักได้มาจากสถิติ AWR ดังกล่าว:
1. การมีส่วนร่วมของเวทมนตร์ Exadata ต่อประสิทธิภาพของฐานข้อมูลไม่สูง - ไม่เกิน 5% และฐานข้อมูล "ขยาย" ได้ไม่ดี
2. หากฐานข้อมูลดังกล่าวถูกถ่ายโอนจาก Exadata ไปยังสถาปัตยกรรม "เซิร์ฟเวอร์ + อาเรย์" แบบคลาสสิก ประสิทธิภาพจะไม่เปลี่ยนแปลงมากนัก เพราะแม้ว่าอาเรย์นี้จะช้ากว่าระบบจัดเก็บข้อมูล Exadata ถึงสามเท่า (ซึ่งแทบจะเป็นไปไม่ได้เลยสำหรับอาเรย์ All Flash สมัยใหม่) จากนั้นเมื่อคูณ 5% ด้วย 15 เราก็จะได้รับส่วนแบ่ง I/O เพิ่มขึ้นโดยรอเป็น XNUMX% - ฐานข้อมูลจะรอดพ้นจากสิ่งนี้อย่างแน่นอน!
ข้อสรุปทั้งสองนี้ไม่ถูกต้อง อีกทั้งยังบิดเบือนความเข้าใจในแนวคิดเบื้องหลังซอฟต์แวร์ Exadata Exadata ไม่เพียงแต่ให้ I/O ที่รวดเร็วเท่านั้น แต่ยังทำงานแตกต่างโดยพื้นฐานเมื่อเปรียบเทียบกับสถาปัตยกรรมเซิร์ฟเวอร์ + อาเรย์แบบคลาสสิก หากการดำเนินการฐานข้อมูลเป็นแบบ "exadapted" อย่างแท้จริง ตรรกะ SQL จะถูกถ่ายโอนไปยังระบบจัดเก็บข้อมูล เซิร์ฟเวอร์จัดเก็บข้อมูลด้วยกลไกพิเศษหลายประการ (โดยหลักแล้วคือ Exadata Storage Indexes แต่ไม่เพียงแต่) ค้นหาข้อมูลที่จำเป็นด้วยตนเองและส่งฐานข้อมูลไปยังเซิร์ฟเวอร์ ซึ่งทำได้ค่อนข้างมีประสิทธิภาพ ดังนั้นส่วนแบ่งของ Exadata ทั่วไปที่รอในเวลาตอบสนองทั้งหมดจึงมีน้อย
การแชร์นี้จะเปลี่ยนแปลงไปอย่างไรนอกเหนือจาก Exadata สิ่งนี้จะส่งผลต่อประสิทธิภาพของฐานข้อมูลโดยรวมอย่างไร? การทดสอบจะตอบคำถามเหล่านี้ได้ดีที่สุด ตัวอย่างเช่น การรอ “การสแกนตารางอัจฉริยะของเซลล์” ภายนอก Exadata อาจกลายเป็นการสแกนแบบเต็มตารางที่หนักหน่วงจน I/O ใช้เวลาตอบสนองทั้งหมดและประสิทธิภาพลดลงอย่างมาก ด้วยเหตุนี้ เมื่อวิเคราะห์ AWR จึงผิดที่จะพิจารณาเปอร์เซ็นต์รวมของความคาดหวังของ Exadata ว่ามีส่วนช่วยในประสิทธิภาพการทำงาน และยิ่งกว่านั้นคือการใช้เปอร์เซ็นต์นี้เพื่อคาดการณ์ประสิทธิภาพภายนอก Exadata เพื่อให้เข้าใจว่าการทำงานของฐานข้อมูลมีความ "แม่นยำ" เพียงใด คุณต้องศึกษาสถิติ AWR ในส่วน "สถิติกิจกรรมอินสแตนซ์" (มีสถิติจำนวนมากที่มีชื่อที่อธิบายตนเองได้) และเปรียบเทียบกัน
และเพื่อทำความเข้าใจว่าฐานข้อมูลภายนอก Exadata จะรู้สึกอย่างไร วิธีที่ดีที่สุดคือสร้างโคลนฐานข้อมูลจากการสำรองข้อมูลบนสถาปัตยกรรมเป้าหมาย และวิเคราะห์ประสิทธิภาพของโคลนนี้ภายใต้โหลด ตามกฎแล้วเจ้าของ Exadata จะมีโอกาสนี้
ผู้แต่ง: Alexey Struchenko หัวหน้าแผนกฐานข้อมูล Jet Infosystems
ที่มา: will.com