Implementing a
Stand-Alone Continuous OPAC

Introduction | Overview | Tasks

What is Continuous OPAC?

"Continuous OPAC" is Endeavor's solution to making a library's Voyager database available to patrons (and staff) in read-only mode during system upgrades. The Endeavor recommended approach requires multiple channels connecting the database (on a mirrored disk array) to both the Voyager database server and the Continuous OPAC server. [1]

Continuous OPAC Using a Mirrored Disk Array (per Endeavor's Guidelines)	Stand-Alone Continuous OPAC

How is Stand-Alone Continuous OPAC different?

Stand-Alone Continuous OPAC is the same thing, but with less complexity and fewer hardware prerequisites. As the name implies, the stand-alone approach dispenses with any hardware connection between the Continuous OPAC server and the Voyager database server disk array. This tutorial explains how to configure such a setup. Most of the configuration steps apply to both approaches, so this tutorial will be relevant regardless of which method you choose to implement.

Prerequisites

Continuous OPAC

Stand-Alone Continuous OPAC

At least two independent servers must be available during the upgrade.
The alternate OPAC server must be large enough to support the expected OPAC load during the upgrade period.
Both the production server and the alternate OPAC server must be running the same version of the operating system.
The production server must maintain at least one mirrored copy of the system which can be physically detached from the production server and cabled to the alternate OPAC system.
The alternate OPAC system must contain an appropriate controller capable of interfacing with the detached mirror of the production server.
The site must complete the Endeavor Information Systems certification classes.
The production server must be left with enough disk space to accommodate the upgrade. The typical Voyager upgrade will consume disk space equal to 4.0 times the size of the largest tablespace. Since the space normally available from the detached mirror is now in use on the alternate server (supporting the OPAC) other disk space will be needed for the operation.

At least two independent servers must be available during the upgrade.
The alternate OPAC server must be large enough to support the expected OPAC load during the upgrade period.
Both the production server and the alternate OPAC server must be running the same version of the operating system.
The alternate OPAC server must have sufficient disk space (preferably a spare disk) to accommodate the Voyager database.

A third way?

Could Continuous OPAC be implemented by doing a Network File System (NFS) mount of the offlined Voyager database submirror? According to Endeavor, NFS mounting the Voyager database is problematic and is not recommended.

Target Audience

Mid-sized academic libraries are likely to find Stand-Alone Continuous OPAC a viable alternative since their database can fit onto a single spare disk. Academic libraries with huge databases (and big budgets!) may also find this a viable alternative if they have a Voyager test server.

References