Optimisation de l'exécution du DDL pour test

Bonjour,

Dans le cadre de déroulement de tests unitaires et d'intégration d'une application java, chaque test détruit et recrée l'ensemble des objets base de données nécessaires à son fonctionnement (environ 300 objets) afin d'avoir un environnement reproductible et que le déroulement des tests ne soit pas pollué par des résidus. L'opération de destruction/recréation prend entre 3 et 4 secondes sous Oracle (contre environ 2s sur SQL Server et postgreSQL et moins de 100ms sous H2 in memory). Le nombre de tests commençant à être élevé (plus de 12000), le temps de mise en place du contexte de test devient problématique (presque une journée complète pour faire tourner tous les tests sur oracle)!
Je suis donc à la recherche d'idées pour optimiser ce processus de réinitialisation d'un ensemble d'objets (niveau schema ou tablespace, ça me va aussi). Compte tenu du contexte de test, la sureté des données de la base ne m'importe guère (les fichiers de la bases sont déjà sur un ramdisk, niveau unrecoverable, il n'y a pas pire). Les solutions ne doivent cependant pas influer sur la représentativité des tests.
Ce que j'ai déjà essayé :
* Flashback de la base
* restauration du tablespace contenant les tables
Ces solutions apportent un gain peu significatif (quand il existe seulement, tout dépend de ce que font les tests). Elles présentent en plus l’inconvénient d'introduire du code spécifique à Oracle pour la mise en place du contexte de test (alors que les drop et create ont l'avantage d'être générés dynamiquement de manière générique par l'application pour tous les SGBD cibles)

Merci pour votre attention et vos suggestion

Bonjour,
Pas de solution magique à ça: Oracle n'est pas optimisé pour faire du DDL.
Le plus rapide serait le restore le la base. A partir du backup fait sur ramdisk aussi:
1. lorsque c'est créé une première fois, backup à froid.
2. ensuite restore à froid (quand même un peu long car il y a redémarrage de l'instance + copie des fichiers)

On parle bien de backup/restore physique (avec RMAN par exemple). Pas d'export/import qui lui recrée les objets comme le DDL.

Cordialement,
Franck.

Merci pour ta réponse.
Effectivement, c'est une solution que j'ai envisagé, mais comme tu l'as préssenti, l'arrêt/redémarrage de l'instance compromet largement le gain espéré. Impossible de faire tenir cette opération dans les 4s. actuellement nécessaires.

Avez-vous essayé le transportable tablespace ?
http://asktom.oracle.com/pls/asktom/...86700346199297

Mais ça reste du spécifique oracle...

Oui, c'est à cela que je faisais allusion avec le point

Citation:

---

* restauration du tablespace contenant les tables

---

Le résultat n'est pas vraiment concluant.
Merci en tout cas pour le lien que je n'avais pas encore trouvé et qui décrit un problème tout à fait similaire au mien (mise à part qu'il cherche un optimisation sur 30min contre 4s. pour moi, ce qui me laisse nettement moins de marge). Je n'avais pas du tout envisagé la solution Workspace Manager évoquée. Je vais regarder si il y a des éléments intéressants de ce coté là.

Au fait, je suppose que les tests unitaires ne couvrent pas plusieurs transactions. Pas moyen de juste faire un rollback au lieu du commit ? Sinon, il y a peut-être un moyen de créer toutes les tables en Global Temporary Table.
Avec ça les 4 secondes paraissent possible. Et lancer les tests en parallèle aussi.

Merci pour vos réponses.
Malheureusement, certains tests font intervenir plusieurs transactions voire sessions (ça n'a plus rien d'unitaire, mais c'est comme ça, et il faut bien tester les cas de concurrence également), le simple rollback n'est donc pas possible. La solution table temporaire souffre des mêmes soucis et construit une base pas nécessairement aussi représentative de la base réelle.
La solution adoptée a été finalement d'isoler les tables fixe de l'application, de se contenter de les vider et de recréer leur contenu initial. Cela a permis de diviser le temps d'execution par 6 sous oracle.

Code:

---

et il faut bien tester les cas de concurrence également

---

:ccool: ces cas de tests sont souvent oubliés !
Pour vider les tables le plus rapide devrait être truncate ... reuse storage.