Discussion :

[Ooops]

Bonjour,

Je viens du monde dba sous unix/linux, et ma nouvelle mission est sur du full windows. J'ai une machine VMware windows 2003 avec un peu plus de 20 bdd dessus. Le vmdk du lecteur E provient d'une baie en raid 5. Tous les datafiles sont sous la même arborescence, genre (E:\oracle\database\SID1\..., E:\oracle\database\SID2\..., etc).


Si, en pratique, le raid 5 rassure un peu question sécurité, ça me laisse bien évidemment sur ma faim, notamment une erreur humaine qui ferait un delete malencontreux sur la racine e:\oracle\database et qui me flinguerait toutes les bases, ou autres joyeusetés du genre !
Et pour info, aucun soucis de perfs malgré cette archi (petites bases)

Je suis etonné, même chez oracle, de ne pas retrouver d'OMF windows qui soit comme sous linux, genre
/SID1_01/oradata
/SID1_02/redo
/SID1_03/oradata

qui permettent de bien étanchéifier les FS des bases ...

La seule chose qu'oracle préconise niveau OMF sous windows, c'est l'utilisation d'ASM, et pour plusieurs raisons on ne le mettra pas en place.

Ca m'étonne même tellement de ne pas trouver d'équivalent OMF unix que je tente ma chance ici, pour savoir si certains ont déjà eu à se poser le même genre de questions et comment ils ont résolus leur problème ? Ou peut-être une bonne idée ??

Une idée par exemple aurait été d'attribuer un lecteur par base, mais ca complexifie bcp l'administration de l'ingé système, on aimerait une autre solution ... comme sous unix quoi :-) ... ah, et évidemment, pas possible de partir sur du linux/unix ...

Je cherche à mettre en place une archi propre, simple et viable question évolutions (même archi pour les nouvelles création bases)


Merci pour vos réponses !
Ooops

[ducho]

Bonjour,

Déjà une petite indication sur Windows, aucun utilisateur ne pourra supprimer un fichier par idnavertance , windows protege les fichiers via les services.
Donc tant que le service est démarré, aucune suppression malencontreuse n'est possible contrairement à Unix / Linux ou un rm sous root est dramatique .

Je ne connais personne utilisant OMF sous windows .
Maintenant, personnellement je crée les dossiers correspondant aux sid de cette façon (pour que les non-dba sachent qu'il s'agit d'Oracle ):

d:\oracle\diag\SID_1\..
D:\oracle\Oradata\SID_1
D:\Oracle\Oradata\SID_2

idem pour les autres disques

maintenant les éditeurs de logiciels ont aussi leur méthode
Je préconise d'installer Oracle sur le disque C:\
les datafiles sur un autre disque
1 fichier de contrôle sur chaque disque

eviter de mettre un fichier dans Oracle_Home, c'est plus facile ensuite d'installer un patchset car depuis 11gr2 , un patchset= autre oracle_home,
(conseillé par Oracle)



cordialement

[Ooops]

Merci ducho pour ta réponse.

Je ne savais pas pour l'histoire du service qui empêchent les deletes des dbf. C'est un moindre mal en effet :-).

Je vais sans doute effectivement devoir me tourner sur une solution du type :

E:\oracle\oradata\SID_X\les dbf
F:\oracle\oradata\SID_X\le tempfile
G:\oracle\redo\SID_X\les redos
H:\oracle\arc\SID_X\les archiveslog

voire doubler les lecteurs pour mixer les SID sur un ou l'autre ...

Mais quand même, niveau étanchéité c'est (plus que) très moyen :

Si une instance déconne et rempli le H:\, le F:\, le E:\, elle va selon les cas me figer ou me faire planter toutes les bases de la machine ...
Evidemment, on va me sortir qu'il y a qu'a bétonner la supervision et tailler aux petits oignons chaque base, mais ça ne m'empêche pas d'être surpris du manque de souplesse du bouzin :-)

J'ai vu que windows 2003 & 2008 intégrait la notion de mount-point, peut-être une piste à creuser de ce côté la ?

[Pomalaix]

Hormis le fait que vous confondez OFA et OMF, j'avoue ne pas comprendre quel problème philosophique vous cherchez à résoudre...

[Ooops]

C'est pas de la confusion, OMF et OFA sont liés, mais si vous préférez parler d'OFA ça me va aussi ...

je cherche juste un moyen pour étanchéifier les FS des bases d'un même serveur windows ... comme ce que je fais sous unix. Et je suis très étonné de la difficulté que cela me pose !

[Ooops]

Pour info, je viens d'essayer avec les points de montage, c'était prometteur :

une partition E:
une partition E:\SID1_01\oradata (datafiles)
une partition E:\SID1_02\redo
une partition E:\SID1_03\oradata (tempfiles)
une partition E:\SID1_04\archivelogs

