Implementing aStand-Alone Continuous OPAC

EndUser – Session 41Michael Doran

University of Texas at Arlingtonhttp://rocky.uta.edu/doran/scopac/

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 officially sanctioned approach requires multiple channels connecting the database (on a mirrored disk array) to both the Voyager database server and the Continuous OPAC server.

Endeavor Support Web: http://support.endinfosys.com/cust/voy/upgrade/copactheory.html

Continuous OPAC using a mirrored disk array

(per Endeavor’s guidelines)

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.

Stand-Alone Continuous OPAC

Prerequisites – Continuous OPAC1. At least two independent servers must be available during the upgrade. 2. The alternate OPAC server must be large enough to support the expected

OPAC load during the upgrade period. 3. Both the production server and the alternate OPAC server must be running

the same version of the operating system. 4. 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.

5. The alternate OPAC system must contain an appropriate controller capable of interfacing with the detached mirror of the production server.

6. The site must complete the Endeavor Information Systems certification classes.

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

Prerequisites – Stand-Alone

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.

Important Note

This tutorial is for system administrators with significant Solaris and Voyager experience. Some steps are described in general terms with the expectation that the sysadmin will be able to fill in the details and also understands the ramifications involved. Care should be exercised when editing Unix system files and restoring data from backups.

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

• Separate server (e.g. application server) to serve as SCOPAC Same operating system as VDBS (e.g. Solaris) Sufficient disk space (preferably a dedicated disk) Apache web server software installed and configured

Create Users and Groups

Voyager

User Groups

Name UID shell Primary GID Secondary GID

oracle 100 ksh endeavor 102 dba 101

voyager 102 ksh endeavor 102 dba 101

library 102 rksh endeavor 102

Note: These are our UIDs/GIDs - yours may be different.

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

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.

Required Voyager database files

