Skip Headers
StorageTek Tape Analytics Guía de administración
Versión 2.0
E53285-01
  Ir a Tabla de Contenido
Contenido
Ir a Índice
Índice

Anterior
Anterior
 
Siguiente
Siguiente
 

3 Administración de servicios de bases de datos

En este capítulo, se describe en detalle la administración de los diferentes servicios de STA. Para la configuración inicial de estos servicios, consulte el capítulo ”Configuración de servicios de STA” en la Guía de instalación y configuración de STA.

3.1 Daemon de servicios de STA

El daemon de servicios de STA, staservd, es un servicio de Linux que se ejecuta de manera continua y es responsable de la gestión y la ejecución del servicio copias de seguridad de STA y el servicio de supervisión de recursos de STA. Tanto el servicio de copias de seguridad de STA como el servicio de supervisión de recursos de STA se ejecutan como procesos de ejecución independientes en el daemon de servicios de STA.

El daemon de servicios de STA se inicia cuando el servidor de STA arranca (con el comando STA start all) y termina cuando se apaga el servidor. También puede iniciar, detener y controlar el estado del daemon de servicios de STA con los siguientes comandos:

  • Para iniciar el daemon de servicios de STA:

    # STA start staservd
    Starting staservd Service...
    staservd service was successfully started
    
  • Para detener el daemon de servicios de STA:

    # STA stop staservd
    Stopping the staservd Service...
    Successfully stopped staservd service
    
  • Para comprobar el estado del daemon de servicios de STA:

    # STA status staservd
    staservd service is running
    

Para obtener más información acerca del comando STA, consulte Capítulo 2, "Administración del servidor."


Nota:

Después de la instalación de STA, se inicia el daemon de servicios de STA junto con los servicios de copia de seguridad y supervisión de recursos de STA, pero no se los activa hasta que se los configure. Para configurar estos servicios, consulte el capítulo "Configuración de servicios de STA" en la Guía de instalación y configuración de STA.

3.2 Servicio de copia de seguridad de STA

El servicio de copia de seguridad de STA es uno de varios servicios que se ejecutan en el daemon de servicios de STA. Realiza una copia de seguridad completa automática de la base de datos y los directorios de configuración clave de STA y escribe los archivos en una ubicación especificada del servidor de STA o en forma comprimida en un servidor remoto. Oracle recomienda configurar un servidor de copia de seguridad remoto.

Antes de continuar, asegúrese de que el daemon de servicios de STA se esté ejecutando. Consulte "Daemon de servicios de STA".

3.2.1 Configuración

El servicio de copia de seguridad de STA se configura mediante la utilidad de administración, staservadm, que se encuentra en /Oracle/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de copia de seguridad de STA, consulte el capítulo ”Configuración de servicios de STA” en la Guía de instalación y configuración de STA.

3.2.2 Proceso de copia de seguridad completa

Una vez configurado, el servicio de copia de seguridad de STA lleva a cabo el siguiente proceso una vez cada 24 horas:

  1. Inicia un volcado de alta velocidad (también denominado ”copia de seguridad en caliente”) de los siguientes tipos de archivo:

    • Archivo de volcado de base de datos MySQL

    • Archivos de log binarios de MySQL

    • Archivos de configuración del daemon de servicios de STA y WebLogic de STA

    • Logs de administración del daemon de servicios de STA y el servicio de copia de seguridad de STA

  2. Transfiere el archivo de volcado al host de copia de seguridad designado

  3. Suprime del servidor de STA los archivos de volcado completo del día anterior

  4. Escribe una copia de los archivos de volcado del día en curso en el directorio /dbbackup/local del servidor de STA.

3.2.3 Visualización de la configuración de preferencias del servicio de copia de seguridad

Introduzca el siguiente comando para ver el estado de la configuración actual de las preferencias:

# ./staservadm -Q

Si el campo "Configured" (Configurado) dice ”no,” significa que el servicio de copia de seguridad se está ejecutando en el modo ”inactivo” y no se está realizando ninguna copia de seguridad. Deberá proporcionar los parámetros de configuración adecuados, según se indica en la Guía de instalación y configuración de STA.

