บันทึกความทรงจำ SQL Tuning (Oracle) #1 เบื้องต้น

      ไม่ได้เขียนบทความใน blog ของตัวเองมานาน ช่วงหลังจากมีลูก มีเรื่องให้คิดเยอะขึ้น มีอะไรที่อยากจะทำ มีความคำถามที่อยากจะถามตัวเอง อยากหาคำตอบให้กับตัวเอง แล้วก็อยากจะห่างจาก social หน่อย ช่วงหลัง ๆ เลยไม่ค่อยได้จับคอมฯ หรือ tablet  ส่วนใหญ่จับแต่ kindle ไว้อ่านหนังสือ เรื่องบ่น ๆ เดี๋ยวค่อยเขียนอีกอันดีกว่า ^ ^"
   
    จริง ๆ บทความนี้คิดว่าอยากจะเขียนมานานละ แล้วก็ลืมไปเลย จนวันนี้เพื่อนคนหนึ่งโทรมาปรึกษาเรื่อง SQL Tuning เลยได้โอกาสเขียนบทความนี้สักที
     


บันทึกความทรงจำการทำ  SQL Tuning (Oracle) #1 เบื้องต้น
    สมัยก่อนประมาณเกือบ ๆ 10 ปีที่แล้วผมยังทำงานสาย IT อยู่บริษัทใหญ่บริษัทนึง สำนักงานใหญ่อยู่สีลม สมัยนั้นทำงานเกือบทุกอย่างค่อยข้างผสมปนเป  ประมาณว่าใครมีปัญหาติดปัญหาอะไรก็มาปรึกษา งานไหนไม่มีใครทำก็เอามาทำ ถ้าจำไม่ผิดตอนนั้นทีมตัวเองเรียกว่าทีม solution

   หนึ่งในปัญหาที่ส่งมาปรึกษากันก็คือ Database ทำงานช้าดึงข้อมูลช้ามาก ซึ่งข้อมูลมีขนาดระดับ 200GB ได้  ก็เลยได้ลองทำ SQL Tuning และได้รู้จักกับ Oracle SQL Analyzer

ขั้นตอนการทำ SQL Tuning 

1. ดึงข้อมูล SQL ที่ทำงานช้าออกมาก่อน ขั้นตอนนี้ก็ง่าย ๆ แค่ดึงคำสั่งที่ทำงานช้าออกมา โดยดูการระยะเวลาการดึงข้อมูล ถ้าเป็น application ก็ลองดูว่า page ไหนทำงานช้าแล้วค่อย ๆ ดึงข้อมูล sql  นั้น ๆ ออกมา 
2. วิเคราะห์คำสั่ง SQL ที่ใช้  คำสั่งที่ใช้ในการ Query จะมีเงื่อนไขค่อนข้างเยอะ แล้วบ้างครั้ง database ที่ออกแบบมานั้น ก็ทำ normalization เรียบร้อยมาก (ในหนังสือเรียน Database จะมีสอนเสมอ) แต่การทำ normalization ที่ละเอียดไม่ได้ตอบโจทก์การทำงานจริง ที่ต้องการความรวดเร็ว  เนื่องจากจะต้องมีการ join table เยอะ ซึ่งการ joint table ยิ่งเยอะ ก็ยิ่งทำให้ DB ทำงานเยอะตามไปด้วย แต่จะไม่ normalization เลยก็ไม่ได้เพราะข้อมูลจะเก็บซ้ำซ้อนเยอะ ทำให้การจัดการ และ DB บวมได้ สิ่งที่ต้องวิเคราะห์แบ่งเป็นข้อ ๆ ได้ดังนี้ 
1.   การ joint table  มีการ joint กี่ table เป็นการ joint  แบบไหน? ( inner, outter, lefe join, right joint) มีการใช้ index เป็น key ในการ joint หรือไม่ ?  ถ้ามีความจำเป็นที่ต้อง joint ก็แนะนำให้สร้างเป็น view เลยดีกว่า จากนั้น select จาก view โดยตรง เนื่องจาก DB ต่าง ๆ จะสร้าง index ให้โดยอัตโนมัติ DB สมัยใหม่นั้นจะมีการสร้าง view ได้หลายแบบ สามารถเลือกสร้างได้ตามความเหมาะสม 
2. เงื่อนไขการ Query แต่ละเงื่อนไข มีการสร้าง index แล้วหรือยัง?  กรณีที่มี index อยู่แล้ว index ที่สร้างมีความเหมาะสมกับเงื่อนไขนั้น ๆ หรือไม่  ถ้าข้อมูลมีขนาดใหญ่มาก ๆ  ก็พยายามลดการ Query ที่ดึงข้อมูลทั้ง DB เช่นการเพิ่มเงื่อนไขของช่วงเวลามาเป็นต้น จะทำให้ DB ทำงานน้อยลง 
3. เพิ่มระบบการ Paging ลงใน SQL ถ้าใน Oracle จะใช้คำสั่ง  Limit จะทำให้ DB ลดการทำงานลง เพราะการใช้งาน ผ่าน App ส่วนใหญ่จะ display ข้อมูลแค่เพียงจำนวนนึง ไม่ได้ใช้พร้อมกันทั้งหมด เป็นต้น 
4. database ที่ใช้ได้ทำการ reindex หรือ เรียงลำดับข้อมูลใหม่หรือไม่?  ส่วนนี้เกี่ยวข้องกับ DBA โดยตรง index ต่าง ๆ เมื่อใช้งานได้สักระยะ ก็ควรจะต้องทำการ reindex ใหม่เสมอ เช่นอาจจะ เดือนละครั้ง หรือ สัปดาห์ละครั้ง เป็นต้น
    
3. แก้ไข index, table, view สร้าง index ตาม criteria ในการใช้งาน  table มีหลายประเภทสามารถเลือกใช้ตามความเหมาะสมได้จะทำให้ DB เร็วขึ้น  view ก็เหมือนกัน ถ้าจำเป็นต้อง joint table บ่อย ๆ สร้าง view ไว้เลยก็เป็นความคิดที่ดี  view เองก็มีทั้ง view แบบ memory และ view แบบ permanant 
4. แก้ไขคำสั่ง SQL ใหม่ โดยอิงจากผลลัพธ์ให้เหมือนเดิม