Recoverable and Nonrecoverable Schedules in Transaction

hello everyone welcome back in this short video we will understand recoverable and non recoverable schedule okay so first of all we need to understand what is recoverability so theoretically recoverability is a situation where we can recover the data after some failure okay we have already understood failure recovery and the system log right so recovery ability is something where after some failure we need to recover the data okay we need to recover the old database State so that is recoverability now asha do can be recoverable or not depending upon how the operations of the schedule is being performed okay so to understand it better let's take two examples let us understand these two examples as you already know that recovery is a tedious process okay it consumes a lot of time so we have to avoid a situation where we have to go for recovery okay so here and thick and theoretically we assume that if a transaction is committed then there should not be a case when we have to roll back the transaction that is a committed transaction should not be rolled back so let me write it down this is very important a committed transaction should never be rolled back okay now let's come to the example here you can see in this schedule let's call it s1 and I will call it s2 okay so this is a schedule and this is the time okay so this occurs first then followed by this operation then followed by this operation okay so this is the timeline now here you can see transaction t1 starts with operation rx that is reading a database item X now first it reads the database item X it increases the value by 10 this in this operation okay and then it writes back so initially let's say X let's say this is our X have value hundred okay then first it reads and then it writes it increases the value by ten and writes back so it is now 110 right but you can see that this transaction is not yet committed okay so let's say commit is somewhere here at the bottom most I mean this is the last most operation now transaction t2 starts and it reads the value okay so what it will read now it will read as 110 okay now it increases or basically decreases it decreases the value by five so it will be now hundred five okay and then it writes back okay so now it will write back the value and it will be now 105 okay then this transaction commits okay then this transaction commits commits means we know that commits means its writes back this value to the disk and then followed by this transaction t1 commits right now let's imagine a situation where after this transaction has committed that is t2 has committed at this point of time at this point of time when transaction t2 has committed but t1 has not yet committed it fails transaction fails okay now when transaction fails here what will happen because transaction t1 is not yet committed it will roll back okay fine so what is rollback it will roll back the value and it will it will roll back to what the original value that is it will become 100 again fine but you can see that as this transaction this transaction is already committed we cannot roll it back okay so this is a theoretical assumption that a committed transaction should not be rolled back of course we can roll back okay as we know that we have log file and we can roll back but this is costly and we do not want to do it okay and theoretically it should be avoided okay it is not possible let's let's call it it's not possible okay so a committed transaction is never roll it back okay so this transaction is already committed it and it is assumed to be completed okay but as this transaction has consumed a data which was not committed this data which was not committed that's why the whole schedule is non recoverable okay the whole schedule is non recoverable now let's come to schedule 2 okay here you can see that before transaction t2 reads the value of X first it is committed okay so basically transaction t2 is reading a committed value okay even if some transaction fails let's say let's find out a failing point so even if it fails here it will roll back and start again okay aunty to of course is not T to have not read anything yet so there is no problem okay so as transaction t2 is reading a data which is already committed that's why there is no chance of inconsistency okay so and if it fails let's say if it fails here so only t2 is failing so it will roll back okay there is no need to roll back of t1 okay and that's why this is a recoverable schedule okay in case of any failure this schedule can be recovered so I hope you understand this this non-recoverable schedule is scheduled where the later transaction is consuming a data which is not yet committed okay so transaction t1 has produced a data and it has not yet committed but transaction t2 has started using the data so there is a wise chance of getting inconsistency right so it is non recoverable while in recoverable other transaction that is next transaction t2 reads data only after the commit of the first transaction okay so it is a safe data to read and that's why it is called recoverable in case of failure so the idea is that non recoverable schedules should not be allowed

Channel: Techtud

Views: 65,235

Rating: 4.8530884 out of 5

Keywords: GATE, IIT, Techtud, Engineering, Recoverable and Nonrecoverable, Transaction Management, Database Management System

Id: jEqnfpaEO6M

Length: 7min 34sec (454 seconds)

Published: Sat Mar 12 2016