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

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

по-моему про права и пользователей забыли, или ваш замечательный legacy, работает как это «принято» из под sa?
и еще, вот так вы включаете обратно ограничения, но чтобы они стали trusted надо делать
Восстанавливаем проверку ограничений:
EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CHECK CONSTRAINT all'
У него же в задаче не миграция продакшен-сервера на предыдущую версию, а просто поднятие бэкапа на более старом серваке. Я, например, со вторым кейсом встречался не раз, а необходимости в первом никогда не видел, и даже не представляю, зачем оно могло бы понадобиться.
Да, именно второй кейс и был описан. В данной задаче требовались только данные с продакшен-сервера, чтобы найти причину возникновения бага. Сам сервер так и продолжил работу, как и раньше. А воспроизведение ситуации для поиска ошибки велось уже на компьютере с локально установленной базой, на которой ты сам себе админ. Поэтому проблем с правами доступа не было.
если в базе с правами все сложно, то у вас тупо даже хранимки будут выдавать не то что ожидается. Это не поднятие бэкапа, а просто перенос данных.
Я решил использовать виртуальную машину Oracle VM VirtualBox с Windows 10 (можно взять тестовый образ для браузера Edge отсюда). На виртуальную машину был установлен SQL Server 2016 и на нем из бэкапа была восстановлена база данных приложения (инструкция).

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

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

Перенос с учетом локализации, согласен, довольно сложный. Однако я заострил внимание на скрипте генерации базы. В него необходимо внести дополнительные настройки, если это потребуется.
Насчет остального, опять же, я описал основное направление и те проблемы, с которыми столкнулся. Если кто-то поделится своим опытом и дополнит эту инструкцию, будет просто замечательно.
В принципе, описан единственный способ скопировать базу с новой версии скуля на более старую. Был в свое время такой опыт — разработка велась на версии 2008, а боевая площадка была на 2005, страшно матерились постоянно по этому поводу :) То разработчики «забудут», что каких-то инструкций в 2005 нет и приходилось переделывать, то вот так же надо быстро базу с дева в бой запустить. Весело было. В целом все верно, забыли только хранимые процедуры, они таким методом не переносятся, их надо из студии Create To и вперед :)
Хранимые процедуры переносятся: код их создания будет присутствовать в скрипте генерации базы. Есть возможность выгрузки только скриптов хранимых процедур.
Проверено для Sql Server 2014 и Microsoft SQL Server Management Studio 12.0.
Эххх, совсем старый стал, отстал от жизни :) В 2008 часть БД, которая относится к Programmability не переезжала в процессе генерации скрипта создания базы, в современных не проверял, всегда придерживаюсь правила, что дев, тест и прод — одной версии. Во избежание, так сказать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации