Version anglaiseVersion espagnoleVersion françaiseInscrivez-vous, c'est gratuit ! (mot de passe oublié)
- Samedi 26 juillet 2008 - 13:07:31
- inscrits : 890229
- connectés : 29452
- questions/jour : 4058
- Taux de réponse : 84.76%
Antivirus comparatif Comparaif sgbd Comparaison date sql Comparaison dates php Comparaison gps Comparaison mac pc Comparateur antivirus Comparatif antivirus Comparatif antivirus gratuits Comparatif appareil photo numerique Comparatif carte graphique Comparatif disque dur multimedia Comparatif firewall Comparatif gsm Comparatif home cinema Comparatif iphone 3g Comparatif iphone htc diamond Comparatif lg viewty Comparatif pc portable Comparatif plasma lcd Comparatif prix essence luxembourg Comparatif sgbd Comparer 2 fichiers excel Comparer deux string Lg kf510 comparatif SgbdPlus
Ils ont besoin de votre aide
- 13:06 changer les coordonnées du compte... (Messagerie/Chat)
- 13:04 Visual Studio 2005 Express (Programmation)
- 13:01 problème de selection de disque lors... (Windows)
- 13:01 Alarme sur ACER travelmate 800 (Matériel/Hardware)
- 13:01 cherche comment rétablir le pilote (Logiciels/Pilotes)
- 13:01 Activer la protection DEP (Windows)
Liste des forumsAidez-lesStatistiquesRechercherCharte
Plateformes d'assistanceDiscussions & Opinions des Communautés
|
|
|
|
Je voudrais faire une comparaison entre les SGBD suivants :
1) Oracle
2) Sql
3) Sybase
Pouvez-vous m'aider?
Merci d'avance
1) Oracle
2) Sql
3) Sybase
Pouvez-vous m'aider?
Merci d'avance
  eddy, le jeudi 17 juillet 2003 à 22:20:04Salut,
