Current Voyager Version

Only customers running Voyager with Oracle 11.2.0.1 and later can run the VIK. To check your version of Oracle, as the voyager user, enter the following command:
sqlplus -v
If you are running Voyager versions prior to 8.2 and/or Oracle 11.2.0.1, you cannot run the VIK. Schedule an Ex Libris Installation Engineer to run the upgrade. Use the Support Portal to open an incident to schedule the upgrade. Under the What type of difficulty are you experiencing? field, select Upgrade.

Extension Modules

Review the list of Voyager extension modules below. There are some extension modules that are not upgraded via the VIK; and therefore, you should schedule the upgrade with Ex Libris.

Server Types

There are the following predefined server types:

1. Single‐server installation (Oracle + App + Web)
2. Oracle and application server (Oracle + App)
3. Oracle‐only server
4. Voyager application and Web server (App + Web)
5. Voyager application‐only server
6. Web server

If your server is not one of these predefined server types, the VIK may not configure your server correctly. Contact the installation team for more details on whether you should use the VIK. Proceeding without advice may result in a non‐working environment since your configuration may not be supported or is untested with the VIK.

Access to the server

You must have root access to the server(s). sudo permissions for root may satisfy this requirement, but only if they permit the user to run arbitrary shell commands.

System Requirements

Before installing Voyager, verify that all operating system components comply with the Voyager requirements as outlined in the Voyager Installation and Upgrade Requirements document located in the Ex Libris Documentation Center.

Licensing

Before running the VIK, you must have a Voyager License Key. All, or at least nearly all, Voyager servers should already have a license key installed. The VIK will automatically read your key if it is present. If you are none-the-less prompted for a key, Open an Ticket via the Support Portal to request your Key. Under the What type of difficulty are you experiencing? field, select Upgrade. The Licensing Manager sends you a long string of characters (this is your Key). The VIK prompts you to enter the Key. Make sure to paste in the whole string including any final symbols. This authorizes and properly tunes your system.

Backup

It is required that a full, cold‐tape working backup of the Voyager system be performed prior to beginning the upgrade process. While the VIK has the ability to perform a backup, this backup allows an immediate rollback of an inoperable system. The VIK backup tool is optional since it requires available space on the local system.

Categories of VIK Problems

Because the VIK was designed to be modular and flexible, you can safely exit and restart it without losing the state of your work. If you run into a problem or question when using the VIK, see the following categories that they can fall into:

• Pre Installation Problems
  All of the pre-installation tasks, including checks, downloads, and backups, can be done at any time. If they fail, they can be retried. If there is a problem, the Voyager system is still running, and, at worst, the upgrade has to be delayed. This includes all items in the VIK until Apache and Voyager are stopped (4.2 and 4.3) except for step 3 Create/Restore Backup. Step 3 requires stopping and starting Voyager and/or Oracle.
• Installation Problems
  Once Apache and Voyager are stopped, any problems running the VIK or its component scripts have the potential to prolong the downtime and prevent the system from being used.

Support for the VIK Problems

See the following description of support provided for VIK problems:

• Pre-installation Problems
  If you experience a pre-installation problem, open an ticket via the support portal as you would with other Voyager problems or questions. These tickets fall under the standard Level 3 or 4 as outlined in the Ex Libris Service Level Agreement.
• Installation Problems

  If you experience an install problem that renders your system down during the standard hours of 7am to 7pm (Central), open a Down System SI and call the Support line, 877‐445‐5693.

  If the problem occurs outside of the support hours, open an ticket and use the VIK Restore feature to roll back the upgrade to the previous version. The problem can then be addressed when the office opens.

The Importance of Backing Up

very Voyager system must have a tested working backup and recovery system. When using the VIK, it is especially important to have a full backup and a plan for restoring before starting an upgrade.

The VIK Menu

Each section and task in the VIK has an associated number. In the menu, you can enter that number to go to a section or start a task. Entering q takes you up a level or exits the VIK from the main menu.

It is safe to exit and rerun the VIK. It remembers what has been completed. Also, if something unexpected happens, exit the VIK and restart where you left off. You canʹt hurt anything if you restart. Below is an example of a VIK menu.

