সেট ট্রানসেকশন আইসোলেশন লেভেলের সুবিধাগুলি পড়াশোনা করুন CO

Question

আমি SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDআমার সাধারণ এসকিউএল প্রশ্নের বেশিরভাগ ক্ষেত্রেই ব্যবহার করি , মূলত কারণ এটি যখন আমার কাছে প্রাথমিকভাবে ভাষা শেখার সময়।

আমার বোঝার থেকে, এই বিচ্ছিন্নতা স্তর একই ভাবে কাজ করে WITH (NO LOCK)তবে আমি শুধু কি কখনো ব্যবহারের প্রবণতা SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED।

• সেখানে কি কখনো এমন একটি সময় আমি ব্যবহার হওয়া উচিত WITH (NO LOCK)উপর SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED।
• কি SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDটেবিল যে আমি পড়া করছি লক আউট থেকে স্টপ অন্যান্য ব্যবহারকারীদের?
• যদি SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDলক বন্ধ করতে ব্যবহৃত হয় তবে আমি কেবল ডেটা পড়ছি, এটি ব্যবহারে কী লাভ? এটি কি কেবলমাত্র সিস্টেম নিবিড় অনুসন্ধানগুলি যা লকগুলি তৈরি করতে পারে? 5-10 সেকেন্ডের মধ্যে ফিরে আসা জিজ্ঞাসাগুলি যখন চলছে তখন কি এটি ব্যবহার করা উপযুক্ত?
• SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDনোংরা তথ্য আপডেট করা এড়াতে সম্ভবত আপডেটে ব্যবহৃত হবে এমন ডেটা পড়ার সময় আমাকে ব্যবহার না করার কথা বলা হয়েছে । এটা কি একমাত্র কারণ হবে?
• যে ধরণের ডাটাবেসটিতে আমি কাজ করছি তার সাথে একটি উত্পাদন এবং পরীক্ষার পরিবেশ রয়েছে। আমরা খুব কমই উত্পাদনের পরিবেশ সম্পর্কে জিজ্ঞাসা করব তবে আমার যখন প্রয়োজন হবে তখন আমি সাধারণত SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDআমার অনুসন্ধানে ব্যবহার করব। আমি বুঝতে পারি যে নোংরা পাঠা এটি দিয়েই সম্ভব। ডেটা ফিরে পাওয়া ছাড়াও যা ডাটাবেসে প্রতিশ্রুতিবদ্ধ না হয়ে শেষ হতে পারে (এবং তাই আমার ফলাফলগুলি ছুঁড়ে ফেলা) কী কী অন্যান্য ধরণের 'নোংরা পাঠ' সম্ভব হতে পারে?

ভর প্রশ্নের জন্য দুঃখিত।

Comments

আপনি একই তথ্য দু'বার পড়তে পারেন হ'ল আরেকটি পিট ফলস। আরইউ বা কোন লককে স্ট্যান্ডার্ড হিসাবে ব্যবহার করা একটি খারাপ ধারণা।

— জেমস অ্যান্ডারসন

আমি ব্যবহার করেন না READ UNCOMMITTEDসর্বত্রই আছে, সঠিক একই উপায় হিসেবে আমি ব্যবহার না করবে WITH (NOLOCK)সর্বত্র (তারা মূলত একই জিনিস) blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere

— মার্ক Sinkinson

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

— usr ডিরেক্টরির

Answer 1

এটি ভয়ানক, আপনি এটি সেভাবে শিখেছিলেন (দুঃখিত!)।

READ UNCOMMITTEDআসুন আপনি প্রতি সারিতে পড়ুন, হ্যাঁ। এমনকি যারা বর্তমানে একটি ব্যবহার করা হয় INSERT, UPDATE, DELETEঅপারেশন। এটি খুব কার্যকর যদি আপনার কিছু ডেটা বা মিশন সমালোচনামূলক- SELECTঅবস্থানগুলিতে একটি তাত্ক্ষণিক নজর নেওয়া দরকার যেখানে ব্লকটি খুব ক্ষতিকারক হবে।

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

আমি ভুলে যাওয়ার পরামর্শ দিই READ UNCOMMITTED। শুধু এটি ব্যবহার যেখানে এটি হচ্ছে সত্যিই প্রয়োজন ছিল।

