Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Débat SGBD : Avantages et inconvénients d'Oracle

Le , par jbmen

0PARTAGES

0  0 
Salut,

J'ai besoin d'introduire dans mon mémoire les avantages et les inconvénients d'Oracle. Si vous pouviez m'aidez, j'en serais ravi car j'ai beaucoup cherché mais je n'ai pas trouvé.

Merci à vous

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de AlternantOracle
Membre régulier https://www.developpez.com
Le 07/07/2010 à 16:27
Citation Envoyé par voran Voir le message

Ce que je reprocherais plutôt à ORACLE, c'est que ces outils sont activés par défaut et peuvent nous rendre hors la loi à l'insu de notre plein gré... enfin les DBA junior
Ca m'a fait beaucoup rire puisque j'ai failli ne pas voir cela pendant mon projet :p.

Sinon je suis pas d'accord non plus pour la coquille vide. Rien que pour les rapports et les remontees d'alertes ca vaut le coup. Ensuite tu gref des widgets sur ta grid et les admins seront en un clic sur la page de la base concernee:

http://www.oracle.com/technology/pro...ets/index.html

Exemple de rapport de dispo:

http://4.bp.blogspot.com/_fSrIpdF1Zd...eport_page.jpg

J'ai beau etre un debutant, j'avoue que ces outils sont plutot bien quand on sait ce que l'on cherche. Bien sur ca ne fait pas tout ...

Et histoire de revenir dans le debat. Je vais donner mon avis de debutant qui vaut ce qu'il vaut. MS-SQL reste un cliquodrome imbitable.

