লেনদেন না ব্যবহার এবং একটি অনুকরণ করার জন্য একটি workaround ব্যবহার করতে বলা


43

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

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

আমি সর্বদা আমার লেনদেনের ক্ষেত্রটি যথাসম্ভব সঙ্কীর্ণ রেখেছি, সর্বদা সেট এক্সএসিএএবিএবিআরটির সাথে এবং সর্বদা ট্রাই / ক্যাচের মধ্যে ব্যবহার করি।

উদাহরণ:

CREATE SCHEMA someschema;
GO


CREATE TABLE someschema.tableA
(id   INT NOT NULL IDENTITY(1, 1) PRIMARY KEY, 
 ColA VARCHAR(10) NOT NULL
);
GO

CREATE TABLE someschema.tableB
(id   INT NOT NULL IDENTITY(1, 1) PRIMARY KEY, 
 ColB VARCHAR(10) NOT NULL
); 
GO


CREATE PROCEDURE someschema.ProcedureName @ColA VARCHAR(10), 
                                          @ColB VARCHAR(10)
AS
SET NOCOUNT, XACT_ABORT ON;
BEGIN
BEGIN TRY
    BEGIN TRANSACTION;

    INSERT INTO someschema.tableA(ColA)
    VALUES(@ColA);

    INSERT INTO someschema.tableB(ColB)
    VALUES(@ColB);

--Implement error
    SELECT 1/0 

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@trancount > 0
    BEGIN
        ROLLBACK TRANSACTION;
    END;
    THROW;
    RETURN;
END CATCH;
END;
GO

তারা আমাকে পরামর্শ দেওয়ার পরামর্শ দিয়েছে।

GO



CREATE PROCEDURE someschema.ProcedureNameNoTransaction @ColA VARCHAR(10), 
                                                       @ColB VARCHAR(10)
AS
SET NOCOUNT ON;
BEGIN
BEGIN TRY
    DECLARE @tableAid INT;
    DECLARE @tableBid INT;

    INSERT INTO someschema.tableA(ColA)
    VALUES(@ColA);
    SET @tableAid = SCOPE_IDENTITY();

    INSERT INTO someschema.tableB(ColB)
    VALUES(@ColB);
    SET @tableBid = SCOPE_IDENTITY();

--Implement error
    SELECT 1/0 

END TRY
BEGIN CATCH
    DELETE FROM someschema.tableA
    WHERE id = @tableAid;

    DELETE FROM someschema.tableB
    WHERE id = @tableBid;

    THROW;

    RETURN;
END CATCH;
END;
GO

সম্প্রদায়ের কাছে আমার প্রশ্নটি নীচে রয়েছে। এটি কি লেনদেনের জন্য একটি কার্যক্ষম কর্ম হিসাবে বিবেচনা করে?

লেনদেন সম্পর্কে আমি যা জানি এবং সমাধানটি কী প্রস্তাব দিচ্ছে তার থেকে আমার মতামতটি হ'ল না, এটি একটি কার্যকর সমাধান নয় এবং ব্যর্থতার অনেকগুলি পয়েন্ট পরিচয় করিয়ে দেয়।

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

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

আমি মনে করি যে আর একটি সমস্যা টাইমআউট বা বিচ্ছিন্ন সংযোগের জন্য exists এটি এখনও ফিরে ঘূর্ণিত পেতে হবে? এটি কেন SEX XACT_ABORT অন ব্যবহার করা উচিত তা আমার বোঝার যাতে এই ক্ষেত্রে, লেনদেনটি পিছনে ফিরে আসবে।

আপনার মতামতের জন্য আগাম ধন্যবাদ!


4
যে মন্তব্যগুলি তাদের বর্ণিত উদ্দেশ্যটি পরিবেশন করে না সেগুলি মুছে ফেলা হয়েছে, বা সম্প্রদায়ের উইকির উত্তরে সরানো হয়েছে।
পল হোয়াইট

উত্তর:


61

