2017-02-14 8 views
-1

У меня есть таблица ниже структуры таблицыатрибута порядка в последовательности оракула

ACC_ID  ACC_TIMESTAMP 
3369376 01-DEC-16 07.21.10 
3369379 01-DEC-16 07.25.06 
3369371 01-DEC-16 07.30.29 
3377485 11-DEC-16 07.47.20 

Sequence деталь:

CREATED   15-APR-14 09.38.45 
LAST_DDL_TIME 15-APR-14 09.38.45 
SEQUENCE_OWNER ACC 
SEQUENCE_NAME ACC_SEQ 
MIN_VALUE   1 
MAX_VALUE   999999999999999999999999999 
INCREMENT_BY 1 
CYCLE_FLAG   N 
ORDER_FLAG   N 
CACHE_SIZE   20 
LAST_NUMBER   87884 

Если я сортировать таблицу в ACC_TIMESTAMP порядке я вижу меньшее значение первичного ключа 3369371, вставленные в 01-DEC-16 07.30.29. Как это было бы возможно, когда более высокое значение 3369376 было уже вставлено в 01-DEC-16 07.21.10? Мой код ожидает, что увеличенный упорядоченный первичный ключ должен соответствовать отметке времени.

Я думаю, что установка ORDER_FLAG на Y будет следовать порядку, основанному на отметке времени (на первом этапе). Пожалуйста помоги.

Вывод должен быть:

ACC_ID  ACC_TIMESTAMP 
3369376 01-DEC-16 07.21.10 
3369379 01-DEC-16 07.25.06 
3369381 01-DEC-16 07.30.29 // something higher value like this, but overall sort on both timestamp and PK value. 
3377485 11-DEC-16 07.47.20 

ответ

1

От Oracle documentation:

ORDER

Укажите, чтобы гарантировать, что последовательность чисел генерируются в порядке запроса. Этот раздел полезен, если вы используете порядковые номера как временные метки. Гарантийный заказ обычно не важен для последовательностей, используемых для генерации первичных ключей.

+1

Это должно только сделать разницу в RAC условиях – APC

1

Последовательности управляются в SGA. См. this answer for more details, но в основном база данных увеличивает последовательность в порядке запросов.

Если вы не находитесь на RAC. По умолчанию RAC-узлы поддерживают собственный кеш значений последовательности, поэтому числа выполняются в блоках, а числа из разных узлов чередуются.

Но если вы не на RAC? Возможно, в коде приложения есть какое-то место, где ID и TIMESTAMP не захватываются в том же самом выражении. Или где-нибудь, где обновляется TIMESTAMP. Не зная, как заполняются ваши идентификаторы и столбцы TIMESTAMP, довольно сложно объяснить.

Кроме того, Опубликованная детали последовательности сказать ...

LAST_NUMBER 87884 

... но Опубликованная ACC_ID два порядка больше. Таким образом, возможно, что ACC_ID генерируется каким-то другим механизмом?

«Мой код ожидает, что первичный ключ с увеличенным порядком должен соответствовать отметке времени».

Это неразумная политика. Если вы не можете гарантировать, что оба столбца заполнены в одном и том же заявлении, а никогда не подменяются, вы должны выбрать один для предоставления порядка создания. Поскольку последовательности в основном обеспечивают гарантированный источник уникальных идентификаторов, вероятно, вы должны полагаться на метку времени.

Но если это действительно важно для вас, и вы на RAC, то все средства использовать предложение для того, чтобы гарантировать запрос заказа:

alter sequence ACC_SEQ order; 
+0

благодарю вас APC, Я на RAC и понял, что мне нужно изменить последовательность, чтобы включить предложение порядка. –

+0

Я полагаю, нет причин, по которым вы должны были включить эту важную информацию. – APC

Смежные вопросы