Oracle XE в качестве локальной базы данных восстановления и Oracle Standard в качестве основной базы данных

Question

Я просто хотел узнать, что вы, ребята, думаете по этому поводу.
У меня есть приложение, написанное на Visual Basic .Net в качестве внешнего интерфейса, и база данных Oracle 11g Standart в качестве внутреннего. Таким образом, у меня есть около 20 ПК, которые запускают это приложение локально. Они все вставляют, обновляют, удаляют данные в этой единой базе данных. Я хочу разработать решение на случай, если база данных сервера выйдет из строя или не сможет оставаться в сети. Так что я думаю о наличии оракула 10g XE на каждом ПК. Таким образом, все данные будут храниться в локальной базе данных. Я думаю о том, чтобы периодически запускать процесс (например, каждые 15 минут) для отправки / получения данных на / с главного сервера. Что вы думаете об этой стратегии?

Answer 1

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

Каждый POS имеет свои данные в обновляемых материализованных представлениях . То есть он может читать и записывать свои собственные данные в локальную базу данных XE. Эти материализованные представления являются частью группы репликации, которая синхронизирует свои данные с основной таблицей в основной базе данных. В противном случае основная база данных отправляет данные своего продукта в материализованные представления только для чтения в базах данных POS. Ценность этой архитектуры в том, что POS всегда подключаются к своим локальным базам данных XE и никогда не подключаются к основной базе данных. Это намного чище, чем в большинстве случаев подключаться к центральной базе данных и переключаться на локальные базы данных в чрезвычайной ситуации.

К сожалению, документация немного сбивает с толку, потому что она называется Advanced Replication и вообще не упоминает "базовую репликацию". Но базовая репликация охватывает большинство вещей: расширенная репликация - это, в основном, записываемые материализованные представления и репликация с несколькими мастерами, ни одна из которых вам не нужна. Я не говорю, что репликация проста, потому что она охватывает некоторые хитрые концепции. Но использование встроенной функциональности Oracle, безусловно, должно быть лучше, чем использование собственной.

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

Answer 2

Мне доставило «удовольствие» попытаться сделать именно такое решение более надежным в POS-системе на основе SQL Server. Как говорит Винсент, это сложный процесс, чреватый непредвиденными кошмарными сценариями и сложным в обслуживании кода (например, ужасные файлы .bat DOS, которые мне пришлось написать). Я должен согласиться с ним, что это более надежное решение для использования сценария ожидания.

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

Answer 3

Это звучит как ужасная идея. Дублирование данных из одной базы данных в другую - сложная тема. Процесс, который вы описываете, включает в себя 20 дубликатов!

Для использования в случае сбоя вам также потребуется механизм двусторонней репликации: 20 клиентов будут продолжать обновлять свою локальную базу данных. Как вы справляетесь с одновременными обновлениями ? Один только процесс слияния с 20 базами данных будет стоить столько ресурсов, что было бы дешевле иметь испытанный профессиональный процесс аварийного восстановления (Disaster Recovery).

С другой стороны, настоящая резервная база данных будет проще для развертывания, проще для тестирования, проще для поддержки и будет стоить меньше ресурсов. Я предлагаю вам не изобретать велосипед:)

Edit:

Кстати, если вам нужен план резервного копирования и восстановления, дублирование базы данных НЕ является решением проблемы. Предлагаю вам прочитать онлайн документацию по восстановлению:

• Основы резервного копирования и восстановления базы данных Oracle
• Расширенное руководство пользователя для Oracle Database Backup and Recovery