Data consistency refers to when same data kept at different places do not match.
Point-in-time consistency is an important property of backup files and a critical objective of software that creates backups. It is also relevant to the design of disk memory systems, specifically relating to what happens when they are unexpectedly shut down.
As a relevant backup example, consider a website with a database such as the online encyclopedia, Wikipedia, which needs to be operational around the clock, but also must be backed up with regularity to protect against disaster. Portions of Wikipedia are constantly being updated every minute of every day, meanwhile, Wikipedia’s database is stored on servers in the form of one or several very large files which require minutes or hours to back up.
These large files as with any database contain numerous data structures which reference each other by location. For example, some structures are indexes which permit the database subsystem to quickly find search results. If the data structures cease to reference each other properly, then the database can be said to be corrupted.
Application Consistency
Application Consistency is similar to Transaction consistency, but on a grander scale. Instead of data consistency within the scope of a single transaction, data must be consistent within the confines of many different transaction streams from one or more applications.
An application may be made up of many different types of data, such as multiple database components, various types of files, and data feeds from other applications. Application consistency is the state in which all related files and databases are in-synch and represent the true status of the application.
Transaction Consistency
A transaction is a logical unit of work that may include any number of file or database updates. During normal processing, transaction consistency is present only
- Before any transactions have run,
- Following the completion of a successful transaction and before the next transaction begins, and
- When the application ends normally or the database is closed.
Following a failure of some kind, the data will not be transaction consistent if transactions were in-flight at the time of the failure. In most cases what occurs is that once the application or database is restarted, the incomplete transactions are identified and the updates relating to these transactions are either “backed-out” or processing resumes with the next dependant write.
