Unisys OS 2200 databases: Difference between revisions

Revision as of 20:03, 12 May 2023

Latest revision as of 12:53, 19 July 2024

Line 1:

{{Advert|date=May 2022}}

{{Inline|date=May 2022}}

{{Short description|Aspect of Unisys OS 2200 operating system}}

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 model|data models]]. [[Flat-file database|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, MNMinnesota. 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, MNMinnesota. 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, MNMinnesota. 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 mixture 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, MNMinnesota. 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, MNMinnesota. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78310737-021.pdf</ref>

The database managers are implemented as a [[Unisys OS 2200 operating system#Subsystems|protected subsystem]] and are called procedures in user programs and other subsystems. The database managers support access using many common distributed data access protocols and [[API|APIs]], including [[Java Database Connectivity|JDBC]], [[OLE DB]], and [[Open Database Connectivity|ODBC]]. See also [[Unisys OS 2200 distributed processing]].

[[File:OS 2200 Database Architecture.jpg|center]]

The heart of the database and transaction system is Integrated Recovery. “Integrated”"Integrated" implies the integration of all data models, the transaction file manager, the transaction scheduler, and the [[Message queue|message queues]]. All activity in all of these areas is [[Journal (computing)|journaled]] (written toon the [[audit trail]]). The audit trail is managed by the Exec which ensures [[synchronization]] for all users.<ref>Unisys Corporation (2010). <u>Integrated Recovery Conceptual Overview</u>. (Unisys publication 7830 8186). Roseville, MNMinnesota. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78308186-004.pdf</ref> The Integrated Recovery Utility (IRU) provides database backup synchronized with executing transactions and audit trails.

The database managers are implemented as a [[Unisys OS 2200 operating system#Subsystems|protected subsystem]] and are called a procedure from user programs and other subsystems. The implementation as a subsystem means that there is no upper limit to the potential concurrency of activities (threads) executing in the database manager. The thread of each user executes the database manager code but within its protection ___domain so that misbehaved and malicious programs cannot affect the integrity of the database. This approach also reduces the path lengths and overhead involved as messages do not have to be sent between the caller and the database manager. All communication is through parameters.

This commonality has made it possible for clients to modernize applications moving from language files, to a network database, to a relational database. They can use a mixture of these at the same time in a single program while retaining full recoverability. With all the recovery, clustering, locking, and cache management centralized, applications do not have to deal with those aspects. In OS 2200 locking is generally implicit in the database verbs used. For example, a read-for-update implies setting a certain type of lock and the corresponding update write implies clearing it.

The database managers support access using many common distributed data access protocols and APIs including [[Java Database Connectivity|JDBC]], [[OLE DB]], and [[Open Database Connectivity|ODBC]]. See also [[Unisys OS 2200 distributed processing]].

[[File:OS 2200 Integrated Recovery.png|center]]

The heart of the database and transaction system is Integrated Recovery. “Integrated” implies the integration of all data models, the transaction file manager, the transaction scheduler, and the message queues. All activity in all of these areas is [[Journal (computing)|journaled]] (written to the [[audit trail]]). The audit trail is managed by the Exec which ensures synchronization for all users.<ref>Unisys Corporation (2010). <u>Integrated Recovery Conceptual Overview</u>. (Unisys publication 7830 8186). Roseville, MN. http://public.support.unisys.com/2200/docs/cp14.0/pdf/78308186-004.pdf</ref>

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 rescheduled. 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.

A full recovery is used when a catastrophic failure has caused loss of some or all of the mass storage holding the database. Affected files are reloaded from the last backup and appropriated updates are applied from the audit trail files.

== References ==