Minimisation des temps d'arrêt planifiés pour les applications OpenEdge

Les éléments de maintenance de longue durée créent des ravages avec les utilisateurs qui tentent d'accéder au système lorsqu'il est en panne. Il existe des moyens de minimiser les temps d'arrêt pour la plupart des éléments de maintenance, ce blog vous l'expliquera plus en détail .

Si vous prévoyez une mise à niveau OpenEdge passez au cloud, migration de la plateforme, dump and load, ou tout autre projet majeur qui a la base de données en panne pendant des heures, il est important de commencer par quelques choses. Premièrement, il est important de comprendre ce qui nécessite des temps d'arrêt et combien de temps durera cette panne. Si la durée de l'indisponibilité dépasse la période d'indisponibilité acceptable, vous devez faire preuve de créativité pour raccourcir la période d'indisponibilité.

Supposons que le projet nécessite un vidage et un chargement de la base de données. Ce processus est généralement nécessaire lors du changement de plate-forme ou lors de la défragmentation de la base de données pour la rendre plus efficace. Il existe de nombreuses façons d'effectuer le vidage et le chargement et de nombreuses façons de l'optimiser pour la vitesse afin de limiter les temps d'arrêt. Dans un exercice de référence, j'ai utilisé la base de données d'un client et utilisé tous les outils disponibles pour OpenEdge pour tester les délais de vidage et de chargement. Voici quelques métriques pour la base de données et les résultats.

Statistiques de la base de données

Méthodes de vidage et de chargement comparées

• Dump et chargement de dictionnaire
• Dump de dictionnaire et chargement en bloc
• Copie du tampon d'une base de données à une autre
• Dump et chargement binaires

Processus des résultats

Vous pouvez voir que la méthode choisie pour effectuer le vidage et le chargement peut être dramatique impact sur les temps d'arrêt pour effectuer le travail. Cependant, cette base de données fait 36 ​​Go, ce qui est assez petit par rapport aux normes modernes. Et si la base de données faisait 100 Go ou 500 Go? Nous examinons maintenant des temps d'arrêt de 80 heures pour la méthode la plus lente et de 10 heures pour les méthodes les plus rapides. Gardez à l'esprit qu'il ne s'agit que de temps de vidage et de chargement, ce qui n'est qu'une partie d'un grand projet. Il ne tient pas compte des sauvegardes, de la vérification et des problèmes rencontrés. Très rapidement, ce temps d'arrêt peut atteindre plusieurs heures ou jours, même avec cette base de données relativement petite de 36 Go.

Si votre entreprise ne peut pas tolérer les temps d'arrêt nécessaires pour effectuer le vidage et le chargement, le résultat le plus probable est que le travail n'est pas effectué. La canette est renversée sur la route, espérant souvent que la décharge et le besoin de chargement disparaissent. Finalement, il vous rattrapera, probablement au pire moment possible. Il est peut-être temps d'envisager des approches originales pour le vidage et le chargement de la base de données.

Progress propose un produit appelé Pro2 qui permet la réplication vers MSSQL, Oracle ou OpenEdge. L'équipe Progress Professional Services a utilisé cet outil à plusieurs reprises pour effectuer un vidage et un chargement dans une autre base de données OpenEdge avec un temps d'arrêt minimal, quelle que soit la taille de la base de données.

Fonctionnement de Pro2

Le produit Pro2 comporte deux composants: Modifier les données Capture (CDC) et réplication. L'élément Change Data Capture utilise des déclencheurs de réplication ou Native CDC (11.7+) pour suivre toutes les mises à jour, les créations et les suppressions effectuées sur la base de données. Tous ces changements sont enregistrés dans une table appelée ReplQueue. ReplQueue ne copie pas l'enregistrement, mais note simplement l'enregistrement qui a changé et la nature de la modification (création, mise à jour ou suppression).

Le code de réplication examine le ReplQueue et traite les modifications, amenant l'enregistrement actuel à la base de données cible. Il s'agit d'un processus constant qui permet une réplication en temps réel. La jointure entre l'enregistrement source et l'enregistrement cible est le ROWID de l'enregistrement source. La table cible a un champ supplémentaire appelé prrowid qui stocke le ROWID source et il y a un index unique sur ce champ.

