Test d'une requête SQL sur Oracle qui inclut une base de données distante

Question

Nos bases de données de développement (Oracle 9i) utilisent une liaison de base de données distante vers une base de données partagée distante.

Cette décision a été prise il y a des années lorsqu'il n'était pas pratique de mettre certains des schémas de base de données sur une machine de développement - ils étaient trop gros.

Nous avons certains schémas sur les machines de développement et nous donnons l'apparence locale aux schémas distants en utilisant les liens de base de données d'Oracle, ainsi que quelques synonymes sur les machines de développement. Le problème que j'ai est que je voudrais tester un morceau de SQL qui joint des tables dans les schémas de chaque côté du lien de base de données.

par exemple. (Un cas simplifié):

select a.col, b.col 
    from a, b 
    where a.b_id = b.id 

• un est sur la base de données locale
• b est sur la base de données de suppression
• J'ai un synonymn sur les paramètres régionaux DB afin que « b » indique effectivement à b @remotedb.

L'exécution de la requête prend des âges dans l'environnement de développement en raison du lien. Les requêtes fonctionnent bien en production (je ne pense pas que l'optimiseur Oracle basé sur les coûts puisse très bien gérer les liens de base de données).

Nous n'avons pas très bien réussi à écrire des tests unitaires pour ces types de requêtes dans le passé - probablement en raison des mauvaises performances - alors j'aimerais commencer à créer des tests pour ces types de requêtes.

Est-ce que quelqu'un a des stratégies pour écrire un test unitaire pour une telle requête, afin d'éviter les problèmes de performance liés à l'utilisation du lien de base de données? Normalement, je chercherais des moyens d'essayer de simuler le service distant, mais comme tout cela se trouve dans une requête SQL, je ne vois pas comment on peut facilement se moquer de la base de données supprimée.

Answer 1

Vous devez créer des copies exactes de tout le schéma dont vous avez besoin de la production en développement mais sans toutes les données. Vous devez remplir le schéma avec suffisamment de données pour pouvoir effectuer un test approprié. Vous pouvez également manipuler l'optimiseur pour qu'il se comporte sur le système de test comme une production en exportant les statistiques du serveur de production et en les important dans la base de développement pour les schémas que vous dupliquez. Ainsi, la requête s'exécutera avec l'ensemble de données que vous avez créé, mais la requête sera optimisée avec des plans similaires à ceux de la production. Ensuite, vous pouvez estimer théoriquement comment cela va évoluer sur la production.

Answer 2

Copiez les données pertinentes dans votre base de données de développement et créez les tables localement.

Idéalement, juste construire un test qui vous dit:

1. Le SQL est correct (il parse)
2. Il fonctionne correctement avec quelques lignes de données de test

Don » t tomber pour le "copions tout" parce que cela signifie que vous n'aurez plus aucune idée de ce que vous testez (et de ce qui vous manque).

En cas de doute, créez une table b avec un seul enregistrement. Si vous obtenez une erreur dans cette zone, ajoutez d'autres lignes au fur et à mesure que vous apprenez où il peut échouer.

Si vous voulez prendre ceci au bord, créez la table de test (avec toutes les données) dans un test unitaire. De cette façon, vous pouvez documenter les données de test que vous utilisez.

[EDIT] Vous avez besoin d'une base de données de test. N'exécutez pas de tests sur une base de données qui peut changer. Idéalement, les tests devraient détruire toute la base de données et la recréer à partir de rien (tables, index, données, tout) comme première étape.

Dans cette base de données de test, conservez uniquement des données de test bien définies qui ne changent que si vous définissez de nouveaux tests (et non par quelqu'un qui "fait juste quelque chose"). Si vous le pouvez, essayez d'exécuter vos tests sur une base de données en mémoire.

Answer 3

Je suggérerais des vues matérialisées. Ce sont des vues qui stockent des données distantes localement.

Answer 4

En théorie, pour effectuer les tests unitaires, vous pouvez travailler avec n'importe quel ensemble de données contrôlées créées et conçues en fonction de vos cas de test. Il ne doit pas être votre système de développement ou de live. C'est en supposant que votre unité est suffisamment portable. Vous devriez le tester avec vos bases de données/applications actuelles quand vous viendrez aux tests d'intégration, qui pourraient tout aussi bien être sur le système live (donc aucun lien DB ne sera nécessaire - Je comprends que vos bases de données live sont en un seul endroit). Ce que j'essaie de dire, c'est que vous pouvez/devriez tester votre unité (c'est-à-dire votre composant, requête ou ce que vous définissez comme une unité) sur un ensemble contrôlé de données qui simulerait différents 'cas d'utilisation' Une fois que vous avez terminé vos tests pour obtenir des résultats satisfaisants, vous pouvez procéder à l'intégration et exécuter des tests d'intégration. Tests d'intégration - vous pouvez l'exécuter dans l'environnement en direct, mais seulement après avoir prouvé par un test d'unité que votre composant est «à l'épreuve des balles» (si cela correspond à l'approche/philosophie de votre entreprise :) - sys réaction de l'admin: "Êtes-vous flippin creazy?!")

Si vous essayez de remonter dans le temps et tester les unités déjà mises en œuvre, alors pourquoi s'embêter? Si elles ont été dans une utilisation de production pendant un certain temps sans incidents, je dirais qu'ils sont OK. Cependant, il y a toujours une chance que votre unité/requête ait un effet de bombe à retardement sur le côté (effet cumulatif dans le temps). Eh bien, analyser l'impact est la réponse.