ডাটাবেসের জন্য লেনদেন লগ পূর্ণ

Question

আমার একটি দীর্ঘ চলমান প্রক্রিয়া রয়েছে যা পুরো সময়ের জন্য একটি লেনদেন উন্মুক্ত করে।

এটি যেভাবে কার্যকর করা হয় তাতে আমার কোনও নিয়ন্ত্রণ নেই।

কারণ কোনও লেনদেন সম্পূর্ণ সময়কালের জন্য উন্মুক্ত রাখা হয়, যখন লেনদেনের লগ পূরণ হয়, এসকিউএল সার্ভার লগ ফাইলের আকার বাড়াতে পারে না।

প্রক্রিয়া ত্রুটি সঙ্গে ব্যর্থ হয় "The transaction log for database 'xxx' is full"।

আমি ডাটাবেস বৈশিষ্ট্যগুলিতে লেনদেন লগ ফাইলের আকার বাড়িয়ে এটি প্রতিরোধ করার চেষ্টা করেছি, তবে আমি একই ত্রুটি পেয়েছি।

আমার পরবর্তী কী চেষ্টা করা উচিত তা নিশ্চিত নয়। প্রক্রিয়াটি কয়েক ঘন্টা ধরে চলে তাই এটি পরীক্ষা এবং ত্রুটি খেলানো সহজ নয়।

কোন ধারনা?

যদি কেউ আগ্রহী হন তবে প্রক্রিয়াটি হ'ল একটি সংস্থা আমদানি Microsoft Dynamics CRM 4.0.

ডিস্কের প্রচুর জায়গা রয়েছে, আমাদের সহজ লগিং মোডে লগ আছে এবং প্রক্রিয়াটি সরিয়ে দেওয়ার আগে লগটিকে ব্যাক আপ করেছিলাম।

- = - = - = - = - আপডেট - - - - - - - - - -

এতক্ষণের মন্তব্যের জন্য সকলকে ধন্যবাদ। নিম্নলিখিতটি আমাকে বিশ্বাস করতে পরিচালিত করেছিল যে প্রকাশ্য লেনদেনের কারণে লগটি বাড়বে না:

আমি নিম্নলিখিত ত্রুটি পাচ্ছি ...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

সুতরাং সেই পরামর্শ অনুসরণ করে আমি " log_reuse_wait_desc column in sys.databases" গিয়েছিলাম এবং এটির " ACTIVE_TRANSACTION" মান রয়েছে ।

মাইক্রোসফ্ট এর মতে: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

এর অর্থ নিম্নলিখিতগুলি:

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

• একটি লেনদেন স্থগিত করা হয় (এসকিউএল সার্ভার 2005 এন্টারপ্রাইজ সংস্করণ এবং কেবল পরবর্তী সংস্করণগুলি)। একটি বিলম্বিত লেনদেন কার্যকরভাবে একটি সক্রিয় লেনদেন যার রোলব্যাক কিছু অনুপলব্ধ সংস্থার কারণে অবরুদ্ধ। স্থগিত লেনদেনের কারণগুলি এবং কীভাবে তাদের পিছিয়ে যাওয়া অবস্থার বাইরে নিয়ে যাওয়া যায় সে সম্পর্কে তথ্যের জন্য, স্থিত লেনদেন দেখুন।

আমি কিছু ভুল বুঝেছি?

- = - = - = - আপডেট 2 - = - = - = -

প্রারম্ভিক লগ ফাইলের আকারটি 30 জিবি সেট করে সবেমাত্র প্রক্রিয়াটি সরিয়ে দেওয়া হয়েছে। এটি সম্পূর্ণ হতে কয়েক ঘন্টা সময় নেবে।

- = - = - = - চূড়ান্ত আপডেট - = - = - = -

সমস্যাটি আসলে লগ ফাইলের জন্য সমস্ত উপলভ্য ডিস্কের জায়গা ব্যবহার করে caused শেষ প্রয়াসে আমি ১২০ জিবি মুক্তি পেয়েছি এবং এটি এখনও এর সবগুলি ব্যবহার করে এবং শেষ পর্যন্ত ব্যর্থ হয়েছিল।

