For det andet, kan jeg opnå rækkefølgen, hvis jeg ændrer rækkefølgen til at være NOCACHE uanset ORDER/NOORDER.
ja, da NOCACHE faktisk er orden, da du tvinger en skrivning til sys.seq$-tabellen på hvert trin, som også skal serialiseres over noder.
--
Jeg vil bestride det accepterede svar i det mulige duplikat. der er stor forskel på CACHE + ORDER og NOCACHE i RAC. Du negerer ikke CACHE med ORDRE; blot at reducere dens effektivitet. Jeg har personligt set ydeevnen af en mellemliggende applikation forringes drastisk, da de brugte NOCACHE på en sekvens og fik adgang til flere noder på én gang. Vi skiftede deres sekvens til ORDER CACHE (da de ønskede en cross-rac ordre). og ydeevnen er drastisk forbedret.
sammenfattende:Sekvenshastigheden vil være fra hurtigste til langsomste som "CACHE NOORDER"->"CACHE ORDER" og langt LANGT efter "NOCACHE".
Dette er også nemt at teste:
Så vi starter med en standardsekvens:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
dvs. CACHE uden ordre. Nu fyrer vi to sessioner op. Jeg bruger en RAC-database med 4 noder 10.2.0.4 i denne test:
mit testscript er simpelthen
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;
/
/
nu kører vi den første 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.
altså 7-8 sekunder for at vælge 100.000 iterationer af sekvensen.
Lad os nu prøve NOCACHE (ORDER vs NOORDER er irrelevant for dette, da vi tvinger en skrivning til seq$ for hvert kald til sekvensen).
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.
så vi er hoppet fra 8 sekunder til 8 MINUTTER for det samme arbejdssæt.
hvad med CACHE + BESTILLING?
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.
så sammenfattende for 100.000 enkeltopkald hentesCACHE NOORDER =8 sekunder NOCACHE =8 minutterCACHE ORDRE =25 sekunder
for cache-rækkefølge laver Oracle meget ping mellem RAC-knuderne, men det GØR IKKE skal skrive ting tilbage til seq$ indtil cachestørrelsen er brugt op, da det hele er gjort i hukommelsen.
Jeg ville, hvis jeg var dig, indstille en passende cachestørrelse (ps. en høj cachestørrelse belaster ikke boksens hukommelse, da Oracle ikke gemmer alle numrene i RAM; kun det nuværende + endelige tal) og overvej BESTIL hvis nødvendigt.