--- Gugun Gunawan <[EMAIL PROTECTED]> wrote: > Ini permintaan tolong saya yang kesekian. > Saya minta tolong penjelasan... > pada database saya terdapat log-log seperti ini > (OEM oracle 10g) > > [Critical] Jan 12, 2007 9:58:25 PM > Listener response to a TNS ping is 1910 msecs - > [Clear] Jan 12, 2007 9:53:25 PM Listener > response to a TNS ping is 30 msecs - > [Critical] Jan 12, 2007 9:33:25 PM > Listener response to a TNS ping is 400 msecs -
TNSPING dapat digunakan utk mengecek status listener di database. Apabila response time lama, ada bbrp kemungkinan: - Network antara OEM ke database lambat (apakah OEM yg dimaksud adalah Db Control atau Grid Control? Kalau DB Control ada di server database lokal, maka harusnya bukan masalah network) - CPU di server db sangat sibuk, sehingga response dari proses listener terhadap request tnsping lambat. Anda bisa meng-ignore kemungkinan network lambat apabila PING (bukan tnsping) pada saat yg sama menunjukkan response time yg cepat. > > Finding Host CPU was a bottleneck and > the instance was consuming 12% of the host CPU. All > wait times will be inflated by wait for CPU. > Impact (minutes) 135.91 > Impact (%) 100 > > > Recommendations > Consider adding more CPUs to the host or > increasing the number of instances serving the > database. Ini mengindikasikan bahwa komponen CPU adalah komponen yg paling signifikan dari keseluruhan response time database. Cuma saya tidak melihat adanya problem apabila satu database cuma memakai 12% dari total CPU. Apabila Anda cek dari utilitas OS (misalkan vmstat), berapa persen rata2 utilisasi CPU pada waktu peak? > Finding Individual database segments > responsible for significant physical I/O were > found. > Impact (minutes) 67.43 > Impact (%) 49.61 > > > Recommendations > Action Investigate application logic involving > I/O on TABLE "GUNAWAN.CUST_TRX_POINTMNG" with object > id 50916. > > View Rationale > Message Run "Segment Advisor" on TABLE > "GUNAWAN.CUST_TRX_POINTMNG" with object id 50916. > Action Run "Segment Advisor" on TABLE > "GUNAWAN.CUST_TRX_POINTMNG" with object id 50916. Ada indikasi bahwa query pada table "GUNAWAN.CUST_TRX_POINTMNG" memerlukan akses langsung ke disk karena belum ada di buffer. Coba Anda cek sql yg berhubungan dengan table tsb dari report AWR (script ada di $ORACLE_HOME/rdbms/admin/awrrpt.sql). Ada kemungkinan query Anda melakukan full table scans yg cukup sering karena tiadanya index yg sesuai. > Finding SQL statements were not shared > due to the usage of literals. This resulted in > additional hard parses which were consuming > significant database time. > Impact (minutes) 3.07 > Impact (%) 3.04 > > > Recommendations > Action Investigate application logic for > possible use of bind variables instead of literals. > Alternatively, you may set the parameter > "cursor_sharing" to "force". Ini mungkin berhubungan dengan bagian development di perusahaan Anda. Sepertinya banyak sql yg tidak menggunakan bind variable. Parameter cursor_sharing bisa Anda cek di init.ora (dr sqlplus: show parameter cursor_sharing). By default nilainya adalah EXACT. Jangan mencoba mengubah parameter ini tanpa mengetahui dampaknya. Total waktu 3 menit yg diperlukan utk parsing 'mungkin' tidak begitu signifikan utk diperhatikan. regards, tomi ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
