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

[osipov_dv]

по-моему про права и пользователей забыли, или ваш замечательный legacy, работает как это «принято» из под sa?
и еще, вот так вы включаете обратно ограничения, но чтобы они стали trusted надо делать
Восстанавливаем проверку ограничений:
EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CHECK CONSTRAINT all'

[DrPass]

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

[fadeinmad]

Да, именно второй кейс и был описан. В данной задаче требовались только данные с продакшен-сервера, чтобы найти причину возникновения бага. Сам сервер так и продолжил работу, как и раньше. А воспроизведение ситуации для поиска ошибки велось уже на компьютере с локально установленной базой, на которой ты сам себе админ. Поэтому проблем с правами доступа не было.

[osipov_dv]

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

[gotch]

Я решил использовать виртуальную машину Oracle VM VirtualBox с Windows 10 (можно взять тестовый образ для браузера Edge отсюда). На виртуальную машину был установлен SQL Server 2016 и на нем из бэкапа была восстановлена база данных приложения (инструкция).

Вот на этом и стоило остановиться. А вдруг баг вопроизводится только на родной платформе.

[DrPass]

В случае с MS SQL чаще бывает наоборот. Количество говнозапросов, которые успешно переваривает 2016, больше, чем те, с которыми справляются 2014, 2012 и 2008.

[fadeinmad]

Такая вероятность была минимальна. Основное подозрение было на сами данные в базе. Некий неучтенный кейс поведения приложения, возможно нарушающий консистентность данных. Остановиться на Server 2016 я не мог, так как для базы требовалось дополнительное окружение (другие базы, сильная связанность данных), настройка которого потребовала бы гораздо большего времени.
Однако, в статье описан не сам поиск бага, а способ, как можно вытащить данные из бэкапа новой версии на сервер более старой версии. Поиск бага — всего лишь причина, по которой пришлось это сделать.
Поводов для использования этого способа немного, но они могут возникнуть. И, как написано в заключении, надеюсь, что это никому не понадобится.

[speshuric]

Как обрабатываются поля с timestamp?
Как обрабатываются триггера? А DDL? А Logon?
Как переносить BLOBы? А с учетом хранения в filestream?
Нормально ли обрабатываются дурацкие set ansi nulls off?
Что делать, если объекты содержат синтаксические ошибки?
… И еще вагон граблей

[fadeinmad]

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

[W001fer]

В принципе, описан единственный способ скопировать базу с новой версии скуля на более старую. Был в свое время такой опыт — разработка велась на версии 2008, а боевая площадка была на 2005, страшно матерились постоянно по этому поводу :) То разработчики «забудут», что каких-то инструкций в 2005 нет и приходилось переделывать, то вот так же надо быстро базу с дева в бой запустить. Весело было. В целом все верно, забыли только хранимые процедуры, они таким методом не переносятся, их надо из студии Create To и вперед :)

[fadeinmad]

Хранимые процедуры переносятся: код их создания будет присутствовать в скрипте генерации базы. Есть возможность выгрузки только скриптов хранимых процедур.
Проверено для Sql Server 2014 и Microsoft SQL Server Management Studio 12.0.

[W001fer]

Эххх, совсем старый стал, отстал от жизни :) В 2008 часть БД, которая относится к Programmability не переезжала в процессе генерации скрипта создания базы, в современных не проверял, всегда придерживаюсь правила, что дев, тест и прод — одной версии. Во избежание, так сказать.