Discussion :

[Mothership]

Bonjour,

Nous utilisons Oracle version enterprise pour nos environnements SAP, developpement, qualité et production.
Nous atteignons une taille critique pour nos bases (environ 2To), limité par la taille des partitions nous profitons d'un weekend pour faire de grannds chambardements.
L'installation effectuée par notre prestataire a été plus que simple, puisque les control files, datafiles et redo logs sont tous sur la même partition. Les archivelogs ont bien été placés sur un autre disque.
En préparation de ce grand weekend, voici ce que nous comptons effectuer, si vous avez des remarques, n'hésitez pas car certains choix ne me paraissent pas évident...

2 partitions d'1To contenant le tablespace de production pour se donner du temps avant de devoir respliter l'ensemble .
1 partition concernant les tablespaces system, user, undo, sysaux, temp etc.
1 partition contenant les archivelogs, la moitié des REDO (1 membre de chaque groupe(4)), la moitié des controlfiles et des répertoires utilisés par SAP pour les sauvegardes et autres tâches d'administration(sapbackup, sapreorg...)
1 partition contenant la seconde moitié des REDO, la moitié des controlfiles

Cette architecture vous parait elle cohérente ?
Nous nous posons la question concernant une seconde destination pour le stockage de nos archivelogs, est ce préconisé ?
Nous sommes partagés sur ce point au sein de l'équipe, certains voient cette double destination comme un secours dans le cas ou le premier LUN serait mort ou plein pour permettre à la base de continuer à fonctionner
D'autres la voient plus comme un stockage longue durée des archivelogs pour restaurer vite en cas de besoin ...

Qu'en pensez vous ?

[petitfrere]

Ce sont des disks ou des partitions ?
si c'est des partitions il n'y a pas beaucoup d'interet de separer les tablespaces... les IO seront les memes ...


Pour les archiveslog utilisez vous rman pour la sauvegarde ?

[Mathias44]

Bonsoir,
sur quoi basez vous votre répartition ? Avez vous des mesures qui vous permettent de la déduire ? avez vous prévu une supervision des io et la possibilité de déplacer vos volumes sur des disques moins sollicites ? quel est votre gestionnaire de volume ? quelle est votre architecture san ? quel niveau de raid avez vous implémentée sur votre stockage ? avez vous envisage l'utilisation d'ASM ?
L'objectif majeur dans ce type d'operation est de lisser au maximum les io sur tous les axes d' écriture => préférez du stripping ou ASM.
En ce qui concerne les archivelogs disposer d une copie permet une sécurité en plus lors d' un éventuel recover si quelqu'un a malencontreusement détruit un ou plsieurs archivelogs. dans la pratique c'est assez rarement mis en œuvre. d'autre part vous gagnerez du temps en restaurant une sauvegarde régulière plutôt qu'en appliquant des "tonnes" d' archivelogs.

[Mothership]

Bonjour,

Tout d'abord merci pour vos réponses.
La répartition des datafiles est effectuée un peu dans l'urgence et donc au hasard, liée à la limite des 2To sur une partition Windows.

Pour la partie Disk/partition, chaque partition est en fait un LUN de notre baie SAN la plus rapide (IBM DS4800)
Nous ne faisons pas actuellement de remontée sur les IOs, les temps en base ayant considérablement chuté depuis l'acquisition de la nouvelle baie, la priorité n'a pas été placée sur ce facteur.

Pour la partie Archivelogs, je pense que mes collègues espèrent éviter le remplissage du répertoire des archives en le dupliqnat et en autorisant via cette commande je crois : et éviter un blocage inopiné en pleine nuit ou autre.
Actuellement nous sauvegardons via notre outil Data Protector (HP) qui a un agent oracle/sap qui fonctionne très bien. Nous effectuons actuellement nos sauvegardes en mode save_delete sur nos médias.
L'utilisation RMAN me pose pour le moment un problème car nous effectuons des rafraichissements d'environnements relativement souvent (ne serait ce que pour tester nos jeux de sauvegardes) et je n'ai pas encore trouvé le moyen de restaurer une base sur un autre environnement que celui sur lequel cette dernière a été backupée.
J'ai peu d'expérience en la matière, c'est pour le moment beaucoup de recherches et de lectures sur le net ... beaucoup de lignes à lire et peu de temps pour réellement les appliquer car mon premier métier tient plus des systèmes que des bases de données.

[petitfrere]

Pour moi l'utilisation de rman est indispensable lorsque qu'une base est mode archivelog.

comment voulez vous faire un recover des archives log a partir d'une sauvegarde tiers (Data Protector)

meme si c'est possible seulement les derniers archivelog seront utilisé, pourquoi tous les garder ?

