sql >> Databáze >  >> RDS >> Oracle

Hodnoty Oracle Sequence nejsou objednány

Za druhé, mohu dosáhnout pořadí, pokud změním pořadí na beNOCACHE bez ohledu na ORDER/NOORDER.

ano, protože NOCACHE je fakticky pořádek, protože vynucujete zápis do tabulky sys.seq$ při každém přírůstku, který se také musí serializovat přes uzly.

--

Zpochybnil bych přijatou odpověď v tomto možném duplikátu. je obrovský rozdíl v CACHE + ORDER a NOCACHE v RAC. CACHE nepopíráte pomocí ORDER; jen snižuje jeho účinnost. Osobně jsem viděl, jak se výkon aplikací střední vrstvy drasticky snížil, protože používali NOCACHE na sekvenci a přistupovali na více uzlech najednou. Přepnuli jsme jejich sekvenci na ORDER CACHE (protože chtěli cross-rac objednávku). a výkon se výrazně zlepšil.

shrnuto:Rychlost sekvence bude od nejrychlejší po nejpomalejší jako "CACHE NOORDER"->"CACHE ORDER" a daleko za "NOCACHE".

To je také snadno testovatelné:

Začneme tedy standardní sekvencí:

SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;

Sequence created.

tj. CACHE bez pořadí. Nyní spustíme dvě sezení. V tomto testu používám 4uzlovou databázi RAC 10.2.0.4:

můj testovací skript je jednoduše

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;                                                   
/ 
/

nyní spustíme první 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.

takže 7-8 sekund na výběr 100 000 iterací sekvence.

Nyní zkusme NOCACHE (ORDER vs NOORDER je pro to irelevantní, protože vynucujeme zápis do seq$ pro každé volání sekvence).

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.

takže jsme u stejné pracovní sady skočili z 8 sekund na 8 MINUT.

co 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.

takže v souhrnu za 100 000 načtení jednoho volání CACHE NOORDER =8 sekundNOCACHE =8 minut CACHE ORDER =25 sekund

pokud jde o pořadí mezipaměti, Oracle dělá hodně pingů mezi uzly RAC, ale NEPROVEDE musíte zapisovat věci zpět do seq$, dokud se nevyčerpá velikost mezipaměti, protože se to všechno dělá v paměti.

Na vašem místě bych nastavil vhodnou velikost mezipaměti (p.s. vysoká velikost mezipaměti nezatěžuje paměť boxu, protože Oracle neukládá všechna čísla do RAM; pouze aktuální + konečné číslo) a zvážil V případě potřeby OBJEDNEJTE.




  1. 4 Datové typy, které budou v SQL Serveru zastaralé

  2. Datetime stejný nebo větší než dnes v MySQL

  3. Jak obejít MySQL Chyba tabulky nelze znovu otevřít

  4. Celý proces obnovení databáze SQL Server z příkazového řádku