Oracle: Как найти отметку времени последнего обновления (любой таблицы) в схеме? - PullRequest
Новая
       25

Oracle: Как найти отметку времени последнего обновления (любой таблицы) в схеме?

8 голосов
/ 21 июля 2011

Существует схема базы данных Oracle (очень маленькая в данных, но все еще около 10-15 таблиц).Он содержит своего рода конфигурацию (таблицы маршрутизации).

Существует приложение, которое время от времени должно опрашивать эту схему.Уведомления не должны использоваться.

Если данные в схеме не были обновлены, приложение должно использовать свою текущую версию в памяти.

Если в какой-либо таблице было какое-либо обновление, приложение должно перезагрузить все таблицы в память.

Какой самый эффективный способ проверить всю схему на наличие обновлений после заданного ключевого момента (времени)или идентификатор транзакции)?

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

Я нашел этот вопрос, где такой псевдостолбец существует на уровне строк:

Как узнать, когда таблица Oracle обновлялась в последний раз

Я думаю, что нечто подобное существует на уровне схемы.

Может кто-нибудь указать мнеправильное направление?

Ответы [ 2 ]

12 голосов
/ 21 июля 2011

Мне неизвестны какие-либо подобные функции в Oracle. См. Ниже.

Лучшее решение, которое я могу придумать, - это создать триггер для каждой из ваших таблиц, который обновляет таблицу из одной строки или context с текущей датой / временем. Такие триггеры могут быть на уровне таблицы (в отличие от уровня строки), поэтому они не будут нести столько накладных расходов, как большинство триггеров.

Кстати, Oracle не может хранить идентификатор транзакции для каждой схемы, поскольку одна транзакция может повлиять на несколько схем. Можно было бы использовать V $ views для отслеживания транзакции обратно на объекты, на которые она влияла, но это было бы непросто и почти наверняка работало бы хуже, чем схема триггера.

Оказывается, если у вас есть 10g, вы можете использовать функцию флэшбэка Oracle, чтобы получить эту информацию. Тем не менее, вам нужно включить флэшбэк (который несет некоторые накладные расходы), и запрос смехотворно медленен (предположительно, потому что он на самом деле не предназначен для этого использования): 

select max(commit_timestamp) 
from FLASHBACK_TRANSACTION_QUERY 
where table_owner = 'YOUR_SCHEMA' 
      and operation in ('INSERT','UPDATE','DELETE','MERGE')

Чтобы избежать проблем с блокировкой в ​​таблице «последнее обновление», вы, вероятно, захотите поместить это обновление в процедуру, которая использует автономную транзакцию, например: 

create or replace procedure log_last_update as
pragma autonomous_transaction;
begin
   update last_update set update_date = greatest(sysdate,update_date);
   commit;
end log_last_update;

Это приведет к тому, что ваше приложение будет до некоторой степени сериализовано: каждому оператору, которому нужно вызвать эту процедуру, нужно будет дождаться завершения предыдущего. Таблица «Последнее обновление» также может быть не синхронизирована, поскольку обновление в ней будет сохраняться, даже если откат обновления, активировавшего триггер, будет выполнен. Наконец, если у вас особенно длинная транзакция, приложение может подобрать новую дату / время до завершения транзакции, что противоречит цели. Чем больше я думаю об этом, тем больше это кажется плохой идеей.

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

3 голосов
/ 09 августа 2011

dbms_stats.gather_table_stats также может помочь: http://forums.oracle.com/forums/thread.jspa?threadID=607610

   4. Statistics is considered to be stale, when the change is over 10% of current rows. 
   (As of 11g, this value can be customized per objects. Cool feature)


    .
    . 
    .

exec dbms_stats.gather_table_stats(user, 'T_STAT');

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
No row selected

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
NO

insert into t_stat select rownum from all_objects where rownum <= 20;

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
No rows selected <-- Oops
select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
NO  <-- Oops

exec dbms_stats.flush_database_monitoring_info;

select * from sys.dba_tab_modifications where table_name = 'T_STAT';
TABLE_OWNER TABLE_NAME  PARTITION_NAME  SUBPARTITION_NAME   INSERTS UPDATES DELETES TIMESTAMP   TRUNCATED   DROP_SEGMENTS
UKJA        T_STAT      20  0   0   2008-01-18 PM 11:30:19  NO  0

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT';
YES
...