Terkadang kebijaksanaan konvensional tidak begitu konvensional, atau umum. Sebagai contoh kasus, DBA mungkin percaya bahwa kumpulan STREAMS dicadangkan secara ketat untuk proses aliran. Itu tidak terjadi karena utilitas Oracle lainnya, seperti Data Pump dan GoldenGate, menggunakan kumpulan itu. Tentu saja memilih untuk menggunakan manajemen dinamis akan secara otomatis mengalokasikan memori yang diperlukan saat permintaan dibuat, namun memori itu harus berasal dari suatu tempat. Oracle akan 'mencuri' apa yang dibutuhkannya dari buffer cache, dan itu tidak akan segera diganti. Mari kita lihat contoh pembuktiannya, menggunakan Data Pump.
'Korban' akan menjadi database Oracle 12.1.0.2 yang dikonfigurasi dengan streams_pool_size disetel ke 0 (karena Streams tidak dikonfigurasi, harapannya adalah kumpulan tidak akan digunakan) dan Manajemen Memori Bersama Otomatis dikonfigurasi (parameter sga_target dan sga_max_size adalah disetel ke nilai bukan nol):
SQL> --SQL> -- Kumpulan aliran BUKAN hanya forSQL> -- StreamsSQL> --SQL> -- Pompa data dan GoldenGate keduanya menggunakanSQL> -- itSQL> --SQL> -- Tidak menyetel ukuran untuk streamsSQL> -- pool dapat menyebabkan masalah saat isSQL> -- pertama digunakanSQL> --SQL> --SQL> -- Melihat parameter databaseSQL> -- periksa sga parameterSQL> -- untuk sizingSQL> --SQL> tampilkan parameter sgaNAME TYPE VALUE------------------------------------- -------- -------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size bilangan bulat besar 600Msga_target bilangan bulat besar 600Munified_audit_sga_queue_size bilangan bulat 1048576
Memeriksa tampilan V$SGA_DYNAMIC_COMPONENTS untuk komponen dengan ukuran saat ini bukan nol, hasil berikut akan ditampilkan:
SQL> SQL> format komponen kolom a29SQL> atur linessize 300 numwidth 12SQL> SQL> pilih komponen, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 dari v$sga_dynamic_components 4 dimana current_components> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE------------------------------ -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------ kolam bersama 176160768 146800640 176160768 0 6 TUMBUH DITANGGUHKAN 15-OKT-19 4194304kolam besar 8388608 8388608 125829120 0 1 PERKECIL Tangguhan 15-OKT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIS 4194304DEFAULT buffer cache 411041792 301989888 419430400 0 8 MENURUTKAN DITANGGUHKAN 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 TUMBUH SEGERA 15-OCT-19 4194304SQL>
Memverifikasi bahwa streams_pool_size disetel ke 0:
SQL> SQL> --SQL> -- Pastikan kumpulan aliran disetel ke SQL> -- 0SQL> --SQL> tampilkan parameter streamsNAME TYPE VALUE---------------- -------------------- ----------- ------------------- -----------streams_pool_size bilangan bulat besar 0SQL>
Ekspor Pompa Data dijalankan dan, setelah itu, komponen memori dinamis diperiksa ukurannya:
SQL> SQL> --SQL> -- Jalankan tugas ekspor Pompa DataSQL> -- dan lihat apa yang terjadi pada streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> kolom SQL> format komponen a29SQL> atur linessize 300 numwidth 12SQL> SQL> pilih komponen, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 dari v$sga_dynamic_components 4 di mana current_SIZE_COMPONSIZE_MINSIZE CU_MINSZ_S_MINS> 0; OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------ shared pool 197132288 146800640 197132288 0 11 TUMBUH SEGERA 15-OCT- 19 4194304kolam besar 8388608 8388608 125829120 0 1 PENYUSUTAN DITANGGUHKAN 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIS 4194304streams pool 8388608 0 8388608 0 2 TUMBUH SEGERA 15-OCT-19 4194304DEFAULT buffer cache 381681664 301989888 419430400 0 15 MENURUTKAN SEGERA 15-OKT-19 4194304Dibagikan TUMBUH SEGERA 15-OCT-19 41943046 baris dipilih.SQL>
Perhatikan bahwa ukuran cache buffer DEFAULT dikurangi menjadi 381681664 dari pengaturan awal 411041792, sebagian untuk membantu 'mendanai' kumpulan Streams. Menguji gagasan itu, streams_pool_size disetel ke 8M (nilai yang ditetapkan Oracle secara dinamis) dan, untuk membuat pengujian sesama mungkin, database dimatikan dan dimulai:
SQL> SQL> --SQL> -- Atur streams_pool_size ke currentSQL> -- valueSQL> --SQL> -- Matikan dan mulai databaseSQL> --SQL> ubah set sistem streams_pool_size=8M scope=spfile; Sistem diubah.SQL> SQL> shutdown segeraDatabase ditutup.Database diturunkan. Contoh ORACLE dimatikan.SQL> contoh startupORACLE dimulai.Total Area Global Sistem 629145600 byteUkuran Tetap 2927528 byteUkuran Variabel 289408088 byteBuffer Database 331350016 byteRedo Buffer 5459968 byteDatabase terpasang.Parameter memori dinamis diperiksa untuk nilai awal:
SQL> SQL> --SQL> -- Periksa ukuran dinamis komponen SGASQL> --SQL> format komponen kolom a29SQL> atur linesize 300 numwidth 12SQL> SQL> pilih komponen, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 dari v$sga_dynamic_components 4 di mana current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP--- UKURAN G-RANU_TERAKHIR_----------------OPER-RANU_TERAKHIR --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------ shared pool 155189248 146800640 155189248 0 2 TUMBUH SEGERA 15-OCT-19 4194304pool besar 125829120 125829120 125829120 0 0 STATIS 4194304java pool 4194304 4194304 419430 4 0 0 STATIS 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIS 4194304DEFAULT buffer cache 327155712 327155712 335544320 0 2 SHRINK IMMEDIATE 15-OCT-19 4194304SQL> SQL> --SQL> -- Hapus file dump sebelumnyaSQL> --SQL> !/bin /rm /u01/app/Oracle/admin/orcl/dpdump/scott.*Jalankan kembali pekerjaan Pompa Data dengan pengaturan kumpulan memori yang disesuaikan:
SQL> SQL> --SQL> -- Jalankan tugas ekspor Pompa DataSQL> -- dan lihat apa yang terjadi pada streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> kolom SQL> format komponen a29SQL> atur linessize 300 numwidth 12SQL> SQL> pilih komponen, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 dari v$sga_dynamic_components 4 di mana current_SIZE_COMPONSIZE_MINSIZE CU_MINSZ_S_MINS> 0; OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------ shared pool 197132288 146800640 197132288 0 12 TUMBUH SEGERA 15 OKT- 19 4194304kolam besar 8388608 8388608 125829120 0 1 PENYUSUTAN DITANGGUHKAN 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIS 4194304stream pool 8388608 8388608 8388608 8388608 0 STATIS 4194304DEFAULT buffer cache 381681664 264241152 381681664 0 14 TUMBUH DEFERRED 15 OKT-19 4194304Shared IO Pool 20971520 19 41943046 baris dipilih.SQL>Perhatikan bahwa cache buffer DEFAULT ditingkatkan, bukan dikurangi seperti pada contoh sebelumnya. Tidak ada memori yang 'dicuri' dari buffer cache sehingga kinerja tidak mengalami perubahan dinamis dari sumber daya. Kemungkinan masalah dengan menyetel stream_pool_size ke 0 dapat berupa penurunan kinerja saat kumpulan aliran dialokasikan karena cache buffer mengalami penyusutan pada saat yang sama kumpulan aliran berkembang. Hal ini terutama terlihat pada sistem di mana beban pengguna pada awalnya agak berat.
Seperti disebutkan sebelumnya, GoldenGate juga menggunakan kumpulan aliran dan, karena aktivitas komit yang berat pada saat proses ekstrak dimulai, dapat menunjukkan kemungkinan degradasi yang mengkhawatirkan dalam layanan yang berlangsung hingga proses ekstrak menyelesaikan aktivitas startupnya. [Proses lain yang dihasilkan oleh GoldenGate berkontribusi pada perlambatan seperti sinkronisasi file log global untuk menghapus data yang berkomitmen ke log redo.] Satu sistem telah sangat menderita ketika proses ekstrak dimulai sehingga login sistem operasi tidak dapat diselesaikan dalam waktu yang ditentukan. waktu, menyebabkan perangkat lunak pemantauan pihak ketiga melaporkan bahwa database yang berjalan di server itu tidak lagi tersedia. Menyetel stream_pool_size ke nilai bukan nol berkontribusi besar dalam meningkatkan kinerja keseluruhan saat proses ekstrak dimulai.
Pengetahuan umum bisa menjadi pedang bermata dua; untuk setiap kasus di mana pengetahuan umum berlaku mungkin ada satu atau lebih kasus di mana tidak. Satu-satunya solusi nyata adalah menguji 'kebijaksanaan' tersebut untuk memverifikasi keakuratannya. Jauh lebih baik untuk mempengaruhi sistem pengujian, pengembangan atau 'kotak pasir' dengan penyelidikan seperti itu daripada menganggap 'pengetahuan' seperti itu sebagai 'injil' hanya untuk menemukan asumsi yang menjadi dasar 'kebijaksanaan' itu salah. Mengetahui lebih baik daripada menebak; sedikit waktu yang dihabiskan dengan penyelidikan dapat menuai manfaat besar ketika tiba saatnya untuk mengimplementasikan proses baru yang melibatkan Oracle.
# # #
Lihat artikel oleh David Fitzjarrell
