Execution plan เหตุใดเจ้าจึงเปลี่ยนไป?


สวัสดีครับ ช่วงนี้นานๆ เข้ามาเขียนซักทีนึงนะครับ แล้ววันนี้ผมก็จะมาบอกเล่าเรื่องราวเกี่ยวกับสิ่งที่เป็นหัวใจสำคัญสำหรับการ Tuning นั้นคือ Execution plan ของแต่ละ SQL statement ว่าเพราะสาเหตุใดบ้างที่ทำให้การคิวรี่ข้อมูลรู้สึกช้าลงหรือแตกต่างออกไปทั้งที่ SQL statement ก็ยังเหมือนเดิม ลองมาดูกันครับ

Continue Reading

ORA-01000 Maximum Cursors Exceeded! เจ้าตายแล้ว!


ห่างหายไปนานเลยครับ ฮ่าๆ ช่วงนี้งานชุกมากๆ แต่ยังไงวันนี้ก็มีเรื่องราวดีๆ มาฝากเหมือนเดิม ORA-01000

นี้มัน Error อะไรกันอีกเนี่ย! ORA-01000 maximum open cursors exceeded! เคยเจอกันไหมครับ? เคยหล่ะซิ โอเค วันนี้ผมจะมางัดแงะแกะเกา Error message ตัวนี้ให้ทุกคนเข้าใจตรงกันนะครับ!

ORA-01000 maximum open cursors exceeded
Cause: A host language program attempted to open too many cursors. The initialization parameter OPEN_CURSORS determines the maximum number of cursors per user.
Action: Modify the program to use fewer cursors. If this error occurs often, shut down Oracle, increase the value of OPEN_CURSORS, and then restart Oracle.

Continue Reading

ORA-1652 TEMP เต็ม! ทำไงดีอ่ะ?


สวัสดีครับ เดียวเริ่มตั้งแต่ช่วงเดือนหน้าผมอาจจะมีเรื่องมาแชร์ทุกคนมากขึ้นครับ เนื่องจากจะเริ่มทำการเตรียมตัวสอบเพื่อเอา Oracle 11g Performance Tuning Certified Expert ถ้าเจอเรื่องอะไรน่าสนใจก็จะเอามาลงแบ่งปันกันเหมือนเดิมครับและสำหรับวันนี้ผมขอเกริ่นนำกันก่อนละกันนะครับ เราจะทำอย่างไรดีถ้า Temporary tablespace เต็ม? ซึ่งเราอาจจะทราบว่ามันจะเกิด ORA-1652: unable to extend temp segment ใน Alert log ขึ้น แล้วทำไงดีหละ? มันเต็มไปแล้วอ่ะ… วันนี้ผมเอาความรู้เกี่ยวกับ Temporary tablespace วิธีการมอนิเตอร์และรับมือกับปัญหา ORA-1652 มาฝากครับ

Continue Reading

Histogram statistics และผลกระทบจาก Bind variable


กรณีศึกษา: การรวบรวม Histogram statistics บนตารางและผลกระทบจากการใช้ Bind variables

สำหรับบทความในวันนี้ ผมจะพูดถึง Histogram statistics และผลกระทบของการใช้ Bind variables ต่อ Execution plan โดยผมจะกล่าวถึง บทความหนึ่งของท่านอาจารย์ของผมครับ

เมื่อเราทำการ Gather Statistics กับตารางที่ข้อมูลไม่ได้มีการปลี่ยนแปลงสามารถทำให้ Query Plan ที่เกิดกับคิวรีบนตารางเหล่านั้นเปลี่ยนไปได้ เช่นหากวันหนึ่งเราทำการ Gather Statistics รันคิวรี (และบันทึก Query Plan) เอาไว้ วันต่อมาเรา Gather Statistics อีก (และไม่ได้แก้ไขข้อมูลเดิมแต่อย่างใด) เมื่อเราคิวรีข้อมูลในตารางเหล่านั้นเราอาจจะพบว่า Query Plan ที่ได้ เปลี่ยนไป ซึ่ง Query Plan ที่ได้ ดูเหมือนวาจะดีกว่าตัวก่อน สาเหตุเป็นเพราะอะไร?

via Tanakorn Thai Oracle DBA: Query Plan เปี๊ยนไป๋!!?.

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

AUTO_SAMPLE_SIZE บน Oracle 11g ไฉไลกว่าเดิม!


เกริ่นนำกันก่อนละกันนะครับเกี่ยวกับการ Gather Optimizer Statistics ใน Oracle version เก่าๆ นั้น เราจำเป็นจะต้องคำนวน(เดา) ซึ่งเป็นเรื่องที่ค่อนข้างจุกจิกและยุ่งยากมากๆ เพราะ ถ้าเรากำหนดค่าไว้ที่ 100% บนออบเจ็กต์ขนาดใหญ่นั้นไม่ดีเอาซะเลย ถึงแม้ว่ามันจะการันตีว่าสถิติถูกรวบรวมมา 100% เต็มแต่ด้วยเวลาที่ใช้ไปนั้นเรียกได้ว่า “เต่าคลาน” เลยทีเดียว จนได้ถือกำเนิด AUTO_SAMPLE_SIZE ขึ้นเป็นครั้งแรกบน Oracle 9i ทำให้เราไม่จำเป็นต้องมาคอยกำหนด ESTIMATE_PERCENT อีกต่อไป แต่ข้อจำกัดของมันก็ยังมีอยู่ ถ้ามีการเบ้ (Skew) ของข้อมูลมากๆ สุดท้ายแล้วการกำหนด ESTIMATE_PERCENT ก็ยังคงมีประสิทธิภาพดีกว่าถ้ามีการเบ้ของข้อมูลมากๆ

Continue Reading