রাতের ব্যাকআপ সহ সহজ পুনরুদ্ধার মোডে কেন লেনদেন লগ বাড়তে থাকে?


24

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

বিশদ: আমার কাছে এসকিউএল সার্ভার ২০০৮ আর 2-তে ~ 200 এমবি ডেটা ফাইল এবং ~ 300 এমবি লগ ফাইল সহ সমস্ত সিম্পল পুনরুদ্ধার মোডে (আমার পছন্দ নয়), রাত্রে পুরো ব্যাকআপ রয়েছে a 500 এমবি ডাটাবেস। লগটি তাত্ক্ষণিকভাবে 300MB তে বাড়বে না, বরং কয়েক মাসের ব্যবধানে ধীরে ধীরে। কমপক্ষে sp_Wo2 এবং ক্রিয়াকলাপের মনিটরের অনুসারে তাদের কোনওটিতে কোনও লেনদেন নেই। আমি যদি ডাটাবেসে ডান-ক্লিক করি এবং বৈশিষ্ট্যগুলি নির্বাচন করি তবে এটি আমাকে বলে tells 50MB বিনামূল্যে। বিশেষত ব্যাকআপের ঠিক পরে, পুরো লগটি কি বিনামূল্যে রাখা উচিত নয়? সিম্পল মোডে লগটি যতক্ষণ না খোলা লেনদেন না হওয়া উচিত তা বিনামূল্যে হওয়া উচিত নয়?

log_reuse_wait_descথেকে sys.databases"নাথিং" বলেছে, যা উপরে উল্লিখিত প্রশ্নোত্তরের ভিত্তিতে বলেছে যে স্থানটি পুনরায় ব্যবহার করার জন্য কোনও কিছুর জন্য অপেক্ষা করা উচিত নয়।

আমি যদি 'ডিবিসিসি শ্রিনকফিল' করি, লগ ফাইলটি 1 এমবিতে সঙ্কুচিত হয়, তাই এটি স্থানটি পুনরায় দাবি করতে রাজি। আমি এমন কিছু সেট আপ করতে পারি যা সাপ্তাহিক লগগুলিকে সঙ্কুচিত করে এবং নিয়ন্ত্রণ থেকে বেরিয়ে আসা থেকে বাঁচায় তবে এসকিউএল সার্ভার কেন আমাকে তা করতে বাধ্য করবে তা নিয়ে আমি বিভ্রান্ত।

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

সরল রিকভারি মডেল - সুতরাং উপরোক্ত ভূমিকাটির সাথে প্রথমে সরল রিকভারি মডেল সম্পর্কে কথা বলা সবচেয়ে সহজ। এই মডেলটিতে, আপনি এসকিউএল সার্ভারকে বলছেন - ক্র্যাশ এবং পুনরুদ্ধার পুনরুদ্ধারের জন্য আপনার লেনদেনের লগ ফাইলটি ব্যবহার করার সাথে আমি ভাল আছি (আপনার সত্যিকারের কোনও পছন্দ নেই .. এসিডি বৈশিষ্ট্যগুলি দেখুন এবং এটি দ্রুত বোঝা উচিত) তবে একবার আপনি না ক্র্যাশ / পুনরুদ্ধার পুনরুদ্ধারের উদ্দেশ্যে পুনরায় আরম্ভ করার প্রয়োজন নেই, এগিয়ে যান এবং লগ ফাইলটি পুনরায় ব্যবহার করুন।

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

এটি বলছে যে লগ স্পেসটি পুনরায় ব্যবহার করা উচিত, তবে কয়েক মাস ধরে এই ধীর গতিতে, মনে হয় না এটি এটি।

আমি কী মিস করছি? কিছু কি এসকিউএল সার্ভারকে ডেটাটিকে "শক্ত" হিসাবে স্বীকৃতি এবং লগটি মুক্ত করার হাত থেকে রক্ষা করছে?

(সম্পাদনা) অ্যাকশন রিপোর্টের পরে - একে একে সামান্য জ্ঞান বিপদজনক

এটি একটি "জনপ্রিয় প্রশ্ন" হিসাবে আবিষ্কার করার পরে, মনে হয়েছিল যে আমি 7 মাস আগে কী ঘটেছিল এবং আমি আশা করি যে আরও কিছু লোককে কিছুটা দুঃখ বাঁচাতে শিখেছি তার একটি ব্যাখ্যা আমার কাছে ধার্য ছিল।

প্রথমে, যখন আপনি একটি ডাটাবেসে বৈশিষ্ট্য দেখেন তখন এসএসএমএসে আপনি যে স্থানটি দেখতে পাচ্ছেন তা হ'ল ডেটা ফাইলের মধ্যে স্থান। আপনি এটি ডাটাবেসে নিম্নলিখিতটি চালিয়ে দেখতে পারেন এবং এসএসএমএস দ্বারা রিপোর্ট করা স্থানটি ফাইলসাইজএমবি এবং ব্যবহৃতস্পেসএমবি এর মধ্যে পার্থক্যটি পেয়ে যাবেন:

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

