LAST_NUMBER på orakelsekvens

Det er normalt, ja. Fra dokumentationen for all_sequences dataordbogsvisning , last_number er:

Dette kan genskabes med en ny sekvens:

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 hoppet op af cachestørrelsen, hvilket er normalt.

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 går ned, men afspejler nu det faktiske sidst genererede sekvensnummer. DDL har (tilsyneladende) forårsaget, at de data, der er skrevet til disken, er blevet opdateret for at afspejle, hvad der tilfældigvis er den aktuelle værdi, snarere end toppen af ​​cachen - enten den gamle cache med 20 værdier eller den nye cache med 5000 værdier. I dit tilfælde fik du 2222292447 , hvilket blot betyder, at du var ti værdier længere gennem cachen, end jeg var, da jeg kørte alter .

Værdien gemt på disken er stort set der, så hvis databasen går ned, ved den, hvor den skal hentes fra. Ved genstart vil sekvensen begynde at generere tal fra den registrerede last_number . Under normal kørsel behøver den ikke at referere tilbage til det, den opdaterer blot værdien på disken, når nye værdier cachelagres. Dette forhindrer, at sekvensnumre bliver genudstedt efter et nedbrud, uden at det er nødvendigt at foretage en dyr (langsom) låsning for at opretholde værdien i realtid - hvilket cachen trods alt er til for at undgå.

Der ville kun være et problem, hvis last_value var lavere end en faktisk genereret sekvens, men det kan ikke ske. (Nå, medmindre sekvensen er indstillet til at cykle).

SQL> select SEQ_PAGE_ID.nextval from dual;

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

Det næste sekvensnummer, der genereres, følger efter det sidste før cachestørrelsesændringen; den har ikke genbrugt en gammel værdi, som du måske har været bekymret for fra ordbogsværdien.

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 viser nu den tidligere lagrede værdi øget med cache-størrelsen på 5000. Det, der er i dataordbogen nu, ændres ikke igen, før vi har forbrugt alle 5000 værdier fra cachen, eller der sker noget andetsteds, der påvirker den - databasen bliver afvist , sekvensen bliver ændret igen osv.