Blog - comments

First, thank you for your interrest in this blog.Yes, the byte code will be interpreted each time bu...
BIEHLER Stephane
Pretty sure this is wrong:> already said that JVMs interprets the generated byte code - that's true...
Gs
Michael, great article, however, I would disagree on DRS/Host Affinity. You are legally only requir...
David Bradshaw
Hi lauri, db_file_multiblock_read_count is still used in exadata smartscan because it defines the si...
Hi Frank,Interesant article. But what does db_file_multiblock_read_count has to do with Exadata? As ...
Lauri
Blog Franck Pachot Oracle et Dbvisit Replicate pour migrer sans arrêt de service... et sans stress

dbi services Blog

Welcome to the dbi services Blog! This IT blog focuses on database, middleware, and OS technologies such as Oracle, Microsoft SQL Server & SharePoint, EMC Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on our blog postings.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.

Oracle et Dbvisit Replicate pour migrer sans arrêt de service... et sans stress

Je viens d'assister au Webinar Zero Downtime Migration pour Oracle, présenté par Chris Lawless qui est récemment passé de Product Manager Golden Gate à Product Manager Dbvisit.  Je vais détailler ici un point très important évoqué par Chris Lawless. La migration par réplication n'est pas seulement envisagée pour éviter un arrêt de service. Arrêt nécéssaire lors de la migration proprement dite (qui peut aller de quelques minutes à plusieurs heures en fonction de la taille et de la complexité de la solution) mais aussi pour les test avant la décision de Go-NoGo de réouverture du service sur la cible.

 

Migrer par réplication

Une migration par réplication, c'est d'abord pour éviter du stress, des coûts et du risque.

Un upgrade classique (dbua par exemple) a l'avantage de garantir l'intégrité des données sans avoir à impliquer les équipes applicatives: pas besoin d'avoir la liste des schemas, des synonymes ou db links, ni de vérifier s'il y a des opérations particulières (nologging) ou des types de données particuliers (XMLTYPE). Pas besoin de se poser des questions sur les triggers, les delete on cascade, etc.

Bien sûr les equipes applicatives seront impliquées pour les tests. Mais lors de la migration le DBA peut s'en occuper sans savoir ce qu'il y a dans sa base. C'est la raison pour laquelle c'est la méthode la plus utilisée. Il n'y a que lorsque la durée de l'arrêt de service peut poser un problème qu'on doit envisager une autre solution. Car un upgrade classique peut prendre une heure (suivant la taille du dictionnaire).

Une migration (lorsque il n'y a pas que la version d'Oracle qui change, mais le stockage, le serveur, la plateforme) peut être plus longue. Des solutions existent pour diminuer cette durée (Transportable Tablespaces, par exemple) mais bien sûr, l'opération sera plus complexe. Et plus complexe veut dire plus de temps, plus de risque, plus de stress.

Alors vient l'idée de migrer par réplication, sans arrêt de service, sans risque, sans stress.

Là, le DBA ne peut pas le faire à l'aveugle. C'est un projet à mettre en place avec les equipes applicatives pour déterminer quoi et quand répliquer. C'est d'ailleurs à mon avis un avantage: la migration est aussi une bonne occasion de faire un peu de ménage. Et pourquoi pas en profiter pour passer en UTF-8 aussi ?

Et il est de toute façon assez facile de tester si notre application supporte la réplication logique. Car bien sûr, le but n'est pas de passer 2 mois à résoudre des problèmes de réplication sur des triggers, contraintes on cascade, vues matérialisées, types de colonnes non supportés, etc.

Alors, pourquoi moins de risque et moins de stress ? Parce qu'on peut mettre en place la réplication sans déranger la production, et la laisser tourner plusieurs jours voir semaines. On ne va décider de basculer l'application sur la cible que lorsque tout est prêt et validé.

