Ceci est une ancienne révision du document !
Table des matières
Relance calculs end
Objet
Cette page décrit comment relancer les calculs END dans les solutions Kerwin et Conext Control.
Il est utile de relancer les calculs lorsque nous constatons une absence de données dans des rapports mensuels.
Kerwin
Principaux Lots
Ouvrir SQL Management Studio.
Exécuter la requête suivante:
USE [CALCUL_END]
GO
DECLARE @return_value int
DECLARE @date1 datetime
DECLARE @date2 datetime
/*Date de début*/
SET @date1 = '15/01/2018 00:00:00'
/*Date de fin*/
SET @date2 = '19/01/2018 00:00:00'
WHILE @date1 < @date2 BEGIN
EXEC @return_value = [dbo].[End_DailyJob] @date1
SET @date1 = dateadd(day, 1, @date1)
END
GO
Lorsque la requête a fini de s'exécuter vous pouvez retourner dans Kerwin, ouvrir le tableaux de bord correspondant et cliquer sur le bouton recalcul.
Pour les sites du Lot 1 et 2, il faut utiliser la base [Cal_END_MIN]
Pour le site de Caillan - Lot 4, il faut utiliser la base [End_DailyJobCaillian]
La requête “End_UpdateSynthMonthMn” est utile pour “forcer” l'exécution des calculs dans le cas d'Hi non valide par exemple
Solaire Direct
Pour les sites de Solar Direct, la procédure est différente : voir ci après.
Bien pensez à modifier la date et à choisir les bons sites dans les requêtes.
A chaque fois que l'on lance la procédure de calcul de l'END, une nouvelle ligne s'ajoute dans le rapport pour la date de calcul.
Il peut donc y avoir plusieurs lignes pour la même date dans les rapports.
Il est donc nécessaire d'effacer dans un premier temps les données pour la date souhaitée avec la procédure suivante : (exemple pour la date du 07/03/2015 et pour le site Les Mees 2)
DELETE
FROM [KERWIN_SQL].[dbo].[LM2_AlDebutFin] where [Date_debut] >='01/05/2018 00:00:00' and [Date_debut] ⇐ '07/05/2018 23:59:59'
DELETE
FROM [KERWIN_SQL].[dbo].[LM2_DebFinToJour] where [Date] >='01/05/2018 00:00:00' and [Date] ⇐ '07/05/2018 23:59:59'
Vérifiez que la suppression à la date indiquée a bien été effectuée en remplaçant “DELETE” par “SELECT *” dans la requête précédente : aucune ligne ne doit être présente.
Ensuite, vous devez modifier les 2 procédures “Daily job Run” et “Up Alarm” pour chaque site dans:
Pour les sites de LM1 et LM2: Kerwin_SQL → Programmability → Stored Procedures pour les sites de LM1 et LM2
- LM1/2_DailyJobRun et LM1/2_UpAlarmes
Pour le site de Vinon: Kerwin_SQL → Programmability → Stored Procedures
- AK_VinDallyJobRunTest1 et AK_VinupAlarmes pour Vinon
Pour Vinon, seulement la date @d est nécessaire (pas besoin d'ajouter de Trigramme type 'SAR' en rejouant les calculs)
Pour Vinon, seulela requête “Up_Alarmes” est à modifier
Pour les autres sites: CALEND → Programmability → Stored Procedures pour les autres sites
Pour le site de Nohic, c'est les fichiers NON.
Sur ces procédures, il faut mettre à “1” (manuel) le paramètre @DailyJobManualActive en haut des deux procédures “Daily job Run” et “Up Alarm”:
Exécuter ensuite la procédure pour enregistrer la modification.
Ensuite relancez la procédure de calcul de l'END :
declare @d datetime
set @d = '07/03/2015'
exec [KERWIN_SQL].[dbo].[LM2_DailyJobRun] 'LM2',@d
Vérifiez dans le rapport qu'une seule ligne pour chaque jour apparait.
Pour finir, il faut repasser les fichiers précédemment décris en “0” (automatique), n'oubliez pas d’exécuter la procédure pour enregistrer la modification.
Attention ,cette dernière étape est important, ça permet aux Jobs SQL journaliers de s’exécuter.
Conext Control ( lot 6 )
Se connecter sur la machine Schneider18 (=ClearScada)
- Le fichier C:\Program Files (x86)\Schneider Electric\Conext Control\PVDBEngine\PVdbConsole\Configurations\Nom_Site\Se.Pv.Controllers.cfg contient la date de la dernière journée valide (normalement la veille). En cas de bug il faut modifier manuellement la date pour passer au jour suivant sinon les données ne sont plus calculées.
- Modifier aussi le fichier C:\Program Files (x86)\Schneider Electric\Conext Control\PVDBEngine\PVdbConsole\Configurations\Nom_Site\Se.Pv.Grafters.Counters.cfg et modifier la 1ère date de chaque ligne.
Si il manque des données dans une journée la consolidation ne s’effectue pas (la ligne est alors en rouge dans le rapport mensuel).
Il faut alors vérifier dans le dossier “Error Files” si il n'y a pas des fichiers à rejouer! (cf.procédure Rejouer fichiers sur Conext Control Lot 6)
Pour relancer les calculs, aller dans le PVDB engine, stopper tous les process pour éviter des conflits sur le sql (process, stop all).
Puis aller dans Data Consolidation, start task et lancer les trois tâches dans l’ordre pour le site concerné, finir par daily job.
Vérifier ensuite la date dans le fichier Se.Pv.Controllers.cfg, elle doit correspondre à la veille.
On peut également valider le recalcul en regardant l'export de données site dans Clearscada ou en lançant la requête de rapport mensuel dans la base SQL.
Bien penser à relancer les process du PVDB, via Process/Start all, une fois les calculs effectués
Cas de relance des calculs :
• On était en perte de com au moment du daily job mais depuis les données sont revenues et ont été stockées dans la database.
• Il existe des error file que l’on a intégré dans la base sql. (file, binary file, sélection puis conversion)
• Sans error file, cela veut dire que l’automate n’était pas alimenté et que l’on n’a aucunes données.
Conext Control CESTAS
Il n'y a pas l'outil PVDbEngine sur cette version de Conext Control! L'outil de calcul PvdbConsole est intégré à la solution et fonctionne en tâche de fond
- sur le serveur ClusterX, ouvrir le fichier c:\Programmes\Schneider Electric\Conext Control\PVdbConsole\Configuration\SPVyyy\Sc.Pv.GraftersCounters.Cfg.xml
X = numéro du cluster, yyy = numéro de la SPV
- modifier le paramètre LastExecutionDtoLocalApp et mettre la date à partir de laquelle les calculs END devront être refaits
- enregistrer le fichier
→ le calcul des END sera effectué automatiquement par le PvdbConsole en tâche de fond.
- sur le serveur ClusterX, ouvrir le fichier c:\Programmes\Schneider Electric\Conext Control\PVdbConsole\Configuration\SPVyyy\Sc.Pv.Controllers.Cfg.xml
X = numéro du cluster, yyy = numéro de la SPV
- modifier le paramètre LastExecutionDtoLocalApp et mettre la date à partir de laquelle les calculs END devront être refaits
- enregistrer le fichier
Le job se relancera automatiquement dans la nuit.
Il est possible de forcer le redémarrage de PVDbConsole en allant, via un clique droit sur la boule ClearScada de la barre de tâche, dans Server Status/General/Modules et relancer le service CCPVScheduler
Il est également possible de forcer un DailyJob en tapant les lignes de commande (cf. procédure pour Conext Control Solaire Direct ci-dessous)
Remarque : les opérations décrites ci-dessus devront être réalisées pour chaque SPV
Conext Control Solaire Direct
Se connecter à la machine sdsv162 en accès RDP. Ce lot comprend bien un PvdbEngine, mais avec un comportement différent que sur le lot 6.
Etape 1: Arrêter les process du PvdbEngine –> la solution la plus rapide est de “killer” l'applicatif via le gestionnaire des tâches, puis de relancer l'application PvdbEngine.exe
Vérifier que tous les processus sont bien en stop.
Etape 2: Modifier les fichiers de configuration correspond aux sites concernés, situés dans le dossier PvdbConsole, en modifiant les dates à partir desquelles on veut relancer les calculs:
Le fichier UpdateCounters:
Le fichier DailyJob:
Etape 3:Une fois que les modifications sont faites pour les dates souhaitées, il faut relancer les commandes de UpdateCounters (responsable des calculs fait dans la BDD) puis du DailyJob (responsable de l'affichage des résultats dans les rapports)
Il faut taper dans l'invit de commande les lignes suivantes dans l'ordre:
Modifier le dernier numéro de la ligne de commande selon le site concerné!
Vous pouvez rajouter l'option -f (avec DailyJobBatch uniquement) pour ne lancer le calcul que sur le premier jour.
Ne pas oublier de relancer tous les processus du PvdbEngine une fois la manipulation effectuée!
Exemple de tâches FS
Cette partie se propose de citer des tâches FS où l'on a résolu des problèmes d'incohérences dans les rapports après avoir rejoué les données:
SD_CC: FS#1852 (Brignoles) CESTAS : FS#2250
Outils de la page
