|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Собственно вопрос связан с валидацией/инвалидацией кеша. У меня есть скрипт-демон, который в фоновом режиме работает с базой данных, обновляя определенные записи. Для того, чтобы сократить обращения к БД, он при запуске считывает значение некоторых таблиц-справочников в кеш и при работе использует кеш. И нужно определить, когда кеш устарел и его нужно обновить. В таблицах-справочниках в качестве PK используется числовое поле, автоматически заполняемое в триггере на основе sequence. Я планирую при считывании кеша запоминать последнее (максимальное) значение PK, а при проверке использовать что-то вроде select 1 from dual where exists (select * from table1 where item_id > <last_id>) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 09:25 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Alibek B., все имхо Нюансы 1) RAC 2) последовательность не циклическая 3) палится по селекту, данные по коммиту .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 09:54 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
1. RAC нет, отдельный сервер Oracle 10g. 2. Само собой, cycle=no, order=yes. 3. Не совсем понял, можно пояснить подробнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 10:51 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Alibek B. ... Я планирую при считывании кеша запоминать последнее (максимальное) значение PK, а при проверке использовать что-то вроде select 1 from dual where exists (select * from table1 where item_id > <last_id>) Нет, в общем многопользовательском случае нельзя, даже если он (сиквенс) NOCACHE. Порядок использования захваченных сеансами значений сиквенса непредсказуем, и, по времени, после большего значения, использованного в одном сеансе, может появиться запись с меньшим значением сиквенса от другого сеанса. если и могут быть выданы такие гарантии, то определятся они не самой последовательностью, а всем протоколом изменения таблиц в конкретном случае. Наколенный result cache можно и изобразить, при особой надобности, для случая коротких справочников, (скажем, в сотню-другую значений, до малых тысяч), записывая использованные значения в биты raw-поля специальной кеш-таблицы, например. Для высоких нагрузок это станет узким местом скорее рано, чем поздно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:16 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
booby ... Наколенный result cache можно и изобразить, при особой надобности, для случая коротких справочников, (скажем, в сотню-другую значений, до малых тысяч), записывая использованные значения в биты raw-поля специальной кеш-таблицы, например. Для высоких нагрузок это станет узким местом скорее рано, чем поздно. лучше - обновляя "номер версии" кеша значением специальной выделенной для этого последовательности ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:35 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Понятно, спасибо за разъяснения. А есть ли в Oracle таймстамп последнего любого изменения таблицы (или другого объекта базы)? Что-то вроде атрибута last_ddl_time, точнее last_dml_time (если бы такой атрибут существовал). Мне нужно какое-то условие для инвалидации кеша, причем нечастое ложное срабатывание вполне допускается. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:42 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
[quot Alibek B. Мне нужно какое-то условие для инвалидации кеша, причем нечастое ложное срабатывание вполне допускается. [/quot] https://docs.oracle.com/cd/B19306_01/B14251_01/adfns_dcn.htm Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:46 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
booby лучше - обновляя "номер версии" кеша значением специальной выделенной для этого последовательности А кто будет обновлять номер версии кеша? Скрипт-демон работает с базой данных сторонней информационной системы, изменить логику которой нет возможности. Конечно можно просто периодически считывать с БД справочники, сравнивать с кешем и обновлять кеш, но хотелось бы уменьшить подобный трафик. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:47 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Как все сложно. Спасибо, похоже именно это и нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:48 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Alibek B.Как все сложно. Это гораздо проще, чем там описано. Тебе же не нужен PL/SQL обработчик и прочее Advanced Queue, достаточно обычной подписки на клиенте, а это вызов пары функций OCI. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 12:51 |
|
Можно ли быть уверенным в том, что sequence всегда возрастает?
|
|||
---|---|---|---|
#18+
Alibek B. 3. Не совсем понял, можно пояснить подробнее? 13:00 сессия 1 select nextval =100 13:01 сессия 2 select nextval =101 13:02 сессия 2 select commit 13:03 сессия 1 select commit в результате 101 будет закомичен раньше 100 "Для того, чтобы сократить обращения к БД" мож и не надо кеш, выиграете Вы 0.0001секунду, а оно того стоит .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 13:32 |
|
|
start [/forum/topic.php?fid=52&fpage=12&tid=1879916]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
76ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 179ms |
0 / 0 |