যখন MAXTRANSFERSIZE এবং CHECKSUM ব্যবহার করা হয় তখন TDE সক্ষম ডাটাবেস পুনরুদ্ধার করতে অক্ষম


10

আপডেট : @ অমিতবানার্জি - মাইক্রোসফ্ট এসকিউএল সার্ভার প্রোডাক্ট গ্রুপের সিনিয়র প্রোগ্রাম ম্যানেজার নিশ্চিত করেছেন যে এমএস এটি ত্রুটিযুক্ত হওয়ায় বিষয়টি তদন্ত করবে

MAXTRANSFERSIZEএসডিএল সার্ভার ২০১ on- তে টিডিই সক্ষম হয়ে > 65536 ব্যবহার করে (আমার ক্ষেত্রে, আমি 65537 বেছে নিয়েছি যাতে আমি টিডিই ডাটাবেসটি সংকুচিত করতে পারি ) ব্যবহার করে কি কেউ সমস্যার সমাধানের সমস্যার মুখোমুখি হয়েছেন CHECKSUM?

নীচে একটি তিরস্কার:

--- create database 
create database test_restore
go
-- create table
create table test_kin (fname char(10))
go
-- Enable TDE 

use master
GO
CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert'
GO
SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore'
GO
use test_restore
go
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE test_restore
GO 
alter database test_restore set encryption ON

সম্পূর্ণ কপিটি কেবল ব্যাকআপ নিন .. দু'বার করুন ..

backup database test_restore 
to disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak' -- change as per your location !!
with init, stats =10  -- overwrite ..using INIT !!
, maxtransfersize = 65537
, compression
,CHECKSUM

এখন একটি verifyonly...

restore verifyonly from disk = 'D:\temporary-short-term\test_restore_KIN_test_restore_1.bak'

ভুল বার্তা :

এমএসজি 3241, স্তর 16, রাজ্য 40, লাইন 11 ডিভাইসের মিডিয়া পরিবার 'ডি: \ অস্থায়ী-স্বল্প-মেয়াদী \ টেস্ট_রেস্টোর_কেস্তেস্ট_রেস্টোর_1.বাক' ভুলভাবে গঠিত হয়েছে। এসকিউএল সার্ভার এই মিডিয়া পরিবারকে প্রক্রিয়া করতে পারে না। এমএসজি 3013, স্তর 16, রাজ্য 1, লাইন 11 ভেরিফাই ডেটাবেস অস্বাভাবিকভাবে শেষ করছে।

বিভিন্ন সংমিশ্রণের সাথে ফলাফল (1 = চালু, 0 = বন্ধ):

+-------------------------+-------------+----------+--------+
| MAXTRANSFERSIZE (65537) | COMPRESSION | CHECKSUM | RESULT |
+-------------------------+-------------+----------+--------+
|                       1 |           1 |        1 | FAIL   |
|                       1 |           1 |        0 | PASS   |
|                       1 |           0 |        1 | FAIL   |
|                       0 |           0 |        0 | PASS   |
|                       0 |           1 |        1 | PASS   |
|                       0 |           1 |        0 | PASS   |
+-------------------------+-------------+----------+--------+

সমস্যাটি ঘটে:

মাইক্রোসফ্ট এসকিউএল সার্ভার 2016 (আরটিএম-সিইউ 1) (কেবি 3164674) - 13.0.2149.0 (এক্স 64) জুলাই 11 2016 22:05:22 কপিরাইট (সি) মাইক্রোসফ্ট কর্পোরেশন এন্টারপ্রাইজ সংস্করণ (64-বিট) উইন্ডোজ সার্ভার 2012 আর 2 স্ট্যান্ডার্ড 6.3 (বিল্ড 9600) :)

উত্তর:


6

আমি আপনার সমস্যা পুনরুত্পাদন করতে সক্ষম ছিল।

যোগ করার পদ্ধতি FORMATথেকে BACKUPকমান্ড আমার জন্য এটি সমাধান।

যদিও আমি কংক্রিট ডকুমেন্টেশন সন্ধান করতে পারি না, এটি আমার মতে এটি একটি নতুন মিডিয়া শিরোলেখ তৈরি INITকরার সময় ব্যাকআপ সেটে বিদ্যমান মিডিয়া শিরোনামকে ধরে রাখার সাথে সম্পর্কিত it'sFORMAT

