Oracle, comme tout serveur de bases de données, nécessite des fichiers pour stocker ses différents objets (tables, index, vues matérialisées, dictionnaire de données…).
Depuis quelques années Oracle a proposé la possibilité de gérer en automatique les noms des fichier, c’est le principe de Oracle Managed Files (OMF)
Dans le même temps, Oracle proposait son stockage propre, Automated Storage Management, désormais quasiment incontournable pour qui veut un stockage robuste dédié aux bases de données Oracle.
Cet article a pour but de creuser un point particulier d’OMF concernant la création de fichiers de tablespaces dans différents diskgroups ASM et surtout dans un environnement de standby databases.
Standby database en résumé
Une standby database, physique particulièrement, est une base de données qui applique au fur et à mesure de leur arrivée les modifications d’une base de données primaire. Le but de la standby database est la possibilité de reprendre l’exploitation rapidement et de préférence sans perte (base en mode transfert de données synchrone) de données en cas de disparition de la base de données primaire. Dans ce cas, la base de données standby devient la base de données primaire.
Le détail de fonctionnement des standby databases dépassant largement le cadre de cet article, seule est ici abordée l’application de la création de tablespace sur la base de données primaire, entraînant la création du même tablespace sur la standby database, dans le cadre d’OMF.
Base de données Primaire et base de données Standby
Dans une architecture primaire-standby, les deux bases de données ont bien souvent le même nom (SID). Pour des questions de différentiation, il est crucial de définir pour chacune des bases de données un nom unique. La paramètre DB_UNIQUE_NAME pourvoit à cela.
Dans la suite de cet article, les deux bases de données se prénomment respectivement TESTDG_DG01 et TESTDG_DG02. Les deux bases de données ont strictement le même SID, TESTDG, l’une étant la copie stricte de l’autre.
ASM (Automated Storage Management)
ASM permet de créer des diskgroups à partir de volumes physiques qui lui sont présentés.
Les deux bases de données TESTDG_DG01 et TESTDG_DG02 ont été créées en stockage ASM et disposent des diskgroups suivants : +DATA, +DATA2, +FRA
OMF (Oracle Managed Files) et ASM
ASM dispose d’une fonction native appelée « fully qualified ASM file name ». ASM est donc configuré de base avec une fonction OMF.
DB_CREATE_FILE_DEST et OMF
DB_CREATE_FILE_DEST est directement lié à OMF. Il permet de laisser Oracle gérer de bout-en-bout la création des fichier, donnant la possibilité de créer un tablespace de la manière suivante :
create tablespace test01 datafile size 10m;
Toutefois il peut être trop restrictif dans un environnement avec standby databases.
Problème
Lorsque ce paramètre est placé, tous les fichiers se trouvent créés strictement dans le répertoire indiqué. Le pendant de ce comportement en environnement standby database est l’arrivée de l’ensemble des fichiers nouvellement créés strictement dans ce répertoire, même si à la source, base de données primaire, une autre destination a été précisée volontairement :
Par exemple, DB_CREATE_FILE_DEST est placé avec la valeur ‘+DATA’.
Base de données primaire (dans l’alert.log de l’instance) :
create tablespace test03 datafile '+DATA2' size 10m Completed: create tablespace test03 datafile '+DATA2' size 10m
Base de données standby (dans l’alert.log de l’instance) :
Datafile 6 added to flashback set Successfully added datafile 6 to media recovery Datafile #6: '+DATA/testdg_dg02/datafile/test03.271.929435283'
Comme on peut le constater, le fichier arrive malgré tout dans le diskgroup ‘+DATA’
Solution
La solution passe par la mise à blanc du paramètre DB_CREATE_FILE_DEST. Comme dit précédemment, ASM gère intégralement les noms de fichier, et cela que ce paramètre soit ou non placé.
Cette solution oblige toutefois à préciser à chaque fois le nom du diskgroup ASM dans lequel le(s) fichier(s) de tablespace doi(ven)t arriver.
La syntaxe
create tablespace test01 datafile size 10m;
n’est plus possible.
Exemple avec DB_CREATE_FILE_DEST non défini
Base de données primaire (dans l’alert.log de l’instance) :
create tablespace test03 datafile '+DATA2' size 10m Completed: create tablespace test03 datafile '+DATA2' size 10m
Base de données standby (dans l’alert.log de l’instance) :
Datafile 6 added to flashback set Successfully added datafile 6 to media recovery Datafile #6: '+DATA2/testdg_dg02/datafile/test03.271.929435283'
Conclusion
Lorsque vous décidez de stocker votre base de données sur plusieurs diskgroups ASM et que vous êtes en environnement avec standby database, il ne faut pas définir le paramètre DB_CREATE_FILE_DEST.
Il est par contre nécessaire pour toute création de tablespace ou ajout de datafile (tempfile) de préciser le diskgroup d’arrivée.
ASM fera dans tous les cas le travail de nommage correct des fichiers tant dans la base de données primaire que dans la base de données secondaire.