Anda mungkin tidak akan mendapatkan data yang Anda cari tanpa melakukan lebih banyak konfigurasi (seperti mengaktifkan audit) atau membuat beberapa kompromi. Apa masalah bisnis yang Anda coba selesaikan? Bergantung pada masalahnya, kami mungkin dapat membantu Anda mengidentifikasi pendekatan termudah untuk mengonfigurasi database agar dapat merekam informasi yang Anda cari.
Oracle tidak berusaha untuk menyimpan di mana pun berapa kali pengguna tertentu (dan khususnya bukan berapa kali pengguna sistem operasi tertentu) mengeksekusi kueri tertentu. SQL_ID di V$SESSION hanya menunjukkan SQL_ID bahwa sesi sedang dijalankan. Jika, seperti yang saya duga, ini adalah aplikasi klien-server, kemungkinan besar ini adalah NULL 99% dari waktu karena sebagian besar waktu, sesi tidak mengeksekusi SQL apa pun, itu menunggu pengguna melakukan sesuatu. PREV_SQL_ID di V$SESSION adalah pernyataan SQL sebelumnya yang dieksekusi-- setidaknya secara umum tidak akan menjadi NULL . Tapi itu hanya akan memiliki satu nilai, itu tidak akan memiliki riwayat pernyataan SQL yang dieksekusi oleh sesi itu.
V$SQL view adalah representasi dari apa yang ada di SQL shared pool. Saat pernyataan SQL tidak lagi ada di kumpulan bersama, pernyataan itu tidak akan lagi berada di V$SQL melihat. Seberapa cepat itu terjadi tergantung pada banyak faktor-- seberapa sering seseorang mengeksekusi pernyataan, seberapa sering pernyataan baru diuraikan (yang umumnya sangat bergantung pada apakah aplikasi Anda menggunakan variabel ikatan dengan benar), seberapa besar kumpulan bersama Anda, dll . Umumnya, itu akan terjadi antara beberapa menit dan sampai database dimatikan.
Jika Anda memiliki lisensi untuk menggunakan tabel AWR dan Anda tertarik pada perkiraan daripada jawaban yang benar-benar tepat, Anda mungkin bisa mendapatkan informasi yang Anda cari dengan melihat beberapa tabel AWR. Misalnya, V$ACTIVE_SESSION_HISTORY akan menangkap pernyataan SQL bahwa setiap sesi secara aktif mengeksekusi setiap detik. Karena ini adalah aplikasi client-server, bagaimanapun, itu berarti bahwa sebagian besar waktu, sesi akan tidak aktif, jadi tidak ada yang akan ditangkap. Pernyataan SQL yang kebetulan ditangkap untuk suatu sesi, bagaimanapun, akan memberi Anda beberapa gagasan tentang frekuensi relatif dari pernyataan SQL yang berbeda. Tentu saja, pernyataan SQL yang berjalan lebih lama lebih mungkin ditangkap juga karena mereka lebih cenderung aktif pada saat tertentu. Jika kueri A dan B keduanya dieksekusi dalam jumlah waktu yang sama persis dan sesi ditangkap mengeksekusi A 5 kali dan B 10 kali dalam satu jam terakhir, Anda dapat menyimpulkan bahwa B dieksekusi kira-kira dua kali lebih sering dari A. Dan jika Anda tahu waktu eksekusi rata-rata kueri, probabilitas rata-rata bahwa kueri ditangkap adalah jumlah detik yang dieksekusi kueri (kueri yang dieksekusi dalam 0,5 detik memiliki peluang 50% untuk ditangkap, kueri yang dieksekusi dalam 0,25 detik memiliki peluang 25% untuk ditangkap) sehingga Anda dapat memperkirakan seberapa sering sesi tertentu mengeksekusi kueri tertentu. Itu jauh dari angka pasti, terutama untuk jangka waktu yang lebih pendek dan untuk kueri yang waktu eksekusi aktualnya lebih bervariasi.
Data dalam V$ACTIVE_SESSION_HISTORY tampilan umumnya tersedia selama beberapa jam. Kemudian akan diambil sampelnya ke dalam DBA_HIST_ACTIVE_SESS_HISTORY tabel yang memotong jumlah data yang tersedia dengan urutan besarnya membuat perkiraan apa pun menjadi kurang akurat. Namun data tersebut disimpan selama interval retensi AWR Anda (secara default, itu satu minggu meskipun banyak situs meningkatkannya menjadi 30 atau 60 hari).