La valeur initiale de la base de données cible est effectuée par un processus de chargement en bloc. C'est là que chaque table est lue recto verso et les enregistrements sont copiés dans la base de données cible.

Comment Pro2 aide à réduire les temps d'arrêt de vidage et de chargement

Cette image montre comment Pro2 peut travailler pour créer une base de données fraîchement sauvegardée et chargée c'est la cible de la réplication Pro2.

Figure 1

La boîte 1 est l'endroit où la base de données de production actuelle s'exécute avec les utilisateurs connectés. L'encadré 2 est l'endroit où une nouvelle base de données reçoit des mises à jour de la base de données de production. Le processus de vidage et de chargement est accompli par le processus de chargement en bloc décrit ci-dessus.

La boîte 1 est l'endroit où la base de données de production actuelle est exécutée avec les utilisateurs connectés. L'encadré 2 est l'endroit où une nouvelle base de données reçoit des mises à jour de la base de données de production. Le processus de vidage et de chargement est accompli par le processus de chargement en bloc décrit ci-dessus.

L'effort pour remplacer la base de données dans la boîte 1 par la nouvelle base de données dans la boîte 2 est:

• Assurez-vous que la file d'attente de réplication est vide dans la boîte 1 [19659034] Arrêtez la base de données sur la case 1
• Supprimez le champ prrowid et index de la base de données dans la case 2
• Sauvegardez la base de données sur la case 2
• Restaurez la base de données sur la case 1
• Démarrez la base de données sur la case 1 [19659069] Pour la plupart des bases de données, quelle que soit la taille de la base de données, le temps d'arrêt sera de moins de deux heures, souvent de moins d'une heure.

  Traiter avec les clients Pro2 existants

  Les clients Pro2 ont un défi supplémentaire. Non seulement ils ont besoin de prendre le temps d'arrêt pour le vidage et le chargement sur leur base de données de production, mais ils doivent également prendre des temps d'arrêt sur la base de données cible pour le processus de chargement en bloc, puisque tous les ROWID ont changé sur la base de données source.

  When Pro2 est installé, le processus de chargement en bloc a tendance à prendre entre trois et cinq jours. Ce n'est pas un gros problème pour le moment car il n'y a pas de processus métier dépendant de la base de données cible. Avance rapide un certain temps et très rapidement cette base de données cible devient aussi critique que la base de données de production source, sinon plus critique. Une interruption de trois à cinq jours pour construire la cible Pro2 pour la plupart des clients est inacceptable.

  Pro2 à la rescousse (encore)

  Pour ces clients, nous pouvons à nouveau utiliser Pro2 pour créer un deuxième chemin, d'abord pour une autre base de données OpenEdge comme décrit ci-dessus, puis un chemin vers la base de données cible. L'image ci-dessous le montre. Il suppose une migration de plate-forme de HPUX vers Linux et une cible Pro2 qui est MSSQL.

  Figure2

  Dans l'image ci-dessus, les cases 1 et 2 existent. Nous construisons le chemin vers la case 3, qui est le vidage et la base de données chargée similaire à la base de données de la figure 1. Ensuite, nous construisons le chemin de la case 3 à la case 4. L'astuce pour que cela fonctionne avec Pro2SQL est d'activer la réplication de deuxième passe où la deuxième passe se réplique dans la base de données OpenEdge dans la boîte 3. Une fois le chargement en masse terminé pour la boîte 3, le chemin de la boîte 3 à la boîte 4 est créé et chargé en masse.

  Le processus de mise en service consiste à migrer vers les boîtes 3 et 4. le temps d'arrêt requis pour le basculement est le temps nécessaire pour supprimer le champ prrowdid et l'index de la base de données dans la boîte 3. le temps d'arrêt typique est inférieure à une heure.

  Conclusion

  Il est important de minimiser les temps d'arrêt nécessaires à un projet. Souvent, les fenêtres de temps d'arrêt sont petits et si un vidage et un chargement sont nécessaires, il est temps de faire preuve de créativité. Le traitement parallèle du processus de vidage et de chargement peut aider, mais peut ne pas être suffisant. Progress Services a très bien aidé les clients à limiter leur temps d'arrêt à quelques heures ou moins, en utilisant des outils spécialement créés à cet effet.

  > Si vous souhaitez en savoir plus sur OpenEdge, contactez-nous . [19659002] En savoir plus