хотя здесь тоже не отражен случай, что определение просто выгрузилось из Library Cache
Насколько помню, в более ранних версиях про это было написано

PS. Но ты продолжай -- и мы поразвлекаемся и ты таки что-то новое узнаешь

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

В моем примере нет потери чисел, и нет сбоев, все работает штатно.
Все числа сиквенса были успешно получены, все находятся в таблице.
Есть наблюдаемый разрыв внутр сессии, т.к. currval намеренно (и я считаю полезно для программиста)
возвращает текущее значение не глобального объекта, а запомненного последнего значения для этой сессии.

Следствие: две разные сессии которые вызовут currval на одном объекте ВСЕГДА увидят разные числа.
Пока я только пользовался nextval, все эти тонкости мне были незаметны. А когда заметил, углубился потому что мне интересно.

Да ну, неужели?




Шучу. Я в работе не натыкался, но на неделе видел в документации, оракл об этом очень недвусмысленно говорит.
Вроде еще есть ограничения на внутренние селекты.

> Почему нужно сомневаться что currval вернет тоже значение что и предыдущий nextval
Это потому, что не написано "предыдущий nextval для этой сессии". В многопользовательском режиме это существенное различие, особенно когда в следующей строчке таким же языком описывается nextval независим от сессии.

Возможно это мои тараканы, когда я работал редактором тех документации я обращал внимание на такие мелочи.

Вы много раз говорили про "документированное поведение", но ссылку на документацию так и не нашли. Вряд ли найдете.

Думаю, что в официальной документации "currval - в контексте сессии, а nextval - глобальный" так нигде и не упомянуто.

По этой причине, Ораклу пришло много баг репортов, и их отделу техподдержки пришлось писать аж целую объяснительную.

https://support.oracle.com/knowledge/Oracle Database Products/2588246_1.html

Давайте я лучше новый вопрос задам на понимание сиквенс.

Вот этот самый кэш сиквенса (который длиной двадцать по умолчанию, и может повлиять на скорость), он глобальный для БД, или свой на каждую сессию? (этого нет в доках, надо подумать).

Точно, у меня так и есть: сиквенс используется чтобы установить порядок, в котором импортировались данные через заданный канал.
Поскольку глобальный сиквенс - это монотонно увеличивающийся безоткатный счетчик, это должно надежно работать.

Признаю ошибку. Я это сообщение от env не заметил. В нем действительно Оракл ясно все объясняет используя термин "юзер", включая невозможность одного юзера увидеть значения полученные другим, а также возможность юзеру продолжать пользоваться последним значением, даже если другой юзер его увеличит.

Я гуглил довольно старательно, но вместо "юзер" искал упоминания сессии.

Зная, что в среде Оракла иногда "юзер и схема" используются взаимозаменяемо, хочется услышать мнение опытных товарищей:
в вышеупомянутом описании работы сиквенсов, было бы правильно использовать слово сессия, или юзер (который с именем и паролем)?

Терзают сомнения, потому что я наблюдал эффект в контексте двух сессий, одного юзера.

Env, извини дружище. Я не увидел твой текст, глаза искали ссылку.

Отвечу на ранее заданный собственный вопрос: кэш для сиквенсов является глобальным, поэтому "запоминание" последнего значения в currval каждой сессии с этим кэшем не связано.

Нерешенным остался вопрос, можно ли подсмотреть какое последнее число было выдано сиквенсом, не в текущей сессии, а глобально.

Или подсмотреть какое следующее число выдаст nextval, при этом не увеличивая сиквенс.

Эти два вопроса не совсем одно и то же, ответы могут различаться больше чем на 1 при штатной работе системы.


Пошерстив интернет и прочитав ответы умных людей, пришел к выводу что эта информация недоступна ни программисту, ни ДБА.

Хочешь знать какое будет следующее значение - бери его через nextval, и мирись с инкрементом.
Хочешь знать какое было последнее выданное в любой из сессий - никак. По крайней мере, гуру с интернета так считают.

А вот это Ваши фантазии. Никто нигде монотонное увеличение не обещает.


Я сначала удивился, но теперь думаю что вы или пытаетесь намекнуть на циклы в счетчике (у меня цикл выключен), или возможно забыли определение монотонности последовательности.

Например, последовательность натуральных чисел 1,2,3,7,42,314,1000 является монотонно увеличивающейся, потому что каждое следующее значение строго больше предыдущего.

А что вы имели в виду?

Кэш действительно глобальный, один на целый сиквенс.
Не огорчайтесь, это неочевидно. (и наверное, мне не стоило упоминать сессии вблизи этого вопроса, это могло запутать).

К этому выводу можно прийти из опыта, через рассуждения или эксперимент.
У меня опыта мало, поэтому я проверил свои рассуждения экспериментом. Действительно, глобальный.
В нем лежат (а иногда пропадают бесследно) числа последней блочной аллокации, чтобы из-за каждого +1 на диск не писать.

А я имел в виду, что записи, вставленные из разных сессий, а потом отсортированные в
порядке времени вставки, могут показать последовательность 1, 10, 2, 11, 3. Так что для
Ваших нужд последовательности бесполезны чуть менее чем совсем.


Хорошо вы меня успокоили что сиквенс монотонный, но обратили внимание на проблему
со вставками его использующие.

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

С одной сессией все понятно: если я вставляю несколько строчек сразу, они обработаются в любом порядке.
Так устроен не только Оракл, это общий принцип. Если мне важен порядок, я буду вставлять по одной строке.

Если интересно, давайте разберем конкретный случай:
Есть таблица, сиквенс и "before-insert" триггер. Поскольку в 11.2 еще не было автонумерации строчек,
кодер использует триггер и сиквенс чтобы создать уникальные ID для основного ключа.

Теперь две сессии (или юзера, или еще две чего-то независимых) вставляют по одной строчке наперегонки:
первая A, а вторая - X.

Тригер их увидет в каком-то неизвестном заранее порядке, возможно одновременно на многоядерном процессоре - я не знаю.
Но исполнение триггера сериализуется на сиквенсе, где вызов nextval послужит механизмом синхронизации для строгой очередности.
Допустим мы получили А1-Х2, первая сессия обогнала вторую. Строки были помечены в триггере с намеком на очередность, но строки еще не вставлены.

Я понимаю вы говорите что эти строки могут на самом деле вставиться в таблицу в порядке X2-A1, и что существует какой-то дополнительный счетчик операций, который сможет показать что Х2 "физически" вставилась первой, а А1 - второй.

Возможно, но это должно влиять на бизнес-логику. Я постулирую что порядок присвоенный в триггере является единственно верным для определения очередности, и всегда отсортирую А1-Х2 исходя из этого. Поэтому невидимая для меня деталь что вставка двух строчек имела какую-либо очередность не должна ни на что повлиять. Как триггер сказал - такая и последовательность.
Я даже не знаю как отсортировать в порядке времени вставки. Это возможно? Это используют? Зачем?

Вы считаете, есть случаи когда нужно беспокоиться о порядке в которой строчки были вставлены? Я не сумел придумать пример где это было бы полезно.

в какой ситуации, выполняя запросы вида insert into tab(id, ts) values (seq.nextval, systimestamp), мы получим расхождение в очередности id и ts?

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

В моем случае односессионной записи по одной строке это бы не повлияло, а вот в другом месте я мог сделать ошибку.

Ну и ну! По умолчанию присваивает уникальные, но не обязательно увеличивающиеся номера? Что так трудно?

Тьфу, дочитал, отбой. Это похоже относится только к кластерам, где действительно монотонность стоит дорого.