Acronyms The following acronyms will be used in order to avoid repeating these two mouthfuls. VDBS - Voyager Database Server SCOPAC - Stand-alone Continuous OPAC Server Requirements
Familiarize yourself with the concept of machine aliases and how the Domain Name Service (DNS) operates. Find out who administers DNS at your site and how to go about editing entries. Create all the relevant Voyager users and groups on the SCOPAC. Copy over each user's .profile file from the VDBS. The "library" user's home directory will also require a symbolic link to the voyager.env file. Prepare a disk The Voyager files must reside on one file system. It is highly recommended that you dedicate a disk to this purpose. Our database of approximately 1,000,000 records fits comfortably on a 35GB disk, and could probably be shoe-horned onto a 20GB disk. In calculating your disk requirements, keep in mind that the /m1 filesystem tends to get bloated over time with non-essential files. Not everything is needed for a SCOPAC instance. Install Voyager database on SCOPAC 
There is more than one way to get the needed files where you want them. I recommend restoring the required Voyager files from your most recent VDBS backup to the SCOPAC disk. Doing so not only accomplishes the task at hand, it also gives you real-world, verifiable practice restoring from backup.
Configuration on SCOPAC
If you maintain a separate WebVoyage server, then the VDBS WebVoyage configuration files may not be the ones you want to use. If this is the case, you would want to copy over the WebVoyage configuration files from the WebVoyager server to the SCOPAC.
Ensuring read-only access As the name suggests, the main purpose of Continuous OPAC is to allow access to your catalog while the production database is being upgraded. Patrons (and staff) will see a static "snapshot" of the database at a particular point in time. Since this snapshot will never be reconciled with your production database, you don't want to allow any updates to the SCOPAC database. In addition to OPAC access, you may also choose to allow staff access via the Voyager client modules. This may determine what read-only access method you choose. Testing You definitely want to test SCOPAC functionality before it is actually needed. As you start up oracle and voyager ( /etc/init.d/dbora start and /etc/init.d/voyager start), you may get error messages. These error messages will usually give you a clue as to what part of your scopac installation needs attention. Chances are good that it is a permissions problem.
Because WebVoyage is designed to easily access an Oracle database on another server, it is sometimes difficult to determine just where it is getting its data. A good test is to point one of your staff clients (e.g. the Cataloging module) at the SCOPAC (by editing the voyager.ini on your PC), make a change to a record, and then verify that the change shows up in your SCOPAC WebVoyage instance and not in your production WebVoyage instance. It is recommended that you do an initial proof-of-concept of SCOPAC prior to any Voyager upgrade. Once you are confident in your SCOPAC setup skill, timing it for an upgrade is a balance between using the most current Voyager database backup for your snapshot vs. leaving enough time for last minute verification and testing. Switching over If you use an alias for your WebVoyage server, you simply have to delete the alias from the DNS entry for your production WebVoyage server and add it to the DNS entry for your SCOPAC server. It is also a good idea to add a short blurb to the WebVoyage header file (or a link to page explaining about the upgrade) so that users are alerted to the fact that the data may be stale. 
|
|
||||||||||||||||||||||||
