ORACLE 10g автоматическое приращение триггер/последовательность не увеличивается, как запрограммировано

Question

Я разработать следующую последовательность на ORACLE 10 DB Wich Autoincrement столбец ID таблицы с именем t_client по (Триггер разработан также и выполнять, когда новые данные по этой таблице зарегистрирован)

вопрос заключается в том, что иногда sequecce не увеличивается на 1 , если не в . Я действительно не нахожу проблему по ее приращению на . Вот пример кода

Secuence ClientConsecutive

CREATE SEQUENCE user_owner.ClientConsecutive 
MINVALUE 0 
MAXVALUE 999999999999999999999999999 
INCREMENT BY 1 
START WITH 1 
CACHE 20 
NOORDER NOCYCLE ; 

Trigger_Client_ID

create or replace 
TRIGGER user_owner.TRIGGER_CLIENT_ID 
BEFORE INSERT ON T_CLIENT 
REFERENCING NEW AS NEW FOR EACH ROW 
DECLARE valueSequence NUMBER := 0; 
BEGIN 
SELECT ClientConsecutive.NEXTVAL INTO valorSecuencia FROM DUAL; 
:NEW.ID_CLIENTE := valueSequence; 
END; 

Когда приложение, связанное с этими объектами выполняет его на SQLDeveloper ищет деталь последовательности иногда его визуализирует

LAST_NUMBER 2 

, который является правильным, когда я зарегистрировать новые данные на пустой стол, но иногда говорит

LAST_NUMBER 21 

Любые идеи?

Answer 1

Последовательности Oracle не гарантируют отсутствие разрывов. На самом деле вы можете гарантировать, что иногда будут пробелы.

В вашем случае вы используете размер кеша по умолчанию 20. Когда база данных закрыта или кеш последовательности устарел из памяти, любые значения, являющиеся частью кеша последовательности, будут потеряны. Поэтому, если кеш содержит номера 1-20 изначально, вы делаете nextval, который возвращает значение 1, а кеш стареет из SGA, прежде чем вы вызовете nextval снова, вы ожидаете получить значение 21 при следующем вызове nextval.

Вы можете уменьшить частоту зазоров, уменьшив размер CACHE в последовательности до 1. Это не устранит пробелы - там, например, будут делаться случаи, когда транзакция откатывается, например. И это снизит производительность. В общем, вы не должны беспокоиться о пробелах, поскольку первичные ключи, созданные последовательно, по определению просто должны быть уникальными идентификаторами.