Wiki

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

====== Gestion BD SQL de CESTAS ======

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

===== 1 - Deux processus =====

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**

=== 1 - 1 - Étapes du processus journalier ===

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

{{:tma:pv:procedures:processus_journalier.jpg?200|}}
=== 1 - 2 - Étapes du processus hebdomadaire ===

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 bases SQL restaurées sur le PCBACKUP
  * La suppression hebdomadaire des copies des BACKUPS copiés sur le PCBACKUP pour restauration
{{:tma:pv:procedures:processus_hebdo_1.jpg?200|}}

<WRAP download 60>
Le PPT d'origine de ces schémas est sauvegardé dans : P:\Projets\ARIRI0692- Schneider TMA CESTAS 2016-2017\4 Dossier technique\4.2 Documents AI\4.2.5 AT\2017\20170220_Stratégie_Sauvegardes_CESTAS\\
Nom: ''PPT_SV_SQL_CESTAS_V3.pptx''
</WRAP>

===== 2 - Détail processus journalier=====

=== 2 - 1 - Création des BACKUPS===

== Jobs d'encapsulation des deux bases PVDB+CCDATA dans SQL==
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.\\
{{:tma:pv:procedures:emp_encapsuation_cluster3.jpg?200|}}

== BACKUP créé dans le dossier F:\SQL\Backup_BDD du CLUSTER/MASTER==
 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.\\
{{:tma:pv:procedures:cluster_backup_rnonenomme.jpg?200|}}

=== 2 - 2 - Transfert des BACKUPS vers NAS===

== Renommage du .BAK avec date du jour ==
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.\\
{{:tma:pv:procedures:cluster_backup_renomme.jpg?200|}}
== Transfert du .BAK daté vers le NAS==
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''.\\
{{:tma:pv:procedures:transfert_nas_backup_all_bases_-_copie.jpg?200|}}

===== 3 - Détail processus hebdomadaire=====

=== 3 - 1 - Transfert des BACKUPS du NAS vers le PCBACKUP===
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''.\\
{{:tma:pv:procedures:transfert_nas_backup_all_bases.jpg?200|}}
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''.\\
{{:tma:pv:procedures:emplacement_prog_logs_transfertnas_backup_suppr.jpg?200|}}

=== 3 - 2 - Restauration des BACKUPS sur le SQL du PCBACKUP===
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''.\\
{{:tma:pv:procedures:emp.png?200|}}\\
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''.\\
{{:tma:pv:procedures:emp_procedures_stockees.jpg?200|}}\\
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''.\\
{{:tma:pv:procedures:emplacement_logs_verif_resto_bd.jpg?200|}}\\
Ces logs peuvent servir en cas de débug. Ci-dessous un exemple des logs.\\
{{:tma:pv:procedures:logs_resto_bd.jpg?200|}}
=== 3 - 3 - Vérification du contenu des 10 bases SQL restaurées sur le PCBACKUP===
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.\\
{{:tma:pv:procedures:logs_verif_bd.jpg?200|}}

=== 3 - 4 - Suppression des copies des BACKUPS ===
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''.\\
{{:tma:pv:procedures:emplacement_prog_logs_transfertnas_backup_suppr.jpg?200|}}\\

===== 4 - Emplacement sauvegarde programmes =====

<WRAP download 60>
Tous les programmes sont sauvegardés dans : P:\Projets\ARIRI0692- Schneider TMA CESTAS 2016-2017\4 Dossier technique\4.2 Documents AI\4.2.6 Sauvegardes\4.2.6.6 SV Prog Transferts Backups SQL
</WRAP>

===== 5 - Troobleshooting =====

En vérifiant les LOG de ''Req_TMA_Verification_DB.TXT'' (cf. chapitre 3 - 3 -), si:
===Les deux bases CCDATA+PVDB d'un CLUSTER/MASTER ne se sont pas restaurées===
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.

===La base CCDATA d'un CLUSTER/MASTER a bien été restaurées mais pas la base PVDB===
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).\\
  - 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.
  - 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.

===Le disque NAS n'est pas détecté par la tâche planifiée ?===
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.

===La taille des derniers backup est plus petite que d'habitude===
Cela arrive généralement quand le job n'as pas assez de place pour travailler.
Lancé l'observateur d'événement :
{{:tma:pv:procedures:lancer_obs_event.png?200|}}

Recherché l'erreur:
{{:tma:pv:procedures:obs_event.png?200|}}
Généralement il faut supprimer d'ancien backup qui n'on 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.

===Une étape fonctionne mal ?===
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.

{{tag>SQL CESTAS GESTION BD BAT PLANIFICATEUR TACHE WINDOWS BAK}}

Résumé

Wiki

Outils pour utilisateurs

Outils du site

Outils de la page