Implementing a Stand-Alone Continuous OPAC

1. Implementing aStand-Alone Continuous OPAC EndUser – Session 41 Michael Doran University of Texas at Arlington http://rocky.uta.edu/doran/scopac/

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

3. Continuous OPAC using a mirrored disk array(per Endeavor’s guidelines)

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

5. Stand-Alone Continuous OPAC

6. 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. Prerequisites – Continuous OPAC

7. Prerequisites – Stand-Alone • 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.

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

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

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

11. Acronyms The following acronyms will be used in order to avoid repeating these two mouthfuls. VDBS - Voyager Database ServerSCOPAC - Stand-alone Continuous OPAC Server

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

13. 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. Create Users and Groups

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

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

16. Required Voyager database files /m1/oracle /app/* /data/* /oradata/* /tmp/* /m1/voyager /bin/* /imagedb/* /xxxdb/* /utility/* /tmp/*

17. Configuration on SCOPAC • Unix system files • Oracle system files • Voyager configuration files

18. Unix system files • /etc/inet/inetd.conf • /etc/inet/services • startup scripts • /etc/init.d/dbora • /etc/init.d/voyager • /etc/system

19. /etc/inet/inetd.conf # # Voyager Entries -- PRODUCTION DATABASE # Popacsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Popacsvr Popacsvr Pcatsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcatsvr Pcatsvr Pacqsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pacqsvr Pacqsvr Pcircsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcircsvr Pcircsvr Prptsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Prptsvr Prptsvr Pmediab stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pmediab Pmediab Pfilesvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pfilesvr Pfilesvr Pkeysvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pkeysvr Pkeysvr Psysadminsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Psysadminsvr Psysadminsvr Pcallslipsvr stream tcp nowait voyager /m1/voyager/xxxdb/sbin/Pcallslipsvr Pcallslipsvr Pscansvr stream tcp nowait voyager /m1/voyager/imagedb/sbin/Pscansvr Pscansvr Pzrouter 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>

20. /etc/services Popacsvr 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

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

22. Oracle system files • Create a symbolic link ln –s /m1/oracle /oracle • Copy over from VDBS /usr/local/bin/oraenv /usr/local/bin/dbhome • Edit listener.ora tnsnames.ora initLIBR.ora

23. listener.ora and tnsnames.ora cd /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))

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

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

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

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

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

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

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

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

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

33. 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!)

34. Before (and after) the upgrade

35. During the upgrade

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