Discussion :

[Yorglaa]

bonjour,
j'ai une question qui me met la tête à rude épreuve...

contexte :

j'ai 2 bases de données sur un serveur et ces bases sont très fortement interconnectées au niveau transactionnel... plein d'infos passent de l'une à l'autre via des proc avec des DBlinks.

j'aimerais créer une stratégie de backups "à chaud" avec les 2 bases en mode archivelog.

mon problème :

comme ces 2 bases sont fortement inter-dépendantes, si l'une d'entre elle a un soucis et que je doive la remonter à un moment précis dans le temps (par exemple au soir d'avant avec des backups journalier "à froid") je devrais en fait le faire sur les 2 bases pour garder la synchronisation des données entre elles.

ma question :

si je mets mes 2 bases en mode archivelog pour effectuer des backups "à chaud", est-ce que je dois également synchoniser les mouvements de redologs entre les bases ? c'est à dire synchroniser les log switch et les archivages afin que, en cas de pépin et que je perde tout de même le log en cours j'aie un point de restauration synchronisé entre mes 2 bases ?

et si je dois faire ça de cette façon, comment faire cette synchronisation des log switch et des archivages y relatifs ?


merci d'avance pour vos infos...

[Pomalaix]

De prime abord, je ne vois pas comment on peut garantir que les basculement de fichiers journaux et leur archivage seront strictement simultanés dans les 2 bases.
On peut certes envisager de provoquer à intervalles réguliers un ALTER SYSTEM SWITCH LOGFILE, mais d'autres événements non planifiés risquent de provoquer un basculemement d'un seul côté.

Vous pouvez détailler ce besoin de "synchronisation" que vous avez entre les 2 bases ?
Est-ce juste un schéma de part et d'autre qui communiquent ? Ou n schémas d'un côté et m de l'autre ?

Est-ce des modifications qui sont reportées dans l'autre base dès qu'elles se produisent dans la première ? Parce qu'alors il faudrait peut-être envisager une réplication en bonne et due forme.

Enfin ce sont juste des réflexions à la lecture de vos indications...

[orafrance]

désolé j'ai pas tout lu

est-ce que tu as pensé au standby database ?

EDIT : Désolé, je crois qu'il n'y a pas de rapport en fait

Pour répondre : si les bases ne sont pas strictement identiques alors les données sont forcément désynchronisées. Les données communes peuvent être synchronisées (à quelques ms près ) mais quid des données autour ?

[Yorglaa]

Bonjour,
Alors je vais essayer de préciser mon contexte de "synchronisation"...

on peut qualifier mes 2 bases comme suit :

1. la base 1 est la base METIER qui contient l'appli "principale" de la boîte...
2. la base 2 est la base COMPTA (un ERP, mais que le module finance actuellement en activité)

la base METIER envoie vers la COMPTA des clients à créer (comptes débiteurs et créanciers) ainsi que des opération comptables, appelée "Décomptes" qui génèrent des papier-valeurs (chèques). Et une fois que ces "Décomptes" sont passés en COMPTA, ils prennent un statut ("Terminé") qui empêche toute modification ultérieure et/ou double comptabilisation.

la base COMPTA fait remonter vers METIER les infos de comptabilisation (ventilation comptable) de ces fameux "Décomptes". la COMPTA remonte également le détails des opérations "ouvertes" (factures) des clients, et ces informations sont capitales pour l'établissement des nouveaux "Décomptes". Ces factures ouvertes ne sont PAS FORCEMENT générées par METIER, mais peuvent être créées manuellement dans COMPTA.

donc mon problème si mes bases sont "désynchronisées" est :

1. si METIER est "remonté" à un point antérieur à COMPTA => nous aurons dans COMPTA des écritures comptables générées par des "Décomptes" METIER qui n'existent plus. Des clients dans COMPTA pas (plus) encore générés dans METIER et si on les recrée dans METIER, ils n'auront probablement plus les mêmes ID (sequences automatiques...)
2. si COMPTA est "remonté" à un point antérieur à METIER => nous aurons dans METIER des "Décomptes" en statut "Terminé" mais dont la comptabilisation n'existe pas/plus. Ces mêmes "Décomptes" auront pu être générés sur la base d'informations (factures ouvertes) provenant de COMPTA qui n'existent plus/pas encore

j'espère que je ne suis pas trop confu... ni trop long !

pour forcer la synchro des log switch, est-il possible de créer un trigger sur un événement système (le log switch au hasard...) qui pourrait à son tour lancer le log switch sur l'autre base ?

ou sinon la solution serait-elle de de mettre mes 2 bases en une ? Une seule base avec 1 schéma METIER et 1 schéma COMPTA... mais là ça va être sport en gestion des droit sur les users (qui évidemment n'ont pas les même droit sur les 2 appli)...ah oui pour aider encore un peu, notre base METIER est en mode CHOOSE et COMPTA en mode RULE (ordre du fournisseur)

voilà, n'hésitez pas à demander des infos si vous avez besoins... je sais que ce n'est pas évident !

et MERCI d'avance pour votre aide précieuse ...

[Yorglaa]

personne aurait même une petite idée ?

bouhouhouh...

[orafrance]

Une solution consiste à faire ces synchros via des triggers...

Ex : Tu crées un trigger sur la table de COMPTA qui doit passer le status à Terminé... dans ce trigger tu transmets l'info à METIER. Si la base se plante pendant le trigger alors le commit n'est pas fait -> l'action n'est pas prise en compte -> tout est synchro. Si la transaction arrive à terme avant le plantage -> pas de probléme.

Qu'en penses-tu ?

[Yorglaa]

excellent idée, je vais creuser...

et pour le trigger sur l'événement "log switch", ça existe ou c'est pas possible ?

[orafrance]

non mais du coup le switch n'a plus aucune importance puisque tout ce fait dans le même transaction

[Yorglaa]

oui c'est juste...

par contre selon ta proposition la transaction originelle globale se trouve sur METIER (et cela je ne peux pas le modifier), et le trigger sur COMPTA...

comment puis-je être sûr que le trigger de COMPTA a bien terminé son travail avant que la transaction originelle de METIER balance le commit (dernière opération de cette transaction) ?

[orafrance]

"la base METIER envoie vers la COMPTA des clients à créer"

le trigger est donc bien sur la table METIER qui va mettre à jour la table COMPTA (via DBLink). Si la maj de METIER est OK c'est que le trigger est OK aussi donc le COMMIT est faisable.

[Yorglaa]

en effet, pour les clients ça joue...

Mais mon problème ne se situe pas au niveau de la synchro des opération "courantes", ça fonctionne déjà bien... mon soucis est au niveau des backups...

le truc c'est juste que j'aimerais avoir mes 2 bases en mode ARCHIVELOG et que je ne sais pas comment synchroniser le log switch, supposant qu'en cas de crash je dois remonter mes 2 bases au même temps ' T ' et que si mes logs n'ont pas été archivés au même moment sur mes 2 bases et bien je n'ai pas ce fameux temps ' T ' synchronisé auquel je peux remonter...

à moins que je n'aie pas bien compris ce que tu essaye de me dire et là je m'en excuse par avance !!

[orafrance]

Ce qui importe (je pense) ce n'est pas que les bases soient sauvegardées exactement au même moment mais surtout que les infos inter-dépendantes soient synchronisées (i.e. : que les lignes de METIER soient bien dans COMPTA et vice-versa après resto).

Pour ça tu as 2 solutions :

1°) rendre synchrones les transactions portant sur des données partagées -> trigger

2°) synchroniser les bases après resto -> batch à lancer après la resto pour reconstruire les données

