Есть ли хороший способ проверить правильность схемы базы данных после обновления или миграции?

У нас есть клиенты, которые переходят с одной версии базы данных на другую (точнее, с Oracle 9i на Oracle 10g или 11g). В одном случае клиент экспортировал старую базу данных и импортировал ее в новую, но по какой-то причине индексы и ограничения не были созданы. Возможно, они сделали это специально, чтобы ускорить процесс импорта, но мы все еще выясняем причину.

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

Обновлять

Спасибо за ответы, предлагающие использовать коммерческие инструменты и / или инструменты с графическим интерфейсом, но нам действительно нужно что-то бесплатное, что мы могли бы упаковать с нашим продуктом. Он также должен управляться командной строкой или сценарием, чтобы наши клиенты могли запускать его в любой среде (unix, linux, windows).


database import oracle database-migration ddl
person Javid Jamae    schedule 26.08.2010    source источник

Ответы (4)


arrow_upward
3
arrow_downward

Предполагая единую схему, что-то вроде этого - дамп USER_OBJECTS в таблицу перед миграцией.

 CREATE TABLE SAVED_USER_OBJECTS AS SELECT * FROM USER_OBJECTS

Затем для проверки после миграции

 SELECT object_type, object_name FROM SAVED_USER_OBJECTS
 MINUS
 SELECT object_type, object_name FROM USER_OBJECTS

Одна из проблем заключается в том, что если вы намеренно удалили объекты между версиями, вам также потребуется удалить из SAVED_USER_OBJECTS. Также это не сработает, если существует неправильная версия объектов.

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

Вы также можете сделать хэш/контрольную сумму для object_type||object_name для всей схемы (сохранить до/сравнить после), но стоимость вычисления не будет сильно отличаться от сравнения двух таблиц по индексам.

person JulesLt    schedule 26.08.2010
comment
+1 за простоту, хотя он не фиксирует отсутствующие ограничения. - person DCookie; 27.08.2010
comment
Хороший момент - и, конечно, любые сгенерированные системой имена (например, ограничения) могут измениться. Вам нужно будет сделать что-то подобное для содержимого ограничения (не имени) в ALL_CONSTRAINTS. - person JulesLt; 27.08.2010
comment
Интересное решение. Я не знал об этом. Отсутствующие ограничения были причиной, по которой мы начали изучать это, поэтому мне также придется изучить соответствие содержимого ограничений. Спасибо за совет! - person Javid Jamae; 27.08.2010

arrow_upward
1
arrow_downward

Если вы готовы потратить немного, DBDiff — эффективная утилита, которая делает именно то, что вам нужно.

http://www.dkgas.com/oradbdiff.htm

person Eton B.    schedule 26.08.2010

arrow_upward
1
arrow_downward

В SQL DEVELOPER (бесплатная утилита Oracle) есть функция различий схемы базы данных. Стоит попробовать.

Надеюсь, поможет.

SQL Developer — скачать

Рони.

person Roni Vered    schedule 26.08.2010
comment
Мы могли бы предложить администраторам баз данных наших клиентов сделать это, но мы надеялись на утилиту командной строки, которая давала логический ответ, который мы могли бы встроить в скрипт. - person Javid Jamae; 26.08.2010

arrow_upward
0
arrow_downward

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

person TMN    schedule 26.08.2010