Conseil répartition fichiers sur disques

[cheprod]

Bonjour,

Je dois bientôt monter une base Oracle 10g sur une machine qui possédera sans doute entre 4 à 6 disques (OS RedHat ES 5).

Il s'agira d'une petite base de données : moins de 50 tables, avec la plus grosse table à 100000 enregistrements. Les autres tables seront plus petites. Pour le moment, l'évolution de la volumétrie n'est pas connue mais aucune table ne devrait dépasser le million d'enregistrements.

Pour les utilisateurs, il y en aura au maximum 10 qui accéderont à la base via une interface Forms en lecture/écriture (en temps normal cela devrait être et 2 ou 3 en parallèle).

Il n'y a donc pas de gros besoin en performance par contre les données sont assez précieuses et il faut pouvoir remonter une base assez rapidement (En plus de la base principale, je pensais donc à mettre en place une base data guard sur une autre machine.)

Je me poser la question de comment répartir les fichiers sur les disque de
manière à avoir des performances correct (pour le confort des utilisateurs de l'IHM) et une sécurité optimale.

J'ai lu pas mal de doc sur internet et notamment :
http://asktom.oracle.com/pls/asktom/f?p=100:11:0:::11_QUESTION_ID:359617936136

J'ai peu d'expérience de la configuration physique et je pensais donc faire ce qui suit (si 6 disques disponibles) :

• Disque 1 : Système + Noyau Oracle
• Disque 2 : Redo 1 + Control 1 + Tablespaces system et sysaux
• Disque 3 : Redo 2 + Control 2 + Undo + Tablespace Tmp
• Disque 4 : Data
• Disque 5 : Index
• Disque 6 : Archivelogs + Sauvegarde RMAN

J'ai également la possibilité de regrouper des disques en Raid 0/Raid 1 ou Raid 5.

Que pensez-vous de la solution proposée? Merci d'avance pour votre aide

[LeoAnderson]

Quelles sont vos contraintes de performances ? de disponibilité ?
les SLA de recovery en cas de crash ? (rapidement, ça veut dire 2 minutes ? 2 heures ? 2 jours ?)
le type de matériel ? (disques IDE pour PC personnels ou disques SCSI pour serveurs professionnels ?)

Quel est la taille de chaque disque ? la taille de la base ? le volume attendu d'archivelog ?

Quelles sont les stratégies de sauvegardes ? les durées de rétention ?
les sauvegardes se feront comment ? disk-to-disk to tape ? disk to tape ? disk to disk ?

Quelle sera l'organisation de la base en termes de tablespaces ?

[cheprod]

Salut,

Pour les contraintes de performance, j'ai encore du mal à les définir... mais je pense qu'il y aura à peu près 10 row mise à jour par seconde grand maximum en période de pointe et en période de croisière, 5 mise à jour par minute.

Pour la disponibilité, c'est du 24/24 (avec pourquoi pas la possibilité d'arrêter la base le temps d'une sauvegarde à froid de temps en temps)

La plage de perte de données souhaitée serait inférieure à 5mn et le temps maximum pour le fail-over doit être de l'ordre de 30mn.

Les disques pourraient être des disques SCSI (15000 tpm) de 80Go.

La taille de la base est estimée à environ 10Go avec une montée en volumétrie à 30Go.

Pour le volume attendu d'archivelog, il n'est pas encore estimé. Comme la plage de perte de données voulue est inférieur à 5mn, est-ce que faire switcher les redo toutes les minutes a du sens (plutôt que 5mn) ?

En estimant la production d'un archivelog de 5mo toutes les 2 minutes, cela reviendrais à avoir environ 4 Go d'archivelog par jour.

Pour les sauvegardes, rien n'est encore bien défini. Sans doute sauvegarde à chaud RMan disk-to-disk quotidienne avec une durée de retention d'environ 1 mois.

Pour l'organisation de la base en terme de tablespace : 3 tablespaces pour les données (organisés en fonction de la taille des données) et 3 tablespaces pour les index (organisés également en fonction de la taille des données)

Merci

[LeoAnderson]

le taux de rotation des redo normal est de 3 à 4 par heure.
en aucun cas 1 / minutes ou toutes les 5 minutes
1 redo de 5 Mo, c'est vraiment petit. faut plus tabler sur 30~50 Mo en général au minimum.

disk to disk quotidiennne avec rétention d'un mois, sur une base de 30 Go => 30 * 30 = 900 Go de place sur disque. va falloir trouver d'autres disques !

Vu que votre contrainte n°1 semble la disponibilité, il faut jouer la sécurité :
Disque 1 : Système + Oracle Home
Disque 2 : Mirror disque 1
Disque 3 : Base Oracle (data & indexes + SYSTEM + TEMP + UNDO, control files & redo multiplexés sur les disques 1, 3 et 5)
Disque 4 : Mirror du disque 3
Disque 5 : Archive log + backups RMAN non encore copiés sur tape
Disque 6 : Mirror du disque 5

quelle est la version ? comptez-vous mettre en place le block change tracking ? faire des sauvegardes incrémentales ? différentielles ?

[cheprod]

Salut,

Merci pour la réponse

Pour ce qui est du taux de rotation des redo logs, je trouvais ça aussi un peu bizard mais j'avais l'expérience d'une base ou un dba a reglé un rotation toutes les 5 mn.

Pour la sauvegarde, c'est vrai que je n'ai pas réellement calculé mais que ça va vite devenir énorme. Je vais donc essayer de trouver une solution plus adapté. La version que je vais utiliser sera une 10g R2. Je ne connaissais pas le block change tracking car je bossais sur 9i avant. Je vais donc me pencher sur la question.

Pour la répartition des fichiers, cela me semble intéressant comme stratégie. Je vais m'assurer que le contrôleur Raid du serveur peut faire 3 groupes de disques en Raid 0.

Est-ce que le fait d'être en raid 0, permet de ne pas dupliquer le fichier de controlfile ?

Merci d'avance

[LeoAnderson]

non, mais en raid 0, il faut multiplexer les redo et control.
ça va déjà vous protéger d'un delete accidentel !

le block change tracking permet juste de faire plus rapidement les sauvegardes incrémentales/différentielles en loggant les blocks qui sont susceptibles d'avoir été modifiés.
mais on ne peut pas réfléchir à une architecture si l'on ne maitrise pas intégralement les besoins et les solutions de sauvegardes à mettre en oeuvre.

Commencez par clarifier ce point...

NB : un taux de rotation très élevé peut s'expliquer (et encore) dans le cas d'une base en standby physique où l'on ne tolère que très peu de perte d'activité transactionnelle.