Data Consistency refers to the usability of data and is often taken for granted in the single site environment. Data Consistency problems may arise even in a single-site environment during recovery situations when backup copies of the production data are used in place of the original data.
In order to ensure that your backup data is useable, it is necessary to understand the backup methodologies that are in place as well as how the primary data is created and accessed. Another very important consideration is the consistency of the data once the recovery has been completed and the application is ready to begin processing.
In order to appreciate the integrity of your data, it is important to understand the dependent write process. This occurs within individual programs, applications, application systems and databases. A dependent write is a data update that is not to be written until a previous update has been successfully completed. In the large systems environments, the logic that determines the sequence in which systems issue “writes” is controlled by the application processing flow and supported by basic system functions.
Considering just the local-site z/OS “production” data for a moment, the consistency of this local data is ensured by a number of protective mechanisms – beginning with ENQ, Reserve/Release, various modes of database functionality as well as the overall timing of the application writes. Usually, when data is to be written, control is passed from the application program to system subroutines to perform the actual write. Once the write has completed, control is returned to the application and processing continues.
This process provides an inherent synchronization and guarantees that record A has been successfully written before the write I/O of record B can be issued by the application.
By and large we take these synchronization features for granted and do not give much thought to how they all work together to protect both the integrity and consistency of the data. It is the integrity of the data and various systems that allows applications to restart after a power failure or other unscheduled event.
Data is said to be Point in Time consistent if all of the interrelated data components (either a group of data sets or a set of logical volumes) are as they were at any single instant in time. This type of consistency can be visualized by picturing a data center that has experienced a power failure. Before the lights come back on and processing resumes, the data is considered time consistent, due to the fact that the entire processing environment failed at the same time.
Different types of failures may create a situation where Point in Time consistency is not maintained. For example, consider the failure of a single logical volume containing data from several applications. If the only recovery option is to restore that volume from a backup taken sometime earlier, the data contained on the restored volume is not consistent with the other volumes, and additional recovery steps must be undertaken.
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
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.
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.
For additional information relating to Data Consistency, please click on one of the links below:
This document was printed from http://recoveryspecialties.com/