সর্বদা লেনদেন করা কি খারাপ অভ্যাস?

88

উদাহরণস্বরূপ, একটি সহজ ছাড়া আর কিছুই লেনদেন করা ভাল অনুশীলন SELECT?

সত্যিকার অর্থে প্রয়োজনীয় না হলে কোনও লেনদেন তৈরিতে কী খরচ হয়?

এমনকি আপনি যদি বিচ্ছিন্নতা স্তরটি ব্যবহার করেন READ UNCOMMITTEDতবে এটি কী খারাপ অভ্যাস?

sql-server best-practices transaction

— elranu
সূত্র

1

প্রভাব এ খুঁজছি BEGIN TRAN SELECT ... COMMITশুধু বনাম SELECTসেখানে প্রদর্শিত হবে একটি হতে অত্যন্ত গৌণ কর্মক্ষমতা পার্থক্য।

— মার্টিন স্মিথ

100

সর্বদা লেনদেন তৈরি করা কি খারাপ অভ্যাস?

আপনি এখানে কোন প্রসঙ্গে কথা বলছেন তা নির্ভর করে। যদি এটি আপডেট হয় তবে আমি স্পষ্টভাবে ট্রান্সঅ্যাকশনগুলি ব্যবহার করার পরামর্শ দেব। এটি যদি একটি নির্বাচন করে থাকে তবে NO (স্পষ্টতই)।

তবে অপেক্ষা করুন প্রথমে বোঝার জন্য আরও কিছু রয়েছে: স্কুয়েল সার্ভারে থাকা সমস্ত কিছুই লেনদেনের মধ্যে রয়েছে।

যখন সেশন বিকল্পটি IMPLICIT_TRANSACTIONSথাকে OFFএবং আপনি স্পষ্টভাবে নির্দিষ্ট করে থাকেন begin tranএবং commit/rollbackতারপরে এটি সাধারণত স্পষ্ট লেনদেন হিসাবে পরিচিত । অন্যথায় আপনি একটি স্বতঃসিদ্ধ লেনদেন পাবেন।

যখন IMPLICIT_TRANSACTIONSহয় ONএকটি অন্তর্নিহিত লেনদেনের যখন বিবৃতি ধরনের বই অনলাইন নিবন্ধ (যেমন নথিভুক্ত এক নির্বাহ স্বয়ংক্রিয়ভাবে শুরু হয় SELECT/ UPDATE/ CREATE) এবং করেছেন বা স্পষ্টভাবে ফিরে ঘূর্ণিত করা আবশ্যক। BEGIN TRANএই মোডে একটি কার্যকর করার ফলে বৃদ্ধি হবে @@TRANCOUNTএবং অন্য "নেস্টেড" লেনদেন শুরু হবে)

আপনি কোন মোডে আছেন তা স্যুইচ করতে, আপনি ব্যবহার করবেন

SET IMPLICIT_TRANSACTIONS ON

অথবা

SET IMPLICIT_TRANSACTIONS OFF

select @@OPTIONS & 2

যদি উপরে 2 প্রদান করে, আপনি অন্তর্ভুক্ত লেনদেনের মোডে আছেন। যদি এটি 0 ফেরত দেয় তবে আপনি স্বতঃসংশ্লিষ্ট in

যখন সত্যই প্রয়োজন হয় না তখন কোনও লেনদেন তৈরি করতে কত খরচ হয়?

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

এমনকি যদি আপনি একটি বিচ্ছিন্ন স্তরের পঠন_বিহীন ব্যবহার করেন। খারাপ অভ্যাস কি? কারণ এটি লক করার ক্ষেত্রে সমস্যা হওয়া উচিত নয়।

READ_UNCOMMITED বিচ্ছিন্নতা স্তর সংজ্ঞা অনুসারে নোংরা পাঠের অনুমতি দেবে অর্থাত্ একটি লেনদেন অন্যান্য লেনদেনের দ্বারা সংঘবদ্ধ পরিবর্তনগুলি দেখতে সক্ষম হবে। এই বিচ্ছিন্নতা স্তরটি যা করে তা হ'ল এটি লকিংয়ের ওভার হেডকে শিথিল করে - ডাটাবেস সম্মতি রক্ষার জন্য লকগুলি অর্জনের পদ্ধতি।

