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

LAST_NUMBER na věštecké sekvenci

To je normální, ano. Z dokumentace pro all_sequences zobrazení datového slovníku , last_number je:

To lze znovu vytvořit pomocí nové sekvence:

SQL> create sequence SEQ_PAGE_ID start with 2222292436 increment by 1 cache 20;

sequence SEQ_PAGE_ID created.

SQL> select sequence_name, increment_by, cache_size, last_number
  2  from user_sequences where sequence_name = 'SEQ_PAGE_ID';

SEQUENCE_NAME                  INCREMENT_BY CACHE_SIZE LAST_NUMBER
------------------------------ ------------ ---------- -----------
SEQ_PAGE_ID                               1         20  2222292436 

SQL> select SEQ_PAGE_ID.nextval from dual;

   NEXTVAL
----------
2222292436 

SQL> select sequence_name, increment_by, cache_size, last_number
  2  from user_sequences where sequence_name = 'SEQ_PAGE_ID';

SEQUENCE_NAME                  INCREMENT_BY CACHE_SIZE LAST_NUMBER
------------------------------ ------------ ---------- -----------
SEQ_PAGE_ID                               1         20  2222292456 

last_number vyskočil o velikost mezipaměti, což je normální.

SQL> alter sequence SEQ_PAGE_ID CACHE 5000;

sequence SEQ_PAGE_ID altered.

SQL> select sequence_name, increment_by, cache_size, last_number
  2  from user_sequences where sequence_name = 'SEQ_PAGE_ID';

SEQUENCE_NAME                  INCREMENT_BY CACHE_SIZE LAST_NUMBER
------------------------------ ------------ ---------- -----------
SEQ_PAGE_ID                               1       5000  2222292437 

last_number klesá, ale nyní odráží skutečné poslední vygenerované pořadové číslo. DDL (zřejmě) způsobilo, že data zapsaná na disk se aktualizují tak, aby odrážela aktuální hodnotu, nikoli horní část mezipaměti - buď starou mezipaměť s 20 hodnotami, nebo novou mezipaměť s 5000 hodnotami. Ve vašem případě máte 2222292447 , což jen znamená, že jste byli v mezipaměti o deset hodnot dále než já, když jsem spustil alter .

Hodnota uložená na disk je z velké části tam, takže pokud databáze spadne, ví, odkud ji vyzvednout. Po restartu sekvence začne generovat čísla ze zaznamenaného last_number . Při normálním běhu se na to nemusí vracet, pouze aktualizuje hodnotu na disku, když jsou nové hodnoty uloženy do mezipaměti. To zabraňuje opětovnému vydání sekvenčních čísel po havárii, aniž by bylo nutné provádět drahé (pomalé) zamykání pro udržení hodnoty v reálném čase – čemuž se má cache koneckonců vyhnout.

Problém by nastal pouze v případě last_value byla nižší než skutečně vygenerovaná sekvence, ale to se nemůže stát. (No, pokud není sekvence nastavena na cyklus).

SQL> select SEQ_PAGE_ID.nextval from dual;

   NEXTVAL
----------
2222292437 

Další vygenerované pořadové číslo následuje po posledním před změnou velikosti mezipaměti; nepoužil znovu starou hodnotu, jak jste se mohli obávat z hodnoty slovníku.

SQL> select sequence_name, increment_by, cache_size, last_number
  2  from user_sequences where sequence_name = 'SEQ_PAGE_ID';

SEQUENCE_NAME                  INCREMENT_BY CACHE_SIZE LAST_NUMBER
------------------------------ ------------ ---------- -----------
SEQ_PAGE_ID                               1       5000  2222297437 

last_number nyní zobrazuje předchozí uloženou hodnotu navýšenou o velikost mezipaměti 5000. To, co je nyní v datovém slovníku, se znovu nezmění, dokud nespotřebujeme všech 5000 hodnot z mezipaměti, nebo se stane něco jinde, co to ovlivní - databáze se vrací , sekvence se znovu mění atd.



  1. Lze %type použít s typem objektu? Je to možné, protože při pokusu o to dostávám chybu

  2. chyba mysql 1066

  3. Mysql Group V 24hodinových intervalech

  4. výběr jedinečných hodnot ze sloupce