আপনার জন্য অন্য বিকল্পটি হ'ল READ_COMMITTED_SNAPSHOTডাটাবেস বিকল্পটি সক্ষম করা - READ COMMITTED SNAPSHOTযার জন্য আপনি নিজের টেম্পডিবায় সক্রিয় সারি সংস্করণের কারণে ব্যবহার করতে পারেন । এইভাবে আপনি কেবল একটি সারির আর একটি (পুরানো) সংস্করণ পড়বেন। এটি আপনার প্রশ্নগুলি ব্লক করবে না block তবে এটি হতে পারে যে আপনি খুব পুরানো মানটি পড়েন তবে একটি সামঞ্জস্যপূর্ণ পুরানো মান।

WITH(READPAST)পরিবর্তে অন্য ধারণা হতে পারে WITH(NOLOCK)। আপনি টেবিলের পুরানো রাজ্যটি পড়বেন (এর মতো কিছুটা SNAPSHOT ISOLATION) তবে আপনি বর্তমানে সমস্ত লক করা সারিগুলি বাদ দিবেন ।

Comments

@ আইনিক, প্রতিক্রিয়াটির জন্য আপনাকে অনেক ধন্যবাদ! আমি সত্যিই যে সাহায্য প্রশংসা করি।

— dmoney

@ হাইঞ্জসাইট, এটির মতো শোনাচ্ছে তবে খুব ভাল সম্ভাবনা রয়েছে যে এটি আমার বক্তব্যটির ব্যাখ্যা, আপনার ইনপুটটির জন্য উভয় উপায়েই ধন্যবাদ।

— dmoney

SNAPSHOT ISOLATIONচালু করার জন্য সক্ষম করার দরকার নেই READ COMMITTED SNAPSHOT। কেবলমাত্র READ COMMITTED SNAPSHOTডাটাবেস বিকল্পটি সক্ষম করা দরকার যাতে পাঠের ধারাবাহিকতার জন্য লক করার পরিবর্তে সারি সংস্করণটি নোংরা পাঠের প্রয়োজনীয়তা এড়ানো উচিত।

— ড্যান গুজম্যান

হ্যাঁ আমি বলতে চাইছিলাম @ ডানগুজম্যান। দুঃখিত, উত্তরটি কিছুটা অস্পষ্ট ছিল। আমি এটি সম্পাদনা করেছি। :-)

— অয়নিক

READPAST এর সাহায্যে আপনি লক হওয়া রেকর্ডগুলি এড়িয়ে যাবেন, আপনি পুরানো মানগুলি পাবেন না - তাই আমি এটি ব্যবহার করতে পারি এটির একমাত্র জায়গাটি হ'ল ক্যু হ্যান্ডলিং

— জেমস জেড

Answer 2

গৃহীত উত্তরের হিসাবে বলা হয়েছে, ভুল ডেটা পড়ার ঝুঁকি হওয়ায় পুনঃবিজ্ঞাত বিচ্ছিন্নতা স্তরটি পড়তে ভুলবেন না (সত্যই যখন প্রয়োজন তখন বাদে)। তবে আপনার প্রশ্নের তৃতীয় বুলেট পয়েন্টের উত্তর দেওয়ার জন্য দুটি পরিস্থিতি আমার পক্ষে দরকারী বলে মনে হচ্ছে:

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

2. এসকিউএল সার্ভার ম্যানেজার স্টুডিওতে আপনি টি-এসকিউএল কোডটি লেনদেনের মধ্যে গুটিয়ে রেখে পরিবর্তনগুলি রোল করার বিকল্প দিতে পারেন test উদাহরণস্বরূপ একটি পরীক্ষামূলক ডাটাবেসে আপনি আপনার পরীক্ষার অংশ হিসাবে প্রাথমিক অবস্থায় ডেটা পুনরুদ্ধার করতে চাইতে পারেন। আপনি যদি লেনদেন-মোড়ানো কোড পরীক্ষা করে থাকেন এবং লেনদেন চলাকালীন আপনি লক করা টেবিলগুলি পরীক্ষা করতে চান, আপনি অন্য উইন্ডোতে মানগুলি পরীক্ষা করার জন্য SET Trans Transration IOLATION READ UNCOMMITTED ব্যবহার করতে পারেন।

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

Answer 3

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

অবশ্যই, READ UNCOMMITTED(ডার্টি রিডস) এই ক্ষেত্রে ভুল তথ্য সরবরাহ করতে পারে, তবে সেই তথ্যটি 5 সেকেন্ড আগে সঠিক ছিল।

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

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

পরিবর্তে, নোংরা পাঠগুলি সিস্টেমটিকে দ্রুত এবং আরও নির্ভরযোগ্য করে তোলে (কিছুটা উন্নত পারফরম্যান্সের কারণে অসঙ্গতিগুলি হওয়ার সম্ভাবনা কম থাকে)।

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

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