Блог

Главная - Вопросы по программированию - Насколько я могу доверять ROWID Оракула в долгосрочной перспективе?

Насколько я могу доверять ROWID Оракула в долгосрочной перспективе?

#java #database #oracle #spring-boot

Вопрос:

Я работаю над небольшим POC, используя Spring Boot и OracleDB.

Ситуация такова :

При запуске приложения я загружаю несколько свойств (некоторые данные) из базы данных в кэш. Там будут частые запросы, где мне понадобятся эти данные, поэтому я решил их кэшировать. Данные в базе данных редко меняются. Только время от времени кто-то может вставить/удалить/обновить пару строк с помощью sql-скрипта. В то время как он меняется, я реализовал уведомление об изменении базы данных Oracle для отправки уведомления службе загрузки spring о том, что некоторые данные изменились и данные в кэше теперь находятся в устаревшем состоянии.

В случае уведомления я получаю только псевдоколонку ROWID, которую можно использовать для указания на то, какая часть данных из бд отличается от кэша, который у меня есть. Чтобы быть в большей безопасности, я решил кэшировать идентификаторы строк для отображения данных в кэше и объекта данных в уведомлении, которое мне отправляет DB. Работая в течение нескольких дней, я обнаружил, что идентификатор строки не меняется, но насколько я должен доверять этому неизменному поведению идентификаторов строк в долгосрочной перспективе или в производственной среде?

Несколько сценариев, объясненных для уточнения:

  1. Кэш будет перезагружаться каждый раз при перезагрузке сервера. Таким образом, изменение данных во время отключения сервера не соответствует действительности.
  2. Я (вплоть до poc) получаю каждое уведомление о вставке/обновлении/удалении в сделанном в бд с помощью sql-запроса/скрипта.

Пример события.toString() для справки:

 Connection information  : local=view-localhost/127.0.0.1:47632, remote=view-localhost/127.0.0.1:57117
Registration ID         : 1201
Notification version    : 1
Event type              : QUERYCHANGE
Database name           : orcl
Query Change Description (length=1)
  query ID=41, query change event type=QUERYCHANGE
  Table Change Description (length=1):    operation=[INSERT], tableName=SYSTEM.PRODUCT, objectNumber=73323
    Row Change Description (length=1):
      ROW:  operation=INSERT, ROWID=AAAR5rAABAAAbHZAAA

Ответ №1:

Предполагая, что ваша таблица не row_movement включена (проверьте dba_tables ).

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

В противном случае строка сохранит свой идентификатор строки.

Метки: