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