কেন অনির্দিষ্ট লেনদেনগুলি পিছনের ক্রমে পূর্বাবস্থায় ফেরাতে হবে?


19

আমার একটি ডাটাবেস লগ রয়েছে যেখানে কিছু লেনদেন জিতে থাকে (তারা ক্র্যাশের আগে প্রতিশ্রুতিবদ্ধ হয়) এবং কিছু হারাতে থাকে (এখনও প্রতিশ্রুতিবদ্ধ হয় না)। আমরা ক্লাসে শিখেছি যে হেরকারীর ক্রিয়াগুলি পিছনের দিকে ফিরে যেতে হবে।

পিছনের দিকে এটি করার কোনও কারণ আছে কি? যে কেউ লগের কোনও সহজ উদাহরণ দিতে পারে যেখানে ফরোয়ার্ড আন্ডোস ভুল ফলাফল দেয়?


এই প্রশ্নটি আরও একটি নির্দিষ্ট ওয়েবসাইটে জিজ্ঞাসা করা উচিত নয়?
nbro

উত্তর:


35

আসল লেনদেন:

  1. রেকর্ড ঢোকান r
  2. আপডেট করুন কিছু ক্ষেত্র এর fr

ফরোয়ার্ড পূর্বাবস্থা:

  1. মুছে ফেলুন রেকর্ড r
  2. আপডেটটি - তে বিপরীত করুন - ওহ অপেক্ষা করুন, আর আর বিদ্যমান নেই! এটি একটি ত্রুটি ঘটায়।rr

বিপরীত ক্রমে কী জিনিসগুলিকে শারীরিকভাবে স্বতন্ত্রভাবে পূর্বাবস্থায় ফিরিয়ে আনতে হবে যদি সিস্টেমটি বুঝতে পারে যে কোন কিছুর স্টেটগুলিতে ফিরে যেতে হবে এবং অন্য কোনও কিছুর প্রক্রিয়া করার আগে সমস্ত প্রয়োজনীয় পরিবর্তনগুলি প্রয়োগ করতে পারে?
সুপারক্যাট

11
বিপরীত ক্রমে পরিবর্তনগুলি পূর্বাবস্থায়িত করা সহজ করে তোলে। আপনি কেন নিজের উপর এটি কঠোর করার চেষ্টা করবেন?
gnasher729

1
না, সিস্টেম করব না সবকিছু কিন্তু এখনও অনগ্রসর যাতে জিনিসটা হবে।
এভিল

3
অনেক রিয়েল ওয়ার্ল্ড ডাটাবেস সিস্টেমগুলিতে এটি বিপরীত ক্রমে না করা সারণিতে কী কী বাধার কারণে সম্ভব হয় না।
শানআরআর

11

ডিলানস্পের উত্তরে যোগ করতে, অ-বিদ্যমান রেকর্ডে একটি ক্ষেত্র আপডেট করার চেষ্টা করা ব্যর্থ হবে, তবে ফলাফলটি এখনও প্রত্যাশিত ফলাফল হবে: রেকর্ড আর নেই।

তবে, এমন পরিস্থিতিতে বিবেচনা করুন যেখানে কোনও রেকর্ড মুছে ফেলা ব্যর্থ হবে:

  1. অর্ডার ও Inোকান
  2. অর্ডারলাইন .োকান

আসুন ধরে নিই, অবাস্তবভাবে নয়, প্রতিটি অর্ডারলাইন অবশ্যই কোনও অর্ডারের সাথে সম্পর্কিত হতে পারে।

এখন অর্ডার মুছে ফেলা দিয়ে শুরু হওয়া লেনদেনের ব্যর্থতা ব্যর্থ হবে কারণ এটি আমাদের ব্যবসায়িক বিধি লঙ্ঘন করবে।

তাহলে পরে

  1. অর্ডার ও মুছে দিন (FAIL)
  2. অর্ডারলাইন এল। (ব্যর্থতা) মুছুন

আমরা একটি বিদ্যমান অর্ডার (অর্ডারলাইন ছাড়াই) শেষ করতে পারি।

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


ঠিক আছে এটি বোধগম্য হয়। আপনার সহায়তার জন্য
THX

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

