Un portefeuille pour la base de données

Afin de permettre à la base de données d’accéder au contenu d’un site sécurisé par le protocole SSL, celui-ci doit avoir un portefeuille (wallet) dans lequel on retrouve les certificats.

1. Obtention des certificats

Cette section décrit comment procéder à l’exportation des certificats associés au domaine (site) dont nous voulons que la base de données puisse accéder.

Note : Les étapes de cette section dépendent du fureteur utilisé. Dans le cas actuel, le fureteur Firefox de Mozilla est utilisé.

• Accéder au site via son adresse sécurisée à l’aide d’un fureteur Internet
• Accéder au détail du certificat du site en cliquant à la gauche de l’adresse URL puis, sur le bouton « More Information… »
• Cliquez sur le bouton « View Certificate » pour faire afficher la fenêtre des propriétés
• Ensuite, déplacez-vous vers l’onglet « Details ». À ce moment, il est important de remarquer dans la partie du haut que la hiérarchie est constituée de plusieurs niveaux. Cela indique que vous devez exporter plusieurs certificats (1 par niveau).
• Pour débuter, sélectionnez le premier niveau puis appuyez sur le bouton « Export » au bas de la fenêtre
• Choisissez le format « X.509 Certificate (PEM) » puis enregistrez le certificat sous un emplacement de votre choix.
• Répéter les deux étapes précédentes pour chacun des niveaux

2. Création du portefeuille

• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaire (ex. oracle)
• Créer une nouvelle entrée dans le portefeuille

Note : Veuillez spécifier un emplacement et un mot de passe pour le protéger.

(oracle) $ orapki wallet create –wallet [répertoire/du/wallet] -pwd [mot_de_passe] -auto_login

3. Importer les certificats dans le portefeuille

• Transférer les certificats précédemment exportés sur le serveur de base de données
• Accéder au serveur de base de données via un outil tel que « Putty »
• Établir une connexion avec le compte propriétaite (ex. oracle)
• Importer tous les trois certificats en exécutant cette commande pour chacun  :

Note : Assurez-vous de préciser le nom exact du fichier correspondant au certificat.

(oracle) $ orapki wallet add -wallet  [répertoire/du/wallet]  -trusted_cert -cert [Nom_fichier_crt] -pwd [mot_de_passe]

4. Afficher le contenu du portefeuille

Vous pouvez exécuter la commande suivant pour vérifier le contenu du portefeuille. La commande affiche les certificats qu’il contient.

(oracle) $ orapki wallet display -wallet [répertoire/du/wallet]

5. Vérifier le fonctionnement

• Démarrer l’outil SQL*Plus
• Établir une connexion à la base de données avec un compte administrateur (DBA)
• Exécuter la requête SQL suivante :

Note : avant d’exécuter la requête, veuillez spécifier l’emplacement (répertoire) où se trouve le fichier (portefeuille) ainsi que le mot de passe de ce dernier

SELECT utl_http.request('https://[Adresse_URL]','',
       'file:[Nom_fichier_Wallet_incluant_Repertoire]', '[Mot de passe]')
  FROM dual;

Si la requête retourne une série de balise « HTML », cela confirme que c’est fonctionnel.

Et pour terminer, n'oubliez pas de jeter un oeil à la liste de contrôle ACL pour que votre schéma (utilisateur) soit autorisé à accéder au site web.

Quels sont les correctifs (patches) installés sur la base de données ?

Si vous désirez connaître les correctifs (patches) d'Oracle qui ont été installés/appliqués sur la base de données, vous pouvez exécuter la commande suivante :

opatch lsinventory

et consulter le contenu des objets ci-dessous du dictionnaire :

select * from DBA_REGISTRY_HISTORY
select * from registry$history;
select * from dba_registry;

Incapable d'émettre un droit malgré la clause "With Grant Option"

Après avoir octroyer le droit d'exécution sur le package UTL_HTTP à un schéma particulier avec la clause "With Grant Option", ce dernier n'a pas été en mesure d'émettre à son tour, ce même droit à un autre schéma malgré la présence de la clause. Lors de l'émission du privilège, l'erreur "ORA-01031 INSUFFICIENT PRIVILEGES" est soulevé. Ce qui ne fait aucun sens.

