Archive

Posts Tagged ‘Base de données’

COOX 7 : Comment modifier le port d’utilisation de la base de données embarquée H2 ?

La console d’administration H2 utilise le port TCP 8082. Si ce port est déjà utilisé par un autre logiciel fonctionnant sur cette machine, il peut être nécessaire de le modifier. Dans COOX 7 Helium, ce port est paramétrable au niveau du service de persistance.
Pour avoir accès à ce paramètre, il faut afficher l’arbre de la persistance (menu : Outils – Préférences) :

préférences

persistanceScreenClipa

Grâce à la touche Basculement b, vous avez accès aux propriétés du service de persistance : il vous suffit alors de modifier le paramètre du port web de la base de données H2.

Pour rappel :

L’utilisation d’une base embarquée H2 s’accompagne de certaines particularités de fonctionnement :

– la base se trouve directement dans le répertoire de votre application : si vous copiez ce répertoire, vous copiez également la base de données.
– Les données du contexte de « Test » (voir option de lancement du Manager) sont toujours celles de l’application origine : le chargement en mode test d’une application écrasera systématiquement la base contextuelle par la base de l’application origine.
– Pour sauvegarder les données de production, il faut copier le dossier context/runtime/db de l’application situé dans active_project.
Pour garantir l’intégralité de la sauvegarde, celle-ci doit se faire quand l’application est arrêtée.

COOX 7 helium : Comment est géré le mode d’archivage des recorders dans la MESbox SCADA ?

Afin de réaliser un archivage, vous devez avant clôturer la base de données courante, puis en créer une nouvelle.
Dans la MESbox SCADA, module de supervision, d’acquisition et de pilotage d’informations, l’opération d’archivage s’effectue à la demande (action ou programmation).
Elle peut être par exemple commandée une fois par jour ou une fois par mois, en fonction du flux d’échantillons enregistrés.
Les données sont stockées dans une succession de table de données. Le mode archivé garantit alors de meilleurs performances d’accès aux données enregistrées.

recorderA noter : le système limite la taille des tables à 1 million d’enregistrements, au-delà il crée automatiquement une archive.

Pour plus d’informations sur les capacités d’extension des fonctions d’historisation et d’archivage des applications, n’hésitez pas à venir découvrir notre module complémentaire « Archive Manager » : le module COOX-AM d’ORDINAL Software permet la mise en place rapide d’un mécanisme d’archivage planifié des données d’application allié à un outil d’exploitation hors production des applications particulièrement convivial.
Doté d’un haut niveau de compression, il facilite le stockage et permet une gestion rationalisée des archives.
Il bénéficie des capacités natives de la plateforme COOX : déploiement Intranet, support de plusieurs bases de données, données visualisées et enregistrées multilingues,…etc. Ses capacités s’étendent à tous les packs MESbox de la gamme.

En savoir plus…

Plateforme COOX : Cause et réparation de la corruption des données

En fonction de la base de données utilisée, des événements particuliers peuvent conduire à une corruption de celle-ci. Cela se produit généralement après les incidents suivants :

  • processus tué au milieu d’une écriture
  • arrêt inattendu de la machine (ex : coupure de courant)
  • problème matériel

Les symptômes typiques d’une table corrompue sont :

  • Vous obtenez une erreur pendant la sélection des données à partir de cette table
  • Les requêtes ne trouvent pas de ligne dans la table ou retournent les données incomplètes.

Les bases de données proposent des outils de réparation.
De manière générale, il est déconseillé de réparer une table pendant que l’application est en fonctionnement, cela peut perturber le système.
Si vous utilisez une base MySQL avec le moteur MyISAM, vous trouverez des informations détaillées à l’adresse suivante :

http://dev.mysql.com/doc/refman/5.0/fr/corrupted-myisam-tables.html

Réparation de la table

COOX – Module Archive Manager : Comment faire pour enrichir la réplication de la base de données par l’option « Stratégie de réplication MES »

Dans le module Archive Manager de COOX, la réplication autorise l’écriture des données dans deux bases de données différentes, ce qui permet :

  • d’avoir une continuité de fonctionnement en cas de défaillance d’un serveur de données
  • d’éviter toute perte de données en cas de défaillance d’un serveur de base de données
  • de planifier une intervention pour revenir à une situation nominale

Nous avons enrichi la fonction de réplication de la base de données par l’option : Stratégie de réplication MES

replication

Stratégies de réplication SCADA :
Le fonctionnement de la réplication correspond à la stratégie de réplication SCADA. C’est le mode utilisé par défaut et correspond au mode de fonctionnement originel.
L’objectif de la stratégie de réplication SCADA est d’avoir une continuité maximale de production.
Ainsi, dans le cas d’une réplication active avec une base de données primaire et une base de données secondaire, cette stratégie décrit le scénario suivant :

  1. Perte du primaire : on bascule sur le secondaire
  2. Retour du primaire : on reste sur le secondaire
  3. Perte du secondaire : on bascule sur le primaire
  4. Retour du secondaire : on reste sur le primaire

Stratégies de réplication MES
Par opposition, le logiciel propose maintenant la stratégie de réplication MES.
L’objectif de cette stratégie est de maximiser la garantie des données.
Ainsi, dans le cadre d’une réplication active avec une base de données primaire et une base de données secondaire, cette stratégie se met en place comme suit :

test

  1. Perte du primaire : on bascule sur le secondaire, le primaire n’est plus autorisé

test2

  1. Retour du primaire : on reste sur le secondaire
  2. Perte du secondaire : on ne bascule pas sur le primaire, car il n’est pas autorisé

test2

  1. Retour du secondaire : on réutilise le secondaire, car il est autorisé

COOX : Comment définir des profils de purge ?

Pour avoir accès à l’arbre de la persistance dans COOX, il faut activer cette option au niveau des préférences du Builder :

Preferences

Par défaut, COOX possède trois profils d’historique :

historique

Les tables appartenant à ces profils sont les suivantes :

TRACKING – 30 jours

tracking

Note : en complément de ces profils de purge automatique, certaines tables utilisées pour la traçabilité matières peuvent nécessiter une purge applicative.

HISTORY – 90 jours
Vous pouvez trouver l’ensemble des tables historiées dans le visuel des bases de données.
Vous y avez accès par le menu Déploiement / Base de données / Table puis onglet « historique »

Entityview

Sur COOX-DOC-Platform (documentation disponible à l’installation du logiciel), vous trouverez des explications complémentaires sur les profils d’historique et de purge, au chapitre « Purge des données ».

Plateforme COOX : Comment faire pour configurer la réplication d’une base de données dans COOX ?

La réplication permet l’écriture des données dans deux bases de données différentes, ce qui permet :

– d’avoir une continuité de fonctionnement en cas de défaillance d’un serveur de base de données
– d’éviter toute perte de données en cas de défaillance d’un serveur de base de données
– de planifier une intervention pour revenir à une situation nominale
– couplage avec la redondance des services

Définition des architectures : Deux types d’architecture sont possibles :

– Le serveur de base de données et le serveur d’application sont hébergés par la même machine

 

– Le serveur de base de données et le serveur d’application sont hébergés par des machines différentes

Interface de paramétrage :

-Définition de deux adresses IP
-Base de données principale
-Base de données secondaire
-Un ou deux noms de base de données
-Le caractère « ; » sert de séparateur

Défaillance de la base de données :

-Le système indique la défaillance
-Le système switch sur la DB de secours
-Il faut planifier une intervention pour revenir à la situation nominale

%d blogueurs aiment cette page :