7 Upgrading to STA 2.3.x

This section provides instructions for upgrading any previously released version of STA to STA 2.3.0 and subsequent STA 2.3.x versions.

Note:

If you are installing STA for the first time, you should perform a new base installation; see Chapter 3, "Installing STA" for instructions.

• Important Information for Planning Your Upgrade

• Upgrade Paths for STA 2.3.0

• Understanding and Performing Automatic Upgrades

• Understanding Post-installation (Manual) Upgrades

• Preparation Tasks for All Upgrades

• Post-installation Upgrade Tasks

• Post-upgrade Configuration Tasks for All Upgrades

• Environment Changes for All Upgrades

• Environment Changes for Upgrades from STA 2.0.x and Earlier

Important Information for Planning Your Upgrade

Before beginning an upgrade, familiarize yourself with all upgrade information and identify the instructions that apply to your site.

During an upgrade, your existing STA data is transformed from the current STA version to the new one. Your existing STA database is not valid with the new version of STA until these transformations are done. After the upgrade, the STA application processes new data according to the new STA schema and analytic rules, and historical data is not reprocessed.

While you are performing the upgrade, STA does not receive exchange information from the monitored libraries. Also, the new version of STA does not begin receiving information from the libraries until after you have completed all upgrade and post-upgrade configuration steps, including testing the SNMP connection to each monitored library.

Be sure to allocate sufficient time for the entire process. Some upgrade preparation tasks may require you to coordinate with other groups at your site, such as network administration. You should have all preparation tasks done in advance so you can complete the upgrade itself in as little time as possible.

Appendix C includes worksheets you can use to organize your upgrade activities and record your settings.

Upgrade Paths for STA 2.3.0

The process for upgrading to STA 2.3.0 varies significantly depending on the STA version currently running at your site. See "Verify Upgrade Prerequisites" to determine your current STA version.

Caution:

Oracle highly recommends backing up your current STA database before beginning any upgrade, regardless of upgrade path. Backups are essential for restoring your database if an upgrade fails for any reason. See "Troubleshooting a Failed Upgrade" or "Recover a Failed Manual Database Upgrade (optional)".

Upgrades from STA 2.1.x or Later

The upgrade from the following STA released versions is an automatic upgrade. You must also be running Linux 6.6. See the STA Requirements Guide for details.

• STA 2.2.1.19.18

• STA 2.2.0.20.66

• STA 2.1.1.64.124

All data transformations and other infrastructure updates are performed automatically by the STA installer. Do not deinstall STA before performing an automatic upgrade. See "Understanding and Performing Automatic Upgrades" for details and instructions.

Upgrades From STA 2.0.x or Earlier

The upgrade from the following released versions is a post-installation upgrade, which is a manual process.

• STA 2.0.x

  • STA 2.0.1.4

  • STA 2.0.0.83

• STA 1.0.x

  • STA 1.0.2.24

  • STA 1.0.1.33

  • STA 1.0.0.99

You must deinstall your current version of STA, install the new STA version, and then run a supplied script to convert your existing data to the new version. See "Understanding Post-installation (Manual) Upgrades" for details and instructions:

Note:

If you are upgrading from STA 1.0.x, you must also install a new version of Linux before installing STA 2.3.x. See the STA Requirements Guide for details.

Understanding and Performing Automatic Upgrades

You can use an automatic upgrade if you are upgrading to STA 2.3.x from STA 2.1.x or later. See the following sections for full details and instructions.

• "Upgrade Paths for STA 2.3.0"

• "When to Perform an Automatic Upgrade"

• "Automatic Upgrade Process"

• "Troubleshooting a Failed Upgrade"

When to Perform an Automatic Upgrade

Automatic upgrades are possible when the underlying operating system, database, and installation framework are consistent from one version of STA to the next. For example, the upgrades from STA 2.0 to STA 2.0.1 and from STA 2.1.x, or STA 2.2.x, to STA 2.3.x are automatic upgrades.

In an automatic upgrade, the STA installer automatically handles all phases of the upgrade. The upgrade installer takes a snapshot of your current data, installs the new version of STA, and then upgrades your data to the new version. The upgrade installer automatically performs all necessary database transformations and infrastructure updates, such as updates to the WebLogic and MySQL servers.

Automatic Upgrade Process

Perform the following activities in the order listed.

1. Perform all preparation tasks that are applicable to your site. See "Preparation Tasks for All Upgrades" for details.

2. Back up the current STA database. See "Task 1: Dump the Old STA Database" for instructions. The automatic upgrade will also back up the current database, but Oracle highly recommends making your own backup before starting the process.

   Caution:

   Backups are essential for restoring your database if an upgrade fails for any reason; see "Troubleshooting a Failed Upgrade" for details.

3. Transfer the database backup to an off-platform backup server. See "Task 2: Transfer the Old Database Dump" and follow the instructions for a single-server upgrade.

4. Download the STA 2.3.x installer. See "Download STA".

5. Ensure that the iptables firewall service is running. Starting with STA 2.3.x, the iptables service must be running for the STA installer to set up required port configurations and for the STA application to support internal port forwarding for SNMP traps. See "Enable the Linux Firewall" for details.

6. Run the STA 2.3.x installer. It automatically detects that you are performing an upgrade and prompts you for all the information it needs to complete the process. See the following topics for details:

   • "Install STA"

   • "STA Graphical Upgrade Screens"

   • "Auto Upgrade Examples"

7. Perform all post-upgrade configuration tasks that are applicable to your site. See "Post-upgrade Configuration Tasks for All Upgrades" for details.

Troubleshooting a Failed Upgrade

If an automatic upgrade is manually interrupted or fails for any reason, the upgrade installer attempts to roll back any changes and return the STA server, application, and database to their original states.However, depending on your server environment and the reasons for the interruption, the rollback may not always be successful.

Oracle recommends taking the following actions after any interrupted or failed automatic upgrade.

1. Deinstall STA. See "STA Deinstallation Tasks" for instructions.

2. Optionally, delete any temporary files and directories that the upgrade installer may have left in the home directory of the Oracle user, some of which may be hidden. For example:

   $ cd /home/oracle
   $ ls -ld .tmp*
   drwxr-xr-x 2 oracle oinstall 27773 Jun 21 15:24 .tmp_staupgrade
   $ rm -rf .tmp_staupgrade/
   

3. Perform a post-installation (manul) upgrade, from Task 4 through Task 9. See "Task 4: Install the New STA Version".

4. Perform all post-upgrade configuration tasks that are applicable to your site. See "Post-upgrade Configuration Tasks for All Upgrades".

See the upgrade log for detailed information about any automatic upgrade issues. See "STA Installation, Upgrade, and Deinstallation Logs" for details.

Understanding Post-installation (Manual) Upgrades

You must use a post-installation upgrade if you are upgrading to STA 2.3.x from STA 2.0.x or earlier. See the following sections for full details and instructions.

• "Upgrade Paths for STA 2.3.0"

• "When to Perform a Post-installation Upgrade"

• "Choosing Whether to Use One Server or Two for Post-installation Upgrades"

• "Single-server Post-installation Upgrade Process"

• "Two-server Post-installation Upgrade Process"

• "Environment Changes for Upgrades from STA 2.0.x and Earlier"

When to Perform a Post-installation Upgrade

Post-installation upgrades are necessary in the following situations:

• The new version of STA requires a new version of Linux. For example, STA 1.0.x requires Linux 5, while STA 2.0 and subsequent versions require Linux 6; therefore, to upgrade to STA 2.0 or later from STA 1.0.x, a new version of Linux must be installed, which requires a post-installation upgrade.

• The STA installation framework has changed significantly. For example, the installer for STA 2.1.0 and subsequent versions use the Oracle Universal Installer framework; therefore, upgrading to STA 2.1.x or later from any previous version of STA requires a post-installation upgrade.

Choosing Whether to Use One Server or Two for Post-installation Upgrades

For post-installation upgrades, you can choose to use either one server or two, depending on your goals and available resources. Automatic upgrades are by nature always done on one server.

The upgrade tasks are largely the same for one- and two-server upgrades, but the tasks are performed in different orders. The two methods are described in the following sections:

• "Single-server Post-installation Upgrade Process"

• "Two-server Post-installation Upgrade Process"

Single-server Post-installation Upgrade Process

Using the single-server method, you must deinstall STA before you install the new version and upgrade the database on the same server. STA is not monitoring libraries while you perform this process.

This method offers the advantage of not requiring an additional dedicated server for the upgrade. If you are upgrading from STA 2.0 or later, you do not need to install a new version of Linux, so this method may be sufficient for your needs.

Single-server Upgrade Steps

Figure 7-1 illustrates the single-server method. You perform Task 1 through Task 9 in sequential order. The process is as follows.

1. Dump the current database (Task 1).

2. Transfer the database to a backup server for safekeeping (Task 2).

3. Depending on your current version of STA, either install Linux 6.x (Task 3a) or Deinstall STA 2.0.x (Task 3b).

4. Install STA 2.3.x (Task 4).

5. As a precaution, dump the new, empty database (Task 5).

6. Transfer the dump of the old database from the backup server to the new one (Task 6).

7. Load the old data into the new database (Task 7)

8. Upgrade the data to the new STA schema (Task 8).

9. Reestablish connections to the monitored libraries, and perform necessary manual configuration tasks (Task 9). Because the old version of STA must be deinstalled before you install STA 2.3.x, you must reenter some user configuration data manually.

Figure 7-1 Single-server Post-installation Upgrade Task Overview

Description of ''Figure 7-1 Single-server Post-installation Upgrade Task Overview''

Two-server Post-installation Upgrade Process

The two-server upgrade method requires a second dedicated STA server, but it offers the advantage of reduced STA application downtime. This method is especially useful if you are upgrading from STA 1.0.x, as the old version of STA can continue to monitor libraries on the old server while both Linux and the new version of STA are installed on the new server.

Even with this method, however, STA is not monitoring libraries while you upgrade the current database to the new STA version. The length of downtime depends on the size of your current database.

Two-server Upgrade Steps

Figure 7-2 illustrates the two-server method. Because you do not dump the old database until after you install the new version of STA, the order of the tasks is rearranged and Task 6 is omitted. The process is as follows:

1. Depending on whether the second server is currently running a version of STA, either install Linux 6.x (Task 3a) or deinstall the old version of STA (Task 3b).

2. Install STA 2.3.x on the new server (Task 4).

3. As a precaution, dump the new database (Task 5).

4. Dump the old database on the old server (Task 1).

5. Transfer the dump of the old database to the new server (Task 2).

6. Load the old data into the new database (Task 7).

7. Upgrade the old database to the new STA schema (Task 8).

8. Reestablish connections to the monitored libraries, and perform necessary manual configuration tasks (Task 9).

Figure 7-2 Two-server Upgrade Task Overview

Description of ''Figure 7-2 Two-server Upgrade Task Overview''

Preparation Tasks for All Upgrades

Note:

This section applies to both automatic and post-installation upgrades.

Perform the following tasks before starting the STA upgrade. Most of these tasks are optional, and Table 7-1 provides guidelines on when to use each one.

Table 7-1 Guidelines for When to Perform Upgrade Preparation Tasks

Task	When to Perform It
"Verify Upgrade Prerequisites"	All upgrades
"Verify Current STA Activity"	All upgrades
"Save Existing Logs (optional)"	You want to retain application logs and service log bundles from the current version of STA.
"Record Current STA User and Configuration Settings (optional)"	You want to retain current STA usernames and configuration settings.
"Rename Custom Templates With STA– Prefix (optional)"	You have custom templates with names prefixed "STA–".
"Record Current Custom Template Settings (optional)"	You want to retain the ownership and visibility settings for existing custom templates.
"Record Executive Report Policy Settings (optional)"	You want to retain the ownership settings for existing Executive Report policies.
"Record Logical Group Ownership Settings (optional)"	You want to retain the ownership settings for existing logical groups.

Verify Upgrade Prerequisites

Use this procedure to ensure that your environment meets all STA 2.3.x prerequisites.

1. Display your current STA version. Some upgrade tasks vary depending on the version of STA from which you are upgrading.

   1. Log in to STA using an STA administrator username.

   2. Click About in the Status Bar.

   3. Verify you are running a currently released version of STA. See "Upgrade Paths for STA 2.3.0" for details.

2. Choose whether you will be using the automatic or post-installation upgrade process. See "Upgrade Paths for STA 2.3.0" for details.

   • If you will be using the post-installation process, determine whether you will be using one server or two. See "Choosing Whether to Use One Server or Two for Post-installation Upgrades" for details.

3. Verify that your site and the target server meet STA 2.3.x requirements. See the STA Requirements Guide for details.

4. Ensure the /tmp file system on the target STA server has sufficient space for the upgrade. The size of /tmp should be at least as large as the size of your existing uncompressed STA database; a minimum of 4 GB is required, and for large databases, Oracle recommends you increase the size of /tmp to 32 GB, at minimum.

5. Review the environment changes relevant to your upgrade path, and make any necessary adjustments to your plan or environment. See "Environment Changes for Upgrades from STA 2.0.x and Earlier" for details.

6. Ensure that all required RPM packages are installed on the STA server. See "Install Required Linux Packages" for instructions. As a final check, the STA installer will also notify you if any packages are missing.

7. Review the file system structure on the STA server and verify that the required users and groups have proper access to the locations used by the STA installer. See "Recommended File System Layout" and "Users, Groups, and Locations Used by the STA Installer".

Verify Current STA Activity

Use this procedure to verify that your current STA environment is functioning normally.

1. Use the following steps to verify that the current version of STA has had recent, successful communication with each monitored library.

   1. Log in to STA as an STA administrator user.

   2. From the Setup & Administration tab, select SNMP Connections.

   3. Verify the following values in the Monitored Libraries table:

      • Recent SNMP Trap Communication Status—GOOD

      • Last Connection Status—SUCCESS

2. Use the following steps to verify that STA is processing exchanges across all libraries.

   1. From the Tape System Activity tab, select Exchanges – Overview.

   2. Select the Filter icon and filter for Exchange End (No. Days) Less Than 1.

   3. In the Table Toolbar, select View, then select Sort, then select Advanced. Sort by Drive Library Name, Drive Serial Number.

   4. Verify that all libraries have exchange activity.

Save Existing Logs (optional)

Existing application and service log bundles are not retained after the upgrade because you must deinstall the current version of STA or install a new version of Linux before installing STA 2.3.x. Use this procedure to save any logs you want to keep.

1. Locate any installation and database logs you want to retain, and move them to a safe place. Logs that may be of interest are located in the STA logs location you have defined for your installation. See "Review STA File System Layout" for details.

2. Use the following steps to create an RDA log bundle on the current STA installation. This step is optional but recommended, as Oracle Support can use the logs to troubleshoot any issues that may have existed before the upgrade.

   1. Log in to STA as an STA Administrator user.

   2. From the Setup & Administration tab, select Logs.

   3. On the Service – Logs screen, click the Create New Log Bundle icon.

   4. In the Create New Log Bundle dialog box, assign a bundle name and click Save. It may take several minutes for the process to complete.

3. Use the following steps to download the RDA log bundle you just created, as well as any others you want to retain. You must download the bundles one at a time.

   1. On the Service – Logs screen, select the bundle you want to download.

   2. Click the Download Selected Log Bundle icon.

   3. In the dialog box, specify the destination location and save the log bundle.

Record Current STA User and Configuration Settings (optional)

This section applies only if you want to retain current STA usernames and configuration settings in STA 2.3.x. Use these procedures to display and record the current values so you can reenter them for STA 2.3.x. You will reenter most of these values after the upgrade; see "Post-upgrade Configuration Tasks for All Upgrades" for details.

Record MySQL Usernames

Use this procedure to display and record existing MySQL usernames used to access the STA database. The STA installer will prompt you for these values. You cannot retrieve the passwords.

1. Open a terminal session on the current STA server, and log in as the Oracle user.

2. Display all STA database usernames by issuing the following query. Enter the database root user password when prompted. For example:

   $ mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql
   Enter password: password
   +--------+
   | user   |
   +--------+
   | root   |
   | staapp |
   | stadba |
   | starpt |
   +--------+
   

3. Record the usernames.

Record STA SNMP Client Settings

Use this procedure to display and record SNMP client settings for STA. You will reenter these values after the upgrade.

Note:

In the new version of STA, the SNMP values must match what is specified on the monitored libraries.

1. Start a supported Web browser on your computer and log in to STA using an STA administrator username.

2. From the Setup & Administration tab, select SNMP Connections.

   The Client Attributes table displays configuration settings for the STA SNMP client.

   
   Description of the illustration ''snmp_clientupgrade.png''
   
   

3. Record the values from the following columns:

   • SNMP Username

   • User Community

   • Trap Community

Record WebLogic Usernames—Upgrades from STA 1.0.x Only

For upgrades from STA 1.0.x, use this procedure to display and record existing WebLogic usernames used to log in to STA. You will reenter these values after the upgrade. You cannot retrieve the passwords.

Note:

Starting with STA 2.0, usernames are created and maintained through the STA user interface; see "Record STA Usernames—Upgrades From STA 2.0.x or Later" for instructions.

1. Start a supported Web browser on your computer and enter the URL of the WebLogic administration console.

   http(s)://STA_host_name:port_number/console/
   

   Where:

   • host_name is the hostname of the STA server.

   • port_number is the STA port number of the WebLogic administration console in the current STA version.

   • STA must be uppercase.

   For example:

   https://staserver.example.com:7002/console/ 
   

2. Log in using the WebLogic administration console username and password.

3. In the Domain Structure navigation tree, click Security Realms.

   
   Description of the illustration ''wl_secrealm.png''
   
   

   The Summary of Security Realms screen appears.

4. In the Name column, select the myrealm active link (do not select the check box).

   
   Description of the illustration ''wl_myrealm.png''
   
   

   The Settings for myrealm screen appears.

5. Select the Users and Groups tab.

   
   Description of the illustration ''wl_checkusers.png''
   
   

   The Users table lists the available usernames.

   
   Description of the illustration ''wl_userstable.png''
   
   

6. Record the usernames you want to retain.

Record STA Usernames—Upgrades From STA 2.0.x or Later

For upgrades from STA 2.0.x or later, use this procedure to display and record usernames used to log in to STA. You will reenter this information after the upgrade. You cannot retrieve the passwords.

Note:

For STA 1.0.x, usernames were created and maintained through the WebLogic administration console; see "Record WebLogic Usernames—Upgrades from STA 1.0.x Only" for instructions.

1. Log in to STA using an STA administrator username.

2. From the Setup & Administration tab, select Users.

   The Configuration – Users screen displays all STA usernames and their roles.

   
   Description of the illustration ''upgrade_users.png''
   
   

3. Record the usernames and roles you want to retain.

Record STA Email Server Settings

Use this procedure to display and record the STA email protocol and, if the email server requires authentication, the account username. You will reenter these values after the upgrade. You cannot display the password.

1. Log in to STA using an STA administrator username.

2. From the Setup & Administration tab, select Email.

3. In the SMTP Server Settings table, select the StorageTek Tape Analytics Alerts record, then click the Edit Selected SMTP Server icon.

   The Define SMTP Server Details dialog box appears.

   
   Description of the illustration ''email_smtpserverd.png''
   
   

4. Record the values from the following fields:

   • Use Secure Connection Protocol

   • Username

Rename Custom Templates With STA– Prefix (optional)

This procedure applies only if you have custom templates with names prefixed "STA-". During STA 2.3.x installation, all templates with the "STA–" prefix are deleted and replaced by new STA predefined templates.

Use this procedure to assign new names to the templates so they will be preserved during the upgrade.

Note:

STA predefined templates are prefixed "STA–"; therefore Oracle recommends that you not use this prefix when naming custom templates.

1. Log in to STA with an administrator username.

2. From the Setup & Administration tab, select Templates Management.

3. Sort the table by date Created/Updated, to focus on templates that have been modified since the STA installation date.

4. Select the text link of a custom template with name prefixed "STA-".

   You are taken to the screen with the selected template applied.

5. Click Save Template in the Templates Toolbar.

   The Save Template dialog box appears.

6. In the Template Name field assign a new name not prefixed "STA-". Your entry must be unique.

7. Click Save.

   The template is saved.

Record Current Custom Template Settings (optional)

This section applies only if you have custom templates. After the upgrade, all custom templates are preserved, but they are owned by the STA application ("STA") with public visibility.

Use this procedure to record the current ownership and visibility settings for all custom templates so you can restore them after the upgrade, if necessary. You can skip this procedure if template ownership and visibility are not critical to your implementation.

1. Log in to STA with an administrator username.

2. From the Setup & Administration tab, select Templates Management.

3. Select the Filter icon and filter the screen to show only templates not owned by STA—this will display custom templates only. The following example uses the Owner Isn't STA filter.

   
   Description of the illustration ''upgrade_filternotsta.png''
   
   

4. Record the current Owner and Public Visibility settings for each custom template. If you have many templates, you may want to take a screen shot.

Record Executive Report Policy Settings (optional)

This section applies only if you have privately owned Executive Report policies. After the upgrade, all Executive Report policies are preserved, but they are assigned public ownership.

Use this procedure to record the current ownership settings for all private policies so you can restore them after the upgrade, if necessary. You can skip this procedure if Executive Report policy ownership is not critical to your implementation.

1. Log in to STA using an STA administrator username.

2. From the Setup & Administration tab, select Executive Reports Policies.

3. Select the Filter icon and filter the screen to show only policies not owned by STA—this will display private policies only. The following example uses the Owner Isn't STA filter.

   
   Description of the illustration ''upgrade_rptnotsta.png''
   
   

4. Record the current Report Owner for each policy. If you have many policies, you may want to take a screen shot.

Record Logical Group Ownership Settings (optional)

This procedure applies only if you want post-upgrade logical group ownership to match the current assignments.

After the upgrade, all existing logical groups are preserved, but they are owned by the STA application ("STA"). Logical group ownership is not critical to STA functioning, and any STA user with Operator or Administrator privileges can modify logical groups; therefore, restoring the current ownership assignments is not essential. However, if you do want to restore the ownership assignments after the upgrade, use this procedure now to record the current settings.

1. Log in to STA using an STA administrator username.

2. From the Setup & Administration tab, select Logical Groups.

3. Record the current Logical Group Owner for each group. If you have many policies, you may want to take a screen shot.

Post-installation Upgrade Tasks

These tasks apply to post-installation (manual) upgrades.

Caution:

Only a Linux administrator and STA administrator should perform the upgrade. All tasks are required and must be performed precisely as written in the order specified, or data loss could result.

If you are using the single-server upgrade method, you perform the tasks in sequential order; see "Single-server Upgrade Steps" for the correct task order.

If you are using the two-server upgrade method, you do not perform the tasks in sequential order and Task 6 is omitted; see "Two-server Upgrade Steps" for the correct task order.

• "Task 1: Dump the Old STA Database"

• "Task 2: Transfer the Old Database Dump"

• "Task 3a: Install the New Linux Version—Upgrades From STA 1.0.x"

• "Task 3b: Deinstall the Old STA Version—Upgrades From STA 2.0.x"

• "Task 4: Install the New STA Version"

• "Task 5: Dump the New STA Database (optional)"

• "Task 6: Transfer the Old STA Database to the STA Server"

• "Task 7: Process and Load the Old STA Database"

• "Task 8: Upgrade the Old Database"

• "Recover a Failed Manual Database Upgrade (optional)"

Task 1: Dump the Old STA Database

Use this procedure to perform a full dump of the old (current) STA database.

1. Use the following steps to display the size of your current STA database.

   1. Log in to STA using an STA administrator username.

   2. Click About in the Status Bar.

   3. In the About dialog box, scroll down to where the Database Current Size is displayed, and record the value.

2. Use the following steps to verify that the location where you want to dump the database has sufficient space.

   1. Open a terminal session on the STA server and log in as the Oracle user.

   2. Display the space available in the database dump destination, and verify it is sufficient for the dump file. For example:

      $ df -h /dbdumpfiles
      Filesystem            Size  Used Avail Use% Mounted on
      /dev/mapper/sta_server-STA_DbVol
                            200G   53G   243G  27% /dbdumpfiles
      

3. Stop all STA services.

   $ STA stop all 
   

4. Start the MySQL service.

   $ service mysql start
   Starting MySQL. SUCCESS!
   

5. Dump the STA database into a single file. Enter the database root user password when prompted.

   $ mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
   Enter password: mysql_root_password
   

   Note:

   The optional –v parameter (for verbose output) is not recommended, as a large number of messages are displayed in the terminal window and it can significantly slow down the command process for large databases.

   In Example 7-1, the STA 2.1.x database is dumped into the /home/oracle folder on the STA server with filename Jan26_dump.sql.

   Example 7-1 Old Database Dump

   $ mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /home/oracle/Jan26_dump.sql
   
   Enter password: mysql_root_password
   ...
   -- Retrieving view structure for table v_library_complex_io...
   ...
   -- Retrieving view structure for table v_library_summary_averages...
   -- It's base table, skipped
   ...
   -- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
   ...
   -- Disconnecting from localhost...
   

6. To reduce the dump file size by approximately 50 percent, gzip the file. For example:

   $ cd /home/oracle 
   $ gzip Jan26_dump.sql
   

Task 2: Transfer the Old Database Dump

Use this procedure to transfer the compressed dump of the old STA database to either an off-platform backup server (single-server method) or the new STA 2.3.x server (two-server method).

Caution:

If you are upgrading from STA 1.0.x with the single-server method, you must back up the STA database to another server. Do not back up the database to a file system on the current STA server, as the Linux 6.x installation in "Task 3a: Install the New Linux Version—Upgrades From STA 1.0.x" will destroy all data on the server.

1. If you have not done so already, stop all STA services.

   $ STA stop all 
   

2. Perform a checksum before transferring the file to the backup server. For example:

   $ cksum /home/oracle/Jan26_dump.sql.gz
   2169286306 37 /home/oracle/Jan26_dump.sql.gz
   

   The output includes a checksum value and byte count. Record the checksum value; you will use it to verify the file integrity after transferring the file to the backup server.

3. Transfer the file to the target server using a transfer utility such as SCP. The –p option preserves timestamp values.

   $ scp -p dump_file target_host:/path/
   

   In Example 7-2, SCP is used to transfer the compressed database dump file Jan26_dump.sql.gz to the /dbdumpfiles folder on backup host backup1.The /dbdumpfiles folder already exists on the backup host.

   Example 7-2 Old Database Transfer to Backup Server (Single-server Method)

   $ cd /home/oracle
   $ scp -p Jan26_dump.sql.gz backup1:/dbdumpfiles
   

   In Example 7-3, SCP is used to transfer the compressed database dump file Jan26_dump.sql.gz to the /dbdumpfiles folder on STA 2.3.x host sta_new.

   Example 7-3 Old Database Transfer to New STA Server (Two-server Method)

   $ cd /home/oracle
   $ scp -p Jan26_dump.sql.gz sta_new:/dbdumpfiles
   

4. On the target server, perform a checksum of the transferred file. Verify that the checksum values match. For example:

   $ cd /dbdumpfiles
   $ cksum Jan26_dump.sql.gz
   2169286306 37 Jan26_dump.sql.gz
   

Task 3a: Install the New Linux Version—Upgrades From STA 1.0.x

Caution:

This activity destroys all data on the server. If you are using the single-server upgrade method, use this procedure only after you have performed "Task 1: Dump the Old STA Database" and "Task 2: Transfer the Old Database Dump".

This procedure applies only to upgrades from STA 1.0.x to STA 2.3.x. Install Linux 6.3 or later on the STA server; see Chapter 2, "Installing Linux" for instructions.

Task 3b: Deinstall the Old STA Version—Upgrades From STA 2.0.x

Caution:

This activity destroys all STA data on the server. If you are using the single-server upgrade method, use this procedure only after you have performed "Task 1: Dump the Old STA Database" and "Task 2: Transfer the Old Database Dump".

This procedure applies only to upgrades from STA 2.0.x to STA 2.3.x. Deinstall the current version of STA, as follows.

• 1. Log in as the system root user.

  2. Change to the STA 2.0.x installation directory.

     # cd /Oracle/StorageTek_Tape_Analytics_install
     

  3. Launch the STA deinstaller with one of the following commands:

     • To use the STA graphical deinstaller:

       # ./Uninstall_StorageTek_Tape_Analytics
       

       This mode requires an X11 display. See "STA Graphical Installer, Upgrade, and Deinstaller Screen Reference" for instructions.

     • To use the STA console deinstaller:

       # ./Uninstall_StorageTek_Tape_Analytics -i console
       

Task 4: Install the New STA Version

Use this procedure to install STA 2.3.x.

1. Install STA 2.3.x; see "Installing STA" for instructions.

2. To verify STA is working properly and complete the STA Administrator setup in WebLogic, log in to the STA application.

   The Dashboard is displayed.

   Note:

   Because the upgrade process is not yet complete, the Dashboard portlets display the message "No data to display"; this is normal. The library data will be displayed correctly after you upgrade the database and configure the new STA version.

3. Log out of STA.

4. Open a terminal session on the STA server and log in as the Oracle user.

5. Stop all STA services.

   $ STA stop all
   

6. For optimal SNMP security, Oracle recommends monitoring the libraries using the SNMP v3 protocol. Starting with STA 2.0, SNMP v2c is disabled by default. However, if you want STA to monitor the libraries using SNMP v2c, you can enable it. See "Enable SNMP v2c Mode for STA" for detailed instructions

Task 5: Dump the New STA Database (optional)

This procedure is optional but recommended. Use this procedure to dump the empty STA 2.3.x database as a safeguard. If the database upgrade (Task 8: Upgrade the Old Database) cannot be completed, you can restore the empty database to recover STA 2.3.x to a state in which it can be configured to run as if it were newly installed with no data; see Recover a Failed Manual Database Upgrade (optional) for details on the recovery process.

1. Open a terminal session on the STA server and log in as the Oracle user.

2. If you have not done so already, stop all STA services.

   $ STA stop all 
   

3. Start the MySQL service.

   $ STA start mysql
   

4. Create the database backup file. Enter the database root user password when prompted.

   $ mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dumpfile_path/dumpfile_name.sql
   

   Note:

   The optional –v parameter (for verbose output) is not recommended, as a large number of messages are displayed in the terminal window and it can significantly slow down the command process for large databases.

   In Example 7-4, the STA 2.3.x database is dumped to the /home/oracle folder on the STA server with filename STA_FRESH_INSTALL_BACKUP.sql.

   Example 7-4 New Database Dump

   $ mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb >  /home/oracle/STA_FRESH_INSTALL_BACKUP.sql
   Enter password: mysql_root_password
   ...
   -- Retrieving view structure for table v_mdv_request_states...
   -- Retrieving view structure for table version_info...
   ...
   -- Disconnecting from localhost...
   

   Note:

   If you see the message, "Can't connect to local MySQL server," the MySQL server is not running. Make sure you have started MySQL (Step 3).

Task 6: Transfer the Old STA Database to the STA Server

Note:

This procedure applies to the single-server method only.

Use this procedure to transfer the backup of the old database to the STA 2.3.x server.

1. If you have not done so already, stop all STA services on the STA 2.3.x server.

   $ STA stop all 
   

2. Transfer the database. The –p option on for SCP preserves timestamp values.

   $ scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
   

   In Example 7-5, SCP is used to transfer the compressed database dump file Jan26_dump.sql.gz from /dbdumpfiles on host backup1 to the /home/oracle folder on the STA 2.3.x server.

   Example 7-5 Old Database Transfer to New STA Server

   $ scp -p backup1:/dbdumpfiles/Jan26_dump.sql.gz /home/oracle
   

3. Perform a checksum of the transferred file. Verify the checksum value matches the one you received in "Task 1: Dump the Old STA Database". For example:

   $ cd /home/oracle/
   $ cksum Jan26_dump.sql.gz
   2169286306 37 /Jan26_dump.sql.gz
   

Task 7: Process and Load the Old STA Database

Use this procedure to decompress the old database and reinstate it on the STA 2.3.x server. The decompressed database may require 10 to 15 times as much space as the compressed database.

1. If you have not done so already, stop all STA services on the STA 2.3.x server.

   $ STA stop all 
   

2. Decompress the backup file. For example:

   $ cd /home/oracle
   $ gunzip Jan26_dump.sql.gz
   

3. Use the following steps to purge the STA database of obsolete data, such as processed SNMP records and empty analytics records.

   Note:

   A permanent record of purgerecs command activity is saved in the STA database. Starting with STA 2.0, database purging also occurs automatically at runtime. Periodically, the MySQL Event Scheduler purges records from various tables to attenuate database growth.

   1. Change to the STA database updates directory.

      $ cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
      

   2. Initiate the purge.

      $ ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/dump_file_name_PURGED.sql
      

      Note:

      For help with the purgerecs command, type the following command:

      $ ./purgerecs -h
      

   In Example 7-6, the purgerecs utility processes the MySQL dump file Jan26_dump.sql in /home/oracle. The output is directed to a new file named Jan26_dump_PURGED.sql in /home/oracle. A progress dot appears for each 200 records processed.

   Example 7-6 Purge Obsolete Data From the Old Database Backup

   $ cd /Oracle/StorageTek_Tape_Analytics/db/updates
   $ ./purgerecs /home/oracle/Jan26_dump.sql /home/oracle/Jan26_dump_PURGED.sql
   ................................................
             STA v1.0.2, Schema 33.02 
   Processed 11,689 lines from 'Jan26_dump.sql':
   ------------------------------------------------
   snmp_storage_cells........1,614,255
   snmp_media................110,205
   ...
   media_summaries...........254
   transform_logs............0
   ================================================
   Records Processed:........13,143,283
   Records Purged:...........2,857,623
   Records Remaining:........10,285,660
   Elapsed Time:.............00:00:11
   

4. This step is optional. Determine the database file size and estimate the load process time.

   $ ls -s -h dump_file_name_PURGED.sql
   

5. Start the MySQL server.

   $ STA start mysql
   

6. Load the old STA database. Enter the database root user password when prompted. Unless you specify the –v (verbose) option (not recommended), there is no command output as the process runs.

   Note:

   The optional –v parameter (for verbose output) is not recommended, as a large number of messages are displayed in the terminal window and it can significantly slow down the command process for large databases.

   $ mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name_PURGED.sql;"
   Password: mysql_root_password
   

   Where:

   • –p—Prompts for the database root password established during STA installation.

   • –e—Execute the following quote-enclosed statements:

     • SET SESSION SQL_LOG_BIN=0;—Turns off unnecessary binary logging, speeding up the load.

     • SOURCE /path_to_dump_file/dump_file_name_PURGED.sql—Loads the dump file into the DB.

   If the command is successful, you are returned to the command prompt once the process completes.

Task 8: Upgrade the Old Database

Use this procedure to upgrade the old STA database to the new STA 2.3.x schema.

1. If you have not done so already, stop all STA services.

   $ STA stop all 
   

2. If you determined in "Verify Upgrade Prerequisites" that the size of /tmp is not sufficient for the upgrade, increase the size of /tmp as necessary.

   If this is not possible, use the following steps to set an environment variable for MySQL to use an alternate temp location:

   1. Create an alternate temp location and assign open permissions to it. For example:

      $ mkdir /dbbackup/tmp
      $ chmod 777 /dbbackup/tmp
      

   2. Stop MySQL.

      $ STA stop mysql
      

   3. Edit the MySQL configuration file. For example:

      $  vi /etc/my.cnf
      

   4. In the mysqld section of the file, add a line defining the alternate temp location, which is identified by the tmpdir variable. Following is an example of the file after this line has been added.

      [mysqld]
      #----- mysqld MySQL Server Options -------------------------
       
      tmpdir                          = /dbbackup/tmp
      server-id                       = 1
      ...
      

   5. Restart MySQL.

      $ STA start mysql
      

3. Change to the database updates directory.

   $ cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
   

4. Start the upgrade script, and enter the database root user password when prompted. For security reasons, the password is not displayed on the screen.

   Note:

   This step requires system root privileges.

   For example:

   $ sudo ./upgradedb.sh
   [sudo] password for oracle:
   
   DB Root Password: 
   +-------------------------------------------------------------+
   | STA DATABASE UPGRADE                                        |
   | Upgrading DB schema from 58.00r0 to 59.00r0                 |
   | Started: 2014-12-12 15:14:45                                |
   +-------------------------------------------------------------+
   STA database is 5.15 GB and contains approximately 12,636,002 records.
   Checking if current database v58.00 is a valid upgrade candidate...
   ...DB v58.00 is a valid upgrade candidate...
   +-------------------------------------------------------------+
   ==> You may ABORT using CTRL-C within 7 seconds
   ==> .....6.....5.....4.....3.....2.....1
   ==> CTRL-C disabled!
   +-------------------------------------------------------------+
   Starting upgrade...
   

   When the process is complete, a banner similar to the following is displayed.

   Caution:

   Wait until you see this banner before proceeding.

   +-------------------------------------------------------------+
   | Started.................2017-02-12 15:14:45                 |
   | Finished................2017-02-12 17:07:11                 |
   | Elapsed Time............01:52:26                            |
   | Starting Version........58.00r0                             |
   | Final Schema Version....59.00r0                             |
   | Schema Release Date.....2017-02-12 11:00:00                 |
   | Records (approximate)...12,636,002                          |
   +-------------------------------------------------------------+
   

5. If in "Task 8: Upgrade the Old Database" you increased the size of /tmp or created an alternate temp location, restore it to its normal size and location.

6. Start all STA services.

   $ STA start all
   

7. This step is optional. Delete the STA_FRESH_INSTALL_BACKUP.sql file to free up disk space on the STA database backup volume.

Recover a Failed Manual Database Upgrade (optional)

Caution:

Perform this procedure only under the direction of your Oracle support representative.

Use this procedure only if the manual database upgrade in "Task 8: Upgrade the Old Database" does not complete successfully and attempts to repeat the upgrade have also failed.

1. Repeat "Task 7: Process and Load the Old STA Database", Step 6, through "Task 8: Upgrade the Old Database".

   If the upgrade fails again, the database is in an unknown, possibly damaged state and you should restore the database to its original, freshly installed state. Proceed to the next step.

2. Delete the damaged upgraded database.

   $ mysql -uroot -p -e "drop database stadb;"
   

3. Change to the STA database backup location and load the new installation database dump file you created in "Task 5: Dump the New STA Database (optional)".

   For example:

   $ cd /dbbackup
   $ mysql -uroot -p -e < /home/oracle/STA_FRESH_INSTALL_BACKUP.sql
   

4. Perform "Task 8: Upgrade the Old Database".

5. Configure STA as a new installation. See the following sections for details:

   • "Configuring Library Connections in STA"

   • "Configure STA Services and User Information"

Post-upgrade Configuration Tasks for All Upgrades

Note:

This section applies to both automatic and post-installation upgrades.

Use these procedures to configure the libraries and STA 2.3.x so STA can begin monitoring library activity.

• "Verify STA Application is Running Properly"

• "Update the STA Trap Recipient on the Libraries"

• "Configure SNMP Settings in STA"

• "Configure STA Services and User Information"

• "Decommission the Old STA Server (optional)"

Verify STA Application is Running Properly

Use this procedure to verify that all STA application services are running and active after the upgrade. See the STA Administration Guide for details about the services and the use of the STA command.

Note:

The staservd daemon may fail to start properly after an automatic upgrade. This procedure will remedy that issue.

1. Open a terminal session on the STA server, and log in as the Oracle user.

2. Display the application status. It may take a few minutes for the command to complete.

   $ STA status all
   mysql is running
   staservd service is running
   staweblogic service is running
   staengine service is running
    .... and the deployed application for staengine is in an ACTIVE state
   staadapter service is running
    .... and the deployed application for staadapter is in an ACTIVE state
   staui service is running
    .... and the deployed application for staui is in an ACTIVE state
   $
   

3. If there are any issues with the STA services, you can review the installation and STA logs for more information. See "STA Installation, Upgrade, and Deinstallation Logs" for their locations.

4. If necessary, stop and restart all STA services. It may take several minutes for the commands to complete.

   $ STA stop all
   Stopping the staui service......
   Successfully stopped the staui service
   Stopping the staadapter service......
   Successfully stopped the staadapter service
   Stopping the staengine service......
   Successfully stopped the staengine service
   Stopping the staweblogic service......
   Successfully stopped the staweblogic service
   Stopping the staservd Service...
   Successfully stopped staservd service
   Stopping the mysql service.....
   Successfully stopped mysql service
   $
   $ STA start all
   Starting mysql Service..
   mysql service was successfully started
   Starting staweblogic Service..........
   staweblogic service was successfully started
   Starting staengine Service..................
   staengine service was successfully started
   Starting staadapter Service..................
   staadapter service was successfully started
   Starting staui Service...............
   staui service was successfully started
   Starting staservd Service.
   staservd service was successfully started
   $
   

Update the STA Trap Recipient on the Libraries

Two new trap levels, 13 (Test Trap) and 14 (Health Trap), were introduced in STA 2.0. Proceed as follows depending on your upgrade path:

• If you are using the two-server upgrade method, add the new STA 2.3.x server as a trap recipient on each monitored library, and be sure to include the new trap levels in the definition. See "Create the STA SNMP v3 Trap Recipient" or "Create the STA SNMP v2c Trap Recipient on the Library".

• If you are using the single-server method to upgrade from STA 2.0.x or later, the STA trap recipient and new trap levels are already defined on each monitored library, so you do not need to make any additional modifications. Proceed to "Configure SNMP Settings in STA".

• If you are using the single-server method to upgrade from STA 1.0.x, the STA trap recipient is already defined on each monitored library, but you must add the new trap levels to the definition. Use the appropriate steps for each library model.

  Note:

  For all library models except SL150, to modify a trap recipient, you must delete the existing definition and then add a new one.

All libraries except SL150 

1. Log in to the library CLI.

2. Display all existing trap recipients, and note the index number of the STA recipient.

   snmp listTrapRecipients
   

3. Delete the STA trap recipient.

   snmp deleteTrapRecipient id index
   

   Where:

   • index is the index number of the STA trap recipient.

4. Re-add the STA trap recipient and include the new trap levels in the trap level list. See "Create the STA SNMP v3 Trap Recipient" or "Create the STA SNMP v2c Trap Recipient on the Library" for instructions.

SL150 libraries 

1. Log in to the browser-based user interface.

2. From the SNMP menu, select SNMP Trap Recipients.

3. Select the STA trap recipient from the list.

4. Select Modify Trap Recipient.

5. Add the new trap levels to the trap level list, and then click Save.

Configure SNMP Settings in STA

Perform these steps for all upgrades. These steps are performed in STA.

1. Log in to STA as an STA administrator user.

2. Reenter the configuration settings for the STA SNMP client, using the values you recorded before the upgrade (see "Record Current STA User and Configuration Settings (optional)"). These values must match what is configured on the monitored libraries. See "Configure SNMP Client Settings for STA" for instructions.

3. Reconfigure the SNMP connection to each library you want STA to monitor. See "Configure the SNMP Connection to a Library" for instructions.

4. To restore SNMP communication between STA and the libraries, test the connection to each monitored library. See "Test a Library SNMP Connection" for instructions.

   Note:

   Once this step has completed successfully, STA begins receiving and processing data from each monitored library.

   You may notice incomplete exchanges on the Exchanges Overview screen from exchanges in process either when STA was stopped or when the library connections were restored. See the STA User's Guide for details about incomplete exchanges.

5. Get the latest SNMP library configuration data from each library. See "Perform a Manual Data Collection" for instructions.

Configure STA Services and User Information

Perform these steps for all upgrades.These steps are performed on the STA server.

If you want to retain settings from the previous STA version, use the values you recorded before the upgrade; see "Record Current STA User and Configuration Settings (optional)".

1. Configure the STA Backup service and STA Resource Monitor service utilities. See the STA Administration Guide for details.

2. Create STA usernames and passwords; see the STA User's Guide for instructions. You may also want to do the following:

   • Notify users of any new password requirements. See "Username and Password Requirements" for details.

   • Direct users to reenter their custom user preferences, if applicable.

3. If the STA email server requires authentication, you must enter the email account username and password; see the STA User's Guide for instructions.

4. Restore original ownership to custom templates, as applicable; see the STA User's Guide for instructions.

5. Restore original ownership to private Executive Report policies, as applicable; see the STA User's Guide for instructions.

6. Restore original ownership to logical groups by recreating the groups, as applicable; see the STA User's Guide for instructions.

Decommission the Old STA Server (optional)

This procedure applies only if you used the two-server post-installation upgrade method. You can use this procedure after verifying that the new STA server is functioning as expected.

1. Remove the old STA server as a trap recipient from each library's SNMP configuration. See the STA User's Guide for instructions.

2. Decommission the old STA server.

Environment Changes for All Upgrades

The following changes have been introduced in STA 2.3.0 and apply to all upgrades from any installed version of STA.

• STA Application Run as the Oracle User

• Internal Redirection Port for SNMP Traps

STA Application Run as the Oracle User

The STA application and provided utilities are run as the Oracle user instead of system root. This change provides improved site security. See "User Accounts for Managing STA" for details about the Oracle user.

Internal Redirection Port for SNMP Traps

SNMP traps received from the monitored libraries are now redirected to an internal non-privileged port that you specify during STA installation or upgrade. See "Internal Port Forwarding for SNMP Traps" for details.

Environment Changes for Upgrades from STA 2.0.x and Earlier

These changes apply only to upgrades from STA 2.0.x or earlier. They were introduced in either STA 2.0.0 or STA 2.1.0; therefore, they have already been applied to your environment if you are upgrading from STA 2.1.x or later.

If you are upgrading from STA 2.0.x or earlier, review the following changes to determine which ones apply to your site and the impact on your upgrade.

• "Required Linux Version"

• "Default WebLogic Port Numbers"

• "Username and Password Requirements"

• "Required Ports for STA Managed Servers"

Required Linux Version

Note:

This change was introduced in STA 2.1.0.

Linux 6.3 or later is required for STA 2.3.0 and later (see the STA Requirements Guide for details). You may need to install a new version of Linux as part of the STA upgrade process, as follows:

• If you are upgrading from STA 1.0.x, you must install Linux 6.3 or later before installing STA 2.3.x. Linux does not support an in-place upgrade from Linux 5.x to Linux 6.x; instead, you must perform a new Linux 6.x installation on the STA server.

• If you are upgrading from STA 2.0.x, you are already running Linux 6.3 or later, so you do not need to install a new version of Linux; however, you must deinstall the current version of STA before installing STA 2.3.x. You may also need to install or update the required Linux RPM packages—as part of the upgrade preparation, you will ensure that all required RPM package levels are installed, and as a final check, the STA installer will also notify you if any packages are missing.

• If you are upgrading from STA 2.1.x or later, you are already running Linux 6.3 or later, and you can use the automatic STA upgrade, which will verify that all required Linux RPM packages are installed on the STA server.

Default WebLogic Port Numbers

Note:

This change was introduced in STA 2.1.0.

Changes to the default WebLogic Administration console port numbers were introduced in STA 2.1.0. If you are currently using the old default port numbers, you may want to change to the new default values. The new and old default port numbers are as follows:

• New defaults for STA 2.1.0 and later—7019 (HTTP) and 7020 (HTTPS)

• Old defaults (STA 1.0.x and STA 2.0.x)—7001 (HTTP) and 7002 (HTTPS)

Note:

The WebLogic Administration console ports are external. Your network administrator may need to configure firewalls and routers to open communication between the STA server and the clients accessing the WebLogic Administration interface.

Username and Password Requirements

Note:

This change was introduced in STA 2.1.0. Additional special characters were made illegal in STA 2.2.0 and STA 2.3.0.

Following are the username and password requirements for STA and MySQL. You may need to coordinate these requirements with any internal requirements at your site.

Username requirements are as follows:

• Must be 1–16 characters in length

• All usernames must be unique

Password requirements are as follows:

• Must be 8–32 characters in length

• Must include at least one uppercase letter and one number

• Must not include spaces or tabs

• Must not include any of the following special characters:

  % & ' ( ) < > ? { } * \ ' " ; , + = # !
  

Required Ports for STA Managed Servers

The default STA managed server port numbers STA 2.0.x and later are as follows:

• StaUi—7021 (HTTP) and 7022 (HTTPS)

• StaEngine—7023 (HTTP) and 7024 (HTTPS)

• StaAdapter—7025 (HTTP) and 7026 (HTTPS)

Note:

The StaUi ports are external. Your network administrator may need to configure firewalls and routers to open communication between the STA server and the clients accessing the STA user interface.