8 升级到 STA 2.1.0

本章提供有关将任何以前发行的 STA 版本升级到 STA 2.1.0 的说明。其中包含以下各节：

• 升级过程概述

• 有效的 STA 2.1.0 升级路径

• 升级方法

• STA 2.1.0 的环境更改

• 升级准备任务

• 升级任务

如果您是首次安装 STA，则应执行新的基础安装；有关说明，请参见第 3 章 安装 STA。

附录 C 包含可用于组织升级活动并记录设置的工作表。

升级过程概述

在升级过程中，会将现有 STA 数据从当前 STA 版本转换到新版本。只有在这些转换完成后，STA 数据库才对新版本的 STA 有效。在升级之后，STA 将根据新的 STA 方案和分析规则处理新数据；不会重新处理历史数据。

在开始升级之前，请阅读本章中的所有说明，并确保为整个过程分配足够的时间。某些升级准备任务可能要求您与站点的其他组（如网络管理）进行协调。应提前完成所有准备任务，以便可以在尽可能短的时间内完成升级本身。

开始升级过程本身后，STA 将无法运行，因此不会从受监视的磁带库接收交换信息。此外，只有在完成升级中的所有步骤并测试到每个受监视磁带库的 SNMP 连接之后，新版本的 STA 才会开始从磁带库接收信息。

注:

某些升级步骤包含仅为计划目的提供的时间估计。根据服务器功能（CPU 数量、CPU 速度、磁盘速度、内存和可用的交换空间），实际时间可能会有所不同。

有效的 STA 2.1.0 升级路径

可以从以下任何发行的 STA 版本升级到 STA 2.1.0：

• STA 2.0.x：

  • STA 2.0.0.83

  • STA 2.0.1.4

• STA 1.0.x：

  • STA 1.0.0.99

  • STA 1.0.1.133

  • STA 1.0.2.24

  注:

  如果要从 STA 1.0.x 进行升级，则还必须在安装 STA 2.1.0 之前安装新版本的 Linux。有关详细信息，请参见《STA 要求指南》。

升级方法

根据您的目标和可用的资源，可以使用任一服务器或两个服务器执行 STA 升级。两种方法的升级任务基本相同，但会按照不同的顺序执行任务。以下各节介绍这两种方法：

• 单服务器升级方法

• 双服务器升级方法

单服务器升级方法

使用单服务器方法时，必须在安装新版本之前卸载 STA 并在同一服务器上升级数据库。在执行该过程时 STA 不会监视磁带库。

该方法的优势在于不要求为升级提供额外的专用服务器。如果要从 STA 2.0.x 进行升级，则无需安装新版本的 Linux，因此该方法可能足以满足您的需要。

图 8-1 说明了单服务器方法。按顺序执行任务 1 至任务 9。总结：

• 转储当前数据库并将其转移到备份服务器以妥善保存（任务 1 和任务 2）。

• 根据您的当前 STA 版本，安装 Linux 6.x（任务 3a）或卸载 STA 2.0.x（任务 3b）。

• 安装 STA 2.1.0，并作为预防措施转储新数据库（任务 4 和任务 5）。

• 从备份服务器转移旧数据库的转储，然后将其装入并升级至新 STA 版本（任务 6 至任务 8）。

• 重新建立到受监视磁带库的连接并执行必要的手动配置任务（任务 9）。由于在安装 STA 2.1.0 之前必须卸载旧版本的 STA，因此必须手动重新输入某些用户配置数据。

图 8-1 单服务器升级任务概述

说明 - 图 8-1 单服务器升级任务概述

双服务器升级方法

双服务器升级方法需要第二个专用 STA 服务器，但其优势在于可减少 STA 应用程序停机时间。如果要从 STA 1.0.x 进行升级，则该方法尤其有用，因为在新服务器上安装 Linux 和新版本的 STA 时，旧版本的 STA 可以继续在旧服务器上监视磁带库。

不过，即使使用该方法，在您将当前数据库升级到新 STA 版本时，STA 也不会监视磁带库。停机时间取决于当前数据库的大小。

图 8-2 说明了双服务器方法。必须按照显示的顺序完成这些任务－未按顺序完成这些任务，省略了任务 6。请注意，只有在新服务器上安装新版本的 STA 后，才转储当前 STA 数据库。总结：

• 根据第二个服务器当前是否在运行某个版本的 STA，安装 Linux 6.x（任务 3a）或卸载 STA 2.0.x（任务 3b）。

• 在新服务器上安装 STA 2.1.0，并作为预防措施转储新数据库（任务 4 和任务 5）。

• 转储旧服务器上的当前数据库并将其转移至新服务器（任务 1 和任务 2）。

• 装入当前数据库并将其升级至新 STA 版本（任务 7 和任务 8）。

• 重新建立到受监视磁带库的连接并执行必要的手动配置任务（任务 9）。

图 8-2 双服务器升级任务概述

说明 - 图 8-2 双服务器升级任务概述

STA 2.1.0 的环境更改

下面是在计划升级到 STA 2.1.0 时应考虑的环境更改摘要。

Linux 版本

