Discussion :

[eristale]

Bonjour

Je suis en train de mettre en place un environnement de serveur BDD avec comme objectif de ne pas avoir de perte de données en cas de crash du serveur ou des disques.
Ma contrainte n'est pas d'avoir 2 semaines de rétention, mais plutôt de ne pas avoir de perte de données en cas de restauration.

pour comprendre le contexte, le progiciel qui utilise la BDD est un progiciel de gestion d’entrepôt avec préparation des commandes clients.
Imaginons, des colis qui se terminent et se positionnent sur le quai d'expédition. Et PAF, plantage crash.
La restauration sur un autre serveur doit impérativement indiquer les colis sur le quai et ne pas remonter 15 ou 20 minutes en arrière en indiquant que les commandes concernées ne sont même pas en préparation.

j'ai donc mis en place les archivelog et une sauvegarde RMan tous les nuits avec épuration des archivolg inutiles.

les procédures de sauvegarde et restauration fonctionnent bien. j'ai seulement un doute avec les redolog qui ne sont pas encore archivés.
parce que je vois bien que je lance des traitements avec le programme que je n'ai aucun archivelog de créé. Si j'ai bien compris, ils se créent quand le redolog est plein et que ça "switch" sur le groupe suivant.

La je coince car je ne trouve aucune info pour restaurer des redolog sur un autre serveur.
J'ai ajouté dans chacun des 3 groupes de redo un fichier sur un autre disque, avec les sauvegardes rman et archivelog.

NB : à la fin de la restauration, au recover database, il restore bien les archivelog , mais semble chercher encore autre chose.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
canal ORA_DISK_1 : restauration terminée, temps écoulé : 00:00:15
nom de fichier d'archivage=C:\ORACLE\ORADATA\E11B001\ARCHIVE_LOG\E11B001_1019305601_1_81.ARC, thread=1, séquence=81
nom de fichier d'archivage=C:\BACKUPORACLE\E11B001\ARCHIVE_LOG\E11B001_1019305601_1_82.ARC, thread=1, séquence=82
nom de fichier d'archivage=C:\BACKUPORACLE\E11B001\ARCHIVE_LOG\E11B001_1019305601_1_83.ARC, thread=1, séquence=83
journal d'archivage introuvable
journal d'archivage, thread=1, séquence=84
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: échec de la commande recover à 10/02/2019 10:11:24
RMAN-06054: la restauration physique requiert un journal inconnu : thread 1, séquence 84 et SCN de début 18181653

merci beaucoup si vous avez une piste.

[pachot]

Bonjour,