La migration se passe en 3 phases:

  • Mise en place de la réplication.
    Ne nécessite pas d'arrêt de service, seulement un bref verrou TM Share sur les tables pour s'assurer qu'il n'y a pas de données non committées au point de départ de la copie des données. On aura bien sûr préparé toute la configuration avant sur un environnement de test.
    Une fois le verrou posé et relâché, les données sont copiées puis la réplication s'applique.
  • Validation de la cible.
    Tout le temps nécessaire pour tester l'application sur l'environnement cible, avec des vraies données de production. On peut comparer les deux environnements pour vérifier la non regression. On peut valider les performances puisque la charge réelle de production arrive sur la cible. On peut même déjà y connecter les applications de production qui travaillent en read-only: reporting, exports,...
    Quand à la source, l'impact sur la production est très faible puisqu'il s'agit seulement de lire le redo généré, et ça peut être fait sur un autre serveur.
    Il n'y a pas de deadline pour ces tests autre que la date souhaitée de migration. C'est la grosse différence avec une migration classique où la durée des tests - avant de réouvrir le service - doit être à la fois rapide et fiable.
  • Basculement de la prod.
    Les applications vont maintenant se connecter à la cible. On va le faire en même temps pour que tout le monde voit toutes les mises à jour. Mais de toute façon la réplication est toujours là: aucune donnée ne serait perdue si on en oubliait une. 
    Ceci se fait sans stress vu que tout l'environnement a été validé avant, pendant plusieurs jours, sur de la production normale. C'est un arrêt de quelques secondes, le temps que l'application se reconnecte. Et là pas de surprise: l'environnement cible a été validé et optimisé bien avant.

 

Licence temporaire et support 12c

Chris Lawless a aussi répondu à deux questions sur les licences et sur le support de la 12c

Au niveau du coût, un produit comme Dbvisit Replicate, qui a déjà un prix de licence tout à fait correct, peut aussi se louer pour une durée limitée si on le souhaite: par exemple pour les 3 mois du projet de migration. Et la version trial de 30 jours peut même permettre de faire un Proof Of Concept sans frais afin de valider la compatibilité de l'application avec la réplication logique. 

Alors pourquoi ne pas passer 1 jour à tester la réplication de notre application ? Dbvisit Replicate peut s'installer en une heure et se configurer rapidement pour répliquer un schema en temps réel. Ce qui permettra d'évaluer la charge de configuration en fonction du nombre d'exceptions à gérer.

Oracle 12c étant une cible supportée, c'est une solution envisageable en venant de n'importe quelle version supérieure à 9.2. Une cible Pluggable Database n'est pas encore supportée, mais de toute façon, Dbvisit s'adresse surtout à des coûts réduits, en Standard Edition. 

 

Quand migrer en 12c ?

Alors, pour apaiser la peur de passer en 12c (peur historique des premières releases d'une nouvelle version), pourquoi ne pas répliquer sa prod 10g ou 11g pendant un mois (version trial) et tester tranquillement son appli sur la cible 12c avec des données de prod ? 

Rate this blog entry:
2

I'm a Senior Consultant, and Oracle Technology Leader at dbi services (Switzerland).


Certified DBA (OCM 11g, OCP 12c, Performance Tuning Expert, Exadata Implementation) I cover all database areas: architecture, data modeling, database design, tuning, operation, and training.


My preferred area is troubleshooting oracle and performance tuning, especially when I acheive to enable an efficient collaboration between the developers and the operational team.
Besides this blog, I participate in the Oracle Community in forums, blogs, articles and presentation.

All that is referenced from my twitter account:
 


    O_Database12c_Admin_Professional_clrOCE_ODb11gPerfTun_clr11gocm_logoalt

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Tuesday, 21 October 2014
AddThis Social Bookmark Button
Deutsch (DE-CH-AT)   French (Fr)

Contact

Contact us now!

Send us your request!

Our workshops

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

Expert insight from insiders!

Fixed Price Services

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

A safe investment: our IT services at fixed prices!

Your flexible SLA

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

ISO 20000 certified & freely customizable!

dbi services Newsletter