Dit is normaal, ja. Uit de documentatie voor de all_sequences gegevenswoordenboekweergave
, last_number is:
Dit kan opnieuw worden gemaakt met een nieuwe reeks:
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
Het last_number sprong omhoog door de cachegrootte, wat normaal is.
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
Het last_number gaat omlaag, maar geeft nu het werkelijke laatst gegenereerde volgnummer weer. De DDL heeft (blijkbaar) ervoor gezorgd dat de gegevens die naar de schijf zijn geschreven, worden bijgewerkt om de huidige waarde weer te geven, in plaats van de bovenkant van de cache - ofwel de oude cache met 20 waarden of de nieuwe cache met 5000 waarden. In jouw geval heb je 2222292447 , wat gewoon betekent dat je tien waarden verder door de cache was dan ik was toen ik de alter uitvoerde .
De waarde die op schijf wordt opgeslagen, is grotendeels aanwezig, zodat als de database crasht, deze weet waar hij moet worden opgehaald. Bij het herstarten begint de reeks nummers te genereren van het geregistreerde last_number . Tijdens normaal draaien hoeft het daar niet naar terug te verwijzen, het werkt alleen de waarde op de schijf bij wanneer nieuwe waarden in de cache worden opgeslagen. Dit voorkomt dat volgnummers opnieuw worden uitgegeven na een crash, zonder dat dure (trage) vergrendelingen nodig zijn om de waarde in realtime te behouden - wat de cache tenslotte moet vermijden.
Er zou alleen een probleem zijn als de last_value lager was dan een werkelijk gegenereerde reeks, maar dat kan niet gebeuren. (Nou, tenzij de reeks is ingesteld om te fietsen).
SQL> select SEQ_PAGE_ID.nextval from dual;
NEXTVAL
----------
2222292437
Het volgende gegenereerde volgnummer volgt op het laatste voor de wijziging van de cachegrootte; het heeft geen oude waarde hergebruikt, zoals u zich misschien zorgen maakte over de woordenboekwaarde.
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
Het last_number toont nu de vorige opgeslagen waarde verhoogd met de cachegrootte van 5000. Wat nu in de datadictionary staat, zal niet meer veranderen totdat we alle 5000 waarden uit de cache hebben verbruikt, of er ergens anders iets gebeurt dat hierop van invloed is - de database wordt teruggestuurd , de volgorde wordt opnieuw gewijzigd, enz.