Après quelques recherches, j'ai alors remarqué que ce comportement est un bug répertorié chez Oracle et il a été observé sur la version 11.2.0.3 de la base de données. (Bug 13036331 : ORA-01031 INSUFFICIENT PRIVILEGES WHEN GRANTING EXECUTE ON DBMS PACKAGES)

Étrangement, mais heureusement, il y a une solution de contournement. Dans mon cas, il a suffit d'effectuer un "Alter system flush shared_pool;" puis d'émettre à nouveau le privilège initial qui comportait la clause "With Grant Option" et ensuite, d'octroyer de nouveau le privilège à l'autre schéma dont il était impossible de faire. Cette fois-ci, ça l'a réussi.

Erreur de connexion à la base de données sous Microsoft Windows

La majeure partie du temps, je travaille sur les plate-formes Unix et Linux et, dernièrement, j'ai eu à installer et configurer une nouvelle base de données sous Oracle Fail Safe sous Microsoft Windows.

L'installation s'est très bien déroulé. Lorsque rendu à l'étape d'ajouter la base de données au groupe de ressources du cluster, nous avions rencontré des erreurs qui mentionnaient qu'il était incapable de se connecter à la base de données. Afin de diagnostiquer le problème, j'ai alors démarré un invite de commandes puis démarré SQL*Plus. J'étais aucunement capable de me connecter à celle-ci, que se soit avec "/ as sysdba" ou avec une chaîne de connexion.

Avec "/ as sysdba", j'obtenais l'erreur "ORA-12560:TNS:protocol adapter error" tandis que lorsque je mentionnais une chaîne de connexion définie dans le "tnsnames.ora", je recevais l'erreur "ORA-12518 Tns: Listener could not hand off client connection".

Après avoir vérifié le statut du "listener", la configuration dans les fichiers listener.ora, tnsnames.ora, sqlnet.ora, etc.. j'ai alors pensé que, dans le merveilleux monde de Windows, il y a des services pour la base de données Oracle... En ouvrant le gestionnaire de services, j'ai remarqué aussitôt que le service "OracleInstanceORCL" n'était pas démarré. Je l'ai tout simplement démarré puis j'ai été en mesure de me connecter avec SQL*Plus des deux façons mentionnées précédemment.

L'envergure du problème n'est pas toujours proportionnel aux efforts déployés à le résoudre.

De grands changements à l'architecture d'Oracle Database

Oracle a annoncé au cours de l'événement Oracle Open World 2012 qu’il se lançait plus que jamais vers le « cloud computing » et, que la prochaine version de la base de données, en l’occurrence 12c sera « multi-tenant ». 

Pour bien comprendre la signification de « multi-tenant », il faut savoir que le mot anglais « tenant » signifie « locataire » en français et que « tenancy » signifie « location ». Dans le monde des technologies de l’information, le «  Multitenancy »  est un principe architectural où une seule instance du logiciel est utilisée pour exécuter un service pour plusieurs clients. Vous ne serez pas surpris de savoir que le principe « Multitenancy » est considéré comme l'un des attributs essentiels de l'informatique en nuage (cloud computing).

Lors des quatre dernières années, Oracle a révisé l’architecture logicielle pour permettre la gestion d’une multitude de bases de données (plusieurs locataires) à partir d’une seule installation tout en contrôlant de façon distincte les ressources matérielles telle que la mémoire, les processus, la sécurité,  et bien d’autres aspects forts utiles dans un environnement partagé de type « cloud ». Ce n’est pas par hasard que la future version portera dorénavant un « c » pour « cloud » au lieu d’un « g ».

Sachez que ce principe n'est pas universellement accepté et soutenue dans l'industrie du logiciel, ce qui peut être une source de différenciation parmi les diverses solutions offertes. Il faut s’attendre que chacun des fournisseurs tireront sur leur bout de couverture pour s’approprier les mérites de ce principe et se vanteront que leur solution est la meilleure.

Il a aussi été mentionné qu’une nouvelle fonctionnalité permettra à la base de données Oracle 12c de surveiller à quelle fréquence les données sont accédées et par quelles types d’opérations (SELECT / INSERT / UPDATE / DELETE). En obtenant ces informations, on peut facilement imaginer qu’elles permettront d’identifier les données qui sont rarement consultées et qu’elles pourraient être archivées. 