STA 2.1.0 需要 Linux 6.3 或更高版本（有关详细信息，请参见《STA 要求指南》）。根据当前 STA 版本，可能需要在 STA 升级过程中安装新版本的 Linux。

• 如果要从 STA 1.0.x 进行升级，则必须在安装 STA 2.1.0 之前安装 Linux 6.3 或更高版本。Linux 不支持从 Linux 5.x 到 Linux 6.x 的就地升级；相反，必须在 STA 服务器上执行新的 Linux 6.x 安装。

• 如果要从 STA 2.0.x 进行升级，则需要已经在运行 Linux 6.3 或更高版本；不过，必须在安装 STA 2.1.0 之前卸载当前版本的 STA。可能还需要安装或卸载所需的 Linux RPM 软件包－作为升级准备的一部分，应确保安装了所有所需的 RPM 软件包级别，此外，作为最终检查，STA 安装程序还会在缺少任何软件包时通知您。

默认 WebLogic 端口号

对于 STA 2.1.0，已更改默认 WebLogic 管理控制台端口号。如果当前在使用旧的默认端口号，则可能需要更改为新的默认值。新的和旧的默认端口号如下所示：

• STA 2.1.0 的新默认值－7019 (HTTP) 和 7020 (HTTPS)

• 旧默认值（STA 1.0.x 和 STA 2.0.x）－7001 (HTTP) 和 7002 (HTTPS)

注:

WebLogic 管理控制台端口是外部端口。网络管理员可能需要配置防火墙和路由器才能打开 STA 服务器与访问 WebLogic 管理界面的客户机之间的通信。

STA 2.0.x 及更高版本所需的端口

注:

该更改是在 STA 2.0.x 中引入的，因此仅当从 STA 1.0.x 升级时该更改才是相关的。

在 STA 2.0.x 中，针对 StaUi 和 StaEngine 受管服务器添加了 STA 端口。STA2.0.x 和 STA 2.1.0 的默认 STA 受管服务器端口号如下所示：

• StaUi－7021 (HTTP) 和 7022 (HTTPS)

• StaEngine－7023 (HTTP) 和 7024 (HTTPS)

• StaAdapter－7025 (HTTP) 和 7026 (HTTPS)

注:

StaUi 端口是外部端口。网络管理员可能需要配置防火墙和路由器才能打开 STA 服务器与访问 STA 用户界面的客户机之间的通信。

用户名和密码要求

对于 STA 2.1.0，已更改 STA 和 MySQL 的用户名和密码要求。可能需要将这些要求与您站点的任何内部要求进行协调。

用户名要求如下：

• 长度必须为 1-16 个字符

• 所有用户名都必须唯一

密码要求如下：

• 长度必须为 8-31 个字符

• 必须至少包含一个数字和一个大写字母

• 不得包含空格

• 不得包含下列任何特殊字符：

  & ' ( ) < > ? { } *  \ ' "
  

升级准备任务

在开始 STA 升级之前执行以下任务。其中的大多数任务是可选的，表 8-1 提供了有关何时使用每项任务的准则。

表 8-1 有关何时执行升级准备任务的准则

任务	何时执行
验证站点是否为升级做好准备	所有升级
保存现有日志（可选）	需要保留当前版本的 STA 的服务日志。
记录当前 STA 用户和配置设置（可选）	需要保留当前 STA 用户名和配置设置。
重命名具有 STA– 前缀的定制模板（可选）	具有名称包含 "STA–" 前缀的定制模板。
记录当前定制模板设置（可选）	需要保留现有定制模板的所有权和可见性设置。
记录主管报告策略设置（可选）	需要保留现有主管报告策略的所有权设置。

验证站点是否为升级做好准备

使用该过程查看升级要求并验证站点是否做好准备。

验证升级先决条件

使用该过程确保您的环境满足所有 STA 2.1.0 先决条件。

1. 显示当前 STA 版本。根据是从 STA 1.0.x 还是从 STA 2.0.x 进行升级，某些升级任务会有所不同。

   1. 使用 STA 管理员用户名登录到 STA。

   2. 在状态栏中单击 About。

   3. 验证是否在运行当前发行的 STA 版本。有关详细信息，请参见有效的 STA 2.1.0 升级路径。

2. 选择要使用单服务器升级方法还是双服务器升级方法。有关详细信息，请参见升级过程概述。

3. 验证站点和目标服务器是否满足 STA 2.1.0 要求。有关详细信息，请参见《STA 要求指南》。

4. 确定目标 STA 服务器上的 /tmp 文件系统是否具有用于升级的足够空间。/tmp 的大小应至少与现有未压缩的 STA 数据库的大小相等；要求至少 4 GB，对于大型数据库，Oracle 建议您将 /tmp 的大小至少增加到 32 GB。

   如果您确定必须增加 /tmp 的大小，可以恰好在运行升级脚本之前执行该操作；有关说明，请参见任务 8：升级旧数据库。

5. 查看与您的升级路径相关的环境更改，并对您的计划或环境进行任何必要的调整。有关详细信息，请参见STA 2.1.0 的环境更改。