আমি এখনও এই সমস্যাটি নিয়ে গবেষণা করছি এবং যদি আমি অতিরিক্ত তথ্য পাই তবে আমি এই উত্তরটি আপডেট করব।


হ্যাঁ, উইলটি FORMATপাশাপাশি শিরোনামকেও ওভাররাইট করবে এবং ব্যবহারের সময় এটি ঘটে না FORMAT। আইএনআইটি-র সাথে MAXTRANSFERSIZEএবং CHECKSUMএকসাথে ব্যাকআপ শিরোনামটি (বা সামগ্রিকভাবে ব্যাকআপ) কেন নষ্ট হয়ে যায় তা এখনও এটি একটি রহস্য । এটি নিম্ন সংস্করণগুলিতে কখনও ঘটেনি তবে তাদের মধ্যে এটি ছিল না MAXTRANSFERSIZE। আপনার উত্তরের জন্য ধন্যবাদ. কারও কাছে আরও তথ্য থাকলে এটি উন্মুক্ত রাখবে।
কিন শাহ

3

দেখে মনে হচ্ছে এটি 4032200 কেবি দিয়ে সম্বোধন করা হয়েছিল:

প্রবেশ থেকে:

লক্ষণ

আপনি মাইক্রোসফট SQL সার্ভার 2016. ডাটাবেসের জন্য স্বচ্ছ ডাটা এনক্রিপশন (TDE) সক্রিয় ব্যবহার করে আপনি দ্বারা ডাটাবেসের ব্যাকআপ চেষ্টা ধরে BACKUP DATABASEটি-SQL বক্তব্য উভয় আছে COMPRESSIONএবং INITবিকল্প নির্দিষ্ট করা হয়েছে। এই পরিস্থিতিতে, আপনি লক্ষ্য করতে পারেন যে বিদ্যমান ব্যাকআপ ফাইলটি নতুন ব্যাকআপ ফাইল দ্বারা ওভাররাইট করা হয়েছে, এবং নতুন ব্যাকআপ ফাইলটি সংকুচিত হয়নি।

সমাধান

এই সমস্যাটি এসকিউএল সার্ভারের জন্য নিম্নলিখিত ক্রমযুক্ত আপডেটগুলিতে স্থির হয়েছে:


1

এটি সম্ভবত একই সমস্যা হিসাবে দেখা দেবে যা আপনি আপনার প্রশ্নে উল্লেখ করেছেন ব্লগ পোস্টটি পরে উল্লেখ করার জন্য আপডেট করা হয়েছিল:

আপডেট 6 এপ্রিল, 2017

আমরা সম্প্রতি এসকিউএল সার্ভার ২০১ T-এ টিডিই এবং ব্যাকআপ সংক্ষেপণের সাথে সম্পর্কিত কিছু সমস্যা আবিষ্কার করেছি them আমরা সেগুলি ঠিক করার সময়, known পরিচিত সমস্যাগুলির মধ্যে দৌড়াতে এড়াতে আপনাকে সহায়তা করার জন্য এখানে কিছু টিপস দেওয়া হয়েছে:

  • বর্তমানে টিডিই এবং ব্যাকআপ সংকোচনের সাথে স্ট্রিপড ব্যাকআপগুলি ব্যবহার করা ভাল নয়

  • যদি আপনার ডাটাবেসে 4 জিবি-র চেয়ে বড় ভার্চুয়াল লগ ফাইল (ভিএলএফ) থাকে তবে আপনার লগ ব্যাকআপের জন্য টিডিই-র সাথে ব্যাকআপ সংক্ষেপণ ব্যবহার করবেন না। আপনি যদি ভিএলএফ কী তা জানেন না, তবে এখানেই শুরু করুন

  • টিডিডি এবং ব্যাকআপ সংক্ষেপণের সাথে কাজ করার জন্য এখনই আইএনআইটি সহ ব্যবহার করা এড়াবেন। পরিবর্তে, আপাতত আপনি বিন্যাসের সাথে ব্যবহার করতে পারেন।