à décliner pour chaque SID sur le serveur, la une base peut remplir son FS sans planter les autres bases.

Sauf qu'on peut pas agrandir les partitions en cas de besoin (sauf la dernière contiguë à de l'espace libre) ...

[ecureuilmasque]

Vous devez pouvoir créer un utilisateur pour chaque base, lancer le service via cet utilisateur, mais j'avoue ne pas bien comprendre aussi votre problème.

Pour étendre un disque 'à la volée' sous windows, il suffit d'avoir des disques dynamiques.

[Ooops]

Je ne m'exprime certainement pas bien. Peut-être qu'avec un exemple ça serait plus clair ?

prenons 2 instances SID1 et SID2 (mais en vrai il peut y en avoir 1 vingtaine par machine)

je choisis la structure proposée par ducho, ex :
E:\oracle\oradata\SID1\*.dbf
E:\oracle\oradata\SID2\*.dbf
et les redo et ctl sur d'autres disques ...

imaginons qu'une requête (mal construite) sur SID1 génère tout d'un coup bcp de tri et fasse grossir le tbs TEMP au point de saturer l'espace disque sur E:\
=> Plus d'espace sur E:\, toutes les bases sur E:\ ne fonctionnent plus. Je veux simplement éviter cela. Sous unix, c'est simple, on définit un ou plusieurs points de montage par base, chaque point de montage a sa propre volumétrie, une base qui grossit anormalement n'impacte qu'elle même et pas les autres bases sur le même serveur.

[Pomalaix]

Si j'ai bien suivi, vous dites que votre espace disque provient d'une baie en RAID 5.

Dès lors, vouloir séparer fichiers de données, fichiers de contrôle et fichiers REDO n'est qu'une complication inutile, alors qu'un seul répertoire par base est suffisant.
Qu'attendez-vous d'une telle séparation ?


Concernant le cloisonnement des bases, là je comprends mieux votre préoccupation.
Pourquoi ne pas faire une partition par base (E:, F:, G:, etc) ?

Avec 20 bases, vous serez proche de la limite alphabétique, mais 20 bases sur une machine, ça paraît un peu bizarre. Il y a peut-être un manque de consolidation là-dessous, ou un besoin qui sera couvert par le mécanisme multi locataires d'Oracle 12c.

Et enfin, comme vous l'avez signalé, la supervision est un élément décisif.
Mettez de plus une limite d'autoextension à vos fichiers temporaires pour éviter les dérives.
(Il faut quand même rappeler que dans une base ordinaire, qui travaille avec des blocs de 8 Ko, un fichier ne peut pas dépasser 32 Go. Le risque de saturation accidentelle de l'espace est donc limité)

[Ooops]

Oouiiii voila, c'est exactement ma pré-occupation : le cloisonnement des bases, ce que j'appelais étanchéité des bases.
Ce cloisonnement, sur unix, je l'applique aussi au niveau d'une même base. Et donc pour répondre à votre question sur ce que ça m'apporte, cela me permet d'être plus fin dans l'admin de mes bases : ex en séparant sur des partitions distinctes le tbs temp et les autres tbs, des que la partition du tbs temp est rempli à 100%, seules les requêtes de tri partent dans les choux, la base reste OK. Si tout est au même endroit, c'est la base qui tombe. Ca me permet aussi d'être plus fin questions perf, puisque les partitions peuvent être sur des disques différents (ie des grappes raid différentes), mais ça je vous l'accorde dans mon cas actuel c'est la petite cerise sur le gâteau ...

Donc, oui, l'idée d'une partition par base est à creuser, même ça veut dire que je m'assois sur la répartition fine d'une base .... effectivement, un vmdk par lecteur me permettrait aussi d'étendre facilement en cas de besoin.

Mon admin système n'est pas très chaud par contre, il me dit qu'il ne sait pas comment va réagir windows, qu'il a jamais vu un serveur windows/oracle avec 20 lecteurs -genre c'est pas trop dans la philosophie de windows- et qu'on risque de devoir faire des benchmarks avant ... bref ...

Pour les 20 bases sur la même machine, oui effectivement ça manque de consolidation, c'est le moins qu'on puisse dire, mais c'est du aux différents éditeurs de produits, on ne peut pas faire grand chose à notre niveau. J'exagère un peu, je vais à terme répartir les bases sur plusieurs machines, mais je voulais quand même vérifier que je passais pas à côté d'une méthode propre à windows qui m'aurait fait me sentir comme ... sous unix :-)

Et enfin, oui je vais devoir être plus vigilant que d'habitude sur le sizing et la supervision, avec 2 ou 3 bases le sizing se fait presque tout seul, mais avec bcp de bases ... c'est moins simple ...

En tout cas, merci pour vos interventions, si d'autres idées vous viennent, n'hésitez pas à les partager ;-)