Présentation des scripts de shell Linux pour les administrateurs de bases de données

Découvrez des scripts shell bash de base pour l'installation, l'exécution et la maintenance des bases de données Oracle sous Linux.

Il y a environ sept ans, Oracle a publié la première base de données commerciale sur Linux. Depuis, Oracle, Red Hat et Novell/SUSE collaborent régulièrement aux modifications apportées au noyau Linux en ce qui concerne les performances des bases de données et des applications. Pour cette raison, Oracle Database 10g for Linux inclut des améliorations étroitement liées au système d'exploitation. Aujourd'hui plus que jamais, les administrateurs de bases de données doivent posséder des connaissances et une expérience sur cette plateforme pour mieux administrer les systèmes sous leur surveillance.

Traditionnellement, les responsabilités sont divisées entre les administrateurs de systèmes et les administrateurs de bases de données. Toutefois, dans la pratique, la distinction n'est pas toujours aussi claire. De nombreux magasins informatiques emploient des travailleurs qui répondent aux préoccupations au niveau de la base de données et du système d'exploitation. Bien sûr, Oracle Database utilise lui-même les ressources du système d'exploitation et est conçu pour interagir étroitement avec son environnement.

En outre, de nombreux Sysadmins et DBA trouvent nécessaire ou pratique d'automatiser les tâches liées à leur travail. L'installation de logiciels, la surveillance des ressources système et la gestion des systèmes constituent des tâches répétitives et sujettes aux erreurs. Ces procédures manuelles gagnent à être remplacées par des processus automatisés.

Les scripts shell sont une des méthodes pour automatiser ces tâches. Ils jouent un rôle important dans le système Linux dès son installation. Différents scripts sont exécutés lors du démarrage et de l'arrêt du système. Les utilitaires d'Oracle et d'autres fournisseurs tiers sont appelés via des scripts shell. Étant donné qu'ils peuvent être développés rapidement, ils ont toujours été utilisés pour le prototypage d'applications. Les administrateurs système tirent parti des fonctionnalités disponibles via des scripts shell pour fournir des solutions adaptées aux besoins spécifiques et aux particularités des systèmes sous leur surveillance.

Dans cet article, je présente les fonctionnalités disponibles via des scripts shell « bash » pertinentes pour l'installation, l'exécution et la maintenance des bases de données Oracle sur une plateforme Linux. Notez que cet article est conçu pour les débutants de script Linux ou les administrateurs de bases de données relativement nouveaux pour Linux ; les sysadmins Linux les plus expérimentés ne le trouveront pas utile.

Qu'est-ce qu'un script shell ?

Un script shell est simplement un fichier texte contenant une séquence de commandes. Lorsque vous exécutez le fichier (ou le script), il exécute les commandes qu'il contient. Le terme shell fait simplement référence à l'interface utilisateur de ligne de commande que vous utilisez pour communiquer avec le noyau Linux. Plusieurs shells différents sont disponibles, notamment C shell (csh), Korn shell (ksh), Bourne shell (sh) et Bourne-Again shell (bash). Le shell lui-même est une commande qui lit les lignes d'un fichier ou d'un terminal, les interprète et exécute généralement d'autres commandes. Le shell Bourne-Again intègre les fonctionnalités des autres shells mentionnés et est celui qui a été utilisé pour les scripts que cet article illustre.

La première ligne du fichier de script permet d'indiquer le shell à utiliser pour exécuter le script. Voici la signification de la première ligne trouvée dans tous les exemples de script :

# !/bin/bash

Pourquoi utiliser des scripts shell ?

Selon votre profil, il se peut que vous ne voyiez aucune valeur immédiate pour les scripts shell en ce qui concerne le travail de l'administrateur de bases de données. Si vous n'avez jamais utilisé des systèmes UNIX ou de type UNIX, la myriade de commandes obscures peut vous effrayer. En outre, en plus d'être une base de données relationnelle, Oracle 10g fournit une plateforme robuste pour le traitement des données au sein de la base de données, ainsi que plusieurs méthodes d'interaction avec le système d'exploitation en dehors de la base de données.