APEX 4.1 - ORA-20987 lors d'une instruction en tant qu'administrateur

Nous avons rencontré un problème lors de l'appel du package d'Oracle Application Express (APEX) qui s'appelle : "APEX_INSTANCE_ADMIN". L'erreur est la suivante :

ORA-20987: APEX - User  requires ADMIN privilege to perform this operation. - Contact your application administrator.

Cette erreur survient même si le schéma Oracle utilisé à le rôle d'administration d'APEX. 

Ce problème est connu chez Oracle et la version 4.1.1 d'APEX règle cette erreur :

Bug 13553903 : CANNOT USE APEX_INSTANCE_ADMIN WITH USER GRANTED APEX_ADMINISTRATION_ROLE

Voting Disk corrompu et... aucune sauvegarde!

Suite à un "downgrade" du clusterware 11gR2 à la version 10gR2 (10.2.0.4), nous n'avons pas réussi à redémarrer le CRS correctement. Après quelques investigations dans les différents fichiers de trace (.log), j'ai alors remarqué le message suivant dans le fichier "cssd.log"

ERROR:   clssnmvReadFatal: voting device corrupt (0x00000000/0x00000000/0//dev/vd1_sys_1g)

Pour remédier à ce problème, nous avons du recréer le "voting disk" car nous n'avions aucune sauvegarde à notre disposition ni de mirroring... chose à ne pas faire.

Voici les étapes effectuées. Ceci a été effectué sur une plate-forme AIX dont les produits Oracle étaient de la version 10gR2 (10.2.0.4)

• Arrêt complet du clusterware

Dans notre cas, la commande "crsctl stop crs" ne fonctionnait pas alors nous avons désactivé le démarrage automatique (init.crs disable) puis redémarrer chacun des noeuds.

• Ajout d'un nouveau raw device

L'administrateur de système nous a alloué un nouveau disque d'une capacité d'un gigaoctet.

• Afficher le voting disk actuel

#crsctl query css votedisk

Cette commande nous a retourné le nom complet du voting disk (ex. /dev/vd1_sys_1g)

• Ajouter un voting disk en précisant l'emplacement exact

# crsctl add css votedisk [/chemin/nom] -force

Ex. # crsctl add css votedisk /dev/vd1_sys_2g -force

• Détruire le voting disk corrompu en spécifiant le chemin complet

# crsctl delete css votedisk [/chemin/nom] -force

Ex. # crsctl delete css votedisk /dev/vd1_sys_1g -force

• Redémarrer le cluster

# crsctl start crs

• Vérifier le nouveau voting disk

# crsctl query css votedisk

Suite à toutes ces étapes, nous nous sommes empressé de recommander la mise en place d'une sauvegarde du voting disk dans la procédure de sauvegarde existante et, de créer au minimum un second voting disk.

Quels sont les variables d'environnement du processus en cours d'exécution

Lors de la migration d'un cluster Oracle 10gR2, nous avons rencontré un problème avec l'assistant de configuration ASMCA lors de l'étape de migration d'ASM. Après avoir fouillé Internet, certains messages de forum et de blogs nous ont mis sur une possible cause : Des variables d'environnement n'auraient pas été réinitialisées (UNSET) avant l'exécution du programme d'installation.

Pour vérifier si cela était notre cause, nous devions obtenir l'identifiant du processus correspondant au programme d'installation d'Oracle (OUI) qui est démarré lors de l'exécution de "runInstaller" :

ps -elf | grep OraInstall

Ensuite, pour obtenir les variables d'environnement en force lors de son exécution, on doit exécuter l'une de ces commandes dépendamment de la plateforme utilisée en précisant l'identifiant du processus obtenu précédemment :

SOLARIS

pargs -e | grep ORACLE

LINUX
cat /proc//environ

AIX
ps eauwww

Si le résultat de la commande est quelque peu exhaustif, je vous recommande de rediriger le résultat de la commande vers un fichier (ex.: ps eauwww > result.log) puis de l'ouvrir avec un éditeur de texte pour vérifier la présence des variables d'environnement.

Statut inconnu (UNKNOWN) de l'instance ASM sous RAC

Voici une situation vécue avec une instance ASM 10g (10.2.0.4) dans un environnement Oracle Real Application Cluster (RAC) 10gR2 sur la plateforme IBM AIX 64 bits.

Le statut de l'instance ASM est devenu "UNKNOWN" et celles des bases de données hébergées sur le même noeud sont OFFLINE. Que se passe-t-il ?

Afin de comprendre, je me suis dirigé vers les fichiers de trace sous l'ORACLE_HOME d'Oracle ASM situé à l'emplacement suivant puis vérifier le contenu du fichier "ora.noeud01.ASM1.asm.log" :

$ cd /opt/oracle/product/asm10g/log/noeud01/racg
$ vi ora.noeud01.ASM1.asm.log (writing error)

Le fichier de trace contenait l'erreur suivante :

RACG][1] [905406][1][ora.noeud01.ASM1.asm]: CLSR-0006: Error encountered when writing file /opt/oracle/product/crs10g/racg/tmp/ora.noeud01.ASM1.asm.ora