2
@ নোকটিসস্কিটওয়ার একটি সাধারণ আই / ও অপারেশন চলাকালীন প্রতিবন্ধকতাগুলি বন্ধ করে দেওয়া তাদের অকেজো করে দেয়। এগুলির একটি কারণ রয়েছে। আমার উদাহরণটি পরিষ্কারভাবে ব্যাখ্যা করে যে কীভাবে সাধারণ পরিস্থিতিতে সীমাবদ্ধতাগুলি পূরণ করা যায়, তবুও রোলব্যাকের সময় লঙ্ঘন করা হয়। রোল ব্যাক করার সময় সীমাবদ্ধতা বন্ধ করা অযথা বিষয়গুলিকে জটিল করে তোলে এবং ভুল সমস্যা সমাধান করে। সমস্যা সীমাবদ্ধতা নয়, সমস্যাটি ভুলভাবে ফিরে যাওয়ার চেষ্টা করে এটি লঙ্ঘন।
oerkelens

হ্যাঁ, এটি উপলব্ধি করে তবে রোলব্যাক চলাকালীন কেন বাধাগুলি পরীক্ষা করে? ধরে নিই রোলব্যাকগুলি কোনও সমস্যা ছাড়াই সম্পূর্ণরূপে গ্যারান্টিযুক্ত করার জন্য ডিজাইন করা হয়েছে, যদি অজান্তে সময় যাচাইয়ের সীমাবদ্ধতাগুলি যদি জানা থাকে যে তারা রোলব্যাকটি সম্পূর্ণ করার সময় লঙ্ঘিত হবে না কেন? বিটিডাব্লু, এটি একটি গ্যারান্টি হওয়া উচিত কারণ যদি কোনও রোলব্যাক ব্যর্থ হয়, তবে ডিবিকে সম্ভবত এটি রোল-ফরোয়ার্ড করতে হবে যা এটি করতে পারে না।
নোকটিস স্কাইটিওয়ার

1
@ নোকটিসস্কিটওয়ারটি অস্থায়ী রাষ্ট্র হওয়া সত্ত্বেও ডিবি-র পক্ষে সীমাবদ্ধতা লঙ্ঘিত হওয়া অবস্থায় থাকতে পারে না। যদি পুরো রোলব্যাকটি পারমাণবিক হয় তবে কোনও অর্ডার না থাকায় এটি কোন অর্ডার হয় তা বিবেচনা করে না, এটি একটি একক নির্দেশ যা "একবারে সমস্ত ঘটে"। যদি দুটি বা ততোধিক লেনদেন থাকে যা কিছু ক্রমে আলাদাভাবে ঘুরিয়ে দেওয়া হয়, তবে আদেশটি বাধ্যতামূলক হওয়া উচিত যে মাঝামাঝিতে ডেটা পাঠ করা কোনও পর্যবেক্ষক কেবল এমন পরিস্থিতি দেখতে পারবেন যেখানে সমস্ত সীমাবদ্ধতা রয়েছে।
পিটারিস

6

চলুন সাদৃশ্য অনুসারে চলুন: বলুন যে আপনি রাতের খাবারের জন্য বাইরে যাচ্ছেন।

  1. মোজা লাগিয়ে দিন।
  2. জুতো রাখুন।
  3. দাড়াও.
  4. দ্বারে দ্বারে হেঁটে।

তারপরে আপনি একটি ফোন কল পাবেন। রাতের খাবারের পরিকল্পনা বাতিল হয়েছে।

  1. মোজা খুলে ফেলুন।
  2. জুতো খুলে ফেল।
  3. বস.
  4. দরজা থেকে দূরে হাঁটা।

সেখানে কিছু ভুল হয়ে যায়। আপনি ট্রিপ এবং নিজেকে আঘাত করতে পারেন। বা আরও সম্ভবত, আপনি বুঝতে পারবেন যে কিছু ক্রিয়াকলাপগুলি পূর্বের ক্রিয়াকলাপগুলি পূর্বাবস্থায় ফেরা না হওয়া পর্যন্ত পূর্বাবস্থায় ফেরানো যাবে না।

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