এটি নিশ্চিত করেছে যে সাধারণ পরিস্থিতিতে আমরা খুব অল্প লগ স্পেস (২০ এমবি বা তার চেয়ে কম) ব্যবহার করছিলাম তবে এটি দ্বিতীয় আইটেমের দিকে নিয়ে যায় ...

দ্বিতীয়ত, লগগুলির ক্রমবর্ধমান সম্পর্কে আমার ধারণাগুলি সময়ের সাথে ধীরে ধীরে ছিল। তবে, বাস্তবে এই তৃতীয় পক্ষের অ্যাপ্লিকেশনটির জন্য প্যাচ প্রয়োগ করার জন্য দায়ী ব্যক্তি প্যাচগুলি প্রয়োগ করার জন্য রাত্রে লগগুলি দ্রুত বাড়ছিল। প্যাচটি একটি একক লেনদেন হিসাবে করা হয়েছিল, সুতরাং প্যাচের উপর নির্ভর করে 200MB ডেটা 300MB লগের প্রয়োজন। এটি নিখুঁত করার মূল কীটি ছিল https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace এ অ্যারন বার্ট্র্যান্ডের প্রশ্নের

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

এটি দেখায় যে কোনও নির্দিষ্ট সন্ধ্যায় লগ বাড়তে থাকে, যখন গ্রাহক ডাটাবেস ব্যবহার করেন না। এটি প্যাচগুলি প্রয়োগ করে এবং রহস্যের উত্তরটি দিয়ে লোকটির সাথে কথোপকথনের দিকে পরিচালিত করে।

যারা আমাকে উত্তরটি পেতে সহায়তা করেছেন তাদের জন্য আবার ধন্যবাদ


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

উত্তর:


20

এটি কী কারণে ঘটছে তা অনুমান করা আমাদের পক্ষে অসম্ভব, তবে এসকিউএল সার্ভার এটির হেকের জন্য কেবল একটি লগ ফাইল 300 এমবিতে বাড়ায় না, এটি 300 এমবিতে বৃদ্ধি পায় কারণ আপনার শেষ সঙ্কুচিত অপারেশন থেকে কোনও এক সময় এটির প্রয়োজন ছিল প্রচুর লগ স্পেস (কিছু বড় একক লেনদেনের কারণে বা অনেকগুলি সামনের একত্রে) whether আপনি যখন লগ ফাইল বর্ধনের ইভেন্টগুলি (আমি এখানে এবং এখানে এই সম্পর্কে কথা বললাম ) এটি করতে বা সংকীর্ণ করার চেষ্টা করতে চাই যখন কখন বা কেন ঘটে (এছাড়াও আপনি যদি ফাইল বর্ধন সেটিং 300 এমবি বা কোনও কিছুতে লগ করেন তবে এটি 300 এমবি দ্বারা বৃদ্ধি পাবে) সক্রিয় লেনদেনের জন্য এটির জন্য 1 এমবিরও বেশি স্থানের দরকার পড়ার সাথে সাথে)।

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


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

1
না, এটি হয়ে গেলে এটি স্বয়ংক্রিয়ভাবে মুক্ত স্থান হয়ে যায় না। প্রতিশ্রুতিবদ্ধ লেনদেনগুলি শূন্য হয় না, তাদের স্থানটি পুনরায় ব্যবহারের জন্য উপলভ্য হিসাবে চিহ্নিত করা হয়েছে।
অ্যারন বারট্রান্ড

1
@ ডেরেককেট "আমি মনে করি না যে আমরা এমন কিছু করছি যা 300 মেগাবাইট লগের প্রয়োজন হবে" ... আপনি অবাক হবেন, লেনদেনের লগ পুনরায় ব্যবহারে আবদ্ধ হতে খুব বেশি লাগে না doesn't কাজের চাপের পরিমাণের দিক থেকে এটিকে ভাবেন না, কারণ এটি সর্বদা কারণ নয়।
থমাস স্ট্রিংগার

ঠিক আছে, তাই কেবল আমি এটি সঠিকভাবে বুঝতে পেরেছি তা নিশ্চিত করার জন্য, 300MB লগ, বর্তমানে প্রয়োজন না হলেও খালি স্থান হিসাবে দেখাবে না, তবে পুনরায় ব্যবহার করা হবে। এবং এক পর্যায়ে কিছু লেনদেন পরিচালনার জন্য এটি 300MB প্রয়োজন। ঠিক আছে, নতুন জিনিসগুলি সন্ধান করতে হবে। ধন্যবাদ!
ডেরেকেট

