มีรหัสวินิจฉัยมากมายในตัว ส่วนหนึ่ง เช่น sql_traceมีการอธิบายไว้อย่างดีในเอกสารประกอบ และส่วนหนึ่ง เช่น การแสดง x$ติดตามไม่ได้รับการจัดทำเป็นเอกสารเลย ฉันชอบใช้เวลาวิเคราะห์โค้ดดังกล่าวอีกครั้งเป็นระยะๆ เพื่อดูว่าความสามารถของโค้ดนั้นล้ำหน้าแค่ไหน ได้รับการยอมรับอย่างเป็นทางการหรือไม่ และได้รับการบันทึกไว้หรือไม่ เมื่อเร็วๆ นี้ ขณะที่ทำงานกับเซิร์ฟเวอร์ Oracle 9i ฉันรู้สึกประหลาดใจที่ค้นพบความสามารถที่เพิ่มขึ้นอย่างมาก oracle_traceซึ่งเกิดขึ้นในช่วงสองสามรุ่นล่าสุด บทความนี้เป็น แนะนำสั้น ๆวี oracle_traceและคำอธิบายความสามารถ
ยังไง... ?
วิธีค้นหาวัตถุที่เป็นแหล่งกำเนิดของเหตุการณ์ทั้งหมด บัฟเฟอร์ไม่ว่างรอซึ่งสามารถเห็นได้ในมุมมอง v$รอสถิติ?
เราทุกคนได้อ่านคู่มือการปรับแต่งประสิทธิภาพแล้ว: "ถ้าคุณเห็น... คุณอาจต้องเพิ่มจำนวนรายการ ที่นั่งฟรี (รายการอิสระ) สำหรับตารางที่มีปัญหา" แต่ไม่ได้บอกว่าจะหาตารางที่มีปัญหามากนี้ได้อย่างไร
ตัวเลือกที่ 1: เรียกใช้สตรีมแบบสอบถามอย่างต่อเนื่องกับมุมมอง v$session_waitและตรวจสอบค่าคอลัมน์ หน้า 1, หน้า 2, หน้า 3เมื่อเหตุการณ์นี้เกิดขึ้น ตามสถิติไม่ช้าก็เร็วคุณจะมีความคิดที่สมเหตุสมผลว่าวัตถุใดทำให้เกิดปัญหา ตัวเลือกนี้ค่อนข้างเจ็บปวด และผลลัพธ์ส่วนหนึ่งขึ้นอยู่กับโชค
ตัวเลือกที่ 2: เปิดใช้งานเหตุการณ์ 10046 ที่ระดับ 8 และรับสตรีมข้อมูลการรอในไฟล์การติดตาม มันสร้างความเครียดให้กับระบบมากและยังต้องใช้โชคอีกด้วย
ตัวเลือกที่ 3: มีเหตุการณ์ (10240) ที่ควรสร้างรายการที่อยู่บล็อกในไฟล์การติดตามที่เรากำลังรอ (เย้!) แต่ฉันยังไม่สามารถทำให้เหตุการณ์นี้ทำงานได้ หากคุณรู้วิธีการทำเช่นนี้โปรดแจ้งให้เราทราบด้วย การตัดสินใจครั้งนี้เหมาะสมที่สุดอย่างแน่นอน
ดังนั้น คุณต้องการรับรายการบล็อกที่คุณต้องรอ พร้อมด้วย ID ของเซสชันการรอ เหตุผลและระยะเวลาของการรอ ทั้งหมดนี้มี ต้นทุนขั้นต่ำทรัพยากร? นี่คือสิ่งที่ช่วยให้คุณได้รับ oracle_trace.
oracle_trace คืออะไร
oracle_traceเป็นส่วนประกอบเซิร์ฟเวอร์ที่รวบรวมข้อมูลเกี่ยวกับเหตุการณ์โดยใช้ทรัพยากรที่ค่อนข้างเล็ก
เหตุการณ์เหล่านี้รวมถึงการรอ การเชื่อมต่อ การยกเลิกการเชื่อมต่อ การแยกวิเคราะห์และการดำเนินการค้นหา การดึงแถว และอื่นๆ
คุณสามารถรวบรวมข้อมูลสำหรับอินสแตนซ์ทั้งหมดหรือเพียงเพื่อก็ได้ ผู้ใช้บางรายเหตุการณ์หรือกระบวนการ นอกจากนี้ ยังสามารถเปิดและปิดการติดตามได้ตลอดเวลา
แต่คุณสมบัติที่น่าประทับใจที่สุดประการหนึ่ง oracle_traceคือมันเป็นไปได้ที่จะจัดระเบียบบัฟเฟอร์ของข้อมูลที่รวบรวมและถ่ายโอนข้อมูลไปยังดิสก์ในบล็อกขนาดใหญ่ แทนที่จะออกทีละบรรทัด นอกจากนี้ คุณสามารถกำหนดให้ไฟล์ที่มีข้อมูลที่รวบรวมไว้เป็น ขนาดคงที่และ นำกลับมาใช้ใหม่ .
โดยธรรมชาติแล้วเมื่อสร้างไฟล์พร้อมข้อมูลแล้วจำเป็นต้องวิเคราะห์มัน ซึ่งสามารถทำได้สองวิธี - รันโปรแกรมที่สร้างชุดรายงานข้อความตามข้อมูลไฟล์ หรือรันโปรแกรมที่อ่านข้อมูลไฟล์และทิ้งลงในชุดตาราง Oracle ซึ่งคุณสามารถสร้างเองได้ รายงาน
การใช้เครื่องมือ oracle_trace
แล้วยังไงล่ะ oracle_traceช่วยตอบคำถามเดิม?
แบบง่าย: หนึ่งในคลาสของเหตุการณ์ที่สามารถติดตามได้คือการรอ คุณต้องตรวจสอบว่าเซิร์ฟเวอร์ทำงานในโหมดที่อนุญาตให้คุณเปิดใช้งานการติดตาม จากนั้นขอให้เซิร์ฟเวอร์ดำเนินการดังกล่าว (ไม่ว่าจะใช้ PL/SQL หรือจาก บรรทัดคำสั่ง) เริ่มการติดตามการรอ ในเวลาเดียวกัน เราจำกัดชุดกิจกรรมรอไว้เฉพาะกิจกรรมเท่านั้น 92 (นี้ บัฟเฟอร์ไม่ว่างรอใน Oracle 9i แต่ให้ตรวจสอบค่าคอลัมน์เผื่อไว้ เหตุการณ์#และ ชื่อจากมุมมอง v$event_nameในระบบของคุณ) จากนั้นคุณก็ต้องนั่งรอประมาณหนึ่งชั่วโมงในช่วงที่รู้สึกว่าปัญหารุนแรงที่สุด เมื่อเราได้รับเพียงพอ ไฟล์ขนาดใหญ่ติดตาม หยุดการติดตาม ใส่ข้อมูลจากไฟล์การติดตามลงในฐานข้อมูล และดำเนินการคำสั่ง SQL ที่ร้องขอดังต่อไปนี้:
เหตุการณ์วัตถุใดเกิดขึ้น บัฟเฟอร์ไม่ว่างรอต้องรอนานแค่ไหน ต้องรอบ่อยแค่ไหน และใครทรมานมากที่สุด?
หากคุณสามารถอยู่กับค่าใช้จ่ายได้ คุณยังสามารถรวบรวมคำสั่ง SQL ที่ค้างอยู่ได้ในขณะติดตาม ทำให้คุณเห็นว่าคำสั่ง SQL ใดที่ได้รับผลกระทบจากการรอมากที่สุด
นำมารวมกันทั้งหมด
ขั้นแรก คุณต้องตั้งค่าพารามิเตอร์การเริ่มต้นจำนวนหนึ่งเพื่อให้คุณสามารถเปิดใช้งานการติดตามบนเซิร์ฟเวอร์ได้ แต่ไม่ต้องเปิดใช้งานทันที รายการพารามิเตอร์เหล่านี้แสดงไว้ในรูปที่ 1 1.
รูปที่ 1: พารามิเตอร์การเริ่มต้นที่เกี่ยวข้อง oracle_trace
พารามิเตอร์ oracle_trace_collection_nameต้องกำหนดให้ชัดเจน ค่าว่าง "" เพราะความหมายมาตรฐานของมันคือ "ออราเคิล"และหากมีการระบุชื่อชุดและเปิดใช้งานการติดตาม เซิร์ฟเวอร์ออราเคิลดำเนินการติดตามระดับอินสแตนซ์ตั้งแต่เริ่มต้น (ว้าว!)
พารามิเตอร์ oracle_trace_collection_pathระบุไดเร็กทอรีที่จะเก็บไฟล์ไว้ ในแค็ตตาล็อก oracle_trace_facility_pathรายการเหตุการณ์ที่สามารถติดตามได้จะถูกโพสต์ ( ไฟล์คำจำกัดความสิ่งอำนวยความสะดวก- ไฟล์คำจำกัดความของเครื่องมือที่จัดทำโดย Oracle Corporation) พารามิเตอร์ oracle_trace_facility_nameระบุรายการกิจกรรมที่เราสนใจ สุดท้ายนี้ คุณสามารถจำกัดขนาด (เป็นไบต์) ของไฟล์การติดตามได้โดยการตั้งค่าพารามิเตอร์ oracle_trace_collection_size.
หลังจากที่เซิร์ฟเวอร์เริ่มทำงาน คุณสามารถเริ่มรวบรวมข้อมูลการติดตามได้
ในบทความนี้ ฉันจะใช้เครื่องมือบรรทัดคำสั่งเท่านั้น แม้ว่าจะมีอินเทอร์เฟซ PL/SQL สำรอง (package dbms_oracle_trace_agent- ประมาณ นักแปล) และแม้กระทั่ง กุยหากคุณซื้อโมดูลที่เกี่ยวข้องสำหรับ ออราเคิล เอ็นเตอร์ไพรส์ผู้จัดการ. เราจะใช้คำสั่งต่อไปนี้:
Otrccol เริ่ม 1 otrace.cfg
ทีม otrccol- อินเทอร์เฟซหลักสำหรับ oracle_trace- มีคำสั่งอื่นๆ แต่คุณสมบัติส่วนใหญ่ได้ถูกเพิ่มเข้าไปแล้ว otrccol- เห็นได้ชัดว่าเป็นพารามิเตอร์ เริ่มต้องเริ่มต้นการติดตาม (และพารามิเตอร์ หยุด- หยุดเธอ) ความหมาย " 1 " เป็นตัวระบุงานที่เลือกแบบสุ่มและ otrace.cfg- ไฟล์กำหนดค่า ตัวอย่างของไฟล์การกำหนดค่าจะแสดงในรูป 2.
รูปที่ 2: ตัวอย่างไฟล์การกำหนดค่า oracle_trace
ไฟล์นี้ต้องการให้เซิร์ฟเวอร์สร้างไฟล์ชุดข้อมูลชื่อ เจพีแอล.ดาทโดยมีไฟล์คำจำกัดความของคอลเลกชันชื่อ jpl.cdfและตั้งไอดี เจพีแอล- คำจำกัดความของเครื่องมือที่ตรวจสอบย้อนกลับอยู่ในไฟล์ รอ.fdf(ไฟล์นี้จัดทำโดย Oracle และมีเพียงเหตุการณ์รอเท่านั้น) ขนาดไฟล์การติดตามจะถูกจำกัดไว้ที่ 10 MB แต่จะถูกนำมาใช้ซ้ำเพื่อให้มีข้อมูล 10 MB ล่าสุดเสมอ ก่อนที่จะดัมพ์ข้อมูลลงในไฟล์นี้ เซิร์ฟเวอร์ Oracle จะสะสมข้อมูลไว้ในบัฟเฟอร์ขนาด 1 MB
ความเป็นไปได้ในการตั้งค่า เรียบร้อย- หนึ่งในมากที่สุด ความสามารถอันทรงพลัง oracle_trace- ค่า "มาตรฐาน" ของสตริงนี้ประกอบด้วย "0 0" แทนที่จะเป็นของฉัน "7 92" และเรียกร้องสิ่งนั้น oracle_traceติดตามอินสแตนซ์ Oracle ทั้งหมดซึ่งได้รับจาก id d901ที่ท้ายบรรทัด ฉันแค่ขอให้ติดตาม วิธีแก้ไขหมายเลข 7(รอกิจกรรม) องค์ประกอบที่ 92(ความคาดหวัง บัฟเฟอร์ไม่ว่างรอ).
หากจำเป็น คุณสามารถระบุหลายบรรทัดในไฟล์ได้ เรียบร้อย- สำหรับการทดลองชุดแรก ฉันใช้สองบรรทัด เรียบร้อยในไฟล์คอนฟิกูเรชันที่ระบุการติดตาม "7 129" และ "7 130" - การอ่านตามลำดับและแบบกระจาย ตามลำดับ เนื่องจากการรอประเภทนี้สร้างได้ง่าย
ฉันจะแสดงความคิดเห็นในส่วนที่ระบุคุณสมบัติการจัดรูปแบบเพิ่มเติม
หลังจากที่ระบบรันมาระยะหนึ่งแล้ว ให้รัน:
Otrccol หยุด 1 otrace.cfg รูปแบบ otrccol otrace.cfg
คำสั่งแรกจะหยุดการติดตาม คำสั่งที่สองอ่านไฟล์และดัมพ์ข้อมูลลงในตาราง Oracle จำนวนหนึ่ง
อย่างไรก็ตาม ก่อนที่คุณจะจัดรูปแบบชุดได้ คุณต้องสร้างสคีมาที่มีตารางที่ใช้ในการจัดรูปแบบก่อน สำหรับชื่อผู้ใช้และรหัสผ่าน เราใช้ค่าที่แสดงไว้ก่อนหน้าในรูป 2. เชือก เต็ม_รูปแบบ=1ในไฟล์คอนฟิกูเรชันทำให้ไฟล์ทั้งหมดถูกทิ้งลงในตาราง การติดตั้ง เต็ม_รูปแบบ=0จะรีเซ็ตเฉพาะข้อมูลใหม่เท่านั้น หมายเหตุด้วยชื่อบริการ ( บริการ) - ระบุฐานข้อมูลซึ่งมีบัญชีที่เกี่ยวข้องอยู่ หากต้องการใช้คำสั่ง รูปแบบคุณต้องเริ่มกระบวนการฟัง TNS (ตัวฟัง TNS) แม้ว่าข้อมูลจะถูกดัมพ์ลงในฐานข้อมูลท้องถิ่นก็ตาม
ในรูป รูปที่ 3 แสดงสคริปต์ขนาดเล็กที่สร้างบัญชีและให้สิทธิ์ที่จำเป็นแก่มัน
รูปที่ 3: การสร้างผู้ใช้ที่มีสคีมาจะมีตารางการติดตาม
เมื่อระบุตัวเลือก รูปแบบโปรแกรมอัตโนมัติ (โดย อย่างน้อยในรูปแบบใหม่ เวอร์ชันของออราเคิล) จะสร้างตารางที่จำเป็นขึ้นมา โครงการที่ระบุ- ตารางเหล่านี้บางตารางจะมีชื่อที่ค่อนข้างมีความหมาย เช่น:
EPC_COLLECTION
ชื่อของผู้อื่นจะไม่มีความหมายใด ๆ :
V_192216243_F_5_E_9_9_0
ปัญหาเกี่ยวกับชื่อที่น่าอึดอัดใจสามารถแก้ไขได้ด้วยการเรียกใช้สคริปต์ otrcsyn.sqlในแค็ตตาล็อก $ORACLE_HOME/otrace/demo.
สคริปต์นี้สร้างคำพ้องสำหรับตาราง โดยตั้งชื่อที่มีความหมาย เช่นนี้
รอการเชื่อมต่อ
(ชื่อจะแตกต่างกันไปขึ้นอยู่กับ. รุ่นที่แตกต่างกันออราเคิล)
ฉันพบปัญหาเล็กน้อยกับ รุ่นอัตโนมัติตาราง หากคุณระบุรายการกองทุนที่มีการคัดเลือกรายการใดรายการหนึ่ง (เช่น รอ.fdf) จะสร้างเฉพาะตารางที่จำเป็นในการนำเสนอผลลัพธ์การจัดรูปแบบที่เกี่ยวข้องเท่านั้น หากคุณนั้นตัดสินใจใช้มากขึ้น รายการทั้งหมดกองทุนที่ติดตามได้ (เช่น oracle.fdf) ที่ การจัดรูปแบบจะเกิดขึ้นความล้มเหลวเนื่องจากมีบางตารางอยู่ แต่บางตารางไม่มี ดังนั้นจึงอาจสมเหตุสมผลที่จะใช้เวลาสองสามวินาทีในการติดตาม oracle.fdfจัดรูปแบบข้อมูล แล้วตัดทอนข้อมูลจากตารางทั้งหมด หยาบแต่. วิธีการที่มีประสิทธิภาพการตั้งค่าของโครงร่างที่เกี่ยวข้อง
ผลลัพธ์บางอย่าง
แล้วเราทำอะไร:
- สร้างไฟล์การกำหนดค่าแล้ว
- เริ่มการรวบรวมข้อมูล
- ดำเนินการบางอย่างในฐานข้อมูล
- หยุดการรวบรวมข้อมูล
- จัดรูปแบบชุดข้อมูลแล้ว
แล้วตอนนี้ล่ะ?
สมมติว่าเราใช้ไฟล์กำหนดค่าที่แสดงในรูปที่ 1 2. การเชื่อมต่อในนามของ บัญชี โอเทรซเราจะพบแถวในตาราง การเชื่อมต่อ, ตัดการเชื่อมต่อและ รอ- แถวในตาราง รอจะบอกทุกอย่างเกี่ยวกับเหตุการณ์ที่เกิดขึ้น บัฟเฟอร์ไม่ว่างรอที่เกิดขึ้นระหว่างการติดตาม
ตัวอย่างเช่น เราสามารถดำเนินการคำสั่ง SQL ดังแสดงในรูปที่ 1 4:
|
รูปที่ 4: ตัวอย่างแบบสอบถามเพื่อระบุการรอที่นานที่สุดสำหรับบล็อกที่ถูกครอบครอง
หากต้องการความแม่นยำมากขึ้น คุณสามารถส่งออกการรอทั้งหมดด้วยการประทับเวลา และตั้งชื่อคอลัมน์ (ค่อนข้างในแง่ดี) timestamp_nano.
หากคุณต้องการค้นหาว่าผู้ใช้รายใดต้องรอนานที่สุด ให้เปลี่ยนแบบสอบถามและสรุปตามคอลัมน์ session_index(เอสไอดี) และ session_serial (อนุกรม#- เพื่อให้ได้ตามค่า ( session_index, session_serial) ชื่อผู้ใช้ ชื่อเครื่อง เวลาที่ลงทะเบียน ฯลฯ คุณสามารถใช้ตาราง (คำพ้องความหมาย) การเชื่อมต่อ.
แน่นอนว่า ไม่มีอะไร (นอกเหนือจากการลงโทษด้านประสิทธิภาพ) ที่ขัดขวางไม่ให้คุณเข้าร่วมตารางนี้เพื่อดูข้อมูลพร็อพเพอร์ตี้ dba_extentsเพื่อแปลงตัวระบุไฟล์และบล็อกเป็นประเภทและชื่อวัตถุ
และหากคุณต้องการระบุคำสั่ง SQL เฉพาะที่คุณต้องรอ คุณสามารถเปลี่ยนไปใช้ไฟล์ได้ตลอดเวลา แม้ว่าจะต้องใช้ทรัพยากรมากขึ้นก็ตาม sql_waits.fdfซึ่งส่งผลให้มีตารางอีกหลายตารางที่เต็มไปด้วยข้อมูลการติดตาม ซึ่งสามารถรวมเข้ากับคอลัมน์ได้ session_index, session_serial, การประทับเวลาและ timestamp_nano.
สุดท้ายนี้ หากคุณคิดว่าค่าใช้จ่ายในการโหลดข้อมูลลงในตารางและการสร้างรายงานจะส่งผลเสียต่อระบบของคุณ คุณสามารถย้ายไฟล์ได้ตลอดเวลา ซีดีและ ข้อมูลไปยังเครื่องอื่นและประมวลผลในฐานข้อมูลอื่น ด้วยการปรับแต่งเล็กน้อย ฉันยังสามารถสร้างชุดข้อมูลบนอินสแตนซ์เวอร์ชัน 9i แล้วรันบนอินสแตนซ์ 8i เพียงเพื่อพิสูจน์ความเป็นไปได้ แน่นอนว่าจะทำให้การระบุวัตถุด้วยหมายเลขบล็อกเป็นเรื่องยาก
อนาคต
ความเป็นไปได้ไม่มีที่สิ้นสุด - ตัวอย่างเช่น ไฟล์คำจำกัดความของเครื่องมือไฟล์ใดไฟล์หนึ่งถูกเรียก oraclec.fdfและช่วยให้คุณสามารถติดตามการดำเนินการในแคชบัฟเฟอร์ได้ ด้วยการติดตามการกระทำเหล่านี้ คุณสามารถระบุได้จนถึงระดับไมโครวินาทีว่าบล็อกใดถูกโหลดลงในแคช ตามลำดับใด และบล็อกใดที่ต้องถูกไล่ออกจากแคชก่อนจึงจะสามารถโหลดได้ (ฉันสงสัยว่าค่าใช้จ่ายเพิ่มเติมจะไม่อนุญาตให้ใช้วิธีนี้เสมอไป)
คุณสมบัติการติดตามอีกประการหนึ่งซึ่งจะเป็นประโยชน์กับหลาย ๆ คนนั้นแสดงโดยไฟล์ เชื่อมต่อ.fdf- มันสกัดกั้นการเชื่อมต่อเซสชันและการยกเลิกการเชื่อมต่อ เช่นเดียวกับวิธีการทำงานของคำสั่ง เซสชันการตรวจสอบ- อย่างไรก็ตาม ไฟล์การติดตามจะสะสมสถิติเพิ่มเติมอีกครึ่งโหล (เช่น ระเบียนทำซ้ำ) ที่เพิ่มลงในตาราง AUD $อย่าตี; และในระหว่างกระบวนการสะสมจะไม่มีการเขียนลงฐานข้อมูล
คุณยังสามารถเข้าถึง ผู้ใช้แต่ละราย: สามารถกำหนดเป้าหมายได้ oracle_traceเพื่อติดตามการกระทำของผู้ใช้รายหนึ่ง คุณยังสามารถเขียนคำสั่ง SQL ที่อ่านตารางผลลัพธ์และสร้างไฟล์ที่คล้ายกับที่คุณสร้างขึ้นได้ sql_trace- ในกรณีนี้ ยังสามารถติดตามช่วงเวลาของการลงทะเบียน การเปลี่ยนจากเซิร์ฟเวอร์ที่ใช้ร่วมกันหนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่ง และสุดท้ายก็ออกจากเซิร์ฟเวอร์
บทสรุป
นี่เป็นเพียงการแนะนำสั้น ๆ เกี่ยวกับ oracle_traceซึ่งได้สัมผัสถึงพื้นฐานการใช้งาน เรายังต้องดำเนินการประเมินความมั่นคงของงานและ ผลข้างเคียงใช้ oracle_traceไม่ต้องพูดถึงผลกระทบต่อประสิทธิภาพการทำงาน
อย่างไรก็ตาม การวิจัยเพียงเล็กน้อยแสดงให้เห็นว่าเครื่องมือนี้ต้องการทรัพยากรน้อยกว่าเครื่องมือวินิจฉัยในตัวอื่นๆ อย่างมาก ทำให้การรายงานมีความยืดหยุ่นและแม่นยำยิ่งขึ้น
ท้ายที่สุดแล้ว oracle_traceช่วยให้คุณได้รับคำตอบที่ถูกต้องสำหรับคำถามที่ซับซ้อนจำนวนหนึ่งซึ่งสร้างปัญหาให้กับ DBA มาหลายปี
โดยส่วนตัวแล้วฉันจะไม่แปลกใจเกินไปถ้า oracle_traceในอีกไม่กี่ปีข้างหน้า มันจะเข้ามาแทนที่เครื่องมือวินิจฉัยอื่นๆ ทั้งหมดในที่สุด
ปัญหา
มีความแตกต่างมากมาย มักจะเป็นเพียงชื่อ ระหว่างการใช้งาน oracle_traceในเวอร์ชัน Oracle 8i และ Oracle 9i บทความนี้เขียนขึ้นจาก Oracle 9i โดยเฉพาะ
12 คำตอบ
คุณสามารถใช้ Oracle Enterprise Manager เพื่อติดตามเซสชันที่ใช้งานอยู่ การดำเนินการสืบค้น แผนการดำเนินการ การล็อก สถิติบางส่วน และแม้แต่แถบความคืบหน้าสำหรับงานที่ยาวขึ้น
ไปที่อินสแตนซ์ → เซสชัน และดูที่แท็บ SQL ของแต่ละเซสชัน
และแน่นอน คุณยังสามารถใช้เครื่องมือนี้ได้ อธิบายแผน FOR, TRACE และวิธีการใช้เครื่องมืออื่นๆ อีกมากมาย Enterprise Manager มีรายงานหลายฉบับสำหรับการสืบค้น SQL ที่แพงที่สุด คุณยังสามารถค้นหาได้ คำขอล่าสุด, เก็บไว้ในแคช
ฉันพบวิธีแก้ปัญหาง่ายๆ
ขั้นตอนที่ 1 เชื่อมต่อกับฐานข้อมูลโดยใช้ผู้ใช้ที่เป็นผู้ดูแลระบบโดยใช้ PLSQL หรือ sqldeveloper หรืออินเทอร์เฟซการสืบค้นอื่น ๆ
ขั้นตอนที่ 2 เรียกใช้สคริปต์ด้านล่าง ในคอลัมน์ S.SQL_TEXT คุณจะเห็นข้อความค้นหาที่ดำเนินการ
เลือก S.LAST_ACTIVE_TIME, S.MODULE, S.SQL_FULLTEXT, S.SQL_PROFILE, S.EXECUTTIONS, S.LAST_LOAD_TIME, S.PARSING_USER_ID, S.SERVICE จาก SYS.V_$SQL S, SYS.ALL_USERS U โดยที่ S.PARSING_USER_ID=U .USER_ID และ UPPER(U.USERNAME) IN ("ชื่อผู้ใช้ oracle ที่นี่") เรียงลำดับตาม TO_DATE(S.LAST_LOAD_TIME, "YYYY-MM-DD/HH24:MI:SS") เรียงลำดับ;
ปัญหาเดียวคือฉันไม่สามารถหาวิธีแสดงค่าได้ พารามิเตอร์อินพุต(สำหรับการเรียกใช้ฟังก์ชัน) แต่อย่างน้อยเราก็สามารถเห็นสิ่งที่ทำงานใน Oracle และลำดับของมันโดยไม่ต้องใช้เครื่องมือเฉพาะใดๆ
แก้ไขชุดระบบ timed_statistics=true
แก้ไขชุดเซสชัน timed_statistics=true -- หากต้องการติดตามเซสชันของคุณเอง
ควรใหญ่พอ:
เลือกค่าจาก v$parameter p โดยที่ name="max_dump_file_size"
ค้นหาจำนวนเมล็ดและ หมายเลขซีเรียลเซสชันที่คุณสนใจ:
เลือก sid, serial# จาก v$session โดยที่ ...your_search_params...
คุณสามารถเริ่มต้นการติดตามด้วยเหตุการณ์ 10046 พารามิเตอร์ที่สี่จะตั้งค่าระดับการติดตาม (12 คือสูงสุด):
เริ่มต้น sys.dbms_system.set_ev(sid, serial#, 10046, 12, "");
จบ;
ปิดการติดตามด้วยการตั้งค่าระดับศูนย์:
เริ่มต้น sys.dbms_system.set_ev(sid, serial#, 10046, 0, ""); จบ;
/* ระดับที่เป็นไปได้: 0 - ปิดการใช้งาน 1 - ระดับต่ำสุด คล้ายกับการตั้งค่า sql_trace = true 4 - ค่าตัวแปรการผูกจะถูกเพิ่มลงในไฟล์การติดตาม 8 - เพิ่มการรอ 12 - ค่าการผูกตัวแปรและเหตุการณ์รอจะถูกเพิ่ม */
เช่นเดียวกันหากคุณต้องการติดตามเซสชันของคุณในระดับที่สูงกว่า:
แก้ไขเหตุการณ์ชุดเซสชัน "บริบทชื่อการติดตาม 10046 ตลอดไป ระดับ 12";
ปิด:
แก้ไขเหตุการณ์ชุดเซสชัน "ปิดบริบทชื่อการติดตาม 10046";
ไฟล์ที่มีข้อมูลการติดตามดิบ:
เลือกค่าจาก v$parameter p โดยที่ name="user_dump_dest"
ชื่อไฟล์ (*. Trc) จะมี spid:
เลือก p.spid จาก v$session s, v$process p โดยที่ s.paddr=p.addr และ ...your_search_params...
คุณสามารถตั้งชื่อได้ด้วยตัวเอง:
สุดท้าย ใช้ TKPROF เพื่อทำให้ไฟล์การติดตามเข้าใจได้ง่ายขึ้น:
C:\ORACLE\admin\databaseSID\udump> C:\ORACLE\admin\databaseSID\udump>tkprof my_trace_file.trc output=my_file.prf TKPROF: Release 9.2.0.1.0 - การผลิตในวันพุธที่ 22 กันยายน 18:05:00 น. 2004 ลิขสิทธิ์ (c) 1982, 2002, ออราเคิล คอร์ปอเรชั่น สงวนลิขสิทธิ์. C:\ORACLE\admin\databaseSID\udump>
หากต้องการดูสถานะการใช้งานของไฟล์การติดตาม ให้ทำดังนี้
ตั้งค่าเซิร์ฟเวอร์เอาท์พุตเป็นขนาด 30000; ประกาศ ALevel binary_integer; เริ่มต้น SYS.DBMS_SYSTEM.Read_Ev (10046, ALevel);
ถ้า ALevel = 0 ดังนั้น DBMS_OUTPUT.Put_Line("sql_trace is off");
อื่น DBMS_OUTPUT.Put_Line("sql_trace เปิดอยู่");
สิ้นสุดถ้า; จบ; -
อีกสองสามอย่าง - ใน SQL*Plus - SET AUTOTRACE ON - จะให้แผนคำอธิบายและสถิติสำหรับแต่ละคำสั่งที่ดำเนินการ TOAD ยังอนุญาตให้ทำโปรไฟล์ฝั่งไคลเอ็นต์ได้ข้อเสียของทั้งสองประการคือ พวกเขาจะแจ้งให้คุณทราบถึงแผนการดำเนินการสำหรับคำสั่งเท่านั้น แต่ไม่ได้แจ้งว่าเครื่องมือเพิ่มประสิทธิภาพมาถึงแผนนั้นได้อย่างไร คุณจะต้องมีการติดตามฝั่งเซิร์ฟเวอร์ระดับล่างสำหรับสิ่งนั้น สิ่งสำคัญอีกประการหนึ่งที่ต้องทำความเข้าใจคือสแน็ปช็อต Statspackวิธีที่ดี
ดูประสิทธิภาพของฐานข้อมูลโดยรวม อธิบายแผน ฯลฯ มีความเข้าใจที่ดีเกี่ยวกับคำสั่ง SQL แต่ละรายการที่เป็นคอขวด Statspack ทำงานได้ดีในการระบุความจริงที่ว่าปัญหาของคุณคือการแสดงออกที่เรียบง่ายด้วย
แผนการที่ดี กล่าวกันว่ามีการประหารชีวิต 1 ล้านครั้งต่อนาที Catch คือการบันทึกการดำเนินการ SQL ทั้งหมดระหว่างสองจุดในเวลา SQL Server ก็เช่นกัน
- มีบางสถานการณ์ที่จะเป็นประโยชน์ในการจับ SQL นั้น ผู้ใช้เฉพาะทำงานบนฐานข้อมูล โดยทั่วไป คุณจะเปิดใช้งานการติดตามเซสชันสำหรับผู้ใช้รายนั้น แต่แนวทางนี้อาจมีปัญหาอยู่ 2 ประการ
- ประการแรก เว็บแอปพลิเคชันจำนวนมากรองรับการรวมกลุ่ม
การเชื่อมต่อแบบถาวร ไปยังฐานข้อมูลที่แชร์โดยผู้ใช้หลายคนประการที่สอง แอปพลิเคชันบางตัวเชื่อมต่อ เรียกใช้ SQL บางตัว และยกเลิกการเชื่อมต่ออย่างรวดเร็ว ซึ่งทำให้ยากต่อการเปิดใช้งานการติดตามเซสชันเลย (แน่นอนว่าคุณสามารถใช้ทริกเกอร์การเข้าสู่ระบบเพื่อเปิดใช้งานการติดตามเซสชันในกรณีนี้)
วิธีแก้ปัญหาที่รวดเร็วและสกปรกคือการรวบรวมทุกอย่าง คำสั่ง SQLฐานข้อมูล ณ จุดใดจุดหนึ่งโดยเฉพาะ จากนั้นตารางจะถูกสอบถามเพื่อสร้างรายการการรัน SQL ทั้งหมดในช่วงเวลานั้น
หากเป็นไปได้ คุณควรทำสิ่งนี้ในระบบการพัฒนาแบบเงียบ - ไม่เช่นนั้นคุณอาจเสี่ยงที่จะได้รับข้อมูลกลับมากเกินไป
ถ่ายภาพสแนปช็อตแรก เรียกใช้ sql ต่อไปนี้เพื่อสร้างสแน็ปช็อตแรก:
สร้างตาราง sql_exec_before เป็นการดำเนินการแบบเลือก hash_value จาก v$sqlarea /
ให้ผู้ใช้ปฏิบัติงานในแอปพลิเคชัน
ถ่ายรูปที่สอง
สร้างตาราง sql_exec_after เป็นการดำเนินการแบบเลือก hash_value จาก v$sqlarea /
ตรวจสอบผลลัพธ์ เมื่อคุณได้บันทึก SQL แล้ว ก็ถึงเวลาค้นหาผลลัพธ์
สวัสดี
บ่อยครั้งที่ผู้ใช้หรือผู้ทดสอบของเราติดต่อฉันด้วยปัญหาต่อไปนี้:
“โปรแกรมเริ่มทำงานสำหรับฉัน ช้า!"
ในขณะเดียวกันก็ไม่มีเวลาศึกษาปัญหาโดยละเอียดเลย และแม้แต่เซิร์ฟเวอร์ที่ใช้งานได้ก็มักจะทำงานกับพารามิเตอร์ sql_trace = false...
ในกรณีนี้ ฉันพบวิธีแก้ปัญหา "ด่วน" ต่อไปนี้สำหรับตัวฉันเอง
1. เราขอให้ผู้ใช้ "เข้าสู่ระบบ" เข้าสู่โปรแกรม
2. ค้นหา sid และซีเรียลของเซสชันผู้ใช้ (เลือก sid, serial# จาก v$session โดยที่<условия поиска>)
3. ดำเนินการบล็อก PL/SQL นี้
ประกาศ
-- 0/1/โมฆะ<-->เท็จ/จริง/โมฆะ
-- พารามิเตอร์บูลีนถูกแปลจาก/เป็นจำนวนเต็ม:
sql_trace บูลีน:= sys.diutil.int_to_bool(1);
เริ่ม
-- เรียกขั้นตอน
dbms_system.set_sql_trace_in_session
(ซิด => 56,
อนุกรม# => 6656,
sql_trace => sql_trace);
จบ;
หลังจากดำเนินการแล้ว การติดตามเซสชันที่ระบุจะเริ่มต้นขึ้น
4. เราขอให้ผู้ใช้ดำเนินการเป็นเวลานาน...
6. ปิดใช้งานการติดตามโดยการรันสคริปต์นี้อีกครั้ง โดยระบุพารามิเตอร์ sql_trace = 0
7. ค้นหาไฟล์ .trc ในไดเรกทอรีเซิร์ฟเวอร์ UDUMP
ชื่อไฟล์ประกอบด้วย ID กระบวนการ ระบบปฏิบัติการ- คุณสามารถค้นหาได้เช่นนี้
SQL> เลือก p.spid จาก v$session s, v$process p
2 โดยที่ s.paddr=p.addr
3 และ ...my_selection_criteria...
4 /
8. เราประมวลผลไฟล์นี้ด้วยยูทิลิตี้ TKPROF (TKPROF<имя trc-файла> <имя выходного файла>)
9. ในไฟล์ผลลัพธ์ เราจะวิเคราะห์ผลลัพธ์สุดท้าย โดยประเมินพารามิเตอร์ CPU และ ELAPSED
เช่น วันนี้ผมได้รับภาพนี้
และผลปรากฏว่ามีปัญหาและเน้นไปที่ระยะเวลารอรับข้อมูล (20.85 วินาที)
เราจำเป็นต้องค้นหาคำถามที่มีปัญหา
10. ในหน้าต่างโดยใช้ ค้นหาคำสั่ง"ทั้งหมด"<имя выходного файла>>1.txt
เราค้นหาบรรทัดทั้งหมดที่ขึ้นต้นด้วย "ผลรวม" และบันทึกลงในไฟล์ 1.txt
11. เราตรวจสอบไฟล์นี้อย่างรวดเร็วและค้นหาค่าที่ไม่เหมาะกับเราในแง่ของมูลค่า
ในกรณีของฉันวันนี้ มีบรรทัดทั้งหมด 2 บรรทัดสำหรับคำขอสองรายการ ซึ่งกินเวลาเกือบทั้งหมดในการรอ
รวม 9 0.00 0.00 0 21 0 9
รวม 3 0.03 0.02 0 3 0 0
รวม 3 0.01 0.00 0 14 0 5
รวม 3 0.64 10.89 11848 17504 0 4
รวม 3 0.07 0.06 0 214 0 29
รวม 15 0.00 0.00 0 15 0 5
รวม 3 0.01 0.00 0 3 0 0
รวม 3 0.00 0.00 0 4 0 1
รวม 3 0.00 0.00 0 8 0 6
รวม 6 0.04 0.02 0 8 0 2
รวม 3 0.00 0.00 0 4 0 1
รวม 3 0.00 0.00 0 3 1 1
รวม 3 0.00 0.00 0 2 0 1
รวม 3 0.01 0.00 0 8 2 1
รวม 2 0.00 0.00 0 4 1 1
รวม 3 0.00 0.00 0 2 0 1
รวม 3 0.21 9.85 7760 12354 0 1
รวม 6 0.00 0.00 0 0 0 0
รวม 6 0.00 0.00 0 0 0 0
จากนั้น เมื่อใช้ค่าเหล่านี้จากบรรทัดเหล่านี้ในไฟล์การติดตามที่ประมวลผล เราจะพบคำขอที่มีปัญหาและจัดการกับคำขอเหล่านั้น
วันนี้ผมสร้างดัชนีสองอันก็เพียงพอแล้ว...
ทั้งหมด...
จากประสบการณ์ของฉัน การจัดการง่ายๆ เหล่านี้ช่วยแก้ไขปัญหาประสิทธิภาพของเซิร์ฟเวอร์ได้ประมาณ 90 เปอร์เซ็นต์
คุณอาจถามว่าทำไมถึงทำขั้นตอนที่ 10? ท้ายที่สุด คุณสามารถค้นหาข้อความค้นหาที่มีปัญหาในไฟล์ TRC ที่ประมวลผลได้ แน่นอนคุณทำได้ หากมีคำขอดังกล่าวหลายร้อยคำขอในการติดตามเดียว จะง่ายกว่าในการดูหรือประมวลผลเฉพาะผลรวมอย่างรวดเร็ว จากนั้นไปยังรายละเอียด...
