Kalawan pos pondok ieu Abdi hoyong dispel salah paham patali analisis database AWR ngajalankeun on Oracle Exadata. Pikeun ampir 10 taun, kuring terus-terusan nyanghareupan patarosan: naon kontribusi Exadata Software pikeun produktivitas? Atanapi nganggo kecap-kecap anu nembe diciptakeun: kumaha "ahli" karya database tinangtu?
Sering patarosan anu leres ieu, dina pamanggih kuring, dijawab leres kalayan ngarujuk kana statistik AWR. Ieu nampilkeun metode ngantosan sistem, anu ngarawat waktos réspon salaku jumlah waktos operasi prosesor (CPU DB) sareng waktos ngantosan tina sababaraha kelas.
Kalayan munculna Exadata, ekspektasi sistem khusus anu aya hubunganana sareng operasi Exadata Software muncul dina statistik AWR. Sakumaha aturan, nami ngantosan sapertos kitu dimimitian ku kecap "sél" (server Panyimpenan Exadata disebut sél), anu paling umum nyaéta ngantosan kalayan nami anu jelas "sél sél pinter scan", "sél multiblock. maca fisik" sareng "sél blok tunggal bacaan fisik".
Dina kalolobaan kasus, pangsa Exadata sapertos ngantosan dina total waktos réspon sakedik, sareng ku kituna aranjeunna henteu digolongkeun kana Top10 Foreground Events ku bagian Total Wait Time (dina hal ieu, anjeun kedah milarian aranjeunna dina Foreground Antosan. Bagian Acara). Kalayan kasusah anu ageung, kami mendakan conto AWR sapopoé ti para nasabah, dimana ekspektasi Exadata kalebet dina bagian Top10 sareng jumlahna sakitar 5%:
kajadian
Ngantosan
Total Waktu Antosan (detik)
Rata-rata Antosan
% waktos DB
Antosan Kelas
CPU DB
115.2K
70.4
SQL * Net leuwih data ti dblink
670,196
5471.5
8.16ms
3.3
Network
sél tunggal blok dibaca fisik
5,661,452
3827.6
676.07us
2.3
Pamaké I/O
Nyingkronkeun kasaimbangan ASM
4,350,012
3481.3
800.30us
2.1
nu lain
maca fisik multiblock sél
759,885
2252
2.96ms
1.4
Pamaké I/O
jalur langsung dibaca
374,368
1811.3
4.84ms
1.1
Pamaké I/O
Pesen SQL * Net ti dblink
7,983
1725
216.08ms
1.1
Network
scan tabel pinter sél
1,007,520
1260.7
1.25ms
0.8
Pamaké I/O
jalur langsung maca temp
520,211
808.4
1.55ms
0.5
Pamaké I/O
enq: TM - pasea
652
795.8
1220.55ms
0.5
aplikasi
Kasimpulan di handap ieu sering ditarik tina statistik AWR sapertos kieu:
1. Kontribusi magic Exadata kana kinerja database teu luhur - teu ngaleuwihan 5%, sarta database "exadatizes" kirang.
2. Upami database sapertos ditransferkeun tina Exadata kana arsitéktur "server + Asép Sunandar Sunarya" klasik, teras kinerjana moal seueur robih. Kusabab sanajan Asép Sunandar Sunarya ieu tétéla jadi tilu kali leuwih laun ti sistem gudang Exadata (anu boro mungkin keur modern arrays Sadaya Flash), lajeng ngalikeun 5% ku tilu urang meunang kanaékan pangsa I / O waits ka 15% - pangkalan data pasti bakal salamet ieu!
Duanana kacindekan ieu henteu akurat, komo deui, aranjeunna nyimpangkeun pamahaman ideu di balik Exadata Software. Exadata henteu ngan nyadiakeun gancang I / O, gawéna fundamentally béda dibandingkeun jeung server Palasik + Arsitéktur Asép Sunandar Sunarya. Lamun operasi database sabenerna "exadapted", lajeng logika SQL ditransferkeun ka sistem gudang. Panyimpen server, hatur nuhun kana sababaraha mékanisme husus (utamina Exadata Panyimpenan Indexes, tapi teu ngan), manggihan data perlu sorangan jeung ngirim DB ka server. Maranehna ngalakukeun ieu rada éfisién, jadi babagi tina Exadata has waits dina total waktu respon leutik.
Kumaha saham ieu bakal robih di luar Exadata? Kumaha ieu bakal mangaruhan kinerja database sakabéhna? Tés bakal ngajawab patarosan ieu. Contona, ngantosan hiji "sél pinter tabel scan" di luar Exadata bisa robah jadi beurat saperti Table Pinuh Scan nu I / O nyokot sakabéh waktu respon jeung kinerja degrades nyirorot. Éta pisan sababna naha éta salah, nalika analisa AWR, mertimbangkeun total persentase ekspektasi Exadata salaku kontribusi magic -na pikeun kinerja, komo deui ngagunakeun persentase ieu prediksi kinerja luar Exadata. Ngartos kumaha "persis" karya database, anjeun kudu diajar statistik AWR tina bagian "Instance Activity Stats" (aya loba statistik kalawan ngaran timer explanatory) jeung ngabandingkeun aranjeunna saling.
Sareng ngartos kumaha database di luar Exadata bakal karasa, langkung saé ngadamel klon database tina cadangan dina arsitektur target sareng nganalisis kinerja clone ieu dina beban. Sakumaha aturan, pamilik Exadata ngagaduhan kasempetan ieu.
Author: Alexey Struchenko, kapala departemén database Jet Infosystems
sumber: www.habr.com