sql >> データベース >  >> RDS >> Oracle

Oracleシーケンスの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を実行したときよりも、キャッシュを介して10個の値が離れていたということです。 。

    ディスクに保存された値は主にそこにあるため、データベースがクラッシュした場合、どこから取得するかがわかります。再起動すると、シーケンスは記録された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の値をすべて消費するか、キャッシュに影響を与える何かが発生するまで、再び変更されません。データベースがバウンスされます。 、シーケンスが再度変更されるなど。



    1. 2つのテーブルの重要なマージ

    2. データの切り捨て:日時の値が正しくありません:''

    3. MySQLサーバーとMicrosoftSQLServer2008の両方でNHibernateを使用する方法

    4. jquerydatatableを使用してページングの並べ替えと検索を追加する