本章详细讲述了各种 STA 服务管理。要首次配置这些服务，请参见《STA 安装和配置指南》。
本章包括以下几节：
STA 服务守护进程 staservd 是连续运行的 Linux 服务，可以管理和运行 STA 备份和 STA 资源监视器服务。STA 备份和 STA 资源监视器服务将作为 STA 服务守护进程内的单独执行线程来运行。
STA 服务器引导（使用 STA start all 命令）时 STA 服务守护进程启动，该服务器关闭时该守护进程终止。您还可以使用以下命令启动、停止 STA 服务守护进程并检查其状态：
启动 STA 服务守护进程：
# STA start staservd
Starting staservd Service...
staservd service was successfully started
停止 STA 服务守护进程：
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
检查 STA 服务守护进程的状态：
# STA status staservd
staservd service is running
有关 STA 命令的更多信息，请参见第 1 章 服务器管理
注:
安装 STA 后，STA 服务守护进程启动 STA 备份和 STA 资源监视器服务，但在对这些服务进行配置后才将其激活。要配置这些服务，请参见《STA 安装和配置指南》。STA 备份服务是 STA 服务守护进程内运行的多个服务之一。它执行 STA 数据库和关键配置目录的自动完全备份，将这些文件写入 STA 服务器上的指定位置或者以压缩格式写入远程服务器。Oracle 建议您配置远程备份服务器。
继续之前，请验证 STA 服务守护进程是否正在运行。请参见STA 服务守护进程。
STA 备份服务使用其管理实用程序 staservadm 进行配置，该实用程序位于 /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin 中。要配置 STA 备份服务，请参见《STA 安装和配置指南》。
配置后，STA 备份服务每 24 小时执行一次以下过程：
启动以下文件类型的高速转储（也称为热备份）：
MySQL 数据库转储文件
MySQL 二进制日志文件
STA 服务守护进程和 STA WebLogic 配置文件
STA 服务守护进程和 STA 备份服务管理日志
将转储文件传输到指定的备份主机
从 STA 服务器中删除前一日的完全转储文件
将当日转储文件的副本写入 STA 服务器上的 /sta_db_backup/local 目录。
显示当前首选项设置的状态。
# ./staservadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Backup Service Settings: Configured [yes] File Transfer –S [SCP] Full Backup –T [11:00] Sleep Interval –i [350 sec] Backup Hostname –s [stabaksvr] Backup Username –u [stabck] Backup Password –p [*******] Backup Directory –d [/home/stabck/STAbackups] Database Username –U [stadba] Database Password –P [*********]
如果 Configured 字段为 [no]，则备份服务正在 "idle" 模式下运行，将不执行任何备份。必须提供适当的配置设置；有关详细信息，请参见《STA 安装和配置指南》。
清除当前首选项设置。
# ./staservadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Backup Service Settings: Configured [no] File Transfer –S [SCP] Full Backup –T [00:00] Sleep Interval –i [300 sec] Backup Hostname –s [] Backup Username –u [] Backup Password –p [] Backup Directory –d [] Database Username –U [] Database Password –P []
备份服务将不再进行配置并且将返回到 "idle" 状态。现在可以提供新设置，有关详细信息，请参见《STA 安装和配置指南》。
验证文件已经成功发送到目标服务器：
检查 STA 服务器上的日志。
登录到目标备份服务器并列出备份目录的内容。
以系统 root 用户身份登录到 STA 服务器。
更改为 STA 数据库备份日志目录。
# cd /sta_logs/db/backups
搜索 staservd.log.0 文件中的以下字符串："INFO: done. Database dump completed"。此文件注册备份服务配置实用程序的活动。
# grep "INFO: done.Database dump completed" staservd.log.0
INFO: done. Database dump completed, file located at /dbbackup/local/20130721_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130722_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130723_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130724_133755.stafullbackup.sql
登录到目标备份服务器。
列出数据库备份目录中的文件。
在此示例中，目录 /backups/tbivb01 已在之前进行了设置来从 STA 服务器 "tbivb01" 接收备份文件。
# ls –1 /backups/tbivb01
0.stadb-bin.000023.gz 0.stadb-bin.000024.gz 0.stadb-bin.000026.gz 0.stadb-bin.000027.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000025.gz 20130723_133755.stadb-bin.000026.gz 20130723_133755.stafullbackup.sql.gz
通过列出 /sta_db_backup/local 目录中的文件验证最新备份文件的副本已经保存在 STA 服务器本地。例如：
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
所列文件的名称格式为 YYYYMMDD_HHMMSS.filename.zip。
请参见第 3 章 密码管理。
STA 资源监视器服务监视和报告 STA 服务器资源，包括数据库表空间和磁盘卷空间、日志记录卷磁盘空间和物理内存使用情况。
可以为每个资源设置使用高水位标志 (high watermark, HWM)。高水位标志是一个阈值，在此处将发出警报。达到或超过该阈值时，将在标准每日资源报告中记录一条警报并可以选择将该警报通过电子邮件发送给一个或多个指定收件人。
例如，如果将数据库表空间 HWM 设置为 60%，当 STA 资源监视器检测到 STA 应用程序已经使用了最大允许数据库表空间的 60% 或更多时，它会开启表空间警报并向指定收件人发送电子邮件。此外，如果开启 nag 模式，资源监视器会在其每次扫描系统时发送警报电子邮件。
STA 资源监视器服务使用其管理实用程序 staresmonadm 进行配置，该实用程序位于 /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin 中。要配置 STA 资源监视器服务，请参见《STA 安装和配置指南》。
输入以下命令来查询首选项设置的当前状态：
# ./staresmonadm –Q
如果 "Configured" 字段为 "no"，则资源监视器服务正在 "idle" 模式下运行，既不监视资源也不发送报告。将需要配置服务器；有关详细信息，请参见《STA 安装和配置指南》。
配置的 STA 资源监视器服务的输出示例：
# ./staresmonadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Resource Monitor Service Settings: Configured [yes] Send Reports –T [13:00] Sleep Interval –i [600 sec] Alert Nagging –n [on] DB Username –U [sta_dba] DB Password –P [*********] DB Tablespace hwm –t [65%] DB Backup hwm (/dbbackup) –b [65%] DB Data hwm (/dbdata) –d [65%] Log Volume hwm (/var/log/tbi) –l [65%] Root Volume hwm (/) –z [70%] Tmp Volume hwm (/tmp) –x [80%] System Memory hwm –m [75%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [john.doe@company.com] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
输入以下命令来清除当前首选项设置：
# ./staresmonadm –C
资源监视器服务将不再进行配置并且将返回到 "idle" 状态。现在可以提供新设置，有关详细信息，请参见《STA 安装和配置指南》。例如：
# ./staresmonadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Resource Monitor Service Settings: Configured [no] Send Reports –T [00:00] Sleep Interval –i [300 sec] Alert Nagging –n [off] DB Username –U [] DB Password –P [] DB Tablespace hwm –t [–1%] DB Backup hwm (/dbbackup) –b [–1%] DB Data hwm (/dbdata) –d [–1%] Log Volume hwm (/var/log/tbi) –l [–1%] Root Volume hwm (/) –z [–1%] Tmp Volume hwm (/tmp) –x [–1%] System Memory hwm –m [–1%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
请参见第 3 章 密码管理
资源监视器报告将使用 STA 资源监视器服务管理实用程序 staresmonadm 进行配置。要配置 STA 资源监视器服务，请参见《STA 安装和配置指南》。
资源监视器可以生成两个不同报告：
资源监视器标准报告大约在 staresmonadm –T 选项指定的时间一天发送一次。如果您没有设置时间，将在午夜第一次扫描时发送报告。报告将发送到您配置此服务时指定的电子邮件收件人。
报告提供以下服务器资源的数据。如果这些资源中的任何资源超过了高水位标志阈值，报告中将显示警报。
数据库表空间和卷
日志记录、备份和根卷
临时目录
系统内存使用情况
注:
报告的值依赖于挂载点。如果多个受监视项共享同一挂载点，这些项的报告值将相同。STA RESOURCE MONITOR STANDARD REPORT System: tbivb03 Scanned: 2013-10-24 11:30:14 Database Tablespace HWM : 60.00% Used : <0.1% MB Used : 13 MB Free : 75763 MB Total : 75776 Location : /dbdata/mysql Database Volume HWM : 60.00% Used : 6.80% MB Used : 6855 MB Free : 93939 MB Total : 100794 Directory : /dbdata/mysql ...
如果 staresmonadm 警报 nag 模式 (–n) 选项设置为 "on"，将在每次扫描后发送资源耗尽警报报告。如果 nag 模式为 "off"，则仅在标准报告中显示警报。
每次扫描之间的时间间隔由 "Sleep Interval" (–i) 属性确定，报告将发送到您配置此服务时指定的电子邮件收件人。报告中提供了建议来帮助解决指示的问题。
STA RESOURCE DEPLETION REPORT
System: server01
Scanned: 2013-10-24 11:34:47
************************************************************
* A L E R T S *
************************************************************
==================================================
ALERT – Low System Physical Memory
==================================================
Physical memory usage has exceeded threshold value!
HWM [1.00%]
Used [48.24%] (!)
MB Used [7757]
MB Free [8324]
MB Total [16080]
Hostname [server01]
Recommendations:
1) Shutdown unneeded processes.
2) Under Linux, try releasing unused caches using commands:
# free –m
# sync
# /sbin/sysctl –q vm.drop_caches=3
# free –m
3) Install additional memory.
STA 服务包含可执行脚本、包含服务器和客户机应用程序的 Java jar 文件、配置文件、转储文件、日志记录文件和累积数据文件。本节介绍了它们的用途和位置。
STA 服务守护进程启动和关闭脚本 staservd 以及系统运行级别符号链接位于以下目录中。此脚本及其关联符号链接由 STA 安装程序创建。
/etc/init.d/staservd－主启动和关闭脚本
/etc/rc0.d/K04staservd－用于系统关闭的符号链接
/etc/rc1.d/K04staservd－用于系统关闭的符号链接
/etc/rc2.d/S96staservd－用于系统启动的符号链接
/etc/rc3.d/S96staservd－用于系统启动的符号链接
/etc/rc4.d/S96staservd－用于系统启动的符号链接
/etc/rc5.d/S96staservd－用于系统启动的符号链接
/etc/rc6.d/K04staservd－用于系统关闭的符号链接
STA 备份服务管理实用程序 staservadm 是一个 Perl 脚本，其调用 oracle.tbi.serveradm.jar 文件中包含的名为 ServerAdm 的 Java 客户机应用程序。有关更多信息，请参见STA 备份服务。
STA 资源监视器管理实用程序 staresmonadm 是一个 Perl 脚本，其调用 oracle.tbi.resmonadm.jar 文件中包含的名为 StaResMonAdm 的 Java 客户机应用程序。StaResMonAdm 是一个 RMI 客户机，其与 STA 服务守护进程通信来设置和重置运行时首选项。有关更多信息，请参见STA 资源监视器服务。
表 2-1 列出了可执行程序及其位置。
| 程序 |
位置 |
|---|---|
|
STA 服务程序 jar 文件 |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
STA 备份服务管理实用程序 Java 应用程序 jar 文件 |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
STA 备份服务管理实用程序用户脚本文件 staservadm |
$STAHOME/common/bin/staservadm |
|
STA ResMon 管理实用程序 Java 应用程序 jar 文件 |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
STA ResMon 管理实用程序 Java 用户脚本文件 staresmonadm |
$STAHOME/common/bin/staresmonadm |
其中：
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
STA 数据库备份包括以下类型的文件：
这些文件记录 STA 服务守护进程服务器 STAServer 及其备份服务配置实用程序 ServerAdm 的活动。管理日志是最多 10 个日志文件的集合，每个文件大小最大 1.0 MB。日志文件名的格式为 *.log.N，其中 N 是日志编号（staservd.log.0、staservadm.log.0、staservd.log.1 等）。
这些日志会轮转，从而当 staservd.log.9 已经写满时将重用日志文件 #1。活动的日志文件始终为 #0 (staservd.log.0)。日志 #0 写满时，其重命名为日志 #1，新日志 #0 将开始。默认情况下，STAServer 和 ServerAdm 日志位于以下目录中：
/STA_logs/db/backups
STA_logs 的默认位置为 /var/log/tbi。
日志位置和内部格式（简单 ASCII 文本或 XML 标记）由位于以下位置的日志记录属性文件 staservd.log.props 和 staservadm.log.props 控制：
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
其中：
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
MySQL 数据库转储文件是数据库方案和数据内容的实时快照。STA 备份服务执行以下操作：
对本节中讨论的文件类型每 24 小时启动一次高速转储（有时称为热备份）。
将最新转储文件传输到指定的备份主机。
从本地备份目录中删除前一日的完全转储文件。
将当日转储文件的副本写入本地备份目录。
默认情况下，STA 备份服务将其本地转储文件和增量 binlog 文件放入 /sta_db_backup/local 目录中，格式为 YYYYMMDD_HHMMSS.filename.sql。
术语增量转储是指 MySQL 二进制日志 (binary log, binlog)，其记录导致会对数据库进行更改的所有事务。STA 备份服务将 binlog 视为主数据库转储之后的增量备份。
STA 增量备份包含自上次完全转储以来生成的所有二进制日志。通过重放 binlog，可以将数据库恢复到日志中记录的最后事务的状态。恢复操作包括装入最新转储文件，然后按顺序重放在最新数据库转储后生成的所有 MySQL binlog。
备份 binlog 包含生成自最新完全转储以来创建的所有 binlog 的列表，然后将这些日志中的每个日志（除了当前日志，因为其仍处于打开状态）传输到备份服务器。
备份二进制日志命名格式为 YYYYMMDD_HHMMSS.stadb–bin.log_sequence_number。
MySQL 二进制日志位置在 MySQL 设置文件 /etc/my.cnf 中定义。该位置当前设置为：
/STA_logs/db
备份 binlog 文件的本地副本位于：
/sta_db_backup/local
将使用 MySQL 命令 PURGE BINARY LOGS BEFORE NOW() 清除成功传输到备份服务器的所有 binlog（最新 binlog 除外）。从而，最新 binlog 和当日的完全备份文件仍位于服务器上。
注意:
从不手动删除 binlog 文件。除了恢复 STA 应用程序数据库所需的文件外，STA 备份服务还备份 STA WebLogic 配置文件以及该文件自己的 STA 服务守护进程配置文件。备份是相应配置目录中的所有文件和目录的递归备份。
执行完全 STA 数据库转储后每 24 小时执行一次配置文件备份。备份文件名称格式为 YYYYMMDD_HHMMSS.filename.zip.gz。
这些备份的源和目标位置显示在表 2-2 中：
| 源位置 |
本地副本 |
远程副本 |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/YYYYMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/YYYYMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.fmconfig.zip.gz |
其中：
$STAHOME = /Oracle_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = 备份服务器 IP 地址或名称
$RDIR = 备份服务器上的目录
监视操作中涉及两种文件：
这些文件记录 STA 服务守护进程和资源监视器管理实用程序 staresmonadm 的活动。这些日志是最多 10 个日志文件的集合，每个文件大小最大 1.0 MB。日志文件名的格式为 *.log.N，其中 N 是日志编号（staservd.log.0、staservadm.log.0、staservd.log.1 等）。
这些日志会轮转，从而当 staservd.log.9 已经写满时将重用日志文件 #1。活动的日志文件始终为 #0 (staservd.log.0)。日志 #0 写满时，其重命名为日志 #1，新日志 #0 将开始。默认情况下，STA 服务、STA ResMon 和 STA ResMonAdm 日志都位于：
/STA_logs/db/backups
日志位置和内部格式（简单 ASCII 文本或 XML 标记）由位于以下位置的日志记录属性文件 staservd.log.props 和 staresmonadm.log.props 控制：
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
其中：
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
每次 ResMon 扫描系统时，它将收集的值写出到逗号分隔值 (comma-separated-value, CSV) 文件，默认情况下该文件位于：
/STA_logs/db/staresmon.csv
Excel 和 MySQL 等程序可以装入此数据文件并使用基于时间的值执行各种分析和图形功能（例如，资源耗尽趋势分析）。
注:
ResMon CSV 文件不会被 STA 备份服务清除、滚动或备份。staresmon.csv 中的每个记录表示一次系统扫描。21 列记录的格式显示在表 2-3 中。
| 列 |
标题 |
描述 |
格式 |
|---|---|---|---|
|
1 |
TIMESTAMP |
扫描的日期和时间 |
"YYYY–MM–DD HH:MM:SS" |
|
2 |
TS_MB_MAX |
最大表空间 |
123 |
|
3 |
TS_MB_USED |
已用数据库空间总计 |
123 |
|
4 |
TS_MB_AVAIL |
剩余数据库空间 |
123 |
|
5 |
TS_PCT_USED |
以最大空间的百分比表示的已用数据库表空间 |
12.34% |
|
6 |
TS_PCT_HWM |
以最大空间的百分比表示的数据库表空间高水位标志 |
12.34% |
|
7 |
DBVOL_MB_MAX |
包含数据库的卷上的最大可用空间 |
123 |
|
8 |
DBVOL_MB_USED |
已用数据库磁盘卷空间总计 |
123 |
|
9 |
DBVOL_MB_AVAIL |
剩余数据库卷磁盘空间 |
123 |
|
10 |
DBVOL_PCT_USED |
以最大空间的百分比表示的已用数据库卷磁盘空间 |
12.34% |
|
11 |
DBVOL_PCT_HWM |
以最大空间的百分比表示的数据库卷高水位标志 |
12.34% |
|
12 |
LOGVOL_MB_MAX |
包含日志的卷上的最大可用空间 |
123 |
|
13 |
LOGVOL_MB_USED |
已用日志记录磁盘卷空间总计 |
123 |
|
14 |
LOGVOL_MB_AVAIL |
剩余日志记录卷磁盘空间 |
123 |
|
15 |
LOGVOL_PCT_USED |
以最大空间的百分比表示的已用日志记录卷磁盘空间 |
12.34% |
|
16 |
LOGVOL_PCT_HWM |
以最大空间的百分比表示的日志记录卷高水位标志 |
12.34% |
|
17 |
MEM_MB_MAX |
最大已安装物理 RAM |
123 |
|
18 |
MEM_MB_USED |
已用物理内存总计 |
123 |
|
19 |
MEM_MB_AVAIL |
剩余物理内存空间 |
123 |
|
20 |
MEM_PCT_USED |
以最大空间的百分比表示的已用物理内存空间 |
12.34% |
|
21 |
MEM_PCT_HWM |
以最大空间的百分比表示的物理内存高水位标志 |
12.34% |
对 STA 服务守护进程、备份服务、备份服务管理实用程序和 STA 资源监视器实用程序的日志记录由位于以下位置的日志记录配置文件进行控制：
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
其中，$STA_HOME 是在 STA 安装过程中指定的 STA 主目录位置；有关详细信息，请参见《STA 安装和配置指南》。
日志记录文件内容和格式由这些文件中的 Java Log Manage 属性控制。表 2-4 汇总了这些属性。有关更多详细信息，请参见以下站点的 Oracle Java SE 文档：
http://docs.oracle.com/en/java/
| 属性 |
描述 |
STA 设置 |
|---|---|---|
|
java.util.logging.FileHandler.append |
指定文件处理程序是否应附加到现有文件。默认为 false。 |
true |
|
java.util.logging.FileHandler.count |
指定要重复循环的输出文件数量。默认为 1。 |
10 |
|
java.util.logging.FileHandler.formatter |
指定格式化程序类名。默认为 java.util.logging.XMLFormatter。 |
Java.util.logging.SimpleFormatter 实现人工可读性。java.util.logging.XMLFormatter 将被注释掉并处于可用状态 |
|
java.util.logging.FileHandler.level |
指定处理程序的默认级别。默认为 Level.ALL。 |
CONFIG |
|
java.util.logging.FileHandler.limit |
指定要写入任何一个文件的大约最大字节数。条目零表示无限制。默认为 no limit。 |
500000 (.5 MB) |
|
java.util.logging.FileHandler.pattern |
指定输出文件名模式。默认为 "%h/java%u.log"。 |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g 其中，STA_logs 是在 Linux 安装过程中建立的日志位置；有关详细信息，请参见《STA 安装和配置指南》。 |
日志级别由这些文件中的 STA 日志记录属性控制。表 2-5 汇总了这些属性。
STA 数据库恢复过程包括装入最新的完全数据库转储，然后重放紧跟在该转储之后的所有二进制日志。
备份服务器目录中存在不同备份文件集。例如：
# cd /data/stabackups
# ls –1
20130721_133755.conf.zip.gz 20130721_133755.fmwconfig.zip.gz 20130721_133755.stadb-bin.000024.gz 20130721_133755.stafullbackup.sql.gz 20130722_133755.conf.zip.gz 20130722_133755.fmwconfig.zip.gz 20130722_133755.stadb-bin.000024.gz 20130722_133755.stafullbackup.sql.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000021.gz 20130723_133755.stadb-bin.000022.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.stadb-bin.000024.gz 20130723_133755.stafullbackup.sql.gz
文件名时间戳格式为 YYYYMMDD_HHMMSS。装入完全转储后，会将具有相同日期标记的所有二进制日志重放到数据库中。
此处讨论了以下管理任务：
使用此过程可将备份文件复制到 STA 服务器。
将一天的完整文件集复制回 STA 服务器。
Oracle 建议将所有内容都复制到 /tmp 目录。例如，假定在服务器 sta.server.com 上安装了 STA 并且您当前登录到了备份服务器。
# scp 20130723*.* sta.server.com:/tmp/.
Password:
以 root 用户身份登录到 STA。
解压缩 *.gz 文件。例如：
# cd /tmp
# gunzip 20130723*.*.gz
使用此过程可恢复配置目录文件。
停止所有 STA 进程。然后，仅重新启动 MySQL 服务器。
# STA stop all
# STA start mysql
解压缩 STAServer 和 STA 服务守护进程配置目录。
zip 文件是使用完整目录路径创建的，从而您可以恢复或覆盖现有文件。通过 unzip 命令，您可以使用 –d 选项重新达到恢复路径的根目录。使用其他选项可以进行更多控制，例如选择性替换。
对于全新恢复，您应该完全替换现有配置目录；但是需要首先备份原始配置目录。例如：
# cd $WLSHOME
# zip –vr fmwconfig.orig.zip fmwconfig
# rm –rf fmwconfig
# cd /tmp
# unzip –X –d/ 20130723_133755.fmwconfig.zip
# cd $STAHOME/common
# zip –vr conf.orig.zip conf
# rm –rf conf
# cd /tmp
# unzip –X –d/ 20130723_133755.conf.zip
其中：
$WLSHOME =/Oracle_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
以 MySQL root 用户身份执行以下命令。
重新装入数据库：
清除存在的任何残余 stadb 数据库。例如：
# mysql –uroot –p –e 'drop database stadb;'
Password:
装入最新的完全转储。这将创建方案并安装所有数据。例如：
# mysql –uroot –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
重放 binlog：
运行每个增量转储 (binlog)，从最新到最旧：
如果要在 MySQL 服务器上执行多个二进制日志，最安全的方法是使用与该服务器的单个连接处理所有日志并使用单个 MySQL 进程执行所有二进制日志的内容。
例如：
# mysqlbinlog 20130723_133755.sta-binlog.000021 \
> 20130723_133755.sta-binlog.000022 \
> 20130723_133755.sta-binlog.000023 \
> 20130723_133755.sta-binlog.000024 |mysql –u root –p
另一种方法是将所有日志串联到单个文件中，然后处理该文件：
# mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql
# mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql
# mysql –u root –p –e 'source /tmp/recoversta.sql'
注:
如果您没有在命令行上提供密码，MySQL 会在继续操作之前提示您输入密码。以 Linux 系统 root 用户身份，输入以下命令：
# STA start all
另一种恢复方法是时间点，可以从特定开始时间点到特定结束时间点重放二进制日志。
例如，检查二进制日志的内容后，您发现紧跟在日志条目 #6817916 之后的一个错误操作导致删除了多个表。在从前一日完成的完全转储恢复数据库后，在重新启动所有 STA 服务之前，您可以使用此过程中显示的命令重放最新的二进制日志，从其初始日志条目编号 "176" 到条目编号 "6817916"。
使用此过程可从日志编号范围恢复 STA 数据库。
确保所有 STA 进程都已关闭，仅 MySQL 服务器正在运行：
# STA stop all
# STA start mysql
以 MySQL root 用户身份，提取有效操作。例如：
# mysqlbinlog ––start–position=176 ––stop–position=6817916
/var/log/tbi/db/stadb–bin.000007 > ./recover.sql
将其应用于数据库。例如：
# mysql –uroot –p –e 'source ./recover.sql'
Password:
以 Linux 系统 root 用户身份，重新启动 STA 应用程序和 STA 服务守护进程：
# STA start all
有关时间点或增量恢复操作的更多信息，请参阅以下站点的 MySQL 文档：