| StorageTek Tape Analytics Guide d'administration Version 2.0 E53286-01 |
|
 Précédent |
 Suivant |
| StorageTek Tape Analytics Guide d'administration Version 2.0 E53286-01 |
|
Précédent |
Suivant |
Ce chapitre décrit en détail l'administration des différents services STA. Pour la configuration initiale de ces services, voir le chapitre "Configuration des services STA" dans le Guide d'installation et de configuration de STA.
Le démon de services STA, staservd, est un service Linux en exécution permanente qui gère et exécute les services de sauvegarde STA et du contrôleur de ressources STA. Les services de sauvegarde STA et du contrôleur de ressources STA sont exécutés séparément dans le démon de services STA.
Le démon de services STA démarre lorsque le serveur STA est initialisé (avec la commande STA start all) et prend fin lorsque le serveur est arrêté. Vous pouvez également démarrer, arrêter et vérifier l'état du démon de services STA à l'aide des commandes suivantes :
Pour démarrer le démon de services STA :
# STA start staservd
Starting staservd Service...
staservd service was successfully started
Pour arrêter le démon de services STA :
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
Pour vérifier l'état du démon de services STA :
# STA status staservd
staservd service is running
Pour plus d'informations sur la commande STA, voir le Chapitre 2, "Administration des serveurs."
|
Remarque: Après l'installation de STA, le démon de services STA démarre les services de sauvegarde STA et de contrôleur de ressources STA, mais ils ne sont pas activés tant qu'ils ne sont pas configurés. Pour configurer ces services, voir le chapitre "Configuration des services STA" dans le 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 de 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 à un emplacement spécifié sur le serveur STA ou sous forme compressée vers un serveur distant. Oracle vous recommande de configurer un serveur distant de sauvegarde.
Avant de continuer, vérifiez que le démon de services STA est bien en cours d'exécution. Voir "Démon de services STA".
"Affichage des paramètres des préférences du service de sauvegarde"
"Vérification de l'envoi des fichiers vers le serveur cible"
"Vérification qu'une copie locale des fichiers de sauvegarde apparaît sur le serveur"
"Réinitialisation du mot de passe du service de sauvegarde STA"
Le service de sauvegarde STA est configuré à l'aide de son utilitaire d'administration, staservadm, situé sous /Oracle/StorageTek_Tape_Analytics/common/bin. Pour configurer le service de sauvegarde STA, voir le chapitre "Configuration des services STA" dans le 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 fichiers suivants :
fichier dump de la base de données MySQL
fichiers journaux binaires de MySQL
fichiers de configuration du démon de services STA et de WebLogic STA
Journaux d'administration du démon de 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 dump du jour précédent présents sur le serveur STA.
Il enregistre une copie des fichiers dump du jour en cours vers le répertoire /dbbackup/local du serveur STA.
Saisissez la commande suivante pour afficher l'état des paramètres actuels des préférences :
# ./staservadm -Q
Si le champ "Configured" indique "no", alors cela signifie que le service de sauvegarde est exécuté en mode inactif et qu'il n'effectue aucune sauvegarde. Vous devez fournir les paramètres de configuration corrects, comme indiqué dans le Guide d'installation et de configuration de STA.
Exemple de sortie d'un service de sauvegarde STA configuré :
# ./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 [*********]
Saisissez la commande suivante pour effacer les paramètres actuels des préférences :
# ./staservadm -C
Le service de sauvegarde n'est plus configuré et revient en l'état inactif. Vous pouvez à présent fournir de nouveaux paramètres, comme indiqué dans le Guide d'installation et de configuration de StorageTek Tape Analytics . Par exemple :
# ./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 []
Pour vérifier que les fichiers ont bien été envoyés :
Vérifiez les journaux sur le serveur STA.
Connectez-vous au serveur de sauvegarde cible et affichez le contenu du répertoire de sauvegarde sous forme de liste.
Le fichier staservd.log.0 enregistre les activités de l'utilitaire de configuration des services de sauvegarde.
Changez le répertoire de travail pour le répertoire du journal de sauvegarde STA.
# cd /var/log/tbi/db/backups
Dans le fichier staservd.log.0, recherchez la chaîne "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
Connectez-vous au serveur de sauvegarde cible.
Affichez les fichiers sous forme de liste. Dans cet exemple, le répertoire /backups/tbivb01 a été configuré auparavant 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
Vérifiez qu'une copie des fichiers de sauvegarde les plus récents a été enregistrée localement sur le serveur STA en affichant les fichiers sous forme de liste dans le répertoire /dbbackup/local :
# ls -l /dbbackup/local
20130721_133755.conf.zip
20130721_133755.fmwconfig.zip
20130721_133755.stafullbackup.zip
Les fichiers énumérés présentent le format AAAAMMJJ_HHMMSS.nom_de_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 disque du volume de journalisation, ainsi que 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 au niveau duquel une alarme est déclenchée. Lorsque le seuil est atteint ou dépassé, une alerte est enregistrée dans le rapport de ressources standard quotidien, et, en option, est 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 à 60 %, lorsque le contrôleur de ressources STA détecte que l'application STA a utilisé 60 % ou plus du tablespace maximum alloué à la base de données, il active une 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.
"Consultation des paramètres des préférences actuels 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 est configuré à l'aide de l'utilitaire d'administration staresmonadm, situé sous /Oracle/StorageTek_Tape_Analytics/common/bin. Pour configurer le service du contrôleur de ressources STA, voir le chapitre "Configuration des services STA" dans le Guide d'installation et de configuration de STA.
Saisissez la commande suivante pour consulter l'état actuel des paramètres des préférences :
# ./staresmonadm -Q
Si le champ "Configured" indique "no", alors cela signifie que le service du contrôleur de ressources est exécuté en mode inactif et qu'il ne surveille aucune ressource et n'envoie aucun rapport. Vous devez configurer le serveur comme indiqué dans le Guide d'installation et de configuration de StorageTek Tape Analytics .
Exemple de sortie d'un service de contrôleur de ressources 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 en l'état inactif. Vous pouvez à présent fournir de nouveaux paramètres, comme indiqué dans le Guide d'installation et de configuration de StorageTek Tape Analytics . 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 sont configurés à 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, voir le chapitre "Configuration des services STA" dans le 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, à peu près à l'heure spécifiée sous 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é vers les destinataires d'e-mail spécifiés lorsque vous avez configuré ce service.
Le rapport fournit des données sur les ressources de serveur suivantes. Si l'une de ces ressources dépasse un seuil de limite supérieure, une alerte apparaît dans le rapport.
Tablespace de base de données et volume
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 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 pour le 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é vers les destinataires d'e-mail spécifiés lorsque vous avez configuré ce service. Des recommandations sont fournies dans le rapport pour permettre de résoudre le ou les problèmes signalés.
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 jar qui contiennent des applications serveur et client, des fichiers de configuration, des fichiers dump, des fichiers de journaux et un fichier de données cumulées. Cette section décrit leurs objectifs et leurs emplacements.
Le sript de démarrage/d'arrêt du démon de services STA staservd, et les liens symboliques vers le niveau d'exécution du système sont situés aux emplacements suivants :
/etc/init.d/staservd : script principal de démarrage/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 l'arrêt du système
/etc/rc3.d/S96staservd : lien symbolique pour l'arrêt du système
/etc/rc4.d/S96staservd : lien symbolique pour l'arrêt du système
/etc/rc5.d/S96staservd : lien symbolique pour l'arrêt du système
/etc/rc6.d/K04staservd : lien symbolique pour l'arrêt du système
Le script staservd init et son lien symbolique associé sont créés par le programme d'installation de STA.
L'utilitaire d'administration du service de sauvegarde STA, staservadm, est un script Perl qui fait appel à une application client Java intitulée ServerAdm contenue dans le fichier oracle.tbi.serveradm.jar. Pour plus d'informations, voir "Service de sauvegarde STA".
L'utilitaire d'administration du contrôleur de ressources STA, staservadm, est un script Perl qui fait appel à une application client Java intitulée StaResMonAdm contenue dans le fichier oracle.tbi.resmonadm.jar. StaResMonAdm est un client RMI qui communique avec le démon de services STA afin de définir et de réinitialiser les préférences d'exécution. Pour plus d'informations, voir "Service du contrôleur de ressources STA".
Le Tableau 3-1 énumère les programmes exécutables ainsi que leurs emplacements.
Tableau 3-1 Emplacements des programmes exécutables
| Programme | Emplacement |
|---|---|
|
Fichier jar du programme de 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, staservadm, d'utilisateur de l'utilitaire d'administration du service de sauvegarde STA |
$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, staresmonadm, de l'utilisateur Java de l'utilitaire d'administration ResMon STA |
$STAHOME/common/bin/staresmonadm |
Où :
$STAHOME =/Oracle/StorageTek_Tape_Analytics
Voici les types de fichiers impliqués dans l'opération de sauvegarde :
Journaux d'administration du démon de services STA et du service de sauvegarde STA
Fichiers de configuration du démon de services STA et de WebLogic
Ils enregistrent les activités de l'utilitaire ServerAdm pour la configuration du démon de services STA, du serveur STA et de ses services de configuration. Les journaux d'administration sont des regroupements de max. 10 fichiers journaux, chacun pouvant présenter une taille max. d'1,0 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 circulent en cycle, ce qui fait que le fichier journal n° 1 sera à nouveau utilisé une fois que staservd.log.9 sera plein. Le fichier journal actif porte toujours le n° #0 (staservd.log.0). Lorsque le fichier n° 0 est plein, il est renommé en fichier n° 1, et un nouveau journal n° 0 est commencé. Par défaut, les journaux du serveur STA et de ServerAdm sont situés sous
/var/log/tbi/db/backups
L'emplacement et le type du format de journal interne (soit en texte ASCII simple, soit en XML) sont gérés par le fichier des propriétés de journalisation staservd.log.props et staservadm.log.prop situés sous :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
Où :
$STAHOME =/Oracle/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 contenues. Le service de sauvegarde STA exécute les actions suivantes :
Toutes les 24 heures, il initie un vidage très rapide (également appelé "sauvegarde à chaud") des types de fichiers 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 dump du jour précédent présents dans le répertoire de sauvegarde local.
Il enregistre une copie du fichier dump du jour en cours vers le répertoire de sauvegarde local.
Le service de sauvegarde STA place par défaut ses fichiers dump locaux et ses fichiers journaux binaires incrémentiels dans le répertoire /dbbackup/local, sous le format AAAAMMJJ_HHMMSS.nom_du_fichier.sql.
Le terme vidages incrémentiels se rapporte aux fichiers binaires MySQL qui enregistrent toutes les transactions qui entraînent une modification d'une base de données. Le service de sauvegarde STA traite les fichiers 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 fichiers binaires, vous pouvez rétablir l'état d'une base de données dans lequel elle était 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 format du nom du journal binaire de sauvegarde est 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 par :
/var/log/tbi/db/
Les copies locales des fichiers journaux binaires de sauvegarde sont situées sous :
/dbbackup/local
Tous les fichiers journaux, à l'exception du plus récent, qui ont été correctement transférés vers le serveur de sauvegarde sont vidés à l'aide de la commande MySQLPURGE BINARY LOGS BEFORE NOW(). Le journal binaire actuel et le fichier de sauvegarde complet du jour en cours 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 de STA ainsi que ses propres fichiers de configuration du démon de 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é. Le format des noms de fichiers de la sauvegarde est AAAAMMJJ_HHMMSS.nom_du_fichier.zip.gz.
Les emplacements source et cibles de ces sauvegardes sont affichés dans le Tableau 3-2 :
Tableau 3-2 Emplacements source/cible de sauvegarde
| Emplacement source | Copie locale | Copie distante |
|---|---|---|
|
$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 |
Où :
$STAHOME =/Oracle/StorageTek_Tape_Analytics
$WLHOME =/Oracle/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 fichiers impliqués dans les opérations de surveillance :
Ils enregistrent les activités de l'utilitaire d'administration, staresmonadm, du démon de services STA et du contrôleur de ressources Ces journaux sont des regroupements de max. 10 fichiers journaux, chacun pouvant présenter une taille max. d'1,0 Mo. Les noms des fichiers journaux sont au format "*.log.N", où "N" est le numéro du journal (staservd.log.0, staresmonadm.log.0, staservd.log.1, et ainsi de suite).
Les journaux circulent en cycle, ce qui fait que le fichier journal n° 1 sera à nouveau utilisé une fois que staservd.log.9 sera plein. Le fichier journal actif porte toujours le n° #0 (staservd.log.0). Lorsque le fichier n° 0 est plein, il est renommé en fichier n° 1, et un nouveau journal n° 0 est commencé. Par défaut, les journaux des services STA, de STA ResMon et de STA ResMonAdm sont tous situés sous :
/var/log/tbi/db/backups
L'emplacement et le type du format de journal interne (soit en texte ASCII simple, soit en XML) sont gérés par le fichier des propriétés de journalisation staservd.log.props et staresmonadm.log.prop situés sous :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
Où :
$STAHOME =/Oracle/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 sous :
/var/log/tbi/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 graphiques avec les valeurs en fonction du temps (p.ex. une 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 représenté au Tableau 3-3.
Tableau 3-3 Format de 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 restant de disque du volume 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 restant de disque du volume 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 de 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 journalisation situés sous :
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
Où :
$STAHOME =/Oracle/StorageTek_Tape_Analytics
Le contenu et le format du fichier de journalisation sont initialisés et contrôlés par les propriétés de configuration du gestionnaire de journal Java. Ces propriétés sont issues des fichiers de propriétés de journalisation indiqués plus haut. Les informations suivantes sont accessibles à l'adresse :
http://download.oracle.com/javase/1.4.2/docs/api/java/util/logging/FileHandler.html.
Tableau 3-4 Contenu des fichiers de journalisation
| Propriété | Description | Paramètre de StorageTek Tape Analytics |
|---|---|---|
|
java.util.logging.FileHandler.append |
Spécifie si FileHandler doit s'ajouter à des fichiers existants (par défaut, paramétré sur false) |
true |
|
java.util.logging.FileHandler.count |
Spécifie le nombre de fichiers de sortie composant un cycle (par défaut, 1) |
10 |
|
java.util.logging.FileHandler.formatter |
Spécifie le nom d'une classe d'un Formatter qu'il faut utiliser (par défaut, java.util.logging.XMLFormatter) |
Java.util.logging.SimpleFormatter pour faciliter la lecture. java.util.loggin.XMLFormatter est mis à disposition sous forme de commentaire |
|
java.util.logging.FileHandler.level |
Spécifie le niveau par défaut du Handler (par défaut, Level. ALL |
CONFIG |
|
java.util.logging.FileHandler.limit |
Spécifie une quantité maximale approximative (en octets) à écrire dans un fichier quelconque. Si zéro est défini, alors il n'y a pas de limite. (par défaut, aucune limite) |
1000000 (1 Mo) |
|
java.util.logging.FileHandler.pattern |
Spécifié un modèle pour la génération d'un nom de fichier de sortie. Pour plus de détails, reportez-vous aux points ci-dessous. (par défaut, "%h/java%u.log"). |
/var/log/tbi/db/backups/staservd.log.%g /var/log/tbi/db/backups/staservadm.log.%g |
Tableau 3-5 Propriétés du démon de services STA
| Propriété | Description | Paramètre de StorageTek Tape Analytics |
|---|---|---|
|
oracle.tbi.server.level oracle.tbi.serveradm.level oracle.tbi.resmonadm.level |
Spécifie le niveau de journal pour le serveur, les fonctions d'administration du serveur ou les fonctions d'administration du contrôleur de ressources. |
CONFIG CONFIG |
La procédure de restauration STA consiste à charger le fichier dump complet le plus récent et à importer tous les journaux binaires suivant immédiatement ce vidage.
Il existe deux ensembles distincts de fichiers de sauvegarde sur 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
Le format d'horodatage et de nom de fichier est 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 fichier dump complet aura été chargé.
Les tâches d'administration suivantes sont abordées ici :
Pour copier des fichiers de sauvegarde vers le serveur :
Copiez et rapatriez l'ensemble complet de fichiers d'une même journée.
Oracle recommande de tout recopier vers 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 et décompressez les fichiers *.gz. Par exemple :
# cd /tmp # gunzip 20130723*.*.gz
Pour restaurer les fichiers du répertoire de configuration :
Arrêtez tous les processus STA. Puis 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 de services STA.
Les fichiers zip ont été créés avec les chemins de répertoires complets pour vous permettre de restaurer et/ou d'écraser les fichiers existants. La commande zip vous permet de rajouter l'option -d à la racine du chemin de restauration. 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 une sauvegarde de l'original d'abord. 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/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle/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 fichier de 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 fichiers de vidage incrémentiel (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 vers le 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 ce tableau temporaire. Lorsque le premier processus mysql est terminé, le serveur supprime le tableau temporaire. Lorsque le deuxième processus mysql tente d'utiliser ce tableau, le serveur signale un "tableau inconnu".
# 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 depuis un point de départ spécifique vers un point final ponctuel spécifique.
Par exemple, après avoir examiné le contenu d'un journal binaire, vous découvrez qu'une erreur d'opération a entraîné la suppression de plusieurs tableaux immédiatement après l'entrée de journal #6817916. Après avoir restauré la base de données depuis le 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 à partir du numéro d'entrée "176" du journal initial jusqu'au numéro d'entrée "6817916" à l'aide des commandes affichées dans cette procédure.
Pour effectuer une restauration à 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 de services STA :
# STA start all
Pour plus d'informations sur les opérations de récupération ponctuelle ou incrémentielle, voir le manuel MySQL :
http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html
|
 Copyright © 2012, 2014, Oracle et/ou ses sociétés affiliés. Tous droits réservés. Informations légales |
|