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.