6. 如果要从 STA 2.0.x 进行升级，请确保在 STA 服务器上安装了所有所需的 RPM 软件包。有关说明，请参见安装必需的 Linux 软件包。作为最终检查，STA 安装程序还会在缺少任何软件包时通知您。

验证当前 STA 活动

使用该过程验证当前 STA 环境是否正常工作。

1. 使用以下步骤验证当前版本的 STA 最近是否曾与每个受监视的磁带库成功通信。

   1. 以 STA 管理员用户身份登录到 STA。

   2. 从 Setup & Administration 选项卡中，选择 SNMP Connections。

   3. 验证 "Monitored Libraries" 表中的以下值：

      • Recent SNMP Trap Communication Status－GOOD

      • Last Connection Status－SUCCESS

2. 使用以下步骤验证 STA 是否在所有磁带库上处理交换。

   1. 从 Tape System Activity 选项卡中，选择 Exchanges – Overview。

   2. 选择 Filter 图标并使用条件 "Exchange End (No. Days)" 为 "Less Than 1" 进行过滤。

   3. 在表工具栏中，选择 View，再选择 Sort，然后选择 Advanced。按照 "Drive Library Name"、"Drive Serial Number" 进行排序。

   4. 验证是否所有磁带库都有交换活动。

保存现有日志（可选）

升级之后不会保留现有应用程序和服务日志，因为必须在安装 STA 2.1.0 之前卸载当前版本的 STA 或安装新版本的 Linux。使用该过程保存您希望保存的任何日志。

1. 找到要保留的任何安装和数据库日志，然后将其移动到安全的位置。可能值得关注的日志位于您为安装定义的 STA 日志位置。有关详细信息，请参见查看 STA 文件系统布局。

2. 使用以下步骤对当前 STA 安装执行服务日志快照。该步骤是可选的，但建议执行该步骤，因为 Oracle 技术支持可使用这些日志解决可能在升级之前存在的任何问题。

   1. 以 STA 管理员用户身份登录到 STA。

   2. 从 Setup & Administration 选项卡中，选择 Logs。

   3. 在 "Service – Logs" 屏幕上，单击 Create New Log Bundle 图标。

   4. 在 "Create New Log Bundle" 对话框中，分配包名称并单击 Save。此过程可能需要几分钟时间才能完成。

3. 使用以下步骤下载您刚才创建的服务日志包，以及您希望保留的任何其他日志包。必须以一次一个的方式下载这些日志包。

   1. 在 "Service – Logs" 屏幕上，选择要下载的包。

   2. 单击 Download Selected Log Bundle 图标。

   3. 在对话框中，指定目标位置并保存日志包。

记录当前 STA 用户和配置设置（可选）

仅当您要保留 STA 2.1.0 中的当前 STA 用户名和配置设置时本节才适用。使用这些过程显示和记录当前值，以便您可以为 STA 2.1.0 重新输入这些值。您将在升级之后重新输入其中的大多数值；有关详细信息，请参见任务 9：配置新 STA 版本。

记录 MySQL 用户名

使用该过程显示和记录用于访问 STA 数据库的现有 MySQL 用户名。STA 安装程序将提示您输入这些值。无法取回密码。

1. 在当前 STA 服务器上打开一个终端会话，然后以系统 root 用户身份登录。

2. 通过发出以下查询显示所有 STA 数据库用户名。在系统提示时，输入数据库 root 用户密码。例如：

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

3. 记录用户名。

记录 STA SNMP 客户机设置

使用该过程显示和记录 STA 的 SNMP 客户机设置。您将在升级之后重新输入这些值。

注:

在新版本的 STA 中，SNMP 值必须与在受监视的磁带库上指定的值相匹配。

1. 使用 STA 管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 SNMP Connections。

   "Client Attributes" 表显示 STA SNMP 客户机的配置设置。

   
   图示说明snmp_clientupgrade.png
   
   

3. 记录以下列中的值：

   • SNMP Username

   • User Community

   • Trap Community

记录 WebLogic 用户名－仅限从 STA 1.0.x 升级

对于从 STA 1.0.x 进行的升级，使用该过程显示和记录用于登录到 STA 的现有 WebLogic 用户名。您将在升级之后重新输入这些值。无法取回密码。

注:

从 STA 2.0.x 开始，通过 STA 用户界面创建和维护用户名；有关说明，请参见记录 STA 用户名－仅限从 STA 2.0.x 升级。

1. 在计算机上启动支持的 Web 浏览器并输入 WebLogic 管理控制台的 URL。

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

   其中：

   • host_name 是 STA 服务器的主机名。

   • port_number 是当前 STA 版本中 WebLogic 管理控制台的 STA 端口号。

   • STA 必须大写。

   例如：

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

2. 使用 WebLogic 管理控制台用户名和密码登录。

3. 在 "Domain Structure" 导航树中，单击 Security Realms。

   
   图示说明wl_secrealm.png
   
   

   此时将显示 "Summary of Security Realms" 屏幕。

4. 在 "Name" 列中，选择 myrealm 活动链接（不要选择复选框）。

   
   图示说明wl_myrealm.png
   
   

   此时将显示 "Settings for myrealm" 屏幕。

