Discussion :

[tchalkost]

Salut à tous,

Voilà j'ai récemment travaillé sur la mise en place d'une base dupliqué et sur une base de secours. J'ai eu l'impression qu'il y avait pas mal de similitude entre ces deux méthodes, mais je n'est pas vraiment saisie la réelle différence.

En faisant l'étude j'ai surtout remarqué que les mises à jours entre ces différentes bases ne se faisaient pas de la même façon.

Et donc je voudrais savoir si vous pouviez m'aider à me dire la réelle différence entre ces 2 méthodes ?

[orafrance]

dans un cas tu rejoues les archive logs (ou les toutes les commandes passées si c'est une LOGICAL) alors que la base dupliqué doit avoir un mécanisme manuel pour synchroniser les données... là on peut pas répondre sans connaitre la startégie

[tchalkost]

Bah en faite la stratégie n'est pas compliqué, je veux avoir deux bases de données qui soient synchronisé. Au début on m'a orientée vers la duplication mais je me suis rendu compte que la base de secours répondait plus à mes besoins. Voyant que la mise à jour ce faisait automatiquement en rejouant les redologs. grâce au topic http://oracle.developpez.com/guide/s...eneralites/#L6

Justement je soupçonnais que la mise à jour de la base dupliqué se faisait manuellement mais je n'en était pas sûr. Bon ça me conforte dans le sens ou je ne me trompais pas dans mon raisonnement

[ariesnojf]

Si je peux me permettre,
la SDB ne pourra être lû en étant synchronisé automatiquement, il faut arreter le managed pour consulter puis de redemarrer le managed.
Ceci dit, la SDB est une solution génial (certain d'entre vous m'ont largement aidé à la mettre en place) mais depuis qu'elle fonctionne, c'est top. On a simulé un crash en réel, et la SDB est repartie en moins de cinq minutes ...

[orafrance]

Justement je soupçonnais que la mise à jour de la base dupliqué se faisait manuellement mais je n'en était pas sûr. Bon ça me conforte dans le sens ou je ne me trompais pas dans mon raisonnement

En effet, une base que tu synchronises avec les redos c'est une standby

[tchalkost]

Bah merci ça me suffit ces réponses. Super site à conseiller et à consommer sans modération.

[Pomalaix]

Si je peux me permettre,
la SDB ne pourra être lû en étant synchronisé automatiquement, il faut arreter le managed pour consulter puis de redemarrer le managed.

Avec le mode standby logique, on a (selon la doc, je n'ai pas eu l'occasion de le vérifier entièrement) pas mal de souplesse :
- application des archives pendant la consultation
- possibilité d'avoir des tables normales dans la base de secours, c'est à dire accessibles également en écriture

[remi4444]

Avec le mode standby logique, on a (selon la doc, je n'ai pas eu l'occasion de le vérifier entièrement) pas mal de souplesse :
- application des archives pendant la consultation
- possibilité d'avoir des tables normales dans la base de secours, c'est à dire accessibles également en écriture

+ possibilité de sortir certaines tables du processus

C'est vrai que c'est souple mais c'est un grosse usine à gaz, ça utilise logminer pour traduire les archives en requêtes puis ça applique les modifs par plusieurs processus en parallèles, outre les avantages que tu cite, il y a des gros inconvéniant (en tout cas en 9.2 je sais pas si la 10 a améliorés):

- Peu performant: car les requêtes sont jouées en mode sql (donc confronté aux éventuels problème d'optim...) et donc ça pédale pas mal dans la choucroute si on doit rattraper beaucoup d'archives, aussi il y a 9 process qui bossent en // pour faire le boulot, bonjout l'écroulement de la machine !
- Pas mal de restrictions (Pas de LOG_PARALLELISM, pas de LONG, pas de NCLOB, pas de type utilisateur, Pas de table organisée en index, pas de ceci, pas de cela... )

t'es toujours pas dégouté là ? bon je continue

- Obligation d'avoir une clause d'unicité sur chaque table (soit PK, soit unique-index, soit déclarer des groupes de colonnes qui feront office de clause unique)
- Des désynchronisations fréquentes. Exemple bête: si on crée un index sans le nommer, il va se retrouver avec un nom différent de l'autre coté....
- installation lourde : à propos de ce qui est cité plus haut et aussi parcqu'il faut installer tout le dictionnaire logminer.
- Reconstruction à chaud impossible (du moins officiellement). Normalement, il faut repartir d'une copie à froid des datafiles. Oracle a publié une amélioration mais il faut quand meme etre en mode exclusif à un moment. Perso, j'ai réussi au bout de 2 jours de galère à faire une vrai reconstruction à chaud en enchainant certaine commandes à toute vitesses dans un moment de calme, mais sans aucune garantie de synchronisation pafaite...
- Buggué: Regression dans la 9.2.0.7

Pour résumer, il ne faut surtout pas considérer une Standby Logique comme une sauvegarde de la base. Car contrairement à la Standby physique qui fait du pur recover, la stanby logique essaye tant bien que mal d'imiter toutes les actions de la base primaire.

Il ne faut donc choisir une standby logique par rapport à la physique qui si on y est vraiment obligé (mais alors vraiment! ). Et même, étant donné qu'elle doit être considérée comme une copie "applicative", je trouve qu'il vaut mieux carément s'orienter vers de la réplication (snapthots ou multi-maitres)