Kedua, Dapatkah saya mencapai pemesanan jika saya mengubah urutan menjadi beNOCACHE terlepas dari ORDER/NOORDER.
ya karena NOCACHE dipesan secara efektif karena Anda memaksa penulisan ke tabel sys.seq$ pada setiap kenaikan, yang juga harus membuat serial di atas node.
--
Saya akan membantah jawaban yang diterima dalam kemungkinan duplikat itu. ada perbedaan besar dalam CACHE + ORDER dan NOCACHE di RAC. Anda tidak meniadakan CACHE dengan ORDER; hanya mengurangi efektivitasnya. Saya pribadi telah melihat kinerja aplikasi tingkat menengah menurun secara drastis karena mereka menggunakan NOCACHE secara berurutan dan mengakses beberapa node sekaligus. Kami mengubah urutan mereka ke ORDER CACHE (karena mereka menginginkan pesanan lintas ras). dan kinerja meningkat secara drastis.
Singkatnya:Kecepatan urutan akan dari yang tercepat ke yang paling lambat sebagai "CACHE NOORDER"->"CACHE ORDER" dan jauh di belakang "NOCACHE".
Ini juga mudah diuji:
Jadi kita mulai dengan urutan standar:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
yaitu CACHE tanpa perintah. Sekarang kita jalankan dua sesi. Saya menggunakan database RAC 4 node 10.2.0.4 dalam pengujian ini:
skrip pengujian saya hanya
select instance_number from v$instance;
set serverout on
declare
v_timer timestamp with time zone := systimestamp;
v_num number(22);
begin
for idx in 1..100000
loop
select daz_test.nextval into v_num from dual;
end loop;
dbms_output.put_line(systimestamp - v_timer);
end;
/
/
sekarang kita jalankan tes pertama (CACHE NOORDER):
SESSION 1 SESSION 2
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:00:07.309916000 +000000000 00:00:07.966913000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:00:08.430094000 +000000000 00:00:07.341760000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
jadi 7-8 detik untuk memilih 100.000 iterasi dari urutan.
Sekarang mari kita coba NOCACHE (ORDER vs NOORDER tidak relevan untuk ini, karena kami memaksa penulisan ke seq$ untuk setiap panggilan ke urutan).
SQL> alter sequence daz_test nocache;
Sequence altered.
SESSION 1 SESSION 2
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:08:20.040064000 +000000000 00:08:15.227200000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:08:30.140277000 +000000000 00:08:35.063616000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
jadi kami melompat dari 8 detik menjadi 8 MENIT untuk set kerja yang sama.
bagaimana dengan CACHE + ORDER?
SQL> alter sequence daz_test cache 100 order;
Sequence altered.
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:00:25.549392000 +000000000 00:00:26.157107000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:00:26.057346000 +000000000 00:00:25.919005000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
jadi secara ringkas untuk 100.000 panggilan pengambilanCACHE NOORDER =8 detikNOCACHE =8 menitCACHE ORDER =25 detik
untuk urutan cache, Oracle melakukan banyak ping antara node RAC, tetapi TIDAK harus menulis barang kembali ke seq$ sampai ukuran cache habis, karena semuanya dilakukan di memori.
saya akan jika saya jadi Anda, atur ukuran cache yang sesuai (p.s. ukuran cache yang tinggi tidak membebani memori kotak, karena Oracle tidak menyimpan semua angka dalam RAM; hanya angka + terakhir saat ini) dan pertimbangkan ORDER jika diperlukan.
