Discussion :

[new_angel]

Bonjour,

nous avons plusieurs petites bases de données sur plusieurs petits serveurs, nous voulons créer un serveur oracle contenant toutes ses petites bases.
Le serveur a 2 cpu (double corps), 16 G de ram et sera avec une baie disque, la question est la suivante :
Quel système d'exploitation utilisé ?

Deux solutions s'offrent a nous
-Red Hat Enterprise Linux je pense a la dernière version 5
ou
-Windows 2008

Pourquoi cette question, je suis administrateur système UNIX, et les autres personnes de mon équipe sont Windows, il serait donc plus facile pour eux d'administrer le serveur en mon absence.
Si vous pouviez argumenter vos réponses ;-)

les + en faveur de Linux :
-facilité de gestion des disques avec LVM
-Moins gourmand en ressource, enfin sans la couche graphique après je ne sais pas

les + en faveurs de Windows:
-IHM connue de tout le monde

Merci

[Kazevil]

Bonjour,

vaste question que le choix entre Linux et Windows Il y a de quoi alimenter un débat pour un bon moment.
Enfin, je vais essayer d'argumenter mon choix. Personnellement je suis clairement pour Linux.
Pourquoi?

• Oracle utilise Linux et Solaris comme plateforme de dévelopement. Ce qui, AMHA, garanti une meilleur qualité et un meilleur support (même si officiellement rien ne le dis, que bcp ne seront pas d'accord). Mais surtout les patch et versions sont disponible plus tôt sur ces environnements. De mémoire la 10.2.0.5 n'est toujours pas disponible sous Windows (ou depuis peu).
• Les environment de Type UNIX nécessite moins de maintenance. Je prend toujours comme exemple l'installation des nombreux patch Windows qui demande en général au moins un reboot du serveur et donc une interruption de service par mois. Dans la même idée, il n'y a pas besoin de logiciel Antivirus, qui mal configurer peut devenir des performance-killer
• Les services Windows sont à mon avis un gros moins sous Windows. En effet afin de se connecter à une base, le service windows doit être démarrer. Donc pour démarrer une base en mount il faut d'abord démarrer le service qui la mets en OPEN puis l'arrêter et la redémarrer en mount. par exemple lord d'un upgrade, le service tente de faire un open alors qu'il faut faire un startup upgrade. C'est mineur, j'en conviens, mais je trouve ça lourdeau.
• Encore dans la liste des services windows, le démarrage pour la première fois d'un listener crée un service. Si par exemple on veut juste faire un test on se retrouve avec un service qui traine et il faut "bidouiller" la base de registre pour le supprimer.
• La gestion de plusieurs ORACLE_HOME est mieux supporté sur les environnement UNIX, via le fichier oratab, que sur les environnements
  Windows
• Oracle et l'ensemble des bases et listeners sur le serveur sont gérés comme un seul Thread sous Windows. Dans le cas par exemple d'un serveur 32 bits, qui est limité à 4GB par thread, ça peux vite devenir compliqué. De plus la gestion sous UNIX par process, à mon avis simplifie et clarifie le suivi et la gestion
• Le système de LVM sous Linux permet d'être très flexible sur la maintenance des mount point et de les agrandir si besoin s'en avoir à mover des data files ou autres.
• ...
  
  Voilà les premiers points qui me viennent à l'esprit, mais comme dit cet avis est forcément partisan et pas à 100% objectif, je dois le reconnaitre.
  Maintenant pour travailler avec les 2 types d'environnements, je préfère personnellement ceux qui sont UNIX based.
  
  Cordialement
  
  Kaz

[Pomalaix]

Pour de petites bases, rien à mon sens ne s'oppose à Windows (pas de problèmes particuliers de gestion mémoire).
Donc ma suggestion serait de choisir l'OS le mieux maîtrisé par l'équipe, maîtrisé ne signifiant pas faire clic clic dans tous les sens sans rien comprendre.

Pour ce qui est des services, il y existe un sympathique utilitaire fourni en standard qui s'appelle SC, et qui permet fort simplement de supprimer un service par exemple. (Pour le démarrage d'une base en MOUNT, je trouve aussi que c'est lourdaud !). En tout cas, aucun bidouillage en base de registre n'est nécessaire.

Quant à la gestion des processus, il est exact que l'instance Oracle et les différents processus serveurs tournent dans un processus unique multithread, lesdits threads étant moins immédiatement visibles. Mais il suffit d'utiliser les bons outils. TLIST par exemple, les vues V$BGPROCESS et V$PROCESS, ou encore "l'assistant d'administration pour Windows" fourni en standard par Oracle, et qui permet de visualiser les threads, et même de les tuer si on le souhaite.
(Au passage, dire que "Oracle et l'ensemble des bases et listeners sur le serveur sont gérés comme un seul Thread sous Windows", ça s'approche d'un gros contresens).

Je ne vois pas en quoi le fichier /etc/oratab, dont l'usage n'est d'ailleurs pas obligatoire, permet de mieux gérer les oracle homes multiples.

Et en matière de stockage, pourquoi ne pas utiliser ASM ? Ca sera aussi transparent sous Windows que sous Linux.

[Kazevil]

Pour ce qui est des services, il y existe un sympathique utilitaire fourni en standard qui s'appelle SC

Ca c'est bon à savoir, merci pour l'info.

Pour ce qui est de la gestion de multiple Oracle Home en Windows comme tout est basé sur des clés de registre, il faut utilisé par exemple le HOME Selector.
Attention je ne dis pas que ce n'est pas possible, je dis simplement qu'une fois de plus c'est plus contraignant ou "lourdeau :-) que sous Unix.
Avec oraenv et oratab on gère ça de façon très simple en UNIX. Le fait que oratab ne soit pas obligatoire, ne veut pas dire qu'il ne soit pas pratique de l'utiliser.

De toute manière je ne peux pas vous donnez tord, comme je le disais ça reste un choix en fonction de ses préférences et compétences (plus Windows ou plus Unix). Quelque soit le domaine la question entre Pro-Windows et Pro-Unix est à mon avis sans fin.

Du coup le meilleur reste ce que vous avez dit:

Donc ma suggestion serait de choisir l'OS le mieux maîtrisé par l'équipe, maîtrisé ne signifiant pas faire clic clic dans tous les sens sans rien comprendre.

Kaz

PS: Aller pour la route je mets un dernier argument pro-UNIX
L'automatisation de tâches via des scripts!! Scripter en ksh reste plus puissant qu'en batch