Utiliser Perl DBI avec Oracle

Avec Oracle10g , Perl vient préconfiguré. Il est d'ailleurs utilisé par les agents Enterprise Manager, en mode "Database control" ou "Grid Control". Voici un exemple simple de fichier Perl qui accède au schéma hr d'une base de données dont l'alias est "blue" :

#!/bin/perl
use strict;
use DBI;

my $dbh = DBI->connect('DBI:Oracle:blue', 'hr', 'hr',)
or die "Impossible de se connecter à la base de données: " . DBI->errstr;

my $sth = $dbh->prepare('select first_name, last_name from employees')
or die "Impossible de créer le statement: " . $dbh->errstr;

my @data;

$sth->execute()
or die "Impossible d'exécuter la requête: " . $sth->errstr;

while (@data = $sth->fetchrow_array()) {
my $fname = $data[0];
my $lname = $data[1];
print "\tnom: $fname $lname \n";
}

$sth->finish;
$dbh->disconnect;


Quelques remarques

• Cet exemple a été testé sur une base de données 10.2.0.2 sous Linux
• Pour les besoins de l'exemple, les variables qui suivent ont été configurées :
• ORACLE_HOME=/u01/oracle/product/10.2.0/db_1
• PATH=$ORACLE_HOME/bin:$ORACLE_HOME/perl/bin:$PATH
• PERL5LIB=$ORACLE_HOME/perl/lib/5.8.3:$ORACLE_HOME/perl/lib/site_perl/5.8.3
• LD_LIBRARY_PATH=$ORACLE_HOME/lib
• Pour que le programme "perl" soit exécuté directement avec le script, il faut créer un lien symbolique de /bin/perl vers $ORACLE_HOME/perl/bin/perl (ça ne fonctionnera que sur Unix ou Linux)
  
  

Créer les schémas d'exemples Oracle

Les schémas d'exemples Oracle (HR, OE, PM, IX, SH) peuvent être créés :

• Avec DBCA lors de la création d'une base de données
  
• Manuellement avec les scripts correspondants
  

Pour créer ces schémas d'exemples manuellement, il convient d'installer les composants de la base de données contenu dans le "Companion CD" de la base de données. Une fois ces composants installés dans le répertoire du logiciel Oracle, vous pourrez y accèder dans le répertoire "demo/schema". Pour en savoir plus, il existe un document intitulé "Sample schema" dans l'ensemble des documentations Oracle 9i ou 10g.

GArK!

Configurer Oracle Database Control 10.2

Une fois une base de données créée et si vous n'avez pas utilisé "dbca", vous devez éventuellement configurer le database control manuellement (Il est extrèmement recommandé *à d'autres fins que de simples fins de tests* d'utiliser un Enterprise Manager Grid Control). Si toutefois, vous pensez toujours vouloir créer un "Database Control", tapez la ligne qui suit sous le compte oracle :

$ emca -config dbcontrol db -repos create

Cet assistant vous demande plusieurs informations comme :

• le nom de l'instance
• le port du listener
• le mot de passe de sys
• le mot de passe de dbsnmp (il crée l'utilisateur)
• le mot de passe sysman (il crée l'utilisateur)

L'assistant effectue la configuration et vous informe de l'URL qu'il faut utiliser pour vous connecter...

G-ArK!

Technologies pour les sauvegardes Oracle

Il existe de nombreuses technologies qui permettent d'effectuer des sauvegardes : les technologies dites "matérielles", les technologies logicielles et les technologies de la base de données.

Les solutions "dites" matérielles :

• Les technologies basées sur des "split-mirrors" consistent à synchroniser des mirroirs de disques, puis d'arrêter la synchronisation afin de garder une image figée des données. Il est généralement possible ensuite de les remonter sur une autre machine et de les envoyer sur bandes. Parmi ces techniques, on peut citer les solutions de "Business Continuance Volumes" (BCV) d'EMC piloté par "TimeFinder" ou "SnapView", les "Business Copy" de HP piloté par "HP StorageWorks Business Copy XP", Les "ShadowImages" d'HDS et Sun et les "FlashCopy" d'IBM.
• La capture des blocs de données modifiées lors de leur écriture et la présentation d'un cliché cohérent en lecture seule à partir de ces captures ont différentes implémentations toutes désignées par la terminologie de "snapshots". On peut citer les copy-on-write snaphots de HDS, les snapshots IBM, StorageWorks Snapshot XP de HP, StorEdge Data Snapshot de Sun, les snapshots d'EMC gérés par EMC Clariion Snapview ou Timefinder et dans un registre d'implémentation un peu différent, les snapshots de Netapp basés sur leur WAFL.
• La réplication de données d'un site à un autre (en mode synchrone ou asynchrone) sont gérés par différentes technologies comme HDS TrueCopy, HP Continuous Access, EMC SRDF ou encore IBM Peer to Peer Remote Copy (PPRC)
• Les technologies de validations des blocs Oracle dans les baies de stockage permettent d'assurer au plus tôt les problèmes de cohérence des données d'une base de données et les résoudre automatiquement. Ces technologies nécessitent l'utilisation de raw devices ou d'Oracle ASM pour que les données dans la baies correspondent aux données en mémoire. Pour en savoir plus sur ce thème, reportez-vous à l'URL qui suit : http://www.oracle.com/technology/deploy/availability/htdocs/HARD.html

Les solutions "dites" logicielles offrent dans des techniques relativement similaires effectuées au niveau des machines :

• Les volumes manager des différents systèmes d'exploitation ou spécialisés sont parfois capables de constituer des copies de volumes ou des "snapshots" à la manière d'une baie de stockage. Par exemple, FlashSnap l'option du volume manager Veritas est capable d'effectuer des copies ou snapshots en lecture depuis depuis les machines. Ils permettent également et généralement d'assurer que les données sont dupliquées dans plusieurs baies de stockage.
• Les medias manager (HP Data protector, EMC EDM et Legato, Veritas NetBackup, Atempo Time Navigator, IBM TSM...) sont des logiciels qui font le lien entre les systèmes d'exploitation et les matériels de robotique bande. Ils sont capables de gérer des cycles de vie complexes des sauvegardes et offre des solutions qui permettent de copier les bases Oracle via, par exemple, un BEGIN/END Backup et une lecture des fichiers ou via Recovery Manager. Certains media managers offrent d'autres techniques ; par exemple EMC EDM est capable d'utiliser EMC Timefinder et Recovery Manager pour constituer un BCV avant d'envoyer une base de données sur bandes
  
• Enfin d'autres solutions spécialisées visent à simplifier les sauvegardes restauration et offrir certains services à valeur ajoutée. C'est le cas de BMC SQL Backtrack

Les solutions Oracle sont incluses dans le logiciel de base de données. Ces composants ont des capacités la même gamme de possibilités que ces solutions avec :

• Oracle Recovery Manager (RMAN) est la solution qui permet les sauvegardes de la base de données sans BEGIN/END BACKUP. Il permet de copier les fichiers sur disque ou vers un Media Manager et valide les blocs (9i+) pour assurer que les fichiers ne sont pas corrompus. Il simplifie notablement la restauration du fait qu'il catalogue l'ensemble des fichiers disponibles et connaît intimement les bases de données. Il permet des stratégies plus fines que une simple copie : sauvegardes incrémentales, pas de sauvegardes des blocs utilisés ou vides (10.2.0.2+)...
• Oracle Flash Recovery Area est une solution d'automatisation des sauvegardes sur disque qui utilise Recovery Manager.
• Oracle Flashback Database, à la manière des technologies de snapshot, stocke les anciennes versions des blocs modifiés par la base de données et permet de revenir dans le passé de la base de données par application des anciennes versions des blocs. Intégré à la base de données et à RMAN, ces opérations sont effectuées sans point de synchronisation et "BEGIN/END BACKUP" contrairement aux technologies de baies ou du volume manager.
• Oracle Secure Backup est le media manager d'Oracle. Issue du rachat de Reliaty en 2004, il est annoncé pour être disponible en été 2006 et devrait permettre de sauvegarder sur bandes les bases de données mais aussi les logiciels Oracle et les fichiers tiers.
• Oracle Automatic Storage Management (ASM) permet d'assurer que les données sont dupliquées dans plusieurs baies de stockage. Du fait qu'ASM offre un attachement direct de la base de données à des devices, il permet de ne plus dépendre de filesystems, ni de volume manager et optimise ainsi les risques de pannes et les performances.
• Oracle Data Guard est une infrastructure de gestion des bases de données standby (copie de la base de données de production). Basé sur l'envoi des fichiers journaux, Oracle Data Guard permet de minimiser significativement les volumes échangés entre le système de production et le système de secours en synchrone ou asynchrone. En outre, Data Guard ne propage pas les erreurs systèmes comme les corruptions de blocs ou les suppressions de fichiers.
• Enterprise Manager GridControl est l'interface graphique de pilotage, d'administration et de reporting de tous les composants de sécurisation des bases de données.

Cet inventaire n'est pas exhaustif. N'hésitez pas à l'enrichir...

G-Ark!

Mythes et sauvegardes de bases de données

Les technologies de sauvegardes/restauration font parti de ces domaines les plus entourés de mythes et légendes en tout genre. L'importance des investissements des entreprises dans ces domaines et la créativité des équipes marketing des multiples acteurs en est sans doute la cause. La vérité est souvent contextuelle et dépend des stratégies mises en oeuvre que des produits.

La question "Comment sauvegarder une base de données ?" ne vient pas en premier dans la mise en oeuvre d'une stratégie de sauvegarde/restauration. Les premières questions sont "Pourquoi sauvegarder vos bases de données ?" et pour chacune de ces raisons "Quel est l'impact d'une indisponibilité (temporaire ou définitive) des données ?".

Autrement dit, ce qui compte pour choisir une stratégie de sauvegarde/restauration de ce sont, dans l'ordre :

• les causes possibles de pertes de vos données,
• l'impact et la probabilité associés à la perte et/ou à l'indisponibilité des données,
• l'investissement nécessaire pour prévenir l'indisponibilité en regard du risque encouru en cas de perte de toute ou partie des données, même temporaire.
• les objectifs de temps de restauration (RTO : Recovery Time Objectives) et des données que l'on accepte de perdre en cas de restauration(RPO : Recovery Point Objectives)
• les techniques de sécurisation qui faut mettre en oeuvre

Il ne faut pas oublier non plus que la stratégie de sauvegarde/restauration n'est qu'une composante d'une stratégie de sécurisation des environnements. Si possible, ces stratégies doivent être cohérentes : Pourquoi investir pour être capable de restaurer en cas de perte d'une baie en moins de 2 heures s'il faut 3 jours pour disposer d'une baie de secours ? Pourquoi constituer une restauration capable de repartir en quelques minutes si le système d'"alerting" et les équipes d'exploitation ne sont pas capables de prendre des décisions en moins de 4 heures ? Ne faut-il pas dimensionner correctement l'infrastructure pour que l'application soit "utilisable", c'est à dire performante et également prévoir la perte de la machine de base de données, du réseau ou de l'application ?

Enfin, la copie de bases de données pour constituer des environnements de tests, de recettes ou de pré-production influence souvent la stratégie de sauvegarde/restauration choisie. En effet, la solution retenue peut être basée sur les mêmes composants techniques dans la mesure où ces problèmes sont proches, a priori (quoique...).

Les causes possibles de pertes de données :
Voici quelques exemples de causes de pertes de données contre lesquelles il faut se prémunir :

• La perte de tout ou partie des données du fait d'une panne de l'un des SPOF (single point of failure) ou d'une panne double
• La perte d'une partie des données (fichiers ou tablespaces) dûe à une erreur de manipulation ou à un problème des logiciels et matériels (suppression d'un fichier, bug dans un filesystem, volume manager ou d'une baie de stockage)
• La perte d'une partie des données (ensemble de blocs qui sont alors dit "corrumpus") dûe à un problème des logiciels et matériels de l'infrastructure base de données (e.g. bug dans un driver I/O, du système ou d'une instance de la base de données)
• Une erreur humaine ou de l'application qui nécessite de faire revenir votre système ou une partie de votre système à une date précédente dans le temps (PITR : Point In Time Recovery)
• Une perte de la totalité de l'infrastructure du fait d'un désastre (incendie, dégât des eaux, attentats)

Administrateur, effectuez des manipulations en production
Dès la création d'une base de données, il est indispensable de mettre en oeuvre une stratégie de sauvegarde/restauration et à chaque manipulation que vous effectuez sur un environnement de production, il faut se poser les questions suivantes :

• Que peut-il m'arriver de pire et quelles seraient les conséquences si ça arrivait ?
• Qu'est-ce que je suis en mesure de reconstituer ?

Mauvaises idées à propos des sauvegardes/restauration :
Voici quelques idées souvent rencontrées et pour lesquels - réfléchissez-y bien !- il est assez facile de trouver des contre-exemples :

• Les technologies de type "split-mirror" sont les plus rapides pour restaurer des environnements.
• Il faut éviter les impacts des sauvegardes sur les environnements de production.
• Les technologies matérielles n'impactent pas le système de production.
• Les technologies de sauvegardes/restauration ne sont pas capables de monter en charge.
• Les technologies de compression sont le meilleur vecteur pour réduire la taille des sauvegardes

Il en existe beaucoup d'autres... N'hésitez pas à enrichir ces exemples de vos expériences !

G-ArK!