Deferred Update - Delayed write
In mainframe systems, a **deferred update**, also known as a **delayed write**, is a strategy where changes to data (e.g., in a database or file) are initially recorded in memory buffers and transaction logs, but not immediately written to the permanent storage (disk). The actual write to disk is postponed until a later point, such as a transaction commit, a checkpoint, or when the buffer needs to be reused. This approach prioritizes performance by minimizing synchronous disk I/O. In the mainframe context, particularly within database management systems (DBMS) like DB2 or IMS, a deferred update (or delayed write) refers to a strategy where changes made to data are initially written to an in-memory buffer or cache rather than directly to persistent storage (disk). These modifications are then written to disk at a later, more opportune time, often in groups, to optimize I/O performance.
Key Characteristics
-
- Performance Enhancement: By reducing the number of physical disk I/O operations, deferred updates significantly improve transaction throughput and overall system performance, as writes to memory are much faster than writes to disk.
- Logging and Recovery: To ensure data integrity and recoverability, all changes made in memory are meticulously recorded in a write-ahead log (WAL) or journal before the actual data pages are updated in memory. This log is crucial for rollback and forward recovery.
- Buffer Management: Data pages are held in buffer pools (e.g., DB2 buffer pools, IMS buffer pools, CICS data tables). The deferred update mechanism relies on efficient buffer management to determine when to write modified ("dirty") pages to disk.
- Commit Processing: For transactional systems (like CICS with DB2/IMS), changes become permanent only upon a successful commit operation. At commit time, the log records associated with the transaction are typically forced to disk, but the data pages themselves might still reside in memory and be written later.
- Checkpointing: Database management systems (DBMS) like DB2 and IMS periodically perform checkpoints, which involve writing all dirty pages up to a certain point to disk, thereby reducing the amount of log data needed for recovery during a restart.
Use Cases
-
- Database Management Systems (DBMS): DB2 for z/OS and IMS DB extensively use deferred updates. When an application updates a row in DB2 or a segment in IMS, the change is applied to the data page in a buffer pool, and a log record is written. The physical write to disk happens later.
- Transaction Processing Systems (TPS): CICS transactions that interact with databases or update files often leverage deferred updates. For instance, CICS VSAM RLS (Record Level Sharing) can use deferred writes for improved performance by buffering updates.
- Operating System Paging: The z/OS operating system itself uses deferred writes when managing virtual storage, writing modified pages of memory to auxiliary storage (paging datasets) only when necessary, rather than immediately.
- Data Sharing Environments: In DB2 Data Sharing or IMS Data Sharing, deferred updates are critical for maintaining cache coherency and reducing cross-system I/O by allowing local updates to be buffered before being externalized.
Related Concepts
Deferred updates are intrinsically linked to transaction management (e.g., CICS, IMS TM) and database recovery mechanisms. They rely heavily on logging and journaling (specifically the write-ahead log principle) to ensure that even if a system failure occurs before data is written to disk, the changes