This is normal, yes. From the documentation for viewing the dictionary all_sequences last_number :
The last sequence number recorded on the disc. If caching is used in a sequence, the number written to disk is the last number cached in the sequence. This number is likely to be larger than the last sequence number that was used.
This can be recreated with a fresh sequence:
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 jumped from cache size, which is normal.
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 goes down, but now displays the actual last sequence number generated. DDL (apparently) caused the data written to disk to be updated to reflect what is happening as the current value, and not the top of the cache — either the old 20-digit cache or the new 5000-digit cache. In your case, you have 2222292447 , which means that you already have ten cache values than I did when I ran alter .
The value stored on disk largely exists, so if the database crashes, it knows where to get it. When restarting, the sequence will begin to generate numbers from the recorded last_number . During normal startup, it does not need to refer to this, it just updates the value on disk when caching new values. This prevents the sequence numbers from being re-issued after a failure, without having to make an expensive (slow) lock to maintain the value in real time - this is what the cache should avoid in the end.
The problem would only be if last_value was below the actual generated sequence, but this could not be. (Well, if the sequence is not set in the loop).
SQL> select SEQ_PAGE_ID.nextval from dual; NEXTVAL ---------- 2222292437
The next serial number generated follows from the last to the cache size change; he did not use the old value, as you might be concerned about the meaning of the dictionary.
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
Now last_number shows the previous saved value, increased by the size of the cache 5000. What is now in the data dictionary will not change now until we have used up all 5000 values from the cache, or something happens in another place, it affects this - the database is dropped data, the sequence changes again, etc.