Oracle ODP.net Managed vs Unmanaged Driver
Existe-t-il des références de performances entre les pilotes Oracle ODP.Net gérés et non gérés?
(c.-à-d. y a-t-il un avantage à passer au pilote géré autre que pour la simplicité de l'architecture/du déploiement)
Je voudrais partager quelques résultats. Je pense que le petit manque de performances vaut la peine par rapport à la facilité de déploiement.
Remarque: seg signifie secondes. Désolé pour ça.
Bien sûr, c'est un test simple, et il y a plusieurs sujets qui ne sont pas couverts comme le pool de connexion, la stabilité, la fiabilité, etc.
Il est important de mentionner que les scénarios ont été exécutés 100 fois. Les quantités de temps sont donc la moyenne de ces 100 exécutions.
Puces de la vidéo de démarrage rapide :
- Moins de fichiers (1 ou 2 DLL au maximum)
- Encombrement réduit (10 Mo contre 200 Mo)
- Déploiement côte à côte plus facile
- Même assemblage pour 32 et 64 bits (sauf pour le deuxième assemblage MTS).
- Sécurité d'accès au code
Je ne suis pas sûr de la performance, mais je doute que ce sera très différent de toute façon. Je suppose que les deux pilotes communiquent de manière identique sur "Oracle Net". Bien qu'il puisse y avoir des différences mineures dans les opérations côté client en mémoire effectuées pour préparer une commande et traiter les résultats, cette surcharge ne représente généralement qu'une fraction du temps par rapport à la transaction entière. La plupart du temps/coût est passé sur le serveur en physique IO et transfert des données au client. Ce n'est tout simplement pas la même chose que de passer par le fournisseur oledb ou System.DataAccess .OracleClient driver. Ceci est une autre version de la même société de SGBDR - ils vont exploiter toutes les mêmes astuces de performance que leur autre client a utilisé. J'aimerais pouvoir publier une étude, mais je suppose qu'une telle chose ne fonctionne pas exister parce qu'en fin de compte, ce serait banal. Un cas d'absence de nouvelles est une bonne nouvelle - si le nouveau fournisseur était en quelque sorte pire, vous liriez à ce sujet.
La simplicité est une raison suffisante pour passer à cette OMI. La grande majorité des développeurs et des administrateurs ne comprennent pas entièrement le fournisseur et sa relation avec le client non géré. La confusion à propos des préférences d'origine d'Oracle, de la non-concordance des versions, des mises à niveau, etc. apparaît constamment. Éliminer ces questions serait un changement bienvenu.
Voici un piège pour vous tous. Cela m'a pris quelques semaines pour comprendre pourquoi les pilotes gérés Oracle ne se connectaient pas à l'aide d'ef6. Si votre base de données possède les algorithmes d'intégrité des données suivants, vous DEVEZ utiliser les pilotes non gérés !!
enfoui profondément dans la documentation Oracle !!! MERCI Oracle !!!!! 
Le déploiement plus facile et l'indépendance des témoins sont vraiment de beaux avantages, mais vous devriez plutôt évaluer soigneusement l'utilisation typique de votre pilote. J'ai été confronté à un handicap de performances de près de 50% lors de l'utilisation du nouveau pilote géré dans les processus 64 bits. D'autres personnes signalent des fuites de mémoire, etc. sur le forum Oracle: https://forums.Oracle.com/community/developer/english/Oracle_database/windows_and_.net/odp.net . On dirait que c'est une sorte de produit buggy Oracle typique qui a besoin de quelques mois/années pour s'installer: /
N'oubliez pas que les types personnalisés ne sont pas encore pris en charge. Cela peut être une raison pour ne pas basculer vers le pilote géré.
Consultez ce document Oracle pour connaître les différences entre la version gérée et la version non gérée:
http://docs.Oracle.com/cd/E16655_01/win.121/e17732/intro004.htm