আমি বুঝতে পারিনি যে এটি আগে ঘটছিল কারণ যখন প্রক্রিয়া রাতারাতি চলছিল, তখন এটি ব্যর্থতায় ফিরে আসছিল। এবার আমি রোলব্যাকের আগে লগ ফাইলের আকার চেক করতে সক্ষম হয়েছি।

আপনার ইনপুট জন্য সমস্ত ধন্যবাদ।

Comments

পুনরায় "... এবং লগ ব্যাক আপ করেছেন" .... যদি ডাটাবেস সিম্পল মোডে থাকে তবে আপনি লগ ব্যাক আপ নিতে পারবেন না, লগ ব্যাকআপগুলি সহজ মোডের জন্য প্রযোজ্য নয়। এটি কি বাল্ক-লগড?

— স্ক্যালাসিড

আমি পুরো ডিবি ব্যাক আপ করেছিলাম এবং এটি সঙ্কুচিত করেছি যার ফলে লগটি 1 এমবিতে সঙ্কুচিত হয়। এরপরে আমি প্রথমে লগ ফাইলটির আকার 20 গিগাবাইটে বাড়িয়েছিলাম এবং এখন 30 জিবি।

— জিম্বো

সম্পর্কিত পোস্ট - TempDB লগিন স্থান এবং ACTIVE_TRANSACTION

— RBT

Answer 1

এটি কি এক সময়ের স্ক্রিপ্ট, বা নিয়মিত কাজ হচ্ছে?

অতীতে, বিশেষ প্রকল্পগুলির জন্য যেগুলি লগ ফাইলের জন্য অস্থায়ীভাবে প্রচুর জায়গা প্রয়োজন, আমি একটি দ্বিতীয় লগ ফাইল তৈরি করে এটিকে বিশাল করে তুলেছি। প্রকল্পটি শেষ হয়ে গেলে আমরা অতিরিক্ত লগ ফাইলটি সরিয়ে ফেলি।

Comments

আমি এটি এক সময়কার কাজ বলব না, তবে আমাদের এটি করা খুব বিরল। আমি দ্বিতীয় লগ ফাইল তৈরি করি নি, তবে আমি আমার বর্তমান লগ ফাইলটির প্রাথমিক আকার 30GB বাড়িয়েছি। আমার শেষ রানের সময় এটি 20 গিগাবাইটে সেট করা হয়েছিল এবং এটি এখনও ব্যর্থ হয়েছিল।

— জিম্বো

আমার কেবলমাত্র একটি ড্রাইভ কাজ করার সাথে সাথে একটি বড় লগ থাকার চেয়ে দ্বিতীয় লগ ফাইলটি কি আরও ভাল হতে পারে?

— জিম্বো

যেমনটি এখনই মনে পড়ছি, অতিরিক্ত ফাইলটি আমাদের বেশিরভাগ ক্ষেত্রে আরও বড় ড্রাইভ অ্যাক্সেস করতে সক্ষম করে।

— মাইক হেন্ডারসন

ডেটা আমদানি করা হচ্ছে কত বড়? আপনি যদি 30 জিবি ডেটা আমদানি করেন তবে আপনার লগ ফাইলটি কমপক্ষে আরও বড় হওয়া দরকার।

— মাইক হেন্ডারসন

লগ আকারের মূল। বর্তমান টাস্কটি আবার ব্যর্থ হয়েছে এবং লগ ফাইলটির আকারটি ব্যর্থ হওয়ার পরে আমি যখন দেখেছি তখন আমি আমার চোখকে বিশ্বাস করতে পারি না। এটি কেবলমাত্র অ্যাকাউন্টগুলির অর্ধেক প্রসেস করেছে এবং ইতিমধ্যে 53 গিগাবাইটে ছিল। দেখে মনে হচ্ছে এই প্রক্রিয়াটি সম্পূর্ণ করতে সক্ষম হতে আমি অন্য 60-70 গিগাবাইটের আশেপাশে কোথাও পরিষ্কার করতে চলেছি।

— জিম্বো

Answer 2

এই সমস্যা সমাধানের জন্য, পরিবর্তন রিকভারি মডেল থেকে সরল তারপর সঙ্কুচিত লগ ফাইল