Avec oracle il y a des docs pour tout. C'est tres bien explique et surtout tres detaille, du coup on comprends vite les mechanismes et on a besoin d'aucune interface pour faire tout ce qu'on veut. A contrario avec MS-SQL c'est un vrai calvair de trouver une explication sur les sysdbo ( quand on ne sait pas ce qu'on cherche ).
2  0 
Avatar de fdenis
Nouveau membre du Club https://www.developpez.com
Le 29/12/2008 à 16:12
Citation Envoyé par kedare Voir le message
- Postgresql est rapide (depuis la 8.2 surtout)
Oracle aussi.

Citation Envoyé par kedare Voir le message

- Postgresql permet l'écriture de procédures stockées en une grande variété de langages (python, java, ruby, c, tcl, etc...) (contrairement a Oracle)
FAUX : tu écris en ce que tu veux avec les "procédures externes" d'Oracle qui existent depuis... toujours à ma connaissance

Citation Envoyé par kedare Voir le message

- Postgresql peut se ballader sans un serveur d'application qui va pomper 50% de la memoire pour être utilisé une fois toute les 2 semaines (contrairement a Oracle)
Oracle Database et Oracle Application Server sont deux choses différentes.

Citation Envoyé par kedare Voir le message

- Postgresql est entièrement modulaire (contrairement a Oracle)
Tiens ? tu peux installer uniquement ce que tu veux sous Oracle, n'importe quel "module", tu peux tout recompiler, les makefiles sont dans l'ORACLE_HOME

Citation Envoyé par kedare Voir le message
- Postgresql est disponible plus frequement sur les hébergement mutualisé, et est plus simple a installer qu'oracle sous linux et dérivé (apt-get install postgresql-server)(sous windows je sait pas)
Oui mais comment fais-tu pour installer plusieures versions de postgresql sur la même machine ? (chaque version faisant tourner 1 ou X instance)
De plus, c'est pas compliqué d'installer Oracle, regarde mon post ici : http://www.developpez.net/forums/d55...us-rhel-5-1-a/

Citation Envoyé par kedare Voir le message

- Postgresql essais va pas aller utiliser un "pseudo-sql modifié" (contrairement a Oracle)
Et donc... ?

Citation Envoyé par kedare Voir le message

- Postgresql est simple a administrer (1 fichier pour la config interne, 1 fichier pour les autorisations sur les interfaces réseau, un ptit combo ANALYZE/VACUUM/REINDEX en cas de besoin (1x par semaine max je dirais, et Hop c'est fini)
Oracle a un fichier d'initialisation (init.ora ou SPFILE - la plupart des paramètres sont dynamiques), il exiiste un fichier pour ce que j'imagine tu appelles les "interfaces réseaux" aussi; Oracle sait gérer les index donc pas besoin de les reconstruire et il est extrèmement simple de mettre en place la mise à jour (ANALYZE) des statistiques pour l'optimiseur (c'est même par défaut en 10). Je vois pas bien ou est la différence là

Citation Envoyé par kedare Voir le message

et surtout:
Postgresql est gratuit,
Oui et sans support

Citation Envoyé par kedare Voir le message
et oui, le développeur ou l'entreprise a pas envie d'aller dépenser plus de 10k$ pour avoir un truc a moitié bugué comme Oracle
Plait-il ? de quels bugs parles-tu ? ca fait plus de 10 ans que je suis DBA Oracle et j'ai du tomber sur 3 "bugs"...

Citation Envoyé par kedare Voir le message

, et qui va lui meme demander un serveur de plus de 15k$ pour tourner convenablement, alors qu'on peut avoir la même chose sans rien payer, totalement stable, et qui arrive a booter sur un P3 avec 256mo de ram sans broncher...
Mais que dis-tu ... Oracle tourne parfaitement avec 150 Mo de RAM (sur un KIMSUFIT d'OVH par exemple) tout comme il peut tourner avec 50 Go de RAM

Citation Envoyé par kedare Voir le message

Bref, Postgresql n'a strictement rien a envier a Oracle, ça serais plutôt l'inverse je pense... ou est l'interet d'utiliser Oracle ?
Tu nous donnes un exemple concret ? car jusque là tes points théoriques sont faux donc bon...
1  0 
Avatar de eprost
Futur Membre du Club https://www.developpez.com
Le 02/03/2009 à 15:25
Pour ceux qui ne connaissent pas Oracle mais veulent réellement se faire une idée de la richesse de la "bête", je suggère de prendre le temps de lire les deux documents suivants qui détaillent les nouveautés de la version 10 et de la version 11. Quelques exemples pour la 11g : intégration au Volume Shadow Services et à Active Directory.

En soi, ces nouveautés ne seront pas toujours très "parlantes", mais à chaque fois, on trouve un lien vers la documentation de référence Oracle qui détaille la chose et permet d'en apprendre plus.

Je recommande de commencer par la doc 10g qui me semble contenir plus de nouveautés "parlantes", c.à.d qui auront un sens pour ceux qui ne maîtrisent pas Oracle.



De plus, la documentation Oracle est une réelle richesse du produit (ça fait 1,2 Go pour la 10G sur mon poste - j'ai bien écrit 1,2 giga-octets). Elle est consultable et téléchargeable gratuitement sur le site Web OTN (voir ici pour télécharger la doc 10g).

Voir par exemple ici pour un accès à toute la documentation 10g : cliquer ici puis ensuite sur "View Library".

Pour ce qui est des fonctionnalités d'Oracle, je confirme ce qui a déjà été écrit dans ce topic : ce SGBD est bien plus qu'un moteur de base de données et il offre des fonctionnalités qui permettent de réels gains de productivité, à condition de connaître leur existence et de savoir s'en servir.

Je rejoins en cela l'analyse faite par Thomas Kyte (le monsieur derrière AskTom) dans son livre "Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions" (ISBN-10 : 1590595300, feuilletable en ligne sur Amazon) : il ne sert à rien de payer une licence Oracle pour faire du SQL standard. Cela est un réel gâchis car on se prive de multiples fonctionnalités qui font gagner de l'argent et du temps.

Parmi celles-ci, quelques exemples (faites un search dans la doc 10g en ligne pour avoir des explications très détaillées, je donne juste une petite synthèse ici car ce post est déjà long) :

- Index calculés, ou "function based index" : permet de faire un index sur le résultat de 0..n fonctions appliquées aux colonnes de la table. Utile par exemple pour indexer UPPER(NOM) au lieu d'avoir à ajouter une colonne NOM_MAJUSCULES + un trigger + tous les problèmes habituels quand on dénormalise un MCD. Une requête faisant "WHERE UPPER(NOM) = 'TATA' utilisera alors cet index.

- Vues matérialisées, ou "materialized views" : je n'ai pas assez de place pour faire une synthèse vraiment fidèle car ce sont des objets très riches... Disons que c'est l'alliance entre une table et une vue, offrant une grande finesse sur la manière dont les données sont rafraîchies (automatiquement ou non), et utilisable par l'optimiseur pour re-écrire des requêtes qui dont la clause WHERE correspond à celle de la vue matérialisée... Oui, c'est un objet très riche.

- Scheduler : quiconque cherche à déployer rapidement un scheduler fonctionnant de la même manière sur Windows, Linux, Solaris, HPUX, OpenVMS, ... aura à coeur de lire la documentation de cet outil. Il n'atteient pas la souplesse des produits dédiés au scheduling mais il est très très largement supérieur à des solutions type crontab (ou équivalent Windows).

- Advanced Queuing : un broker de messages disposant notamment d'une API JMS, intégré à la base de données, donc exploitable depuis tous les langages supportés par Oracle sur toutes les plate-formes Oracle. Et, comme cela est intégré à la base de données, on ne se demande pas s'il faut faire des transactions XA (ou du code bien plein de bugs pour émuler XA) afin d'avoir la garantie de ne jamais perdre un seul message quoiqu'il arrive.

- Streams et Change Data Capture (en mode asynchrone) : framework et outillage par-dessus permettant de répliquer des données en temps réel entre deux instances Oracle, avec éventuellement des filtrages, des règles de routage pour orienter / dupliquer les données vers plusieurs noeuds physiques, gestion des erreurs, ... le tout étant évidemment totalement transactionnel. Qui a déjà voulu coder ce genre de choses saura apprécier le gain de productivité.

- PL/SQL : un véritable langage de programmation, avec un compilateur optimisant, orienté objet (mais ce n'est pas une obligation d'en faire usage). Conceptuellement, PL/SQL est très proche de ADA (définition de sous-types par exemple).

- Packages pré-installés : la liste est trop longue pour lister tous les packages de code pré-installés, c'est une véritable bibliothèque (indexation full text, ...).

- SQL étendu (oui, pas standard) : gestion native du XML, opérateurs hiérarchiques (chercher "CONNECT BY" par exemple), opérateurs analytiques (chercher "OVER", ... toutes ces extensions permettent de véritablement tirer profit du SGBD. Les opérateurs analytiques par exemple évitent d'avoir à écrire des requêtes complexes faisant des auto-jointures sur elles-mêmes. Le gain est immédiat en coût de maintenance (et bien souvent en performances). Les opérateurs hiérarchiques permettent de faire des requêtes qui parcourent des structures de données arborescences (sans aucune limite de profondeur, évidemment, avec toute la souplesse de SQL pour définir la relation père <=> fils). Le gain est immédiat en codage et maintenance.

- Optimiseur par les coûts (cost based optimizer) + statistiques données + statistiques système : l'un des points forts du SGBD. Juste pour donner une idée, il est utile de savoir que Oracle va calculer le chemin d'accès physique aux données (= le plan d'exécution) en fonction de la répartition statistique des valeurs dans les tables (+ index existants) afin de choisir le ou les index qui seront les plus efficaces pour les valeurs données dans la clause WHERE. Mais cela va aussi être pondéré par le fait que l'index et la table sont à peu près (ou non) organisés physiquement dans le même ordre (sinon, cela génère beaucoup d'I/O sur des blocs très éloignés les uns des autres). Cela peut aussi être pondéré par les performances du CPU, des I/O pour x blocs séquentiels, pour x blocs aléatoires, ...

- Consistent read : encore un élément capital qui est bien souvent ignoré (sauf par Firebird, PGSQL), qui fait que le SGBD pose très très très peu de verrous. Cela est un facteur clef quand on doit faire face à une montée de charge car Oracle. Par exemple, Oracle ne pose aucun verrou quand on fait un SELECT : une autre session peut faire de l'UPDATE sur les mêmes lignes sans être bloquée, à l'inverse de beaucoup d'autres SGBD. Ce fonctionnement est natif, c'est d'ailleurs la seule et unique manière dont Oracle sait fonctionner. Quand on a un système avec plusieurs centaines de requêtes par seconde en concurrence sur une même table, ça fait un sérieux avantage, en prenant bien conscience que la performance ne se fait pas au prix de dénormalisations du MCD pour ajouter des tables intermédiaires, "tordre" les requêtes, ou que sais-je encore.

- Consistent read : c'est aussi cette fonctionnalité qui fait que les résultats produits par une requête Oracle sont toujours cohérents par rapport à l'isolation (souvenez-vous, le I de ACID). Pour faire un reporting un peu gourmand par exemple, on passe en mode READONLY (ou SERIALIZED si écritures nécessaires) et on peut laisser tourner les 50 requêtes de reporting pendant 5 heures : le résultat fourni à la fin sera totalement isolé de ce qui a été fait sur le SGBD pendant 5 heures ET sera totalement cohérent (un count(*) from T fait un début retourne le même résultat quand on l'exécute 5 heures après, même si la table T a grossi de 1 million de lignes) ET tout ceci est obtenu "out of the box" de manière native.

- Architecture et consistent read : le bon fonctionnement d'une requête Oracle dépend uniquement de l'espace disque attribué Oracle. Cela paraît anodin mais je pense que c'est plus profond qu'il n'y paraît et cela a de véritables impacts en termes de productivité. En effet, l'architecture Oracle est très largement basée sur les journaux (redo logs et archive logs) afin d'offrir ce fameux "consistent read". En première lecture, on comprend qu'il faut acheter des disques durs ou du SAN. C'est vrai. Mais en seconde analyse, on comprend surtout que l'on peut coder les fontions d'une application de manière "naturelle", c.à.d avec un seul et unique COMMIT à la fin, lorsque tout le travail a été fait. Je m'explique : combien de fois avez-vous vu du code qui fait des trucs du genre "lecture ligne à ligne, traitement, si nb_lignes % 500 = 0 alors tracer 'je suis à la ligne XXX' puis commit, etc" ? Ce sont de véritables mines : si le traitement plante au milieu, il faut prévoir du code pour repartir (= bug, = maintenance, = cher). Et surtout, cela laisse la base de données dans un état incohérent - c'est dramatique. Il faut alors faire le traitement dans des tables annexes, isolées, ... = code, = bug, = cher... L'architecture Oracle permet (d'autres aussi ?) de ne pas faire de genre de code : on code l'application en fonction des contraintes métier et le COMMIT est codé quand on a atteint un état cohérent, pas avant. Ensuite, c'est à l'architecture système de s'adapter, et c'est la bonne démarche (ou alors, c'est qu'on n'a pas les moyens de ses ambitions, et le problème n'est plus technique). Tout cela se fait sans aucune difficulté technique.

- Architecture : pour illustrer la richesse de la chose par rapport au point précédent, on peut même ajouter de l'espace disque à Oracle "à chaud" : en attendant que le DBA et l'ingénieur système interviennent pour allouer un peu plus d'espace disque, le moteur se met en attente, les requêtes qui ont provoqué le débordement disque sont juste bloquées. Puis, après ajout d'espace disque, tout repart, zéro plantage, zéro arrêt, les applications qui avaient des requêtes en cours n'ont strictement rien vu. Cela est un véritable gain par rapport à un Système d'Information qui se plante à cause d'un "file system full" provoqué par une volumétrie inattendue par exemple.

- Et de multiples autres choses telles que RMAN qui est un véritable outil de backup à chaud / à froid livré en standard, ou encore Oracle Enterprise Manager (= frontal Web d'administration), ou encore AWR (= collecte en temps réel de métriques de performance très très pointues), ...

Donc, pour synthétiser : quand on achète Oracle, on achète une Formule 1 car on a pour objectif de gagner un Grand Prix. Dès lors, il faut s'entourer d'expertise (ou l'acquérir) afin de savoir tirer profit d'un engin exceptionnel et des capacités qu'il offre (et cela est certainement vrai pour d'autres SGBD).

Dès lors, il est également contre-productif de vouloir s'en tenir à du SQL standard (que ce soit avec Oracle ou d'autres) : quel intérêt ? j'ai payé pour avoir accès à du SQL performant, pourquoi s'en priver ? qui oserait dire par exemple "on va coder en Java mais il faut être portable vers C#, Pascal et COBOL" ? en quoi est-ce différent pour un SGBD ?

Maintenant, si l'objectif n'est pas de gagner un Grand Prix (ou si on n'a pas les moyens / le temps d'apprendre à conduire une Formule 1), alors il faut impérativement choisir un véhicule plus approprié.

Merci de leur courage à ceux qui ont lu ce post jusqu'ici...
1  0 
Avatar de 7gyY9w1ZY6ySRgPeaefZ
Expert éminent https://www.developpez.com
Le 09/09/2008 à 3:53
Citation Envoyé par jbmen Voir le message
les avantages et les inconvénients d'oracle
Pour quelles besoins ? Difficile de répondre dans l'absolu.
0  0 
Avatar de orafrance
Expert éminent sénior https://www.developpez.com
Le 09/09/2008 à 9:07
par rapport à quoi ? Inconvénient : ça fait pas le café, avantage : ça stocke plutôt bien les données
0  0 
Avatar de Vincent Rogier
Rédacteur https://www.developpez.com
Le 09/09/2008 à 14:08
Quelques avantages (ce qui me vient en premier à l'esprit) :
  • SGBD le plus portable (machines/architectures)
  • SGBD le plus utilisé (48% marché global),
  • SGBD le plus riche en termes de fonctionnalités
  • SGBD le plus tunable
  • Larges solutions d'accès (tout langages et toute technologies)
  • Pas mauvais sur le marché de la haute dispo, gestion des clusters, ..
  • ...
0  0 
Avatar de orafrance
Expert éminent sénior https://www.developpez.com
Le 09/09/2008 à 15:54
Citation Envoyé par vicenzo  Voir le message
[*]SGBD le plus riche en termes de fonctionnalités

SQL Server 2005 fait aussi bien

Citation Envoyé par vicenzo  Voir le message
[*]Larges solutions d'accès (tout langages et toute technologies)

Comme tous les SGBD

Citation Envoyé par vicenzo  Voir le message
[*]Pas mauvais sur le marché de la haute dispo, gestion des clusters, ..[*]...[/LIST]

SQL Server est bien meilleur... je dirais que c'est plutôt un inconvénient pour Oracle en fait
0  0 
Avatar de Vincent Rogier
Rédacteur https://www.developpez.com
Le 09/09/2008 à 16:09
Citation Envoyé par orafrance


SQL Server 2005 fait aussi bien

Citation Envoyé par vicenzo

SGBD le plus riche en termes de fonctionnalités
On pourrait très bien lister les fonctionnalités, mais cela n'as pas de sens sens. Ce que je dis, c'est que Oracle a des fonctionnalités peu rencontrées ailleurs comme la gestion avancée des pools de sessions et connexions, un support de migrabilité de session avancé et des choses comma la gestion de LOB de 128 TeraOctets, .....
Sur que SqlServeur a plein de fonctionnalités, mais je pense toute de même que la gamme est tout de même "plus large" chez Oracle

Citation Envoyé par orafrance


Comme tous les SGBD

Citation Envoyé par vicenzo

Larges solutions d'accès (tout langages et toute technologies)
Ben pas forcément... J'ai pas vu de précompilateur cobol pour SQLServer... Ca existe ? Ni d'API fortran pour FireBird....

Citation Envoyé par orafrance

SQL Server est bien meilleur... je dirais que c'est plutôt un inconvénient pour Oracle en fait

Citation Envoyé par vicenzo

Pas mauvais sur le marché de la haute dispo, gestion des clusters, ...
Ok, on peut en discuter, je reste dubitatif... si SQLServer était si parfait en terme de dispo, perf etc... sur des bases énormes, tous les grand compte aurait des serveur windows .
Sérieusement, encore une fois, je ne compare pas Oracle à SQLServer.
Tout ce que je dis, c'est qu'il y a peu de SGBD (j'ai pas dit qu'oracle était le seul...) pouvant assurer un haute dispo garantie et une clusterisation sur des Teras de données...
0  0 
Avatar de orafrance
Expert éminent sénior https://www.developpez.com
Le 09/09/2008 à 17:08
Citation Envoyé par vicenzo Voir le message
On pourrait très bien lister les fonctionnalités, mais cela n'as pas de sens sens. Ce que je dis, c'est que Oracle a des fonctionnalités peu rencontrées ailleurs comme la gestion avancée des pools de sessions et connexions, un support de migrabilité de session avancé et des choses comma la gestion de LOB de 128 TeraOctets, .....
Sur que SqlServeur a plein de fonctionnalités, mais je pense toute de même que la gamme est tout de même "plus large" chez Oracle

Ben pas forcément... J'ai pas vu de précompilateur cobol pour SQLServer... Ca existe ? Ni d'API fortran pour FireBird....
En effet, Oracle tire son épingle du jeu en s'intéressant à des besoins très spécifique

Citation Envoyé par vicenzo Voir le message
Ok, on peut en discuter, je reste dubitatif... si SQLServer était si parfait en terme de dispo, perf etc... sur des bases énormes, tous les grand compte aurait des serveur windows .
Mais c'est le cas

Sauf qu'on mets pas ses gros serveurs Unix à la poubelle ni migrer les SGBD tous les 4 matins

Le plus gros soucis de SQL Server c'est d'être distribué uniquement sous Windows. Mais Windows regagne du terrain notamment grâce à la virtualisation, de fait, SQL Server suit le mouvement

Les clients commencent à en avoir assez des versions à répétition avec des bugs improbables sous Oracle (le dbca 10.2.0.1 qui ne pouvait pas créer l'instance c'est quand même un peu gros )

Citation Envoyé par vicenzo Voir le message
Sérieusement, encore une fois, je ne compare pas Oracle à SQLServer.
Tout ce que je dis, c'est qu'il y a peu de SGBD (j'ai pas dit qu'oracle était le seul...) pouvant assurer un haute dispo garantie et une clusterisation sur des Teras de données...
SQL Server en est capable et la mise en oeuvre est beaucoup plus simple que sous Oracle. Sans exagérer, tu montes l'équivalent d'une standby en quelques clics ou en quelques secondes en le scriptant.

Je découvre SQL Server et, vraiment, je suis bluffé par la simplicité qui ne sacrifie pas à l'efficacité... c'est vraiment fort Mirroring, copie de base de données ou la sécurité sont indéniablement des points forts de SQL Server... et il n'y a rien d'étonnant à ça : c'est évidemment beaucoup plus simple d'améliorer l'intégration du SGBD avec le système quand on est éditeur du SGBD et de l'OS sur lequel il est installé

D'ailleurs, si j'avais un seul inconvénient à retenir sous Oracle ce serait le coup de l'exploitation.
0  0 
Avatar de jbmen
Nouveau membre du Club https://www.developpez.com
Le 10/09/2008 à 14:23
merci les mecs,

se que je cherche c les avantages et les inconvénients en générale ,pas listé tout mais au moins pour montré que oracle et le meilleur de tous.

merci de votre aide ...

un lien ou une doc me fera un grand plaisir
0  0