যেহেতু আমি স্ট্যাক ওভারফ্লোতে সর্বাধিক ভারপ্রাপ্ত আপ-ভোটযুক্ত পরামর্শ সহ উত্তরগুলির সাথে সত্যই সন্তুষ্ট নই এবং মাইকের উত্তরটি দেয় না এমন কয়েকটি বিষয় আমি উল্লেখ করতে চাই, তাই আমি ভেবেছিলাম যে আমি সরবরাহ করব এখানে আমার ইনপুট। আমি এই উত্তরটির একটি অনুলিপিও সেখানে রেখেছি।
একটি লগ ফাইল ছোট করা সত্যিই এমন পরিস্থিতিতে জন্য সংরক্ষণ করা উচিত যেখানে এটি অপ্রত্যাশিত বিকাশের মুখোমুখি হয় যা আপনি আবার ঘটবে বলে আশা করেন না। যদি লগ ফাইলটি আবার একই আকারে বাড়তে থাকে তবে অস্থায়ীভাবে সঙ্কুচিত করে খুব বেশি কার্যকর করা হয় না। এখন, আপনার ডাটাবেসের পুনরুদ্ধারের লক্ষ্যগুলির উপর নির্ভর করে, এটি আপনার করা উচিত।
প্রথমে পুরো ব্যাকআপ নিন
কোনও কিছু ভুল হয়ে যাওয়ার পরে আপনি এটি পুনরুদ্ধার করতে পারবেন তা নিশ্চিত করে কখনও আপনার ডাটাবেসে কোনও পরিবর্তন করবেন না make
আপনি যদি পয়েন্ট-ইন-টাইম পুনরুদ্ধারের বিষয়ে যত্নশীল হন
(এবং পয়েন্ট-ইন-টাইম পুনরুদ্ধারের দ্বারা, আমি বোঝাতে চাইছি আপনি সম্পূর্ণ বা ডিফারেনশিয়াল ব্যাকআপ ব্যতীত অন্য কোনও কিছুতে পুনরুদ্ধার করতে সক্ষম হওয়া সম্পর্কে যত্নশীল।)
সম্ভবত আপনার ডাটাবেস FULLপুনরুদ্ধার মোডে আছে। যদি তা না হয় তবে তা নিশ্চিত হয়ে নিন:
ALTER DATABASE yourdb SET RECOVERY FULL;
এমনকি আপনি যদি নিয়মিত পুরো ব্যাকআপ নিচ্ছেন তবে লগ ব্যাকআপ না করা পর্যন্ত লগ ফাইলটি বৃদ্ধি এবং বৃদ্ধি পাবে - এটি আপনার সুরক্ষার জন্য, আপনার ডিস্কের জায়গায় অকারণে না খাওয়া। আপনার পুনরুদ্ধারের উদ্দেশ্য অনুসারে আপনার এই লগ ব্যাকআপগুলি বেশ ঘন ঘন করা উচিত। উদাহরণস্বরূপ, যদি আপনার কোনও ব্যবসায়িক বিধি থাকে যাতে বলা হয় যে কোনও দুর্যোগের ঘটনায় আপনি 15 মিনিটেরও বেশি ডেটা হারাতে পারবেন, আপনার একটি কাজ থাকা উচিত যা প্রতি 15 মিনিটে লগ ব্যাক আপ করে। এখানে একটি স্ক্রিপ্ট রয়েছে যা বর্তমান সময়ের উপর ভিত্তি করে টাইমস্ট্যাম্পড ফাইলের নাম উত্পন্ন করবে (তবে আপনি এটি রক্ষণাবেক্ষণ পরিকল্পনাগুলি ইত্যাদির সাহায্যেও করতে পারেন, কেবল রক্ষণাবেক্ষণ পরিকল্পনাগুলিতে সংকোচন বিকল্পগুলির মধ্যে কোনওটি চয়ন করবেন না, তারা ভয়ঙ্কর)
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_'
+ CONVERT(CHAR(8), GETDATE(), 112) + '_'
+ REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
+ '.trn';
BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;
নোট করুন যে \\backup_share\কোনও পৃথক মেশিনে থাকা উচিত যা একটি ভিন্ন অন্তর্নিহিত স্টোরেজ ডিভাইসের প্রতিনিধিত্ব করে। এগুলিকে একই মেশিনে ব্যাক আপ করা (বা কোনও ভিন্ন মেশিন যা একই অন্তর্নিহিত ডিস্কগুলি ব্যবহার করে, বা একই শারীরিক হোস্টে থাকা অন্য কোনও ভিএম) আপনাকে সত্যিই সহায়তা করে না, যেহেতু যদি মেশিনটি ফুরিয়ে যায়, আপনি আপনার ডাটাবেস হারিয়ে ফেলেছেন এবং এর ব্যাকআপ। আপনার নেটওয়ার্ক অবকাঠামোর উপর নির্ভর করে স্থানীয়ভাবে ব্যাকআপ নেওয়ার বিষয়টি আরও বুদ্ধিমান হতে পারে এবং তারপরে এগুলি পর্দার আড়ালে অন্য কোনও স্থানে স্থানান্তর করতে পারে; উভয় ক্ষেত্রেই আপনি এগুলি যত তাড়াতাড়ি সম্ভব প্রাথমিক ডাটাবেস মেশিন থেকে নামাতে চান।
এখন, একবার আপনার নিয়মিত লগ ব্যাকআপগুলি চলতে থাকলে লগ ফাইলটি এখন অবধি যা কিছু বাড়ে তার চেয়ে বেশি যুক্তিসঙ্গতভাবে সঙ্কুচিত করা যুক্তিসঙ্গত হওয়া উচিত। লগ ফাইলটি 1 এমবি না হওয়া পর্যন্ত বারবার চলার অর্থ এই নয়SHRINKFILE - এমনকি আপনি লগটি ঘন ঘন ব্যাকআপ করে রাখছেন এমন কি, এরপরেও যে কোনও সমবর্তী লেনদেনের যোগফল সংযোজন করা দরকার। লগ ফাইল অটোগ্রো ইভেন্টগুলি ব্যয়বহুল, যেহেতু এসকিউএল সার্ভারকে ফাইলগুলি শূন্য করতে হয় (তাত্ক্ষণিক ফাইল আরম্ভকরণ সক্ষম করার সময় ডেটা ফাইলের বিপরীতে) হয় এবং এটি হওয়ার সময় ব্যবহারকারীর লেনদেন অপেক্ষা করতে হয়। আপনি এই বৃদ্ধি-সঙ্কুচিত-বৃদ্ধি-সঙ্কুচিত রুটিনটি যতটা সম্ভব সম্ভব করতে চান এবং আপনি অবশ্যই আপনার ব্যবহারকারীদের এটির জন্য অর্থ প্রদান করতে চাইবেন না।
নোট করুন যে সঙ্কুচিত হওয়ার সম্ভাবনার আগে আপনাকে লগটিকে দু'বার ব্যাক আপ করতে হবে (ধন্যবাদ রবার্ট)।
সুতরাং, আপনাকে আপনার লগ ফাইলের জন্য একটি ব্যবহারিক আকার নিয়ে আসা দরকার। আপনার সিস্টেম সম্পর্কে আরও বেশি কিছু না জেনে এটি কী তা এখানে আপনাকে কেউ বলতে পারে না, তবে আপনি যদি প্রায়শই লগ ফাইলটি সঙ্কুচিত করে চলেছেন এবং এটি আবার বাড়ছে, তবে একটি ভাল জলছবি সম্ভবত এটি সবচেয়ে বড় থেকে 10-50% বেশি is । আসুন এটি 200 এমবিতে আসে এবং আপনি যে কোনও পরবর্তী অটোগ্রোথ ইভেন্ট 50 এমবি হতে চান তা আপনি লগ ফাইলের আকারটি এইভাবে সামঞ্জস্য করতে পারেন:
USE [master];
GO
ALTER DATABASE Test1
MODIFY FILE
(NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO
নোট করুন যে লগ ফাইলটি বর্তমানে> 200 এমবি থাকলে আপনার প্রথমে এটি চালানোর প্রয়োজন হতে পারে:
USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO
আপনি যদি পয়েন্ট-ইন-টাইম পুনরুদ্ধারের বিষয়ে চিন্তা না করেন
যদি এটি একটি পরীক্ষামূলক ডাটাবেস হয় এবং আপনি পয়েন্ট-ইন-টাইম পুনরুদ্ধারের বিষয়ে যত্নশীল না হন তবে আপনার অবশ্যই নিশ্চিত হওয়া উচিত যে আপনার ডাটাবেসটি SIMPLEপুনরুদ্ধার মোডে রয়েছে।
ALTER DATABASE yourdb SET RECOVERY SIMPLE;
SIMPLEপুনরুদ্ধার মোডে ডাটাবেস স্থাপন করা নিশ্চিত করে যে এসকিউএল সার্ভার সমস্ত লেনদেনের রেকর্ড রাখার পরিবর্তে বাড়ানোর পরিবর্তে লগ ফাইলের ( FULLপুনরুদ্ধারে নিষ্ক্রিয় লেনদেনগুলি পুনরায় ব্যবহার করে) পুনরায় ব্যবহার করে (যেমন আপনি লগ ব্যাক আপ না করা পর্যন্ত পুনরুদ্ধার করে)। CHECKPOINTইভেন্টগুলি লগ নিয়ন্ত্রণ করতে এবং এটির মধ্যে এটির বাড়ানোর প্রয়োজন হবে না তা নিশ্চিত করতে সহায়তা করবে যদি না আপনি CHECKPOINTs এর মধ্যে প্রচুর টি-লগ ক্রিয়াকলাপ তৈরি করেন ।
এরপরে, আপনার অবশ্যই নিখুঁতভাবে নিশ্চিত করা উচিত যে এই লগের বৃদ্ধি সত্যই কোনও অস্বাভাবিক ঘটনার কারণে হয়েছিল (বলুন, একটি বার্ষিক বসন্ত পরিষ্কার করা বা আপনার বৃহত্তম সূচকগুলি পুনর্নির্মাণ), এবং সাধারণ, দৈনন্দিন ব্যবহারের কারণে নয়। আপনি যদি লগ ফাইলটিকে একটি হাস্যকর আকারে সঙ্কুচিত করেন এবং এসকিউএল সার্ভারটি আপনার স্বাভাবিক ক্রিয়াকলাপ সামঞ্জস্য করার জন্য এটি আবার বাড়িয়ে তুলতে পারে তবে আপনি কী অর্জন করেছেন? আপনি কি কেবলমাত্র অস্থায়ীভাবে ছেড়ে দিয়েছিলেন সেই ডিস্ক স্থানটি ব্যবহার করতে সক্ষম? আপনার যদি তাত্ক্ষণিক সংশোধন প্রয়োজন হয়, তবে আপনি নিম্নলিখিতগুলি চালাতে পারেন:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO
অন্যথায়, একটি উপযুক্ত আকার এবং বৃদ্ধি হার সেট করুন। পয়েন্ট-ইন-টাইম পুনরুদ্ধারের ক্ষেত্রে উদাহরণ অনুসারে, কোন ফাইলের আকার উপযুক্ত তা নির্ধারণ করতে এবং যুক্তিসঙ্গত অটোগ্রোথ পরামিতিগুলি সেট করতে আপনি একই কোড এবং যুক্তি ব্যবহার করতে পারেন।
কিছু কাজ আপনি করতে চান না
TRUNCATE_ONLYবিকল্পের সাথে লগটি ব্যাক আপ করুন এবং তারপরেSHRINKFILE । একটির জন্য, এই TRUNCATE_ONLYবিকল্পটি হ্রাস করা হয়েছে এবং এসকিউএল সার্ভারের বর্তমান সংস্করণগুলিতে আর উপলভ্য নয়। দ্বিতীয়ত, আপনি যদি FULLপুনরুদ্ধার মডেলটিতে থাকেন তবে এটি আপনার লগ চেইনটিকে ধ্বংস করবে এবং একটি নতুন, পূর্ণ ব্যাকআপের প্রয়োজন হবে।
ডাটাবেসটি আলাদা করুন, লগ ফাইলটি মুছুন এবং পুনরায় সংযুক্ত করুন । আমি জোর দিয়ে বলতে পারি না এটি কতটা বিপজ্জনক হতে পারে। আপনার ডাটাবেস ফিরে না আসতে পারে, সন্দেহ হিসাবে এটি আসতে পারে, আপনাকে ব্যাকআপে ফিরে যেতে হতে পারে (যদি আপনার একটি থাকে) ইত্যাদি etc.
"সঙ্কুচিত ডাটাবেস" বিকল্পটি ব্যবহার করুন । DBCC SHRINKDATABASEএবং এটি করার জন্য রক্ষণাবেক্ষণ পরিকল্পনার বিকল্পটি হ'ল খারাপ ধারণা, বিশেষত যদি আপনার কেবলমাত্র কোনও লগ সমস্যার সমস্যা সমাধানের প্রয়োজন হয়। আপনি যে ফাইলটি সমন্বয় এবং এটি স্বাধীনভাবে সমন্বয় ব্যবহার চান লক্ষ্য DBCC SHRINKFILEবা ALTER DATABASE ... MODIFY FILE(উদাহরণ উপরে)।
লগ ফাইলটি 1 এমবিতে সঙ্কুচিত করুন । এটি লোভনীয় বলে মনে হচ্ছে কারণ, আরে, এসকিউএল সার্ভার আমাকে এটি কিছু নির্দিষ্ট পরিস্থিতিতে করতে দেবে এবং এটি যে সমস্ত জায়গা খালি করে তা তাকিয়ে থাকবে! আপনার ডাটাবেসটি কেবল না পড়লে (এবং এটি হ'ল এটির ব্যবহার হিসাবে চিহ্নিত করা উচিত ALTER DATABASE) এটি একেবারে কেবলমাত্র অনেক অপ্রয়োজনীয় বৃদ্ধির ঘটনা ঘটায়, কারণ লগটিকে পুনরুদ্ধারের মডেল নির্বিশেষে বর্তমান লেনদেনের সাথে সামঞ্জস্য করতে হবে। এই স্থানটি অস্থায়ীভাবে মুক্ত করার অর্থ কী, ঠিক এসকিউএল সার্ভার আস্তে আস্তে এবং ব্যথার সাথে এটিকে ফিরিয়ে নিতে পারে?
একটি দ্বিতীয় লগ ফাইল তৈরি করুন । এটি আপনার ডিস্কটি পূর্ণ করে এমন ড্রাইভের জন্য অস্থায়ীভাবে ত্রাণ সরবরাহ করবে, তবে এটি ব্যান্ড-সহায়তা দিয়ে একটি পাঙ্কচারযুক্ত ফুসফুস ঠিক করার চেষ্টা করার মতো। আপনার কেবলমাত্র আরেকটি সম্ভাব্য সমস্যা যুক্ত করার পরিবর্তে সমস্যাযুক্ত লগ ফাইলটি সরাসরি মোকাবেলা করা উচিত। কিছু লেনদেনের লগ ক্রিয়াকলাপকে অন্য ড্রাইভে পুনঃনির্দেশিত করা ব্যতীত, দ্বিতীয় লগ ফাইলটি আপনার পক্ষে সত্যিই কিছুই করে না (দ্বিতীয় ডেটা ফাইলের বিপরীতে), যেহেতু একবারে কেবলমাত্র একটি ফাইল ব্যবহার করা যেতে পারে। পল রান্ডাল আরও ব্যাখ্যা করেছেন যে কেন পরে একাধিক লগ ফাইল আপনাকে কামড় দিতে পারে ।
সতর্ক হও
আপনার লগ ফাইলটি কিছুটা অল্প পরিমাণে সঙ্কুচিত করার পরিবর্তে এবং অল্প পরিমাণে নিজেরাই অবিচ্ছিন্নভাবে বাড়িয়ে দেওয়ার পরিবর্তে এটি কিছুটা যুক্তিসঙ্গত বৃহত আকারে সেট করুন (এমন একটি যা আপনার বৃহত্তম সমান্তরাল লেনদেনের যোগফলকে সামঞ্জস্য করবে) এবং একটি যুক্তিসঙ্গত অটোগ্রো সেট করুন ফ্যালব্যাক হিসাবে সেট করা, যাতে একক লেনদেনকে সন্তুষ্ট করতে একাধিকবার বাড়তে হবে না এবং এটি স্বাভাবিক ব্যবসায়িক ক্রিয়াকলাপের সময় বৃদ্ধি পেতে অপেক্ষাকৃত বিরল হয়ে যায়।
এখানে সবচেয়ে খারাপ সম্ভাব্য সেটিংসগুলি হ'ল 1 এমবি বৃদ্ধি বা 10% বৃদ্ধি। যথেষ্ট মজাদার, এগুলি এসকিউএল সার্ভারের ডিফল্ট (যা আমি অভিযোগ করেছি এবং কোনও লাভের পরিবর্তনের জন্য বলেছি ) - ডেটা ফাইলের জন্য 1 এমবি এবং লগ ফাইলের জন্য 10%। পূর্বের এই দিন এবং যুগে খুব ছোট, এবং পরবর্তী সময়টি প্রতিটি সময় দীর্ঘ এবং দীর্ঘতর ইভেন্টগুলির দিকে পরিচালিত করে (বলুন, আপনার লগ ফাইলটি 500 এমবি, প্রথম বৃদ্ধি 50 এমবি, পরবর্তী বৃদ্ধি 55.5 এমবি, পরবর্তী বৃদ্ধি 60.5 এমবি ইত্যাদি ইত্যাদি - এবং ধীরে ধীরে I / O, বিশ্বাস করুন, আপনি সত্যিই এই বক্ররেখা লক্ষ্য করবেন)।
আরও পড়া
দয়া করে এখানে থামবেন না; সঙ্কুচিত লগ ফাইলগুলি সম্পর্কে আপনি যে পরামর্শটি দেখতে পান সেখানে বেশিরভাগই সহজাতভাবে খারাপ এবং এমনকি সম্ভাব্য বিপর্যয়কর হলেও, এমন কিছু লোক আছেন যারা ডিস্কের স্থান মুক্ত করার চেয়ে ডেটা অখণ্ডতার বিষয়ে বেশি যত্নশীল।