তুমি পারবে না না SQL সার্ভার (এবং সম্ভবত অন্য কোন সঠিক RDBMS) লেনদেন ব্যবহার করুন। সুস্পষ্ট লেনদেনের সীমানা ( begin transaction... commit) এর অভাবে প্রতিটি এসকিউএল বিবৃতি একটি নতুন লেনদেন শুরু করে, যা বিবৃতি সম্পূর্ণ (বা ব্যর্থ) পরে সংক্ষিপ্ত প্রতিশ্রুতিবদ্ধ (বা রোলড ব্যাক) করা হয়।

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

  • পারমাণবিকতা: ব্যর্থ। যদি আপনার সিউডো-লেনদেনের মাঝামাঝি কোনও "শক্ত" ত্রুটি দেখা দেয় তবে পরিবর্তনটি অ-পারমাণবিক হবে।

  • ধারাবাহিকতা: ব্যর্থ। উপরের দিক থেকে এটি অনুসরণ করে যে আপনার "ডেটা" শক্ত "ত্রুটির পরে বেমানান অবস্থায় থাকবে।

  • বিচ্ছিন্নতা: ব্যর্থ। আপনার সিউডো-লেনদেনের মাধ্যমে আপনার সিউডো-লেনদেনের সংশোধিত কিছু ডেটা আপনার সম্পূর্ণ হওয়ার পূর্বে একসাথে ছদ্ম-লেনদেনের পরিবর্তন হতে পারে।

  • স্থায়িত্ব: সাফল্য। আপনার করা পরিবর্তনগুলি টেকসই হবে , ডাটাবেস সার্ভার তা নিশ্চিত করবে; এই একমাত্র জিনিস যা আপনার সহকর্মীর দৃষ্টিভঙ্গি স্ক্রু করতে পারে না।

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

উপসংহারে, আপনার "ডিবিএ" এর পরামর্শটি যদি আপনি পারেন তবে তা অগ্রাহ্য করুন, যদি আপনার আত্মা থাকে তবে এটির সাথে লড়াই করুন এবং যদি তারা উত্থাপিত হয় তবে নির্দিষ্ট সম্মতিযুক্ত সমস্যা নিয়ে এখানে ফিরে আসুন।


14

কিছু ত্রুটি রয়েছে যা এত মারাত্মক যে CATCH ব্লকটি কখনই প্রবেশ করে না। ডকুমেন্টেশন থেকে

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

মনোযোগ, যেমন ক্লায়েন্ট-বিঘ্নিত অনুরোধ বা ভাঙা ক্লায়েন্ট সংযোগ।

কেআইএলএল স্টেটমেন্টটি ব্যবহার করে যখন সিস্টেম প্রশাসক দ্বারা সেশনটি শেষ হয়।

...

সংশ্লেষ ত্রুটিগুলির মতো সংকলন ত্রুটিগুলি, যা কোনও ব্যাচকে চলমান থেকে বাধা দেয়।

স্থগিত নাম রেজোলিউশনের কারণে যে ত্রুটিগুলি ঘটে ...

এগুলির অনেকগুলি গতিশীল এসকিউএল এর মাধ্যমে উত্পাদন করা সহজ। আপনি যেমন দেখিয়েছেন এমন বিবৃতিগুলি পূর্বাবস্থায় ফেরানো আপনার ত্রুটি থেকে আপনার ডেটা রক্ষা করবে না।


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

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

10

আই-ওয়ান : আপনাকে যে প্রস্তাবিত পরামর্শটি দেওয়া হয়েছে এটি এসিডের "এ" লঙ্ঘন করা সম্ভব করে (কমপক্ষে)। উদাহরণস্বরূপ, যদি এসপি কোনও দূরবর্তী ক্লায়েন্ট এবং সংযোগ বিরতির দ্বারা কার্যকর করা হয় তবে আংশিক "কমিট" / "রোলব্যাক" ঘটতে পারে, কারণ সার্ভারদুটি সন্নিবেশ / মোছার মধ্যে সেশনটি শেষ করতেপারে (এবং এসপি এক্সিকিউশনটি এটি শেষ হওয়ার আগেই বাতিল করে দিতে পারে) ।

এটি কি লেনদেনের জন্য একটি কার্যক্ষম কর্ম হিসাবে বিবেচনা করে?

ড্যান-গুজম্যান : না,CATCHক্লায়েন্ট এপিআই ব্যাচ বাতিল করেছে বলে ক্লোকারের এপিআই ব্যাচ বাতিল করায় ব্লকটি কখনই ক্যোয়ারির সময়সীমার ক্ষেত্রে কার্যকর করা হয় না। কোনও লেনদেন ছাড়াইSET XACT_ABORT ONবর্তমান বিবৃতি ব্যতীত অন্য কিছু রোলব্যাক করতে পারবেন না।

tibor-karaszi : আপনার 4 টি লেনদেন হয়েছে যার অর্থ লেনদেন লগ ফাইলে আরও লগিং। মনে রাখবেন যে প্রতিটি লেনদেনের জন্য লগ রেকর্ডগুলির একটি সমকালীন লেখার প্রয়োজন হয় অর্থাৎ অনেকগুলি লেনদেন ব্যবহার করার সময় আপনি সেই দিক থেকে খারাপ সম্পাদনা পান।

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

