Das ist normal, ja. Aus der Dokumentation für die all_sequences Datenwörterbuchansicht
, last_number ist:
Dies kann mit einer neuen Sequenz neu erstellt werden:
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
Die last_number um die Cache-Größe nach oben gesprungen, was normal ist.
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
Die last_number sinkt, spiegelt aber jetzt die tatsächlich zuletzt generierte Sequenznummer wider. Die DDL hat (anscheinend) bewirkt, dass die auf die Festplatte geschriebenen Daten aktualisiert werden, um den aktuellen Wert widerzuspiegeln, und nicht den Anfang des Caches - entweder den alten 20-Werte-Cache oder den neuen 5000-Werte-Cache. In Ihrem Fall haben Sie 2222292447 , was nur bedeutet, dass Sie zehn Werte weiter durch den Cache gegangen sind als ich, als ich alter ausgeführt habe .
Der auf der Festplatte gespeicherte Wert ist größtenteils vorhanden, sodass die Datenbank bei einem Absturz weiß, wo sie abholen muss. Beim Neustart beginnt die Sequenz, Zahlen aus der aufgezeichneten last_number zu generieren . Während des normalen Betriebs muss es nicht darauf zurückgreifen, es aktualisiert nur den Wert auf der Festplatte, wenn neue Werte zwischengespeichert werden. Dadurch wird verhindert, dass Sequenznummern nach einem Absturz neu ausgegeben werden, ohne dass teure (langsame) Sperren erforderlich sind, um den Wert in Echtzeit aufrechtzuerhalten – was der Cache schließlich vermeiden soll.
Es würde nur ein Problem geben, wenn der last_value niedriger war als eine tatsächlich generierte Sequenz, aber das kann nicht passieren. (Nun, es sei denn, die Sequenz ist auf Zyklus eingestellt).
SQL> select SEQ_PAGE_ID.nextval from dual;
NEXTVAL
----------
2222292437
Die nächste generierte Folgenummer folgt auf die letzte vor der Änderung der Cache-Größe; Es hat keinen alten Wert wiederverwendet, wie Sie vielleicht wegen des Wörterbuchwerts befürchtet haben.
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
Die last_number zeigt jetzt den vorherigen gespeicherten Wert erhöht um die Cache-Größe von 5000 an. Was sich im Datenwörterbuch befindet, ändert sich jetzt nicht mehr, bis wir alle 5000 Werte aus dem Cache verbraucht haben oder etwas anderswo passiert, das sich darauf auswirkt - die Datenbank wird geprellt , die Reihenfolge wird wieder geändert usw.
