Ознаки
У Microsoft SQL Server 2019 відновлення стиснутої бази даних або журналу резервних копій баз даних, для яких активовано прозоре шифрування даних (TDE), може призвести до такої помилки:
Msg 3241, рівень 16, стан 18, рядок <lineNumber>
Медіафайл на пристрої "<ім'я файлу резервної копії>" неправильно сформовано. SQL Server не може обробити цей медіафайл.
Інші способи вирішення
Щоб вирішити цю проблему, не стискайте резервні копії бази даних із підтримкою TDE, використовуючи один із наведених нижче способів.
-
Використовуйте функцію WITH COMPRESSION, як описано в розділі РЕЗЕРВНЕ КОПІЮВАННЯ (Transact-SQL).
-
Покладайтеся на стандартне стискання резервних копій, як описано в поданні або настройці параметра конфігурації сервера для стискання резервної копії за замовчуванням.
Спосіб вирішення
Сукупні відомості про оновлення
Цю проблему вирішено в сукупному пакеті оновлень для SQL Server:
Сукупне оновлення 16 для SQL Server 2019
Примітка. Щоб уникнути проблем, потрібно створити резервні копії разом із цим виправленням. Інсталяція фіксованого куба на цільовому екземплярі та спроба відновити ту саму резервну копію, створену без виправлення, не працюватиме.
Додаткова інформація
Увага!: Починаючи з SQL Server 2019 CU16, створення стиснутих резервних копій (бази даних або журналу) З підтримкою TDE буде використовувати новий формат резервного копіювання, який можна відновити тільки в екземплярі, який має CU16 або пізнішої інсталяції.
Відновлення стиснутої резервної копії бази даних із підтримкою TDE, створеної в CU16 або пізнішої версії екземпляра SQL Server 2019 версії CU15 або ранішої версії, і викликає такі помилки:
-
ВІДНОВИТИ БАЗУ ДАНИХ
Msg 3013, level 16, State 1, Line <LineNumber>
Відновлення бази даних припиняється ненормально.
Msg 9004, рівень 21, стан 1, рядок <lineNumber>
Під час обробки журналу бази даних "TDE_DB" сталася помилка. Якщо це можливо, відновіть файл із резервної копії. Якщо резервна копія недоступна, можливо, знадобиться перебудувати журнал.
-
ВІДНОВИТИ ЖУРНАЛ
Розташування: mediaRead.cpp:1018
Вираз: readSize <= m_Demand
SPID: 84
Ідентифікатор процесу: ProcessID
Msg 3013, level 16, State 1, Line <LineNumber>
Ненормально завершується функція RESTORE LOG.
Msg 3624, level 20, State 1, Line <LineNumber>
Помилка перевірки твердження системи. Докладні відомості див. в журналі помилок SQL Server. Зазвичай помилка твердження виникає через помилку програмного забезпечення або пошкодження даних. Щоб перевірити наявність пошкоджень бази даних, радимо запустити DBCC CHECKDB. Якщо ви погодилися відправити дампи до корпорації Майкрософт під час налаштування, міні-дамп буде відправлено до корпорації Майкрософт. Оновлення може бути доступне від корпорації Майкрософт в останньому пакеті оновлень або виправлення від служби технічної підтримки.
Примітка. Відновлення ЗАГОЛОВКА Й ВІДНОВЛЕННЯ FILELISTONLY не впливає на проблему та працюватиме в усіх випадках.
ФУНКЦІЯ RESTORE VERIFYONLY може успішно повернутися для ПОВНОЇ резервної копії, неприпустимої відповідно до наведеного вище сценарію: не покладайтеся на функцію RESTORE VERIFYONLY, щоб установити можливість відновлення резервної копії, не переходячи до вищенаведених проблем. ВІДНОВЛЕННЯ ФУНКЦІЇ VERIFYONLY для резервного копіювання журналу зазвичай завершуватиметься помилкою з фактичним журналом відновлення, описаним вище.
Тому важливо переконатися, що в контексті, де TDE і резервного копіювання стискання може бути ввімкнуто, будь-які екземпляри SQL Server 2019, що споживають резервні копії з інших екземплярів SQL Server 2019, отримують CU16 (або пізнішої версії) перед екземплярами, які створюють резервний матеріал. Архітектури доставки журналів будуть основним прикладом такої ситуації: спочатку оновити допоміжні екземпляри.
Після створення резервної копії журналу транзакцій за допомогою стискання його зазвичай неможливо відтворити без стискання. Таким чином, оновлення журнал доставки основний сервер SQL Server 2019 CU16 або пізнішої версії в такому контексті буде порушити відновлення завдань, доки додатковий сервер також оновлюється.
Некомпресована резервна копія бази даних із підтримкою TDE, стиснута резервна копія бази даних, яку не ввімкнуто для TDE, або некомпресована резервна копія бази даних, не активованої для TDE, не використовуватиме новий формат резервного копіювання, введений в CU16, і може бути відновлена в екземплярі SQL Server 2019 будь-якої версії.
Тому потрібно вимкнути резервне копіювання стискання, якщо ви плануєте відновити TDE-включений матеріал бази даних (повне резервне копіювання або резервне копіювання журналу транзакцій) до будь-яких екземплярів SQL Server попередніх версій, перш ніж SQL Server 2019 CU16.
Кожен новий сукупний пакет оновлень для SQL Server містить усі виправлення та виправлення системи безпеки, які були в попередній збірці. Радимо інсталювати найновішу збірку для своєї версії SQL Server:
Стан
Корпорація Майкрософт підтвердила, що це проблема в продуктах Microsoft, перелічених у розділі "Стосується".
Посилання
Дізнайтеся про термінологію, яку корпорація Майкрософт використовує для опису оновлень програмного забезпечення.
