LAST_NUMBER в последователността на оракул

Това е нормално, да. От документация за all_sequences изглед на речник на данни , last_number е:

Това може да бъде пресъздадено с нова последователност:

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 скочи с размера на кеша, което е нормално.

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 намалява, но сега отразява действителния последен генериран пореден номер. DDL (очевидно) е накарал данните, записани на диска, да бъдат актуализирани, за да отразяват това, което е текущата стойност, а не горната част на кеша - или стария кеш с 20 стойности, или новия кеш с 5000 стойности. Във вашия случай имате 2222292447 , което просто означава, че сте били десет стойности по-далеч в кеша, отколкото бях аз, когато стартирах alter .

Стойността, записана на диска, е до голяма степен там, така че ако базата данни се срине, тя знае откъде да вземе. При рестартиране последователността ще започне да генерира числа от записаното last_number . По време на нормално изпълнение не е необходимо да се обръща към това, просто актуализира стойността на диска, когато се кешират нови стойности. Това предотвратява повторното издаване на поредни номера след срив, без да е необходимо да се прави скъпо (бавно) заключване, за да се поддържа стойността в реално време - което в края на краищата трябва да избягва кешът.

Ще има проблем само ако last_value е по-нисък от действително генерирана последователност, но това не може да се случи. (Е, освен ако последователността не е настроена на цикъл).

SQL> select SEQ_PAGE_ID.nextval from dual;

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

Следващият генериран пореден номер следва последния преди промяната на размера на кеша; не е използвал повторно стара стойност, както може би сте се притеснявали от стойността на речника.

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 сега показва предишната съхранена стойност, увеличена с размера на кеша от 5000. Това, което сега е в речника на данните, няма да се промени отново, докато не изконсумираме всичките 5000 стойности от кеша или нещо се случи другаде, което го засяга - базата данни се отхвърля , последователността се променя отново и т.н.