এছাড়াও, তারা ম্যানুয়ালি যা প্রয়োগ করার চেষ্টা করছে তা হ'ল কার্যকরভাবে একটি দরিদ্র-ম্যান আশাবাদী সম্মতি। পরিবর্তে তাদের কী করা উচিত তা হ'ল ইতিমধ্যে এসকিউএল সার্ভারে নির্মিত বিশ্বের সেরা কয়েকটি আশাবাদী সমঝোতা ব্যবহার করা। এটি উপরের বিচ্ছিন্নতা বিন্দুতে যায়। সমস্ত সম্ভাবনা তারা তারা বর্তমানে আশাবাদী সম্পাতবিন্দু বিচ্ছিন্নতা মাত্রা এক, এর ব্যবহার করছেন যাই হোক না কেন হতাশাপূর্ণ সম্পাতবিন্দু বিচ্ছিন্নতা পর্যায় থেকে স্যুইচ করতে হবে SNAPSHOTবা READ_COMMITTED_SNAPSHOT। এগুলি কার্যকরভাবে তাদের ম্যানুয়াল কোড হিসাবে একই কাজ করবে, এটি এটিকে সঠিকভাবে করবে except

রস-প্রেসার : যদি আপনার অত্যন্ত দীর্ঘ চলমান প্রক্রিয়া থাকে - যেমন আজ কিছু ঘটে থাকে এবং পরের সপ্তাহে কিছু একটা ফলোআপ করতে হয় এবং যদি পরের সপ্তাহের জিনিসটি ব্যর্থ হয় তবে আজকের বিপরীতে ব্যর্থ হতে হবে - আপনি বৌদ্ধিকাগুলি সন্ধান করতে চাইতে পারেন । কড়া কথা বলতে এটি ডাটাবেসের বাইরে, কারণ এটিতে একটি সার্ভিস বাস প্রয়োজন।


5

খারাপ ধারণা কোডটি কেবল লাইনটি ঠিক করতে আরও ব্যয়বহুল হতে চলেছে।

সুস্পষ্ট লেনদেন (রোলব্যাক / প্রতিশ্রুতি) ব্যবহার করে যদি কোনও অবরুদ্ধ সমস্যা থাকে তবে সমস্যাগুলি সমাধানের জন্য কিছু দুর্দান্ত ধারণার জন্য আপনার ডিবিএকে ইন্টারনেটে নির্দেশ করুন।

ব্লকিং উপশম করার জন্য এখানে একটি উপায়: https://www.sqlservercentral.com/articles/using-indexes-to-reduce-blocking-in-concurrent- Transferences

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

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


4

জাল লেনদেন কৌশলটি বিপজ্জনক কারণ এটি সম্মতিযুক্ত ইস্যুগুলিকে মঞ্জুরি দেয় যা লেনদেনগুলি বিশেষত প্রতিরোধ করে। বিবেচনা করুন যে দ্বিতীয় উদাহরণে বিবৃতিগুলির মধ্যে যে কোনও ডেটা পরিবর্তন করা যেতে পারে।

জাল লেনদেন মুছে ফেলা চালাতে বা সফল হতে গ্যারান্টিযুক্ত হয় না। জাল লেনদেনের সময় যদি ডাটাবেস সার্ভারটি বন্ধ হয়ে যায় তবে কিছু তবে সমস্ত প্রভাব থেকে যায় না। লেনদেনের রোলব্যাক যেভাবে বলা যায় তাতে তাদের সাফল্যের গ্যারান্টিও দেওয়া হয় না।

এই কৌশলটি সন্নিবেশকারীদের সাথে কাজ করতে পারে তবে আপডেট বা মুছে ফেলা (কোনও টাইম-মেশিন এসকিউএল বিবৃতি নেই) নিয়ে কাজ করবে না।

যদি কঠোর লেনদেনের সম্মতিতে বাধা সৃষ্টি হয় তবে প্রচুর সমাধান রয়েছে, এমনকি সুরক্ষা স্তর হ্রাস করাও ... এগুলি সমস্যা সমাধানের সঠিক উপায়।

আপনার ডিবিএ এমন একটি প্রস্তাব দিচ্ছে যা ডাটাবেসের কেবলমাত্র একজন ব্যবহারকারী থাকাকালীন ঠিক কাজ করতে পারে তবে যে কোনও ধরণের গুরুতর ব্যবহারের জন্য একেবারেই অযোগ্য।


4

এটি কোনও প্রোগ্রামিং ইস্যু নয়, বরং এটি একটি আন্তঃব্যক্তিক / ভুল যোগাযোগের সমস্যা। সম্ভবত আপনার "ডিবিএ" লেনদেনের বিষয়ে নয়, লক নিয়ে চিন্তিত।