Je me suis alors déplacé vers le répertoire "/opt/oracle/product/crs10g/racg/tmp" pour vérifier les fichiers présents et leurs permissions.

$ cd /opt/oracle/product/crs10g/racg/tmp
$ ls -al

Voyant que tout semblait correct et que rien n'attirait mon attention, j'ai prit la décision de déplacer tous les fichiers de ce répertoire vers un autre répertoire dans le but de laisser Oracle les recréer au besoin :

# mkdir -p /tmp/backup
# mv * /tmp/backup

Suite au déplacement, j'ai redémarré le CRS puis revérifier graduellement le statut de chacune des composantes :

# crsctl stop crs
# crsctl start crs
# crsctl check crs
# crs_stat.sh

Toutes les composantes ont redémarrées correctement. Maintenant, je dois investiguer pour comprendre ce qu'il s'est réellement passé.

Appel de fonction PL/SQL dans un énoncé SQL

J’ai remarqué que plusieurs cas de lenteur ont été soulevés par le fait que des fonctions PL/SQL sont utilisées dans les clauses WHERE des énoncés SQL d'une vue utilisée par une application développé sous Oracle Application Express (APEX).

Par exemple, lorsque la fonction est appelée de cette façon, l’optimiseur d’Oracle l’exécute à toutes les rangées même si les valeurs passées sont toujours les mêmes :

SELECT empl.nom_empl, empl.prn_empl, clien.ide_clien, mand.num_contt
  FROM gma_mand mand, gcl_clien clien, gem_empl empl
 WHERE mand.num_empl_gestn = empl.num_empl
   AND mand.ide_clien      = clien.ide_clien
   AND pkg_securite.verfc_acces (v('USER')) = 1;

Alors, il est recommandé de l’encapsuler dans une requête SQL (scalar subquery) car cette requête sera exécutée qu’une seul fois et ce, peu importe le nombre de rangées retournées :

SELECT empl.nom_empl, empl.prn_empl, clien.ide_clien, mand.num_contt
  FROM gma_mand mand, gcl_clien clien, gem_empl empl
 WHERE mand.num_empl_gestn = empl.num_empl
   AND mand.ide_clien      = clien.ide_clien
   AND (SELECT pkg_securite.verfc_acces (v('USER')) FROM DUAL) = 1;

L’appel à des stored procedure dans des énoncés SQL peut être très couteux en ressource. Dans le cas rencontré avec la vue, l’exécution de la stored procedure était effectuée pour chaque enregistrement retourné. En l’englobant dans un énoncé SQL (select … from dual), Oracle ne l’exécute qu’une seule fois. Un important gain en performance a été constaté dès que le changement a été mis en place.

Modifier l'information réseau contenu dans l'OCR

Si vous obtenez les messages :

PRVG-1513 : Failed to retrieve current selection of public and private network classifications for node
PRVG-11050 : No matching interfaces "" for subnet "" on nodes "racnode1"

Il est fort possible que l'information contenu dans l'OCR ne soit pas correcte. Pour remédier à cela, vous devrez procéder comme suit pour vérifier les interfaces définis dans l'OCR puis de la redéfinir selon votre cas.

voici un exemple :

• Afficher les interfaces présents sur le noeud

$ oifcfg iflist -p -n
en3  10.2.2.0  UNKNOWN  255.255.255.0
en0  10.25.9.0  PRIVATE  255.255.255.0

