У меня есть несколько таблиц, которые необходимо реплицировать / синхронизировать в нескольких базах данных в нашем кластере SQL Server 2008.
Я знаю, что возможна репликация между несколькими экземплярами, но я ищу репликацию или синхронизацию в одном экземпляре между определенными таблицами баз данных.
Репликация / синхронизация должна происходить каждые полчаса или около того, но я не возражаю, чтобы это происходило постоянно.
Я не могу использовать DROP для целевой таблицы и INSERT (копировать) исходную таблицу, так как существует множество ограничений.
Причина в том, чтобы не управлять на уровне приложения и одновременно записывать данные в 2 разные базы данных.
Пример:
В DB1 есть T1, T2 и T3 - они постоянно обновляются приложением, APP1 работает на DB1.
DB2 должна постоянно иметь обновленную копию T1, кроме того, есть другое приложение, APP2 работает только на DB2.
И DB1, и DB2 расположены в одном экземпляре INST1.
Можно ли реплицировать T1, T2 и T3 из DB1 в DB2?
Во-первых, функции репликации SQL Server можно настроить между разными базами данных в одном экземпляре.
Настройка и администрирование репликации SQL Server может потребовать больше усилий, чем вы хотите. Предстоит принять множество решений (какие Добрый репликации? Все столбцы или только некоторые из них? Все строки или только некоторые из них? Я хочу проиндексировать целевые таблицы? Некоторые виды репликации требуют изменений в базовой модели данных. Если вы не контролируете исходный код приложений, возможно ли вообще изменить модель данных? и т. д. и т. д.) репликация может прерваться, и это может быть незаметно какое-то время, файлы журналов могут неожиданно расти.
С триггерами вы должны поддерживать код триггера в случае изменения базовых таблиц. Что будет, если триггер перестанет работать? Как повторно синхронизировать таблицы? Как долго это займет? И т. Д. И т. Д.
Как упоминалось в комментариях, одной из альтернатив репликации является использование представлений. Потенциально это означает поддержку кода в случае, если базовые таблицы (T1, T2, T3) изменяются по какой-либо причине. Из-за этого, мнения были бы моим вторым предложением.
Моим первым предложением было бы использовать функцию «синонимов», чтобы просто ссылаться на исходные таблицы. Если вы используете представления или синонимы, данные будут храниться только в одном месте (DB1), поэтому не нужно беспокоиться о синхронизации изменений между копиями данных.
Возможный минус здесь (для представлений или синонимов) заключается в том, что DB2 фактически не будет содержать данные T1, поэтому для резервного копирования и восстановления DB2 (на тестовый сервер или сервер разработки) также потребуется резервное копирование и восстановление DB1.
У меня похожая проблема и конкретная проблема с использованием синонимов. У меня есть две базы данных на одном сервере, которые обслуживают два отдельных приложения. DB1 включает информацию, относящуюся к информации страхового агента. DB2 включает информацию, относящуюся к прямой почтовой рассылке и другим маркетинговым программам.
Информация об агенте в таблице AGENT в DB1 необходима в DB2, чтобы я мог связать агента с нашей прямой почтовой рассылкой и другими маркетинговыми программами. Эта ассоциация должна быть определена с использованием отношений PK / FK. Проблема №1: Использование функции представления или табличного значения в DB2, которая ссылается на таблицу AGENT в DB1, не позволяет мне ссылаться на PK в представлении / функции как на FK в связанных таблицах в DB2. Проблема №2: Если вы определяете синоним в DB2 вне таблицы агента в DB1, вы не можете определить FK в других таблицах в DB2, ссылаясь на синоним.
Если таблица агентов в DB1 является главной, а в DB2 есть таблица агентов, которая является подписчиком DB1, я не должен иметь возможность определять дополнительные отношения, добавлять уникальный индекс и т. Д. В таблицу агентов в DB2 для приложения он предоставляет данные для.
Например, приложение, работающее с DB1, не нуждается в индексировании округа агента. Приложение, работающее под управлением DB2, должно иметь индексирование округа агента. Как я могу использовать репликацию и разрешить подписчику иметь уникальные отношения и индексы в DB2?
Если он находится в одном и том же экземпляре, быстрым решением было бы создать синоним в каждой базе данных для таблиц данных, используя имя из трех частей (представление database.schema.table). Затем вы ссылаетесь на таблицу / синоним в каждой базе данных как на локальный ресурс, и у вас есть возможность позже переключиться на репликацию, просто сохранив имя таблицы таким же.
это только от DB1-> DB2? или вы хотите изменений, которые происходят в DB2-> DB1?
Вы думали о решении, которое использует триггеры?
Также нет ничего плохого в использовании репликации сервера sql между одним и тем же экземпляром из одной базы данных в другую.