Как в Oracle (и других БД) принято делать репликацию в другом формате?
Мне кажется тебе хорошо подойдёт Materialized view replication.
Причём в твоём случае это самый простой вариант: Read-Only.
Если запросы не сложные, то они смогут обновляться в инкрементальном режиме.
Причём в твоём случае это самый простой вариант: Read-Only.
Если запросы не сложные, то они смогут обновляться в инкрементальном режиме.
Ок, скорее всего подойдёт для большинства вещей, спасибо.
Тем не менее, вопрос по-прежнему стоит тот же: если у меня есть настоящая таблица, в которую в течение дня я пишу апдейты получаемые из message queue (эта часть non-negotiable, I'm afraid а потом хочу на всякий случай синхронизировать ночью, как наиболее эффективно это сделать?
Тем не менее, вопрос по-прежнему стоит тот же: если у меня есть настоящая таблица, в которую в течение дня я пишу апдейты получаемые из message queue (эта часть non-negotiable, I'm afraid а потом хочу на всякий случай синхронизировать ночью, как наиболее эффективно это сделать?
универсальный способ - добавить в таблицу колонку со свойствами:
значения уникальные,
значение в записи меняется при каждом изменении записи на большее, чем все остальные в таблице.
в mssql таким свойством обладает колонка с типом timestamp, в oracle тоже что-то такое было.
зы
если записи из таблицы могут удаляться, то тогда еще необходимо дополнительно похимичить:
при удалении записи помечаются как удаленные, но на самом деле не удаляются,
или удаленные записи перемещаются в другую таблицу.
значения уникальные,
значение в записи меняется при каждом изменении записи на большее, чем все остальные в таблице.
в mssql таким свойством обладает колонка с типом timestamp, в oracle тоже что-то такое было.
зы
если записи из таблицы могут удаляться, то тогда еще необходимо дополнительно похимичить:
при удалении записи помечаются как удаленные, но на самом деле не удаляются,
или удаленные записи перемещаются в другую таблицу.
У меня несколько доп. вопросов/уточнений/тезисов:
1. Обе БД оракловые? Если да, то даже по dblink'у можно сделать fast refresh материализованных представлений. Нужно будет только насоздавать логов на исходные таблицы, и затягивать лишние row id. Возможно, если в собранных вьюхах используются хитрые джойны, придётся немного дублировать данные. Более подробно - надо гуглить по "restrictions on fast refreshable materialized views Oracle".
2. Репликация матвьюхами фастом между двумя различными физическими серверами чревата ошибками ora-12008 (принципиальный момент, два сервера на одной виртуалке не будут сбоить так как мир неидеален, иногда один сервер отстаёт от другого на секунду, логи матпредставлений разъезжаются, и приходится их обновлять complete'ом.
3. Объёмы у тебя небольшие, так что можно и complete'ом обновлять, ничего страшного.
4. Не совсем понял, как соотносятся внешняя и внутренняя базы. Из последней ремарки следует, что они в некоторой части независимы, и общего у них только то, что описывают они одинаковые сущности.
Если есть потребность складывать во внутреннюю базу и внутренние данные, которые апдейтятся в течение дня, и внешние данные, которые нужно иногда закачивать, то матвью будут лишними и противоестественными. Проще будет пользоваться "некрасивым" вариантом, при котором на таблицы внешней базы довешиваются поля "date_updated", и происходит закачка по уже собранным тобой вьюхам в окне по date_updated (кстати, пресловутое матвью, ссылающееся на апдейтящуюся таблицу и нельзя будет создать без множественных извращений, которые тебе будут не нужны).
1. Обе БД оракловые? Если да, то даже по dblink'у можно сделать fast refresh материализованных представлений. Нужно будет только насоздавать логов на исходные таблицы, и затягивать лишние row id. Возможно, если в собранных вьюхах используются хитрые джойны, придётся немного дублировать данные. Более подробно - надо гуглить по "restrictions on fast refreshable materialized views Oracle".
2. Репликация матвьюхами фастом между двумя различными физическими серверами чревата ошибками ora-12008 (принципиальный момент, два сервера на одной виртуалке не будут сбоить так как мир неидеален, иногда один сервер отстаёт от другого на секунду, логи матпредставлений разъезжаются, и приходится их обновлять complete'ом.
3. Объёмы у тебя небольшие, так что можно и complete'ом обновлять, ничего страшного.
4. Не совсем понял, как соотносятся внешняя и внутренняя базы. Из последней ремарки следует, что они в некоторой части независимы, и общего у них только то, что описывают они одинаковые сущности.
Если есть потребность складывать во внутреннюю базу и внутренние данные, которые апдейтятся в течение дня, и внешние данные, которые нужно иногда закачивать, то матвью будут лишними и противоестественными. Проще будет пользоваться "некрасивым" вариантом, при котором на таблицы внешней базы довешиваются поля "date_updated", и происходит закачка по уже собранным тобой вьюхам в окне по date_updated (кстати, пресловутое матвью, ссылающееся на апдейтящуюся таблицу и нельзя будет создать без множественных извращений, которые тебе будут не нужны).
Тем не менее, вопрос по-прежнему стоит тот же: если у меня есть настоящая таблица, в которую в течение дня я пишу апдейты получаемые из message queue (эта часть non-negotiable, I'm afraid а потом хочу на всякий случай синхронизировать ночью, как наиболее эффективно это сделать?Я бы подумал о Writable Materialized View (в той же ссылке чуть ниже). Ты можешь менять данные в нём как хочешь, а потом вызовом обновления синхронизировать с мастер-таблицей.
Судя по описанию, у него не просто источник-приёмник. Матвьюхи могут не подойти, надо послушать продолжение условий задачи.
О, Writable Materialized View по ходу подойдут идеально, спасибо!
Оставить комментарий
bleyman
Есть внешняя база подключённая через dblink. В ней есть разные таблицы, содержащие данные о Сущностях. Есть локальная база, в которой данные о Сущностях лежат по-другому, типа, некоторые поля в другом формате, некоторые вещи которые там раскиданы по нескольким таблицам тут лежат в одной, всё такое.Я сделал немножко вьюшек которые показывают внешние данные в формате внутренних.
Как правильно сказать "а теперь перезачитай-ка всё содержимое этой таблицы из этого вью"?
truncate + select?
merge + delete?
Что-то другое?
Объёмы данных — ну, полтора миллиона записей в одной из самых больших табличек (селект на varchar(25) primary key вытаскивает 300 мегабайт, например, если тащить всё то ещё в десять раз больше будет большая часть не меняется (но в случае dblink ей же всегда приходится засасывать всё, причём для merge + delete — два раза).
То есть как-то напрягает, что эти данные, они же действительно очень редко меняются, нет ли какого-нибудь магического заклинания чтобы это всё один раз вытянуть с внешней базы, апдейтнуть что следует апдейтнуть, инсертнуть новое, удалить не найденное?