Salut,
 
Je dois faire un choix entre Oracle 10i, et un SQL Server 2000.
 
J'ai une machine sous Win 2003, avec 2 Go de mémoire, des disques SCSI, et un bi-pro.
 
J'ai souvenir que Oracle 8.0.5 était catastrophique sur architecture x86. Depuis la 8i, je sais que le noyau a été totalement réécrit afin d'être plus optimisé pour Win32.
 
D'après vous, lequel de ces SGBD supportera le plus une montée en charge en importante ?
 
Je devrais me retrouver avec une base comprise entre 2 et 10 Go assez rapidement, avec des trigger à plus savoir qu'en faire (et récursifs), couplés à des PS schédulées, relativement complexes aussi, qui vont tourner à intervals très cours (toutes les 5 minutes au maximum). Tout ceci générera des transactions portant sur plusieurs millions de lignes, je sais que Oracle à tendance à faire des "rollback segment fault" quand il y a trop de données traîtées dans une transaction.
 
Les volumes impactés par ces schedules seront rapidement énormes, à la fois pour la lecture, mais aussi pour l'écriture.
 
Je sais que SQL Server est vraiment très rapide pour tout ce qui est complexe, surtout au niveau sélection (jusqu'à présent, je l'ai toujours trouvé plus rapide qu'Oracle à ce niveau là).
Par contre, pour ce qui est des mises à jours de données, Oracle semble plus rapide.
 
Ensuite, la base sera touchée à partir d'un site Web écrit en ASP et objets VB (ouais, je sais, c'est d'un autre age mais bon). Avec SQL Server, je sais que je peux bénéficier d'un drivers OLEDB, extrêment performant. Avec Oracle, je ne suis pas sûr qu'il y a un tel drivers, et surtout, vu la quantité de bugs qu'il y a dans le drivers ODBC de la version 9i Unix (la moitié de types plantent, etc.), c'est un point qui nécessite que je sois rassuré.
 
Mon principal souci, c'est que depuis 5 ans, j'ai pas vu tourner un Oracle sur une machine Win32 "correcte", et encore moins une version récente d'Oracle, du coup j'ai en mémoire les perfs catastrophiques de l'époque, et les perfs grandioses d'un serveur Unix, mais c'est pas la même bécanne
 
A votre avis, qu'est-ce que je préconnise ?

jai le meme probleme que toi: Oracle 10i ou SQL Server
 
ici jai besoin de pouvoir gerer des bd de taille relativement importante
 
au debut jai mm pense a mySQL (gratuit,facile a installer chez les clients) mais qd je vois qu'il ne supporte mm pa les trigger et autre => au revoir    
 
pour linstant jai pa encore reussi a me decider, le seul truc qui meloigne d'Oracle c son prix et la prise en main beaucoup plus difficile  
 
sinon jai trouve 1 article la dessus mais c pas terrible
http://www.mssqlcity.com/Articles/ [...] oracle.htm

Bon, je vais me tourner vers SQL Server, parceque je le maîtrise beaucoup plus, à tous les niveaux (j'ai bidouillé chez moi avec, alors que j'ai installé une fois Oracle chez moi et ça marchait pas donc j'ai aucune expérience niveau admin / paramètres )
 
Sinon, il y a quelques inexactitudes dans le lien que tu as donné. Par exemple, avec SQL Server, on peut tout à fait faire des tables temporaires, et même deux types différentes : locales à la session, étendues à toute la base. Plus quelques autres éléments qui auraient pu nécessité explication, au niveau de l'absence des triggers "BEFORE", qui reviennent au même que "INSTEAD OF", puisque dans ces derniers, on fait manuellement l'action dans la table, donc si on annule avant de faire l'action, ça revient au même qu'un BEFORE

klr que le test est pas tres bien realisé
 
ne serait ce que les prix ca me semble un peu exagere 2.000.000$ la version doracle
 
faudrait vraiment que je trouve un test qui soit un minimum correct
 
jpeut pas justifier le choix dSQL server en disant : "oui c celui qui me plait le mieux puis jai rencontre un type sur hf....."
 
enfin bon voila quoi jmanque de doc

C'est sûr...
 
Disons que jusqu'à 8i, il y avait une raison en or pour ne pas choisir Oracle : comme Apache à l'époque, il s'agissait de la version Unix recompilée pour Win32, avec tous les défauts d'optimisation liés à la plateforme d'origine (multi-process au lieu de multi-thread, taille des registres utilisés, etc.)
Mais depuis la 8i, ils maintiennent deux versions en //, et Oracle est bien mieu optimisé.
 
Je pense qu'un argument de taille, outre le prix, c'est le coût de la maintenance : étant donné la config minimum, SQL Server semble moins gourmand (c'est pas compliqué à voir d'ailleurs, puisque la 9i en tout cas, toute l'interface est en Java, ce qui n'est pas là pour optimiser la bête).
Mais surtout, c'est l'administration : alors que les paramètres de SQL Server sont très clairs et très détaillés dans l'aide fournie, Oracle nécessite un DBA confirmé pour être correctement installé et paramètré au jour le jour. Donc entre payer un simple ingénieur réseau ou ingénieur système à 3 K€/mois pour paramètrer la base, tu es obligé de taper dans l'expert, qui demande dans les 4 ou 5K€/mois. C'est non négligeable je pense. On doit trouver la même problématique au niveau hébergement, bien que je n'aie jamais creusé le sujet.
 
Ceci dit, dans mon cas, le coût n'a qu'une faible importance, étant donné que le client a déjà tout ce qu'il faut en interne, que ce soit les licences ou les DBA.
 
Ensuite, d'un point de vue fonctionnalités, Oracle est un peu plus complet que SQL Server, mais son principal défaut, c'est l'absence de doc claire (c'est pire que le man de Linux), donc on n'arrive jamais à utiliser ce qu'on veut, ou alors on y passe plus de temps.
 
Ensuite, et surtout, les lacunes de SQL Server 2000 par rapport à Oracle devraient être en partie comblées par la nouvelle mouture 2005 qui va sortir sous peu.
A nouveau, c'est un point qui ne m'impacte pas vraiment, puisque la base n'aura pas besoin des éléments aujourd'hui spécifiques à Oracle.
 
Reste alors pas grand chose, mise à par la puissance brute du produit (à hauteur de combien de requêtes simultanées l'un prend le dessus par rapport à l'autre, dans une config "classique", c'est à dire sans cluster ni load balancing - car dans ce domaine, SQL Server semble largement outrepasser Oracle, mais comme dit dans ton lien, ce n'est pas représentatif des besoins de la majorité des entreprises)
 
Reste un avantage pour SQL Server au niveau des fonctionnalités : c'est DTS. Avec Oracle, il n'y a pas d'équivalent, et pour ce qui est de la coopération inter-bases, c'est un élément non négligeable (c'est quand même pas mal de pouvoir, sans développement, faire de la réplication d'un serveur tournant avec un SGBD x, sur SQL Server, tout en mixant les données provenant d'un SGBD y, suivant une table de paramètrage modifiée à la main dans un fichier CSV ou Excel). J'ai pu tester ce point et on peut réellement faire en quelques minutes des outils d'intégration de données qui nécessiteraient un projet entier sous Oracle.
 
A côté de ça, Oracle a des éléments sympatiques, tels que le SQL Loader, qui permet d'alimenter une table à partir d'un fichier formaté de plusieurs Go en quelques secondes, ou ses fonctions d'indexation de texte, qui outrepassent celles de SQL Server (qui sont déjà pas mal quand même)
 
Choix difficile en somme.

Mais tu peux leur dire "oui c celui qui me plait le mieux puis jai rencontre un type sur hf.....et en plus il est moins cher" , la le boss il va etre tout de suite plus cooperatif a mon avi

Parcontre hop dans mes bookmarks comme d'ailleurs pratiquement tout les topics sur lesquels arjuna poste . Que dire ... j'y connais tres peu en bases de données et c'est chaque fois un cours acceleré de lire ce genre de topic

l'autre jour qqn m'a parlé d'un probleme souvent rencontré sous SQL server, il s'agissait dun probleme avec les fichiers log qui ont tendance a se remplir un peu trop rapidement ainsi qu'une mauvaise capacité a gerer des gros volumes de données
 
bon jai pas trop compris, je connais pas trop SQL server jusque la jmen suis uniquement servi pour le developpement,  jamais fait dadministration de cette db

En effet, les fichiers de log ont le problème avec SQL Server de... grossir... et autant normalement ils devraient être flushés après chaque backup, autant ça ne marche pas toujours.
 
Les premières semaines après mise en place, il est donc important de les monitorer pour voir s'ils déconnent ou pas. Ca m'est arrivé de remplir un disque de 80 Go dédié aux logs en mois de 2 jours.
Mais il y a une bidouille qu'on peut automatiser qui permet d'aller vider les logs à la bourrin à la fin de chaque backup. Le problème n'est donc pas catastrophique.
 
Sinon, pour ce qui est la gestion de la volumétrie, je n'ai encore jamais eu d'echo. Actuellement, la plus grosse base avec laquelle j'aie bossé faisait moins de 1 Go.
D'ici la mise en place du projet qui me fait poser la question, je devrais terminer un autre projet, où la base atteindra plusieurs Go (avec un refresh tous les jours en plus...), je pourrai alors en dire plus sur le sujet.

Euh, vous commencez à me faire flipper avec toutes ces histoires de fichier log qui grossit en douce !! Vu que je tourne sous SQL Server 2000 depuis 1 mois et demi j'aimerai m'assurer que ca ne m'arrive pas. Ils sont ou ces fichiers ?

Tu les vois quand tu fais "propriété de la base". Il y a la taille de la base qui s'affiche, et celle des logs.
 
PS: Ce ne sont pas des "logs" à proprement parler, mais le log des transactions. Le SGBD stipule là-dedans toutes les actions effectuées dans la base en tenant compte des transactions, afin de pouvoir retrouver un état stable de la base après un crash.
 
=> Tu restaure le backup principal.
=> Tu restaure les backups incrémentiels.
=> Tu rééxécute ligne par ligne ce log jusqu'à l'instant de la merde qui a planté la base.
 
Vi son utilité, il est censé être tronqué à chaque backup complet, voir incrémentiel. Mais il semblerait qu'il y a un bug qui fait qu'il n'est pas toujours tronqué. Il y a alors une série de lignes de commandes à schedule avec le backup afin de les shooter manuellement à la fin du backup.
 
Ceci dit, tu t'en rend vite compte qu'ils sont pleins, car vu que SQL Server ne peut plus loguer dedans tes actions, il refuse de les effectuer dans la base (pour ne pas se retrouver sans posibilité de les restaurer), avec un message très explicite

j'arrive peut etre tard mais prend sql2000 sans hesiter, 10Go c'est rien pour une base.
Aujourd'hui pour choisir un sgbd c'est plus une histoire de fonctionalité que de perfs sauf sur les tres grosses bases (>1000 Go).  
 
Pour les logs de sql2000, tu peux soit mettre l'option 'truncate log on checkpoint' qui va vider automatiquement le log tres regulierement, ou bien mettre une 'performance alert' qui va backuper le log sur disque des que son taux de remplissage est >60 % par exemple.