5. 选择 Users and Groups 选项卡。

   
   图示说明wl_checkusers.png
   
   

   "Users" 表列出了可用的用户名。

   
   图示说明wl_userstable.png
   
   

6. 记录要保留的用户名。

记录 STA 用户名－仅限从 STA 2.0.x 升级

对于从 STA 2.0.x 进行的升级，使用该过程显示和记录用于登录到 STA 的用户名。您将在升级之后重新输入该信息。无法取回密码。

注:

对于 STA 1.0.x，通过 WebLogic 管理控制台创建和维护用户名；有关说明，请参见记录 WebLogic 用户名－仅限从 STA 1.0.x 升级。

1. 使用 STA 管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 Users。

   "Configuration – Users" 屏幕显示所有 STA 用户名及其角色。

   
   图示说明upgrade_users.png
   
   

3. 记录要保留的用户名和角色。

记录 STA 电子邮件服务器设置

使用该过程显示和记录 STA 电子邮件协议和帐户用户名（如果电子邮件服务器要求验证）。您将在升级之后重新输入这些值。无法显示密码。

1. 使用 STA 管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 Email。

3. 在 "SMTP Server Settings" 表中，选择 "StorageTek Tape Analytics Alerts" 记录，然后单击 Edit Selected SMTP Server 图标。

   此时将显示 "Define SMTP Server Details" 对话框。

   
   图示说明email_smtpserverd.png
   
   

4. 记录以下字段中的值：

   • Use Secure Connection Protocol

   • Username

重命名具有 STA– 前缀的定制模板（可选）

仅当您具有名称包含 "STA–" 前缀的定制模板时该过程才适用。在 STA 2.1.0 安装期间，会将所有具有 "STA–" 前缀的模板删除并替换为新的 STA 预定义模板。

使用该过程为这些模板分配新名称，以便在升级过程中保留这些模板。

注:

STA 预定义的模板具有前缀 "STA–"；因此 Oracle 建议您在命名定制模板时不要使用该前缀。

1. 使用管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 Templates Management。

3. 按 "Date Created"/"Date Updated" 对表进行排序，以便聚焦于自 STA 安装日期以来修改过的模板。

4. 选择名称包含 "STA‐" 前缀的定制模板的文本链接。

   您将被带到应用了所选模板的屏幕。

5. 在模板工具栏中单击 Save Template。

   此时将显示 "Save Template" 对话框。

6. 在 Template Name 字段中分配不包含 "STA‐" 前缀的新名称。输入必须是唯一的。

7. 单击 Save。

   将保存该模板。

记录当前定制模板设置（可选）

仅当您具有定制模板时本节才适用。升级会保留定制模板，但在升级之后所有定制模板将由 STA 拥有并具有公共可见性。

使用该过程记录所有定制模板的当前所有权和可见性设置，以便您可以在升级之后根据需要恢复这些设置。如果模板所有权和可见性对您的实施并非至关重要，则可以跳过该过程。

1. 使用管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 Templates Management。

3. 选择 Filter 图标并过滤屏幕，以便仅显示不由 STA 拥有的模板－这将仅显示定制模板。

   
   图示说明upgrade_filternotsta.png
   
   

4. 记录每个定制模板的当前 "Owner" 和 "Public Visibility" 设置。如果您有许多模板，则可能需要生成屏幕抓图。

记录主管报告策略设置（可选）

仅当您具有专有的主管报告策略时本节才适用。升级会保留所有主管报告策略，但在升级之后会为所有专用策略分配公共所有权。

使用该过程记录所有专用策略的当前所有权设置，以便您可以在升级之后根据需要恢复这些设置。如果主管报告策略所有权对您的实施并非至关重要，则可以跳过该过程。

1. 使用 STA 管理员用户名登录到 STA。

2. 从 Setup & Administration 选项卡中，选择 Executive Reports Policies。

3. 选择 Filter 图标并过滤屏幕，以便仅显示不由 STA 拥有的策略－这将仅显示专用策略。

   
   图示说明upgrade_rptnotsta.png
   
   

4. 记录每个策略的当前 "Report Owner"。如果您有许多策略，则可能需要生成屏幕抓图。

升级任务

注意:

只应由 Linux 管理员和 STA 管理员执行升级。所有任务都是必需的，并且必须按照指定的顺序根据所示的内容准确执行，否则可能会导致数据丢失。

如果要使用单服务器升级方法，则按顺序执行这些任务；有关详细信息，请参见图 8-1 单服务器升级任务概述。

如果要使用双服务器升级方法，则不要按顺序执行这些任务并省略任务 6；有关任务顺序，请参见图 8-2 双服务器升级任务概述。

• 任务 1：转储旧 STA 数据库

• 任务 2：转移旧数据库转储

• 任务 3a：安装新 Linux 版本（从 STA 1.0.x 升级）

• 任务 3b：卸载旧 STA 版本（从 STA 2.0.x 升级）

• 任务 4：安装新 STA 版本

• 任务 5：转储新 STA 数据库（可选）

• 任务 6：将旧 STA 数据库转移至 STA 服务器

• 任务 7：处理并装入旧 STA 数据库

• 任务 8：升级旧数据库

• 任务 9：配置新 STA 版本

• 恢复失败的数据库升级（可选）

任务 1：转储旧 STA 数据库

使用该过程执行旧（当前）STA 数据库的完整转储。

1. 使用以下步骤显示当前 STA 数据库的大小。

   1. 使用 STA 管理员用户名登录到 STA。

   2. 在状态栏中单击 About。

   3. 在 "About" 对话框中，向下滚动到显示 "Database Current Size" 的位置，然后记下相应的值。

2. 使用以下步骤验证要用于转储数据库的位置是否具有足够的空间。

   1. 在 STA 服务器上打开一个终端会话，然后以系统 root 用户身份登录。

   2. 显示数据库转储目标中的可用空间，并验证该空间是否足以容纳转储文件。例如：

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

3. 停止所有 STA 服务。

   # STA stop all 
   

4. 启动 MySQL 服务。

   # service mysql start
   

5. 将 STA 数据库转储到单个文件中。在系统提示时，输入数据库 root 用户密码。

   # 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
   

   注:

   不建议使用可选的 –v 参数（用于详细输出），因为终端窗口中会显示大量消息，对于大型数据库，该参数会显著降低命令处理速度。

   在示例 8-1 中，使用文件名 Dec14_dump.sql 将 STA 1.0.x 数据库转储至 STA 服务器上的 /dbdumpfiles 文件夹。

   示例 8-1 旧数据库转储

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb > /dbdumpfiles/Dec14_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. 要将转储文件大小缩减约 50%，可用 gzip 压缩文件。

   # cd /path_to_dump_file/
   # gzip dump_file_name.sql
   

任务 2：转移旧数据库转储

使用该过程将压缩的旧 STA 数据库转储转移到平台外的备份服务器（单服务器方法）或者转移到新的 STA 2.1.0 服务器（双服务器方法）。

注意:

如果要使用单服务器方法从 STA 1.0.x 进行升级，则必须将 STA 数据库备份至其他服务器。不要将数据库备份到当前 STA 服务器上的文件系统，因为任务 3a：安装新 Linux 版本（从 STA 1.0.x 升级） 中的 Linux 6.x 安装将销毁服务器上的所有数据。

1. 如果尚未执行该操作，则停止所有 STA 服务。

   # STA stop all 
   

2. 在将文件转移到备份服务器之前执行校验和计算。

   # cksum dump_file_name.sql.gz
   

   输出包括校验和值和字节计数。记录校验和值；在将文件转移到备份服务器之后，将使用该值来验证文件完整性。

3. 使用 SCP 之类的转移实用程序将文件转移到目标服务器。–p 选项可保留时间戳值。

   # scp -p dump_file_name.sql.gz target_host:/path/
   

   在示例 8-2 中，SCP 用于将压缩的数据库转储文件 Dec14_dump.sql.gz 转移至备份主机 backup1 上的 /dbdumpfiles 文件夹。备份主机上已经存在 /dbdumpfiles 文件夹。

   示例 8-2 到备份服务器的旧数据库转移（单服务器方法）

   # cd /dbdumpfiles
   # scp -p Dec14_dump.sql.gz backup1:/dbdumpfiles
   

   在示例 8-3 中，SCP 用于将压缩的数据库转储文件 Dec14_dump.sql.gz 转移至 STA 2.1.0 主机 sta_new 上的 /dbdumpfiles 文件夹。

   示例 8-3 到新 STA 服务器的旧数据库转移（双服务器方法）

   # cd /dbdumpfiles
   # scp -p Dec14_dump.sql.gz sta_new:/dbdumpfiles
   

4. 在目标服务器上，对转移的文件执行校验和计算。验证校验和值是否匹配。

   # cd /path_to_dump_file/
   # cksum dump_file_name.sql.gz
   

任务 3a：安装新 Linux 版本（从 STA 1.0.x 升级）

该过程仅适用于从 STA 1.0.x 进行升级。在 STA 服务器上安装 Linux 6.3 或更高版本；有关说明，请参见第 2 章 安装 Linux。

注意:

该活动会销毁服务器上的所有数据。如果要使用单服务器升级方法，则仅在执行任务 1：转储旧 STA 数据库 和任务 2：转移旧数据库转储 后使用该过程。

任务 3b：卸载旧 STA 版本（从 STA 2.0.x 升级）

该过程仅适用于从 STA 2.0.x 进行的升级。卸载当前版本的 STA；有关说明，请参见卸载 STA 和验证卸载是否成功。

注意:

该活动会销毁服务器上的所有 STA 数据。如果要使用单服务器升级方法，则仅在执行任务 1：转储旧 STA 数据库 和任务 2：转移旧数据库转储 后使用该过程。

任务 4：安装新 STA 版本

使用该过程安装 STA 2.1.0。

1. 安装 STA 2.1.0；有关说明，请参见安装 STA。