• Afficher les interfaces définis par la commande "setif"

$ oifcfg getif
en0  10.25.9.0  global  public
en3  10.2.1.0  global  cluster_interconnect

En comparant les adresses IP des interfaces, on remarque qu'un d'elle est incorrecte (10.2.1.0). On doit supprimé cette entrée pour la réinsérer avec la bonne adresse IP (10.2.2.0) :

$ oifcfg delif -global en3

$ oifcfg setif -global en3/10.2.2.0:cluster_interconnect

L'interface de configuration "OIFCFG" permet de définir et de gérer les interfaces réseau. Il permet d'allouer et libérer les interfaces réseaux,d'utiliser des interfaces réseau spécifiques et obtenir des informations de configuration des composant.De plus, vous pouvez utiliser "OIFCFG" sur une instance unique et des environnements impliquant Oracle Clusterware.

Configuration des interfaces de l'interconnect

Lors de la vérification de la configuration d'un cluster existant de la version 10gR2 (runcluvfy.sh) en prévision de le mettre à niveau à la version 11gR2 (11.2.0.3), nous avions reçu le message suivant :

WARNING:
Could not find a suitable set of interfaces for the private interconnect
Checking subnet mask consistency...
Subnet mask consistency check passed for subnet "10.2.190.0".
PRVG-11055 : Interfaces configured with subnet number "192.168.2.0" have multiple subnets masks
PRVG-11056 : subnet masks "255.255.255.0" are configured with subnet number "192.168.2.0" on nodes "qaora05t"
PRVG-11056 : subnet masks "255.255.255.224" are configured with subnet number "192.168.2.0" on nodes "qaora06t"
Subnet mask consistency check failed.

Result: Node connectivity check failed

Nous avons dû modifier le "netmask" au niveau du serveur "srvbd02" pour qu'il soit identique sur les 2  noeuds (serveurs) du cluster, voici les étapes réalisées :

$oifcfg iflist -p -n
en2  10.2.190.0  PRIVATE  255.255.255.0
en4  192.168.2.0  PRIVATE  255.255.255.0

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xfffffe00 broadcast 192.168.2.31
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Le "netmask" qui est égale à "0xffffffe0" doit être modifié pour être "0xffffff00" :

#chdev -l en4 -a netaddr=192.168.2.14 -a netmask=0xffffff00

#ifconfig en4
en4: flags=1e080863,c0
        inet 192.168.2.14 netmask 0xffffff00 broadcast 192.168.2.255
         tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0

Suite à ce changement, le « cluster verify » à passer sans erreur.


Ce cluster était sur une plateforme IBM AIX 5.3 64bits.

Un merci tout spécial à mon collègue Nabil Ben Tekaya. Grâce à ses yeux de lynx, il a remarqué la différence au niveau des masques réseau.

INS-40406 avec Oracle Universal Installer

Lors d'une tentative de migration d'Oracle Clusterware de 10g à la version 11gR2, nous avons rencontré l'erreur INS-40406. Le programme d'installation ne voyait pas la présence d'un cluster.

Suite à plusieurs recherches, nous avons remarqué qu'il manquait le paramètre : CRS="true" dans le fichier "inventory.xml" vis-à-vis la balise correspondant à l'ORACLE_HOME du cluster.

Après avoir ajouter le paramètre, le programme d'installation a reconnu le cluster.

Exemple : CRS="true"

Contrôle de la compatibilité des fichiers d'export

Au moment de faire un import avec l'utilitaire Oracle Datapump, si vous rencontrez les erreurs suivantes :

    ORA-39001: invalid argument value
    ORA-39000: bad dump file specification
    ORA-39142: incompatible version number 3.1 in dump file "/u01/app/oracle/admin/ORCL/dpdump/FICHIER.DMP"

Cela signifie que vous tentez d'importer un fichier d'export dont la version de la base de données d'où a été exécuté l'export ne corresond à celle de destination.

Pour contourner ceci, vous pouvez utiliser le paramètre "VERSION" au moment de l'export pour indiquer que la structure du fichier d'export doit être compatible avec la version mentionnée. Voici un exemple :

    expdp dumpfile=fichier.dmp logfile=fichier.log content=all schemas=test version=10.2

