Ce chapitre décrit en détail l'administration des différents services STA. Pour procéder à la configuration initiale de ces services, reportez-vous au Guide d'installation et de configuration de STA.
Ce chapitre se compose des sections suivantes :
Le démon des services STA (staservd) est un service Linux en exécution permanente qui gère et exécute le service de sauvegarde STA et celui du contrôleur de ressources STA. Le service de sauvegarde STA et celui du contrôleur de ressources STA sont exécutés séparément dans le démon des services STA.
Le démon des services STA démarre lorsque le serveur STA est initialisé (avec la commande STA start all) et s'interrompt lorsque le serveur est arrêté. Vous pouvez également démarrer, arrêter et vérifier l'état du démon des services STA à l'aide des commandes suivantes :
Pour démarrer le démon des services STA :
# STA start staservd
Starting staservd Service...
staservd service was successfully started
Pour arrêter le démon des services STA :
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
Pour vérifier le statut du démon des services STA :
# STA status staservd
staservd service is running
Pour plus d'informations sur la commande STA, reportez-vous au Chapitre 1, Administration des serveurs..
Remarque:
Après l'installation de STA, le démon des services STA démarre le service de sauvegarde STA et celui du contrôleur de ressources STA, mais ceux-ci ne sont pas activés tant qu'ils n'ont pas été configurés. Pour configurer ces services, reportez-vous au Guide d'installation et de configuration de STA.Le service de sauvegarde STA est l'un des nombreux services exécutés dans le démon des services STA. Il effectue une sauvegarde complète automatique de la base de données STA et des répertoires de configuration des clés, enregistre ces fichiers dans un emplacement spécifié sur le serveur STA ou sous forme compressée sur un serveur distant. Oracle vous recommande de configurer un serveur distant pour la sauvegarde.
Avant de continuer, vérifiez que le démon des services STA est bien en cours d'exécution. Voir Démon des services STA.
Affichage des paramètres des préférences du service de sauvegarde
Vérification de l'envoi des fichiers de sauvegarde au serveur cible
Vérification qu'une copie locale des fichiers de sauvegarde se trouve sur le serveur STA
Réinitialisation du mot de passe du service de sauvegarde STA
Le service de sauvegarde STA se configure à l'aide de son utilitaire d'administration (staservadm), situé dans le répertoire /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. Pour configurer le service de sauvegarde STA, reportez-vous au Guide d'installation et de configuration de STA.
Une fois configuré, le service de sauvegarde STA effectue le processus suivant toutes les 24 heures :
Il initie un vidage très rapide (également appelé sauvegarde à chaud) des types de fichier suivants :
Fichier dump de la base de données MySQL
Fichiers journaux binaires de MySQL
Fichiers de configuration du démon des services STA et de WebLogic pour STA
Journaux d'administration du démon des services STA et du service de sauvegarde STA
Il transfère le fichier dump vers l'hôte de sauvegarde désigné.
Il supprime tous les fichiers du vidage complet du jour précédent présents sur le serveur STA.
Il écrit une copie des fichiers dump du jour actuel cours dans le répertoire /sta_db_backup/local du serveur STA.
Affichez le statut des paramètres actuels des préférences.
# ./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 [*********]
Si le champ Configured indique [no], cela signifie que le service de sauvegarde s'exécute en mode inactif et qu'il n'effectue aucune sauvegarde. Vous devez fournir les paramètres de configuration adéquats. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA.
Effacez les paramètres actuels des préférences.
# ./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 []
Le service de sauvegarde n'est plus configuré et revient à l'état inactif. Vous pouvez à présent fournir de nouveaux paramètres. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA.
Pour vérifier que les fichiers ont été envoyés avec succès au serveur cible :
Vérifiez les journaux sur le serveur STA.
Connectez-vous au serveur de sauvegarde cible et affichez sous forme de liste le contenu du répertoire de sauvegarde.
Connectez-vous au serveur STA en tant qu'utilisateur root du système.
Accédez au répertoire des journaux de sauvegarde de la base de données STA.
# cd /sta_logs/db/backups
Dans le fichier staservd.log.0, recherchez la chaîne "INFO: done. Database dump completed.". Ce fichier enregistre les activités de l'utilitaire de configuration des services de sauvegarde.
# 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
Connectez-vous au serveur de sauvegarde cible.
Affichez sous forme de liste les fichiers que contient le répertoire des sauvegardes de la base de données.
Dans cet exemple, le répertoire /backups/tbivb01 a préalablement été configuré pour recevoir les fichiers de sauvegarde provenant du serveur 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
Pour vérifier qu'une copie des fichiers de sauvegarde les plus récents a été enregistrée localement sur le serveur STA, affichez sous forme de liste les fichiers situés dans le répertoire /sta_db_backup/local. Par exemple :
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
Le nom des fichiers répertoriés est au format AAAAMMJJ_HHMMSS.nom_du_fichier.zip.
Le service du contrôleur de ressources STA surveille et signale les ressources du serveur STA, y compris le tablespace de la base de données et l'espace du volume du disque, l'espace disque du volume de journalisation, et l'utilisation de la mémoire physique.
Vous pouvez définir des limites supérieures d'utilisation (HWM) pour chaque ressource. Une limite supérieure est un seuil de déclenchement d'une alerte. Lorsque le seuil est atteint ou dépassé, une alerte est enregistrée dans le rapport de ressources standard quotidien et, en option, envoyée par e-mail à un ou plusieurs destinataires désignés.
Par exemple, si vous définissez le HWM du tablespace de la base de données sur 60 %, lorsque le contrôleur de ressources STA détecte que l'application STA a utilisé 60 % ou plus du tablespace maximal alloué à la base de données, il active l'alerte de tablespace et envoie un e-mail aux destinataires désignés. En outre, si le mode Répétition est activé, le contrôleur de ressources continue à envoyer un e-mail d'alerte à chaque fois qu'il analyse le système.
Interrogation des paramètres actuels des préférences du contrôleur de ressources
Effacement des paramètres des préférences du contrôleur de ressources
Réinitialisation du mot de passe du contrôleur de ressources STA
Le service du contrôleur de ressources STA se configure à l'aide de son utilitaire d'administration (staresmonadm), situé dans le répertoire /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. Pour configurer le service du contrôleur de ressources STA, reportez-vous au Guide d'installation et de configuration de STA.
Saisissez la commande suivante pour interroger le statut actuel des paramètres des préférences :
# ./staresmonadm –Q
Si le champ Configured indique "no", cela signifie que le service du contrôleur de ressources s'exécute en mode "inactif" et donc qu'il ne surveille aucune ressource et n'envoie aucun rapport. Vous devrez configurer le serveur. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA.
Exemple de sortie lorsque le service du contrôleur de ressources STA est configuré :
# ./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]
Saisissez la commande suivante pour effacer les paramètres actuels des préférences :
# ./staresmonadm –C
Le service du contrôleur de ressources n'est plus configuré et revient à l'état inactif. Vous pouvez à présent fournir de nouveaux paramètres. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA. Par exemple :
# ./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]
Les rapports du contrôleur de ressources se configurent à l'aide de l'utilitaire d'administration du service du contrôleur de ressources STA (staresmonadm). Pour configurer le service du contrôleur de ressources STA, reportez-vous au Guide d'installation et de configuration de STA.
Le contrôleur de ressources peut produire deux types de rapport différents :
Un rapport standard du contrôleur de ressources est envoyé une fois par jour, approximativement à l'heure spécifiée par l'option staresmonadm –T. Si vous ne définissez aucune heure, le rapport est envoyé au moment de la première analyse après minuit. Le rapport est envoyé aux destinataires d'e-mail que vous avez spécifiés lorsque vous avez configuré ce service.
Le rapport fournit des données sur les ressources suivantes du serveur. Si l'une de ces ressources dépasse un seuil de limite supérieure, une alerte apparaît dans le rapport.
Tablespace et volume de la base de données
Journalisation, sauvegarde et volume root
Répertoire temporaire
Utilisation de la mémoire système
Remarque:
Les valeurs signalées dépendent des points de montage. Si plusieurs éléments surveillés partagent le même point de montage, les valeurs signalées pour ces éléments seront identiques.Exemple 2-1 Exemple de rapport standard (tronqué)
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 ...
Un rapport d'alerte de diminution des ressources est envoyé après chaque analyse si l'option du mode de répétition d'alerte staresmonadm (-n) est activée. Si le mode de répétition d'alerte est désactivé, les alertes s'affichent uniquement dans le rapport standard.
L'intervalle entre chaque analyse est déterminé par l'attribut Intervalle de mise en sommeil (–i), et le rapport est envoyé aux destinataires d'e-mail que vous avez spécifiés lorsque vous avez configuré ce service. Des recommandations sont fournies dans le rapport pour permettre de résoudre les problèmes signalés.
Exemple 2-2 Exemple de rapport d'alerte de diminution des ressources
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.
Les services STA incluent des scripts exécutables, des fichiers Java de type jar qui contiennent des applications serveur et client, des fichiers de configuration, un fichier dump, des fichiers journaux et un fichier de données cumulées. Cette section décrit leurs objectifs et leurs emplacements.
Le script de démarrage et d'arrêt du démon des services STA (staservd) et les liens symboliques vers le niveau d'exécution du système sont situés dans les emplacements suivants. Ce script et les liens symboliques associés sont créés par le programme d'installation de STA.
/etc/init.d/staservd : principal script de démarrage et d'arrêt
/etc/rc0.d/K04staservd : lien symbolique pour l'arrêt du système
/etc/rc1.d/K04staservd : lien symbolique pour l'arrêt du système
/etc/rc2.d/S96staservd : lien symbolique pour le démarrage du système
/etc/rc3.d/S96staservd : lien symbolique pour le démarrage du système
/etc/rc4.d/S96staservd : lien symbolique pour le démarrage du système
/etc/rc5.d/S96staservd : lien symbolique pour le démarrage du système
/etc/rc6.d/K04staservd : lien symbolique pour l'arrêt du système
L'utilitaire d'administration du service de sauvegarde STA (staservadm) est un script Perl qui appelle une application Java côté client nommée ServerAdm et située dans le fichier oracle.tbi.serveradm.jar. Pour plus d'informations, reportez-vous à la section Service de sauvegarde STA.
L'utilitaire d'administration du contrôleur de ressources STA (staresmonadm) est un script Perl qui appelle une application Java côté client nommée StaResMonAdm et située dans le fichier oracle.tbi.resmonadm.jar. StaResMonAdm est un client RMI qui communique avec le démon des services STA afin de définir et de réinitialiser les préférences d'exécution. Pour plus d'informations, reportez-vous à la section Service du contrôleur de ressources STA.
Le Tableau 2-1 répertorie les programmes exécutables ainsi que leurs emplacements.
Tableau 2-1 Emplacements des programmes exécutables
| Programme | Emplacement |
|---|---|
|
Fichier jar des programmes des services STA |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
Fichier jar de l'application Java de l'utilitaire d'administration des services de sauvegarde STA |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
Fichier script utilisateur de l'utilitaire d'administration du service de sauvegarde STA (staservadm) |
$STAHOME/common/bin/staservadm |
|
Fichier jar de l'application Java de l'utilitaire d'administration ResMon STA |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
Fichier script utilisateur Java de l'utilitaire d'administration ResMon STA (staresmonadm) |
$STAHOME/common/bin/staresmonadm |
Où :
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
La sauvegarde de la base de données STA comprend les types de fichier suivants :
Journaux d'administration du démon des services et du service de sauvegarde STA
Fichiers de configuration du démon des services STA et de WebLogic
Ces journaux enregistrent les activités du serveur du démon des services STA (STAServer) et de son utilitaire de configuration des services de sauvegarde (ServerAdm). Les journaux d'administration sont des regroupements de jusqu'à 10 fichiers journaux, chacun pouvant présenter une taille maximale de 1 Mo. Les noms des fichiers journaux sont au format *.log.N, où N est le numéro du journal (staservd.log.0, staservadm.log.0, staservd.log.1, et ainsi de suite).
Les journaux subissent une rotation, ce qui fait que le fichier journal n° 1 sera réutilisé une fois que staservd.log.9 sera plein. Le fichier journal actif porte toujours le n° 0 (staservd.log.0). Lorsque le journal n° 0 est plein, il est renommé en utilisant le n° 1, et un nouveau journal n° 0 est commencé. Par défaut, les journaux STAServer et ServerAdm sont situés dans le répertoire suivant :
/STA_logs/db/backups
L'emplacement par défaut de STA_logs est /var/log/tbi.
L'emplacement et le format interne des journaux (soit en texte ASCII simple, soit en XML) sont contrôlés par les fichiers des propriétés de journalisation (staservd.log.props et staservadm.log.props), situés dans les emplacements suivants :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
Où :
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Le fichier dump de la base de données MySQL est un instantané ponctuel du schéma de la base de données et des données qu'elle contient. Le service de sauvegarde STA réalise les actions suivantes :
Toutes les 24 heures, il initie un vidage très rapide (également appelé sauvegarde à chaud) des types de fichier abordés dans cette section.
Il transfère le fichier dump le plus récent vers l'hôte de sauvegarde désigné.
Il supprime tous les fichiers du vidage complet du jour précédent présents dans le répertoire de sauvegarde local.
Il enregistre une copie du fichier dump du jour actuel dans le répertoire de sauvegarde local.
Par défaut, le service de sauvegarde STA place ses fichiers dump locaux et ses fichiers journaux binaires incrémentiels dans le répertoire /sta_db_backup/local, au format AAAAMMJJ_HHMMSS.nom_du_fichier.sql.
Le terme vidages incrémentiels fait référence aux journaux binaires MySQL qui enregistrent toutes les transactions entraînant une modification d'une base de données. Le service de sauvegarde STA traite les journaux binaires comme des sauvegardes incrémentielles faisant suite au vidage principal de la base de données.
Les vidages incrémentiels STA comprennent tous les journaux binaires produits depuis le dernier vidage complet. En réimportant les journaux binaires, vous pouvez restaurer une base de données à l'état dans lequel elle se trouvait jusqu'à la dernière transaction enregistrée dans le journal. Une restauration consiste à charger le fichier dump le plus récent et à importer, dans l'ordre, tous les journaux binaires MySQL qui ont été générés suite au dernier vidage de la base de données.
La sauvegarde des journaux binaires consiste à établir une liste de tous les journaux binaires créés depuis le vidage complet le plus récent, puis à transmettre chacun de ces journaux (à l'exception de celui en cours car il est toujours ouvert) au serveur de sauvegarde.
Le journal binaire de sauvegarde est au format AAAAMMJJ_HHMMSS.stadb–bin.numéro_séquentiel_du_journal.
L'emplacement du journal binaire MySQL est défini dans le fichier de paramètres MySQL /etc/my.cnf. Actuellement, il est défini sur :
/STA_logs/db
Les copies locales des fichiers journaux binaires de sauvegarde sont situées dans :
/sta_db_backup/local
Tous les fichiers journaux, à l'exception du plus récent, qui ont été correctement transférés vers le serveur de sauvegarde sont purgés à l'aide de la commande MySQL PURGE BINARY LOGS BEFORE NOW(). Le journal binaire actuel et le fichier de sauvegarde complète du jour actuel restent donc sur le serveur.
Mise en garde:
N'effacez jamais manuellement les fichiers journaux binaires.En plus des fichiers nécessaires à la récupération de la base de données de l'application STA, le service de sauvegarde STA sauvegarde également les fichiers de configuration de WebLogic pour STA ainsi que ses propres fichiers de configuration au niveau du démon des services STA. La sauvegarde est une sauvegarde récursive de tous les fichiers et répertoires dans leurs répertoires de configuration respectifs.
Les sauvegardes des fichiers de configuration sont effectuées toutes les 24 heures lorsque le vidage complet de la base de données STA est exécuté. Les noms des fichiers de sauvegarde sont au format AAAAMMJJ_HHMMSS.nom_du_fichier.zip.gz.
Les emplacements source et cible de ces sauvegardes sont affichés dans le Tableau 2-2 :
Tableau 2-2 Emplacements source/cible des sauvegardes
| Emplacement source | Copie locale | Copie distante |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/AAAAMMJJ_HHMMSS.conf.zip |
$RHOST:$RDIR/AAAAMMJJ_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/AAAAMMJJ_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/AAAAMMJJ_HHMMSS.fmconfig.zip.gz |
Où :
$STAHOME = /Oracle_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = nom ou adresse IP du serveur de sauvegarde
$RDIR = répertoire sur le serveur de sauvegarde
Il existe deux types de fichier impliqués dans les opérations de surveillance :
Ces journaux enregistrent les activités du démon des services STA et de l'utilitaire d'administration staresmonadm. Ces journaux sont des regroupements de jusqu'à 10 fichiers journaux, chacun pouvant présenter une taille maximale de 1 Mo. Les noms des fichiers journaux sont au format *.log.N, où N est le numéro du journal (staservd.log.0, staservadm.log.0, staservd.log.1, et ainsi de suite).
Les journaux subissent une rotation, ce qui fait que le fichier journal n° 1 sera réutilisé une fois que staservd.log.9 sera plein. Le fichier journal actif porte toujours le n° 0 (staservd.log.0). Lorsque le journal n° 0 est plein, il est renommé en utilisant le n° 1, et un nouveau journal n° 0 est commencé. Par défaut, les journaux des services STA, de ResMon STA et de ResMonAdm STA sont tous situés dans :
/STA_logs/db/backups
L'emplacement et le format interne des journaux (soit en texte ASCII simple, soit en XML) sont contrôlés par les fichiers des propriétés de journalisation (staservd.log.props et staresmonadm.log.props), situés dans les emplacements suivants :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
Où :
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
A chaque fois que ResMon analyse le système, il enregistre les valeurs collectées dans un fichier de valeurs séparées par des virgules (CSV) qui se situe par défaut dans :
/STA_logs/db/staresmon.csv
Les programmes comme Excel et MySQL peuvent charger ce fichier de données et effectuer différentes fonctions d'analyse et de représentation graphique reposant sur des valeurs temporelles (par exemple, l'analyse des tendances de diminution des ressources).
Remarque:
Le fichier CSV ResMon n'est ni purgé, ni reporté, ni sauvegardé par le service de sauvegarde STA.Chaque enregistrement dans staresmon.csv représente une analyse du système. Le format d'enregistrement à 21 colonnes est illustré dans le Tableau 2-3.
Tableau 2-3 Format du fichier CSV du contrôleur de ressources
| Col. | En-tête | Description | Format |
|---|---|---|---|
|
1 |
TIMESTAMP |
Date et heure de l'analyse |
"AAAA–MM–JJ HH:MM:SS" |
|
2 |
TS_MB_MAX |
Tablespace maximum |
123 |
|
3 |
TS_MB_USED |
Espace total utilisé par la base de données |
123 |
|
4 |
TS_MB_AVAIL |
Espace restant pour la base de données |
123 |
|
5 |
TS_PCT_USED |
Tablespace utilisé, sous forme de pourcentage du maximum |
12.34% |
|
6 |
TS_PCT_HWM |
Limite supérieure du tablespace, sous forme de pourcentage du maximum |
12.34% |
|
7 |
DBVOL_MB_MAX |
Espace disponible max. sur le volume qui contient la base de données |
123 |
|
8 |
DBVOL_MB_USED |
Espace total du volume du disque utilisé par la base de données |
123 |
|
9 |
DBVOL_MB_AVAIL |
Espace disque du volume restant pour la base de données |
123 |
|
10 |
DBVOL_PCT_USED |
Espace disque du volume utilisé par la base de données, sous forme de pourcentage du maximum |
12.34% |
|
11 |
DBVOL_PCT_HWM |
Limite supérieure du volume de la base de données, sous forme de pourcentage du maximum |
12.34% |
|
12 |
LOGVOL_MB_MAX |
Espace disponible max. sur le volume qui contient les journaux |
123 |
|
13 |
LOGVOL_MB_USED |
Espace total du volume du disque utilisé par les journaux |
123 |
|
14 |
LOGVOL_MB_AVAIL |
Espace disque du volume restant pour les journaux |
123 |
|
15 |
LOGVOL_PCT_USED |
Espace disque du volume utilisé par les journaux, sous forme de pourcentage du maximum |
12.34% |
|
16 |
LOGVOL_PCT_HWM |
Limite supérieure du volume des journaux, sous forme de pourcentage du maximum |
12.34% |
|
17 |
MEM_MB_MAX |
RAM physique maximale installée |
123 |
|
18 |
MEM_MB_USED |
Mémoire physique totale utilisée |
123 |
|
19 |
MEM_MB_AVAIL |
Espace restant de la mémoire physique |
123 |
|
20 |
MEM_PCT_USED |
Espace de mémoire physique utilisé, sous forme de pourcentage du maximum |
12.34% |
|
21 |
MEM_PCT_HWM |
Limite supérieure de la mémoire physique, sous forme de pourcentage du maximum |
12.34% |
La journalisation pour le démon des services STA, le service de sauvegarde, l'utilitaire d'administration du service de sauvegarde et l'utilitaire du contrôleur de ressources STA est contrôlée par les fichiers de configuration de la journalisation situés dans :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
Où $STA_HOME est l'emplacement initial de STA, spécifié lors de son installation. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA.
Le contenu et le format du fichier de journalisation sont contrôlés par les propriétés de configuration du gestionnaire de journal Java. Le Tableau 2-4 récapitule ces propriétés. Pour plus d'informations, reportez-vous à la documentation Oracle Java SE disponible à l'adresse suivante :
http://docs.oracle.com/en/java/
Tableau 2-4 Propriétés de journalisation Java
| Propriété | Description | Paramètre STA |
|---|---|---|
|
java.util.logging.FileHandler.append |
Spécifie si le FileHandler doit ajouter les éléments à la fin de fichiers existants. La valeur par défaut est false. |
true |
|
java.util.logging.FileHandler.count |
Spécifie le nombre de fichiers de sortie composant un cycle. La valeur par défaut est 1. |
10 |
|
java.util.logging.FileHandler.formatter |
Spécifie le nom de la classe du Formatter. La valeur par défaut est java.util.logging.XMLFormatter. |
Java.util.logging.SimpleFormatter pour faciliter la lecture. java.util.logging.XMLFormatter est mis à disposition sous forme de commentaire. |
|
java.util.logging.FileHandler.level |
Spécifie le niveau par défaut du Handler. La valeur par défaut est Level. ALL. |
CONFIG |
|
java.util.logging.FileHandler.limit |
Spécifie la quantité maximale approximative (en octets) à écrire dans un fichier quelconque. Une entrée de zéro indique qu'il n'y a aucune limite. La valeur par défaut est aucune limite. |
500000 (0,5 Mo) |
|
java.util.logging.FileHandler.pattern |
Spécifie le modèle à utiliser pour le nom du fichier de sortie. La valeur par défaut est "%h/java%u.log". |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g Où STA_logs est l'emplacement des journaux défini lors de l'installation de Linux. Pour plus d'informations, reportez-vous au Guide d'installation et de configuration de STA. |
Les niveaux de journal sont contrôlés par les propriétés de journalisation de STA dans ces fichiers. Le Tableau 2-5 récapitule ces propriétés.
Tableau 2-5 Propriétés de journalisation des services STA
| Propriété | Description | Paramètre STA |
|---|---|---|
|
oracle.tbi.server.level |
Spécifie le niveau de journal pour le serveur. |
CONFIG |
|
oracle.tbi.serveradm.level |
Spécifie le niveau de journal pour les fonctions d'administration du serveur. |
CONFIG |
|
oracle.tbi.resmonadm.level |
Spécifie le niveau de journal pour les fonctions d'administration du contrôleur de ressources. |
CONFIG |
La procédure de restauration de la base de données STA consiste à charger le vidage complet de la base de données le plus récent, puis à restaurer les journaux binaires suivant immédiatement ce vidage.
Il existe deux ensembles distincts de fichiers de sauvegarde dans le répertoire du serveur de sauvegarde. Par exemple :
# 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
L'horodatage indiqué dans le nom du fichier est au format AAAAMMJJ_HHMMSS. Tous les journaux binaires présentant la même date seront importés dans la base de données une fois que le vidage complet aura été chargé.
Les tâches d'administration suivantes sont abordées ici :
Procédez comme suit pour copier des fichiers de sauvegarde sur le serveur STA.
Copiez et rapatriez l'ensemble complet de fichiers d'une même journée sur le serveur STA.
Oracle recommande de tout recopier dans le répertoire /tmp. Par exemple, en présumant que STA est installé sur le serveur sta.server.com et que vous êtes actuellement connecté au serveur de sauvegarde :
# scp 20130723*.* sta.server.com:/tmp/.
Password:
Connectez-vous au serveur STA en tant qu'utilisateur root.
Décompressez les fichiers *.gz. Par exemple :
# cd /tmp
# gunzip 20130723*.*.gz
Procédez comme suit pour restaurer les fichiers du répertoire de configuration.
Arrêtez tous les processus STA. Ensuite, redémarrez uniquement le serveur MySQL.
# STA stop all
# STA start mysql
Décompressez les répertoires de configuration du serveur STA et du démon des services STA.
Les fichiers zip ont été créés avec les chemins de répertoires complets pour vous permettre de restaurer ou d'écraser les fichiers existants. La commande unzip vous permet de recréer la racine du chemin de restauration à l'aide de l'option –d. Des options supplémentaires augmentent le contrôle, comme le remplacement sélectif.
Pour une restauration propre, il est nécessaire de remplacer entièrement le répertoire de configuration existant. Cependant, faites d'abord une sauvegarde de l'original. Par exemple :
# 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
Où :
$WLSHOME =/Oracle_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Exécutez les commandes suivantes en tant qu'utilisateur root MySQL :
Pour recharger la base de données :
Eliminez tous les éventuels stadb restant dans la base de données. Par exemple :
# mysql –uroot –p –e 'drop database stadb;'
Password:
Chargez le dernier vidage complet. Ceci crée le schéma et installe toutes les données. Par exemple :
# mysql –uroot –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
Pour réimporter les journaux binaires :
Exécutez chacun des vidages incrémentiels (journaux binaires) depuis le plus récent jusqu'au plus ancien.
Si vous devez exécuter plusieurs journaux binaires sur le serveur MySQL, la méthode la plus sûre consiste à les traiter tous à l'aide d'une seule connexion au serveur et d'un seul processus MySQL pour exécuter le contenu de tous les journaux binaires.
Par exemple :
# 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
Une approche consiste à concaténer tous les journaux en un seul fichier puis à traiter le fichier :
# 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'
Remarque:
Si vous ne fournissez pas de mot de passe sur la ligne de commande, MySQL vous invite à le saisir avant de continuer.Le traitement des journaux binaires comme décrit dans l'exemple ci-dessous peut créer des connexions multiples au serveur. Les connexions multiples créent des problèmes si le premier fichier journal contient une instruction CREATE TEMPORARY TABLE alors que le deuxième journal contient une instruction qui utilise cette table temporaire. Lorsque le premier processus MySQL s'interrompt, le serveur supprime la table temporaire. Lorsque le deuxième processus MySQL tente d'utiliser ce tableau, le serveur signale une "table inconnue".
# mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!!
# mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
En tant qu'utilisateur root du système Linux, saisissez la commande suivante :
# STA start all
Une autre méthode de restauration est celle dite ponctuelle, où les journaux binaires peuvent être importés entre deux points dans le temps spécifiques.
Par exemple, après avoir examiné le contenu d'un journal binaire, vous découvrez qu'une opération erronée a entraîné la suppression de plusieurs tables immédiatement après l'entrée de journal n° 6817916. Après avoir restauré la base de données à partir du vidage complet du jour précédent, et avant de redémarrer tous les services STA, vous pouvez importer le journal binaire le plus récent entre le numéro d'entrée de journal initial "176" et le numéro d'entrée "6817916" à l'aide des commandes affichées dans cette procédure.
Procédez comme suit pour restaurer la base de données STA à partir d'une plage de numéros de journaux.
Assurez-vous que tous les processus STA sont arrêtés et que seul le serveur MySQL est en cours d'exécution :
# STA stop all
# STA start mysql
En tant qu'utilisateur root MySQL, extrayez les opérations valides. Par exemple :
# mysqlbinlog ––start–position=176 ––stop–position=6817916
/var/log/tbi/db/stadb–bin.000007 > ./recover.sql
Appliquez-les à la base de données. Par exemple :
# mysql –uroot –p –e 'source ./recover.sql'
Password:
En tant qu'utilisateur root du système Linux, redémarrez l'application STA et le démon des services STA :
# STA start all
Pour plus d'informations sur les opérations de récupération ponctuelle ou incrémentielle, reportez-vous à la documentation MySQL à l'adresse suivante :