Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
choix: implementation oracle sous unix ou windows ?
slut ,
je dois faire une etude comparative concernant l'implementation d'oracle sous un systeme d'exploitation (windows ou la famille unix). Je n'ai pas de documentation en tant que telle pour qui me permette de le faire. Si possible , j'aimerai donc que vous me guidiez un peu sur les avantages et inconvenients des couples "oracle-windows" ou "oracle-unix".
merci; toutes les idées sont les bienvenues
Quel vaste débat et sources de préjugés +/- fondés que vous ouvrez là !
En tout état de cause, il serait bon que vous nous en disiez plus sur votre projet (architecture, contraintes opérationnelles, volumétrie, nombre d'accès concurrents, types de produit, ...)
Rien que pour la gestion des fichiers, je préfère Unix. J'aime pas du tout le passage par la base de registre et les services qu'impose windows... l'administration est, pour moi, beaucoup plus simple sous Unix
coté perf... j'ai pas vu d'énormes volumes sous windows mais les bases que j'ai vu fonctionnait très bien
sauf erreur de ma part le couple "Oracle-Unix" est historiquement le couple de Base pour ORACLE (developpé integralement en C depuis sa version 3)
et pour le reste j'ai la meme opinion qu'orafrance avec quand meme une preference pour UNIX .. mais ce jugement n'est pas du tout objectif (Vu que mon OS de predilection c'est ce dernier)
Historiquement le couple c'etait "Oracle-Vms"Envoyé par argoet
Et moi aussi j'ai le même opinion qu'ORAFRANCE. c.a.d (UNIX)
Je ne serais pas aussi catégorique
Si dans le cadre de ce projet, personne n'a de compétences UNIX, ou que l'ensemble du parc installé est constitué de PC/Serveurs Windows et si par ailleurs la base Oracle doit être en étroite coopération avec des produits n'existant que sous Windows...
par ailleurs, il faut voir la question des coûts des licences serveur et Oracle.
Bref, à mon avis, ça dépend réellement du contexte ! (d'ailleurs, si ce n'était pas le cas, je ne vois pas pourquoi Oracle developperait une version Windows...)
Oracle fourni une version Windows pour ne pas perdre de parts de marché. (notament les petites structures qui ne peuvent pas investir dans un serveur Unix)
Et pour l'exacte même raison, c'est Windows que je préfère, parce que sous Windows il est impossible de supprimer par erreur un fichier en cours d'utilisation.
J'ajouterai que mettre un serveur Oracle sous Unix oblige FORCEMENT les dba à avoir de bonnes compétences en Unix. Ca paraît évident mais quand on se retrouve avec des fichiers de données ne pouvant pas dépasser 2 Go parce que le serveur Unix a été (mal) configuré comme ça, ça saoûle !!
Sinon il me semblait que c'était sous Linux que les versions nouvelles sortaient en premier, mais je dois me tromper.
Et euh j'y pense, il n'existe aucun problème de format, de character set ou de chose comme ça (j'en ai jamais rencontré alors je ne pense pas, mais s'il en existe, il est bon de le savoir).
La première version Oracle est la V2 ( 1979) ne supportait pas les transactions.(Relational Software, Inc. ).
c'est en 1983 que Relational Software, Inc. devenue Oracle Corporation et à réalisé Oracle V3 sur Digital VAX/VMS.
Pour l'environnement UNIX c'etait en 1984.
c'est vrai mais on est pas sensé supprimer un fichier non plus mais je t'accorde que ça peut être pratique... sauf pour copier ces fichiers justementEt pour l'exacte même raison, c'est Windows que je préfère, parce que sous Windows il est impossible de supprimer par erreur un fichier en cours d'utilisation.
J'avais oublié l'essentiel : les process Unix sont parfaitement correllé avec v$process... sous Windows on voit juste Oracle.exe
Bien entendu, si personne ne connait Unix dans la société qui est déjà Full Windows, la migration parait dangereuse et surtout inutileBref, à mon avis, ça dépend réellement du contexte !
Et sous windows si l'admin a eu la mauvaise idée de faire une partition FAT32 ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part Ca paraît évident mais quand on se retrouve avec des fichiers de données ne pouvant pas dépasser 2 Go parce que le serveur Unix a été (mal) configuré comme ça, ça saoûle !!
En tout cas, je préfère largement les variables d'environnement à la base de registre
Quand je vois la galère du multi-home sous Windows alors que c'est réglé en une commande sous unix par exemple
Sécurité
Il y a aussi un aspect sécurité. Le monde windows est beaucoup plus attaqué par les pirates que le monde unix.
De ne jours cet aspect n'est pas à négliger !
Re: Sécurité
C'est ce que j'appelle une légende urbaine, c'est à dire une invention que tout le monde prend plaisir à raconter
En effet, pour qui c'est un peu intéresser au hacking et warez, il est acquis que les serveurs Unix sont autant la cible des hackers que les serveurs M$. D'autre part, un Windows correctement administré est extrémement complexe à pénétrer (les droits sur les répertoires existent aussi bien sous M$ que sus Unix). Enfin, il ne faut pas oublier que les firewalls et routeurs sont déjà un excellent moyen de se prémunir des attaques
Pour finir, la base de données (bah oui c'est quand même le sujet
Re: Sécurité
C'est pas tout à fait une légende : n'importe qui possède le mot de passe du compte administrateur va être capable de cliquouiller à gaucher et à droite en voulant bien faire pouvant ainsi faire une véritable passoire.C'est ce que j'appelle une légende urbaine, c'est à dire une invention que tout le monde prend plaisir à raconter
(... )
Par contre, même avec le compte root sous la main, il faut un minimum de connaissance pour faire des conneries sur le système ! ;-)
Donc, l'attaque vient de l'intérieur..... (comme toujours, d'ailleurs !)
Re: Sécurité
1°) Il faut commencer par admettre que la 1° régle de sécurité est violé puisque par définition les passwwords admin et root ne sont réservés qu'aux admins
2°) faut donc un chown -R oracle:dba . en étant sur / et tu va comprendre comme ça peut aller très vite
Si une personne veut s'attaquer à une bdd ou autre système, c'est surement qu'elle s'y connait déjà un peu.
Sinon ca serait vraiment par mégarde, et j'en passe.
Sinon suivant le contexte, les applis qui tournent autour, les besoins, ca peut etre l'un ou l'autre.
Après dans une PME, ca sera plutot du Windows que de l'Unix (cas vécu avec l'ERP Générix)
Ou tout simplement paske la dite société a déjà des licenses et serveurs M$ et donc ne veut pas s'éparpiller (ca se négocie aussi tout ça)
Je pense qu'oracle a été mis sous windows pour concurrencer MS SQL server, qui lui coute bcp moins cher, et vient de microsoft.
Après, y'a aussi Linux, qui demande aussi des bonnes notions sur ce système, mais à un cout moindre (sans parler du cout humain)
Bref, la plateforme dépend aussi de l'existant dans l'entreprise et de sa politique informatique .... et des finances
1) Sauf qu'il y a toujours un endroit où le mot de passe est stocké, ne serait-ce que pour le cas où l'admin passe sous un train ! :-/
2) Certes, mais chown -R oracle:dba, tu ne vas pas l'inventer tout seul comme ça ! il faut déjà à la base de connaissances d'Unix....
1- ABSOLUMENT PAS ! J'ai travaillé chez un client certifié ISO-(jesaisplus quoi pour la sécurité niveau banque) et tous les mots de passe étaient dans un coffre fort
2- bah le 1° venu n'arrive de toute façon pas à se connecter s'il n'y connait rien... sous windows il faudra connaitre le domaine et sous linux le nom de la machine... soyons sérieux, tu parles d'un cas impossible dans la vraie vie
1) Ah parce qu'un coffre-fort, c'est pas un endroit ?!et la clé du coffre a été jétée dans un puit sans fond ?
2) Mais il n'y a pas que de grosses structures avec des salles informatiques de plusieurs Ha dans la vraie vie ! Il y a aussi des entités plus petites où le serveur est dans une salle spéciale mais dans laquelle on ne te demande pas forcément ton empreinte rétinienne avant d'entrer....
Oué, mais y'a pas tjs des génies de l'informatique non plus dans ces sociétés.
Et généralement, tu vérouilles tout quand tu n'es plus là, sinon c'est sous ta responsabilité, donc au moindre pb, c'est toi qui prend tout dans ta gueule. (t'as fauté dans ton job en gros, licenciement faute grave !)
Répondre avec citation
Partager