1. ডাটাবেস বৈশিষ্ট্য> বিকল্পসমূহ> পুনরুদ্ধার মডেল> সাধারণ

2. ডাটাবেস টাস্ক> সঙ্কুচিত> ফাইল> লগ

সম্পন্ন.

তারপরে আপনার ডিবি লগ ফাইলের আকারটি ডাটাবেস প্রোপার্টি> ফাইলস> ডেটাবেস ফাইল> পথের উপর পরীক্ষা করুন

পূর্ণ স্কয়ার সার্ভার লগ চেক করতে: এসএসএমএস> ডেটাবেস> পরিচালনা> এসকিউএল সার্ভার লগস> বর্তমান এ লগ ফাইল প্রদর্শক খুলুন

Comments

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

— জিম্বো

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

— মার্সেল

পারফেক্ট! ধন্যবাদ!

— ইউরি

এটি সমস্যার সমাধান করেনি। আমার লগে মাত্র 500 বাইট রয়েছে। আমি মনে করি গতকাল ব্যাকআপ করার পরে এই সমস্যা শুরু হয়েছিল।

— রিকার্ডো ফ্রান্সা

আপনার যদি পুরো ড্রাইভে কিছুটা মেগাবাইট বাদ দেওয়া থাকে তবে এটি অবশ্যই স্থির।

— স্টিভ বাউমান

Answer 3

আমার একবারে এই ত্রুটি হয়েছিল এবং এটি সার্ভারের হার্ড ড্রাইভ হিসাবে শেষ হয়ে যায় যা ডিস্কের জায়গার বাইরে চলে যায়।

Comments

ওপির আপডেটগুলি পড়ুন। এটি ইস্যুতে পরিণত হয়েছিল।

— কলম্ব

Answer 4

আপনি কি লগ ফাইলের জন্য অটোগ্রোথ এবং সীমাবদ্ধ ফাইল বৃদ্ধি উভয় সক্ষম করেছেন? আপনি এসএসএমএসের মাধ্যমে এটিকে "ডেটাবেস প্রোপার্টি> ফাইলস" এ সম্পাদনা করতে পারেন

Comments

হ্যাঁ. এটি 10% অটোগ্রোতে নির্বিঘ্নিত হয়েছে। সমস্যাটি হ'ল মুক্ত লেনদেনের সময় অটোগ্রো কাজ করবে না।

— জিম্বো

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

— লুইস এলএল

SQL সার্ভার হবে একটি লেনদেন সময় লগ autogrow যদি এটা আরো স্থান প্রয়োজন লেনদেন সম্পূর্ণ করতে।

— রস ম্যাকনাব

হাই রস, আমি উন্মুক্ত লেনদেনটি এই প্রশ্নের আপডেটে বৃদ্ধি বৃদ্ধি রোধ করছে ভেবে আমার যুক্তি সরবরাহ করেছি। আমি কি আমার যুক্তিতে ভুল?

— জিম্বো

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

— লুইস এলএল

Answer 5

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

Comments

দুর্ভাগ্যক্রমে প্রক্রিয়াটি যেভাবে সম্পাদিত হচ্ছে তাতে আমার কোনও নিয়ন্ত্রণ নেই। ডায়নামিক্স সিআরএম হ'ল একটি মাইক্রোসফ্ট অ্যাপ্লিকেশন এবং সংস্থা আমদানি প্রক্রিয়া সেই আবেদনের অংশ।

— জিম্বো

Answer 6

নিম্নলিখিতটি লগকে ছাঁটাই করবে।

USE [yourdbname] 
GO

-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO

-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN  RETURN 0 END
GO

Comments

আরে পিনাল, এই কার্যকারিতা সম্পূর্ণরূপে এসকিউএল সার্ভার 2008 থেকে এবং উপরোক্ত সরানো হয়েছে brentozar.com/archive/2009/08/...

— কোনোর

পরবর্তী সংস্করণগুলির সাথে, ব্যাকআপ লগ <myDB> টু ডিস্ক = এন'নুল: 'চেষ্টা করুন

— হ্যানস লিন্ডগ্রেন

Answer 7

