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.
lundi 21 février 2011
mercredi 16 février 2011
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.
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/
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.
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.
vendredi 4 février 2011
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.
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.
S'abonner à :
Messages (Atom)