Ce wiki explique comment est construite la gestion des BD SQL (CCDATA+PVDB) de CESTAS.

La gestion des BD SQL de CESTAS s'explique en 2 processus:

• Un processus de BACKUP journalier > en cas de perte brutale d'un serveur CLUSTER ou MASTER, seulement 1 jour maximum de données sont perdues
• Un processus de restauration hebdomadaire > afin de tester le contenu des BACKUPS créés

Le processus journalier consiste en :

• La création journalière de BACKUPS des 10 bases SQL des 5 serveurs de CESTAS (5 CCDATA+ 5 PVDB)
• Le transfert journalier de ces BACKUPS vers l'espace de stockage NAS

Le processus hebdomadaire consiste en :

• Le transfert hebdomadaire de ces BACKUPS du NAS vers le PCBACKUP
• La restauration hebdomadaire de ces BACKUPS sur le SQL du PCBACKUP
• La vérification hebdomadaire du contenu des 10 8 bases SQL restaurées sur le PCBACKUP. Les bases du master ne sont pas vérifiées.
• La suppression hebdomadaire des copies des BACKUPS copiés sur le PCBACKUP pour restauration

Ce job s'appelle TMA_BACKUP_PVDB_CCDATA, il se trouve dans l'agent SQL Server de chaque CLUSTER/MASTER : cf. image en dessous. Il s’exécute sur chaque machine à 23h00.

Le job TMA_BACKUP_PVDB_CCDATA créée ainsi un fichier .BAK dans le répertoire F:\SQL\Backup_BDD de chaque CLUSTER/MASTER : cf. image en dessous.

Le fichier .BAK est renommé daté suite à l'appel de la fonction .BAT Transfert_backup_SQL_v4.BAT par le planificateur de tâche.
La fonction .BAT Transfert_backup_SQL_v4.BAT se trouve également dans le répertoire F:\SQL\Backup_BDD de chaque CLUSTER/MASTER : cf. image en dessous.
La fonction .BAT Transfert_backup_SQL_v4.BAT génère également un fichier de log Transfert_backup_v4.LOG dans le répertoire F:\SQL\Backup_BDD qui peut servir au débug.

Une fois daté, la fonction .BAT Transfert_backup_SQL_v4.BAT déplace (action “couper-coller”) le .BAK dans le répertoire \\NAS\SV_SQL\SV_NON_TESTEES du NAS.
La réussite du transfert est enregistrée dans le fichier de log Transfert_backup_v4.LOG.

Le planificateur de tâches du PCBACKUP appelle à 08h00 simultanément 5 programmes .BAT qui vont chercher sur le NAS les .BAK du jour de chaque CLUSTER/MASTER, 5 au total, et les copier sur le PCBACKUP dans le dossier F:\SQL.
Les 5 programmes .BAT pour ce transfert s'appellent CLUSTERX_Transfert_NAS_to_BACKUP_v1.BAT. Ils se trouvent dans F:\SQL\Programmes_Transferts.
Ces 5 programmes .BAT de transfert enregistrent des logs dans le même fichier de log Transferts_NAS_to_BACKUP_v1.LOG. Le fichier de log se trouve aussi dans F:\SQL\Programmes_Transferts.

L'agent SQL Server du SQL du PCBACKUP appelle le job Restauration_Toutes_BD à 12h00 pour restaurer les 5 .BAK dans les 10 bases SQL nommées ARCHIVE_CCDATA_CLUSTERX ou ARCHIVES_PVDB_CLUSTERX.

Le job Restauration_Toutes_BD appelle la procédure stockée dbo.Restauration_BD_Toutes qui se trouve dans Bases de données système\Master\Programmabilité\Procédures stockées.

Le job Restauration_Toutes_BD enregistre des LOG dans le fichier Req_TMA_Restauration_BD_Logs.TXT dans le dossier F:\SQL\Requetes_Restauration_Bases.

Ces logs peuvent servir en cas de débug. Ci-dessous un exemple des logs.

L'agent SQL Server du SQL du PCBACKUP appelle le job Verification_Toutes_BD à 18h00 pour vérifier le contenu des BD toutes justement restaurée (étape 3 - 2 -).
Le job Verification_Toutes_BD appelle la procédure stockée dbo.Verification_BD_Toutes qui se trouve dans Bases de données système\Master\Programmabilité\Procédures stockées.
Le job Verification_Toutes_BD enregistre des LOG dans le fichier Req_TMA_Verification_BD_Logs.TXT dans le dossier F:\SQL\Requetes_Restauration_Bases.
Ces logs peuvent servir en cas de débug.Ci-dessous un exemple des logs.

Le planificateur de tâches du PCBACKUP appelle à 18h00 simultanément 5 programmes .BAT qui vont supprimer sur le PCBACKUP les .BAK restaurés la même journée. Ceci pour éviter d'avoir une accumulation de .BAK sur le PCBACKUP.
Les programmes .BAT de suppression s'appellent CLUSTERX_Suppression_SV_BACKUP_v1.BAT, ils se trouvent dans F:\SQL\Programmes_Transferts sur le PCBACKUP.
Ces 5 programmes .BAT de suppression enregistrent des logs dans le même fichier de log Suppression_SV_BACKUP_v1.LOG. Le fichier de log se trouve aussi dans F:\SQL\Programmes_Transferts.

En vérifiant les LOG de Req_TMA_Verification_DB.TXT (cf. chapitre 3 - 3 -), si:

Vérifier les logs de transfert NAS vers PCBACKUP : est ce que le .BAK a été trouvé sur le NAS ? Remonter ensuite la chaine jusqu'au CLUSTER/MASTER et voir où ça a bloqué en s'aidant des LOGs de chaque programme.

Vérifier la taille du .BAK qui a été restauré (on le retrouvera sur le NAS dans le dossier \\NAS\SV_SQL\SV_NON_TESTEES, bien s'assurer de la date du .BAK).

1. Si la taille du .BAK est toute petite, c'est que le CLUSTER n'a pas eu assez de place sur son disque F:\ pour créer une copie de CCDATA+PVDB : il a donc créé un .BAK ne contenant que CCDATA. Il faut alors libérer de l'espace sur le disque F:\. Si la place est prise par des .BAK qui s'empilent sur le CLUSTER, il faut contrôler les LOG de transfert du .BAK du CLUSTER vers le NAS.
2. Si la taille du .BAK est grande, c'est que le CLUSTER a bien créé un .BAK avec le PVDB et le CCDATA mais le transfert du .BAK vers le NAS a été tronqué. Il faut vérifier les logs du programme de transfert. Si on ne voit pas la fin du transfert, c'est que l'action du planificateur de tâche a arrêté le transfert (durée du transfert > durée maximale de l'action du planificateur de tâches) : il faut alors ouvrir le planificateur de tâches et les paramètres de l'action planifiée et augmenter le paramètre de durée maximale de l'action.

Ouvrir le planificateur de tâches. S'assurer que l'action planifiée utilise bien la session utilisateur en cours, qui lui octroie les mêmes droits et dossiers partagés que vous.

Cela arrive généralement quand le job n'as pas assez de place pour travailler. Lancé l'observateur d'événement :

Recherché l'erreur:

Généralement il faut supprimer d'anciens backup qui n'ont pas réussi à être transféré. Le problème se répète alors car il y a de moins en moins de place au fur et à mesure que les backup s'entassent.

Analyser les LOG de chaque étape. Tester des transferts, appels, restaurations en démarrant les jobs SQL ou en double-cliquant sur les programmes .BAT. Si une action .BAT fonctionne bien via une exécution manuelle, c'est que le problème vient d'un paramètre côté planificateur de tâches.