Result Codes

Upon completing the steps in the VIK, the status of a step change displays.

• OK
  The step completed successfully.
• FAILED
  An issue occurred. More details about the error can be found in the installation log.
• IN‐PROCESS
  This is used during the client download portion of the VIK. This step can be rerun periodically since it is waiting for the status of processes on the server to change to OK or FAILED.
• SKIP
  This means that the step can be skipped, and you can move on to the next step. If you run the step anyway, it reports back to you that it should be skipped.
• ?
  An abnormal exit occurred. This could result from exiting a step prematurely or from an undetermined status of a step. Run the step again.
• -
  The minus sign (‐) means that the step has not been run and needs to be run prior to proceeding to the next step.

If all the steps in a section are OK, press the Enter key to get to the next section. See below for an example:

Supply a Value or Press Enter

Many times in the VIK, you are asked to supply a value. If there is an option inside square brackets, or sometimes parentheses, you can press Enter to accept that value instead of supplying a value. If you are unsure of a setting, this default value should be the safest option.

Be Patient While the VIK is Working

Some tasks in the VIK take time; and after starting one, you may not get any further feedback until it is done. We try to indicate if a task takes a while to complete so that you know that you can let it wait.

Re-Entering the VIK

If you exit/quit and want to get back into the VIK, from /m1/incoming/v1030/vik4 enter:
./ikit_menu

VIK Log

A single log file containing confirmation and feedback on the installation, the status of each step, and reporting errors is created. This log file is placed in /m1/incoming/v1030/vik4/log/voyager_installation.log.

After Completion

Upon completing the VIK, Voyager clients need to be installed on each PC that uses the new version of Voyager. You can find these clients on your Voyager server in /m1/voyager/clients/<version>. You must use a either an FTP or SFTP client depending your server’s configuration. The clients can also be found in the Ex Libris Documentation Center in the Implementation Guides section.

Customizations for Classic WebVoyáge are restored and work immediately following your upgrade.

If you are upgrading from a release of Tomcat WebVoyáge earlier than Voyager 8.0.0, customized skins are not restored and are not available for immediate use after the upgrade. Customizations to WebVoyáge must be applied manually. Use of the preview server is recommended prior to the upgrade. This helps ensure that downtime is minimal upon upgrading to your production environment. After the upgrade, backups of your customizations can be found in /m1/upgrade/<VERSION>/pre<VERSION>/voyager/<db>/tomcat/vwebv/context/vwebv/.

Refer to the Voyager Upgrade Release Planning section of the Ex Libris Documentation Center for documents (for each version) that identify the WebVoyáge files that have changed in the skin directories and a description of the changes in the skin files (WebVoyáge Changes to Skin Files).

To start or restart the VIK, do the following:

A single log file containing confirmation and feedback on the installation, the status of each step, and reporting errors can be found under /m1/incoming/v1030/vik4/log/voyager_installation.log.

The following main menu is used throughout the Voyager installation, outlining the main steps. The main menu has a header including the current date and operating system used.

1.1 Configuring the VIK Environment

This step sets up the environment for running the VIK. You are prompted to enter parameters such as e‐mail address, the FTP server to download the files, the local software repository directory, and other default values used throughout the VIK.

If at any point a variable is not defined or needs to be changed, this step can be rerun to change those parameters.

1.2 Pre-installation System Checks

This step checks that your environment meets the minimum requirements for the version of Voyager that you are upgrading to. It checks for a compatible OS release, sufficient disk space, memory and the presence of required packages. You should run this step on all servers in a multi‐server environment prior to continuing with the process you are performing.

If there are any warnings during the third‐party product checks, this is acceptable since the VIK upgrades the third‐party products that are not at the recommended version. This is much more important during the system check at the end of the installation.

During the extension modules checks, you may find "WARNING CHECK LICENSING FOR" with a list of databases specified. This means that the extension module seems to be partially installed according to the installation checks. It is safe to proceed since the VIK upgrades the components it finds. It also displays when this is run on a Web server since it cannot connect to the database to check schema for all of the extension modules.

At the end of the summary, the script determines if you are okay to proceed to the next version of Voyager. If for any reason the check script reports FAILED, you need to resolve any problems prior to continuing. This ensures that your system meets the requirements.

1.3 Create / Update the Site Information

This step creates the required site for the VIK to work properly. It automatically selects the local server for running the VIK.

You are prompted to Enter Customer Initials (no spaces). This is used along with your license key. Usually this should be automatically detected.

1.4 View Site

This step displays your Site Code as well as your server name. Press Enter and continue.

1.5 Create / Update the Server Information

Once the site is created, you move onto the creation of the server configuration. The user defines the IP, Fully Qualified Domain Name (FQDN), hostname, and so on. This process sets up the VOYAGER_BASE, where Voyager is installed, and other configurations specific to a Voyager server.

There are six predefined server types:

1. Single Server Installation (Oracle + App + Web)
2. Oracle and Application Server (Oracle + App)
3. Oracle Only Server
4. Voyager Application and Web Server (App + Web)
5. Voyager Application Only Server
6. Web Server

The VIK will automatically try to determine which type your server is. Verify that the VIK has chosen the correct server type. Press return to select the server type the VIK has chosen, or select a different server type.

1.6 View the Server(s) Information

This step displays the server that is currently configured for the VIK. To change any of the values you need to run the Create/Update the server information step.

1.7 Create the exlibris Group

This step creates the exlibris unix group if it does not exist.

1.8 Create the dba Group

This step creates the dba unix group if it does not exist.

1.9 Create the oracle User

This step checks or creates the oracle unix user for managing the oracle software with the user home of /home/oracle. The user shell is /bin/ksh.

When creating the new user, if needed, you are prompted for a new unix password.

1.10 Create the voyager User

This step checks or creates the voyager unix user for managing and using the voyager software with the user home of /home/voyager. The user shell /bin/ksh.

When creating the new user, if needed, you are prompted for a new unix password.

1.11 Run Pre-installation Setup

This step checks the permissions setup of required directories for the VIK to perform a successful installation.

1.12 Install Voyager License

Before running the VIK, you must have a Voyager License Key. If you have not done so already, open an ticket via the Support Portal to request your Key. The Licensing Manager sends you a long string of characters (this is your Key). The VIK prompts you to enter the Key. Make sure you paste in the whole string including any final symbols. This authorizes and properly tunes your system.

1.13 Run OS Tuning Setup

This step checks the system for values used for tuning your voyager system. If the values are not correct, the step updates the values appropriately.

2.1 Download the FTP Configuration File

Enter the number 1 to download the latest version of the configuration file used for downloading the Voyager, Oracle, and third‐party software.

The target directory on your local server is the location configured in 1.1 Configuring the VIK Environment. If you need to change the location of the target directory, do so in that step

An e‐mail message is sent to the address you entered when the FTP download is started and completed.

2.2 Download Oracle Software

The next step is to download the Oracle software.

2.3 Download Oracle Critical Patch Update

This step downloads the Oracle Patch Set Update

2.4 Download Voyager Software

The next step is to download the Voyager software.

2.5 Download Voyager Extension Modules

The next step is to download the Voyager extension modules.

2.6 Download the Voyager Service Pack

To continue downloading the Voyager software, you need to download the most recent service pack released, if a service pack has been released.

2.7 Download the Third-Party Products

This step downloads the latest set of third party products used with Voyager. These include Apache httpd, Perl and Tomcat.

2.8 Download Voyager Hot Fix

This step downloads the most recent hot fix that applies to the version of Voyager that you are upgrading to, if one is available.

2.9 Check for Completion of Downloads

This steps checks for the completion of the Voyager software, Voyager third‐ party software, Voyager extensions software, and service pack downloads.

2.10 Check for the Successful/Correct Download of the Oracle Software

This step checks the checksum of the Oracle software downloaded with a known correct size of the packages. If you encounter any problems with the download and you cannot resolve the problem yourself, contact your local support office.

2.11 Check for the Successful/Correct Download of the Oracle CPU

This step checks the checksum of the Oracle critical patch update software downloaded with a known correct size of the packages. If you encounter any problems with the download and you cannot resolve the problem yourself, contact your local support office.

2.12 Check for the Successful/Correct Download of the Voyager Software

This step checks the checksum of the Voyager software downloaded with a known correct size of the packages. If you encounter any problems with the download and you cannot resolve the problem yourself, contact your local support office.

2.13 Check for the Successful/Correct Download of the Voyager Extension Modules

This step checks the checksum of the Voyager extension module software downloaded with a known correct size of the packages. If you encounter any problems with the download and you cannot resolve the problem yourself, contact your local support office.

2.14 Check for the Successful/Correct Download of the Voyager Service Pack(s)

This step checks the checksum of the Voyager service pack software downloaded with a known correct size of the packages.

2.15 Check for the Successful/Correct Download of the Third-Party Products

This step checks the checksum of the third‐party software downloaded with a known correct size of the packages. If you encounter any problems with the download and you cannot resolve the problem yourself, contact your local support office.

2.16 Check for the Successful/Correct Download of the Voyager Hot Fix

This step checks that the Voyager hot fix software was downloaded completely and correctly.

4.1 Extract the Third-Party Software

This step extracts the third party package files into the local software repository (LSWR). This means that the files are ready to install as soon as Voyager and Apache are shut down.

4.2 Stop Voyager Software

This step stops the Voyager software. Since Voyager is actively using the third party packages, it must be shut down before the VIK can upgrade those packages. This is also a pre-requisite for upgrading the Voyager application in menu 6.

4.3 Stop Apache Software

This step stops the Apache httpd. This is required so that the Apache httpd can be upgraded. It also prevents connections from being made to the Voyager software via the web. This is also a pre-requisite for upgrading the Voyager application in menu 6.

4.4 Install/Upgrade the Third-Party Software

This step installs the latest approved versions of the Apache httpd, Perl, Tomcat and OpenSSL. It installs or upgrades the appropriate OpenJDK system packages from Red Hat for your Voyager release. The Apache httpd configuration and logs are preserved and updated as necessary for the new software versions.

4.5 Configure the Third-Party Software

This step finishes the upgrade of third party packages in /m1/shared. It corrects permission and file ownership issues under /m1/shared. Less secure Apache httpd SSL configurations are amended. New features are added to Apache httpd virtual hosts if they are missing. Where the currently installed Voyager release is compatible with the newly installed Tomcat and Java versions, Voyager is configured to use the new packages. When the currently installed Voyager release is not compatible, you will see a WARNING in the VIK for those steps, but performing the Voyager upgrade in Menu 6 will make these new packages the active ones.

5.1 Shut Down Oracle

This step shuts down the Oracle database. This makes sure that there will be no further connections to the database, which would interfere with the upgrade. Doing so also ensures that the status of the Oracle database is under control of the VIK, rather than the operating system's facilities.

5.2 Disable Oracle Archive Logging

This step records the status (enabled / disabled) of Oracle archive logging in the VIK. If archive logging is enabled, it disables it. The original status is restored after your Voyager upgrade, in menu 7 step 5.

5.3 Backup Voyager Schemas

This step records information about your current Oracle data file layout, Oracle listener configuration, and database tuning. It does an Oracle data pump export of your Voyager data (and in most cases your read-only users) and saves this data under /m1/upgrade/<Voyager Release>/pre<Voyager Release>/oracle/voyager_backups.

5.4 Archive the VGER Database

This step archives your Oracle database files (usually /oracle/oradata/VGER) to /m1/upgrade/<Voyager Release>/pre<Voyager Release>/oracle/oradata/VGER, and then compresses them.

5.5 Create and prepare required directories

This step creates various Oracle relevant directories under /oracle and ensures that the permissions on all relevant files and directories are appropriate.

5.6 Extract the Oracle software

This step extracts the new Oracle RDBMS binaries and data files on your server in their appropriate locations

5.7 Add Oracle new ORACLE_HOME to the Oracle Inventory

This step creates or updates the Oracle Inventory catalog, to enable database maintenance and patching features. It also re-links the Oracle RDBMS binaries against the system libraries for compatibility.

5.8 Update OS Files and Permissions

This step runs the $ORACLE_HOME/root.sh script, which creates /usr/local/bin/oraenv, /usr/local/bin/coraenv, and /usr/local/bin/dbhome. It also does some post‐inventory cleanup of files and permissions.

5.9 Migrate Oracle Configuration Files

This step copies the Oracle network configuration files to your new Oracle RDBMS install. The files are updated for security, revised tuning parameters, and compatibility.

5.10 Update oratab, Oracle user .profile

This step updates the oracle user's login .profile and the system /etc/oratab file with the path to the new Oracle RDBMS install. The path that is set in /etc/oratab is the true absolute path to the new Oracle install. Symbolic links are expanded.

5.11 Migrate spfile to the new ORACLE_HOME

This step migrates your existing Oracle database tuning to the new RDBMS install. Parameters may be updated for compatibility, and to ensure the smooth completion of the following steps.

5.12 Test Oracle startup

Start the new database for the first time. This makes sure that we've successfully performed the tasks in steps 5.5 - 5.11.

5.13 Extract Oracle Patches

Oracle releases quarterly patch packages for the Oracle RDBMS. These patches include various functionality and security fixes for the database. Ex Libris qualifies these packages for Voyager no less often than twice a year. This step prepares the patch set which you downloaded in menu 2 for installation on this server.

5.14 Install the Oracle Patch Set Update

This step updates the Oracle binaries with the Oracle Patch Set Update package, and records the patch information in the Oracle Inventory.. This is the first half of the RDBMS patching process.

5.15 Patch the Oracle Catalog for PSU

This step updates the Oracle Catalog (the contents and structure of the database) with the Patch Set Update package. This is the second half of the RDBMS patching process.

5.16 Recompile Invalid Oracle Objects

Various activities performed above may have invalidated objects in the Oracle Catalog. This step recompiles the invalid objects, to ensure that the database performance is consistent when it needs those objects next. The database is then shut down to ensure that everything is consistent.

5.17 Start Oracle

Start the freshly patched database in order to continue the upgrade process.

5.18 Recreate Tablespaces

This creates new data files in Oracle to hold the Voyager data.

5.19 Populate Oracle with Voyager Data

Load the Oracle Data Pump export files from the old database (step 5.3) into the new database.

5.20 Update Voyager Application ORACLE_HOME

Configure Voyager to use the new Oracle RDBMS install.

5.21 Run Post Import processing

This creates or re-creates indexes which may not be properly migrated to the new Oracle RDBMS.

5.22 Fix Oracle Catalog Permissions

This step performs extensive clean-up and permission adjustment in the Oracle catalog. Old log files are removed from /oracle/app/oracle/diag and logging structures are updated for compatibility with the new database.

5.23 Tune Oracle

With the database installed, patched and populated, this step tunes database parameters appropriate to your data size, server configuration and Voyager best practices.

5.24 Check Voyager Tablespace Size

Since the size of the data in Oracle may have grown substantially since the last upgrade, this step checks that the database has at least 20% space available for growth in each Voyager tablespace. If less space is available, this step offers to create additional data files.

6.1 Extract the Voyager Software

This step extracts the Voyager packages into the local software repository. This may take some time. The cursor blinks while the process is running. You are notified when it is complete.

6.2 Install the Voyager Software

Once the software is extracted, this step installs the new version of the Voyager binaries, libraries, upgrade scripts, and utilities into /m1/voyager. The files are installed into the respective directories separated by version such as /m1/voyager/bin/<version>. This may take some time. The cursor blinks while the process is running. You are notified when it is complete.

6.3 Configure the Upgrade

This step walks you through selecting the databases you need to upgrade on this server.

From this step forward the only databases that are available for processing are the databases selected in this step. To change the databases to work with, you must revisit this step and change the database selection(s). You must reselect the databases that were previously selected if you want to work with them again.

Once the databases have been selected, the VIK aggregates critical data for each database. Record counts, database port series, username and password, and database type.

6.4 View Configuration and Integrity Check

This step shows you the databases you selected and the important information gathered in the previous step. Additionally this step checks for any inconsistencies in the voyager database. It checks the integrity of several different tables that have had issues in the past. It also ensures that any upgrade‐specific issues are caught and brought to the attention of the person performing the upgrade.

6.5 Back up Voyager Permissions

This step takes a snapshot of the permissions found in /m1/voyager prior to the upgrade. This can be important for institutions that use specific permissions based on distributed tasks.

6.6 Prepare the Upgrade

This step prepares to upgrade your database. New xxxdb directories are created in the vik working directory for each database. Database upgrades are configured based on the type of server on which the VIK is run.

6.7 Upgrade Voyager (xxxdb) Extension Modules

This step examines your database and ensures that extension modules found and supported by the VIK are upgraded and working after the completion of the VIK.

6.8 Restore Voyager (xxxdb) Custom Files

This step copies your reports, Tomcat skins, and some other custom files from each xxxdb in /m1/voyager to the new xxxdb directories created by step 6.6. If the restoration fails due to insufficient space, clean up unnecessary files in xxxdb/rpt, xxxdb/local, xxxdb/edi, and any old Primo exports under xxxdb/primo. You may then re‐run this step.

6.9 Upgrade Voyager (xxxdb) directory

This step archives your existing xxxdb directories to /m1/upgrade/version/pre<Version>/voyager/xxxdb. It then installs the new xxxdb directories from vik4/work created in step 6.6 and configured in steps 6.8 and 6.9.

6.10 Upgrade the Voyager (xxxdb) Schema

This step applies the database schema changes and configuration adjustments required to update each Voyager xxxdb from its previous version to the new version.

6.11 Apply the Service Pack

This step runs the service pack that was downloaded during step 2.4. The service pack applied is the latest service pack available. If another version of a Voyager service pack is preferred, this service pack must be downloaded and executed manually.

6.12 Apply the Hot Fix

If a hot fix was downloaded by step 2.8, this step runs this hot fix. If a Service Pack was downloaded, this step depends on the successful completion of step 6.13. The hot fix provided will not apply to an older or newer version. Additional hot-fix activities may be performed in addition to the hot fix package downloaded in step 2.8

6.13 Check / Setup Authority Heading Index(es)

To ensure that Authority Headings Keyword is configured and working, this step ensures that the necessary Oracle objects are in place. If it does not find the required objects, it sets them up for you.

6.14 Setup Voyager Regens

This step sets up the necessary regens by identifying the version of Voyager from which you are coming and to which you are upgrading.

6.15 Run Voyager (xxxdb) Regens

Due to database schema changes during the upgrade, bug fixes, and the passage of time, a full index regeneration is required at upgrade time. This ensures that your indexes are structured correctly and that Voyager is in the best possible condition. This step runs the required regens necessary to have the data changes appropriately propagated throughout the database.

For a list of the required regens, refer to the Voyager Road To guide and locate the version of Voyager from which you are upgrading.

The regen times for any given database can vary greatly based on the size of the database, the performance of the hard disks, and the types of regens performed.

During this step, all databases selected have their regens performed. You receive a progress meter for each database and its regen being performed. The VIK performs all regens for a single database. When it has completed, it continues to the next database until the regens have been completed for all databases.

Each index regen is run in the background. If your connection to the server fails, you can follow the progress of the current regen by tailing the file /m1/voyager/utility/version/xxxdb/regen.xxxdb.log. You will then have to manually run any remaining index regens.

Once all database regens have been completed, you return to the VIK menus. You are not able to proceed with the VIK until control is returned to the VIK menu.

6.16 Run Voyager (xxxdb) DBCompare

This step compares the current Voyager schema with a known schema provided by Ex Libris. If it finds any views missing or indexes, this utility attempts to fix them. It reports if it was successful or a failure. If it reports a failure, contact Ex Libris Support immediately for further analysis.

6.17 Tune Voyager Application

This step tunes the Voyager application to the recommended standard. It ensures that WebVoyáge meets the minimum recommended tuning levels.

7.1 Install the Updated Profiles for Voyager and Oracle Users

This step installs the updated user profiles for the Voyager and Oracle users. With a new release, changes to these files are possible. It is important to ensure that you have the latest .profiles installed.

If your institution has any customizations set up in either profile you need to ensure you update the user .profiles with your custom settings and configurations.

7.2 Restore Voyager Permissions

