Відновити базу даних із резервного файлу різної версії / видання


11

Я читав, що можна відновити базу даних у 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 Server 2012 Business Intelligence Edition до екземпляра розробника?
sdg320

Відповіді:


15

Від Developer to Enterprise буде добре, будьте впевнені, що якщо ви використовуєте ліцензування процесора, у вас є ліцензії на цільовому сервері для покриття всіх процесорів. І недостатньо просто заховати їх від 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 , Сервіс-брокер тощо):

  • дзеркальне відображення
  • певні форми реплікації
  • доставка журналів
  • Знімки бази даних
  • індексація в Інтернеті
  • оновлені розподілені перегляди з розділеннями
  • резервне стиснення
  • управління на основі політики
  • план-путівники
  • пошта бази даних
  • плани обслуговування
  • повнотекстовий пошук

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

Звичайно, можуть бути й інші готівки, про які вас не попередить - вони не завадять міграції, але вони можуть призвести до дуже різної продуктивності в цілі. Приклади:

  1. Різні обмеження пам'яті / процесора на цільовому виданні (або навіть базовій операційній системі на цілі). Це трохи людей, які перейшли з R2 Enterprise у 2008 р. До 2012 Enterprise (CAL), де послуга штучно обмежена першими 20 ядрами). Це може призвести до прямої різниці в продуктивності (наприклад, недостатньо пам’яті для задоволення запиту, наприклад, або набагато повільніше паралельного виконання запитів); більш тонкі з них включають вибір плану, який робиться через різного обладнання.
  2. Надійність на такі функції, як індексований збіг подання на джерело, не буде автоматично дотримуватися в цілі без зміни вихідного коду на використання NOEXPAND. І ви можете навіть не усвідомлювати, що ця можливість є причиною, коли ваші запити раптово сповільнюються.
  3. Те саме стосується паралельних операцій з індексом і, ймовірно, низки інших оптимізацій, які не приходять до тями в цей момент (на щастя, я працюю майже виключно в просторі Enterprise, тому мені не доведеться турбуватися про обмеження нижчих видань у більшості випадків ).

ОНОВЛЕННЯ на основі цього дубліката :

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

Помилка RESTORE для сервера "сервер \ екземпляр".
RESTORE не міг запустити базу даних "ім'я бази даних".

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

База даних "Ім'я бази даних" неможливо запустити, оскільки частина функціональних можливостей бази даних недоступна в поточній версії SQL Server.
База даних "Ім'я бази даних" не може бути запущена в цій редакції SQL Server, оскільки вона містить функцію розділу "_dta_pf__9987". Тільки Enterprise Edition SQL Server підтримує функції розділу.

Тепер це не зовсім вірно - ви також можете відновити програму Evaluation Edition або версію для розробників, але це не в курсі. Щоб відновити цю базу даних, у вас є два варіанти:

  1. Відновіть до відповідної версії SQL Server - це означатиме пошук або встановлення нового екземпляра.
  2. Відновіть резервну копію на вихідному сервері як нову базу даних з іншим іменем, видаліть будь-які й усі функції підприємства, потім знову створіть резервну копію бази даних та відновіть її у меншому виданні. (У цьому конкретному випадку я залишив назву функції розділу в повідомленні про помилку, тому що це все одно здається предметом, який можна скасувати - його створив радник з налаштування бази даних двигуна і, можливо, це зробив хтось, хто не зовсім знайте, що вони робили. Це не завжди так.)

Різновидом (2) буде просто видалити розділ та інші функції з вихідної бази даних та взяти ще одну резервну копію. Але якщо це не зламається ...


3

Developer and Enterprise - це одне і те ж програмне забезпечення, лише з різними ліцензійними угодами.

Вам слід добре відновити цю базу даних за пунктом призначення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.