গাণিতিকভাবে বলা: ক্রিয়াগুলি কমিট নাও হতে পারে, তাই যখনই আপনি প্রথমে বা দ্বিতীয় কোন পদক্ষেপটি বিবেচনা করবেন তখনই আপনি যে পদক্ষেপগুলি পূর্বাবস্থায় ফিরিয়ে আনবেন তা গুরুত্বপূর্ণ।


3

এটি সঠিক কারণ লেনদেন একে অপরের উপরে নির্মিত হয় এবং লেনদেনের ফলাফল সংঘটিত হওয়ার আগে পরিস্থিতির উপর অনেক বেশি নির্ভরশীল।

আসুন আর্থিক লেনদেনগুলি দেখুন:

(শুরুতে, লেনদেনের জন্য aআমার 100 ডলার before ণী হওয়ার আগে )

  1. a আমার প্রতি 100 মার্কিন ডলার (এখন মোট debtণ 200)
  2. aতিনি আমার যে পাওনা তার উপর 10% ছাড় পান। (এখন মোট debtণ 180)

ধরা যাক আমি দুটি লেনদেন বাতিল করতে চাই।

আমরা যদি প্রথমটি বাতিল করে দিই তবে আমরা এগুলি শেষ করব:

  1. নিম্ন debtণ 100 (এখন 80ণ 80)
  2. 10% ছাড় বাতিল করুন (এখন 80ণ 80 / 0.9 = 88)

এটি ভুল, আমাদের ১০০ debtণ ফিরিয়ে নেওয়া দরকার we যদি আমরা বিপরীত ক্রমে লেনদেন বাতিল করি তবে এটি ঠিক হবে।

  1. ছাড় বাতিল - এখন debtণ 200
  2. কম 100 debtণ - এখন debtণ 100

2

ধরুন কেবল একটি কলাম সহ একটি টেবিল টি রয়েছে।

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

At 8:00 A.M., Transaction 100 inserts rows with values 101, 102 and 103 into table T. At 8:10 A.M., Transaction 100 is committed and the commit for transaction 100 completes. At 8:15 A.M., Transaction 200 updates row 101 to 201, 102 to 202 and 103 to 203. At 8:20 A.M., Transaction 200 has not been committed and remains in the undo log of the database. At 8:25 A.M., Transaction 300 increments each row by 50, changing row 201 to 251, 202 to 252, and 203 to 253. At 8:30 A.M., Transaction 300 has not been committed and remains in the undo log of the database. At 8:35 A.M., The instance providing access to the database crashes.

At 8:40 A.M., The instance is restarted, and the database files are opened as the instance is started:

              The committed values in T are still 101, 102 and 103.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, if they are written into the "redo
              log" of the database, there is a need to "roll back"
              the transactions AFTER the "redo log" is applied.

              Since 201, 202, and 203, and 251, 252 and 253
              are not committed, they are in the "undo log"
              of the database.

              The undo log of the database is used BOTH to (1) roll
              back a transaction that is deliberately rolled 
              back in the memory structure of the database instance, 
              and also (2) during the instance recovery at 8:40 A.M.

At 8:41 A.M., The redo log has been applied, and the T table contains values 251, 252 and 253 in the instance memory.

              The undo log has not yet been applied.

At 8:42 A.M., The undo log is applied in the reverse order: Uncommitted transaction 300 is undone, and Uncommitted transaction 200 is undone.

কেন দুটি প্রতিশ্রুতিবদ্ধ এবং অনির্ধারিত লেনদেনগুলি পুনরায় লগ ফাইলটিতে লিখিত হয়? এর কারণ হ'ল পয়েন্ট-ইন-টাইম পুনরুদ্ধার।

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

"পূর্বাবস্থায় ফিরিয়ে আনতে" লেনদেনগুলি কেন বিপরীত ক্রমে ফিরে আসে? লেনদেন 300 প্রতিটি সারির প্রতিটি কলামের বিদ্যমান মান 50 যোগ করেছে। সুতরাং, যদি লেনদেন 200 প্রথমে আবার ঘূর্ণিত হয় তবে মানগুলি 251, 252 এবং 253 থেকে 201, 202 এবং 203 এ পরিবর্তিত হয় transaction মূল প্রতিশ্রুতিবদ্ধ মান।

রেফারেন্স:

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273


0

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

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