Недостатки консолидации баз данных? - PullRequest
2 голосов
/ 25 августа 2010

В организации, которая имеет два приложения, каждое из которых имеет собственный экземпляр базы данных Oracle, каковы недостатки объединения двух баз данных в одну базу данных с двумя схемами?

Резервные копии и репликация базы данных больше и медленнее, вероятно.Что еще?

Немного предыстории:

Две базы данных являются «источником золота» для соответствующих данных.Каждый из них имеет решающее значение для работы организации, и каждый фактически используется несколькими приложениями, инструментами и отчетами (но каждая база данных в основном «принадлежит» одному приложению).Часто возникает необходимость объединения данных в базах данных, чтобы связать сущности в одном с сущностями в другом.По этой причине есть ссылки на БД, соединяющие два и несколько материализованных представлений между базами данных для повышения производительности.Предпринимаются усилия по сокращению дублирования данных, и эти материализованные представления обсуждаются.Некоторые в организации хотят упразднить ссылки на БД и материализованные представления и внедрить больше веб-сервисов, чтобы сделать данные доступными в приложениях.Меня беспокоит то, что существует слишком много ситуаций, требующих сложных объединений данных между двумя базами данных, поэтому службы, которые предоставляют данные, не будут работать.Другой подход к сокращению ссылок на БД и материализованных представлений состоит в том, чтобы объединить схемы в одну базу данных, но я хочу убедиться, что не забывал о каких-либо критических недостатках этого подхода.

Ответы [ 4 ]

1 голос
/ 25 августа 2010

Трудно сказать по предоставленной информации, большой размер в мире БД будет 100 ГБ или более, поэтому 2 ДБ будут 200 ГБ. если обе базы данных не превышают 100 ГБ, то размер не должен быть важным фактором при принятии решения, репликация и синхронизация могут выполняться только при изменениях, а резервные копии не должны иметь большого значения (опять же, это зависит от специфики, например, когда резервные копии сделаны или если возможны простои или резервное копирование выполняется в непиковое время) Помимо этого, другие факторы: именование коллизий в dbo, таких как ключи, имена внешних ключей, имена таблиц и т. д. некоторые переименования таблиц, имена хранимых процедур тоже.

1 голос
/ 25 августа 2010

Самая большая проблема, с которой я столкнулся, заключается в том, что весь ваш код необходимо будет переписать для учета новой базы данных и схем.Или хотя бы посмотрел.Этот курс вводит новые ошибки.Я не знаю, как Oracle обрабатывает ссылки на разные базы данных, поэтому я приведу пример того, что я имею в виду, используя синтаксис SQL Server.Если бы я соединял две таблицы на одном и том же сервере в разных базах данных, мой выбор был бы примерно таким:

SELECT a.field1, b.field2 FROM database1.dbo.table1 a JOIN database2.dbo.table2 b ONa.myid = b.myFK

Чтобы перейти к новой консолидированной идее, вы должны написать:

SELECT a.field1, b.field2 ОТ schema1.table1 ПРИСОЕДИНЯЙТЕСЬ к schema2.table2b ON a.myid = b.myFK

Теперь вам нужно быть особенно осторожным с любыми таблицами с одинаковыми именами в обеих базах данных, это может вызвать некоторые хитрые ошибки.

Обратите внимание на этиэто не сложные изменения, но весь SQL, попавший в вашу базу данных, должен быть изучен, чтобы увидеть, будет ли он работать или скорректирован, если нет.

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

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

1 голос
/ 25 августа 2010

В одной консолидированной базе данных вы потеряете некоторую гибкость с точки зрения администратора баз данных:

  • База данных, очевидно, может иметь только одну версию (например, 10.2.0.5), что означает, что обновленияи исправления будут влиять на все схемы - это может быть плохо в случае несоответствия требований приложений нескольких поставщиков.
  • Аналогичным образом, некоторые административные задачи (восстановление базы данных A к моменту времени t) могут быть более сложными содна база данных.

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


На стороне разработки остерегайтесь коллизий пространства имен: некоторые функции являются глобальными для одной базы данных, например:

  • каталоги,
  • публичные синонимы,
  • Ссылка на БД
  • Схемы

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

1 голос
/ 25 августа 2010

Может иметь отношение к стоимости лицензии - увеличение или уменьшение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...