Table of Contents
Storage structure is the memory structure in the system. It is mainly divided into two categories :
Volatile Memory
These are the primary memory devices in the system, and are placed along with the CPU. These memories can store only small amount of data, but they are very fast. E.g.:- main memory, cache memory etc. these memories cannot endure system crashes- data in these memories will be lost on failure.
Non-Volatile memory
These are secondary memories and are huge in size, but slow in processing. E.g.:- Flash memory, hard disk, magnetic tapes etc. these memories are designed to withstand system crashes.
Stable Memory
This is said to be third form of memory structure but it is same as non volatile memory. In this case, copies of same non volatile memories are stored at different places. This is because, in case of any crash and data loss, data can be recovered from other copies. This is even helpful if there one of non-volatile memory is lost due to fire or flood. It can be recovered from other network location. But there can be failure while taking the backup of DB into different stable storage devices. Even it may fail to transfer all the data successfully; either it will partially transfer the data to remote devices or completely fail to store the data in stable memory. Hence extra caution has to be taken while taking the backup of data from one stable memory to other. There are different methods followed to copy the data. One of them is to copy the data in two phases – copy the data blocks to first storage device, if it is successful copy to second storage device. The copying is complete only when second copy is executed successfully. But second copy of data blocks may fail to copy whole blocks. In such case, each data blocks in first copy and second copy needs to be compared for its inconsistency. But verifying each blocks would be very costly task as we may have huge number of data block. One of the better way to identify the failed block is to identify the block which was in progress during the failure. Take only this block, compare the data and correct the mismatches.
Failure Classification
When a transaction is being executed in the system, it may fail to execute due to various reasons. The failure can be because of system program, bug in a program, user, or system crash. These failures can be broadly classified into three categories.
- Transaction Failure : This type of failure affects only few tables or processes. This is the condition in the transaction where a transaction cannot execute it further. This failure can be because of user or executing program/ transaction. The user may cancel the transaction when the transaction is executing by pressing the cancel button or abort using the DB commands. The transaction may fail because of the constraints on the tables – violation of constraints. It can even fail if there is concurrent processing of multiple transactions and there is lack of resources for all of them or deadlock situation. All these will cause the transaction to stop processing in the middle of its execution. When a transaction fails / stops in the middle, it would have partially changed DB and it needs to be rolled back to previous consistent state. In ATM withdrawal example, if the user cancels his transaction after step (i), the system should be able to stop further processing of the transaction, or if he cancels the transaction after step (ii), the system should be strong enough to update his balance in his account. Here system may cancel the transaction due to insufficient balance. The failure can be because of errors in the code – logical errors or because of system errors like deadlock or unavailability of system resources to execute the transactions.
- System Crash : This can be because of hardware or software failure or because of external factors like power failure. This is the failure of the system because of the bug in the software or the failure of system processor. This crash mainly affects the data in the primary memory. If it affects only the primary memory, the actual data will not be really affected and recovery from this failure is easy. This is because primary memories are temporary storages and it would not have updated the actual database. Hence the system will be in a consistent state before to the transaction. But when secondary memory crashes, there would be a loss of data and need to take serious actions to recover lost data. Because secondary memories contain actual DB data. Recovering them from crash is little tedious and requires more effort. DB Recovery system provides strong mechanisms to recovery the system from crash and maintains the atomicity of the transactions. In most of the cases data in the secondary memory are not affected because of this crash. This is because; the database has lots of integrity checkpoints to prevent the data loss from secondary memory.
- Disk Failure : These are the issues with hard disks like formation of bad sectors, disk head crash, unavailability of disk etc. Data can even be lost because of fire, flood, theft etc. This is mainly affects the secondary memory where the actual data lies. In these cases, we need to have alternative ways of storing DB. We can create backups of DB at regular basis and store them separately from the memory where DB is stored or maintain multiple copies of DB at different network locations to recover them from failure.
