এসকিউএল সার্ভার ফাইলস্ট্রেম ব্যবহার করার সময় (আংশিক) ব্যাকআপগুলি ছোট রাখা


12

আমার প্রায় 1TB ডেটাযুক্ত একটি ডাটাবেস রয়েছে FILESTREAMযা আমার ব্যাক আপ করার প্রয়োজন নেই (যদি ডেটা মুছে ফেলা হয় তবে কয়েক ঘন্টা পরে এটি স্বয়ংক্রিয়ভাবে পুনরায় তৈরি করা হত, সুতরাং এটি গুরুত্বপূর্ণ নয়)। বেশিরভাগ ডেটা প্রতিটি দু'দিন পরে পরিবর্তিত হয়, তাই ডিফারেনশিয়াল ব্যাকআপগুলি আকারটি কমিয়ে রাখতে সত্যিই সহায়তা করে না।

আমি পথ আমি রিকভারি মোড সেটিং প্রয়োজনীয় কাজ ব্যাকআপ ছিল Fullএকটি পৃথক তৈরি, FILEGROUPজন্য FILESTREAM, তারপর শুধুমাত্র "প্রাথমিক" ব্যাক-আপ করার FILEGROUP। এই সমস্যার কারণ হ'ল লগ ফাইল (যা ব্যাক আপও হয়) এখন অযথা বড় কারণ এতে FILESTREAMডেটা রয়েছে ।

SIMPLEপুনরুদ্ধার মোড নির্দিষ্ট গুলিগুলির ব্যাকআপগুলি নেওয়ার আমার ক্ষমতা কেড়ে নেয় FILEGROUP, তাই আমি মনে করি না এটি কোনও বিকল্প হবে।

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

Simpleপুনরুদ্ধার মোডে আংশিক ব্যাকআপ তৈরি করার কোনও উপায় আছে ( FILESTREAMকেবলমাত্র পড়ার জন্য টেবিলটি সেট না করে )? যদি তা না হয় তবে আমার সমস্যার আর কোনও বুদ্ধিমান সমাধান রয়েছে কি?

উত্তর:


3

এই সমস্যার কারণটি হ'ল লগ ফাইলটি (যা ব্যাকআপও হয়) এখন অযথা বড় কারণ এটিতে ফাইলস্ট্রেম ডেটা অন্তর্ভুক্ত রয়েছে।

আমি নিশ্চিত না আপনি লগ ফাইলটি নিজেই খুব বড় বা লগ ফাইলের ব্যাকআপগুলি খুব বড় হয়ে গেছে কিনা তা নিশ্চিত।

যদি এটি প্রাক্তন হয় তবে আপনি কতক্ষণ লগ আপকে সমর্থন করছিলেন? অ্যাপ্লিকেশন ডিজাইনের উপর নির্ভর করে আপনি আরও ঘন ঘন ব্যাকআপের মাধ্যমে আকার হ্রাস করতে সক্ষম হতে পারেন (এবং প্রতি 5 মিনিটে খুব বেশি ঘন ঘন হয় না)। তবে আপনি যদি ইতিমধ্যে এটি করে থাকেন এবং এটি এখনও বেলুনিং হয় তবে সম্ভবত আপনার ভাগ্য খুব খারাপ। বড় লগ ফাইল আবার সমস্যা কেন?

যদি এটি পরে থাকে - মনে হয় আপনি সরল পুনরুদ্ধারের মডেলটি চালিয়ে যেতে পেরে খুশি হন এবং সময়মতো কোনও পুনরুদ্ধার হয় না যদি এটি আপনাকে ছোট ব্যাকআপ দেয়; এক্ষেত্রে পুরো মোডে থাকুন এবং আপনার লগ ব্যাকআপগুলি বাতিল করুন।


আমি লগ ব্যাকআপগুলি বুঝতে পারি নি যা প্রায়শই অস্বাভাবিক ছিল না! আপনার "বড় লগ ফাইল আবার সমস্যা কেন?" প্রশ্ন আসলে আমাকে সে সম্পর্কে চিন্তাভাবনা করেছিল এবং আমার কোনও উত্তর নেই। সুতরাং, আপনার কাছে +100!
ডেভিড মুরডোক

3

সিম্পল পুনরুদ্ধার মোডে সেট করা একটি ডাটাবেসের সমাধানটিতে কেবলমাত্র পঠনযোগ্য ফাইল গোষ্ঠীতে (যা আপনার আদর্শ বিকল্প নয়) ফাইলস্ট্রেম ডেটা রাখা থাকে এবং তারপরে কেবলমাত্র পড়ুন / লেখার ফাইল গ্রুপগুলিকে ব্যতিক্রম করে এই জাতীয়:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