Ejemplo de salida de un servicio de copia de seguridad de STA configurado:

# ./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 [*********]

3.2.4 Borrado de configuración de preferencias

Introduzca el siguiente comando para borrar la configuración actual de las preferencias:

# ./staservadm -C

El servicio de copia de seguridad ya no está configurado y regresará al estado ”inactivo”. Ahora puede proporcionar una nueva configuración según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics. Por ejemplo:

# ./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 []

3.2.5 Verificación del envío de archivos al servidor de destino

Para verificar que los archivos se hayan enviado correctamente:

  • Compruebe los logs del servidor de STA.

  • Inicie sesión en el servidor de copia de seguridad de destino y muestre el contenido del directorio de copia de seguridad.

3.2.5.1 Comprobación de logs de servidor y servidor de copia de seguridad de destino

El archivo staservd.log.0 registra las actividades de la utilidad de configuración de los servicios de copia de seguridad.

  1. Cambie el directorio de trabajo al directorio de log de copia de seguridad de STA.

    # cd /var/log/tbi/db/backups
    
  2. Busque en el archivo staservd.log.0 la cadena ”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
    
  3. Inicie sesión en el servidor de copia de seguridad de destino.

  4. Muestre una lista de los archivos. En este ejemplo, el directorio /backups/tbivb01 fue configurado para recibir los archivos de copia de seguridad del servidor de 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
    

3.2.6 Verificación de la existencia de una copia local de los archivos de copia de seguridad en el servidor

Para verificar que se haya guardado una copia de los archivos de la copia de seguridad más reciente de manera local en el servidor de STA, muestre una lista de los archivos del directorio /dbbackup/local:

# ls -l /dbbackup/local
20130721_133755.conf.zip
20130721_133755.fmwconfig.zip
20130721_133755.stafullbackup.zip

Los archivos enumerados tendrán el formato AAAAMMDD_HHMMSS.nombre del archivo.zip.

3.2.7 Restablecimiento de la contraseña del servicio de copia de seguridad de STA

Consulte Capítulo 4, "Administración de contraseñas".

3.3 Servicio de supervisión de recursos de STA

El servicio de supervisión de recursos de STA, como su nombre lo indica, supervisa los recursos del servidor de STA, incluidos el espacio de tablas de la base de datos y el espacio de volumen de disco, el espacio de disco de volumen de log y el uso de memoria física, y genera los informes correspondientes.

Es posible configurar límites superiores (HWM) de uso para cada recurso. Un límite superior es un umbral que, cuando se lo alcanza, hace que se genere una alerta. Cuando se alcanza o se excede este umbral, se registra una alerta en el informe de recursos diario estándar y, de manera opcional, se la envía por correo electrónico a uno o varios destinatarios designados.

Por ejemplo, si el espacio de tablas de la base de datos tiene un HWM del 60%, cuando el supervisor de recursos de STA detecta que la aplicación de STA ha utilizado el 60% o más del espacio de tablas de base de datos máximo permitido, activa la alerta de espacio de tablas y envía un correo electrónico a los destinatarios designados. Asimismo, si el modo de insistencia está activado, el supervisor de recursos continúa enviando alertas por correo electrónico cada vez que analiza el sistema.

3.3.1 Configuración

El servicio de supervisión de recursos de STA se configura mediante la utilidad de administración asociada, staresmonadm, que se encuentra en /Oracle/StorageTek_Tape_Analytics/common/bin. Para configurar el servicio de supervisión de recursos de STA, consulte el capítulo ”Configuración de servicios de STA” en la Guía de instalación y configuración de STA.

3.3.2 Consulta de la configuración de preferencias actual del supervisor de recursos

Introduzca el siguiente comando para consultar el estado de la configuración de las preferencias:

# ./staresmonadm -Q

Si el campo Configured (Configurado) dice ”no,” significa que el servicio de supervisión de recursos se está ejecutando en el modo ”inactivo” y no está supervisando los recursos ni enviando informes. Ahora deberá configurar el servidor según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics.

Ejemplo de salida de un servicio de supervisión de recursos de STA configurado:

