Как стать автором
Обновить

Перенос базы данных в более старую версию MS SQL Server

Время на прочтение 5 мин
Количество просмотров 35K
Всего голосов 19: ↑18 и ↓1 +17
Комментарии 22

Комментарии 22

Можно и Foreign Key Constraints сразу, только надо добавить анализ таблиц на связи. Но совсем грустно, если Foreign внутри одной таблицы.

Было несколько таблиц с FK внутри одной таблицы и несколько пар таблиц с взаимообратными FK

Создать пустую базу, скопировать схему с помощью RedGate SQL Compare, потом скопировать данные с помощью RedGate SQL Data Compare. Насколько я помню, можно даже из бэкап файла сравнение/копирование производить.
Если надо один раз, то можно и триальными версиями воспользоваться.

Аналогичные инструменты встроены в Visual Studio, в том числе бесплатную Community Edition.

Придерусь: VS Community Edition бесплатна только для малого бизнеса.
Индексы лучше создавать после переноса данных — это ускорит сам перенос.
На таблицу-приёмник лучше накладывать блокировку TABLOCK, а БД-приёмник должна быть с моделью восстановления simple или bulk-logged, чтобы sql server мог выполнять insert с минимальным протоколированием.
С identity-колонками по-любому геморрой.

>>7) Готово! Вы перенесли базу из нового сервера SQL в старый, хоть это и считалось невозможным. Причем перенос осуществляется примерно со скоростью передачи данных по сети, т.е. очень быстро.
1) это не считалось невозможным;
2) это гораздо медленнее чем передача данных по сети, особенно в таком исполнении, как в статье.

1) У меня была модель SIMPLE как раз, забыл об этом написать.
2) 10 ГБ база у меня скопировалась за 20 минут по 100 Мегабитному каналу (со скоростью сети было бы не менее 13 минут), так что явно не "гораздо медленнее"

10 ГБ — это объём данных? Или размер mdf-файла?

Реальный объем данных был около 9 ГБ и около 10% reserved space.

Да, при сложных индексах можно сильно выиграть.

И ещё момент странный: почему constraints отнесены на применение после переноса данных, а триггеры — нет? Триггеры же могут быть достаточно сложными.

У меня в базе триггеров было мало и они были примитивные. Так то да, можно было их тоже потом создать. Кстати триггер на INSERT сработает всего один раз после INSERT...SELECT FROM

Попробуйте создать базу с моделью восстановления simple и compatibility version совпадающей с вашей установкой.
Дальше практически в несколько кликов перенесите данные через мастер импорта.
После отсоедините файлы и перенесите на другую машину.
Это действовало для 2013 Sharepoint'a.

Обращение напрямую к прилинкованному серверу не всегда эффективно, иногда лучше использовать openqwery. По крайней мере выборки по условиям выполняются в разы быстрее.
1) Подобным методом не получится перенести таблицы, в которых есть колонки с типом XML.
Вот тут как раз openqwery тоже поможет — выполняете запрос на доноре с преобразованием XML в текст. Инсертите потом его спокойно в поля XML.
Теперь надо все в одну процедуру оформить
exec db_copy старая база, новая база
У меня лишь один вопрос, зачем?

Я же написал. Есть "шаблон" базы (голая схема без данных), который может работать в разных версиях сервера SQL. У каждого клиента свои данные в базе и своя версия SQL. Клиент хотел передать мне бэкап базы, чтобы я посмотрел ошибку в данных. Но меня нет настолько новой версии SQL, как установлена у клиента, я хочу загнать его базу в свой, более старый SQL.
Бывают и другие похожие потребности, например необходимость миграции базы с компа на комп внутри предприятия (например, из-за роста размера БД), когда на одном компе установлен новый лицензионный SQL, а на второй — старый лицензионный SQL.

А что если разбить создание схемы на два этапа, и добавить identity после вставки данных? Мне проверить негде, но alter table сможет корректно добавить identity?
Я просто оставлю это здесь
Стандартная генерация скриптов, «Schema + Data». Выручало не раз при даунгрейде версии сервера.


Спасибо за наводку! Для схемы подойдет. Скриптовать сами данные на базе размером в десятки и сотни гигабайт выглядит как ужас-ужас.

Пробовал скриптовать базу в 90 ГБ. Спешить было особо некуда, оставил на ночь. К утру скрипты успешно создались, а вот с запуском пришлось повозиться. А если ещё изменить что-то в скрипте надо — то да, ужас-ужас :)

Но для небольших баз (до ~4 Гб) вполне себе вариант.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории