অচলাবস্থার মূল কারণগুলি কী এবং সেগুলি প্রতিরোধ করা যেতে পারে?


55

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

এই ত্রুটিটি আমি প্রথমবার দেখেছি এবং কার্যকরভাবে কীভাবে এটি ট্র্যাক এবং ঠিক করা যায় তা জানতাম না। আমি জানি এমন সমস্ত সম্ভাব্য উপায়ে চেষ্টা করেছি এবং শেষ পর্যন্ত খুঁজে পেয়েছি যে টেবিলটি আপডেট করা হচ্ছে তাতে প্রাথমিক কী নেই! ভাগ্যক্রমে এটি একটি পরিচয় কলাম ছিল।

পরে আমি সেই বিকাশকারীকে পেয়েছি যারা ডিপোরিয়ডের জন্য মেসেজেড-আপের ডেটাবেস স্ক্রিপ্ট করে। আমি একটি প্রাথমিক কী যুক্ত করেছি এবং সমস্যাটি সমাধান করা হয়েছে।

আমি আনন্দিত বোধ করলাম এবং আমার প্রকল্পে ফিরে এসেছি এবং সেই অচলাবস্থার কারণ অনুসন্ধান করার জন্য কিছু গবেষণা করেছি ...

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

আমি জানি এটি একটি সুস্পষ্ট সংজ্ঞা নয়, সে কারণেই আমি এখানে পোস্ট করছি ...

  • অনুপস্থিত প্রাথমিক কীটি কি সমস্যা?
  • (পারস্পরিক বর্জন, হোল্ড অ্যান্ড ওয়েট, প্রিপিমেশন এবং সার্কুলার ওয়েট) ব্যতীত অন্য কোন শর্ত রয়েছে কি না?
  • আমি কীভাবে ডেডলকগুলি রোধ এবং ট্র্যাক করব?

2
বিজ্ঞপ্তি অপেক্ষা (মূলত ট্রিগারগুলির অতিমাত্রায় ব্যবহারের কারণে) আমি যে অচলাবস্থা দেখেছি তার মধ্যে আইএমই সংখ্যাগরিষ্ঠ (সমস্ত?) রয়েছে।
সত্যজিৎ ভাট

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

উত্তর:


38

দু'জনের মধ্যে ডেডলকগুলি ট্র্যাক করা সহজ:

ডিফল্টরূপে, ত্রুটি লগতে ডেডলকগুলি লেখা হয় না। আপনি এসকিউএলকে ট্রেস ফ্ল্যাগ 1204 এবং 3605 এর মাধ্যমে ত্রুটি লগটিতে ডেডলকগুলি লিখতে বাধ্য করতে পারেন।

এসকিউএল সার্ভার ত্রুটি লগতে অচলাবস্থার তথ্য লিখুন: ডিবিসিসি ট্র্যাকিয়ন (-1, 1204, 3605)

এটি বন্ধ করুন: ডিবিসিসি ট্র্যাসিওএফএফ (-1, 1204, 3605)

1204 ট্রেস ফ্ল্যাগের আলোচনার জন্য "ট্রাবলশুটিং ডেডলকস" দেখুন এবং এটি চালু হওয়ার পরে আপনি কী আউটপুট পাবেন। https://msdn.microsoft.com/en-us/library/ms178104.aspx

প্রতিরোধ করা আরও কঠিন, মূলত আপনাকে নিম্নলিখিতগুলি সন্ধান করতে হবে:

কোড ব্লক 1 সেই ক্রমে রিসোর্স এ, তারপরে রিসোর্স বি লক করে।

কোড ব্লক 2 সেই ক্রমে রিসোর্স বি লক করে, তারপরে রিসোর্স এ।

এটি ক্লাসিক শর্ত যেখানে কোনও অচলাবস্থা দেখা দিতে পারে, যদি উভয় সংস্থার লকিং পারমাণবিক না হয়, কোড ব্লক 1 এটিকে লক করতে পারে এবং প্রাক-খালি করা যেতে পারে, তবে কোড ব্লক 2 টি লক বিটিকে প্রসেসিংয়ের সময় পাওয়ার আগেই B টি লক করতে পারে। এখন আপনার অচলাবস্থা আছে।

এই অবস্থাটি রোধ করতে আপনি নীচের মতো কিছু করতে পারেন

কোড ব্লক এ (স্যুইডো কোড)

Lock Shared Resource Z
    Lock Resource A
    Lock Resource B
Unlock Shared Resource Z
...

কোড ব্লক বি (সিউডো কোড)

Lock Shared Resource Z
    Lock Resource B
    Lock Resource A
Unlock Shared Resource Z
...

A এবং B এর সাথে করা হয়ে গেলে আনলক করতে ভুলে যাবেন না

এটি কোড ব্লক এ এবং কোড ব্লক বি এর মধ্যে অচলাবস্থা রোধ করবে

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


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

23

আমার প্রিয় পড়া এবং ডেডলক বিষয়ে জানার জন্য নিবন্ধ আছেন: সরল টক - ডেডলক খুঁজিয়া বাহির এবং SQL সার্ভার মধ্য - ডেডলক সমাধান করতে প্রোফাইলার ব্যবহার । কোনও পরিস্থিতির স্তন্যপান কীভাবে পরিচালনা করতে হয় সে সম্পর্কে তারা আপনাকে নমুনা এবং পরামর্শ দেবে।

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

তবে নিবন্ধগুলি আরও ভালভাবে পড়ুন, সেগুলি পরামর্শের দিক থেকে ভাল।


16

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

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

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

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

...

তাদের ট্র্যাক করার ক্ষেত্রে এটি নির্ভর করে আপনি যে ডাটাবেস সফটওয়্যারটি ব্যবহার করছেন তার উপর।


ডাউনভোট করার সময় মন্তব্য প্রদান করা সাধারণ সৌজন্যে ... এটি একটি বৈধ উত্তর, একটি নির্বাচনী বিবৃতি একটি টেবিল লকে উন্নীত করা এবং চিরতরে নেওয়া নিশ্চিতভাবে কোনও অচলাবস্থার কারণ হতে পারে।
ব্ল্যাকইস

1
এমএস এসকিউএল সার্ভার সূচকগুলি ক্লাস্টার না করা হলে অপ্রত্যাশিত লকিং আচরণও দিতে পারে। এটি সারি স্তরের লকিং ব্যবহার করার জন্য আপনার দিকটিকে নিঃশব্দে উপেক্ষা করবে এবং পৃষ্ঠা স্তর লকিং করবে। তারপরে আপনি পৃষ্ঠায় অপেক্ষারত ডেডলকগুলি পেতে পারেন।
জয়

7

শুধু কার্সার জিনিস বিকাশ। এটা আসলেই খারাপ। এটি পুরো টেবিলটি লক করে তারপরে একের পর এক সারিগুলি প্রক্রিয়া করে।

কিছুক্ষণ লুপ ব্যবহার করে কার্সারের ফ্যাশনে সারিগুলির মধ্য দিয়ে যাওয়া ভাল

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

প্লাস এটি দ্রুত। যাইহোক কেন সেখানে কার্সার রয়েছে তা আপনাকে অবাক করে তোলে।

এই ধরণের কাঠামোর উদাহরণ এখানে:

DECLARE @LastID INT = (SELECT MAX(ID) FROM Tbl)
DECLARE @ID     INT = (SELECT MIN(ID) FROM Tbl)
WHILE @ID <= @LastID
    BEGIN
    IF EXISTS (SELECT * FROM Tbl WHERE ID = @ID)
        BEGIN
        -- Do something to this row of the table
        END

    SET @ID += 1  -- Don't forget this part!
    END

যদি আপনার আইডি ক্ষেত্রটি অপ্রয়োজনীয় হয়, আপনি আইডির একটি পৃথক তালিকা টানতে পারেন এবং এর মাধ্যমে পুনরাবৃত্তি করতে পারেন:

DECLARE @IDs TABLE
    (
    Seq INT NOT NULL IDENTITY PRIMARY KEY,
    ID  INT NOT NULL
    )
INSERT INTO @IDs (ID)
    SELECT ID
    FROM Tbl
    WHERE 1=1  -- Criteria here

DECLARE @Rec     INT = 1
DECLARE @NumRecs INT = (SELECT MAX(Seq) FROM @IDs)
DECLARE @ID      INT
WHILE @Rec <= @NumRecs
    BEGIN
    SET @ID = (SELECT ID FROM @IDs WHERE Seq = @Seq)

    -- Do something to this row of the table

    SET @Seq += 1  -- Don't forget this part!
    END

6

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

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

আমার প্রিয় লক প্রতিরোধের কৌশলটি 'স্ন্যাপশট' বৈশিষ্ট্যগুলি ব্যবহার করছে। পড়ার জন্য প্রতিশ্রুতিবদ্ধ স্ন্যাপশট বৈশিষ্ট্যটির অর্থ হ'ল পাঠগুলি লকগুলি ব্যবহার করে না! এবং আপনার যদি 'পড়ুন প্রতিশ্রুতিবদ্ধ' এর চেয়ে আরও নিয়ন্ত্রণের প্রয়োজন হয় তবে সেখানে 'স্ন্যাপ শট বিচ্ছিন্নতা স্তর' বৈশিষ্ট্য রয়েছে। অন্যটি খেলোয়াড়কে অবরুদ্ধ না করে এইটিকে সিরিয়ালযুক্ত (এখানে এমএস পদ ব্যবহার করে) লেনদেনের অনুমতি দেয়।

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


-2

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

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