J’ai décidé de raconter mes expériences pour illustrer le fait que préparer et s’entraîner est le meilleur moyen de réussir une opération quand il s’agit d’intervenir sur Oracle. Ce qui suit et, les moins nombreux possibles, posts qui suivront sur ce thème, raconteront ces histoires où , j’aurais mieux fait de ne pas me lever ou, au moins, laisser quelqu’un d’autres faire le travail. Je ne suis donc pas très fier de ce qui suit mais, au moins, je ne ferai plus jamais ça !

27 heures debout…

Je suppose que le titre explique tout et pourtant, ce n’est pas la cause mais plutôt la conséquence de mes problèmes. La vrai cause serait plutôt de réaliser un job qu’un autre avait préparé et que j’étais loin de maitriser. Enfin, ça commençait par une intervention à 3h15 du matin (la base est dans un autre fuseau horaire) et je suis debout depuis 20h15 environ : export d’une base et import sur une autre machine (facile ? 3 heures maximum ?) . Je ne vous raconte pas ce qui tourne autour de la base et auquel je ne comprends rien… J’aurais du me méfier

• Erreur #1, ils modifient la base d’origine avant l’export

Pourquoi, j’en sais toujours rien mais il faut supprimer une file d’attente AQ avant d’exporter les données. La conséquence je la paierai plus tard quand je cherche les droits positionnés sur la nouvelle base

• Erreur #2, ne pas vérifier que les utilisateurs et rôles sont crées dans la base avant de lancer l’import

La base, les utilisateurs et rôles étaient créés pourquoi j’aurais du vérifier ? 4h18 du mat… L’import part en vrille…

• Erreur #3, mes sessions ssh sur la base d’import et l’import ne veut pas s’arrêter au crtl-C

Je me dépêche de rediriger mes sessions de la base d’import sur la cible et kill -9 de gunzip qui alimente le pipe ! terminer. Je relance ! et pourtant j’utilise toujours nohup d’habitude :

mknod imp_pipe p
nohup gunzip < exp.dmp.gz > imp_pipe &

• Erreur #4, ne pas faire une copie des privilèges.

C’est le même problème que pour l’erreur 2 sauf que, en plus, les privilèges associées aux objets supprimés ont disparu. Merci d’avoir les procédures invalides pour m’aider.

• Erreur #5, la pire ! 7H30, j’ai supposé…

Comme prévu dans la checklist, je demande à ce qu’on change le réseau. C’est le milieu de la nuit chez eux ! Quelqu’un me contacte :

lui : "Qu'est ce que je dois faire ?"
moi : "La base X est migrée, change le réseau !"
lui : "Qu'est ce que je dois changer ?"
moi : "(blanc) !" 

On m’a dit de changer, on m’a jamais dit quoi et j’ai supposé que le types gens du réseau savaient ! J’aurais dû savoir !

• Erreur #6, je n’ai pas le mot de passe

Avant de redémarrer l’application, j’informe mon interlocuteur que j’ai du recréer un utilisateur et que je n’ai pas le mot de passe, l’application n’arrivera pas à se connecter… Lui non plus ! Merci le mecanisme de HASH des mots de passe d’Oracle 10g (Ca risque d’etre différent en 11g, quoique j’en sais rien)

sur la base d'export :
select username, password
   from dba_users
  where username='&username';

sur la base d'import :
alter user &username
  identified by values '&passwd_hash';

• Erreur #7, 11H… tout à l’air bien; les clients sont connectés depuis un moment !

Quelqu'un : la base est en noarchivelog
moi : ...

C’est la que j’ai appris que « to bounce », signifie aussi arrêter et redémarrer une base de données. et que ca pouvait prendre de très longues secondes de faire un « shutdown immediate » même après un « startup exclusive open force ». Là, j’avoue, ça a été ma pire journée depuis longtemps et le pire c’est que c’est de ma faute. Et c’est pas fini…

Oracle 10g sur Windows…

J’installe Oracle (10g) sous Windows dans un nouvel Oracle Home sur un serveur qui sert aussi de serveur web (IIS) et bien croyez-le ou non, ça flingue les connexions d’IIS à sa base de données Oracle. Et pas à cause de la registry non ! À cause de la variable d’environnement PATH qui est change par l’installer de la 10g

Finalement, ça c’est bien terminé… Je suis allé me coucher !

-GarK!