Standby DB avec Oracle 8i

Bonjour,

J'aimerais juste une précision de fonctionnement de Standby DataBase sous 8i.
Est-il possible d'ouvrir cette SDB en écriture sous 8i ???

Chaque doc que je lis dise qu'il faut l'ouvrir en mode Read-Only.


Mon cas:
Une base de prod sur serveur 1 (base critique dont l'utilisation de la base pour les users ne doit pas être arrêtée)
Une SDB sur serveur 2

En cas de crash serveur 1, activation serveur 2. Seulement si la SDB est en lecture seule, les users ne peuvent plus écrire.

Y'a-t-il un moyen d'ouvrir cette SDB en écriture ???
Faut-il avoir une 2de instance sur serveur 2 pour basculer la SDB ???

Merci pour vos réponses ...

En cas de crash, vous voulez ouvrir la base de secours en lecture/écriture. Soit.
Mais comment voulez-vous que la base1, après réparations, redevienne opréationnelle tout en prenant en compte les modifications faites sur la base 2 ?

dans ce cas, c'est un fonctionnement en cluster qu'il vous faudrait, pas en standby.... :?

Questions sur le cluster oracle :
à ma connaissance, il ne duplique pas les données, uniquement l' instance
non ?

Pour Léo:

Pour rebasculer en base 1, je pensais à un cold backup de base 2, puis rebasculer sur base 1. (Possible ???)

(Autant, on ne peut pas se permettre l'arrêt de la base à n'importe quel moment, par contre on le peut en prévenant les users suffisament de temps à l'avance pour l'arrêter et faire les opérations de maintenance).

Quand au "cluster", je ne connais pas ce mode de fonctionnement, je vais donc y regarder d'un peu plus près ...

Quand à ma question principale: Peut-on ouvrir une SDB en écriture sous 8i ???
Est-ce que qlqun peut me renseigner, SVP ???

J'oubliais l'essentiel:
Merci pour les 1ières indications Léo et Ducho ....

Citation:

---

Envoyé par jflaman

Quand à ma question principale: Peut-on ouvrir une SDB en écriture sous 8i ???
Est-ce que qlqun peut me renseigner, SVP ???

---

Non.

Pour avoir acces en écriture il faut 'activer' la SDB qui du coup n'est plus SDB.

Une SDB ne peut etre ouverte qu'en lecture, et encore seulement s'il n'y a pas un 'recover' en cours

Merci Alain pour cette réponse claire. (Qui ne m'arrange pas ...).

Quand vous dites activer la SDB, il faut délier la SDB pour qu'elle redevienne une DB "standard". Dans ce cas, une sauvegarde des CTL avant de mettre la base en SDB suffit-elle ? , puis de remplacer les CTL SDB par ces CTL sauvegardés ? (J'espère que je suis clair ...)


Je tiens à préciser que si cette SDB doit être activée, c'est que la base principale à crasher. Donc par conséquence la SDB ne devrait plus recevoir les archives logs et ne devrait pas y avoir un recover en cours ?

Merci pour les réponses ...

Citation:

---

Envoyé par jflaman

Merci Alain pour cette réponse claire. (Qui ne m'arrange pas ...).

Quand vous dites activer la SDB, il faut délier la SDB pour qu'elle redevienne une DB "standard". Dans ce cas, une sauvegarde des CTL avant de mettre la base en SDB suffit-elle ? , puis de remplacer les CTL SDB par ces CTL sauvegardés ? (J'espère que je suis clair ...)


Je tiens à préciser que si cette SDB doit être activée, c'est que la base principale à crasher. Donc par conséquence la SDB ne devrait plus recevoir les archives logs et ne devrait pas y avoir un recover en cours ?

Merci pour les réponses ...

---

Si tu compte ouvrir en ecriture c'est pour y écrire..
Donc ta base stdb contiendra des données différentes, en admettant que la manipulation des ctl fonctionne, ce qui est plus que douteux, il se passera quoi a la prochaine arrivée d'archivelog ? un beau conflit..

Si il y a vraiement un besoin imperatif d'ecrire dans la deuxieme base, la technique standby n'est pas le bon choix

Citation:

---

Envoyé par ducho

Questions sur le cluster oracle :
à ma connaissance, il ne duplique pas les données, uniquement l' instance
non ?

---

Exact !
Récapitulatif sommaire des solutions de haute disponibilité :

RAC (cluster) : on a une base de données unique, sur une baie de disques partagée, et plusieurs serveurs sur chacun desquels tourne une instance.
Ces instances attaquent simultanément la même base, avec deux avantages principaux :
- la charge de traitement étant répartie sur les différents serveurs, l'application peut supporter un plus grand nombre d'utilisateurs
- si l'un des serveurs tombe en panne, la production n'est pas interrompue, la charge se reportant sur les serveurs restant disponibles

Base de secours (standby) : on a deux bases de données séparées, l'une étant la base active, qui reçoit les écritures, et l'autre, non accessible en écriture, se contentant d'intégrer les logs archivés issus de la base active.
En cas de panne du serveur hébergeant la base active, on opére un basculement sur la base de secours, qui devient celle active.
Cette formule constitue un gaspillage évident, puisque lorsque que tout va bien, le serveur de secours ne sert à rien.

OFS (Oracle Fail Safe) : cette solution, disponible uniquement en environnement Windows, est constituée de deux serveurs supportant chacun une installation Oracle (sans données), et d'une baie de disques partagée qui héberge les données.
Chaque base ne peut être gérée que par une instance à la fois. Cependant, rien n'oblige à avoir un serveur qui reste les bras croisés en attendant une éventuelle panne. Chaque serveur peut fort bien faire tourner ses propres instances, pourvu qu'au total, une base de données ne soit accédée que par une seule instance à un moment donné.
Si l'un des serveurs tombe en panne, le serveur restant en service prendra en charge les instances qu'il supportait en temps normal, plus les instances correspondant au serveur en panne.

Réplication multimaître : On a deux serveurs qui hébergent chacun une copie de le même base de données, et en assurent la synchronisation avec un léger différé.
Si l'un des serveurs tombe en panne, on se rabat sur l'autre.

Le comparatif de Fadace http://fadace.developpez.com/sgbdcmp/cluster/ est une excellente lecture sur le sujet !

Merci pour toutes ces indications.