Oui, dans ce cas il faut pouvoir accéder aux online logs. Et donc, pour être vu par le nouveau serveur, ils doivent être sur un filesystem partagé.
Idéalement, la base serait sur un NAS et les fichiers accédés en DirectNFS. En cas de crash serveur, il suffit de monter les volumes sur le serveur de spare (sur lequel la même version d'Oracle est prête). En cas de crash disque, alors il faut restaurer les datafiles et archived logs à partir des backups et espérer avoit au moins un des membres des online logs disponible.

Recommendation: ne pas backuper les online redo logs. Car le risque est lors d'un restore d'écraser ceux qui contiennent les dernières transactions.

Bien sûr la meilleur protection pour cela serait Data Guard. En Enterprise Edition et il faut que le serveur de standby soit sous license. Mais il peut s'agir d'un serveur qui est déjà sous license, avec des bases de test par exemple.

Cordialement,
Franck.

[eristale]

Merci pour ce retour Franck

est-ce que dans mes étapes de restauration, je dois simplement recopier mes 3 fichiers redolog
dans le répertoire des DataFiles (la où ils étaient sur le serveur d'origine, dans la même arborescence) ?
entre les "Restore dataBase" et le "recover database" si dessous ?

je sais qu'il va me manquer mes 3 fichier redo log que j'avais sur le serveur d'origine qui était sur un disque partagé et qui faisaient parti des groupes 1 à 3.
mais ça je peux ajouter ajouter le retrait de ces 3 fichiers dans le script de restauration.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
RMAN> configure channel device type disk format "c:\BackupOracle\E11B001\%U";
RMAN> catalog start with "c:\BackupOracle\E11B001";
RMAN> Restore database;
RMAN> recover database;
RMAN> alter database open resetlogs;

Merci.

[pachot]

Oui, si les fichier redo sont au même emplacement, ils seront lus par le recovery.
Pour être s'ur de ne pas perdre des transactions, il ne faut pas mettre 'restelogs' dans le open. Si tout le redo est disponible (grâce aux online redo logs) la base doit s'ouvrir sand redo log: toutes les transactions commitées sont récupérées et la journalisation du redo continue é la sequence suivante, comme s'il n'y a vait pas eu de problème.
'resetlogs' c'est justement lorsqu'on a predu du redo, et donc des transactions, mais qu'on a pas le choix.

[eristale]

Impressionnant RMan, j'arrive à restaurer à la seconde près sans aucune perte.

Effectivement si dans chaque groupe de redolog j'ajoute un fichier que je positionne dans le répertoire de sauvegarde, je vois bien la restauration de 3 redolog après la restauration des archivelog.

NB : Ce qui suit c'est pour tester et valider la procédure, je n'en suis pas encore à mettre en prod.

Sur mon serveur le répertoire des sauvegardes RMan est "c:\BackupOracle\E11B001\"
le répertoire des archiveslog est aussi "c:\BackupOracle\E11B001\"
et donc les fichiers Redolog que j'ai ajouté aux 3 groupes sont aussi dans "c:\BackupOracle\E11B001\"

si sur un autre serveur je copie tout le répertoire "c:\BackupOracle\E11B001\" au même endroit avec la même arborescence, la restauration fonctionne parfaitement.

par contre si sur mon serveur de restauration, je mappe un lecteur réseau (j'ai partagé "C:\BackupOracle" sur le serveur de BDD) ça me donne le chemin "X:\E11B001"

ça ne fonctionne pas des la restauration du spfile

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
RMAN> set DBID 1744133395;                                                              
2> run {                                                                           
3>       set controlfile autobackup format for device type disk to "X:\E11B001\%F"; 
4>       restore spfile from autobackup;                                           
5>     }                                                                           
6> Quit;
exécution de la commande : SET DBID
exécution de la commande : SET CONTROLFILE AUTOBACKUP FORMAT
Démarrage de restore dans 03/10/19
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : SID=81 type d'unité=DISK
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20191003
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20191002
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20191001
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20190930
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20190929
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20190928
canal ORA_DISK_1 : recherche de AUTOBACKUP effectuée le : 20190927
canal ORA_DISK_1 : aucun AUTOBACKUP trouvé en 7 jours
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: échec de la commande restore à 10/03/2019 12:53:31
RMAN-06172: aucun AUTOBACKUP n'a été trouvé ou le descripteur indiqué n'est pas une copie ou un élément valide
 
Recovery Manager terminé.

c'est comme si il voulait que mon arborescence soit exactement la même que sur le serveur de départ.


Question subsidiaire : pourquoi il remonte à 7 jours ? pourquoi pas 30 ou 50 ?

[eristale]

Sur le serveur de BDD, je voudrai qu'il mette les archivelog, la sauvegarde et créer 3 redolog sur un disque mappé "S:"

"S" étant la lettre que je donne à mon lecteur mappé qui est un répertoire d'un autre serveur (tous les droits sont accordés).

mais quand j'active les archivelog sur ce lecteur, Oracle me dit que ce lecteur n'est pas accessible.
Idem pour la sauvegarde.

Peut-être qu'ils ne voient pas mon mappage "S" du fait qu'ils sont de service ou lance des services.

comment on fait dans ce cas pour que les redolog et archivelogs soient ailleurs qu'en local sur la machine où la BDD tourne ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Total System Global Area  835104768 bytes
Fixed Size                    2285832 bytes
Variable Size                  247467768 bytes
Database Buffers          578813952 bytes
Redo Buffers                    6537216 bytes
Base de données montée.
alter system set log_archive_dest='S:\Server-Dev-DB11\V10Loc01'
*
ERREUR à la ligne 1 :
ORA-02097: le paramètre ne peut pas être modifié, car la valeur indiquée n'est
pas valide
ORA-16032: la chaîne de destination du paramètre LOG_ARCHIVE_DEST ne peut pas
être traduite
ORA-09291: sksachk : unité non valide indiquée pour la destination d'archivage
OSD-04018: Accès impossible à l'unité ou au répertoire indiqué.
O/S-Error: (OS 3) Le chemin d’accès spécifié est introuvable.
 
Système modifié.
Base de données modifiée.

[pachot]

Je pense au'il faut utiliser le chemin UNC (\\serveur\share)

[eristale]

J'ai essayé aussi,
D'après ce que j'ai trouvé c'est un problème de droit, les services qui effectuent l'action, n'ont pas le droit de sortir sur le réseau.
J'ai basculé tous les service Oracle sur un compte utilisateur qui arrive à allez sur le réseau.

Mais toujours rien.

je suis coincé.