2. 要验证 STA 是否正常工作并在 WebLogic 中完成 STA Administrator 设置，请登录到 STA 应用程序。

   此时将显示显示板。

   注:

   由于升级过程尚未完成，因此显示板 portlet 显示消息 "No data to display"；这是正常的。升级数据库并配置新 STA 版本之后，将正确显示磁带库数据。

3. 注销 STA。

4. 在 STA 服务器上打开一个终端会话，然后以系统 root 用户身份登录。

5. 停止所有 STA 服务。

   # STA stop all
   

6. 仅当您希望 STA 使用 SNMP v2c 监视磁带库时，该步骤才适用（有关详细信息，请参见附录 F 配置 SNMP v2c 模式）。从 STA 2.0.x 开始，默认启用 SNMP v2c。使用以下步骤确认已启用 SNMP v2c。

   1. 转到 STA 配置文件目录。

      # cd /Oracle_storage_home/Middleware/user_projects/domains/TBI
      

   2. 显示 SNMP 版本属性文件并验证 V2c 参数是否设置为 true。

      # cat TbiSnmpVersionSupport.properties
      V2c=true
      Verbal=false
      

   3. 如果该参数未设置为 "true"，则参见为 STA 启用 SNMP v2c 模式 以了解有关如何更改该参数的说明。

任务 5：转储新 STA 数据库（可选）

该过程是可选的，但建议执行该过程。作为一种保护措施，使用该过程转储空 STA 2.1.0 数据库。如果无法完成数据库升级（任务 8：升级旧数据库），则可以恢复空数据库，以将 STA 2.1.0 恢复至可将其配置为以似乎新安装（无数据）的方式运行的状态；有关恢复过程的详细信息，请参见恢复失败的数据库升级（可选）。

1. 在 STA 服务器上打开一个终端会话，然后以系统 root 用户身份登录。

2. 如果尚未执行该操作，则停止所有 STA 服务。

   # STA stop all 
   

3. 启动 MySQL 服务。

   # STA start mysql
   

4. 创建数据库备份文件。在系统提示时，输入数据库 root 用户密码。

   # 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
   

   注:

   不建议使用可选的 –v 参数（用于详细输出），因为终端窗口中会显示大量消息，对于大型数据库，该参数会显著降低命令处理速度。

   在示例 8-4 中，使用文件名 STA_FRESH_INSTALL_BACKUP.sql 将 STA 2.1.0 数据库转储到 STA 服务器上的 /dbdumpfiles 文件夹中。

   示例 8-4 新数据库转储

   # mysqldump -uroot -p --opt --add-drop-database --comments --complete-insert --dump-date --events --flush-logs --routines --single-transaction --triggers --databases stadb >  /dbdumpfiles/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...
   

   注:

   如果看到消息 "Can't connect to local MySQL server"，则表示 MySQL 服务器未运行。请确保启动了 MySQL（步骤 3）。

任务 6：将旧 STA 数据库转移至 STA 服务器

注:

该过程仅适用于单服务器方法。

使用该过程将 STA 1.0.x 或 STA 2.0.x 数据库备份转移至 STA 2.1.0 服务器。

1. 如果尚未执行该操作，则停止所有 STA 服务。

   # STA stop all 
   

2. 转移数据库。为 SCP 启用 –p 选项可保留时间戳值。

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

   在示例 8-5 中，SCP 用于将压缩的数据库转储文件 Dec14_dump.sql.gz 从主机 backup1 上的 /dbdumpfiles 转移至 STA 2.1.0 服务器上的 /dbdumpfiles 文件夹。

   示例 8-5 到新 STA 服务器的旧数据库转移

   # scp -p backup1:/dbdumpfiles/Dec14_dump.sql.gz /dbdumpfiles
   

3. 对转移的文件执行校验和计算。验证校验和值是否与在任务 1：转储旧 STA 数据库 中收到的值匹配。

   # cd /path_to_dump_file/
   # cksum dump_file_name.sql.gz
   

任务 7：处理并装入旧 STA 数据库

使用该过程解压缩 STA 1.0.x 或 STA 2.0.x 数据库并在 STA 2.1.0 服务器上将其重新恢复。解压缩的数据库需要的空间可能是压缩数据库的 10 到 15 倍。

1. 如果尚未执行该操作，则停止所有 STA 服务。

   # STA stop all 
   

2. 解压缩备份文件。

   # gunzip dump_file_name.sql.gz
   

