একটি লগ ফাইল ছোট করা সত্যিই এমন পরিস্থিতিতে জন্য সংরক্ষিত করা উচিত যেখানে এটি অপ্রত্যাশিত বৃদ্ধির মুখোমুখি হয় যা আপনি আবার ঘটবে বলে আশা করেন না। যদি লগ ফাইলটি আবার একই আকারে বাড়তে থাকে তবে অস্থায়ীভাবে সঙ্কুচিত করে খুব বেশি কার্যকর করা হয় না। এখন, আপনার ডাটাবেসের পুনরুদ্ধারের লক্ষ্যগুলির উপর নির্ভর করে, এটি আপনার করা উচিত।
প্রথমে পুরো ব্যাকআপ নিন
কোনও কিছু ভুল হয়ে যাওয়ার পরে আপনি এটি পুনরুদ্ধার করতে পারবেন না তা নিশ্চিত করে কখনও আপনার ডাটাবেসে কোনও পরিবর্তন করবেন না।
আপনি যদি পয়েন্ট-ইন-টাইম পুনরুদ্ধারের বিষয়ে যত্নশীল হন
(এবং পয়েন্ট-ইন-টাইম পুনরুদ্ধারের দ্বারা, আমি বলতে চাইছি আপনি সম্পূর্ণ বা ডিফারেনশিয়াল ব্যাকআপ ব্যতীত অন্য কোনও কিছুতে পুনরুদ্ধার করতে সক্ষম হওয়া সম্পর্কে যত্নশীল।)
সম্ভবত আপনার ডাটাবেস FULLপুনরুদ্ধার মোডে আছে। যদি তা না হয় তবে তা নিশ্চিত হয়ে নিন:
ALTER DATABASE testdb SET RECOVERY FULL;
এমনকি আপনি যদি নিয়মিত পুরো ব্যাকআপ নিচ্ছেন তবে লগ ব্যাকআপ না করা পর্যন্ত লগ ফাইলটি বৃদ্ধি এবং বৃদ্ধি পাবে - এটি আপনার সুরক্ষার জন্য, আপনার ডিস্কের জায়গায় অকারণে না খাওয়া। আপনার পুনরুদ্ধারের উদ্দেশ্য অনুসারে আপনার এই লগ ব্যাকআপগুলি বেশ ঘন ঘন করা উচিত। উদাহরণস্বরূপ, যদি আপনার কোনও ব্যবসায়িক বিধি থাকে যাতে বলা হয় যে আপনি কোনও দুর্যোগের ঘটনায় 15 মিনিটের বেশি ডেটা হারাতে পারবেন না, আপনার এমন একটি কাজ থাকা উচিত যা প্রতি 15 মিনিটে লগ ব্যাক আপ করে। এখানে একটি স্ক্রিপ্ট রয়েছে যা বর্তমান সময়ের উপর ভিত্তি করে টাইমস্ট্যাম্পড ফাইলের নাম উত্পন্ন করবে (তবে আপনি এটি রক্ষণাবেক্ষণ পরিকল্পনাগুলি ইত্যাদির সাহায্যেও করতে পারেন, কেবল রক্ষণাবেক্ষণ পরিকল্পনাগুলিতে সঙ্কুচিত বিকল্পগুলি বেছে নেবেন না, তারা ভয়ঙ্কর)।
DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_'
+ 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 testdb SET RECOVERY SIMPLE;
SIMPLEপুনরুদ্ধার মোডে ডাটাবেস স্থাপন করা নিশ্চিত করে যে এসকিউএল সার্ভার সমস্ত লেনদেনের রেকর্ড রাখার জন্য বাড়ার পরিবর্তে লগ ফাইলের ( FULLপুনরুদ্ধারে নিষ্ক্রিয় লেনদেনগুলি পুনরায় ব্যবহার করে) পুনরায় ব্যবহার করে (যেমন আপনি লগ ব্যাক আপ না করা পর্যন্ত পুনরুদ্ধার করে)। CHECKPOINTইভেন্টগুলি লগ নিয়ন্ত্রণ করতে সহায়তা করে এবং এটির মধ্যে এটির বাড়ানোর দরকার নেই তা নিশ্চিত করতে সাহায্য করবে যদি না আপনি মধ্যে প্রচুর টি-লগ ক্রিয়াকলাপ তৈরি করেনCHECKPOINT s এর ।
এরপরে, আপনার অবশ্যই নিখুঁতভাবে নিশ্চিত করা উচিত যে এই লগের বৃদ্ধি সত্যই কোনও অস্বাভাবিক ঘটনার কারণে হয়েছিল (বলুন, একটি বার্ষিক বসন্ত পরিষ্কার করা বা আপনার বৃহত্তম সূচকগুলি পুনর্নির্মাণ), এবং সাধারণ, দৈনন্দিন ব্যবহারের কারণে নয়। আপনি যদি লগ ফাইলটিকে একটি হাস্যকর আকারে সঙ্কুচিত করেন এবং এসকিউএল সার্ভারটি আপনার স্বাভাবিক ক্রিয়াকলাপ সামঞ্জস্য করতে আবার এটি বাড়িয়ে তুলতে পারে তবে আপনি কী অর্জন করেছেন? আপনি কি কেবলমাত্র অস্থায়ীভাবে ছেড়ে দিয়েছিলেন সেই ডিস্ক স্থানটি ব্যবহার করতে সক্ষম? আপনার যদি তাত্ক্ষণিক সংশোধন প্রয়োজন হয়, তবে আপনি নিম্নলিখিতগুলি চালাতে পারেন:
USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
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, বিশ্বাস করুন, আপনি সত্যিই এই বক্ররেখা লক্ষ্য করবেন)।
আরও পড়া
দয়া করে এখানে থামবেন না; সঙ্কুচিত লগ ফাইলগুলি সম্পর্কে আপনি যে পরামর্শটি দেখতে পান সেখানে বেশিরভাগই সহজাতভাবে খারাপ এবং এমনকি সম্ভাব্য বিপর্যয়কর হলেও, এমন কিছু লোক আছেন যারা ডিস্কের স্থান মুক্ত করার চেয়ে ডেটা অখণ্ডতার বিষয়ে বেশি যত্নশীল।
২০০৯ সালে আমি একটি ব্লগ পোস্ট লিখেছিলাম যখন আমি কয়েকটিকে "লগ ফাইলটি সঙ্কুচিত করার জন্য এখানে রয়েছে" পোস্টগুলি বসন্তে দেখতে পেলাম ।
একটি ব্লগ পোস্ট ব্রেন্ট ওজার চার বছর আগে একটি এসকিউএল সার্ভার ম্যাগাজিন নিবন্ধ প্রকাশিত হওয়া উচিত ছিল না বলে প্রতিক্রিয়া জানিয়ে একাধিক সংস্থার দিকে ইঙ্গিত করে লিখেছিল ।
পল র্যান্ডালের একটি ব্লগ পোস্ট ব্যাখ্যা করছে যে টি-লগ রক্ষণাবেক্ষণ কেন গুরুত্বপূর্ণ এবং কেন আপনার ডেটা ফাইল সঙ্কুচিত করা উচিত নয় ।
মাইক ওয়ালশের একটি দুর্দান্ত উত্তর রয়েছে যার মধ্যে এই কয়েকটি দিকও রয়েছে যার সাথে আপনি নিজের লগ ফাইলটি তাত্ক্ষণিকভাবে সঙ্কুচিত করতে পারবেন না এমন কারণগুলিও অন্তর্ভুক্ত রয়েছে ।