Cependant, plusieurs raisons peuvent vous inciter à entrer dans le monde des scripts shell, notamment :

• Vous devez prendre en charge des scripts existants.
• Vous souhaitez automatiser la configuration de votre système avant l'installation d'un logiciel Oracle. Par exemple, vous pouvez écrire un script pour vérifier l'état initial du système d'exploitation et signaler tout prérequis à satisfaire avant l'installation du logiciel. Le script peut également créer des utilisateurs et des groupes du système d'exploitation appropriés et définir des variables d'environnement pour les utilisateurs.
• Une base de données Oracle en cours d'exécution peut être utilisée pour exécuter des tâches manuelles ou programmées. Toutefois, certaines tâches doivent être exécutées lorsque la base de données n'est pas en cours d'exécution. Vous pouvez utiliser un script pour arrêter ou démarrer une base de données (ainsi qu'un processus d'écoute ou un processus de base de données associé). Une telle action ne peut pas être lancée à partir de la base de données elle-même.
• Vous avez besoin d'un mécanisme pour surveiller l'état d'une base de données (i.e. si elle est en cours d'exécution et disponible pour traiter des requêtes). Un tel script peut également surveiller les autres processus et ressources qui ne sont pas propres à Oracle pour fournir une image plus complète de ce qui se passe dans le système.
• Il faut automatiser les sauvegardes. Oracle Recovery Manager (RMAN) vous permet de développer des scripts de sauvegarde pouvant être exécutés sur n'importe quelle plateforme. Vous pouvez appeler Oracle Recovery Manager à partir d'un script shell et l'utiliser pour effectuer de nombreuses activités de sauvegarde et de récupération.
• Vous pouvez avoir une exigence qui n'est pas spécifique à une seule base de données. Vous disposez peut-être de plusieurs bases de données sur un même ordinateur. Il n'est peut-être pas conseillé de répondre à cette exigence en utilisant une seule base de données et cela pose également des problèmes de sécurité potentiels. Dans ce cas, le script shell fournit un moyen de satisfaire les exigences d'une manière qui n'associe pas le processus à une base de données unique.

Quand ne faut-il pas utiliser des scripts shell ?

Oracle Database inclut des fonctionnalités qui s'étendent au-delà de la définition traditionnelle d'un SGBDR. Comme tout autre logiciel, il utilise des ressources fournies par le système d'exploitation, mais il peut « voir » et « modifier » son environnement à un degré beaucoup plus élevé que les autres logiciels. Les vues fixes SQL et Oracle fournissent une image du système à partir de la base de données, tandis que les scripts shell fournissent une vue du système à partir de l'extérieur de la base de données. Les scripts shell ne sont pas la panacée.

Il est important de reconnaître que de nombreux aspects du système d'exploitation peuvent être surveillés et modifiés depuis la base de données. Les vues fixes d'Oracle (vues avec un préfixe v$) peuvent être utilisées pour déterminer le nom d'hôte de l'ordinateur (v$instance) ou le nom de la plateforme sur laquelle la base de données est exécutée (v$database). L'emplacement et les autres attributs des fichiers associés à la base de données peuvent également être déterminés de cette manière. L'emplacement et les autres attributs des fichiers de données (v$datafile, dba_data_files), des fichiers temporaires (v$tempfile, dba_temp_files), des fichiers de journalisation (v$logfile), des journaux d'archivage (v$archived_log) et des fichiers de contrôle (v$controlfile) peuvent être interrogés directement à partir de la base de données. Vous pouvez déterminer les informations relatives à la zone de récupération rapide ($recovery_file_dest) à partir de cette vue, ainsi que certains paramètres init.ora (db_recovery_file_dest, db_recovery_file_dest_size). Le statut des processus (v$process) et de la mémoire (v$sga, v$sgastat, etc.) peut également être interrogé. Il existe différents packages PL/SQL intégrés, ainsi que la possibilité de créer des objets de base de données Java et C qui permettent d'accéder davantage au système d'exploitation sous-jacent.

Si vous envisagez de créer des scripts pour une tâche qui nécessite de nombreux accès à la base de données, ce n'est probablement pas votre meilleure option. Plus loin dans cet article, vous trouverez une description de l'accès à la base de données à l'aide de SQL*Plus, mais dans de nombreux cas, il est préférable d'aborder le problème en utilisant un autre langage.

Les graphiques ci-dessous récapitulent les informations accessibles à partir de la base de données elle-même :

Scripts BASH

Les scripts sont invoqués dans le cadre d'un processus automatisé (sans intervention humaine) ou exécutés de manière interactive lors qu'un utilisateur répond aux questions. Tant que vous disposez des droits d'accès exécutables pour un fichier, vous pouvez l'exécuter à partir de la ligne de commande en saisissant son nom. Si vous ne disposez pas de droits d'accès exécutable pour le fichier mais que vous disposez de droits d'accès en lecture, vous pouvez exécuter le script en le faisant précéder de sh.

Si un script est conçu pour être exécuté sans saisie par l'utilisateur, plusieurs options sont disponibles pour l'appeler. Vous pouvez exécuter un script en arrière-plan et continuer même si vous vous déconnectez, en saisissant une commande au format suivant :

nohup /path_to_dir/myscript_here.sh &

Cette méthode peut être utile pour exécuter des scripts qui prennent beaucoup de temps. La commande at peut être utilisée pour exécuter un script ultérieurement et cron peut être utilisé pour programmer l'exécution de scripts de façon récurrente.

Les exemples suivants couvrent les aspects essentiels de la fourniture d'une sortie à afficher (à l'aide de echo), de la boucle, de la logique conditionnelle et de l'affectation de variable.

print_args.sh. Les arguments sont des mots situés à droite du nom de commande transmis au script. Pour accéder au premier paramètre, utilisez la variable $1. La variable $0 contient le nom du script lui-même. La variable $# contient le nombre d'arguments dans le script. Une méthode pratique pour parcourir tous les paramètres transmis implique l'utilisation d'une boucle while et de la commande shift. Cette commande permet de parcourir tous les arguments de la liste d'arguments (plutôt que de rester dans une boucle infinie).

while [ $# -ne 0  ]
do
        echo $1
        shift
done

Si un script prend un nom de fichier comme argument (ou invite l'utilisateur à entrer un nom de fichier) et que le fichier est lu ultérieurement dans le script, il est conseillé de vérifier s'il est accessible et lisible. Par exemple, un script de récupération impliquant la sélection d'un fichier de contrôle sauvegardé peut inviter l'utilisateur à effectuer une sélection qui sera utilisée ultérieurement dans le script pour restaurer le fichier.

if [ ! -r $1 ]; then # not exists and is readable
                        echo "File $1 does not exist or is not readable."
                exit;
fi 

La séquence de caractères

if [ ! -r $1 ];

permet réellement d'effectuer le test. Si le contenu entre crochets renvoie la valeur true, les commandes qui apparaissent entre if et fi seront exécutées. Le test se trouve entre les crochets. Le point d'exclamation permet d'obtenir l'inverse du test. L'option -r vérifie si le fichier est lisible. Dans ce cas précis, le test porte sur le premier argument transmis au script. En utilisant un autre test (-d), vous pouvez vérifier si une entrée donnée est un répertoire (voir is_a_directory.sh).

do_continue.sh. Cet exemple est une séquence représentative simple de commandes pouvant être utilisée pour lire des entrées utilisateur à diverses fins. Avant d'exécuter un processus pouvant entraîner une perte de données ou d'autres résultats indésirables dans certaines conditions qui ne sont pas déterminables à partir du script, il est conseillé d'inclure une invite demandant si l'utilisateur souhaite réellement que le script exécute la ou les commandes suivantes. L'exemple suivant demande si l'utilisateur veut continuer, lit une variable nommée doContinue à partir de la ligne de commande et évalue ce que l'utilisateur a saisi. Si l'utilisateur saisit autre chose que "y" (pour « yes »), cette personne est informée que le script va être interrompu et qu'il se ferme sans exécuter le reste du script après la fin du bloc if (fi).

doContinue=n
echo -n "Do you really want to continue? (y/n) " 
read doContinue

if [ "$doContinue" != "y" ]; then
      echo "Quitting..."
      exit
fi

Il est impératif que seuls les utilisateurs disposant des droits d'accès et de l'environnement appropriés exécutent un script donné. Une vérification utile d'un script teste l'utilisateur qui tente d'exécuter le script. Si vous placez une commande entre des guillemets inversés (‘), les résultats de la commande peuvent être renvoyés au script. L'exemple suivant récupère l'utilisateur actuellement connecté à l'aide de whoami et affiche la date à l'aide de la commande date plus tard dans le script.

echo "You are logged in as ‘whoami‘";

if [ ‘whoami‘ != "oracle" ]; then
  echo "Must be logged on as oracle to run this script."
  exit
fi

echo "Running script at ‘date‘"

Les scripts écrits pour interagir avec Oracle Database nécessitent parfois la saisie d'informations sensibles, telles qu'un mot de passe de base de données. La commande stty –echo désactive l'affichage à l'écran, de sorte que les informations saisies pour la commande de lecture suivante n'apparaissent pas à l'écran. Une fois que les informations sensibles ont été lues et stockées dans une variable (pw dans l'exemple ci-dessous), l'affichage peut être réactivé avec un écho stty.

stty -echo    
        echo -n "Enter the database system password:  "
        read pw
stty echo

Scripts Oracle

Certains fichiers se trouvent à un emplacement fixe pour une installation Oracle donnée. Vous pouvez déterminer l'inventaire Oracle en consultant le fichier /etc/oraInst.loc. Le fichier /etc/oratab identifie les bases de données (et autres programmes Oracle) installées sur le serveur.

get_inv_location.sh. Ce script est un peu moins intuitif que les exemples précédents. En décomposant le script en commandes de composant, vous comprendrez mieux ce qui est accompli.

Pour déterminer l'emplacement de l'inventaire, vous allez diriger les résultats de la commande cat (qui affiche le contenu du fichier) vers grep (utilitaire qui imprime les lignes correspondant à un modèle donné). Vous recherchez des lignes contenant inventory_loc.

cat /etc/oraInst.loc | grep inventory_loc

S'il existe plusieurs emplacements, car il y a plusieurs installations, il convient d'exclure les lignes commentées avec un # . L'option -v exclut les lignes contenant le modèle donné.

cat /etc/oraInst.loc |grep -v "#"|grep inventory_loc

Le résultat de cette commande se présente comme suit :

inventory_loc=/u01/oraInventory

Vous pouvez rediriger le résultat vers un fichier à l'aide de la redirection >. Si le fichier n'existe pas, il est créé. S'il existe, il est écrasé.

cat /etc/oraInst.loc|grep -v "#"|grep inventory_loc > tmp

Une fois que vous disposez de l'enregistrement qui indique l'emplacement de stockage, il faut supprimer la partie de l'enregistrement avant le signe égal. Cette fois-ci, vous envoyez les résultats de la commande cat à l'éveil (langage d'analyse de modèle et de traitement souvent utilisé pour fractionner les champs de longueur variable), qui symbolise essentiellement la chaîne. L'option –F indique à awk d'utiliser le signe égal comme séparateur. Vous imprimez ensuite le deuxième jeton de cette chaîne ($2), qui correspond à tout ce qui est à droite du signe égal. Le résultat est notre emplacement de stockage (/u01/oraInventory).

cat tmp | awk -F= '{print $2}'

Il n'y a pas de raison particulière de conserver le fichier temporaire (tmp), il peut donc être supprimé.

rm tmp

list_oracle_homes.sh. Si vous souhaitez déterminer ORACLE_HOME pour une base de données donnée, vous disposez de plusieurs options. Vous pouvez vous connecter en tant qu'utilisateur de base de données et afficher la variable $ORACLE_HOME avec la commande echo. Vous pouvez également effectuer une recherche dans le fichier /etc/oratab et sélectionner le nom associé à une instance donnée. Les entrées de base de données de ce fichier sont au format

$ORACLE_SID:$ORACLE_HOME:<N|Y>:

L'un des liens suivants affiche la valeur ORACLE_HOME d'une entrée avec la valeur ORACLE_SID de TESTDB :

cat /etc/oratab | awk -F: '{if ($1=="TESTDB") print $2 }'

Toutefois, que faire si vous devez effectuer une opération sur chaque ORACLE_HOME répertorié dans le fichier /etc/orainst ? Vous pouvez parcourir une telle liste en utilisant le fragment de code suivant.

dblist=‘cat /etc/oratab | grep -v "#" | awk -F: '{print $2 }'‘

for ohome in $dblist ; do
  echo $ohome
done

La variable dblist est utilisée en tant que tableau. Tous les chemins ORACLE_HOME se trouvent dans cette variable. Une boucle for est utilisée pour parcourir cette liste et chaque entrée est affectée à la variable ohome, puis transmise vers la sortie standard.

search_log.sh. Divers journaux sont générés par les produits Oracle et vous pourriez vouloir les surveiller. Le journal d'alertes de base de données contient des messages qui sont essentiels pour les opérations de base de données. Les fichiers journaux sont également générés lors de l'installation ou de la désinstallation des produits et lors de l'application des correctifs. Le script suivant itère sur un fichier qui lui est transmis en tant qu'argument. Si des lignes contiennent ORA-, un e-mail est envoyé au destinataire désigné.

cat $1 | grep ORA- > alert.err

if [ ‘cat alert.err|wc -l‘ -gt 0 ]
then
        mail -s "$0 $1 Errors" administrator@yourcompany.com < alert.err
fi 

Le test spécifique en cours d'exécution est le nombre de mots qui existent dans le fichier alert.err, qui est écrit lorsque vous redirigez vers alert.err. Si le nombre de mots (wc) est supérieur à (-gt) zéro, le contenu du bloc if sera exécuté. Dans ce cas, vous utilisez mail (send mail peut également être utilisé) pour envoyer un message. L'objet du message contient le script en cours d'exécution ($0), le nom du journal recherché ($1) et les lignes qui correspondent à notre recherche initiale (ORA-) comme corps du message.

Des variables d'environnement telles que ORACLE_HOME, ORACLE_BASE et ORACLE_SID peuvent être utilisées pour localiser des ressources qui ne se trouvent pas à un emplacement fixe dans l'environnement Linux. Si vous administrez une instance d'application Oracle E-Business Suite 11i, vous disposez de nombreuses autres variables d'environnement pouvant être utilisées pour localiser des ressources. Il s'agit notamment de APPL_TOP, TWO_TASK, CONTEXT_NAME et CONTEXT_FILE, pour n'en nommer que quelques-uns. Pour afficher la liste complète de votre environnement, exécutez la commande suivante et examinez le fichier obtenu (myenv.txt) :

env > myenv.txt

Différentes combinaisons de ces variables d'environnement peuvent être utilisées comme emplacement d'un fichier recherché. Par exemple, un emplacement de journal d'alertes peut être désigné comme

$ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log

En fonction des principes introduits dans ce script, un plus grand principe peut être écrit et programmé pour s'exécuter à intervalles réguliers, ce qui permet de rechercher le contenu du fichier d'alertes (ou un autre fichier d'intérêt) et d'envoyer un e-mail s'il existe des erreurs. Ensuite, le contenu du journal peut être déplacé vers un autre fichier, afin d'envoyer par e-mail seulement les messages d'erreur les plus récents.

Scripts Oracle Recovery Manager. Oracle Recovery Manager (RMAN) est un utilitaire qui peut être utilisé pour administrer la sauvegarde et la récupération de la base de données. Il simplifie considérablement l'administration sur plusieurs plateformes, car tous les scripts de sauvegarde peuvent être écrits pour être exécutés par RMAN, ce qui réduit la quantité de code propre à la plateforme. RMAN peut être appelé par le système d'exploitation sous-jacent et transmis un script. Par exemple, une sauvegarde à froid (cold.sh) peut se composer du script suivant :

#!/bin/bash
rman target / <<EOF
shutdown immediate;
startup mount;
backup spfile;
backup database;
alter database open;
delete noprompt obsolete;
quit;
EOF

La ligne 1 indique que vous utilisez le shell bash. La ligne 2 appelle Oracle Recovery Manager et spécifie la connexion utilisateur du système d'exploitation à la base de données cible (spécifiée dans la variable d'environnement $ORACLE_SID). L'élément <<EOF qui suit indique que les commandes suivantes seront transmises à RMAN pour traitement. La fin de la dernière (EOF) ligne indique que vous avez atteint la fin de la série de commandes à transmettre à RMAN. RMAN est ensuite utilisé pour arrêter la base de données, démarrer et monter la base de données, puis procéder à la sauvegarde du fichier de paramètres serveur et du contenu de la base de données. La base de données est alors ouverte. Les sauvegardes antérieures à celles indiquées dans la stratégie de conservation sont ensuite supprimées. Reportez-vous à la documentation RMAN pour créer une sauvegarde adaptée à votre situation.

Les sauvegardes nocturnes sont généralement programmées et exécutées automatiquement. Le script ci-dessus peut être appelé et le contenu de la sortie standard envoyé à une adresse e-mail avec la commande suivante :

sh cold.sh | mail -s"Backup ‘date‘" administrator@yourcompany.com

D'autres utilitaires Oracle peuvent également être exécutés à partir de scripts shell. L'utilitaire tnsping peut être utilisé pour déterminer si un identificateur de connexion Oracle donné peut contacter le processus d'écoute. Vous pouvez exécuter cet utilitaire pour vérifier les problèmes de connexion :

tnsping ptch04 | grep TNS-

Les exportations et les importations de bases de données (traditionnelles et data pump) sont également de bons candidats pour le script des processus récurrents.

Installation de la base de données. De nombreuses étapes de la configuration d'une base de données peuvent être automatisées. Avant d'installer Oracle 10g sous Linux, vous devez exécuter différents tests pour vérifier la version minimale requise des packages et les paramètres du noyau. Vous pouvez obtenir la version d'un package à l'aide de la commande rpm avec l'option –q.

rpm -q compat-libstdc++

Vous pouvez déterminer différents aspects du système en consultant le système de fichiers /proc « virtuel » ou « pseudo ». Il ne contient pas de fichiers réels, mais plutôt des informations système d'exécution qui peuvent être affichées comme si elles résidaient dans des fichiers. Par exemple, /proc/meminfo contient les informations relatives à la mémoire du système et MemTotal /proc/meminfo affiche la mémoire totale du système. En utilisant awk comme vous l'avez fait précédemment, vous pouvez isoler la quantité de mémoire en kilo-octets, en utilisant :

grep MemTotal /proc/meminfo | awk '{print $2}'

Une telle commande peut être utilisée dans le contexte d'un script qui effectue des comparaisons et répondrait en conséquence (voire réaliserait la mise à jour le système lui-même). Les exemples de scripts 10gchecks_kernel.sh et 10gchecks.sh affichent simplement les versions et paramètres actuels et recommandés en fonction de la documentation Oracle.

Surveillance de bases de données. La commande ps peut être utilisée pour examiner le statut du processus et vérifier si une base de données, un processus d'écoute, un script ou tout autre processus intéressant est en cours d'exécution. Si vous souhaitez répertorier toutes les bases de données en cours d'exécution sur un serveur, vous pouvez exécuter la commande suivante :

echo "‘ps -ef | grep smon|grep -v grep|awk '{print $8}'| awk -F \"_\" '{print$3}'‘"

Bien que cela soit fonctionnel, c'est un peu difficile à comprendre à première vue. La première commande, ps (à l'aide des options -ef pour une liste complète de tous les processus), recherche tous les processus en cours d'exécution sur le serveur. L'élément suivant, grep, recherche SMON (processus en arrière-plan Oracle System Monitor), qui indique que la base de données est en cours d'exécution. Vous souhaitez supprimer les entrées qui font référence à la commande grep elle-même, qui est en cours d'exécution. Vous utilisez ensuite awk pour localiser la huitième colonne de la liste, qui contient le nom du processus de surveillance système sous la forme ora_smon_<oracle_sid>. La dernière instance de awk utilise ensuite le caractère de soulignement comme séparateur pour rechercher et imprimer le nom de la base de données propriétaire du processus SMON. Le tiret bas doit apparaître entre guillemets et la barre oblique inverse est utilisée avant chaque guillemet pour échapper à ces guillemets (car la chaîne entière apparaît entre guillemets).

exec_sql.sh. Comme mentionné précédemment, il est possible d'interroger la base de données à partir d'un script shell à condition que l'utilisateur ait accès à sqlplus. L'exemple suivant renvoie une liste (séparée par des espaces) de machines qui gèrent actuellement des sessions dans la base de données :

  
   
#!/bin/bash

output=‘sqlplus -s "/ as sysdba" <<EOF
       set heading off feedback off verify off
       select distinct machine from v\\$session;
       exit
EOF
‘

echo $output    

Ce script est similaire au script RMAN précédent dans la mesure où vous saisissez des commandes dans un autre programme. Une connexion locale authentifiée par le système d'exploitation est établie sur la base de données en tant que sysdba. Pour empêcher le renvoi de messages inutiles, ce script désactive l'en-tête, les retours et vérifie les options de SQL*Plus. La requête est exécutée et SQL*Plus est quitté.

N'oubliez pas la double barre oblique inverse avant le signe dollar dans le nom de la vue. Il s'agit de séquences d'échappement requises dans la chaîne : la première barre oblique échappe à la seconde barre oblique, qui échappe au signe dollar. Encore une fois, ce n'est pas très élégant, mais ça fonctionne.

Comme mentionné précédemment, si vous souhaitez écrire un élément nécessitant un accès étendu à la base de données, le script shell n'est pas la meilleure option. Il peut être préférable de réécrire le script en langage PL/SQL, Perl (qui utilise une syntaxe similaire à celle utilisée dans les scripts shell), Python, Java ou un autre langage de votre choix.

Conclusion

Les scripts shell peuvent être un outil efficace pour automatiser rapidement les tâches d'administration répétitives et sources d'erreurs. Les exemples de cet article donnent une introduction aux possibilités disponibles, mais ils sont loin d'être exhaustifs. Chaque système présente des disfonctionnements et des défauts distincts ainsi qu'une configuration unique. Un administrateur développera des solutions uniques pour répondre aux besoins de chaque système.

Casimir Saternos est DBA certifié Oracle, développeur d'entreprise certifié IBM et programmeur Java certifié Sun à Allentown aux États-Unis.