3. 使用以下步骤清除 STA 数据库中的过时数据，如处理的 SNMP 记录和空分析记录。

   时间估计：对于 STA 1.0.x 和 STA 2.0.x，每千兆字节未压缩的数据库快照大小最多需要一分钟。

   注:

   purgerecs 命令活动的永久记录保存在 STA 数据库中。从 STA 2.0 开始，也会在运行时自动清除数据库。MySQL Event Scheduler 会定期从各个表中清除记录，以降低数据库的增长。

   1. 转至 STA 数据库更新目录。

      # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
      

   2. 启动清除。

      # ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/dump_file_name_PURGED.sql
      

      注:

      如需 purgerecs 命令的帮助，请键入以下命令：

      # ./purgerecs -h
      

   在示例 8-6 中，purgerecs 实用程序处理 /dbdumpfiles 中的 MySQL 转储文件 Dec14_dump.sql。输出定向至 /dbdumpfiles 中名为 Dec14_dump_PURGED.sql 的新文件。每处理 200 个记录会显示一个进度点。

   示例 8-6 从旧数据库备份中清除过时的数据

   # cd /Oracle/StorageTek_Tape_Analytics/db/updates
   # ./purgerecs /dbdumpfiles/Dec14_dump.sql /dbdumpfiles/Dec14_dump_PURGED.sql
   ................................................
             STA v1.0.2, Schema 33.02 
   Processed 11,689 lines from '20130711_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. 此步骤是可选的。确定数据库文件大小并估计装入过程时间。

   时间估计：对于 STA 1.0.x 和 STA 2.0.x，每千兆字节未压缩的数据库快照大小最多需要三至十分钟。

   # ls -s -h dump_file_name_PURGED.sql
   

5. 启动 MySQL 服务器。

   # STA start mysql
   

6. 装入 STA 1.0.x 或 STA 2.0.x 数据库。在系统提示时，输入数据库 root 用户密码。除非指定 –v（详细）选项（不建议），否则不会在该过程进行中显示命令输出。

   注:

   不建议使用可选的 –v 参数（用于详细输出），因为终端窗口中会显示大量消息，对于大型数据库，该参数会显著降低命令处理速度。

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

   其中：

   • –p－提示输入在 STA 安装过程中建立的数据库 root 用户密码。

   • –e－执行以下用引号括起来的语句：

     • SET SESSION SQL_LOG_BIN=0;－关闭不必要的二进制日志记录，从而加快装入速度。

     • SOURCE /path_to_dump_file/dump_file_name_PURGED.sql－将转储文件装入数据库。

   如果该命令成功，将在过程完成后返回到命令提示符。

任务 8：升级旧数据库

使用该过程将 STA 1.0.x 或 STA 2.0.x 数据库升级至新 STA 2.1.0 方案。

时间估计：每千兆字节未压缩的数据库快照大小需要的大约时间。

• 从 STA 1.0.x－每千兆字节最多需要五分钟

• 从 STA 2.0.x－每千兆字节最多需要 30 分钟

1. 如果尚未执行该操作，则停止所有 STA 服务。

   # STA stop all 
   

2. 如果在验证升级先决条件 中确定 /tmp 的大小不足够用于升级，则根据需要增加 /tmp 的大小。

   如果该方法不可行，则使用以下步骤设置 MySQL 的环境变量，以使用备用临时位置：

   1. 创建备用临时位置并为其分配开放权限。例如：

      # mkdir /dbbackup/tmp
      # chmod 777 /dbbackup/tmp
      

   2. 停止 MySQL。

      # STA stop mysql
      

   3. 编辑 MySQL 配置文件。例如：

      #  vi /etc/my.cnf
      

   4. 在该文件的 mysqld 部分中，添加用于定义备用临时位置（由 tmpdir 变量指定）的行。下面是添加该行后的文件示例。

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

   5. 重新启动 MySQL。

      # STA start mysql
      

3. 转至数据库更新目录。

   # cd /Oracle_storage_home/StorageTek_Tape_Analytics/db/updates
   

4. 启动升级脚本，并在系统提示时输入数据库 root 用户密码。出于安全方面的考虑，屏幕上不显示密码。

   # ./upgradedb.sh
   

   注:

   可以系统 root 用户或 Oracle 安装用户身份执行该步骤。

   下面是一个屏幕显示示例。

   # ./upgradedb.sh
   
   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...
   

   该过程完成时，会显示类似于以下内容的标题。

   注意:

   等到能看到该标题时再继续执行。
   

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

5. 如果在任务 8：升级旧数据库 中增加了 /tmp 的大小或创建了备用临时位置，则将其恢复至其正常大小和位置。

6. 启动所有 STA 服务。

   # STA start all
   

7. 此步骤是可选的。删除 STA_FRESH_INSTALL_BACKUP.sql 文件以释放 STA 数据库备份卷上的磁盘空间。

任务 9：配置新 STA 版本

使用这些过程配置磁带库和 STA 2.1.0，以便 STA 可以开始监视磁带库活动。

在磁带库上更新 STA 陷阱接收方

STA 2.0.x 中引入了两个新陷阱级别 13（测试陷阱）和 14（运行状况陷阱）。对每个受监视的磁带库执行以下步骤，以确保在 STA 陷阱接收方定义中包含这些陷阱级别。

1. 根据升级路径，按如下所示继续操作：

   • 如果要使用单服务器方法从 STA 2.0.x 进行升级，则转至在 STA 中配置 SNMP 设置。

   • 如果要使用单服务器方法从 STA 1.0.x 进行升级，则转至步骤 2，将新陷阱级别添加至每个受监视磁带库上的现有 STA 陷阱接收方。

   • 如果要使用双服务器升级方法，则转至步骤 3，将新 STA 陷阱接收方添加至每个受监视的磁带库。

