এটি সত্যিই সমস্ত ক্রেজি মনে হয় না, তবে লক্ষ্য রাখবেন যে কিছু ইউআই ডায়ালগের সম্পূর্ণ আপ টু ডেট তথ্য না থাকতে পারে (এই কারণেই আমাদের কাছে ডিবিসিসি আপডেটের মতো জিনিস রয়েছে ), এবং রাউন্ডিংও সেগুলির মধ্যে কিছুতে জড়িত থাকতে পারে গণনার। শেষ অবধি, ডায়ালগগুলি আপনাকে পুরো ডাটাবেসের জন্য মোট স্থান দেখায় , কিন্তু অনির্ধারিত স্থানটি কেবল ডেটা ফাইলের জন্য গণনা করা হয় , লগ নয়।
আসুন কিছু জিনিস একত্রিত করা যাক।
- ডাটাবেস বৈশিষ্ট্য এবং সঙ্কুচিত ডাটাবেস একই জিনিস দেখায় (যে আপনি যেভাবে যাইহোক, ডাটাবেস UI সঙ্কুচিত করা উচিত নয়!)।
- ডেটাবেস ফাইলের বৈশিষ্ট্যগুলি 17 + 75 = 92 দেখায় যা যোগ করার আগে গোল করে, সম্ভবত 1-এ একই 91.31।
- বরাদ্দ স্থানের জন্য, পৃথক ফাইলগুলির জন্য সঙ্কুচিত 16.38 + 74.94 = 91.32 - আবার, সম্ভবত কিছু গোলাকার হবে, অন্যথায় ঠিক 1 টি মিলবে।
- স্থান উপলব্ধ থাকার জন্য, পৃথক ফাইলগুলির জন্য সঙ্কোচিত হ'ল একমাত্র জায়গা যেখানে আমি একটি সত্য তাত্পর্যতা সন্দেহ করি এবং এটি হ'ল ইউআই যেখানে এটির ডেটা পায় সে সম্পর্কে অসঙ্গতিপূর্ণ এবং এই জায়গাগুলির মধ্যে কিছুটি ক্যাচিংয়ের সাপেক্ষে ডিবিসিসি আপডেটের প্রয়োজন।
আমার এই অ্যাডভেঞ্চার ওয়ার্কস ২০১২ এর স্থানীয় অনুলিপিটির ( এই স্ক্রিপ্টটি থেকে কিছু বিস্তৃত টেবিল সহ ) এই বিভিন্ন সংলাপগুলি কী চালায় সে সম্পর্কে একবার নজর দেওয়া যাক ।
EXEC sp_spaceused;
এই রিটার্ন (শুধুমাত্র প্রথম রেজাল্ট):
database_size unallocated space
------------- -----------------
1545.81 MB 6.67 MB
মূলত এটি চালায়, যা - আমি ট্রেসের মাধ্যমে নিশ্চিত করেছি - ডাটাবেস বৈশিষ্ট্য এবং ডাটাবেস সঙ্কুচিত কথোপকথনগুলি থেকে প্রায় একই প্রশ্নটি কার্যকর করা হয়েছে (আমি সঞ্চিত পদ্ধতি থেকে অপ্রাসঙ্গিক অংশগুলি খোদাই করেছি এবং গণিতের প্রতিনিধিত্ব করার জন্য একটি বহিরাগত কোয়েরি যুক্ত করেছি) যা এসএসএমএস প্রদর্শনের জন্য করে):
SELECT database_size = DbSize*8.0/1024 + LogSize*8.0/1024,
[unallocated space] = (DbSize-SpaceUsed)*8.0/1024
FROM
(
SELECT
(SELECT SUM(CAST(df.size as float)) FROM sys.database_files AS df
WHERE df.type in ( 0, 2, 4 ) ) AS [DbSize],
SUM(a.total_pages) AS [SpaceUsed],
(SELECT SUM(CAST(df.size as float)) FROM sys.database_files AS df
WHERE df.type in (1, 3)) AS [LogSize]
FROM sys.partitions p
join sys.allocation_units a on p.partition_id = a.container_id
left join sys.internal_tables it on p.object_id = it.object_id
) AS x;
এটি একটি ম্যাচ ফেরায়:
database_size unallocated space
------------- -----------------
1545.8125 6.671875
এই কথোপকথনগুলি এই তথ্যটি সঠিকভাবে দেখায়। ডাটাবেস বৈশিষ্ট্য ডায়ালগ:
সংক্ষিপ্ত ডাটাবেস ডায়ালগ:
অন্যদিকে সঙ্কুচিত ফাইল ডায়লগগুলি কিছুটা আলাদা ক্যোরি চালায় (আবার এটি সুবিধার জন্য খোদাই করা / অভিযোজিত):
SELECT SUBSTRING(name, CHARINDEX('_',name)+1, 4),
[Currently allocated space] = size/1024.0,
[Available free space] = (Size-UsedSpace)/1024.0
FROM
(
SELECT s.name,
CAST(FILEPROPERTY(s.name, 'SpaceUsed') AS float)*CONVERT(float,8) AS [UsedSpace],
s.size * CONVERT(float,8) AS [Size]
FROM sys.database_files AS s
WHERE (s.type IN (0,1))
) AS x;
নোট, এছাড়াও, একটি ডিএমভির পরিবর্তে কোনও ফাংশন থেকে আকারের ডেটা প্রাপ্ত করার পাশাপাশি, ফাইল স্ট্রিম / হেকাটনের মতো নতুন ফাইল প্রকারের জন্য পূর্বাভাসগুলি আপডেট করা হয়নি।
ফলাফল:
Currently allocated space Available free space
---- ------------------------- --------------------
Data 1517 7.9375 -- wrong
Log 28.8125 25.671875 -- wrong
সমস্যাটি হ'ল FILEPROPERTY()ফাংশন, যা আপ টু ডেট থাকার গ্যারান্টিযুক্ত নয় (এমনকি DBCC UPDATEUSAGE(0);চালানোর পরেও ; আরও নীচে)। এটি সংলাপগুলিতে এই বিভ্রান্তিমূলক তথ্য দিয়ে শেষ হয়:
দ্রষ্টব্য, আবারও, 6.67 মেগাবাইটটি কখনই সত্যই সঠিক ছিল না, যেহেতু এটি কেবলমাত্র ডাটাবেসের মোট আকার পরিমাপ করছে - লগকে সম্পূর্ণ উপেক্ষা করে, বরাদ্দ করা পৃষ্ঠাগুলির সংখ্যা।
সমস্ত সততার সাথে, আপনি যদি ডাটাবেসে ব্যবহৃত স্থানের সঠিক প্রতিবেদন করতে চান তবে মিকি মাউস ইউআই ব্যবহার বন্ধ করুন যা এগুলি বের করার জন্য বিভিন্ন ধরণের অনুসন্ধান চালায় এবং তথ্য পুনরুদ্ধারের জন্য সঙ্কুচিত ফাইল ডায়ালগগুলি ব্যবহার বন্ধ করুন। এগুলি নির্দিষ্ট ক্ষেত্রে বাসি ডেটা সমস্যার সাথে স্পষ্ট হয়। আপনি বিশ্বাস করতে পারেন এমন উত্সের বিরুদ্ধে একটি আসল জিজ্ঞাসা চালান। আমি যা পছন্দ করি তা এখানে:
DECLARE @log_used DECIMAL(19,7);
CREATE TABLE #x(n SYSNAME, s DECIMAL(19,7), u DECIMAL(19,7), b BIT);
INSERT #x EXEC('DBCC SQLPERF(LogSpace);');
SELECT @log_used = u FROM #x WHERE n = DB_NAME();
DROP TABLE #x;
DECLARE @data_used DECIMAL(19,7);
SELECT @data_used = SUM(a.total_pages)*8/1024.0
FROM sys.partitions AS p
INNER JOIN sys.allocation_units AS a
ON p.[partition_id] = a.container_id;
;WITH x(t,s) AS
(
SELECT [type] = CASE
WHEN [type] IN (0,2,4) THEN 'data' ELSE 'log' END,
size*8/1024.0 FROM sys.database_files AS f
)
SELECT
file_type = t,
size = s,
available = s-CASE t WHEN 'data' THEN @data_used ELSE @log_used END
FROM x;
এই ক্যোয়ারিতে তিনটি সংখ্যা ফিরে আসে যা খুব পরিচিত হওয়া উচিত, এবং এমন একটি যা:
file_type size available
--------- ----------- ----------
data 1517.000000 6.6718750
log 28.812500 17.9008512
নোট করুন যে ডিবিসিসি এসকিউএলপিআরএফ স্থান ব্যবহারের সাথে সামান্য ঝুঁকিতে রয়েছে, উদাহরণস্বরূপ দৌড়ানোর পরে:
DBCC UPDATEUSAGE(0);
উপরের প্রশ্নটি পরিবর্তে এটির ফল দেয়:
file_type size available
--------- ----------- ----------
data 1517.000000 8.0781250
log 28.812500 17.8669481
sp_spaceusedএখন আবার মিলও সংখ্যাগুলি ( 1545.81 MB / 8.08 MB) উত্পন্ন করে , যদিও - আবার - এটি কেবলমাত্র ডেটা ফাইল (গুলি) তে উপলব্ধ স্থান এবং ডাটাবেস সম্পত্তি এবং ডাটাবেস সঙ্কুচিত ডায়ালগগুলি পাশাপাশি "নির্ভুল" (তবে সঙ্কুচিত ফাইল ডায়লগগুলি এখনও রয়েছে উপায় বন্ধ - FILEPROPERTY()এটি মোটেই প্রভাবিত হবে বলে মনে হয় না UPDATEUSAGE):
ওহ, এবং পাশাপাশি উইন্ডোজ এক্সপ্লোরার এই ফাইলগুলির সম্পর্কে কী ভাবায় তাও দেখায়, তাই আপনি এমবি নির্ধারণের জন্য গণনাগুলির সাথে সম্পর্কিত করতে পারেন:
এগুলি কতটা সঠিক হওয়া দরকার তা অবশ্যই নির্ভর করে আপনি তথ্যের সাথে কী করতে চলেছেন on