1
আরেকটি বিষয় বিবেচনা করতে হবে: লগ ইতিমধ্যে 70% পূর্ণ হয়ে গেলে কেবল একটি সহজ পুনরুদ্ধার ডাটাবেসের জন্য একটি স্বয়ংক্রিয় চেকপয়েন্টটি সারিযুক্ত হয়। সুতরাং, সময় নির্ভর উপর নির্ভর করে আপনার বৃদ্ধির ফলস্বরূপ এতগুলি লগ ক্রিয়াকলাপের প্রয়োজন হবে না।
পল হোয়াইট GoFundMonica বলেছেন

6

আপনার বর্তমান সমস্ত পরীক্ষাগুলি ( DBCC SHRINKFILE, log_reuse_wait_desc) কেবলমাত্র এখনই প্রমাণ করছে যে আপনি লেনদেন লগের ভার্চুয়াল লগ ফাইলগুলি যথাযথভাবে পুনরায় ব্যবহার করছেন। কিন্তু যখন আপনার লেনদেনের লগ ফাইলগুলিতে আপনার অটো বর্ধনের ইভেন্টগুলি ঘটে তখন লগটি পুনরায় ব্যবহার করা যায় না এমন প্রতিক্রিয়া।

পুন: পুন, যে নয় একটি চলমান অবস্থায় (ঠিক কিভাবে উপসর্গ আপনি বর্তমানে দেখছি অভাব সাথে সঠিক এখন আপনি বলে মনে হয়)। মুষ্টিমেয় কিছু জিনিস রয়েছে যা এই আচরণের কারণ হতে পারে, এমনকি সহজ পুনরুদ্ধারের মডেলটিতেও।

আপনার সেরা বেট হ'ল log_reuse_wait_descআপনার ডাটাবেসটির জন্য নিয়মিতভাবে টানতে কোনও তথ্য সংগ্রহের কাজ সেটআপ করা এবং নিয়মিতভাবে এটি কোথাও লগইন করা। তারপরে আপনার লগ পুনরায় ব্যবহারের অভাবজনিত কারণে রিভার্স-ইঞ্জিনিয়ার সক্ষম হওয়া উচিত।

এটি বলছে যে লগ স্পেসটি পুনরায় ব্যবহার করা উচিত, তবে কয়েক মাস ধরে এই ধীর গতিতে, মনে হয় না এটি এটি।

আমি উপরে ইঙ্গিত হিসাবে, এটি সাধারণত চলমান শর্ত নয় যা লেনদেনের লগ পুনরায় ব্যবহারের অভাবের কারণ হয় (বেশ কয়েকটি কোণার কেস যেমন খারাপভাবে নির্মিত লেনদেনের মতো সংরক্ষণ করে), তাই আপনাকে কখন এটি ঘটতে হবে তা চিহ্নিত করতে হবে । লাইটওয়েট ডায়াগনস্টিক ডেটা সংগ্রহের একটি ভাল শুরু হওয়া উচিত।


যদি তিনি 50MB ফ্রি দেখতে পান এবং 300MB লগটি fn_DBLOG () তার লগের আকার বাড়িয়ে দিচ্ছিল তাতে তাকে কিছুটা অন্তর্দৃষ্টি দেবে?
কেনেথ ফিশার

0

আপনি কি ডিবিগুলিতে স্বয়ংক্রিয়-সঙ্কোচন সক্ষম করেছেন? এবং / অথবা আপনার সূচি পুনর্নির্মাণগুলি সম্পাদন করার পরিকল্পনা নির্ধারণ করেছে?

সূচকের রক্ষণাবেক্ষণের পরে একটি অটো-সঙ্কোচন উল্লেখযোগ্য লগ ভলিউম তৈরি করবে।

জিডিইউগুলিতে ক্লাস্টারড ইনডেক্সের মতো ডিবি ডিজাইনের সমস্যা থাকলে, নিজেই সূচক রক্ষণাবেক্ষণও উল্লেখযোগ্য লগের ভলিউম তৈরি করে।


ডিবিগুলিতে অটো সঙ্কোচন সক্ষম করা নেই, আমরা সূচী বিভাজনগুলি বন্টনজার / অর্চাইভ / ২০০৯ / ২০১৮ এড়াতে চাইছি । আমাদের সাপ্তাহিক অখণ্ডতা চেক আছে, তবে আমি মনে করি না যে এর সূচক হিসাবে কোনও সূচি পুনর্নির্মাণ আছে, আমাকে এটি সন্ধান করতে হবে। এগুলি ছাড়া, কোনও জিইউডি নেই, প্রতিটি টেবিলের একটি পরিচয় কলাম রয়েছে যা প্রাথমিক কী।
ডেরেকেট

-3
 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.