Po drugie, czy mogę osiągnąć zamówienie, jeśli zmienię kolejność na NOCACHE niezależnie od ORDER/NOORDER.
tak, ponieważ NOCACHE jest efektywnie uporządkowane, ponieważ wymuszasz zapis do tabeli sys.seq$ przy każdym inkremencie, który również musi być serializowany przez węzły.
--
Zakwestionowałbym przyjętą odpowiedź w tym możliwym duplikacie. jest ogromna różnica w CACHE + ORDER i NOCACHE w RAC. Nie negujesz CACHE za pomocą ORDER; po prostu zmniejszając jego skuteczność. Osobiście widziałem drastyczny spadek wydajności aplikacji warstwy środkowej, ponieważ używali one NOCACHE w sekwencji i uzyskiwali dostęp do wielu węzłów jednocześnie. Zmieniliśmy ich kolejność na ORDER CACHE (ponieważ chcieli zamówienia cross-rac). i wydajność znacznie się poprawiła.
Podsumowując:Szybkość sekwencji będzie od najszybszej do najwolniejszej jako "CACHE NOORDER"->"CACHE ORDER" i daleko za "NOCACHE".
Jest to również łatwe do przetestowania:
Zaczynamy więc od standardowej sekwencji:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
tj. CACHE bez zamówienia. Teraz odpalamy dwie sesje. W tym teście używam 4-węzłowej bazy danych RAC 10.2.0.4:
mój skrypt testowy jest po prostu
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;
/
/
teraz uruchamiamy pierwszy test (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.
więc 7-8 sekund, aby wybrać 100 000 iteracji sekwencji.
Teraz spróbujmy NOCACHE (ORDER vs NOORDER nie ma tu znaczenia, ponieważ wymuszamy zapis do seq$ dla każdego wywołania sekwencji).
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.
więc przeskoczyliśmy z 8 sekund do 8 MINUT dla tego samego zestawu pracy.
co z CACHE + ZAMÓWIENIE?
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.
więc w sumie za 100 000 pojedynczych wywołań CACHE NOORDER =8 sekundNOCACHE =8 minutCACHE ORDER =25 sekund
w przypadku kolejności w pamięci podręcznej Oracle wykonuje dużo pingowania między węzłami RAC , ale NIE DZIAŁA trzeba zapisywać rzeczy z powrotem do seq$, dopóki rozmiar pamięci podręcznej nie zostanie zużyty, ponieważ wszystko odbywa się w pamięci.
gdybym był tobą, ustawiłbym odpowiedni rozmiar pamięci podręcznej (np. duży rozmiar pamięci podręcznej nie obciąża pamięci urządzenia, ponieważ Oracle nie przechowuje wszystkich liczb w pamięci RAM; tylko bieżąca + końcowa liczba) i rozważ ZAMÓW w razie potrzeby.
