LAST_NUMBER w sekwencji wyroczni

To normalne, tak. Z dokumentacji all_sequences widok słownika danych , last_number jest:

Można to odtworzyć za pomocą nowej sekwencji:

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 podskoczył przez rozmiar pamięci podręcznej, co jest normalne.

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 spada, ale teraz odzwierciedla rzeczywisty ostatnio wygenerowany numer sekwencji. DDL (najwyraźniej) spowodował, że dane zapisane na dysku zostały zaktualizowane, aby odzwierciedlały bieżącą wartość, a nie górną część pamięci podręcznej — albo starą 20-wartościową pamięć podręczną, albo nową 5000-wartościową pamięć podręczną. W twoim przypadku masz 2222292447 , co oznacza, że ​​znalazłeś się o dziesięć wartości dalej w pamięci podręcznej niż wtedy, gdy uruchomiłem alter .

Wartość zapisana na dysku jest w dużej mierze tam, więc jeśli baza danych ulegnie awarii, będzie wiedziała, skąd pobrać. Po ponownym uruchomieniu sekwencja zacznie generować liczby z zarejestrowanego last_number . Podczas normalnego działania nie musi się do tego odwoływać, po prostu aktualizuje wartość na dysku, gdy buforowane są nowe wartości. Zapobiega to ponownemu wystawianiu numerów sekwencyjnych po awarii, bez konieczności wykonywania kosztownego (powolnego) blokowania w celu utrzymania wartości w czasie rzeczywistym — czego w końcu należy unikać w pamięci podręcznej.

Problem byłby tylko wtedy, gdyby last_value był niższy niż faktycznie wygenerowana sekwencja, ale to nie może się zdarzyć. (Cóż, chyba że sekwencja jest ustawiona na cykl).

SQL> select SEQ_PAGE_ID.nextval from dual;

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

Następny wygenerowany numer sekwencyjny następuje po ostatnim przed zmianą rozmiaru pamięci podręcznej; nie użyto ponownie starej wartości, ponieważ mogłeś się martwić ze słownika.

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 teraz pokazuje poprzednią zapisaną wartość powiększoną o rozmiar pamięci podręcznej 5000. To, co znajduje się w słowniku danych, nie zmieni się teraz ponownie, dopóki nie zużyjemy wszystkich 5000 wartości z pamięci podręcznej lub coś się stanie w innym miejscu, co ma na to wpływ - baza danych jest odbijana , sekwencja jest ponownie zmieniana itd.