Probablement que la manière la plus sure de semer le désordre dans vos bases de données Oracle est d’utiliser des conventions de nommage de vos fichiers les plus exotiques possibles. Parmi ces « bonnes » pratiques, vous ne voudrez pas utiliser :

• Nommer les fichiers de redo logs avec une extension .log de sorte que les Administrateurs Systèmes puissent les supprimer à la première occasion.
• Cacher les fichiers en les préfixant par un point sur Unix ou en utilisant la commande « attrib -h » sous Windows
• Utiliser des extensions de fichiers pour ajouter à la confusion (.tmp, .trc, .exe, .zip, .tar.gz, .bz2, .cpio, .com, .bat, .virus, .quarantine, .bak, .2bdeleted, .20081010, .doc, …)
• Utiliser des noms de fichiers et de répertoires les moins explicites possible. A ce propos faire croire que le fichier est une erreur de manipulation d’un shell script est généralement assez efficace : Nommer vos fichiers core, -help, kill, -9, -x, oracle@node1, root@localhost. Mettre les fichiers dans /temp ou /etc est aussi une bonne trouvaille ! Utilisez des noms évocateurs comme readme.1st ou delete.after.april.txt !
• Utiliser des caractères compliqués : remplacer les O par des 0, les l par des 1 ! Utilisez des espaces, des , des ‘ et des « .
• Utiliser des raw devices et des liens. S’assurer que les liens se terminent par .dbf et que vos raw devices aient une taille telle que le prochain DBA pensera que étendre la taille du fichier .dbf sera la meilleure façon de régler le problème.

Vous trouverez peut-être que ce genre de pratiques est sadique ? Le problème, c’est juste que ça existe pour de vrai ; je les ai tous vu. Si ce post peut simplement vous aider à réfléchir 2 fois avant que vous utilisiez « rm » ou « alter database datafile », alors ça sera peut-être une petite victoire pour vous 😉