A mon avis c'est impossible de synchroniser les switchs à la milliseconde près et surtout à la transaction près... voila

[Yorglaa]

bon, et bien merci beaucoup pour ces infos...

je vais essayer de creuser le coup des triggers...

sinon juste pour info et en 2 mots, comment tu vois le coup des batch de synchro (principe), en loguant de manière externe (fichier plat) toutes les actions de la base ?

[orafrance]

Ha non, le batch ira vérifier l'état de tels enregistrements METIER et vérifiera que pour le même ID dans COMPTA les modifs ont bien été faites. Voir par exemple si des décomptes sont passés alors que le status n'est pas à "Terminé"... c'est bien plus compliqué mais à mon avis c'est quand même assez utile ce genre de batch... ne serait-ce que pour les vérifs lors des clotures comptables

[Yorglaa]

ah oui, en effet ça me plait bien...

donc si je résume, avec cette méthode je peux avoir mes 2 bases en ARCHIVELOG et si une des deux plante, je la remonte au plus proche avec les archives et le log courant (si je ne l'ai pas perdu) puis passe la proc de synchro adéquate qu'on peut résumer comme suit :

1. dans METIER : quel "Décompte" est en statut "Terminé" mais pas comptabilisé (et je comptabilise), quel client est là mais n'est pas en COMPTA (et je transfère) et quelle facture ouverte est référencée ici mais n'existe pas dans COMPTA (et je liste pour création manuelle dans COMPTA).
2. dans COMPTA : quel comptabilisation de "Décompte" j'ai pour une "Décompte" non "Terminé" ou non existant (je liste pour création et/ou update du statut), quel client "METIER" est là mais pas dans METIER (je liste pour création manuelle dans METIER) et quelle facture est référencée dans un "Décompte" mais n'existe pas ici (je liste pour création manuelle)

juste comme ça, à froid ça te semble cohérent ?

bon bien sûr le plus drôle reste à faire... les Procédures... mais c'est là que notre job devient intéressant...

[orafrance]

c'est exactement ça