আমার কাছে কেবল 2 জিবি বাকি আছে, সুতরাং আমার এই ইতিহাসের টেবিলটি সরিয়ে ফেলতে হবে। এই টেবিলটি এখন খালি কিন্তু ডাটাবেস ডিস্কের স্থান প্রকাশিত হয়নি। এবং ডাটাবেস ফাইলটি 320 জিবি।
উত্তর:
আপনি যদি ভলিউমে প্রকৃত ডাটাবেস ফাইল ব্যবহারের বিষয়ে উল্লেখ করছেন, তবে এসকিউএল সার্ভার স্বয়ংক্রিয়ভাবে এটি পরিচালনা করে না । আপনি ডাটাবেস থেকে ডেটা সরিয়েছেন তার অর্থ এই নয় যে ডাটাবেস ফাইলগুলি কেবল বিদ্যমান ডেটা ফিট করার জন্য সঙ্কুচিত হবে।
আপনি হলে কি আপনি খুঁজছেন করা চাই আছে ভলিউমে শূণ্যস্থান একত্রিত করার জন্য, সঙ্গে বিশেষ ফাইল মাপে হবে DBCC SHRINKFILE। সেই ডকুমেন্টেশন অনুসারে কয়েকটি সেরা অনুশীলনগুলি লক্ষ্য করার মতো:
সেরা অনুশীলন
আপনি কোনও ফাইল সঙ্কুচিত করার পরিকল্পনা করার সময় নিম্নলিখিত তথ্যগুলি বিবেচনা করুন:
একটি সঙ্কোচন অপারেশন একটি অপারেশনের পরে সবচেয়ে কার্যকর হয় যা প্রচুর অব্যবহৃত স্থান তৈরি করে, যেমন একটি কাটা টেবিল বা একটি ড্রপ টেবিল অপারেশন।
বেশিরভাগ ডাটাবেসগুলিতে নিয়মিত প্রতিদিন কাজকর্মের জন্য কিছু মুক্ত স্থানের প্রয়োজন। যদি আপনি বারবার একটি ডাটাবেস সঙ্কুচিত করেন এবং লক্ষ্য করেন যে ডাটাবেসের আকার আবার বেড়েছে, এটি নির্দেশ করে যে সঙ্কুচিত হওয়া স্থানটি নিয়মিত ক্রিয়াকলাপের জন্য প্রয়োজন। এই ক্ষেত্রে, বারবার ডাটাবেস সঙ্কুচিত করা একটি নষ্ট অপারেশন।
একটি সঙ্কুচিত ক্রিয়াকলাপ ডাটাবেসে সূচকের খণ্ডিত অবস্থা সংরক্ষণ করে না এবং সাধারণত বিভাজনকে একটি ডিগ্রীতে বৃদ্ধি করে। এটি বারবার ডাটাবেস সঙ্কুচিত না করার আরেকটি কারণ।
একযোগে পরিবর্তে একই ডাটাবেসে একাধিক ফাইল সঙ্কুচিত করুন। সিস্টেম টেবিলগুলিতে বিতর্ক অবরুদ্ধ হওয়ার কারণে বিলম্ব ঘটাতে পারে।
উল্লেখ্য:
DBCC SHRINKFILEপ্রক্রিয়াটির যে কোনও পর্যায়ে অপারেশনগুলি থামানো যেতে পারে, এবং যে কোনও সমাপ্ত কাজ ধরে রাখা হয়।
এটি করার সময় অবশ্যই কয়েকটি বিষয় বিবেচনা করতে হবে এবং আমি আপনাকে এই অপারেশনটি করার পরে কী ঘটবে সে সম্পর্কে পল রান্ডালের ব্লগ পোস্টটি একবার দেখার পরামর্শ দিই ।
প্রথম পদক্ষেপটি নিশ্চিতভাবেই হবে যে আপনি প্রকৃতপক্ষে কতগুলি স্থান এবং মুক্ত স্থান প্রতিস্থাপন করতে সক্ষম হবেন, সেই সাথে ফাইলগুলিতে ব্যবহৃত স্থানটিও যাচাই করা হবে:
use AdventureWorks2012;
go
;with db_file_cte as
(
select
name,
type_desc,
physical_name,
size_mb =
convert(decimal(11, 2), size * 8.0 / 1024),
space_used_mb =
convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
from sys.database_files
)
select
name,
type_desc,
physical_name,
size_mb,
space_used_mb,
space_used_percent =
case size_mb
when 0 then 0
else convert(decimal(5, 2), space_used_mb / size_mb * 100)
end
from db_file_cte;
আপনি যখন টেবিলটি কেটে ফেলেন এবং বুকস অনলাইনে 128 এরও বেশি এক্সটেন্টস অপসারণের সাথে জড়িত থাকে তখন এটি স্বাভাবিক আচরণ
আপনি যখন বৃহত সূচকগুলি ফেলে বা পুনর্নির্মাণ করেন, বা বড় টেবিলগুলি ফেলে বা ছাঁটাই করেন, তখন ডাটাবেস ইঞ্জিন কোনও লেনদেন সীমাবদ্ধ না হওয়া অবধি আসল পৃষ্ঠা অবলম্বন এবং তাদের সম্পর্কিত লকগুলি ডিফেন্ড করে। এই প্রয়োগটি বহুমুখী পরিবেশে স্বতঃসংশোধন এবং সুস্পষ্ট লেনদেন উভয়কেই সমর্থন করে এবং বড় টেবিল এবং সূচকগুলিতে প্রযোজ্য যা 128 এর বেশি এক্সটেন্ট ব্যবহার করে।
লজিকাল এবং শারীরিক: পৃথক দুটি ধাপে প্রক্রিয়া বিভক্ত করে বড় অবজেক্টগুলি ফেলে দেওয়ার জন্য প্রয়োজনীয় বরাদ্দ লকগুলি ডাটাবেস ইঞ্জিন এড়িয়ে চলে।
যৌক্তিক পর্যায়ে, সারণী বা সূচকের দ্বারা ব্যবহৃত বিদ্যমান বরাদ্দ ইউনিটগুলি লেনদেনের জন্য চিহ্নিত করা হয় এবং লেনদেন না হওয়া পর্যন্ত লক করা হয়। বাদ পড়া ক্লাস্টারড ইনডেক্সের সাথে, ডাটা সারিগুলি অনুলিপি করা হয় এবং তারপরে পুনর্নির্মিত ক্লাস্টারড ইনডেক্স বা হিপ স্টোরের তৈরি নতুন বরাদ্দ ইউনিটে স্থানান্তরিত হয়। (কোনও সূচি পুনর্নির্মাণের ক্ষেত্রে, ডাটা সারিগুলিও বাছাই করা হয় a) যখন কোনও রোলব্যাক থাকে, কেবলমাত্র এই যৌক্তিক পর্যায়ে ফিরে যেতে হবে।
লেনদেন শুরুর পরে শারীরিক পর্ব ঘটে। বিলম্বের জন্য চিহ্নিত বরাদ্দ ইউনিটগুলি শারীরিকভাবে ব্যাচগুলিতে বাদ দেওয়া হয়। এই ড্রপগুলি পটভূমিতে সংক্ষিপ্ত লেনদেনের ভিতরে পরিচালিত হয় এবং প্রচুর লক প্রয়োজন হয় না।
যেহেতু কোনও লেনদেন করার পরে শারীরিক পর্ব ঘটে, তাই সারণী বা সূচকের সঞ্চয় স্থানটি এখনও অনুপলব্ধ হিসাবে উপস্থিত হতে পারে। যদি এই স্থানটি দৈহিক পর্ব শেষ হওয়ার আগে ডেটাবেস বৃদ্ধির জন্য প্রয়োজন হয়, ডেটাবেস ইঞ্জিন অবলম্বনের জন্য চিহ্নিত বরাদ্দ ইউনিটগুলি থেকে স্থান পুনরুদ্ধার করার চেষ্টা করে। এই বরাদ্দ ইউনিটগুলির দ্বারা বর্তমানে ব্যবহৃত স্থানটি অনুসন্ধান করতে, sys.allocation_units ক্যাটালগ ভিউটি ব্যবহার করুন।
বিলম্বিত ড্রপ ক্রিয়াকলাপগুলি অবিলম্বে বরাদ্দ স্থান ছেড়ে দেয় না এবং তারা ডেটাবেস ইঞ্জিনে অতিরিক্ত ওভারহেড ব্যয় প্রবর্তন করে। সুতরাং, যে সারণী এবং সূচকগুলি 128 বা তার চেয়ে কম এক্সটেন্ট ব্যবহার করে সেগুলি এসকিউএল সার্ভার 2000-এর মতোই বাদ দেওয়া হয়, কেটে ফেলা হয় এবং পুনর্নির্মাণ করা হয় This এর অর্থ লেনদেন শুরুর আগেই যৌক্তিক এবং শারীরিক উভয় পর্যায় ঘটে।
আপনাকে অপেক্ষা করতে হবে এবং অবশ্যই স্থানটি পুনরুদ্ধার করতে আপনাকে ম্যানুয়ালি ফাইলটি সঙ্কুচিত করতে হবে এটিরও উল্লেখযোগ্য যে সঙ্কুচিত হওয়ার কারণে যৌক্তিক খণ্ডন ঘটে এবং আপনার প্রয়োজনীয়তা গুরুতর না হলে এড়ানো উচিত। আপনার কিছুটা কীভাবে সঙ্কুচিত হওয়া এবং টুকরো টুকরো করার মধ্যে ভারসাম্য রইল। নিজেকে জিজ্ঞাসা করা আরও ভাল যে সঙ্কুচিত হওয়া পরিস্থিতি বিবেচনা করে সমস্যাটি সমাধান করবে কিনা যেখানে ডেটা আবার কোনওভাবে বাড়বে।
ডাটাবেসে কতটা ফাঁকা জায়গা রয়েছে তা যাচাই করতে নীচের ক্যোয়ারীটি ব্যবহার করুন
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;টমস এবং শ্যাঙ্কির উত্তরগুলি ছাড়াও, যদি আপনার ডাটাবেসে LOB / BLOB ডেটা থাকে তবে DBCC SHRINKFILE কাজ করতে পারে না। যদি এটি হয় তবে আপনি ডাটাবেস অফলাইনে নিতে পারবেন কিনা তা নির্ভর করে আপনার দুটি বিকল্প রয়েছে have আপনি যদি ডাটাবেসটিকে অফলাইনে নিতে পারেন তবে খালি স্থানটি সরাতে আপনাকে ডেটা অনুলিপি করে আবার কপি করতে হবে। আপনি নিম্নলিখিতগুলির মধ্যে একটি দ্বারা এটি সম্পাদন করতে পারেন:
আপনি যদি অফলাইনে ডাটাবেসটি নিতে না পারেন তবে আপনি EMPTYFILE বিকল্পের সাহায্যে DBCC SHRINKFILE কমান্ডটি ব্যবহার করতে পারেন ।
অফলাইন অনুলিপিটির জন্য বিশদ: http://support.microsoft.com/kb/324432/en-us
EMPTYFILE বিকল্পের জন্য বর্তমান তথ্য http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx