Surveiller la migration

Effectué

L’analyse, la journalisation et les diagnostics configurés lors des migrations de développement, de test et d’« exécutions sèches » constituent les composants les plus importants d’une migration VLDB.

Le déploiement de l’analyse et de l’interprétation nécessaires des résultats d’analyse et de diagnostic après chaque cycle de test est obligatoire et essentiel pour l’optimisation du basculement de la migration et de la planification de la production. Les résultats obtenus lors des migrations de test sont également nécessaires pour juger si la migration de production réelle suit les mêmes modèles et chronologies que les migrations de test. Les clients doivent demander des points de contrôle de révision de projets réguliers du partenaire SAP. Contactez Microsoft pour obtenir la liste des consultants qui ont démontré les compétences techniques et organisationnelles requises pour réussir un projet.

Sans l’analyse et la journalisation complètes, il serait presque impossible d’effectuer des migrations sécurisées, reproductibles, cohérentes et à faible temps d’arrêt avec une garantie de perte de données. Si des problèmes tels que de longs temps d’exécution de certains packages devaient avoir lieu, il est presque impossible pour Microsoft et/ou SAP d’assister avec des conseils immédiats sans données d’analyse ni documentation de conception de la migration.

Pendant le runtime d’une migration de système d’exploitation/base de code, surveillez les éléments suivants :

  • Paramètres au niveau du système d’exploitation sur les hôtes de base de données et R3load : processeur par thread, temps du noyau par thread, mémoire disponible (Go), page en entrée/s, en sortie/s, lectures d’E/S de disque/s, écriture d’E/S de disque/s, lecture disque en Ko/s, écriture disque en Ko/s
  • Paramètres au niveau de la base de données sur SQL Server cible : lignes BCP/s, BCP ko/s,% journal des transactions en %, allocations de mémoire, allocations de mémoire en attente, verrous, mémoire de verrouillage, verrouillage/blocage
  • Analyse du réseau : cela est normalement géré par l’équipe réseau. La configuration exacte de l’analyse du réseau dépend de la situation spécifique au client.

Au cours de l’exécution de l’importation de base de données, il est recommandé d’exécuter l’instruction SQL suivante à des intervalles de quelques minutes et de documenter tout ce qui pourrait être anormal (par exemple, des temps d’attente élevés).

select session_id, request_id,start_time, status, command, wait_type, wait_resource, wait_time, last_wait_type, blocking_session_id from sys.dm_exec_requests
where session_id >49 orderby wait_time desc;

Pendant tous les cycles de test de migration, un « plan de vol » qui indique le nombre de packages exportés et importés (axe y) doit être tracé sur le temps (axe x). L’objectif de ce graphique est d’établir un taux de progression attendu lors du dernier basculement de la migration de production. Écart (positif ou négatif) par rapport au « plan de vol » attendu pendant le test ou la migration de production finale est facilement détectée à l’aide de cette méthode. D’autres paramètres tels que le processeur, le disque et les lignes R3load/s peuvent être superposés par-dessus le « plan de vol ».

Capture d’écran d’un exemple de graphe de plan de vol montrant les packages importés et exportés pendant une migration de test.

À la fin de l’exportation et de l’importation, les rapports sur l’heure de la migration doivent être collectés (export_time.html et import_time.html).