Amélioration de la sécurité sous Oracle 11g

La version 11g de la base de données apporte un lot d’amélioration touchant la sécurité. Entre autre, le profil d’utilisateur par défaut est créé avec une politique d’expiration du mot de passe. Ce comportement peut être changé cependant il est recommandé de conserver cette politique pour le profil par défaut. Au besoin, mieux vaut créer de nouveaux profils avec les politiques désirées et les associer aux utilisateurs concernés.

La modification du profil s’effectue de la façon suivante pour que le mot de passe n’expire jamais :

SQL> alter profile [Nom_Profil] limit password_life_time unlimited;

Autre point à considérer avec la version 11g, le mot de passe est dorénavant sensible à la casse.

Accès controlés aux services réseaux (ACL)

Dorénavant, toutes les fonctionnalités de base de données exigeant une interaction avec les services réseaux sont maintenant contrôlées par une liste d’accès. Cette liste est appelée « Access Control List (ACL) ». Oracle a mis en place un contrôle d’accès granulaire aux services externes.

Ce mécanisme permet de contrôler les accès aux fonctionnalités « UTL_TCP », « UTL_SMTP », « UTL_MAIL », « UTL_HTTP », et « UTL_INADDR ». Si le schéma Oracle exécutant ces fonctionnalités ne possède pas les droits nécessaires, une erreur sera soulevée. Pour octroyer des privilèges, vous pouvez utiliser le package d’Oracle « DBMS_NETWORK_ACL_ADMIN ».

Oracle Fail.... Quoi ?

Connaissez-vous Oracle Fail Safe ? C’est un logiciel inclus avec une licence de base de données Oracle sous le système d’exploitation Microsoft Windows Server. C'est un logiciel de haute disponibilité qui s’intègre à Microsoft Cluster Server et qui procure une solution rapide et efficace pour configurer, vérifier et basculer les bases de données Oracle ainsi que les applications sur une plateforme Windows. Par exemple, dans le cas d'une défaillance du système, Oracle Fail Safe fonctionne avec Microsoft Cluster Server pour redémarrer la base de données Oracle et les applications sur un nœud (serveur) de cluster.

Oracle Fail Safe est optimisé pour un environnement cluster de Microsoft et il comprend deux principales composantes, un serveur et un gestionnaire :

• Le composant serveur « Oracle Services pour MSCS » fonctionne avec le logiciel de gestion du cluster de Microsoft  et contient un ensemble de bibliothèques de ressources pour assurer le basculement automatique lors d’une interruption planifiée ou non.
• La composante de gestion « Oracle Fail Safe Manager » fournit un outil convivial qui fonctionne avec le logiciel serveur d’Oracle Fail Safe sur un ou plusieurs clusters pour effectuer la configuration, la gestion et la surveillance.

Flash OU Fast ?

Est-ce qu’on dit « flashback recovery area » ou « fast recovery area » ? Et bien les deux sont utilisés cependant, depuis la version 11g Release 2 de la base de données, le mot « flash » a laissé sa place pour « fast ». Disons que le mot « fast » s’apprête mieux à  cette zone réservée pour le recouvrement rapide.

Statistiques non collectées automatiquement

Les statistiques sur les « fixed object » doivent être collectées manuellement. Elles ne sont pas collectées automatiquement par la tâche automatisée qu’Oracle créé pour la collecte de statistiques. La collecte s’effectue en exécutant la commande « DBMS_STATS.GATHER_FIXED_OBJECTS_STATS ».

Ces objets contiennent des informations concernant l’activité de la base de données et elles sont accédées fréquemment donc il  y a un impact direct sur le temps réponse si les statistiques sont désuètes.

Il  est recommandé de réaliser la collecte lorsqu’il y a une activité (charge) représentative sur la base de données.  D’autant plus, suite à l’exécution du script « catupgrd.sql », il est conseillé d’effectuer la collecte de statistiques sur ces objets pour optimiser le temps de traitement de la recompilation via le script « utlrp.sql ».

En ce qui concerne la fréquence de collecte, veuillez actualiser les statistiques lorsque si une mise à jour majeure est effectuée sur la base de données ou sur une application, aussi lorsque vous apportez des changements importants à la configuration de la base de données.