আপনি এটি কোনও সংযোগ / ক্যোয়ারী স্তরে ব্যবহার করতে পারেন, যাতে এটি অন্যান্য প্রশ্নের উপর প্রভাব ফেলে না।

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

জেফ অ্যাটউডের একটি আকর্ষণীয় নিবন্ধ পেয়েছেন ডাইনিংসকে ডাইনিংসকে ডাইনিং ফিলোসফার্স ধাঁধা কারণে এবং পড়ার জন্য প্রতিশ্রুতিবদ্ধ স্ন্যাপশট বিচ্ছিন্নতা স্তরের বর্ণনা দিয়েছিলেন ।

সম্পাদনা করুন:

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

এখানে চিত্র বর্ণনা লিখুন

কোডের উদাহরণ :

create table testTran (id int, Name varchar(8))
go

-- 19 sec
-- Autocommit transaction
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
---------------------------------------------------
-- 2 sec
-- Implicit transaction
SET IMPLICIT_TRANSACTIONS ON
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
COMMIT;
SET IMPLICIT_TRANSACTIONS OFF


----------------------------------------------------
-- 2 sec
-- Explicit transaction
declare @i int
set @i = 0
BEGIN TRAN
WHILE @i < 100000
Begin
INSERT INTO testTran values (1,'Kin Shah')
set @i = @i+1
End
COMMIT TRAN

স্বতঃসিদ্ধ লেনদেন : (@ ট্র্যাভিসগ্যান দ্বারা হাইলাইট হিসাবে সম্পাদিত)

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

ছদ্মবেশ এবং সুস্পষ্ট লেনদেন:

সন্নিবেশ 2 সেকেন্ড সময় নিয়েছে।
এক্সপ্লিক্ট লেনদেনের জন্য, লগ বাফারগুলি কেবল তখন পূর্ণ হবে fl
স্বতঃপদে লেনদেনের বিপরীতে, এক্সপ্লিক্ট লেনদেনের ক্ষেত্রে, চেকপয়েন্ট প্রক্রিয়ায় বেশি সময় লাগবে কারণ এতে আরও বেশি লগ বাফার থাকবে (মনে রাখবেন যে লগ বাফারগুলি পূর্ণ হলে কেবল সেগুলি ফ্লাশ করা হবে)।

একটি ডিএমভি sys.dm_tran_datedia_transferences আছে যা ডাটাবেস স্তরে লেনদেনের তথ্য ফিরিয়ে দেবে।

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

উপরোক্ত পরীক্ষাগুলি থেকে, স্পষ্ট এবং সুস্পষ্ট লেনদেনের মধ্যে কোনও পার্থক্য নেই।

উত্তরে আরও যোগ করতে সহায়তার জন্য @ ট্র্যাভিসগানকে ধন্যবাদ।

— কিন শাহ
সূত্র

35

একটি এসকিউএল স্টেটমেন্ট সর্বদা লেনদেনের মধ্যে চলে। আপনি যদি স্পষ্টভাবে একটি শুরু না করেন, তবে প্রতিটি এসকিউএল বিবৃতি নিজেই একটি লেনদেনে চলবে।

একমাত্র পছন্দ হ'ল আপনি কোনও লেনদেনে একাধিক বিবৃতি বান্ডিল করবেন কিনা। একাধিক বিবৃতি বিস্তৃত লেনদেনগুলি একযোগে আঘাত করে এমন লকগুলি ফেলে। সুতরাং "সর্বদা" লেনদেন তৈরি করা ভাল ধারণা নয়। আপনার সুবিধার বিপরীতে ব্যয়ের ভারসাম্য রক্ষা করা উচিত।

— Andomar
সূত্র

1

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

— রশ্মি
সূত্র