Миграция и объединение нескольких баз данных в одну

Question

В проекте обновления мне нужно сделать следующее:

Переместите 3 базы данных из SQL2000 в SQL2005 и объедините их одновременно. Уже есть довольно много перекрестных запросов к базе данных, используемых в SP и Views. Текущий план состоит в том, чтобы переместить каждую из старых баз данных в отдельную схему в 1 базе данных.

Это означает, что нам также придется изменить наши текущие SP и Views, теперь у нас есть:

SELECT OrderId, OrderDate FROM Sales.dbo.Orders

и ожидаем, что нам придется изменить это на

SELECT OrderId, OrderDate FROM Sales.Orders

Вопрос: как мы можем сделать это максимально автоматизированным?

Я знаю о SED и аналогичных способах изменения скриптов. Я хотел бы получить советы о том, как быть «умным» в этом, например, стратегии разделения сценариев, производительность (тонны строк INSERT INTO) и т. Д.

Примечание. Я просматривал мастер импорта / экспорта, но, очевидно, мне пришлось бы вручную устанавливать схему для каждой выходной таблицы и в любом случае исправить SP с помощью сценариев ALTER.

Answer 1

Я сделал это пару лет назад, и столкнулся с несколькими проблемами, о которых вы хотите знать.

Предположения:

• У вас есть один сервер баз данных SQL 2000 с 3 базами данных, A / B / C
• Вы хотите, чтобы все объекты оказались в SQL 2005 в базе данных A (мы будем называть это целевым объектом)
• Вы хотите в конце концов избавиться от баз данных B и C (старые источники)
• У вас нет полноценной тестовой среды, в которой вы можете автоматически восстанавливать свои производственные базы данных каждый день и повторять сценарии снова и снова до тех пор, пока они не станут правильными. (Это лучший способ, и я тоже использовал этот подход, но он трудоемкий.)

Вот мои усвоенные уроки:

Не делайте слияние и SQL 2005 не меняются в один и тот же день. Либо выполняйте слияние до того, как вы перейдете в 2005, либо после, но не пытайтесь выполнить все это за один перерыв , Это будет беспорядок, указывающий пальцем. Если бы это был я, я бы сначала поехал в 2005, чтобы убрать его с дороги. Таким образом, я знаю, что все разрывы происходят не из-за изменения схемы, и такие типы разрывов легче исправить. Вы хотите по крайней мере неделю активности конечного пользователя в окне 2005 года, прежде чем объявить о победе и перейти к слиянию.

Создавайте новые объекты в Target заранее. Даже если они не запрашиваются в ваших живых производственных приложениях, продолжайте и создавайте их сейчас. Таким образом, вы можете заполнить поддельные тестовые данные там, чтобы протестировать ваши приложения заранее. Да, это означает смешивание данных в реальном времени и тестовых данных, но, честно говоря, вы уже работаете без сети. Однако будьте осторожны с полями идентификации, поскольку в результате вы можете получить конфликтующие записи с одним и тем же идентификационным номером, но разными данными в целевых и исходных базах данных.

Создайте представления в Target заранее. Вы упомянули, что у вас есть представления, которые уже выполняют запросы между базами данных. Скопируйте их из Source to Target прямо сейчас и скажите всем другим разработчикам (докладчикам, опытным пользователям) вместо этого начать ссылаться на представления Target. Это не ускорит вашу собственную работу, но ускоряет их работу. Если вы сможете дойти до того момента, когда сможете убедиться, что они достигают цели (даже если целевые представления по-прежнему указывают на таблицы в Source), это упростит устранение неполадок в день миграции. Затем вы можете начать отказывать в разрешениях в представлениях «Источник».

Синхронизация таблиц заблаговременно. Составьте список всех таблиц, которые необходимо удалить из источников, и для каждой проанализируйте, как они обновляются. Если он только вставляется (не обновляется и не удаляется), как таблица журналов, то напишите сценарий T-SQL, чтобы начать синхронизировать его в Target. Запустите этот скрипт через задание агента SQL в периоды низкой активности на вашем сервере, например, ночью. Таким образом, когда наступит день начала работы, вам не нужно будет сдвигать столько записей, то есть окно ввода в действие будет меньше, а журналы транзакций Target могут оставаться меньше. Таблицы, которые постоянно обновляются или удаляются, не так просты, и вы сами решаете, хотите ли вы их синхронизировать. Мы сделали это для любых таблиц более миллиона строк.