This step restores the permissions snapshot that was taken in menu 6 step 5. If the snapshot was not taken, it cannot restore permissions.

7.3 Install / Upgrade the Start / Stop Scripts

This step creates the main startup/shutdown scripts in the /etc/init.d/ directory if required. Refer to Chapter 3 of the Technical Userʹs Guide for more information regarding startup/shutdown scripts.

Required links for automatic startup and shutdown of Voyager and the database (when rebooting) are also created if necessary.

7.4. Update the Apache Configuration

This step updates or sets up a new Apache httpd configuration that must be done at the end of the upgrade.

7.5 Enable Oracle Archive Logging

If Oracle archive logging was enabled prior to the upgrade, this step re‐enables Oracle archive logging.

7.6 Start Apache

This step re-starts the Apache httpd server (stopped in menu 4). In some cases the VIK may not be able to completely maintain compatibility between your existing configuration and the new Apache httpd release. Pay close attention to any errors here. If the step fails, you may also find helpful error messages at the end of the /m1/shared/apache2/logs/error_log file.

7.7 Start Oracle

This step starts the Oracle RDBMS under control of the operating system if it is installed on this server.

7.8 Start Voyager

This step starts the Voyager services that are installed on this server.

7.9 Update the Utility Scripts

This step updates the /m1/utility directory with updated scripts and utilities. Most importantly it delivers the latest dailybackup script that is released for your operating system.

7.10 Set Up the System Statistics and Accounting

This step sets up of some statistics gathering and accounting. It helps Ex Libris evaluate how the application is performing and gives Ex Libris information for feature changes to the software.

7.11 Create/Recreate the Voyager (xxxdb) Read-Only Users

This step ensures that the read-only Oracle users, which are used for Microsoft Access, ODBC reports and certain other scripted activities, have complete read permissions on the Voyager database. The schema upgrade and index regeneration performed in Menu 6 of the VIK may have added new objects to the database, or revoked access to existing database objects. This step repairs those issues.

The step attempts to automatically determine the read-only users for each database. In most cases you may press return to accept the defaults and all read-only users will be refreshed. If you select 'n' at the prompt you can chose an alternate read-only user to refresh.

This step does not have any impact on the operation of the Voyager application. It may be re-run at any time with Voyager active.

7.12 Remove endeavor Group

This step cleans up the endeavor OS group from your server. It is rarely applicable on modern Voyager servers.

7.13 Cleanup Regen Directories

This step recovers additional space used during the full index regeneration during VIK menu 6. A number of semi-temporary files in /m1/voyager/utility/<VERSION>/*db are removed, while preserving log files which may asist Voyager support in case of difficulties.

7.14 Clean Up Local Software Repository

This step cleans up the local software repository directory. It deletes unnecessary files and packages that were extracted during the upgrade processes. The directory affected is /m1/incoming/v1030 or the local software directory defined in step 1.1. The files initially downloaded from Ex Libris are preserved in case they might be needed again.

7.15 Cleanup Old Voyager Binaries, Libraries, and Upgrade Files

This step deletes all binary, library, and upgrade files that have been left on the server from previous service packs, upgrades, and work performed by Ex Libris. It recovers space used by files no longer used by your Voyager application.

The directories affected are:

• /m1/voyager/bin/<OLDVERSIONS>
• /m1/voyager/lib/<OLDVERSIONS>
• /m1/voyager/utility/<OLDVERSIONS>

7.16. Uninstall Old Oracle Files

This step removes old installs of the Oracle RDBMS from the Oracle inventory.

7.17 Reboot the Server

This step reboots the server after the upgrade. Rebooting at this point makes sure that all of the Voyager relevant services will work on system startup. While this is not strictly required, Voyager support has found that it is far less stressful to address startup issues during a scheduled downtime, rather than immediately subsequent to an unscheduled outage at 3AM.

7.18 Run the System Check Script (Post Upgrade)

This step is run just like the step in the pre‐installation checks. This step is to ensure that all of the requirements are met and complete.

7.19 Test WebVoyage and List Regen Warnings

This step performs basic tests for OPAC functionality and ensures that results are returned. It also reviews the regen logs for anything that may need to be brought to your attention.