Un pare-feu pour la base de données

Pour aider sa clientèle à prévenir les attaques internes et externes, Oracle a développé un nouveau produit intitulé Oracle Database Firewall. Il est destiné à défendre et à protéger les bases de données. En quelque sorte, il est sur la ligne de front. Ce nouveau produit surveille l'activité de base de données sur le réseau pour aider à prévenir les accès non autorisés, les injections SQL, l’escalade de privilège ou de rôle, et plusieurs autres attaques internes et externes et ce, en temps réel.

Ce pare-feu de base de données ne nécessitent pas de modifications aux applications existantes, et, en plus de protéger la plus récente base de données Oracle (11g) et celles précédentes, il peut être utilisé avec IBM DB2 pour Linux, UNIX et Windows, Microsoft SQL Server 2000, 2005 et 2008; Sybase Adaptive Server Enterprise (ASE) (versions 12.5.3 à 15), et Sybase SQL Anywhere V10.

Grâce à une technologie d’analyse grammaticale d’énoncé SQL, Oracle Database Firewall examine les énoncés SQL envoyées à la base de données et peut conserver une trace, alerter, bloquer ou remplacer certaines instructions SQL selon des politiques prédéfinis.

Cette solution est très intéressante et mérite d'être explorer mais, omme tout autre méthode de sécurisation, il y a assurément un impact sur la performance car, il faut bien que le travail s'effectue.

Identifier la base de données utilisée par le processus

En surveillant la performance des processus sur un serveur Linux, j'ai remarqué qu'il y avait un processus qui était réellement gourmand en temps CPU. Pour mieux comprendre, j'ai voulu obtenir plus de détails sur celui-ci.

La seule chose que je savais, c'est que le processus concerné avait été démarré avec le compte Oracle et c'est tout. Aucune autre information m'indiquait sur quelles bases de données je devais investiguer et, disons que ça ne me tentait pas de les faire une à une car ce serveur en héberge plusieurs.

En sachant que chaque processus démarré sur le serveur a ses propres valeurs de variables d'environnement, nous pouvons connaître sur quelle base de données il a effectué sa connexion en consultant le contenu du fichier intitulé "environ". Ce fichier est situé sous le répertoire "/proc/". Dans mon cas, j'ai identifié l'identifiant du processus (13198) via l'outil "top" et ensuite, j'ai exécuté la commande suivante :

cat /proc/13198/environ

La commande affiche toutes les variables d'environnement et leurs valeurs. Il suffit d'y repérer la valeur de la variable "ORACLE_SID" et vous saurez sur quelle base de données le processus s'exécute.

Impasse suite à une tentative d'export

Après avoir tenté un export d'un schéma sur une base de données avec l'outil EXPDP, j'ai obtenu une erreur, qui malheureusement, je ne me souviens pas. Suite à cette erreur, j'ai tenté à nouveau un export mais sans succès car rien n'aboutissait.

J'ai alors vérifié l'état de la session dans la vue « v$session » et, j'ai remarqué que ma session provenant de l'outil EXPDP était bloquée par une autre. La session bloquante correspondait à ma précédente session qui était tombée en erreur.

Pour me permettre de réaliser l'export, j'ai alors décidé de terminer la session avec la commande "Alter system kill session". À ma grande surprise, la base de données m'a retournée une erreur me disant que la session n'existe pas. Suite à cela, j'ai décidé d'être plus radicale puis de terminer la processus de la session directement sur le serveur. Encore là, je ne trouvais pas de processus correspondant à la session. Me voilà dans une impasse... Le seul moyen que j'ai pu faire pour m'en sortir a été de redémarrer l'instance de la base de données avec la commande "shutdown abort" car la commande "shutdown immediate" ne parvenait pas à arrêter les processus.

Si vous avez déjà rencontré ce genre de problème et que vous l’avez résolu autrement, merci de partager avec moi.

Surveillance du matériel

Afin d'assurer une disponibilité du service, une surveillance des performances matérielles est primordial. La surveillance des performances peut être divisée en quatre ressources principales :

Processeur

La surveillance de l'utilisation du processeur permet de suivre le niveau de travail généré par l'ensemble des processus

Mémoire

La surveillance de la mémoire permet de déterminer l'utilisation de la mémoire vive par les processus et cela nous indique si elle est suffisante

E/S disque (IO)

L'E/S disque peut souvent s'avérer être un goulot d'étranglement lorsque des traitements impliquant un volume très important de données nécessitent plusieurs accès disque. Parfois, ceci peut être provoqué par une mémoire vive insuffisante.

Flux réseau

Le flux réseau a des conséquences notables sur les performances lorsqu'il y a un nombre important d'accès clients simultanés.

Il est recommandé, en tant que meilleure pratique, d'effectuer une surveillance préventive des ressources de manière à ce qu'elles ne dépassent pas régulièrement 80 %. Une ressource qui atteint ce niveau doit soulever un avertissement. Si les ressources atteignent le seuil de 90%, il est recommandé de considérer ce niveau comme étant critique. Peu importe le niveau atteint, il est important d'investiguer afin d'identifier les causes.

Durant une période de 24 heures, les ressources sont sollicitées très différemment. Le niveau de service est beaucoup plus important au cours de la journée qu'en dehors des heures ouvrables habituelles car la majorité des ressources doivent être disponibles aux utilisateurs du système. À l'occasion, les seuils peuvent être franchis en soirée avec une plus grande tolérance car les travaux planifiés tels que les traitements en lot, la génération de rapport et les prises de copie de sécurité sont effectués pendant cette période de bas achalandage et, se disputent grandement les ressources. Le même phénomène se produit de façon hebdomadaire, mensuel, trimestriel, annuel, etc...

Afin de mieux gérer les différentes périodes d'achalandage, la mise en place d'une ligne de base (baseline) permet de mieux interpréter, analyser et comprendre l'utilisation des ressources aux différentes périodes. D'ailleurs, l'implantation d'une ligne de base permet de gérer efficacement les notifications sans en générer inutilement.

Même si la surveillance est un élément très important, celle-ci ne doit pas être trop présente et énergivore. Avec l'aide de compteur et un minimum de ressources, elle doit être en mesure de collecter et surveiller l'utilisation des ressources sans entraîner à elle seul des problèmes de performance.

À ne pas mettre avant la commande "BACKUP"

En voulant prendre une copie de la commande de création du "Controlfile" de la base de données dans un script RMAN, je me suis aperçu que la série de commandes n'était pas générée dans le fichier de trace.

Après quelques essais, je me suis rendu compte que si la commande "BACKUP..." suit directement la commande "ALTER DATABASE BACKUP CONTROLFILE...", le fichier de trace se créer sans contenir les commandes SQL.

Donc. j'ai tout simplement déplacé la commande SQL à la toute fin :

run
{
BACKUP DATABASE FILESPERSET 1 PLUS ARCHIVELOG;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";
}

Ceci a été observé en effectuant une sauvegarde d'une base de données Oracle 10G Express Edition (XE) sous Linux RHEL4 sans catalogue RMAN.

Outil de désinstallation d'Oracle 11gR2

Depuis la version 11gR2, Oracle rends disponible un outil de désinstallation. Ce dernier est situé dans "$ORACLE_HOME/deinstall" et il peut être téléchargé à partir du site d'Oracle au même endroit qu'on retrouve les fichiers pour la base de données.

L'outil de désinstallation effectue vraiment tout. Il supprime Oracle Clusterware, Oracle Automatic Storage Management (ASM), et Oracle Real Application Clusters (Oracle RAC) ou, une installation de base de données Standalone.

L'outil effectue toutes les actions nécessaires lors de la suppression du logiciel à partir d'un ORACLE_HOME. Il identifie toutes les instances associées à un ORACLE_HOME et il s'occupe d'arrêter tous les processus pour ensuite, supprimer toutes les composantes incluant les "listeners".

Pour l'exécuter, il suffit de mentionner au minimum l'ORACLE_HOME que vous désirez supprimé. Voici un exemple :

$ORACLE_HOME/deinstall/deinstall -home /u01/app/oracle/product/11.1.0/db_1

Vous pouvez utiliser le paramètre "checkonly". Ce dernier est fort utile car il fait le même traitement cependant, il ne supprime aucune composante :

$ORACLE_HOME/deinstall/deinstall -home /u01/app/oracle/product/11.1.0/db_1 -checkonly

Bon ménage à tous !

OOW 2010 – Database Track – Jour 4…le dernier!

C'est peut-être le dernier jour mais non le moindre en fait de contenu. Aujourd'hui, j'ai eu droit à des conférences sur l'optimisation avec les outils ASH et AWR et, une autre à propos d'Oracle Active Data Guard. Comme toutes les autres sessions, elles furent très intéressantes et remplies d'informations pertinentes.

La première conférence était présentée par nul autre que Thomas Kyte. Disons que ça commence bien la journée! Comme d'habitude, il a su me captiver dès la première seconde et ce, jusqu'à la toute dernière.

Ce que j'ai particulièrement aimé (et que j'aimerai probablement toujours), c'est les façons d'effectuer de l'optimisation à partir de simples lignes de commandes avec un outil tel que SQL*Plus. Les raisons sont bien simples car en mandat nous n'avons pas toujours recours à des outils graphiques et, aussi, j'aime voir les commandes exécutées et les résultats. Je ne suis pas trop fervent des boites noirs par lesquels une multitude de commandes sont exécutées sans que nous ne sachions ce qui est accomplis.

Alors, voici quelques faits à propos d'ASH ainsi qu'AWR :

ASH

• ASH = Active Session History
• ASH est toujours actifs, donc, lorsqu'un problème survient, on peut directement s'y référer puis comparer les valeurs actuelles avec celles précédant le problème.
• Simplifie l'investigation car autrement un problème peut être difficilement reproduit
• Ce mécanisme accède directement à la structure du noyau de la base de données
• Ne contient pas tous les énoncés SQL qui ont été exécutés. On y retrouve seulement ceux qui ont été actifs et qui sont plus " gourmands "
• Un échantillon d'énoncé SQL actif est collecté à chaque seconde en mémoire. Le processus " MMON Lite (MMNL) " s'occupe d'accomplir cette tâche.
• L'échantillon est conservé dans une cache (buffer) circulaire dans le SGA. Par défaut, il a la dimension de 2 MB par CPU (consulter la vue V$SGASTAT pour la taille totale utilisée)
• Les données d'ASH sont principalement consultées via la vue V$ACTIVE_SESSION_HISTORY
• Une partie de l'échantillon utilisé par ASH alimente l'AWR
• Permet d'effectuer une analyse basée sur le temps de traitement sur la base de données (DB Time)
• Les données proviennent principalement des vues V$SESSION et V$SESSION_WAIT
• Si nous effectuons la somme des secondes d'ASH, nous obtiendrons le " DB Time "
• La page " Top Activity " dans Oracle EM est basée sur les données d'ASH. Le pourcentage d'activité correspondant à un énoncé SQL correspond au pourcentage du " DB Time "
• Il ne faut pas utiliser des fonctions telles que MIN, MAX et AVG avec les données provenant d'ASH car les résultats seront biaisés. Les données proviennent d'échantillon et les longs traitements fausseront les résultats.
• Le contenu d'ASH peut être exporté puis chargé dans une table ou un chiffrier
• ASH n'est pas un résultat de trace mais plutôt de l'échantillonnage

AWR

• AWR = Automatic Workload Repository
• AWR est présent dans toutes les éditions de base de données
• Il est constitué de statistiques de base (ex. physical reads), de statistiques sur les énoncés SQL (disk read par SQL), mesures (physical reads/seconde) et d'information (échantillon) provenant d'ASH.
• Un cliché (snapshot) provient d'un processus qui extrait les données de la mémoire puis qui les écrient sur disque.
• Ne jamais comparer deux clichés dont un redémarrage de base de données a eu lieu durant la période couverte par les clichés
• Le package DBMS_WORKLOAD_REPOSITORY permet de gérer l'AWR
• La rétention par défaut est de 7 jours, Oracle supprime automatiquement les données plus anciennes. Il est recommandé (bonne pratique) de conserver un minimum d'un mois.

En conclusion, Oracle Open World fut une expérience formidable. J'ai grandement apprécié les conférences. Je fus très impressionné par l'ampleur de l'événement. Bravo à Oracle et je leur dit : " Two Thumbs Up "