Discussion :

[philwood]

Bonjour, je ne suis pas un grand spécialiste des bases de données et d'Oracle en particulier.
Je dois mettre en place dans mon entreprise une solution de sauvegarde à chaud RMAN.
On me pose le problème de cohérence des données entre le tiers applicatif et la base de données en cas de restauration de l'ensemble du SI, certaine application écrivant des données hors base.
Je pensais opérer de la manière suivante :
Arrêt de l'application
Prise de snapshoot de l'application ( Sauvegarde du snapshoot en tache de fond)
Interrogation du SCN de la base de données application arrêtée.
Redémarrage de l'application
Ceci devrait assurer un minimum d'indispo (1 min max ).
Ma question est : si je restaure mon appli et ma base au n° de SCN appli arrêtée, est ce que je suis certain de retrouver une cohérence de mon SI ?
Est ce que le SCN d'une base correspond bien à une photo dans le temps de l'état de la base ?
Merci d'avance

[jkofr]

Hello,

Pas besoin d'arrêter l'application.
Tu peux réaliser une sauvegarde complète, différentielle ou incrémentale en ligne base ouverte pendant que les utilisateurs travaillent.

Se pose juste le problème de performance quelque peu affecté par la sauvegarde suivant ta configuration.

C'est quoi le but du snapshot de l'application? Explique.

jko

[philwood]

Et bien certaine application écrivent des données hors base comme par exemple des docs pdf, des jpg, ou même des données propres au fonctionnement du logiciel. Ces fichiers sont référencés dans la base mais sont stockés "hors base" sur un FS à part.
Du coup, si l'on restaure la base de données à un autre point dans le temps que l'application, on peut se retrouver avec des fichier référencés dans la base mais qui n'existent pas(plus) physiquement et inversement. D'ou incohérence.
Enfin, c'est ce que j'ai compris ...

[jkofr]

C'est bien comme Appli :-)


Tu est sous linux? quelle version d'Oracle?

jko

[philwood]

Oui, ce n'est pas moi qui choisi :-)

Nous sommes sur RHEL5 en 10g 11g

Que penses tu de l'interrogation du SCN de la base pour assurer la cohérence ?

[jkofr]

Pas évident de maintenir une cohérence exacte entre 2 volumes distincts à un timing donné.

Si tu restaure ta base à une version antérieure, tu ne vas pas avoir de problème de synchro, tu va juste avoir des fichiers pdf,jpg non référencés en base. Est-ce grave?

Dans un autre cas, tu aurait des références dans la base sur des fichiers qui ont disparu suite un crach et restaure de ton volume. C'est possible dans ton cas?

Je pense que tu devrais plutôt essayer de sécuriser le stockage.

Avec RHEL5 ASM est très bien supporté.

Tu pourrai faire différents volumes ASM
-DATA
-FRA
-DOCU

DOCU serait monté en ACFS

Chaque diskgroup en high redundancy sur des stockages différents.
Cela te donnerai une très bonne sécurité je pense.

jko

[pachot]

Bonjour,

Ma question est : si je restaure mon appli et ma base au n° de SCN appli arrêtée, est ce que je suis certain de retrouver une cohérence de mon SI ?
Est ce que le SCN d'une base correspond bien à une photo dans le temps de l'état de la base ?

Oui et oui.
Mais si pour une raison quelconque tu dois restaurer à un autre SCN le problème n'est pas réglé. Donc si tu une sauvegarde tous les jours tu peux perdre 24 heures de données

Du coup, si l'on restaure la base de données à un autre point dans le temps que l'application, on peut se retrouver avec des fichier référencés dans la base mais qui n'existent pas(plus) physiquement et inversement. D'ou incohérence.

L'appli peut gérer ça avec des règles du genre:
- toujours commiter l'enregistrement de la référence après avoir écrit le fichier
- avoir une procédure de nettoyage des références vers des fichiers inexistants en cas de restauration des fichiers à une version anérieure. S'ils sont perdus, plus besoin des références
- avoir une procédure de re-référencement des fichiers orphelins si on restaure la base à une version antérieure aux fichiers (peu probable) ou alors simplement les supprimer.
- si modification d'un fichier, avoir un numéro de version dans son identification pour éviter de pointer sur une autre version après une restauration.

Cordialement,
Franck.