2. 如果要使用单服务器方法从 STA 1.0.x 进行升级，则使用磁带库型号的相应步骤将新陷阱级别添加至 STA 陷阱接收方。

   对于除 SL150 之外的所有磁带库型号，要修改陷阱接收方，必须删除现有定义，然后添加新定义。

   除 SL150 之外的所有磁带库 

   1. 登录到磁带库 CLI。

   2. 显示所有现有陷阱接收方，并记下 STA 接收方的索引号。

      snmp listTrapRecipients
      

   3. 删除 STA 陷阱接收方。

      snmp deleteTrapRecipient id index
      

      其中：

      • index 是 STA 陷阱接收方的索引号。

   4. 重新添加 STA 陷阱接收方并在陷阱级别列表中包含新陷阱级别。有关说明，请参见创建 STA SNMP v3 陷阱接收方 或在磁带库上创建 STA SNMP v2c 陷阱接收方。

   SL150 磁带库 

   1. 登录到基于浏览器的用户界面。

   2. 从 SNMP 菜单中，选择 SNMP Trap Recipients。

   3. 从列表中选择 STA 陷阱接收方。

   4. 选择 Modify Trap Recipient。

   5. 将新陷阱级别添加至陷阱级别列表，然后单击 Save。

3. 如果要使用双服务器升级方法，则在每个磁带库上作为陷阱接收方添加新 STA 2.1.0 服务器。请参见创建 STA SNMP v3 陷阱接收方 或在磁带库上创建 STA SNMP v2c 陷阱接收方。

在 STA 中配置 SNMP 设置

为所有升级执行这些步骤。在 STA 中执行这些步骤。

1. 以 STA 管理员用户身份登录到 STA。

2. 使用在升级之前记录的值重新输入 STA SNMP 客户机的配置设置；请参见记录当前 STA 用户和配置设置（可选）。这些值必须与在受监视磁带库上配置的值相匹配。有关说明，请参见配置 STA 的 SNMP 客户机设置。

3. 要恢复 STA 与磁带库之间的 SNMP 通信，请测试到每个受监视磁带库的连接。有关说明，请参见测试磁带库 SNMP 连接。

   注:

   该步骤成功完成后，STA 开始接收并处理来自每个受监视磁带库的数据。

   对于在停止 STA 或恢复磁带库连接时正在进行的交换，您可能会在 "Exchanges Overview" 屏幕上发现未完成的交换。有关未完成的交换的详细信息，请参见《STA 用户指南》。

4. 从每个磁带库获取最新的 SNMP 磁带库配置数据。有关说明，请参见执行手动数据收集。

配置 STA 服务和用户信息

针对所有升级执行这些步骤。在 STA 服务器上执行这些步骤。

如果您希望保留以前 STA 版本的设置，则使用在升级之前记录的值；请参见记录当前 STA 用户和配置设置（可选）。

注:

在升级之后，STA 拥有所有逻辑组。逻辑组所有权对于 STA 正常运行并非至关重要，具有 Operator 或 Administrator 特权的任何 STA 用户都可以修改逻辑组。

1. 配置 STA 备份服务和 STA 资源监视器服务实用程序。有关详细信息，请参见第 7 章 配置 STA 服务。

2. 创建 STA 用户名和密码；有关说明，请参见《STA 用户指南》。您可能还需要执行以下操作：

   • 向用户通知 STA 2.1.0 的新密码要求。

   • 指示用户重新输入其定制用户首选项（如果适用）。

3. 如果 STA 电子邮件服务器要求验证，则必须输入电子邮件帐户用户名和密码；有关说明，请参见《STA 用户指南》。

4. 为定制模板恢复原始所有权（如果适用）；有关说明，请参见《STA 用户指南》。

5. 为专用主管报告策略恢复原始所有权（如果适用）；有关说明，请参见《STA 用户指南》。

使旧 STA 服务器退役（可选）

仅当您使用了双服务器升级方法时该过程才适用。可以在确认新 STA 服务器正常运行后使用该过程。

1. 从每个磁带库的 SNMP 配置中删除作为陷阱接收方的旧 STA 1.0.x 或 STA 2.0.x 服务器。有关说明，请参见《STA 用户指南》。

2. 使旧 STA 1.0.x 或 STA 2.0.x 服务器退役。

恢复失败的数据库升级（可选）

注意:

仅在 Oracle 支持代表的指导下执行该过程。

仅当任务 8：升级旧数据库 中的数据库升级未成功完成且重复升级的尝试也失败时才使用该过程。

1. 重复任务 7：处理并装入旧 STA 数据库 的步骤 6 至任务 8：升级旧数据库。

   如果升级再次失败，则数据库处于未知、可能损坏的状态，应将数据库恢复至其原始的全新安装状态。继续执行下一步。

2. 删除损坏的升级后数据库。

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

3. 转至 STA 数据库备份位置，并装入在任务 5：转储新 STA 数据库（可选） 中创建的新安装数据库转储文件。

   例如：

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

4. 执行任务 8：升级旧数据库。

5. 作为新安装配置 STA。有关详细信息，请参见以下各部分：

   • 在 STA 中配置磁带库连接

   • 配置 STA 服务