Проверка на наличие конфликтов записей между исходными базами данных. Похоже, что это не относится к вам конкретно, но я отмечу это здесь на тот случай, если кто-то еще сделает слияние, и они читают это для советов. Если у вас более одной исходной базы данных, выведите список объектов. Если у вас есть два объекта с одинаковым именем, проверьте их схему. Я работал со случаями, когда в каждой базе данных у них была таблица State или Region, и они должны были быть идентичными, но у них были поля идентичности для их первичных ключей. Каждая дочерняя таблица (например, «Клиенты», связанная с таблицей «Регион») ссылалась на родительскую таблицу («Регион») по первичному ключу (поле идентификатора), который не совпадал из одной базы данных в другую. В этом случае разумнее всего заранее сделать окно отключения перед днем ​​миграции, чтобы очистить эти записи с помощью сценариев ручного обновления.

1. Отключить любые ограничения или отношения внешнего ключа
2. Изменить поля идентификации (если они являются таблицами поиска, вы можете отключить идентификацию и просто запустить с указанными вручную числами ПК)
3. Измените таблицу регионов, добавив поле NewID, соответствующее тому, чем оно станет, и поле OldID, показывающее, как оно было
4. Обновите все дочерние таблицы (Клиенты), чтобы использовать номер NewID вместо исходного
5. Обновите таблицу Region, чтобы в поле действительного идентификатора теперь было значение NewID, а в поле OldID - то, что раньше было Region. (Вы, вероятно, собираетесь что-то испортить, как пропустить детский стол, о котором вы не знали, и вы удивитесь, что это было раньше.)

Разбейте миграцию на части. Перечислите каждый сохраненный процесс во всех базах данных. Если любой из них может быть перемещен без перемещения данных, сделайте это в первую очередь. Например, если у вас есть Source.dbo.usp_RunReport и он относится только к таблицам в целевой базе данных, то сделайте это на первом этапе. Если у вас есть небольшие таблицы поиска в системе, которые используются только внутри вашего приложения, невидимы для клиентов или отчетов, поместите это также на первом этапе. Похоже, он слишком мал, чтобы беспокоиться, но идея состоит в том, чтобы уменьшить количество паники в день миграции. Чем меньше вас интересует, тем лучше вы можете устранять неполадки. Мы переместили все статические таблицы поиска (State, Region, Calendar и т. Д.) Заранее. Объем работы, требуемый на этапе 1 - просто перемещение этих небольших статических таблиц - заставил руководство понять, насколько огромным будет перемещение остальных, и это принесло нам ресурсы и время, которые мы не получили бы в противном случае.

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

В день переноса вставляйте вставки по одной таблице за раз или меньше. Вы хотите, чтобы транзакции вставки были максимально сжатыми. Чем меньше транзакций вставки, тем меньше места вам потребуется в журнале транзакций. Помните, что журнал транзакций будет расти вместе с операторами вставки даже в простом режиме. После каждого раунда вставок выполняйте проверку работоспособности, чтобы убедиться, что они работают и что у вас не останется свободного места на диске для файлов данных или файлов t-log.

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

Другие опции для исходных баз данных:

• Переименуйте их, чтобы вы могли по-прежнему запрашивать их, но приложения их не трогали
• Отсоедините их, но оставьте файлы доступными на случай, если вам понадобится устранить неполадки
• Удалите все логины и используйте новые логины для доступа к существующим базам данных на всякий случай. Затем, если чей-то отчет только для чтения полностью заблокирован, вы можете временно разрешить ему работать, введя новый логин и сообщив, что он ссылается на неверную базу данных.

После завершения обновлений перестройте индексы и статистику для Target. Если вы просто делаете непрерывные вставки, это не имеет большого значения, но если вы объединяете несколько баз данных (например, две Sales) базы данных, которые были разбиты на регионы страны), тогда вы захотите навести порядок.

ИМХО, используйте одну схему, если вы не можете оправдать выигрыш от нескольких схем. Эта последняя - всего лишь мои два цента, но, похоже, вы проделали огромную работу, чтобы перейти от 3 базы данных по 1 схеме каждая, 1 база данных с 3 схемами. Если вы не совсем уверены в том, что такое схема с тремя схемами, вы можете рассмотреть возможность использования схемы с одной схемой, иначе в будущем вы будете в очередной грязной переделке. 3 схемы имеют смысл, если у вас есть конкретные потребности в безопасности, но в противном случае, просто убедитесь, что вы получаете те деньги, которые вам нужны. Сейчас самое время перейти к одной схеме.

