আমি কেবল ভাবছি যদি আপনি কোনও ডিবিতে লেনদেন শুরু করেন এবং এটি প্রতিশ্রুতিবদ্ধ বা রোলব্যাক করতে ভুলে গেছেন তবে কি হবে। সার্ভার ডাউন হবে? বলুন আপনি এটি 3 দিনের জন্য রেখেছেন।
এমন ব্যবহারকারীরাও এটি ব্যবহার করছেন এটি ধরে নিয়ে যে এটি ব্যবহার করা হচ্ছে যে অন্য ব্যবহারকারীরা জানেন না যে কোনও অনাবৃত লেনদেন রয়েছে (আসুন আমরা ধরে নিই যে ব্যবহারকারীরা কেবল ডাটাবেসে ডেটা inোকাচ্ছেন)) এই কর্মের পরিণতিগুলি কী কী?
উত্তর:
নিজে খোলামেলা লেনদেন করার কোনও ফল হবে না। আমার স্নাতকের
BEGIN TRANSACTION
-- wait for a while, doing nothing
-- wait a bit longer
COMMIT
সবচেয়ে খারাপভাবে, স্থিতির মানগুলির কয়েকটি বাইট ধরে রাখবে। কোন ব্যাপারই না.
বেশিরভাগ প্রোগ্রামগুলি লেনদেনের মধ্যেই আসল কাজ করবে এবং এটি অন্য একটি বিষয়। লেনদেনের মূল বিষয়টি তাই আপনি নিশ্চিত হতে পারেন যে একই ডাটাবেসে একইসাথে অন্যান্য ব্যবহারকারী লেখার পরেও ডাটাবেসের মধ্যে বেশ কয়েকটি তথ্য একই সাথে সত্য।
ব্যাংক অ্যাকাউন্টগুলির মধ্যে অর্থ স্থানান্তর করার ক্যানোনিকাল উদাহরণটি ধরুন। সিস্টেমকে অবশ্যই নিশ্চিত করতে হবে যে উত্স অ্যাকাউন্টটি বিদ্যমান আছে, পর্যাপ্ত তহবিল রয়েছে, গন্তব্য অ্যাকাউন্ট উপস্থিত রয়েছে এবং ডেবিট এবং ক্রেডিট উভয়ই ঘটে বা হয় না। অন্যান্য লেনদেনগুলি হওয়ার সময় অবশ্যই এটির নিশ্চয়তা থাকতে হবে, এমনকি এই দুটি অ্যাকাউন্টের মধ্যেও। সংশ্লিষ্ট টেবিলে লক নিয়ে সিস্টেমটি এটি নিশ্চিত করে । লকগুলি কী কী নেওয়া হয় এবং আপনি যে কত লোকের কাজ দেখেন তা লেনদেনের বিচ্ছিন্নতা স্তর দ্বারা নিয়ন্ত্রিত হয় ।
সুতরাং আপনি যদি অনেক কাজ করেন তবে একটি ভাল সুযোগ রয়েছে অন্য লেনদেনগুলি যে লকগুলিতে লক রয়েছে তার অপেক্ষায় অপেক্ষা করা হবে। এটি সিস্টেমের সামগ্রিক মাধ্যমে আউটপুট হ্রাস করবে। শেষ পর্যন্ত তারা সময়সীমা সীমাবদ্ধ করতে এবং ব্যর্থ হবে, যা সামগ্রিক সিস্টেমের আচরণের জন্য একটি সমস্যা। আপনি যদি আশাবাদী বিচ্ছিন্নতা স্তরটি ব্যবহার করেন তবে অন্যের কাজের কারণে কোনও প্রতিশ্রুতি দেওয়ার চেষ্টা করার সময় আপনার লেনদেন ব্যর্থ হতে পারে।
লক ধরে রাখা সিস্টেমের সংস্থান নেয়। এটি মেমরি যা থ্রিপুট হ্রাস করে অন্যান্য অনুরোধগুলি প্রক্রিয়া করতে সিস্টেম ব্যবহার করতে পারে না।
যদি প্রচুর কাজ সম্পাদিত হয় তবে সিস্টেম লক বিস্তৃতি সম্পাদন করতে বেছে নিতে পারে । পৃথক সারিগুলি লক করার পরিবর্তে পুরো টেবিলটি লক হয়ে যাবে। তারপরে আরও সহবর্তী ব্যবহারকারী প্রভাবিত হবে, সিস্টেমের মাধ্যমে আউটপুট আরও কমে যাবে এবং প্রয়োগের প্রভাব আরও বেশি হবে।
লক ফাইলগুলিতে ডেটা পরিবর্তনগুলি লিখিত হয়, লকগুলি যেমন তাদের রক্ষা করে। লেনদেন শুরু না হওয়া পর্যন্ত এগুলি লগ থেকে সাফ করা যায় না। অতএব খুব দীর্ঘ লেনদেন এর ফলে সম্পর্কিত সমস্যাগুলির সাথে লগ ফাইল ব্লোট করতে পারে।
যদি বর্তমান কাজটি টেম্পডিবি ব্যবহার করে, যা সম্ভবত বড় কাজের চাপের জন্য থাকে তবে লেনদেন শেষ না হওয়া পর্যন্ত সেখানকার সংস্থানগুলি সংযুক্ত থাকতে পারে। চরম ক্ষেত্রে এটি অন্যান্য কাজগুলিকে ব্যর্থ করতে পারে কারণ তাদের জন্য আর পর্যাপ্ত জায়গা নেই। আমার এমন কেস হয়েছে যেখানে একটি দুর্বল কোডড UPDATE ভরাট টেম্পডিবি হয়েছে তাই কোনও রিপোর্টের SORT এর জন্য পর্যাপ্ত ডিস্ক অবশিষ্ট ছিল এবং রিপোর্ট ব্যর্থ হয়েছিল।
আপনি যদি লেনদেনটি রোলব্যাক করতে চান বা সিস্টেম ব্যর্থ হয় এবং পুনরুদ্ধার করে, সিস্টেমটি পুনরায় উপলব্ধ হয়ে উঠতে সময় নেওয়া কতটা কাজ সম্পাদিত হয়েছিল তার উপর নির্ভর করবে। কেবল কোনও লেনদেন খোলা থাকলে পুনরুদ্ধারের সময়কে প্রভাবিত করবে না, এটি কতটা কাজ সম্পাদিত হয়েছিল। লেনদেন যদি খোলা ছিল তবে এক ঘন্টা পুনরুদ্ধারের জন্য অলসতা প্রায় তাত্ক্ষণিক হবে। যদি এটি ঘন্টা ধরে নিয়মিত লিখতে থাকে তবে থাম্বের নিয়মটি হ'ল পুনরুদ্ধারের সময়টিও প্রায় এক ঘন্টা হবে।
আপনি দেখতে পাচ্ছেন দীর্ঘ লেনদেন সমস্যা হতে পারে। ওএলটিপি সিস্টেমগুলির জন্য সর্বোত্তম অনুশীলন হ'ল প্রতি ব্যবসায় লেনদেনের জন্য একটি ডাটাবেস লেনদেন। ঘন ঘন কমিট সহ ব্লকগুলিতে ব্যাচের কাজের প্রক্রিয়া ইনপুটটির জন্য এবং যুক্তি কোডিং পুনরায় আরম্ভ করুন। সাধারণত এক হাজার ডিবি লেনদেনের মধ্যে কয়েক হাজার রেকর্ড প্রক্রিয়া করা যায়, তবে এটি একত্রে এবং পুনরায় ব্যবহারের জন্য পরীক্ষা করা উচিত।
অন্য চরম জায়গায় যেতে এবং পুরোপুরি লেনদেন এবং লকগুলি এড়ানোর প্রলোভন করবেন না। আপনার যদি আপনার ডেটাগুলির মধ্যে ধারাবাহিকতা বজায় রাখার প্রয়োজন হয় (এবং কেন আপনি অন্য একটি ডেটাবেস ব্যবহার করবেন?) বিচ্ছিন্নতা স্তর এবং লেনদেনের একটি খুব গুরুত্বপূর্ণ উদ্দেশ্য পরিবেশন করে। আপনার বিকল্পগুলি সম্পর্কে জানুন এবং সিদ্ধান্ত নিন যে আপনি নিজের অ্যাপ্লিকেশনের প্রতিটি অংশের জন্য বাঁচতে প্রস্তুত সম্মত এবং সঠিকতার ভারসাম্য।
আপনার বৃহত্তম ফলাফলটি লেনদেনে ব্যবহৃত জিনিসগুলি ব্লক করা হবে। বিশেষত যদি আপনি ধরে নেন যে আপনার ব্যবহারকারীরা ডেটা areোকাচ্ছে, তবে দীর্ঘকাল চলমান লেনদেনে সাধারণভাবে ব্যবহৃত টেবিলগুলিতে SELECT স্টেটমেন্ট অন্তর্ভুক্ত থাকতে পারে। আপনার ব্যবহারকারীর আপডেটের বিবৃতিগুলি তাদের আপডেটগুলি বা সন্নিবেশগুলি সম্পূর্ণ করতে প্রয়োজনীয় লকটি পেতে সক্ষম নাও হতে পারে।
লগ ফাইলের ক্রিয়াকলাপটি ঘটতে পারে এমন একটি মাধ্যমিক জিনিসটি বলুন আপনি যদি একটি বড় ডেটাसेट আপডেট করে থাকেন তবে লেনদেন যে লগ ব্যবহার করছে তা সেই লেনদেনের সময়কালের জন্য সক্রিয় রয়েছে। লেনদেন প্রতিশ্রুতিবদ্ধ বা ঘূর্ণিত না হওয়া পর্যন্ত আপনি লগের সেই অংশটি পুনরায় ব্যবহার করতে সক্ষম হবেন না। আপনি যেখানে বেশ সক্রিয় ওলটিপি সিস্টেমে থাকতে পারেন এমন পরিস্থিতিতে আপনার স্টোরেজ ডিভাইসটি পূরণ করে আপনার লগ ফাইলটি দ্রুত বাড়তে পারে।
অসম্পূর্ণ লেনদেনের ফলে প্রচুর সংখ্যক তালাবন্ধি আটকে থাকতে পারে এবং অবরুদ্ধ হতে পারে
যখন কোনও লেনদেন সম্পন্ন হয় না কারণ কোনও প্রশ্নের সময় শেষ হয়ে যায় বা ব্যাচটি কোনও লেনদেনের মাঝামাঝি সময়ে কোনও কমিট বা রোলব্যাক বিবৃতি জারি না করে লেনদেন সম্পন্ন করার জন্য বাতিল করা হয়, তখন লেনদেনটি উন্মুক্ত থাকে এবং সেই লেনদেনের সময় অধিগ্রহণ করা সমস্ত লক অবিরত থাকে অনুষ্ঠিত হবে. একই সংযোগে সম্পাদিত পরবর্তী লেনদেনগুলিকে নেস্টেড লেনদেন হিসাবে বিবেচনা করা হয়, সুতরাং এই সম্পন্ন লেনদেনগুলিতে অর্জিত সমস্ত লক প্রকাশ হয় না। এই সমস্যাটি একই সংযোগ থেকে কার্যকর হওয়া সমস্ত লেনদেনের সাথে পুনরাবৃত্তি করে যতক্ষণ না কোনও রোলব্যাক কার্যকর করা হয়। ফলস্বরূপ, প্রচুর সংখ্যক তালা আটকে থাকে, ব্যবহারকারীরা অবরুদ্ধ থাকে এবং লেনদেনগুলি হারিয়ে যায়, যার ফলস্বরূপ এমন ডেটা তৈরি হয় যা আপনি প্রত্যাশার চেয়ে আলাদা।