Je me trompe peux etre et j'aimerais l'avis d'un expert, mais une base en mode archivelog sans une utilisation meme minime d'RMAN est quasi inutile.

Pour la repartition des tablespaces... on s'en fiche un peu c'est votre SAN qui va gérer les IOs surtout si c'est des LUN ... a confirmer....

[Mothership]

Pour la partie sauvegarde, nous utilisons une sauvegarde online_cons ...
lors du job, la base rentre en mode backup, sauvegarde les datafiles et les archivelogs nécessaire à la consistence de la base.

Nos archivelogs sont ensuite sauvegardés puis supprimés par une sauvegarde via un agent du même type.
Nous pouvons restaurer aujourd'hui les datafiles + les archivelogs sans utiliser les canaux RMAN.

Pour la partie datafiles/tablespace c'est uniquement pour sécuriser les données (une partition peut être endommagée et non récupérable) et donc répartir les différents éléments (controlfiles, archivelogs, datafiles etc.) mais aussi de limiter la croissance de notre partition et ainsi ne pas atteindre la limite des 2go.

[petitfrere]

OK ta sauvegarde est correct, les archives log sont donc reaplicable en cas de restauration mais je reste dubitatif sur la nécessité de garder tous les archives log ....


pour la partie datafiles/tablespace, c'est un SAN tu peux avoir plusieurs disk qui cassent sans qu'il y est de gros impact sur ton LUN, a la limite ton seul soucis c'est de repartir correctemment et proportionnellement tes datafiles dans l'un est l'autre unité logique. pour ne pas en remplir un plus rapidement que l'autre mais la tes le seul a le savoir


Pour les redo idealement il te faudrait 2 membres par group

duplication des archivelog...: mouais why not, c'est du luxe surtout si vous les gardez tous qui plus est sur un SAN

[pifor]

Je me trompe peux etre et j'aimerais l'avis d'un expert, mais une base en mode archivelog sans une utilisation meme minime d'RMAN est quasi inutile.

Faire des sauvegardes de base en mode archivelog existait avant RMAN et est toujours supporté même depuis l'existence de RMAN: c'est ce que la documentation appelle les "user-managed backups". Depuis l'existence de RMAN, la documentation tend de plus en plus à documenter RMAN et à documenter de moins en moins les sauvegardes et restaurations non-RMAN mais ce mode est toujours supporté même en 11.2:

Oracle Backup and Recovery Solutions

When implementing a backup and recovery strategy, you have the following solutions available:

*

Recovery Manager (RMAN)

Recovery Manager is fully integrated with the Oracle database to perform a range of backup and recovery activities, including maintaining an RMAN repository of historical data about backups. You can access RMAN through the command line or through Oracle Enterprise Manager.
*

User-managed backup and recovery

In this solution, you perform backup and recovery with a mixture of host operating system commands and SQL*Plus recovery commands.You are responsible for determining all aspects of when and how backups and recovery are done.

These solutions are supported by Oracle and are fully documented, but RMAN is the preferred solution for database backup and recovery. RMAN provides a common interface for backup tasks across different host operating systems, and offers several backup techniques not available through user-managed methods.

[petitfrere]

MERCI pour l'info

[13thFloor]

Pour moi l'utilisation de rman est indispensable lorsque qu'une base est mode archivelog.
...Je me trompe peux etre et j'aimerais l'avis d'un expert, mais une base en mode archivelog sans une utilisation meme minime d'RMAN est quasi inutile.

Sous SAP il doit utiliser brbackup, qui se base sur rman. Donc pas de souci coté sauvegarde.

les temps en base ayant considérablement chuté depuis l'acquisition de la nouvelle baie

Très intéressant (du raid ? des caches en pagaille ? du direct io ? ...) mais pas le sujet, dommage.

Archi : redo et archive au même endroit pas top. Ce sont des fichiers écrits chacun séquentiellement.
S'il s'agit de SAP BW, une partition dédié au TEMP n'aurait pas été superflu car c'est un tablespace très sollicité.
Si c'est de l'oltp, undo et temp peuvent cohabiter ensemble.

[Mothership]

Merci pour ces infos.

je pense qu'on est sur la bonne voie, comme je le pensais la double_archive_dest est loin d'être primordiale surtout sans garder un long historique.
Pour la partie SAN et les gains de performances, on est passé d'une baie surchargée de la génération n - 2. La nouvelle baie et l'ajout d'un cluster SVC (énorme cache) a littéralement fait gagné + de 100 ms sur la plupart des requêtes gourmandes, le peaufinage sur l'instance SAP a fait le reste.
L'impact a été vu sur les jobs, l'achivage, seuls les users n'ont rien vu (c'est que leur condition n'était pas si déplorable que ça).