Answer 2

Вы можете попробовать Redgate SQL Compare и Data Compare. У них есть функция отображения схемы, которая должна позволить вам сопоставить схему dbo со схемой продаж в другой, а затем переместить таблицы и процессы. Это позволит вам не связываться с мастером экспорта SQL. Вам все равно придется рефакторинг ваших других объектов, хотя.

Я люблю эти два инструмента.

---

редактировать: Я думаю, что вы также можете получить полнофункциональную демоверсию.

---

редактирование: Кроме того, они предлагают SQL Refactor, который делает «умное» переименование. Оценка!

Answer 3

Я находился в аналогичном положении, когда у меня было несколько баз данных SQL Server 2008, которые были объединены в 1. Мое решение состояло в том, чтобы использовать задачу Transfer Server Objects служб Integration Services в новой целевой базе данных. Все данные были скопированы вместе с таблицами. После этого в очень сложном запросе я записал все хранимые процедуры / функции / представления / и т. Д. в файл и изменил все ссылки на базы данных и заново создал хранимые процедуры и другие объекты.

Хитрость с хранимыми процедурами состояла в том, чтобы записать их в порядке или в syscontraints, чтобы гарантировать, что хранимые процедуры или функции, которые ссылались на другие хранимые процедуры / функции внутри, были созданы последними.

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

Answer 4

Хорошо, поэтому мое базовое понимание вашей проблемы выглядит примерно так:

1. У вас есть три разные базы данных (т.е. Sales, Manu, Inventory)
2. Они имеют разные имена таблиц и процедур (в Manu или Inventory не существует имен таблиц / процедур в Sales)
3. Вы хотите, чтобы все таблицы / процедуры из всех трех баз данных в одной базе данных (т.е. SaleManInv)
4. Некоторые хранимые процедуры в каждой базе данных явно ссылаются на таблицы в других базах данных (т.е. Sales.dbo.lookupItem () явно ссылается на таблицу Inventory.dbo.Items)

Экспорт и импорт таблиц, похоже, не будет проблемой, что я бы сделал для проков:

1. Экспортируйте один процесс из базы данных SQL Server 2000 в базу данных SQL Server 2005, чтобы определить, нужно ли вам избавиться от «.dbo». часть перекрестных ссылок.
2. Экспорт всех процедур в текстовые файлы (одна и та же папка для всех процедур)
3. Используйте текстовый редактор с надписью «Поиск и замена в файлах» (я использую PSPAD) и замените все «Sales.dbo». с "SaleManInv.dbo.", затем все "Iventory.dbo." с "SameManInv.dbo." и т.д., чтобы преобразовать все ссылки на новую базу данных.
4. Затем запустите экспортированные и измененные процедуры в вашу новую базу данных.

Это имеет какой-то смысл? : -)

Answer 5

Не могли бы вы иметь фиктивную базу данных с именем SALES, имеющую ПРОСМОТР, который называется [Orders]:

CREATE VIEW Sales.dbo.Orders
AS
SELECT OrderId, OrderDate, ...
FROM CombinedDatabase.Sales.Orders

, а затем

ВЫБРАТЬ ... ОТ Sales.dbo.Order

все равно будет работать.

Вы не сможете ВСТАВИТЬ / ОБНОВИТЬ эту таблицу без каких-либо дополнительных jiggery-pokery.

Если бы у вас были такие журналы ПРОСМОТРОВ, чтобы они использовались, это позволило бы вам исправить код, вызвавший их !! но я не могу придумать, как это сделать; однако вы можете отключить каждый из них по очереди, запустить некоторые тесты, исправить все, что не работает, а затем перейти к следующему ... и, таким образом, устранить их путем рефакторинга, но в процессе работы у вас будет работающее приложение.

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

Если у вас есть фактические имена столбцов / таблиц, такие как «Продажи» и «Заказы», ​​я думаю, что что-то вроде SED было бы рискованно

Answer 6

Я хотел бы знать, если это такие же данные. Тем не мение. Я хотел бы создать новый столбец с именем «SourceSystem». Поэтому, когда босс прибежит после:

"- каков был объем продаж между БД system1 и db2 в 2004 году"

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