Ten tweede, kan ik de volgorde bereiken als ik de volgorde verander naar beNOCACHE, ongeacht ORDER/NOORDER.
ja, aangezien NOCACHE effectief is, omdat je bij elke stap een schrijfactie naar de sys.seq$-tabel dwingt, die ook via knooppunten moet worden geserialiseerd.
--
Ik zou het geaccepteerde antwoord in dat mogelijke duplicaat betwisten. er is een enorm verschil in CACHE + ORDER en NOCACHE in RAC. U negeert de CACHE niet met ORDER; alleen de effectiviteit ervan verminderen. Ik heb persoonlijk gezien dat de prestaties van een applicatie op de middelste laag drastisch achteruitgingen omdat ze NOCACHE op een reeks gebruikten en toegang hadden tot meerdere knooppunten tegelijk. We hebben hun volgorde omgeschakeld naar ORDER CACHE (omdat ze een cross-rac-volgorde wilden). en prestaties drastisch verbeterd.
samenvattend:De volgordesnelheid zal van het snelst naar het langzaamst zijn als "CACHE NOORDER"->"CACHE ORDER" en ver achter op "NOCACHE".
Dit is ook gemakkelijk te testen:
We beginnen dus met een standaardreeks:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
dwz CACHE zonder bestelling. Nu starten we twee sessies. Ik gebruik een RAC-database met 4 knooppunten 10.2.0.4 in deze test:
mijn testscript is gewoon
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 voeren we de eerste test uit (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.
dus 7-8 seconden om 100.000 herhalingen van de reeks te selecteren.
Laten we nu NOCACHE proberen (ORDER vs NOORDER is hierbij niet relevant, omdat we een schrijven naar seq$ forceren voor elke aanroep van de reeks).
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.
dus we zijn van 8 seconden naar 8 MINUTEN gesprongen voor dezelfde werkset.
hoe zit het met CACHE + BESTELLEN?
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.
dus samengevat voor 100.000 enkele oproepen CACHE NOORDER =8 secondenNOCACHE =8 minutenCACHE ORDER =25 seconden
voor cachevolgorde doet oracle veel pingen tussen de RAC-knooppunten, maar het DOESNT moet dingen terugschrijven naar seq$ totdat de cachegrootte is opgebruikt, omdat het allemaal in het geheugen wordt gedaan.
ik zou als ik jou was, een geschikte cachegrootte instellen (ps. een hoge cachegrootte belast het geheugen van de box niet, omdat Oracle niet alle nummers in RAM opslaat; alleen het huidige + laatste nummer) en overweeg BESTEL indien nodig.