|
| gestion des Coupures de courant ou un plantage du système |
| Débuté par Teo, 13 nov. 2006 15:11 - 5 réponses |
| |
| | | |
|
| |
Posté le 13 novembre 2006 - 15:11 |
J'ai constaté en HF Classic que parfois , suite à une coupure de Courant, les index so,t détruites, une partie des données est bizzares (caractères non imprimables).
Jusqu'à présent Windev ne propose rien pour resoudre le problème.
Exemple : vous avez votre id automa. à 350, et suite à une panne vous annuler vos transactions vous reindexer , mais vous avez de valeurs du genre 23693322000 ou -262225221, inexploitable, non interprétable.
Quelqu'un connait-il ce problème ? Comment le résout-il ? |
| |
| |
| | | |
|
| | |
| |
Posté le 13 novembre 2006 - 15:58 |
Bonjour,
Attention de bien situer le niveau d'intervention en fonction de la panne
(sujet d'un prochain billet ?) !
En cas de défaut matériel, il faut d'abord intervenir sur le matériel
lui-même pour le sécuriser. Un serveur hébergeant une base de données par
définition en doit pas être victime de coupure de courant !
Mais je sais dans la pratique, certains déploiements sont fait en ignorant
les principales règles de sécurité. Si vous êtes dans ce cas, je vous
conseille en action immédiate d'augmenter le niveau de sécurité de
l'application : "HSécurité(2)". Ensuite utilisez la base en mode
Client/Serveur plutôt que classique, vous éviterez les perturbations pouvant
être liées au réseau.
Pour une réparation après panne, vous avez l'option de révision complète du
programme WDOPTIMISEUR. Si elle est insuffisante, vous pouvez créer une
moulinette de récupération, qui vous permettra de recréer une copie saine
d'un fichier ("HAlias" + "HcopieEnreg"). Dans tous les cas la protection de
l'alimentation du serveur reste obligatoire.
Elian Lacroix
elian.lacroix@gmail.com
http://elianlacroix.blogspot.com
"Teo" <teophilel@yahoo.fr> a écrit dans le message de news:
45586c8d$1@news.pcsoft.fr...
J'ai constaté en HF Classic que parfois , suite à une coupure de Courant,
les index so,t détruites, une partie des données est bizzares (caractères
non imprimables).
Jusqu'à présent Windev ne propose rien pour resoudre le problème.
Exemple : vous avez votre id automa. à 350, et suite à une panne vous
annuler vos transactions vous reindexer , mais vous avez de valeurs du
genre 23693322000 ou -262225221, inexploitable, non interprétable.
Quelqu'un connait-il ce problème ? Comment le résout-il ?
|
| |
| |
| | | |
|
| | |
| |
Posté le 13 novembre 2006 - 16:53 |
Si je suis d'accord sur le fait qu'un serveur DOIT être protégé par un onduleur, il ne me parrait pas normal qu'une base de données soit endommagée par une bête coupure de courant.
Il suffit d'une coupure prolongée, qui dépasse l'autonomie de l'onduleur, d'une panne du bloc d'alimentation (si pas de redondance), d'une surchauffe... pour que le serveur s'arrête.
Nous avons déjà subit ce genre d'arrêt "violent" de nos serveurs, à cause d'une panne de climatisation, d'une coupure de courant trop longue (malgré un onduleur de 10KVA avec 3 packs de batteries), et aucune de nos bases de données (Progress, SQLServer et MaxDB) n'a été endommagée. Les transactions en cours au moment de l'arrêt sont annulées, et tout repart sans problème.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 13 novembre 2006 - 21:29 |
C'est parfois plus complexe que cela. Dabord vous exiger que le client achète l'onduleur mais par la suite, vous ne connaissez pas la durée de vie des batteries.
Pour la routine, si vous avez 2 tables, c'est bien, si vous avez 50, il faut reconstruire tout.
Si le client ne vous pas informer, son icrémentation aura continuer et il aura peut être ajouter de nouvelles choses.
Techniquement serait un filtre dans les index, cela se fait en dbf (avec .cdx) mais pas faisable avec HF.
La solution C/S, peut-on adopter comme standard de distribution des appli monoposte le C/S ?
J'ai utilise Sybase ASA, en 15 ans j'ai reconstituer au plus 3 fois. Je cherche toujours la solution. |
| |
| |
| | | |
|
| | |
| |
Posté le 14 novembre 2006 - 10:24 |
le passage en C/S resoud 95% des problèmes d'index.
On s'épargne les problèmes de réseau ce qui est déjà énorme.
Ensuite pour l'onduleur, normalement il y a un petit soft vendu avec qui permet d'éteindre le serveur lorsque l'onduleur n'a plus de jus.
Voila. moi j'avais une appli en HF classic sur un serveur (env 15 utilisateurs sur une appli de env 100 tables). Avant je devais réindexer tout les 3 jours en reconstruisant certains index et en remettant manuellement l'ID du fichier.
Maintenant en C/S, je n'ai plus de problème.
Apres s'il y a un soucis sur une appli avec 1 seul utilisateur, ça me semble bizarre. surement un problème reseau.
En tout cas c'est clair: HF classic + reseau pourri = reindexation et prises de tete en vue. |
| |
| |
| | | |
|
| | |
| |
Posté le 15 novembre 2006 - 01:48 |
Bonsoir,
Je suis également tout à fait d'accord ! Mais dans le message de "Téo" j'ai
noté "une partie des données est bizzares (caractères non imprimables)" :
cela indépendamment de la base de données est révélateur d'un problème le
plus souvent matériel lié à un disque défectueux, ou en tout cas sur lequel
il y a un eu problème d'écriture sérieux.
Je partage également l'avis de "Jean" sur ce même sujet, l'utilisation de la
base en mode client/serveur est un plus indéniable pour les données, les
risques liés au réseau étant réduits.
Elian Lacroix
elian.lacroix@gmail.com
http://elianlacroix.blogspot.com
"Frédéric DEMILLY" <f.demilly@pacificpeche.fr> a écrit dans le message de
news: 455884a6$1@news.pcsoft.fr...
Si je suis d'accord sur le fait qu'un serveur DOIT être protégé par un
onduleur, il ne me parrait pas normal qu'une base de données soit
endommagée par une bête coupure de courant.
Il suffit d'une coupure prolongée, qui dépasse l'autonomie de l'onduleur,
d'une panne du bloc d'alimentation (si pas de redondance), d'une
surchauffe... pour que le serveur s'arrête.
Nous avons déjà subit ce genre d'arrêt "violent" de nos serveurs, à cause
d'une panne de climatisation, d'une coupure de courant trop longue (malgré
un onduleur de 10KVA avec 3 packs de batteries), et aucune de nos bases de
données (Progress, SQLServer et MaxDB) n'a été endommagée. Les
transactions en cours au moment de l'arrêt sont annulées, et tout repart
sans problème.
Frédéric.
|
| |
| |
| | | |
|
| | | | |
| | |
|