অন্যান্য উত্তরগুলি ইতিমধ্যে ব্যাখ্যা করেছে যে আপনাকে কেন লেনদেন ব্যবহার করতে হবে ... আমার অর্থ এটিই আরডিবিএমএস যা করে, সঠিকভাবে ব্যবহৃত লেনদেন ছাড়াই কোনও ডেটা অখণ্ডতা থাকে না, তাই আমি কীভাবে আসল সমস্যাটি সমাধান করবেন সে বিষয়ে ফোকাস করব, যা: কেন তা খুঁজে বার করুন আপনার "ডিবিএ" লেনদেনের ক্ষেত্রে অ্যালার্জি তৈরি করেছে এবং তাকে তার মতামত পরিবর্তন করতে রাজি করলেন।

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

এর মতো একটি পরিস্থিতি বিবেচনা করুন:

BEGIN
UPDATE or DELETE some row, which takes locks it
...do something that takes a while
...perform other queries
COMMIT

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

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

তিনি আপনাকে যা বলছেন তা হ'ল "স্ক্রু ড্রাইভারটিকে স্পর্শ করবেন না!" সুতরাং আপনি আপনার প্রশ্নে পোস্ট করা কোডটি মূলত স্ক্রু চালানোর জন্য হাতুড়ি ব্যবহার করছে। আরও ভাল বিকল্প হ'ল তাকে বোঝানো আপনি কীভাবে কোনও স্ক্রু ড্রাইভার ব্যবহার করবেন তা জানেন ...

আমি বেশ কয়েকটি উদাহরণ বিবেচনা করতে পারি ... ভাল, তারা মাইএসকিউএল এ ছিল তবে এটিও কার্যকর হওয়া উচিত।

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

যেহেতু এটি খুব সামান্য র‌্যাম নিয়ে একটি রাস্টবকেটে চলেছে, আপডেটটি জানিয়েছে যে ফুলটেক্সট সূচকটি প্রায়শই কয়েক সেকেন্ডের তীব্র এলোমেলো আইও বক্সের একক স্লো স্পিনিং ড্রাইভে পরিণত হয়।

সমস্যাটি হ'ল যে ব্যক্তিরা এই বিষয়টিতে ক্লিক করেছেন তারা বিষয়টিতে দর্শন সংখ্যা বাড়িয়ে দেওয়ার জন্য একটি ক্যোয়ারী তৈরি করেছেন, যার জন্য বিষয় সারিটিতে একটি লকও প্রয়োজন। সুতরাং, এর ফুলটেক্সট সূচক আপডেট হওয়ার সময় কেউই বিষয়টি দেখতে পেল না। মানে, সারিটি পড়া যেতে পারে তবে এটি আপডেট করা লক হয়ে যায়।

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

সমাধানটি সঠিকভাবে ক্রমে নিয়ে যাওয়া ছিল: শুরু করুন, কোনও তালা না নিয়ে পোস্টটি সন্নিবেশ করুন এবং ফুলটেক্সট সূচকটি আপডেট করুন, তারপরে পোস্টের গণনা এবং শেষ পোস্টের তারিখ, এবং কমিটের মাধ্যমে বিষয় / ফোরামের সারিগুলি দ্রুত আপডেট করুন। এটি সমস্যার সম্পূর্ণ সমাধান করেছে। এটি কেবল কয়েকটি ক্যোয়ারির চারপাশে ঘোরাঘুরি করছিল, সত্যিই সহজ।

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

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

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


3

টিএলডিআর: সঠিক বিচ্ছিন্নতা স্তর ব্যবহার করুন ।

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

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

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


2

আপনি ইন-মেমোরি ওয়ালটিপি টেবিলগুলি ব্যবহার করার সিদ্ধান্ত নিতে পারেন। তারা অবশ্যই লেনদেনগুলি ব্যবহার করে তবে এতে কোনও ব্লক জড়িত নেই।
পরিবর্তে সমস্ত ক্রিয়াকলাপ সফল হবে, তবে প্রতিশ্রুতির সময় ইঞ্জিন লেনদেনের দ্বন্দ্বগুলি পরীক্ষা করবে এবং কমিটগুলির মধ্যে একটি ব্যর্থ হতে পারে। মাইক্রোসফ্ট "আশাবাদী লকিং" শব্দটি ব্যবহার করে।
যদি স্কেলিংয়ের সমস্যাটি দুটি রাইট ক্রিয়াকলাপের মধ্যে দ্বন্দ্বের কারণে হয়ে থাকে, যেমন একই সারির দুটি আপডেট করার চেষ্টা করে দুটি সমবর্তী লেনদেন, ইন-মেমরি ওলটিপি একটি লেনদেনকে সফল হতে দেয় এবং অন্য লেনদেনকে ব্যর্থ করে। ব্যর্থ লেনদেনটি স্পষ্টভাবে বা স্পষ্টভাবে পুনরায় জমা দিতে হবে, লেনদেনটির পুনরায় চেষ্টা করে trying
আরও এখানে: মেমরি ওলটিপিতে


-5

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

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