যদি আপনার ডাটাবেস পুনরুদ্ধারের মডেলটি পূর্ণ থাকে এবং আপনার লগ ব্যাকআপ রক্ষণাবেক্ষণ পরিকল্পনা না থাকে তবে আপনি এই ত্রুটিটি পাবেন কারণ লেনদেন লগের কারণে পূর্ণ হয়ে যায় LOG_BACKUP।

এটি এই ডাটাবেসে কোনও ক্রিয়াকলাপ (যেমন সঙ্কুচিত করা) রোধ করবে এবং এসকিউএল সার্ভার ডেটাবেস ইঞ্জিন 9002 ত্রুটি বাড়িয়ে তুলবে।

এই আচরণটি কাটিয়ে উঠতে আমি আপনাকে এটি যাচাই করার পরামর্শ দিচ্ছি LOG_BACKUP এর কারণে ডাটাবেস 'শেয়ারপয়েন্ট_কনফিগ' এর জন্য লেনদেন লগটি পূর্ণ, যা সমস্যার সমাধানের জন্য বিশদ পদক্ষেপগুলি দেখায়।

Answer 8

আমি ত্রুটিটি পেয়েছি: "ডিস্কের স্থান খালি করার জন্য আমার ডাটাবেসের সারণি থেকে পুরানো সারিগুলি মুছে ফেলার সময় 'ACTIVE_TRANSACTION' এর কারণে 'ডাটাবেস' ... 'এর জন্য লেনদেন লগ পূর্ণ হয়েছে I আমি বুঝতে পেরেছি যে সারিগুলির সংখ্যা যদি এই ত্রুটিটি ঘটবে মুছে ফেলা হবে আমার ক্ষেত্রে 1000000 এর চেয়ে বড়।

উদাহরণ স্বরূপ:

পরিবর্তে এই বিবৃতি ব্যবহার:

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

বারবার নিম্নলিখিত বিবৃতি ব্যবহার:

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

Answer 9

আমার সমস্যা সীমিত মুছে ফেলার একাধিক সম্পাদনের সাথে সমাধান করা যেমন মতো

আগে

DELETE FROM TableName WHERE Condition

পরে

DELETE TOP(1000) FROM TableName WHERECondition

Answer 10

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

আপনার কাছে থাকা অন্য বিকল্পটি হ'ল মার্জ (আপলোড) দুটি ক্রিয়ায় বিভক্ত করা। একটি যা সন্নিবেশ করায় এবং অপরটি আপডেট করে এবং মোছা করে।

Comments

আপনি যদি প্রশ্নটি পড়ে থাকেন তবে আপনি জানতেন যে ডিবিটি ইতিমধ্যে সাধারণ পুনরুদ্ধার মোডে ছিল কারণ এটি হচ্ছে। আপনার যখন দীর্ঘ সময় ধরে উন্মুক্ত লেনদেন হয় তখন এটি সাহায্য করবে না। লেনদেন প্রতিশ্রুতিবদ্ধ বা ঘূর্ণিত না হওয়া পর্যন্ত ফাইলটি বাড়তে থাকে। প্রশ্নের প্রথম লাইনটি পড়ুন "আমার একটি দীর্ঘ চলমান প্রক্রিয়া রয়েছে যা পুরো সময়ের জন্য একটি লেনদেন উন্মুক্ত করে।"

— জিম্বো

Answer 11

এটা চেষ্টা কর:

USE YourDB;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 50 MB.  
DBCC SHRINKFILE (YourDB_log, 50);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE YourDB
SET RECOVERY FULL;  
GO 

আমি আসা করি এটা সাহায্য করবে.

Comments

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

— জিম্বো

Answer 12

এখানে আমার নায়ক কোড। আমি এই সমস্যার মুখোমুখি হয়েছি। এবং এটি ঠিক করতে এই কোডটি ব্যবহার করুন।

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

Comments

দয়া করে আপনার উত্তরটি কেবলমাত্র পেস্টিং কোডের পরিবর্তে প্রসঙ্গে দিন। দেখুন এখানে আরো বিস্তারিত জানার জন্য।

— gehbiszumeis

Answer 13

এটা চেষ্টা কর:

সম্ভব হলে এমএসএসকিউএসএলএসভার এবং এসকিউএলএসএভারভাইগেন্ট সেবা পুনরায় চালু করুন ।