# ./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]

3.3.3 Borrado de la configuración de preferencias del supervisor de recursos

Introduzca el siguiente comando para borrar la configuración actual de las preferencias:

# ./staresmonadm -C

El servicio de supervisión de servicios ya no está configurado y regresará al estado ”inactivo”. Ahora puede proporcionar una nueva configuración según se indica en la Guía de instalación y configuración de StorageTek Tape Analytics. Por ejemplo:

# ./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.3.4 Restablecimiento de la contraseña del supervisor de recursos de STA

Consulte Capítulo 4, "Administración de contraseñas."

3.4 Informes del supervisor de recursos

Los informes del supervisor de recursos se configuran mediante la utilidad de administración del servicio de supervisión de recursos de STA, staresmonadm. Para configurar el servicio de supervisión de recursos de STA, consulte el capítulo ”Configuración de servicios de STA” en la Guía de instalación y configuración de STA.

El supervisor de recursos puede producir dos tipos diferentes de informes:

3.4.1 Informe estándar de supervisión de recursos

El informe estándar de supervisión de recursos se envía una vez por día aproximadamente a la hora especificada por la opción staresmonadm -T. Si no se configura ninguna hora, el informe se envía al hacer el primer análisis después de la medianoche. El informe se envía a los destinatarios de correo electrónico especificados al configurar este servicio.

El informe proporciona datos sobre los siguientes recursos del servidor. Si alguno de estos recursos excede el umbral de límite superior, aparece una alerta en el informe.

  • Espacio de tablas y volumen de base de datos

  • Volumen de log, copia de seguridad y raíz

  • Directorio temporal

  • Uso de memoria del sistema


Nota:

Los valores informados se basan en puntos de montaje. Si varios de los elementos supervisados usan el mismo punto de montaje, los valores informados para esos elementos serán idénticos.

Ejemplo de informe estándar (truncado)

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

3.4.2 Informe de alerta de agotamiento de recursos

Después de cada análisis se envía un informe de alerta de agotamiento de recursos si la opción staresmonadm alert nag mode (-n) está configurada con el valor ”on”. Si el modo de insistencia no está activado, las alertas se muestran solamente en el informe estándar.

El intervalo entre análisis está determinado por el atributo Sleep Interval (-i), y el informe se envía a los destinatarios de correo electrónico especificados al configurar el servicio. En el informe, se proporcionan recomendaciones para ayudar a resolver los problemas indicados.

Ejemplo de informe de alerta de agotamiento de recursos

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.

3.5 Tipos y ubicaciones de archivos

Los servicios de STA están compuestos por secuencias de comandos ejecutables, archivos java-jar que contienen aplicaciones de servidor y cliente, archivos de configuración, archivos de volcado, archivos log y un archivo de datos acumulados. En esta sección, se describen sus finalidades y ubicaciones.

3.5.1 Secuencia de comandos de inicio y cierre del daemon de servicios de STA

La secuencia de comandos de inicio y cierre del daemon de servicios de STA, staservd, y los enlaces simbólicos de nivel de ejecución del sistema se encuentran en:

/etc/init.d/staservd - Secuencia de comandos principal de inicio y cierre

/etc/rc0.d/K04staservd - Enlace simbólico para cierre del sistema

/etc/rc1.d/K04staservd - Enlace simbólico para cierre del sistema

/etc/rc2.d/S96staservd - Enlace simbólico para inicio del sistema

/etc/rc3.d/S96staservd - Enlace simbólico para inicio del sistema

/etc/rc4.d/S96staservd - Enlace simbólico para inicio del sistema

/etc/rc5.d/S96staservd - Enlace simbólico para inicio del sistema

/etc/rc6.d/K04staservd - Enlace simbólico para cierre del sistema

La secuencia de comandos staservd init y los enlaces simbólicos asociados son creados por el instalador de STA.

3.5.2 Utilidades de administración de STA

La utilidad de administración del servicio de copia de seguridad de STA, staservadm, es una secuencia de comandos Perl que llama a una aplicación cliente Java llamada ServerAdm que está contenida en el archivo oracle.tbi.serveradm.jar. Para obtener más información, consulte "Servicio de copia de seguridad de STA".

La utilidad de administración del supervisor de recursos de STA, staresmonadm, es una secuencia de comandos Perl que llama a una aplicación cliente Java llamada StaResMonAdm que está contenida en el archivo oracle.tbi.resmonadm.jar. StaResMonAdm es un cliente de RMI que se comunica con el daemon de servicios de STA para configurar y restablecer las preferencias del tiempo de ejecución. Para obtener más información, consulte "Servicio de supervisión de recursos de STA".

3.5.3 Ubicaciones de programas ejecutables

Tabla 3-1 enumera los programas ejecutables y sus ubicaciones.

Tabla 3-1 Ubicaciones de programas ejecutables

Programa Ubicación

Archivo jar de programa de servicios de STA

$STAHOME/common/lib/oracle.tbi.server.jar

Archivo jar de aplicación Java de utilidad de administración de servicios de copia de seguridad de STA

$STAHOME/common/lib/oracle.tbi.serveradm.jar

Archivo de secuencia de comandos de usuario de utilidad de administración de servicios de copia de seguridad de STA, staservadm

$STAHOME/common/bin/staservadm

Archivo jar de aplicación Java de utilidad de administración de supervisión de recursos de STA

$STAHOME/common/lib/oracle.tbi.resmonadm.jar

Archivo de secuencia de comandos de usuario de Java de utilidad de administración de supervisión de recursos de STA, staresmonadm

$STAHOME/common/bin/staresmonadm


Donde:

$STAHOME =/Oracle/StorageTek_Tape_Analytics

3.5.4 Ubicaciones de archivos de copia de seguridad

En la operación de copia de seguridad, se utilizan las siguientes clases de archivos:

3.5.4.1 Logs de administración de daemon de servicios y servicio de copia de seguridad de STA

Registran las actividades del servidor del daemon de servicios de STA, STAServer, y su utilidad de configuración de servicios de copia de seguridad, ServerAdm. Los logs de administración son conjuntos de hasta 10 archivos log, cada uno de hasta 1,0 MB. Los nombres de los archivos log tienen el formato "*.log.N," donde "N" es el número del log (staservd.log.0, staservadm.log.0, staservd.log.1, etc.).

Se hace una rotación circular de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se completa el archivo staservd.log.9. El archivo log activo siempre es el #0 (staservd.log.0). Cuando se completa el log #0, se le cambia el nombre por log #1 y se inicia un nuevo log #0. De forma predeterminada, los logs de STAServer y ServerAdm se encuentran en:

/var/log/tbi/db/backups

La ubicación y el tipo de formato de log interno (texto ASCII simple o marcas XML) están determinados por los archivos de propiedades de log staservd.log.props y staservadm.log.props que se encuentran en:

$STAHOME/common/conf/staservd.log.props

$STAHOME/common/conf/staservadm.log.props

Donde:

$STAHOME =/Oracle/StorageTek_Tape_Analytics

3.5.4.2 Archivos de volcado de base de datos MYSQL

El archivo de volcado de base de datos MySQL es una instantánea del esquema y el contenido de datos de la base de datos en un momento dado. El servicio de copia de seguridad de STA realiza estas acciones:

  1. Inicia un volcado de alta velocidad (a veces llamado "copia de seguridad en caliente") una vez cada 24 horas de los tipos de archivos que se indican en esta sección.

  2. Transfiere el archivo de volcado más reciente al host de copia de seguridad designado.

  3. Suprime del directorio de copia de seguridad local todos los archivos de volcado del día anterior.

  4. Escribe una copia del archivo de volcado del día en curso en el directorio de copia de seguridad local.

    De manera predeterminada, el servicio de copia de seguridad de STA coloca los archivos de volcado local y los archivos log binario (binlog) incrementales en el directorio /dbbackup/local con el formato AAAAMMDD_HHMMSS.nombre de archivo.sql.

3.5.4.3 Logs binarios de MySQL

El término volcados incrementales hace referencia a los logs binarios de MySQL (binlogs) que registran todas las transacciones que generan cambios en la base de datos. El servicio de copia de seguridad de STA trata a los logs binarios como copias de seguridad incrementales posteriores al volcado de la base de datos principal.

Los volcados incrementales de STA están compuestos por todos los logs binarios producidos desde el último volcado completo. La reproducción de los logs binarios permite restaurar el estado de la base de datos hasta la última transacción registrada en el archivo log. La restauración es la carga del archivo de volcado más reciente, y posteriormente la reproducción, en orden, de todos los logs binarios de MySQL que se hubieran generado después del volcado más reciente de la base de datos.

La copia de seguridad de los logs binarios consiste en hacer una lista de todos los logs binarios creados desde el volcado completo más reciente y después transmitir cada uno de esos logs (excepto el actual, que todavía está abierto) al servidor de copia de seguridad.

El formato de nomenclatura de los logs binarios de copia de seguridad es AAAMMDD_HHMMSS.stadb-bin.número_secuencia_log.

La ubicación de los logs binarios de MySQL se define en el archivo de configuración de MySQL /etc/my.cnf. Actualmente se encuentra en:

/var/log/tbi/db/

Las copias locales de los archivos de log binario de copia de seguridad se encuentran en:

/dbbackup/local

Todos los logs binarios que se hayan transferido correctamente al servidor de copia de seguridad, con la excepción del más reciente, se depuran mediante el comando de MySQL PURGE BINARY LOGS BEFORE NOW(). Así, el log binario actual y el archivo de copia de seguridad completa del día actual permanecen en el servidor.


Precaución:

Nunca suprima manualmente los archivos de log binario.

3.5.4.4 Archivos de configuración del daemon de servicios de STA y WebLogic

Además de los archivos necesarios para recuperar la base de datos de aplicaciones de STA, el servicio de copia de seguridad de STA también hace copias de seguridad de los archivos de configuración de WebLogic de STA y sus propios archivos de configuración del daemon de servicios de STA. La copia de seguridad es recursiva e incluye todos los archivos y los directorios que se encuentran en los directorios de configuración respectivos.

Las copias de seguridad de los archivos de configuración se realizan una vez cada 24 horas, cuando se realiza el volcado completo de la base de datos de STA. El formato de los nombres de los archivos de copia de seguridad es AAAAMMDD_HHMMSS.nombre del archivo.zip.gz.

Las ubicaciones de origen y destino de estas copias de seguridad se muestran en Tabla 3-2:

Tabla 3-2 Ubicaciones de origen y destino de copia de seguridad

Ubicación de origen Copia local Copia remota

$STAHOME/common/conf/*

$BACKUPS/AAAMMDD_HHMMSS.conf.zip

$RHOST:$RDIR/AAAMMDD_HHMMSS.conf.zip.gz

$WLHOME/config/fmconfig/*

$BACKUPS/AAAAMMDD_HHMMSS.fmconfig.zip

$RHOST:$RDIR/AAAAMMDD_HHMMSS.fmconfig.zip.gz


Donde:

$STAHOME =/Oracle/StorageTek_Tape_Analytics

$WLHOME =/Oracle/Middleware/user_projects/domains/TBI

$BACKUPS =/dbdata/mysql/backups

$RHOST = dirección IP o nombre del servidor de copia de seguridad

$RDIR = directorio en el servidor de copia de seguridad

3.5.5 Ubicaciones de archivos de supervisión de recursos

En las operaciones de supervisión de recursos, se utilizan dos clases de archivos:

3.5.5.1 Logs de administración de daemon de servicios y supervisión de recursos de STA

Registran las actividades del daemon de servicios de STA y la utilidad de administración de supervisión de recursos, staresmonadm. Estos logs son conjuntos de hasta 10 archivos de log, cada uno de hasta 1,0 MB. Los nombres de los archivos log tienen el formato "*.log.N," donde "N" es el número del log (staservd.log.0, staresmonadm.log.0, staservd.log.1, etc.).

Se hace una rotación circular de los logs, de manera que el archivo log #1 se vuelve a utilizar cuando se completa el archivo staservd.log.9. El archivo log activo siempre es el #0 (staservd.log.0). Cuando se completa el log #0, se le cambia el nombre por log #1 y se inicia un nuevo log #0. De manera predeterminada, los logs de servicios de STA, supervisión de recursos de STA y administración de supervisión de recursos de STA se encuentran en:

/var/log/tbi/db/backups

La ubicación y el formato de log (texto ASCII simple o marcas XML) están determinados por los archivos de propiedades de log staservd.log.props y staresmonadm.log.props que se encuentran en:

$STAHOME/common/conf/staservd.log.props

$STAHOME/common/conf/staresmonadm.log.props

Donde:

$STAHOME =/Oracle/StorageTek_Tape_Analytics

3.5.5.2 Archivo CSV de supervisión de recursos de STA

Cada vez que el servicio de supervisión de recursos analiza el sistema, escribe los valores recopilados en un archivo de valores separados por comas (CSV) que, de manera predeterminada, se encuentra en:

/var/log/tbi/db/staresmon.csv

Este archivo de datos se puede cargar en programas como Excel y MySQL para realizar diversas funciones de análisis y trazado de gráficos con valores basados en el tiempo (por ejemplo, análisis de tendencias de agotamiento de recursos).


Nota:

El servicio de copia de seguridad no depura, revierte ni incluye el archivo CSV del servicio de supervisión de recursos en las copias de seguridad.

Cada registro del archivo staresmon.csv representa un análisis del sistema. El formato del registro de 21 columnas se muestra en Tabla 3-3.

Tabla 3-3 Formato de archivo CSV de supervisión de recursos

Col Cabecera Descripción Formato

1

TIMESTAMP

Fecha y hora del análisis

"AAAA-MM-DD

HH:MM:SS"

2

TS_MB_MAX

Espacio de tabla máximo

123

3

TS_MB_USED

Espacio de base de datos usado total

123

4

TS_MB_AVAIL

Espacio de base de datos restante

123

5

TS_PCT_USED

Espacio de tablas de base de datos usado como porcentaje del máximo

12.34%

6

TS_PCT_HWM

Límite superior de espacio de tablas de base de datos como porcentaje del máximo

12.34%

7

DBVOL_MB_MAX

Espacio disponible máximo en el volumen que contiene la base de datos

123

8

DBVOL_MB_USED

Espacio de volumen de disco de base de datos total usado

123

9

DBVOL_MB_AVAIL

Espacio de disco de volumen de base de datos restante

123

10

DBVOL_PCT_USED

Espacio de disco de volumen de base de datos usado como porcentaje del máximo

12.34%

11

DBVOL_PCT_HWM

Límite superior de volumen de base de datos como porcentaje del máximo

12.34%

12

LOGVOL_MB_MAX

Espacio disponible máximo en el volumen que contiene los logs

123

13

LOGVOL_MB_USED

Espacio de volumen de disco de log total usado

123

14

LOGVOL_MB_AVAIL

Espacio de disco de volumen de log restante

123

15

LOGVOL_PCT_USED

Espacio de disco de volumen de log usado como porcentaje del máximo

12.34%

16

LOGVOL_PCT_HWM

Límite superior de volumen de log como porcentaje del máximo

12.34%

17

MEM_MB_MAX

RAM física instalada máxima

123

18

MEM_MB_USED

Memoria física total usada

123

19

MEM_MB_AVAIL

Espacio de memoria física restante

123

20

MEM_PCT_USED

Espacio de memoria física usado como porcentaje del máximo

12.34%

21

MEM_PCT_HWM

Límite superior de memoria física como porcentaje del máximo

12.34%


3.6 Archivos de configuración de log

La generación de archivos de log para el daemon de servicios de STA, el servicio de copia de seguridad, la utilidad de administración del servicio de copia de seguridad y la utilidad de supervisión de recursos de STA se controla mediante los archivos de configuración de log que se encuentran en:

$STAHOME/common/conf/staservd.log.props

$STAHOME/common/conf/staservadm.log.props

$STAHOME/common/conf/staresmonadm.log.props

Donde:

$STAHOME =/Oracle/StorageTek_Tape_Analytics

El contenido y el formato del archivo log se inicializan y controlan mediante las propiedades de configuración del gestor de logs de Java. Estas propiedades se leen de los archivos de propiedades de log indicadas anteriormente. La siguiente información se puede encontrar en:

http://download.oracle.com/javase/1.4.2/docs/api/java/util/logging/FileHandler.html.

Tabla 3-4 Contenido de archivo log

Propiedad Descripción Configuración de StorageTek Tape Analytics

java.util.logging.FileHandler.append

Especifica si se debe anexar FileHandler a los archivos existentes (la configuración predeterminada es "false").

true

java.util.logging.FileHandler.count

Especifica la cantidad de archivos de salida del ciclo (la configuración predeterminada es 1).

10

java.util.logging.FileHandler.formatter

Especifica el nombre de clase de formateador que se utiliza (la configuración predeterminada es java.util.logging.XMLFormatter)

Java.util.logging.SimpleFormatter para lectura por seres humanos. java.util.loggin.XMLFormatter se convierte en comentario y está disponible

java.util.logging.FileHandler.level

Especifica el nivel por defecto del manejador (la configuración predeterminada es Level. ALL).

CONFIG

java.util.logging.FileHandler.limit

Especifica una cantidad máxima aproximada (en bytes) para escribir en un archivo. Si este valor es cero, no hay límite. (La configuración predeterminada es sin límite).

1000000 (1MB)

java.util.logging.FileHandler.pattern

Especifica un patrón para generar el nombre del archivo de salida. Para obtener más información, consulte la información que se muestra abajo. (La configuración predeterminada es "%h/java%u.log").

/var/log/tbi/db/backups/staservd.log.%g

/var/log/tbi/db/backups/staservadm.log.%g


Tabla 3-5 Propiedades del daemon de servicios de STA

Propiedad Descripción Configuración de StorageTek Tape Analytics

oracle.tbi.server.level

oracle.tbi.serveradm.level

oracle.tbi.resmonadm.level

Especifica el nivel de log del servidor, las funciones de administración del servidor o las funciones de administración del supervisor de recursos.

CONFIG

CONFIG


3.7 Restauración de bases de datos de STA

El procedimiento de restauración de STA consiste en cargar el volcado completo más reciente y después reproducir todos los logs binarios inmediatamente posteriores al volcado.

En el directorio del servidor de copia de seguridad hay juegos de archivos de copia de seguridad bien diferenciados. Por ejemplo:

# 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

El formato de la marca de tiempo del nombre de archivo es AAAAMMDD_HHMMSS. Todos los logs binarios que tengan la misma etiqueta de fecha se reproducen en la base de datos después de cargar el volcado completo.

En esta sección, se analizan las siguientes tareas de administración:

3.7.1 Copia de archivos de copia de seguridad en el servidor

Para copiar archivos de copia de seguridad en el servidor:

  1. Copie el juego completo de archivos del día en el servidor de STA.

    Oracle recomienda copiar todo lo que haya en el directorio /tmp. Por ejemplo, suponiendo que STA esté instalado en el servidor sta.server.com y usted esté actualmente conectado al servidor de copia de seguridad.

    # scp 20130723*.* sta.server.com:/tmp/.
    Password:
    
  2. Inicie sesión como usuario root en el servidor de STA y descomprima los archivos *.gz. Por ejemplo:

    # cd /tmp
    # gunzip 20130723*.*.gz
    

3.7.2 Restauración de archivos del directorio de configuración

Para restaurar los archivos del directorio de configuración:

  1. Detenga todos los procesos del STA. A continuación, reinicie sólo el servidor de MySQL.

    # STA stop all
    # STA start mysql
    
  2. Descomprima los directorios de configuración de STAServer y el daemon de servicios de STA.

    Los archivos zip se crearon con las rutas de directorio completas para que sea posible restaurar y/o sobrescribir archivos existentes. El comando zip le permite restablecer la raíz de la ruta de restauración con la opción -d. Hay opciones adicionales que permiten lograr un mayor control, por ejemplo, el reemplazo selectivo.

    Para una restauración desde cero, debe reemplazar por completo el directorio de configuración existente. Sin embargo, haga antes una copia de seguridad del directorio original. Por ejemplo:

    # 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
    

Donde:

$WLSHOME =/Oracle/Middleware/user_projects/domains/TBI/config

$STAHOME =/Oracle/StorageTek_Tape_Analytics

3.7.3 Restauración de la base de datos

Ejecute los siguientes comandos como usuario root de MySQL:

3.7.3.1 Recarga de la base de datos

Para volver a cargar la base de datos:

  1. Elimine la base de datos residual de stadb, si hay una. Por ejemplo:

    # mysql -uroot -p -e 'drop database stadb;'
    Password:
    
  2. Cargue el volcado completo más reciente. Al hacerlo, se crea el esquema y se instalan todos los datos. Por ejemplo:

    # mysql -uroot -p -e 'source 20130723_133755.stafullbackup.sql;'
    Password:
    

3.7.3.2 Reproducción de los logs binarios

Para reproducir los logs binarios:

  1. Ejecute cada uno de los volcados incrementales (logs binarios), de más reciente a más antiguo.

    Si tiene más de un log binario para ejecutar en el servidor de MySQL, el método más seguro es procesar todos los archivos mediante una única conexión con el servidor y un único proceso mysql para ejecutar el contenido de todos los logs binarios.

    Por ejemplo:

    # 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
    

    Otro enfoque es concatenar todos los logs en un único archivo y después procesar ese archivo:

    # 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'
    

Nota:

Si no proporciona una contraseña en la línea de comandos, MySQL se la solicita antes de continuar.

3.7.3.2.1 Evite establecer varias conexiones con el servidor

El procesamiento de los logs binarios, como el que se muestra en el siguiente ejemplo, puede crear varias conexiones con el servidor. La existencia de más de una conexión ocasiona problemas si el primer archivo log contiene la instrucción CREATE TEMPORARY TABLE y el segundo log contiene una instrucción que usa esa tabla temporaria. Cuando finaliza el primer proceso de mysql, el servidor elimina la tabla temporaria. Cuando el segundo proceso de mysql intenta usar esa tabla, el servidor informa ”unknown table” (tabla desconocida).

# mysqlbinlog binlog.000001 |mysql -u root -p #<=== DANGER!!
# mysqlbinlog binlog.000002 |mysql -u root -p #<=== DANGER!!

3.7.3.3 Reinicio de todos los servicios

Como usuario root del sistema Linux, introduzca el siguiente comando:

# STA start all

3.7.4 Restauraciones puntuales

Otro método de restauración es el de las restauraciones "puntuales", en el que se pueden reproducir los logs binarios desde un momento específico y hasta un momento específico.

Por ejemplo, después de examinar el contenido de un log binario, descubre que una operación errónea hizo que se eliminaran varias tablas inmediatamente después de la entrada de log #6817916. Después de restaurar la base de datos a partir del volcado completo que se realizó el día anterior, y antes de reiniciar todos los servicios de STA, puede usar los comandos que se muestran en este procedimiento para reproducir el log binario más reciente desde el número de entrada de log inicial "176" hasta el número de entrada "6817916".

3.7.4.1 Restauración a partir de un rango de números de log

Para restaurar a partir de un rango de números de log:

  1. Asegúrese de que todos los procesos de STA estén cerrados y que se esté ejecutando sólo el servidor de MySQL:

    # STA stop all
    # STA start mysql 
    
  2. Como usuario root de MySQL, extraiga las operaciones válidas. Por ejemplo:

    # mysqlbinlog --start-position=176 --stop-position=6817916
    /var/log/tbi/db/stadb-bin.000007 > ./recover.sql
    
  3. Aplíquelas a la base de datos. Por ejemplo:

    # mysql -uroot -p -e 'source ./recover.sql'
    Password:
    
  4. Como usuario root del sistema Linux, reinicie la aplicación de STA y el daemon de servicios de STA:

    # STA start all
    

Para obtener más información acerca de las operaciones de recuperación puntual o incremental, consulte el manual de MySQL:

http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html