Unisys OS 2200 databases: Difference between revisions

Content deleted Content added
SmithRQ (talk | contribs)
m Update document links
m top: clean up, typo(s) fixed: re-scheduled → rescheduled
Line 1:
The [[Unisys OS 2200 operating system|OS 2200]] database managers are all part of the Universal Data System (UDS). UDS provides a common control structure for multiple different data models. Flat files (sequential, multi-keyed indexed sequential – MSAM, and fixed-block),<ref>Unisys Corporation (2010). <u>Shared File System (SFS 2200) Administration and Support Reference Manual</u>. (Unisys publication 7831 0786). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310786-003.pdf</ref> [[Network model|network]] (DMS),<ref>Unisys Corporation (2010). <u>Data Management System (DMS 2200) Schema Data Definition Language (DDL) Administration, Operations, and Programming Guide</u>. (Unisys publication 7831 0745). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310745-005.pdf</ref> and [[Relational database|relational]] (RDMS)<ref>Unisys Corporation (2010). <u>Relational Data Management System (RDMS 2200) and IPF SQL Interface End Use Guide</u>. (Unisys publication 7831 0778). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310778-003.pdf</ref> data models all share a common locking, recovery, and clustering mechanism. OS 2200 applications can use any mixtures of these data models along with the high-volume transaction file system<ref>Unisys Corporation (2012). <u>Transaction Processing Conceptual Overview</u>. (Unisys publication 7830 9960). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78309960-004.pdf</ref> within the same program while retaining a single common recovery mechanism.<ref>Unisys Corporation (2013). <u>Universal Data System Administration and Support Reference Manual</u>. (Unisys publication 7831 0737). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310737-021.pdf</ref>
 
[[File:OS 2200 Database Architecture.jpg|center]]
Line 15:
The Integrated Recovery Utility (IRU) is the heart of the recovery system. It provides database backup synchronized with executing transactions and the audit trails. Transactions and batch applications do not need to be stopped to back up the database. IRU makes that unnecessary. All backups can be performed in a running system. Start-of-backup and complete-backup sentinel blocks are written to the audit trail. IRU uses these blocks and other information on the audit trail to perform the fastest possible recovery operations.
 
There are three main types of recovery actions. All are designed to work across clustered systems. Short recovery is normally used when an application or system failure necessitates performing recovery. Most transactional updates are not written to the database files on disk until the transaction completes successfully and instead are kept in memory or in a roll-forward file. Recovery then means indicating which transactions were in progress and need to be re-scheduledrescheduled. Transactions that had completed but whose data was not yet written to disk have their data written to the disk files.
 
Recovery to a point in time is most often used when an application update with errors was inserted in the system or a human mistake has partially corrupted the database. The IRU may be told to simply take all the state back to a previous time.