Восстановить базу данных из файла резервной копии другой версии / издания

Я читал, что можно восстановить базу данных в SQL Server, если вы восстанавливаете из более старой версии в более новую версию по причинам обратной совместимости.

Кто-нибудь знает из рук вон, можно ли восстановить базу данных из файла * .bak для разных выпусков SQL Server? Мы перемещаем очень большую базу данных через FTP, что займет пару дней, поэтому мы бы предпочли сделать это только один раз. Если к моменту передачи базы данных по FTP никто не ответит, мы, очевидно, попробуем это и посмотрим, работает ли она путем тестирования, и ответим на наш собственный вопрос.

Ниже приведен запрос для получения сведений о версии SQL Server. Это productversionв формате {major revision}.{minor revision}.{release revision}.{build number}. В моем случае значение {release revision}имеет значение 5500для источника и 5512для цели. Так что это выглядит хорошо. Тем не менее, editionэто другое.

Запрос:

SELECT 
  SERVERPROPERTY('productversion'), 
  SERVERPROPERTY('productlevel'), 
  SERVERPROPERTY('edition')

Исходная база данных:

10.0.5500.0
SP3
Developer Edition (64-bit)

Целевая база данных:

10.0.5512.0
SP3
Enterprise Edition (64-bit)

С разработчиком на предприятие все будет в порядке, просто убедитесь, что если вы используете лицензирование процессора, у вас есть лицензии на целевом сервере, чтобы охватить все процессоры. И недостаточно просто скрыть их от SQL, если они физически связаны с машиной, вы несете ответственность за них.

Кроме того, при переходе от более низкой сборки к более высокой сборке ваша версия базы данных будет увеличиваться. Существует несколько сценариев, в которых это может быть проблематично - например, если вы используете поддержку 15 000 разделов в конкретной сборке 2008 года, она не будет работать при обновлении до конкретной сборки 2008 R2. Вы также можете полагаться на оптимизацию (и иметь обходные пути), которые на самом деле являются ошибками в старой сборке, но исправлены в новой сборке, и это может привести к снижению производительности. Также очень важно проверить все флаги трассировки, используемые в источнике, и определить, должны ли они также быть включены в месте назначения. Не берите в голову работу, логины и т. Д.

Конечно, вы не можете вернуться назад. Я никогда не пробовал незначительное понижение, например, 10.0.5512 -> 10.0.5500, но в пакете обновления или версии определенно невозможно. Так что, если у вас есть база данных 2012 года в вашем экземпляре Developer Edition, и вы хотите поместить ее в свой экземпляр 2008 в производство, вы получите свою работу за вас (см. Здесь и здесь ) - особенно если вы использовали функции 2012 года ,

Но для того, чтобы охватить другие случаи, которые могут затронуть людей в этом вопросе (например, кто-то хочет перейти от Developer -> Standard или Enterprise -> Express или что у вас есть) ...

Существуют другие редакции -> редакции редакции, которые не будут проходить так хорошо, например, от Developer -> Express, если вы использовали какие-либо функции, которые не поддерживаются в Express (и то же самое касается любой редакции, отличной от Enterprise). Некоторые примеры функций, которые вы не сможете использовать в версиях более низкого уровня (в этом случае восстановление прекратит работу в тот момент, когда оно попытается перевести базу данных в оперативный режим):

• Разметка
• Изменить захват данных
• Сжатие данных
• Прозрачное шифрование данных

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

SELECT feature_name FROM sys.dm_db_persisted_sku_features;

Я не уверен, что аудит SQL Server должен быть в этом списке - эксклюзивность редакции этой функции изменилась, поэтому она, вероятно, зависит от того, что вы делаете с ней. Есть и другие вещи, которые вы могли бы использовать, но не будут отображаться в DMV (некоторые из-за того, что они есть в вашем коде, которые DMV не анализирует, а некоторые из-за того, что ваша база данных зависит от внешних факторов, таких как агент SQL Server). Сервисный брокер и т. Д.):

• зеркальное отображение
• определенные формы репликации
• доставка журналов
• снимки базы данных
• онлайн индексация
• обновляемые распределенные разделенные представления
• сжатие резервных копий
• управление на основе политики
• план руководства
• база данных почты
• планы обслуживания
• полнотекстовый поиск

Также есть случаи, когда вы не сможете перейти от разработчика к Express из-за ограничений размера файлов (общий размер баз данных Express ограничен 10 ГБ).

Конечно, могут быть и другие ошибки, о которых вы не будете предупреждены - они не помешают миграции, но могут привести к очень разной производительности на цели. Примеры:

1. Различные ограничения памяти / ЦП в целевой редакции (или даже в базовой операционной системе на цели). Это немало людей, которые перешли с 2008 R2 Enterprise на 2012 Enterprise (CAL), где сервис искусственно ограничен первыми 20 ядрами). Это может привести к прямым различиям в производительности (например, недостаточно памяти для выполнения запроса или значительно снизить производительность параллельных запросов); более тонкие включают выбор плана, который сделан из-за различного основного оборудования.
2. Опора на такие функции, как сопоставление индексированных представлений в исходном коде, не будет автоматически соблюдаться в целевом объекте без изменения исходного кода для использования NOEXPAND. И вы можете даже не осознавать, что именно благодаря этой возможности ваши запросы неожиданно замедляются.
3. То же самое касается параллельных операций с индексами и, возможно, множества других оптимизаций, которые не приходят на ум в данный момент (к счастью, я работаю почти исключительно в корпоративной среде, поэтому мне не нужно беспокоиться об ограничениях более низких выпусков в большинстве случаев ).

ОБНОВЛЕНИЕ на основе этого дубликата :

Могут быть случаи, когда вы пытаетесь восстановить базу данных из определенной версии в более низкую версию (даже в той же версии), и вы получаете ошибки, которые менее чем полезны :

Ошибка восстановления для сервера «сервер \ экземпляр».
RESTORE не может запустить базу данных «databasename».

Это не очень интуитивно понятно. Однако если вы загляните глубже в журналы событий SQL Server, вы увидите больше полезных ошибок (только один пример):

Невозможно запустить базу данных «имя базы данных», поскольку некоторые функции базы данных недоступны в текущей редакции SQL Server.
База данных «имя базы данных» не может быть запущена в этом выпуске SQL Server, поскольку она содержит функцию разделения «_dta_pf__9987». Только редакция SQL Server для предприятий поддерживает функции секционирования.

Это не совсем так - вы также можете восстановить Evaluation Edition или Developer Edition, но это не относится к делу. Чтобы восстановить эту базу данных, у вас есть два варианта:

1. Восстановите до соответствующей версии SQL Server - это будет означать поиск или установку нового экземпляра.
2. Восстановите резервную копию на исходном сервере как новую базу данных с другим именем, удалите все и все функции Enterprise, затем снова сделайте резервную копию базы данных и восстановите ее в более ранней версии. (В этом конкретном случае я оставил имя функции раздела в сообщении об ошибке, потому что это все равно кажется отбрасываемой вещью - оно было создано помощником по настройке ядра СУБД и, возможно, было сделано кем-то, кто не совсем знаю, что они делают. Это не всегда так.)

Вариант (2) может состоять в том, чтобы просто удалить разделы и другие функции из исходной базы данных и сделать еще одну резервную копию. Но если это не сломано ...

Developer и Enterprise - это одно и то же программное обеспечение, только с разными лицензионными соглашениями.

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