J'ai une base 8.1.7 qui tourne sous NT 24h/24 7j/7 (en mode archivelog
donc).
Et l'objectif est d'en faire une migration en 9i sur un AIX sans bien sur
arrêter l'application !
Que me conseillez vous comme méthode afin de minimiser au maximum l'arrêt de
la base?
Je vois bien un export/import mais le pb c'est que entre le début de
l'export et la fin de l'import toutes les nouvelles transactions sur mon
ancienne base 8.1.7 ne se retrouveront pas sur ma nouvelle base en 9i? est
il alors possible de "rejouer" les redolog de la 8.1.7 intervenu entre le
début de l'export de la 8.1.7 et la fin de l'import sur la 9i ? Mais dans ce
cas comment connaitre PRECISEMENT à la milliseconde pres le début de
l'export de la 8.1.7 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno Jargot
On Wed, 16 Jul 2003 21:06:05 +0200, sgbd wrote:
Bonjour à tous,
J'ai un gros problème.
J'ai une base 8.1.7 qui tourne sous NT 24h/24 7j/7 (en mode archivelog donc).
Et l'objectif est d'en faire une migration en 9i sur un AIX sans bien sur arrêter l'application !
Que me conseillez vous comme méthode afin de minimiser au maximum l'arrêt de la base?
Je vois bien un export/import mais le pb c'est que entre le début de l'export et la fin de l'import toutes les nouvelles transactions sur mon ancienne base 8.1.7 ne se retrouveront pas sur ma nouvelle base en 9i? est il alors possible de "rejouer" les redolog de la 8.1.7 intervenu entre le début de l'export de la 8.1.7 et la fin de l'import sur la 9i ? Mais dans ce cas comment connaitre PRECISEMENT à la milliseconde pres le début de l'export de la 8.1.7 ?
-> Il n'est pas possible de rejouer des redo logs sur une base reconstituée par un export/import. -> Tu es obligé de faire un export/import vu que tu changes de plateforme.
Je ne pense pas qu'il existe de possibilités simple de réduire l'arrêt de la base.
Suivant le volume de la base, le coût de l'arrêt, la seule possibilité que je vois est : -> Poser un point de synchronisation au moment de faire l'export (par exemple en virant tout les utilisateurs, mettre la base en mode restrict, commencer l'export en mode consistent=y, rouvrir l'accès à la base) -> pendant que les utilisateurs travaillent sur l'ancienne base, effectuer l'import sur le nouveau serveur. -> une fois que l'import est terminé, fermer aux utilisateurs l'ancienne base et rejouer toutes les modifications qui ont eu lieu sur l'ancienne base sur la nouvelle. -> Ouvrir l'accès aux utilisateurs sur la nouvelle base.
La question est maintenant de déterminer quelles sont les modifications qui ont eu lieu sur l'ancienne base après le début de l'export. Cela devra être géré au niveau de l'application. Il faut bien connaitre l'application pour savoir comment déterminer les modifications (quitte à mettre l'application dans un mode "trace") ensuite il faut développer tous les scripts qui extraieront ces modifications de l'ancienne base et qui l'appliqueront sur la nouvelle base.
Après, il faut voir ce qu'il est possible de faire. Eventuellement, n'activer que les fonctionnalités que l'on est capable de tracer (mode dégradé).
Je ne vois pas d'autre solution. Du fait que l'ancienne plateforme et la nouvelle sont différentes (WinNT et AIX), il n'y a pas de possibilité d'utiliser les mécanismes de haute disponibilité de Oracle.
On Wed, 16 Jul 2003 21:06:05 +0200, sgbd wrote:
Bonjour à tous,
J'ai un gros problème.
J'ai une base 8.1.7 qui tourne sous NT 24h/24 7j/7 (en mode archivelog
donc).
Et l'objectif est d'en faire une migration en 9i sur un AIX sans bien sur
arrêter l'application !
Que me conseillez vous comme méthode afin de minimiser au maximum l'arrêt de
la base?
Je vois bien un export/import mais le pb c'est que entre le début de
l'export et la fin de l'import toutes les nouvelles transactions sur mon
ancienne base 8.1.7 ne se retrouveront pas sur ma nouvelle base en 9i? est
il alors possible de "rejouer" les redolog de la 8.1.7 intervenu entre le
début de l'export de la 8.1.7 et la fin de l'import sur la 9i ? Mais dans ce
cas comment connaitre PRECISEMENT à la milliseconde pres le début de
l'export de la 8.1.7 ?
-> Il n'est pas possible de rejouer des redo logs sur une base
reconstituée par un export/import.
-> Tu es obligé de faire un export/import vu que tu changes de
plateforme.
Je ne pense pas qu'il existe de possibilités simple de réduire l'arrêt
de la base.
Suivant le volume de la base, le coût de l'arrêt, la seule possibilité
que je vois est :
-> Poser un point de synchronisation au moment de faire l'export (par
exemple en virant tout les utilisateurs, mettre la base en mode
restrict, commencer l'export en mode consistent=y, rouvrir l'accès à
la base)
-> pendant que les utilisateurs travaillent sur l'ancienne base,
effectuer l'import sur le nouveau serveur.
-> une fois que l'import est terminé, fermer aux utilisateurs
l'ancienne base et rejouer toutes les modifications qui ont eu lieu
sur l'ancienne base sur la nouvelle.
-> Ouvrir l'accès aux utilisateurs sur la nouvelle base.
La question est maintenant de déterminer quelles sont les
modifications qui ont eu lieu sur l'ancienne base après le début de
l'export. Cela devra être géré au niveau de l'application. Il faut
bien connaitre l'application pour savoir comment déterminer les
modifications (quitte à mettre l'application dans un mode "trace")
ensuite il faut développer tous les scripts qui extraieront ces
modifications de l'ancienne base et qui l'appliqueront sur la nouvelle
base.
Après, il faut voir ce qu'il est possible de faire. Eventuellement,
n'activer que les fonctionnalités que l'on est capable de tracer (mode
dégradé).
Je ne vois pas d'autre solution. Du fait que l'ancienne plateforme et
la nouvelle sont différentes (WinNT et AIX), il n'y a pas de
possibilité d'utiliser les mécanismes de haute disponibilité de
Oracle.
J'ai une base 8.1.7 qui tourne sous NT 24h/24 7j/7 (en mode archivelog donc).
Et l'objectif est d'en faire une migration en 9i sur un AIX sans bien sur arrêter l'application !
Que me conseillez vous comme méthode afin de minimiser au maximum l'arrêt de la base?
Je vois bien un export/import mais le pb c'est que entre le début de l'export et la fin de l'import toutes les nouvelles transactions sur mon ancienne base 8.1.7 ne se retrouveront pas sur ma nouvelle base en 9i? est il alors possible de "rejouer" les redolog de la 8.1.7 intervenu entre le début de l'export de la 8.1.7 et la fin de l'import sur la 9i ? Mais dans ce cas comment connaitre PRECISEMENT à la milliseconde pres le début de l'export de la 8.1.7 ?
-> Il n'est pas possible de rejouer des redo logs sur une base reconstituée par un export/import. -> Tu es obligé de faire un export/import vu que tu changes de plateforme.
Je ne pense pas qu'il existe de possibilités simple de réduire l'arrêt de la base.
Suivant le volume de la base, le coût de l'arrêt, la seule possibilité que je vois est : -> Poser un point de synchronisation au moment de faire l'export (par exemple en virant tout les utilisateurs, mettre la base en mode restrict, commencer l'export en mode consistent=y, rouvrir l'accès à la base) -> pendant que les utilisateurs travaillent sur l'ancienne base, effectuer l'import sur le nouveau serveur. -> une fois que l'import est terminé, fermer aux utilisateurs l'ancienne base et rejouer toutes les modifications qui ont eu lieu sur l'ancienne base sur la nouvelle. -> Ouvrir l'accès aux utilisateurs sur la nouvelle base.
La question est maintenant de déterminer quelles sont les modifications qui ont eu lieu sur l'ancienne base après le début de l'export. Cela devra être géré au niveau de l'application. Il faut bien connaitre l'application pour savoir comment déterminer les modifications (quitte à mettre l'application dans un mode "trace") ensuite il faut développer tous les scripts qui extraieront ces modifications de l'ancienne base et qui l'appliqueront sur la nouvelle base.
Après, il faut voir ce qu'il est possible de faire. Eventuellement, n'activer que les fonctionnalités que l'on est capable de tracer (mode dégradé).
Je ne vois pas d'autre solution. Du fait que l'ancienne plateforme et la nouvelle sont différentes (WinNT et AIX), il n'y a pas de possibilité d'utiliser les mécanismes de haute disponibilité de Oracle.
