Diff
Как предлагает DevSolar, простой способ получить различия состоит в том, чтобы сделать тщательный дамп двух баз данных (с одним выходным файлом на таблицу и в каждом файле, одной логической строкой на запись в таблице) и применить Замечательная, надежная и почтенная diff программа для файлов для каждой таблицы. Однако этот «осторожный» может быть чем-то вроде гаечного ключа в работах - вам нужно убедиться, что каждый файл данных выгружается в отсортированном порядке (а не только в физическом порядке), так что если запись появляется в обоих случаях, она появляется та же самая позиция в файле. Если данные не так упорядочены, вы получите много ложных различий.
Еще до того, как вы это сделаете, вам нужно сравнить две схемы - потому что многие различия в схеме автоматически приведут к тому, что каждая строка в двух таблицах с одинаковым именем будет иметь разные строки. Например, если таблица A из базы данных DB1 имеет 10 столбцов, а таблица A из базы данных Db2 имеет 11 столбцов, каждая строка в выгруженных данных будет отличаться.
Вам также нужно беспокоиться о некоторых других столбцах, которые могут отличаться - в частности, об автоматически назначаемых идентификационных номерах, а также значениях «время последнего обновления» или «время создания». Автоматические идентификационные номера в первичном ключе часто сильно влияют на порядок данных в таблицах, которые присоединяются к PK - вы должны рассмотреть, есть ли хороший способ обойти это. Это будет зависеть отчасти от истории баз данных; были ли они когда-то общей базой данных, которая была скопирована, изменена и теперь рекомбинируется? В этом случае может возникнуть меньше проблем, чем если бы это были две базы данных с одинаковой схемой, но у которых никогда не было общего происхождения с данными, хранящимися в ней.
Вы можете обнаружить, что лучше всего создавать представления так, чтобы структура данных, отраженная представлением, была одинаковой для обеих баз данных (даже если определение представления не одинаково из-за различий в схеме). Затем вы можете сравнить результаты вывода этих представлений. Сделанный аккуратно, это может уменьшить или минимизировать различия благодаря автоматически назначенным идентификационным номерам.
1012 * патч *
Давайте представим, что вам удалось получить сопоставимые данные, и теперь вам нужно синхронизировать небольшое количество различий. Есть ли инструмент для исправления ошибок?
Ответ вполне вероятен для того, кого вы не хотели слышать - Нет.
Одна из проблем заключается в том, что вы должны решить, каков будет требуемый результат операции. Это объединение двух баз данных, или пересечение, или что? Какую базу данных вы собираетесь изменить - первую или вторую, или обе?
Строки, удаленные из одной базы данных, которые появляются в другой, могут быть удалены из другой или вставлены в одну. Вставленные строки являются зеркалом удаленных строк и требуют аналогичной обработки. Это было легко ...
Если по каким-либо критериям в обеих базах данных появляется «одна и та же строка», но есть различия в полях (столбцах), то вам нужно выполнить более хитрую работу. Вы должны решить, какие из разных столбцов следует изменить в базе данных, которую вы в настоящее время модифицируете. Стандартные инструменты Unix (такие как diff) предназначены для линейных различий. В этот момент я бы, вероятно, заглянул в Perl (но Python или другие языки сценариев подойдут), взяв записи различий для таблицы вместе с именем таблицы и списком столбцов (чтобы можно было связать поля в данных с колонками в базе данных), а затем организуйте для него генерацию соответствующих операторов. Типы могут быть фактором - вашему утверждению UPDATE может потребоваться заключать в кавычки строки, а не заключать в кавычки числа для обновлений. Вам также необходимо знать первичный ключ, чтобы вы могли определить строку, подлежащую обновлению. Вывод будет подходящим набором операторов UPDATE, которые преобразуют первую версию таблицы во вторую.