/m1/oracle /app/* /data/* /oradata/* /tmp/*/m1/voyager /bin/* /imagedb/* /xxxdb/* /utility/* /tmp/*

Configuration on SCOPAC

• Unix system files

• Oracle system files

• Voyager configuration files

Unix system files

• /etc/inet/inetd.conf

• /etc/inet/services

• startup scripts /etc/init.d/dbora /etc/init.d/voyager

• /etc/system

/etc/inet/inetd.conf

## Voyager Entries -- PRODUCTION DATABASE#Popacsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Popacsvr PopacsvrPcatsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcatsvr PcatsvrPacqsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pacqsvr PacqsvrPcircsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcircsvr PcircsvrPrptsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Prptsvr PrptsvrPmediab stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pmediab PmediabPfilesvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pfilesvr PfilesvrPkeysvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pkeysvr PkeysvrPsysadminsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Psysadminsvr PsysadminsvrPcallslipsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcallslipsvr PcallslipsvrPscansvr stream tcp nowait voyager /m1/voyager/imagedb/sbin/Pscansvr PscansvrPzrouter stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pzrouter Pzrouter

Don't forget to send the inetd daemon a hangup signal so that it will reread the edited config file: # ps -ef | grep inetd root 162 1 0 Feb 13 ? 0:03 /usr/sbin/inetd -s -t# kill -HUP <pid>

/etc/servicesPopacsvr 7000/tcp # OPAC Server

Pcatsvr 7010/tcp # Cataloging Server

Pacqsvr 7020/tcp # Acquisitions Server

Pcircsvr 7030/tcp # Circulation Server

Prptsvr 7040/tcp # Reporting Server

Psysadminsvr 7050/tcp # System Administration Server

Pkeysvr 7060/tcp # Keyword Server

Pfilesvr 7070/tcp # File/Abstracts Server

Pcallslipsvr 7080/tcp # Request server

Pscansvr 7081/tcp # Scandoc server

Pmediab 7085/tcp # Media Scheduling server

Pz3950svr 7090/tcp # Z39.50 Server

Pzrouter 7091/tcp # Z39.50 Client Router

Piasock 7090/tcp # Image Server File Manager

/etc/system* Memory settings for Oracle for Voyager Continuous OPAC

set semsys:seminfo_semmap=10

set semsys:seminfo_semmni=400

set semsys:seminfo_semmns=4000

set semsys:seminfo_semmnu=400

set semsys:seminfo_semmsl=400

set shmsys:shminfo_shmmax=2047000000

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmmni=400

set semsys:seminfo_semume=10

forceload: sys/semsys

forceload: sys/shmsys

set slowscan=600

* End of memory settings for Oracle for Voyager Continuous OPAC

Oracle system files

• Create a symbolic link

ln –s /m1/oracle /oracle

• Copy over from VDBS

/usr/local/bin/oraenv

/usr/local/bin/dbhome

• Editlistener.ora

tnsnames.ora

initLIBR.ora

listener.ora and tnsnames.oracd /m1/oracle/app/oracle/product/8.0.5/network/admin/

# diff listener.ora.scopac listener.ora.vdbs

10c10

< (ADDRESS= (PROTOCOL= TCP)(Host= scopachost)(Port= 1521))

---

> (ADDRESS= (PROTOCOL= TCP)(Host= vdbshost)(Port= 1521))

# diff tnsnames.ora.scopac tnsnames.ora.vdbs

14c14

< (ADDRESS = (PROTOCOL= TCP)(Host= scopachost)(Port= 1521))

---

> (ADDRESS = (PROTOCOL= TCP)(Host= vdbshost)(Port= 1521))

initLIBR.ora# diff initLIBR.ora.scopac initLIBR.ora.vdbs

89c89

< spin_count = 2000 # = 2000 + ((#CPUS -1) *1780) or 2000 if only one CPU

---

> spin_count = 10900 # = 2000 + ((#CPUS -1) *1780) or 2000 if only one CPU

91,92c91,92

< log_simultaneous_copies = 2 # 2 * # CPUS

< db_block_lru_latches = 2 # 2 * # CPUS

---

> log_simultaneous_copies = 12 # 2 * # CPUS

> db_block_lru_latches = 12 # 2 * # CPUS

Note that these CPU-dependent parameters are obsoleted in Oracle9i.

Merge files from WebVoyage server

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.

Voyager config files – opac.ini

• /m1/voyager/xxxdb/etc/ascopac/opac.ini

# diff opac.ini.scopac opac.ini.vdbs

2c2

< Server=scopachost

---

> Server=vdbshost

5c5

< FileServer=scopachost

---

> FileServer=vdbshost

Voyager config files – voyager.ini

• /m1/voyager/xxxdb/etc/webvoyage/voyager.ini

# diff voyager.ini.scopac voyager.ini.vdbs

7c7

< Server=scopachost.yourdomain.edu

---

> Server=vdbshost.yourdomain.edu

10c10

< FileServer=scopachost.yourdomain.edu

---

> FileServer=vdbshost.yourdomain.edu

Ensuring read-only access

Method 1   Turn off any WebVoyage buttons that patrons would use to access their information by commenting out the appropriate lines in the opac.in file. If you have implemented MyOPAC, this method may be more complicated and may involve additional configuration files.

Ensuring read-only access

Method 2   Set the Oracle xxxdb tablespace to read-only within the Oracle Server Manager utility. This is what Endeavor recommends so contact support for more information.

SVRMGR> alter tablespace xxxdb read only

Ensuring read-only access

Method 3   Mount the /m1 filesystem disk read-only. This method is only mentioned so that it can be ruled out as a possibility. It should not be used, since it may cause Oracle to abort on start up.

Testing

You definitely want to test SCOPAC functionality before it is actually needed. 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.

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.

Do the same for your VDBS server alias if you will be allowing staff module access to SCOPAC.

About aliases

A server on a network typically has an IP address and a hostname. In TCP/IP networking, a name service such as DNS resolves the hostname to the server's IP address. An alias is an additional name that also resolves to that IP address.

Why use an alias if the server already has a perfectly good hostname? By associating a particular alias with a service, that service (and all client requests for that service) can then be tranferred from one physical server to another simply by changing two DNS entries. (And assuming that the service runs on both servers, naturally!)

Before (and after) the upgrade

During the upgrade

One last thing…

It is 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.