Cardinality Feedback คิดผิดกันดีนัก เดียวพี่คิดเอง!!!


Cardinality Feedback

ช่วงนี้รัวๆ บทความให้เลยละกันครับ คันไม้คันมือมากกกกกก ก็วันนี้จัดให้อีกซักหนึ่งเรื่องแล้วกันนะครับเกี่ยวกับอีกหนึ่งความสามารถใน Oracle 11gR2 นั่นคือ Cardinality Feedback นั่นเองครับผม

Cardinality Feedback คืออะไร? ทำงานอย่างไร?

Cardinality Feedback ถูกนำมาใช้ครั้งแรกใน Oracle 11gR2 จุดประสงค์ก็เพื่อช่วยในเรื่องการ Generate execution plan ให้ดีขึ้นในคิวรี่ที่มีการรันบ่อยๆ และสำหรับคิวรี่ที่มีการคำนวนผลลัพธ์ที่ไม่ดี ซึ่งนั่นทำให้ Optimizer อาจจะคำนวนผิดพลาดได้ในหลายๆ สาเหตุ เช่น Statistics ที่ผิดพลาด, เส้นทางของคิวรี่ที่ซับซ้อนเกินความจำเป็น ไม่ว่าจะด้วยเหตุผลใดที่ทำให้เกิดการคำนวนผิดพลาด Cardinality Feedback นี่เองจะเข้ามาช่วยแก้ปัญหาตรงนี้

Continue Reading

Advertisements

SKEWONLY vs SIZE AUTO อะไรควรใช้ตอนไหน


เมื่อบทความที่แล้วผมได้พูดถึงตารางที่มีการเก็บ Histogram statistic และผลกระทบจากการใช้ Bind variable บนตารางนั้นๆ ไปแล้ว ถ้าใครมีคำถามสงสัยก็ลองถามเข้ามาได้ครับ แต่ในวันนี้ผมจะเล่าถึง Option นึงเกี่ยวกับการ Gather statistic ที่ส่วนใหญ่มักจะมองข้ามความสำคัญไป นั่นก็คือ METHOD_OPT ครับ โดยส่วนใหญ่มักจะถูกใช้เป็นค่า Default (เฮ้ยๆ ช่างมันเถอะ gather stats แล้วก็โอเคแล้วมั่ง) ซึ่ง Default ที่ผมพูดถึงนั่นก็คือ “FOR ALL COLUMNS SIZE AUTO” ครับ (ในบทความนี้ผมขอเรียกสั้นๆ ว่า AUTO นะครับ และ “FOR ALL COLUMNS SIZE SKEWONLY” ซึ่งเป็นพระเอกของเราในวันนี้ ผมขอเรียกสั้นๆ ว่า SKEWONLY ครับ)

Continue Reading

Function-based index กับการใช้งานคอลัมน์ DATE


สำหรับวันนี้ผมจะมาทำจำลองเหตุการณ์ว่าทำไม? เมื่อเราใช้ TRUNC ฟังก์ชั่นบน DATE คอลัมน์ในคิวรี่แล้ว ทำไมคิวรี่ของเราจึงช้าลง ในขณะทีเราก็สร้างอินเด็กซ์บน DATE ไปให้แล้ว และในช่วงท้ายผมจะพูดถึงพระเอกของงานนี้นั้นคือ function-based index นั่นเองครับ เอาละครับมาเริ่มกันเลย
หนึ่งในสาเหตุสำหรับปัญหาเกี่ยวกับ SQL Statement ที่ได้พบได้เจอกันบ่อยๆ นั่นก็คือ Full table scan ซึ่งถูกกำหนดให้เป็น invalidating บน Index ใน SQL Statement ที่ WHERE clause ถูกเรียกใช้งาน Built-in function บน DATE column มาดูตัวอย่างกันครับ

Continue Reading

Parallel query processing ตอนที่ 1


เมื่อใดที่เราควรใช้ Parallel processing

ครั้งหนึ่งเมื่อเหล่า Developer เห็นผมใช้ Parallel hint เพื่อทำให้ได้ผลลัพธ์จาก Query เร็วขึ้น ไม่นานหลังจากนั้น ทุกๆ SQL ที่ถุกสร้างขึ้นโดย developer ท่านนั้นจะมีส่วนของ Parallel hint เพิ่มขึ้นมาด้วยตามแบบอย่างที่ผมทำให้พวกเค้าเห็น และหลังจากนั้นไม่นาน ประสิทธิภาพของระบบก็แย่ลงเนื่องมาจากการใช้ Parallel processing ที่มากเกินความจำเป็น

บทเรียนจากเรื่องนี้คือ ถ้ามี SQL ที่ถูกเรียกใช้งานพร้อมๆ กันบนฐานข้อมูลพยายามที่จะใช้ทรัพยากรทั้งหมดของระบบ (โดยเฉพาะแบบParallel processing) นั่นคือยิ่งจะทำให้ประสิทธิภาพของระบบแย่ลง ไม่ใช่ทำให้ดีขึ้น ดังนั้นเราควรเลือกใช้ Parallel เมื่อทำแล้วมั่นใจว่าทำให้ประสิทธิภาพดีขึ้นเท่านั้นโดยไม่ได้ไปกระทบกับประสิทธิภาพในส่วนอื่นๆ บนฐานข้อมูล

ในส่วนของบทความที่จะเขียนต่อไปนี้จะกล่าวถึงลักษณะของเหตุการณ์ว่าเมื่อใดเราควรเลือกใช้ Parallel SQL

Continue Reading

Index Selectivity นั้นสำคัญไฉน?


Index selectivity คืออะไร?

Balance tree index ช่วยทำให้ประสิทธิภาพของคิวรี่ที่เรียกข้อมูลปริมาณน้อยๆ จากตารางดีขึ้น ดังนั้นเราจึงควรสร้าง อินเด็กซ์บนตารางที่ถูกคิวรี่ในจำนวนบรรทัดต่ำกว่า 15% บ่อยๆ ซึ่งค่านี้สามารถปรับเปลี่ยนได้ตามความเหมาะสมตามสถานการณ์ที่ว่า จำนวนข้อมูลแค่ไหนที่อินเด็กซ์สามารถเรียกได้หรือคอลัมน์ใดๆ บนอินเด็กซ์ที่ต้องการใช้ในการ Join กับตารางอื่นๆ

ค่าเรโชของค่าเฉพาะบน column (Distinct value) ต่อจำนวนข้อมูลบนตารางจะถูกนำมาใช้ในการคำนวนหา Selectivity ของอินเด็กซ์นั้นๆ ซึ่ง Selectivity ในอุดมคติคือเท่ากับ 1 เทียบได้กับการใช้อินเด็กซ์แบบ Unique บน NOT NULL column นั่นเอง

Continue Reading