এসকিউএল ইঞ্জিনিয়ারিং এসকিউএল সার্ভার ২০১ 2016-এ এই সমস্যার সমাধানের জন্য কাজ করছে further আমাদের আরও ভাগ করার জন্য আমরা আরও একবার এই ব্লগ পোস্টটি আপডেট করব।

সেই নোট সত্ত্বেও, ব্লগ পোস্টটি তার পরে আর কোনও তথ্যের সাথে আপডেট করা হয়নি।

তবে, KB 4019893 এটিকেও সম্বোধন করতে পারে:

যদিও কেবি নিবন্ধে প্রতিবেদন করা ত্রুটি বার্তাটি আপনি প্রতিবেদন করছেন তার চেয়ে আলাদা হলেও, অবদানকারী উপাদানগুলি খুব সাদৃশ্যপূর্ণ। এসকিউএল সার্ভার 2016 এসপি 1 সিইউ 3 প্রথমে ফিক্সটি অন্তর্ভুক্ত করেছে, যেমনটি এর হটফিক্স তালিকায় দেখা গেছে । যাইহোক, এমন খবর পাওয়া গেছে যে এটি সব পরিস্থিতিতে সমস্যার সমাধান করেনি।

এসকিউএল সার্ভার 2016 এসপি 1 সিইউ 4 এর জন্য একটি (সম্ভবত আপডেট করা) ফিক্সও অন্তর্ভুক্ত করে এবং কেবি 4019893 এর পরে এসপি 1 সিই 4 দেখতে সমস্যাটি যে সংস্করণটিতে ঠিক করা হয়েছিল সে হিসাবে দেখাতে আপডেট করা হয়েছে।

দুর্ভাগ্যক্রমে, আমি নিজের অভিজ্ঞতা থেকে নিশ্চিত করতে পারি যে এসপি 1 সিইউ 4-তে স্থির করাও এই সমস্যাটিকে পুরোপুরি সমাধান করে না। আমি বর্তমানে এক TDE-সক্রিয় ডাটাবেসের এখনও যখন ব্যবহার করা বেশি এসপি 1 CU4 উপর ধারাবাহিকভাবে দুর্নীতিগ্রস্ত ব্যাকআপ উত্পাদন করে আছে COMPRESSION(মাধ্যমে MAXTRANSFERSIZE> 64 কিলোবাইট) এবং CHECKSUM। আমিও এই পরিবেশে কয়েক ডজন অন্যান্য TDE-সক্রিয় ডাটাবেস যে ধারাবাহিকভাবে আছে না , এক এক করে একটি প্রায় একই স্কিমা কিন্তু ছোট ডেটা সেটটি সঙ্গে, আছে একটি প্রকরণ যে ওই সমস্ত সেটিংসের অধীনে দুর্নীতিগ্রস্ত ব্যাকআপ উত্পাদন। এটি ইঙ্গিত করে বলে মনে হচ্ছে যে মাইক্রোসফ্ট সত্যিকার অর্থে যে পরিস্থিতিগুলির কারণ হতে পারে সেগুলি এড়িয়ে চলেছে, তবে এখনও সেগুলির সমস্ত সমাধান করেনি।

FORMATঅন্য উত্তর এবং এসকিউএলএকেট ব্লগ পোস্টে উল্লেখ করা হিসাবে আমি এখনও এই সমস্যাটি নিয়ে কাজ করার চেষ্টা করিনি , তবে আমি যদি এখানে চেষ্টা করতে সক্ষম হই এবং এটি সমস্যার সমাধান করে তবে আমি এখানে একটি আপডেট সরবরাহ করব। আমার কাছে যে ডাটাবেসটি এটি পুনরুত্পাদন করে তা দুর্ভাগ্যক্রমে বরং বড় (~ 1 টিবি), এবং এমন একটি ডেভলপমেন্ট / কিউএ ক্লাস্টারে থাকে যাতে অতিরিক্ত স্টোরেজ স্পেস নেই (অন্ততপক্ষে সেই স্কেল), সুতরাং এর বিভিন্নতা পরীক্ষা করে লজিস্টিক্যালি চ্যালেঞ্জিং এবং সময়সাপেক্ষ বলে প্রমাণিত।


এই সমস্যাটি এখনও এসকিউএল 2017-এ রয়েছে
স্বরূপ কোথাপালি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.