Je connais pas Sybase, mais il y a deja un probleme dans ta question; sql n'est pas un sgbd, c'est (comme son nom l'indique;) un langage de requetes. Si tu veux comparer des sgbd, je te conseille 2 endroits: - Ce site ;) - le site suivant: http://www.hds.utc.fr/~crozatst/ftp/nf17/ le dernier site est celui de mon prof de bases de donnees cette annee. Un certain nombre de documents seront inutiles (corrections d'exercices, de tp...) mais je te conseille: access.pdf, mysql.pdf, oracle.pdf, sgbdro.pdf qui decrivent les sgbd du meme nom. Les fichiers nx17*.pdf parlent de conception de base de donnees je crois, et web.pdf d'applications (php, java...) Sinon si tu as des questions plus precises, n'hesite pas... Bon courage, Eddy |
| yanban, le vendredi 18 juillet 2003 à 09:16:13 Je connais pas sybase.
Par contre Oracle est THE database et franchement SQL Server ne tiens vraiment pas la comparaison. Un argument simple et imparable? : SQL Server ne tourne que sur..microsoft alors qu'Oracle est dispo sur toutes platformes ( MS, autres unixes et linuxes...). Résultat ; Si tu prends SQL Server et ben t'es marié avec MS pour la vie, et qui te dit que (même) si t'es content de ton WIn2000 aujourd'hui, t'en seras content ds quelques années ?? Par contre avec Oracle tu fais un export/import..et hop, t'as changé de platforme!
|
Penser aussi à PostgreSQL et BerkeleyDB qui ont d'excellentes performances.
http://www.postgresql.org/ http://www.postgresql.com/ http://www.sleepycat.com/ |
| Maurice Pelchat, le lundi 17 mai 2004 à 21:21:53 J'ai fait une comparaison entre ces SGBD. J'ai utilisé Sybase, SQL Server et Oracle. J'ai fait une comparaison théorique entre PostgreSQL et SQL Server.
Si le multi-plate forme est ton premier critère, aussi bien t'enligner sur Oracle/Sybase mais ils sont dispendieux. Je ne sais pas si ils sont en train de reviser leur mise en marché. J'ai entendu dire que oui dans le cas d'Oracle. SQL Server et Sybase se ressemblent beaucoup sur l'interaction avec la base de donnée. SQL Server est un descendant philosophique de Sybase, en ce sens qu'il est né d'une association entre Microsoft et Sybase qui croyait ainsi se tailler un avenir via un entrée par la micro-informatique (l'équivalent micro d'Oracle à la même époque était affreux). Depuis ils ont mis fin à leur association, Microsoft a réécrit entièrement l'engin, qui roule très bien, et possède un excellent optimiseur de requête. Je ne sais pas si Sybase a bien évolué depuis le temps. Le langage de requête de SQL Server est très bien et est très prometteur pour la version SQL 2005. Il règle plusieurs problèmes qui datent depuis des lunes avec le langage SQL. Ce qui est bien avec SQL Server c'est qu'on peut indiquer précisément à l'optimiseur comment résoudre sa requête, lorsque l'optimiseur n'y arrive pas. Avec Oracle7 il y a des indices qu'on peut lui fournir, mais il n'écoute pas toujours. Avec Oracle8 et au dessus c'est à réévaluer. Avec Sybase je ne sais pas. Avec PostgreSQL la façon de contraindre l'optimiseur ne nous garantit pas le résultat. En ce qui concerne la performance, SQL Server se débrouille assez bien, même avec des très grosses BD. Au sujet de PostgreSQL, il ressemble à Ingres, avec des concepts intéressants. Cependant l'ordre de grandeur des investissements faits dans l'optimiseur de requête est faible en comparaison de ce que les produits commerciaux font. Donc comment se comporte son optimiseur face aux requêtes complexes est à démontrer. Si j'insiste tant sur l'optimiseur, c'est que le gros de mauvaises performances des applications utilisant le langage SQL viennent de mauvaises optimisations de requêtes. Un optimiseur qui rate plus souvent son coup te donnera plus de maux de tête. Une requête complexe bien optimisée fait plus rapidement le travail que les milliers de petites requêtes qu'il faut faire à la place. De plus cela t'évite de programmer les boucles de code et les structures plour stocker des résultats intermédiaires. Donc si ton serveur est capable faire l'algorithme d'obtention des données à ta place, c'est payant. Pour ça il faut qu'il soit capable bien optimiser ses requêtes. SQL Server possède pour diagnostiquer la partie requêtes d'une application, un excellent traceur de requêtes (avec filtres, plan d'accès, requêtes durées, deadlock etc etc. SVP). J'ai commencé à chercher l'équivalent dans PostgreSQL. Il ne semble pas y avoir d'outil équivalent. Un tel outil est essentiel dans le déboggage d'applications client-seveur. Cela permet qu'on puisse faire de la recherche de problème dans une application, sans qu'on ait à utiliser un déboggueur. J'ai cessé de travailler avec Oracle depuis la version 7. A l'époque il fallait acheter des produits complémentaires si on voulait faire facilement une trace des requêtes au serveur. En gros, sans cet outil, il fallait pas mal travailler pour faire l'équivalent du diagnostic qu'on arrive à faire avec SQL Server. Si on a besoin d'envoyer un scénario de trace à un client, c'est très facile avec SQL Server. SQL Server offre des outils de gestion très faciles à employer avec un céduleur de tâches de maintenance de la BD. Microsoft à l'avantage de n'avoir qu'à développer que pour Windows... Oracle et Sybase ont de moins bon outils. Peut être Sybase s'est amélioré depuis. Si tu as un petit environnement, MSDB c'est la version gratuite de SQL Server, sans ses outils graphiques (mais il existe du freeware qui le fait). MSDB est parfaitement compatible avec SQL Server parce que c'est SQL Server, avec un barrure sur la performance, à partir de cinq requêtes actives en même temps. En gros ça peut supporter une vingtaine d'usagers en même temps avec une très bonne performance. Ensuite c'est fait exprès pour ne pas aller trop vite. Microsoft veut vendre sa BD si l'application et votre clientèle sont gros. Un truc : vous vous achetez la version SQL Server developper edition, cela vous donne accès à tout comme développeur, et dans un environnement de développement. POur déployer l'application, vous pouvez utiliser MSDE si le client est petit, ou SQL Server Standart Edition s'il est gros. Un dernier point extrêmement important. La documentation. SQL Server possède une documentation en-ligne supérieure à ses concurrents. Cela est très important pour avoir le pourquoi et le comment de ce que l'on essaie de faire. Il y a beaucoup de sites pour avoir de l'aide et le SQL Server Magazine. Je crois que Oracle doit aussi avoir une grosse communauté de développeurs. La doc. de PostgreSQL est moins invitante. SQL Server est de loin le meilleur produit jamais développé par Microsoft. C'est un produit très stable. On peut trouver de temps à autre des gens qui se plaignent, mais c'est l'exception. Je crois pour ma part qu'il s'agit de gens qui ont des problèmes de compétence avec SQL Server, ou plus simplement avec le SQL. Sybase est sans doute plus "user-friendly" que Oracle, mais on s'inquiète un peu pour son avenir, sa part de marché semblant ne pas grossir très vite. PostgreSQL a une communauté intéressée à le faire progresser, il est vrai, mais je pense qu'il est douteux qu'il arrivent à le faire progresser aussi vite que les gros joueurs tels Oracle, Microsoft SQL Server, IBM (db2), tout simplement parce que ces trois derniers sont en grosse compétition, et qu'ils n'ont pas le choix d'investir leur revenus dans la progression de leur SGBD respectifs. Par exemple Oracle 10g est un gros investissement d'Oracle pour simplifier l'utilisation d'Oracle qui a toujours été pas mal plus compliqué à utiliser que SQL Server. A la base il a une plus vieille architecture avec beaucoup de boutons d'ajustements si on peut dire. Oracle est conscient de ce désavantage et essaie d'y palier. IBM travaille aussi en ce sens. La raison : Microsoft accroît sa part de marché à leur dépends. Mais dans les trois, le marché grossit, car les SGBD relationnels sont de plus en plus utilisés. SQL 2005 (la version bétâ) offre déjà pas mal de fonctionnalités qui vos assister le développement de services Web, le développement de requêtes, les traitements asynchrones, letraitement du XML et le dévelopement de code serveur. Je crois que les compétiteurs ont aussi des offres à faire de ce côté. C'est un marché en bonne santé. Comme développeur cependant et comme responsable du soutien je me sens plus à l'aise avec SQL Server. En dernier lieu, pour nous francophones, Microsoft supporte admirablement bien la langue française, aussi bien dans la Doc, que dans le logiciel, et surtout dans les règles de comparaison des caractères. Par exemple il est capable de rechercher dans la BD en faisant abstraction de l'accentuation et de la casse (comme Sybase aussi). Essayez de faire la même chose de manière performante avec PostgreSQL, Oracle ou DB2. On voit que Sybase / Microsoft SQL Server sont des produits bâtis sur une architecture plus récente. Les autres ont dû évoluer avec ce qu'ils avaient à la base. En dernier l'aspect intégrité/recouvrement des données est très simple avec SQL Server (on peut faire du point-in-time recovery) très facilement. Le recouvrement Point in time est souvent requis lorsque les usagers ont fait des erreurs de manipulation dans les productions de leurs application. Sybase permet quelquechose de similaire, mais je ne sais pas si il est aisé de le faire. Oracle aussi, mais c'est plus compliqué. En ce qui concerne PostgreSQL il n'en est pas fait mention dans la doc. Je dois dire à leur décharge qu'il me reste sans doute à approfondir mes lectures sur PostgreSQL. Mais à date, il ne semble pas y avoir de gros paragraphes la dessus. Ça me donne à penser que ça n'existe pas sur cette plate-forme, mais c'est à vérifier. Je ne parles pas de MYSql car il s'agit d'un produit qui a été conçu pour des besoins simples, mais à mon point de vue il est en dessous des autres, à moins que ce qu'on veut faire soit assez simple et ne risque pas de trop se compliquer.
|
| MP, le mercredi 2 juin 2004 à 15:12:45 Les 4 type de bases de données sont bien pourvues en types de données. Pour les champs très longs, il y a les types text et image de SQL Server/Sybase. Les champs de type text supportent une recherche par opérateur like (pattern matching) (mais non indéxé) comme le disait l'auteur précédent. Les champs de type text supportent le style de comparaison de caractères de SQL Server.
Oracle offre la notion de LOB et CLOB probablement pour les mêmes raisons. La prochaine version de SQL Server SQL 2005 supporte aussi la notion de colonnes de type XML. Ces champs seront aussi indexables et exploitable par des primitives XML. Si tes données CAO sont exportables en XML et qu'il y a des possibilités de les exploiter, ça peut devenir intéressant. La prochaine version de SQL Server, SQL 2005 introduit aussi des extensions au SQL extrêmements intéressantes dont les Common Table Expressions, les générateurs de valeurs séquentielles dans les résultats de requêtes, et des services broker (des trucs qui permettent le traitement distribué et asynchrone au moyen de queues de messages entre les serveurs SQL). Il y a aussi les reporting Services (récemment introduit dans SQL 2000). Ce truc permet de produire des rapports Web très riches en fonctionnalités, exportables en différents formats (.pdf excel xml), cédulables, sur demande ou automatique paramétrisables etc... Si j'étais à ta place, je n'hésiterais pas un instant à choisir SQL Server, sans compter que SQL Server est disponible en version gratuite (MSDE). Cette version diminue automatiquement sa performance passé 5 requêtes simultanées, mais c'est la même chose que la version standart. Evidemment si vous un petit projet ou un petit client, c'est une aubaine. Le hic c'est une version sans outils d'administration graphique. Cependant des outils d'administration gratuits existent pour MSDE. De toute manière l'administration par commandes SQL est relativement simple (backups / restore), même à partir d'une application. |
| yanban, le mercredi 2 juin 2004 à 19:51:19 Si jétais à ta place, je n'hésiterais pas une seconde à choisir Oracle.
Si l'argument donné au dessus ne te suffit, il en éxistent des centaines d'autres bien qu'il soit impossible de comparer fonction par fonction : les concepts eux-meême étant si different au départ ( par example chez Oracle il est TOUJOURS possible de lire une donnée, une lecture n'est jamais bloquée par un autre utilisateur en train d'écrire - pas le cas pour tous les sgbdr ;)). Mais honnetement, demande à n'importe quel admin quelle fiabilité il occordait aux OS Microsoft il y a 5 ans... la reponse sera rapide : aucune. MAintenant projete toi dans l'avenir et pense comment sérieusement tu pourrais affirmer que ds 5 ans tu continueras à utiliser un OS MS en production. D'ailleur rien que le fait de devoir appliquer un Patch sur l'OS tous les 15 jours et souvent devoir redémarrer le serveur et donc la base à simplement un impacte énorme sur les performances des bases puisque toute ta mémoir est vidée à cet instant. En réponse à MP, je lui dirait seulement qu'il y a autant de difference entre oracle 7 et 9i qu'entre Windows 3.11 et WInn 2003.... alors comparons ce qui est comparable (SQL server néxistait d'ailleur pas à cette épok lol ). Concernant les outils de backup, alors là, je préfere en rire car dire qu'Oracle n'est pas bon en backup/restauration, c''est quand même poussé le bouchon un peu loin maurice !! Meme chose concernant la doc : la doc Oracle est tout simplement sensationnelle (bien qu'en anglais) et dispo sur plein de sites avec également un service support paerformant et réactif et surtout des centaines de forums de haut niveau. A toi de voir si tu veux investir dans un produit sur lequel tu puisse compter, performant, leader depuis des années, où tes données seront sécurisées ou alors sur un produit que tu seras potentiellement obligé d'abandonner pour differeente raison ( OS trop pourri, MS décicdant de ne plus faire de développement dessus car pas asser rentables - d'ailleur pas d'évolution depuis la version 2000 alors qu'Oracle sort environ une version majeur par an- ETC ..... ) et pour lequel tu devras migrer ton application et tes données. |
C'est vrai qu'Oracle a investi en ingénierie dans leur SGBD plus que n'importe qui d'autre.
Le SGBD Oracle est l'un des logiciels qui totalise le plus de jour/homme de travail. Microsoft n'a débarqué que récemment dans les bases de données, et avec un sacré retard. :-) |
| Maurice Pelchat, le lundi 7 juin 2004 à 17:48:27 Bonjour à tous
Un peu de calme les amis Oracle. Mon but n'est pas de caler Oracle du tout. C'est un produit respectable et il y a beaucoup de gens qui l'utilisent. Et oui j'ai vu aussi des améliorations dans leur produit version 9i. Mais voilà quelle est mon impression. Avant la compétition de Microsoft, Oracle se traînait les bottes sur les standarts SQL (en autres les jointures ansi). Il a fallu attendre deux versions Oracle (8 et 9)après que Microsoft l'ait introduit. En ce qui concerne la question de l'OS quand SQL Server roule sur un serveur dédié on n'a pas de problème. On a beaucoup de clients qui roulent beaucoup de serveurs SQL Server depuis des années sans arrêt. On n'a pas à patcher un serveur SQL pour Outlook, ou Internet Explorer ou d'autres bébelles qui ne roulent pas dessus. On ne parle pas d'un cas de poste de travail. Mais on a raison de dire que dans en environnement ou on ne veut pas de période de maintenance que c'est ennuyeux. Remarque que dans de tels environnement on règle cette question avec du clustering. En ce qui concerne les backups / restore désolé de vous contredire. La processus est pas mal compliqué sur Oracle. Sur SQL Server un restore de BD n'exige de n'avoir personne sur la BD et de passer qu'une commande de recouvrement. Pour revenir en arrière à un point précis dans le temps, ce n'est guère plus compliqué. On ne se retrouve pas avec x fichiers d'archivelog à gérer. Je n'ai pas dit que le processus de backup restore d'oracle est pas bon, j'ai juste dit que c'est compliqué, et ça c'est pas pareil. Je suis persuadé que le processus de backup / restore d'Oracle doit être bon, puisqu'il est utilisé par des entreprises sérieuses et c'est la cas aussi de Microsoft SQL Server . SQL Server tourne aussi dans des grosses entreprises pour de grosses applications. Voir les études de cas : http://www.microsoft.com/resources/casestudies/FindCaseStudyResults.aspx?ProTaxID=1273 Les deux produits sont des produits matures et fiables, et le débat n'est pas là. Le débat doit porter sur l'adéquation entre vos besoins en évolution, la facilité de travail avec l'outil, et la grosseur de l'implantation que vous voulez faire. Si vous voulez faire roulez la bourse de Paris avec Oracle, vous ne faites pas un mauvais choix. Vous aurez aussi le moyen de vous payer les DBA, les coûteuses licences, et vous aurez l'avantage de choisir la plate-forme. J'ai eu de la formation d'un gars Oracle qui a été DBA en chef la bas et c'est ce qu'il y avait. On peut aussi faire du petit avec Oracle, mais c'est un plus compliqué, à moins de mettre l'archivelog de côté, ou de se programmer des processus de ménage de ces fichiers. Installez SQL Server puis installez Oracle et configurez-le cela en dit long sur cet aspect. SQL Server offre des procédures de maintenance automatique, Oracle offre-t-il quelquechose de ce côté maintenant ? Je ne le sais pas. En ce qui concerne le travail investit dans Oracle, il faut départager ce qui se fait au niveau du SGBD, et des applications Oracle, parce qu'Oracle c'est aussi une boîte d'applications. La partie applications Oracle draîne pas mal de gros d'investissements, et Oracle veut faire déborder ses affaires de ce côté (ex. ses tentatives d'acquisition de JD Edwards). Microsoft a une TRES grosse équipe de développeurs à plein temps sur le développement de SQL 2005, alors si on as appris qu'ils avaient l'intention de ne plus investir dans SQL Server, dites moi où on a pêché cela. Et ce n'est pas dans les fonctionnalités qu'ils annoncent qu'ils semblent avoir l'intention de mettre les freins. En ce qui concerne SQL 2000, il y ont ajouté les services de notifications et de reporting. Tous les gros développeurs de SGBD investissent massivement dans leur produits et la plupart auront des fonctionnalités toutes les plus intéressantes les unes que les autres. Pourquoi ? parce que le SGBD est un excellent moyen d'assurer sa présence dans l'entreprise. Tous aussi essaient de combler les lacunes comparatives qu'ils ont par rapport à leurs concurrents ou les distancer davantage dans leurs avantages. Donc souvent les impressions acquises il y a quelques années ne valent plus aujourd'hui. Par exemple DB2 essaie de rendre plus simple l'admin. de sa BD, et je crois que Oracle aussi, mais ils ont du chemin à faire de ce côté. Quand tu regarde le paquet d'options statiques et ésotériques qu'on trouve dans le fichier init d'Oracle, et l'évolution d'Oracle tu comprends deux choses: Il s'agit d'un gros produit bâtit sur une ancienne architecture. On investit sans doute dessus mais ils ont a vivre avec ce qu'ils ont fait au départ. C'est vrai que le versionning d'Oracle (lire des données antérieures à celles qui sont en train d'être modifiées par une transaction) est parfois un avantage (dans les rapports) et aussi un inconvénient. Il faut avoir eu des problèmes esotériques de rollback segments pour comprendre. Es-ce moins pire maintenant avec Oracle 9i ? Je n'en sais absolument rien. Nos connaisseurs Oracle peuvent se prononcer là dessus. Microsoft offrira une fonctionnalité équivalente activable sur option dans SQL 2005. Ça reste à comparer. On peut débuter avec Microsoft SQL Server et faire beaucoup de chemin avec sans problème. C'est tant mieux si les SGBD ont de plus en plus de fonctionnalités à offrir à toutes sortes de prix et avec toutes sortes de niveaux de complexité. Pour notre part on développe de grosses applications avec SQL Server, et les petites y sont aussi faciles à développer. Quelqu'un qui débute en SGBD se sentira très à l'aise avec SQL Server. L'outil est élégant et performant. Il faut pas comparer les produits à partir du passé car il ont évolués. En ce qui concerne la perennité de ces produits ces sont tous des produits qui sont là pour rester (SQL Server, Oracle, DB2) et ils vont tous conserver des parts de marché suffisantes pour continuer à progresser, avec leur supporters passionnées.
|
| yanban, le mardi 8 juin 2004 à 15:05:31 Bonjour,
Continuons donc notre comparaison Oracle/sql Server. J'avoue être fan d'Oracle (ceçi explique celà) et malheureusement ne pas ( vouloir) connaitre SQL Server suffisament sur certains points. D'autre part, je galere chaque fois à trouver des bon site, des bonne docs, des "white paper" sur SQL SERVER ce qui est dautant plus découragant. Passons. Pour reprendre, remarquez dans un premier temps que je parle uniquement de la version 9i, version sortie il ya maintenant pas mal de temps et que je ne parlerais même pas de la version 10G (sortie il y a environ 6 mois) car je ne la connais pas assez. Contrairement à vous qui parlez déjà de la 2005 pas encore dispo. Déjà, J'ai quand même un doute sur le fait qu'il puisse y avoir des Server Windows avec SQL Server dessus qui n'ont pas redémarrer depuis des années. Si c'était le cas, je suppose qu'ils auront de toutes façon à rebooter pour mettre la 2005.;) En parlant de Clustering, Oracle le supporte depuis la fin des années 80, avt même que NT n'éxiste! Cela me fait d'ailleurs penser à autre chose d'hallucinant sur SQL Server : le fait que lorsque vous voulez installer un nouveau Serveur SQL sur votre serveur, le programme d'installation vous demande d'arrêter tous vos autres Server SQL (sympa pour les base en prod, ça!) Pour les backup/restaurations, soyons honnête : la comparaison est impossible, tellement Oracle est en avance. UN peu compliqué? .. peut être mais le résultat obtenu n'est pas le même! Oracle permets (entre autre) : 1. D'utiliser la fonction Flasback : ce qui permet à UNE session (pendant que les autres utilisateurs continuent à travailler normalement) de revenir en arriere et donc par example de voir une table telle qu'elle éxistait il y a une heure (par example) pour eventuellement corriger par la suite d'éventuelles erreurs. ça c'est ce que l'on appelle multiversionning et "read consistency". J'avoue avoir des doutes sur ce que MS proposera...mais à voir. A propos de versionning, car ça c'est un point enorme, pourquoi ne pas faire le test suivant : create table test (a numeric) --> créer une table insert into test values (1) --> insérer des données Commencer une transaction : begin transaction update test set a=2 Maintenant, allez sur un autre poste ou lancer une autre session et faites : select * from test Mettez le chronometre en route. Résultat : sur MS SQL Server, vous attendez indifinement et ce uniquement pour pouvoir lire une donnée, sur Oracle la réponse est immédiate. Que montre ce test ? que MS (et d'autre, tel que DB2) a choisit la facilité alors qu'Oracle non. Résultat : concepts completement différent, retard irratrapable des autres. De la même façon, SQL Server pratique l'escalade de locks, car les lock sont des précieuses ressources sur MS et qu'il faut les économiser. Résultat : des données sont lockées sans raison. Sur Oracle , avoir un lock ou 1000 "coute" autant : absolument rien--> L'application est donc plus disponible. 3.Pour revenir au pb de restauration : Sur Oracle, on peut arrêter la base et restaurer l'ensemble à une date/heure inférieure 4.Mieux : ON peut aussi faire une restauration d'un tablespace jusqu'a un point dans le temps. C'est à dire : tous les utilisateurs reste connectés, on rends seulement indisponible certains fichiers ( ce qui ne bloque pas les autre) puis on restaure le(s) fichier(s) en cause jusqu'à la date/heure choisie. 5. On peut analyser les fichiers log pour voir quelles modifs ont été faites et eventuellement faire les modifs inverses. On récupere aussi le login utilisateur de la personne qui a fait la modif (rien a voir avec les possibilité d'Audit, qui s'ajoutent aussi à celà). D'autre pts sur backup/restauration : - Les fichiers redolog (ou transactions log pour MS) sont mirroirable sur Oracle. - Ils sont archivés automatiquement sur Oracle et manuellement sur MS ce qui implique l'utilisation de script ( pb en cas de modif de charge) - SUR MS Sql, en cas de perte de MSDB, il est nécessaire de récuperer le CD pour recréer MAster. Pour Oracle : un backup contient TOUT. - Oracle peut restaurer par block : si un block est corrompu, il n'est pas nécessaire de restaurer le fichier complet. ON peut uniquement restauré le block ( taille type 8ko), pendant que le reste du fichier est utilisé. ETC..... Les possibilités sont infinies et automatisable ce qui permets d'avoir le moins possible d'intervention utilisateur et donc de risque d'erreur. Pour répondre rapidement sur le fichier init d'Oracle : il permets d'avoir la main sur de nombreux parameteres dont l'allocation cyblée de mémoire. On ne peut pas sérieusement critiquer le fait qu'Oracle soit hautement configurable et laisse la main sur de nombreux parametres de tuning. De même ce fichier init existe maintenant en binaire, ce qui permets -entre autre- de modifier le montant de la mémoire allouée à chaque "pool" Oracle sans redemarrer la base ( toujours un souci de disponibilité maximum). Les rollback segment sont remplacés depuis la 9i par un tablespace d'undo et les erreurs presque chose du passé ( dejà le fait qu'elles éxistent auparavent était seulement lié à de la mauvaise administration). Je pense sérieusement qu'Oracle et SQL Server ne joue pas dans la même catégorie, et les points en faveurs d'Oracle sont vraiment nombreux. De ce fait la comparaison ne tiens même pas et on pourrait passer des jours à le prouver.C'est pourquoi j'avais ds un premier temps uniquement apporté comme point fort le fait qu'Oracle est dispo sur "tous" les OS. Que seront ces bases SQL Server, quand tout le monde changera d'OS ? (peut être pour LInux... ?) Plus d'info (objective ;) ) sur : http://otn.oracle.com/products/manageability/database/pdf/SSOracletechcomparison1.pdf |
| Maurice, le vendredi 11 juin 2004 à 21:51:16 Bonjour,
En réponse à notre dernier interlocuteur. Ne pas vouloir connaître une plate-forme n'est pas sage professionnellement. Les autres plate-formes ont parfois de bonnes idées et cela permet une comparaison plus nuancée en fonction de l'adéquation entre l'offre (ce que la plate-forme offre) et les besoins (les problèmes applicatifs qu'on doit résoudre). ---L'information sur SQL. Elle ne manque pas : Voici d'excellents sites de départ: http://www.winnetmag.com/SQLServer/ http://www.sqljunkies.com Le site d'acceuil SQL Server chez Microsoft offre toutes sortes de renvois dont des études de cas, et des grosses implantations SQL Server. http://www.microsoft.com/sql/ Et pour les white paper / astuces SQL Server : http://msdn.microsoft.com/sql/ En plus il y a l'excellente documentation électronique de SQL Server : Books Online qu'on peut directement récupérer de www.microsoft.com/SQL. Elle est en format .CHM Je ne reproche à personne d'être fan d'une technologie de BD particulière, les technologies de BD son devenues très intéressantes depuis les dernières années. Donc je peux vous comprendre d'être fan d'Oracle, moi même je fais encore des découvertes passionnantes sur SQL Server malgré mes dix ans d'expérience sur cette plate-forme. Chaque plate-forme offre ses avantages et ses manières de faire. ---Au sujet de l'installation de SQL Server. Installer un serveur SQL2000 ne demande pas d'arrêter l'OS et si votre intention est d'installer une nouvelle instance, il ne demande pas d'arrêter les autre instances SQL Server. Je l'ai déjà fait et le fait encore régulièrement. Etant de background Oracle, j'imagine que votre intention est d'installer une instance SQL supplémentaire. Avec SQL Server c'est moins nécessaire car un seul moteur SQL Server en mémoire supervise plusieurs databases. Le moteur Oracle est spécifique à un database. C'est une différence avec laquelle les experts des deux côtés savent tirer partie. De plus deux instances SQL Server peuvent rouler à des versions et services packs différents. Peut être que votre impression provient d'une expérience passée avec SQL7 ou sur NT. En parlant de Clustering, je reconnais qu'Oracle se vante d'offrir bien des option$$$ à ce sujet. Je pense que leur offre a ses mérites techniques, et qu'elle est aussi assez dispendieuse. Cependant en ce qui concerne les grosses implantations SQL Server (présentées sur le site de Microsoft) il y a des cas dont l'envergure est telle que 98% des développeurs n'auront jamais à toucher. ---Au sujet des backups restore. Pour ce qui est des backups restore, je réaffirme que la comparaison se fait très bien avec Oracle. SQL Server rend très simple la restoration à un point dans le temps. L'archivage des logs de génère pas une multitude de fichiers car il n'y a pas de nécessité d'avoir des redo log. En fait l'archivage des log est simplement l'affaire d'une simple commande SQL dont l'exécution est cédulé par l'agent SQL (un service qui roule en parralèle avec SQL Server). La commande SQL et sa cédule peuvent être générée via l'interface graphique de Entreprise Manager. La destination du backup partiel peut se combiner au fichier de backup total ou à un fichier de backup partiels, car SQL Serveur peut mettre plusieurs backups dans un même fichier et s'y retrouver. De même lors du restore il se rappelle où il a mis ses backups et génère les requêtes appropriées pour revenir à la version désirée de la base de donnée. ---La récupération de master / msdb. Votre prétention à savoir qu'une perte de MSDB demande de reconstruire la base de données master est complètement contraire à mon expérience. Cette base de données se restore comme les autres. En théorie je le savais et j'ai même essayé au cas en simulant sa perte. La reconstruction de la base de donnée master n'est requis que si l'on en perd les fichiers. C'est la même problèmatique que de perdre les fichier contrôle avec Oracle mais c'est plus simple sur SQL Server. SQL Server ne garde que peu de lien entre cette BD et les autres, de sorte que le retour en arrière sur master n'empêche pas l'instance SQL de fonctionner. Une fois les fichiers récupérés (soit par une copie valide faite après installation ou par reconstruction) on réapplique le backup le plus récent qu'on a. Même là on peut s'en tirer facilement sans backup très récent. La reconstruction du fichier master se fait en deux clic de souris. Il n'y rien là qui demande de s'arracher les cheveux. Une fois les fichiers reconstruits (une affaire de quelques minutes) on réapplique nos backups les plus récents. Il faudrait être pas mal négligent pour ne pas avoir de backup de BD, surtout qu'il est possible via l'interface graphique de mettre en place les backups automatiques avec gestion des fichiers sans écrire une seule commande SQL ou script. ---Le retour en arrière et l'intégrité. Si Oracle vous permet de revenir en arrière avec la fonction flashback (par exemple revenir en arrière d'une heure), c'est à condition que les fichiers qui contiennent cette information soit assez gros. Si une période de grosse activité produit de l'information en excédent de la capacité de ces fichiers un retour en arrière sera j'imagine impossible. Avec SQL Server on procède simplement à un restore du database sous un autre nom de BD avec du point in time restore du fichier de backup (total + partiel). C'est assez rapide car il n'y a pas de nécessité à installer une autre instance comme sous Oracle car SQL Server est multi-database. Dans ce cas là tu est sûr de trouver l'information. En ce qui concerne la possibilité de corriger une erreur passée, vous voulez sans doute parler de la possibilité de la diagnostiquer, de retourner en arrière et de reprendre le traitement. J'imagine mal quelqu'un affirmer être en mesure de jouer dans une table et de ne pas tenir compte que les modifications à cette table dépendent de d'autres règles d'intégrité référentielles. SQL Server permet une restoration partielle d'une base de données par filegroup et les filegroup ainsi restorés sont disponibles. Si on parle au futur (SQL 2005) il sera possible d'accèder la base de données encore plus rapidement avant même la fin du backup, mais cette affirmation me laisse perplexe car elle doit imposer des restrictions d'accès. C'est à voir... ---SQL Server 2000 n'offre pas la possibilité d' |