Dengan postingan singkat ini saya ingin menghilangkan salah satu kesalahpahaman terkait analisis database AWR yang berjalan di Oracle Exadata. Selama hampir 10 tahun, saya terus-menerus dihadapkan pada pertanyaan: apa kontribusi Perangkat Lunak Exadata terhadap produktivitas? Atau menggunakan kata-kata baru: seberapa “ahli” pekerjaan database tertentu?
Seringkali pertanyaan yang benar ini, menurut saya, dijawab secara salah dengan mengacu pada statistik AWR. Ini menyajikan metode menunggu sistem, yang memperlakukan waktu respons sebagai jumlah waktu operasi prosesor (DB CPU) dan waktu tunggu berbagai kelas.
Dengan munculnya Exadata, ekspektasi sistem spesifik terkait pengoperasian Perangkat Lunak Exadata muncul dalam statistik AWR. Biasanya, nama penantian tersebut dimulai dengan kata “sel” (server Penyimpanan Exadata disebut sel), yang paling umum adalah penantian dengan nama yang cukup jelas “pemindaian tabel pintar sel”, “multiblok sel pembacaan fisik” dan “pembacaan fisik blok tunggal sel”.
Dalam kebanyakan kasus, bagian dari waktu tunggu Exadata dalam total waktu respons kecil, dan oleh karena itu, waktu tunggu tersebut bahkan tidak termasuk dalam bagian 10 Peristiwa Latar Depan Teratas menurut Total Waktu Tunggu (dalam hal ini, Anda perlu mencarinya di bagian Tunggu Latar Depan Bagian Acara). Dengan susah payah, kami menemukan contoh AWR harian dari pelanggan kami, di mana ekspektasi Exadata dimasukkan dalam bagian Top10 dan totalnya sekitar 5%:
Acara
Menunggu
Total Waktu Tunggu (detik)
Rata-rata Tunggu
%waktu DB
Tunggu Kelas
CPU DB
115.2K
70.4
SQL*Net lebih banyak data dari dblink
670,196
5471.5
8.16ms
3.3
jaringan
pembacaan fisik blok tunggal sel
5,661,452
3827.6
676.07us
2.3
I/O pengguna
Sinkronkan penyeimbangan kembali ASM
4,350,012
3481.3
800.30us
2.1
Lainnya
pembacaan fisik multiblok sel
759,885
2252
2.96ms
1.4
I/O pengguna
jalur langsung membaca
374,368
1811.3
4.84ms
1.1
I/O pengguna
Pesan SQL*Net dari dblink
7,983
1725
216.08ms
1.1
jaringan
pemindaian tabel pintar sel
1,007,520
1260.7
1.25ms
0.8
I/O pengguna
jalur langsung baca suhu
520,211
808.4
1.55ms
0.5
I/O pengguna
enq: TM - perselisihan
652
795.8
1220.55ms
0.5
Aplikasi
Kesimpulan berikut sering diambil dari statistik AWR tersebut:
1. Kontribusi sihir Exadata terhadap kinerja basis data tidak tinggi - tidak melebihi 5%, dan basis data “exadatize” buruk.
2. Jika database tersebut ditransfer dari Exadata ke arsitektur “server + array” klasik, kinerjanya tidak akan banyak berubah. Karena meskipun array ini ternyata tiga kali lebih lambat dibandingkan sistem penyimpanan Exadata (yang hampir tidak mungkin dilakukan untuk array All Flash modern), maka mengalikan 5% dengan tiga kita mendapatkan peningkatan bagian I/O yang menunggu hingga 15% - database pasti akan bertahan!
Kedua kesimpulan ini tidak akurat, apalagi mendistorsi pemahaman ide di balik Perangkat Lunak Exadata. Exadata tidak hanya menyediakan I/O cepat, ia bekerja secara mendasar berbeda dibandingkan dengan arsitektur server + array klasik. Jika operasi database benar-benar “exadapted”, maka logika SQL ditransfer ke sistem penyimpanan. Server penyimpanan, berkat sejumlah mekanisme khusus (terutama Indeks Penyimpanan Exadata, tetapi tidak hanya), menemukan sendiri data yang diperlukan dan mengirim DB ke server. Mereka melakukan ini dengan cukup efisien, sehingga porsi waktu tunggu Exadata pada total waktu responsnya kecil.
Bagaimana perubahan pembagian ini di luar Exadata? Bagaimana pengaruhnya terhadap kinerja database secara keseluruhan? Pengujian akan menjawab pertanyaan-pertanyaan ini dengan baik. Misalnya, menunggu “pemindaian tabel cerdas sel” di luar Exadata dapat berubah menjadi Pemindaian Tabel Penuh yang berat sehingga I/O menghabiskan seluruh waktu respons dan kinerja menurun drastis. Oleh karena itu, ketika menganalisis AWR, adalah salah jika mempertimbangkan persentase total ekspektasi Exadata sebagai kontribusi keajaibannya terhadap kinerja, dan terlebih lagi menggunakan persentase ini untuk memprediksi kinerja di luar Exadata. Untuk memahami seberapa "tepatnya" kerja database, Anda perlu mempelajari statistik AWR di bagian "Statistik Aktivitas Instance" (ada banyak statistik dengan nama yang cukup jelas) dan membandingkannya satu sama lain.
Dan untuk memahami bagaimana rasanya database di luar Exadata, yang terbaik adalah membuat klon database dari cadangan pada arsitektur target dan menganalisis kinerja klon ini saat dimuat. Biasanya, pemilik Exadata memiliki peluang ini.
penulis: Alexei Struchenko, kepala departemen database Jet Infosystems
Sumber: www.habr.com