Fault-tolerance is systematically applied to the organization of a parallel associative (content addressable) database processor. Storage areas are protected by duplication and by error detecting and/or correcting codes. A duplex Checking Unit is introduced to check the reading and writing operations. Individual Area Processors are employed to search the storage areas. They are protected by duplexing or triplexing with or without sparing. Effectiveness of these fault-tolerance techniques is assessed by means of reliability predictions for a 100-storage area system. The UCLA ARIES reliability modeling program is employed to obtain the reliability predictions. Major gains in system reliability are demonstrated, and relative effectiveness of alternate approaches is analyzed.

The need for robust recovery facilities in modern database management systems is quite well known. Various authors have addressed recovery facilities and specific techniques, but none have delved into the problem of recovery in database machines. In this paper, the types of undesirable events that occur in a database environment are classified and the necessary recovery information, with subsequent actions to recover the correct state of the database, is summarized. A model of the “processor-per-track” class of parallel associative database processor is presented. Three different types of recovery mechanisms that may be considered for parallel associative database processors are identified. For each architecture, both the workload imposed by the recovery mechanisms on the execution of database operations (i.e., retrieve, modify, delete, and insert) and the workload involved in the recovery actions (i.e., rollback, restart, restore, and reconstruct) are analyzed. The performance of the three architectures is quantitatively compared. This comparison is made in terms of the number of extra revolutions of the database area required to process a transaction versus the number of records affected by a transaction. A variety of different design parameters of the database processor, of the database, and of a mix of transaction types (modify, insert, and delete) are considered. A large number of combinations is selected and the effects of the parameters on the extra processing time are identified.