এটি কোনও পঠন / লেখার ফাইলগোষ্ঠীতে পরিবর্তিত কোনও ডেটা পাবে। বাক্সের বাইরে এটিই সবচেয়ে সহজ, আপনি ফাইলস্ট্রেম ডেটা না পেয়ে আংশিক ব্যাকআপ পরিচালনা করতে পারবেন। তবে এটির প্রয়োজন হবে যে পূর্বোক্ত তথ্যের জন্য লোড প্রক্রিয়াটির জন্য ফাইলগ্রুপটি পড়া / লেখার জন্য কোনও অতিরিক্ত ডেটা লোড করতে হবে এবং তারপরে কেবল আবার পড়ার জন্য সেট করতে হবে। অবশ্যই আদর্শ নয়।


এটি আমাদের নিখুঁত হতে পারে যদি আমাদের স্বয়ংক্রিয় সিস্টেমটি ফাইলস্ট্রেমকে কখনও কখনও কখনও কখনও সাধারণভাবে মোকাবিলা করার জন্য ডিজাইন করা হয়। দুর্ভাগ্যক্রমে, সমস্ত পরিষেবাগুলিকে রিফ্যাক্টর করতে অনেক বেশি সময় লাগত, বিশেষত যেহেতু আমরা এখনই সমস্যাটিতে কেবল হার্ড ড্রাইভ ফেলে দিতে পারি। আপনাকে ধন্যবাদ, এগিয়ে যেতে, সমস্ত নতুন পরিষেবাদি এটি মাথায় রেখে ডিজাইন করা হবে এবং সময়ের সাথে সাথে পুরানো পরিষেবাগুলি আপডেট করার পরিকল্পনা কার্যকর হচ্ছে। (আমি আশা করি আমি আপনাকে অর্ধেক অনুগ্রহের পুরষ্কার দিতে পারি!
ডেভিড মুরডোক

2

আমি মলিন একটি বিকল্প হিসাবে এই প্রদানের, কিন্তু আপনি যদি নিজস্ব ডাটাবেসের মধ্যে FILESTREAM তথ্য দলবদ্ধ করা চয়ন, আপনি প্রণালী দ্বারা পৃথক DBS মধ্যে সারণির মধ্যে, RI বজায় রাখতে পারে মনে ট্রিগার :

ট্রিগার -> মন্তব্য -> সীমাবদ্ধতা:
একটি ট্রিগার কেবলমাত্র বর্তমান ডাটাবেসে তৈরি করা হয়; যাইহোক, একটি ট্রিগার বর্তমান ডাটাবেসের বাইরে অবজেক্টগুলি রেফারেন্স করতে পারে।

পারফরম্যান্স সমস্যা এবং আপনার মাথার ত্বকের একটি অংশ হতাশায় আপনার মাথার পশমের গোছা টানানোর পরে চুলহীন হয়ে উঠবে আশা করুন, তবে তাত্ত্বিকভাবে আপনি এটি করতে পারেন। আমি কোনও স্তরে এই পদ্ধতির প্রস্তাব দিচ্ছি না, পরিবর্তে আমি দৃ strongly়ভাবে পরামর্শ দিচ্ছি যে আপনি আপনার টলগ ব্যাকআপগুলির ফ্রিকোয়েন্সি বাড়িয়ে তুলুন এবং / অথবা বাল্ক- লগড রিকভারি মডেলটিতে স্যুইচ করুন এবং দেখুন যে কতটা স্থান আপনাকে বাঁচায়, তবে এটি একটি সম্ভাব্য সমাধান। সত্যিই আপনার এই ডেটা আলাদা করার এবং একটি ফ্রাঙ্কেনস্টেইনীয় ডাটাবেস ডিজাইনের সাথে ডিল করার সুবিধাটি বিবেচনা করতে হবে তবে এটি একটি বিকল্প।

... আমাকে এখন গোসল করতে হবে ...


1

আমি জানি এই প্রশ্নের উত্তর ইতিমধ্যে দেওয়া হয়েছে, তবে অন্য একটি সমাধান রয়েছে যা অন্যকে সাহায্য করতে পারে। সম্প্রতি আমি ব্রেন্ট ওজারের ব্লগ থেকে শিখেছি যে এখনই আপনার লগ ব্যাকআপগুলি বাতিল করার জন্য একটি বিকল্প রয়েছে:

BACKUP LOG MyDb TO DISK='NUL:'

সুতরাং আপনি আপনার ডাটাবেসটিকে Fullরিকভারি মোডে রেখে ফাইলগ্রুপগুলির ব্যাকআপ করতে পারেন । যখন আপনার লেনদেনের লগটি খুব বড় হয়ে যায়, তারপরে কেবল ব্যাকআপ লগ কমান্ডটি সরবরাহ করুন এবং আপনার কাজ শেষ হয়ে যায়।


অপ্রত্যাশিত ক্রিয়াকলাপটি অযৌক্তিকভাবে লগ ফাইলের আকারটি চালিত করবে না তা নিশ্চিত করার জন্য আমি এখনও নির্ধারিত কাজ হিসাবে লগ ব্যাকআপগুলি চালিয়ে যাওয়ার পরামর্শ দেব।
আরডিফোজ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.