Discussion :

[wdmini]

Bonjour,
Nous rencontrons des problèmes d'index corrompu en HyperFile Classic chez un seul utilisateur alors que l'appli tourne chez une bonne 50aine d'utilisateurs sans problème.

La base de données est partagée dans un dossier sur un serveur 2008.

Si on réindexe tout repart mais de nouveaux défaut apparaissent relativement rapidement (quelques jours).

Quelqu'un a-t-il une idée sur les causes possibles et surtout comment éviter ces problèmes.
A priori pas de problème matériel...

Merci d'avance de toutes vos réponses...

WDmini

[hpascal]

Bonjour

A l'époque ou j'utilisais encore Hyperfile en réseau, on avait aussi ce problème sur certains serveurs. Une modification de la base de registre (du serveur) permettait de résoudre le problème (liée à les gestion des "verrous opportunistes")

Je te mets deux liens sur le sujet mais fais d'autres recherches là dessus:
http://windev.dev4u.org/index.php?op...d=59&Itemid=70
http://support.microsoft.com/kb/296264/fr

Mais c'était parfois difficile à faire passer en clientèle. Dire qu'on client qu'on doit modifier la BDR de son serveur et surtout qu'il va devoir le redémarrer pour résoudre le problème.
Depuis j'ai fais une croix sur HF en réseau, même si avec le moteur Client/Serveur les choses ont changées.

D'ailleurs pourquoi ne pas passer en Client/Serveur ?

[José13680]

Bonjour,

Je sais que cela fait pas mal de temps que ces soucis ont été abordés mais nous sommes en 2013 et je rencontre pour la première fois ces pb de corruption d'index après avoir migré un serveur 2003 en 2008 R2!
Nous avons pourtant un serveur récent datant de janvier 2013 et totalement à jour.
Côté postes de travail nous avons une grande majorité de PC sous XP (pareil totalement à jour) et quelques Windows 7 (à jour aussi). De lpus, aucun souci de matériel ou de drviers réseau, toutes les machines sont à peu près équivalentes, récentes et les cartes sont des gigabits.

Auparavant nous n'avions JAMAIS eu le moindre souci de corruption d'index, et pourtant nos applis existent et fonctionnent avec la même base HF depuis plus de 10 ans pour la plupart!!
Il est à noter que le seul fichier posant ces problèmes est encore en HF5 et nous allons très vite le migrer en HF7 et que ce fichier est la pus volumineux et le plus souvent accédé en écriture.

J'ai fait beaucoup de recherches et sollicité l'AD de PCSoft et nous allons nous orienter dans les mois à venir vers une migration de nos fichiers HF classic vers du C/S!

En attendant, j'aimerai savoir si parmi vos différentes expériences, certaines peuvent affirmer que les soucis sont liés, comme tout semble le montrer, à des versions de SMB différents (SMB1 pour les XP et SMB2 pour les 7), et si les manips de registres pour forcer SMB1 sont efficaces ?

D'autre part, si quelques pouvait m'expliquer ce qui ne fonctionnement pas bien lorsqu'on a des version de SMB différentes, cela me serait très utile pour comprendre où intervenir!

J'ai par ailleurs vu que certains hotfix Microsoft avaient été publiés mais je pense qu'ayant un OS 2008 R2 des plus récents, je n'en ai pas besoin ? J'ai vérifié les versions des fichier MRXSMB2 et les miennes sont plus récentes.

Merci donc par avance pour votre aide.

[frenchsting]

2 pistes (même si ce n'est pas sûr que ça fonctionne) :
Utiliser des hferme() dès que possible dans tes applis
Utiliser un automate pour réindexer le fichier la nuit (les postes clients ne doivent pas accéder au fichier en question).

Pour tes histoires de SMB, je ne pourrai pas t'aider, par contre, essaye de poster du coté de la partie "windows" du forum et/ou sur le forum officiel microsoft.

[José13680]

Merci pour cette réponse rapide!

Cependant, nous ne pouvons pas mettre des hferme partout, même si nous savons bien que sur les fichiers HF5, cela forcerait l'écriture des données!

D'autre part, le souci ne se produit que sur 1 seul fichier (sur plus d'une trentaine), le plus souvent accédé en écriture pas plusieurs postes clients.
C'est arrivé 4 fois en 2 mois, et la réindéxation est rapide (6 minutes pour plus d'1,2 millions d'enregs). Donc nous réindéxons dès que cela se produit.

Enfin, je vais continuer mes recherches sur SMB car c'est vraiment depuis la migration sous 2008 R2 de notre ancien serveur 2003 que cela se produit, donc à part SMB, je ne vois pas....

Encore merci.

[frenchsting]

Si le nombre de corruptions est faible, cela vaut-il le coup de passer bcp de temps à chercher sur le net ?
Ma solution de réindexation auto du fichier tous les soirs par un automate sera peut-être plus rapide, non ? C'est un plâtrage mais en attendant que tu fasses la migration vers du HF classic...

Les hferme sont lourds certes, mais mis à des endroits stratégiques cela pourrait suffire.

Attention de ne pas minimiser la migration vers classic, car la modification de la gestion des espaces en fin de champ peut entraîner pas mal de modifs...

[José13680]

En effet le nombre de corruption est très faible mais à chaque fois on est obligés de demander à chaque utilisateur de fermer les applications ouvrant le ficher (environ 30 utilisateurs) et de réindéxer. Ce fichier est vital pour la société !

Les hferme ont déjà été envisagés en attendant la migration en HF Classic qui est en bonne voie.
Cependant d'après l'AD de PCSoft, le passage en HF Classic ne garantit en rien la résolution du problème qui peut tout à fait continuer à se produire même si on sait que HF7 est beaucoup plus robuste que HF5!

LA solution est de passer en C/S et c'est ce qu'on envisage très sérieusement mais cela va nous prendre plus de temps....

Pour ces qui est des espaces, nous y avons pensé et de toutes façons lors de la conversion, on peut les garder..

[frenchsting]

Je me doute bien que c'est le fichier le plus important !!! C'est pour cela qu'il est le dernier migré.

Le problème est surtout dû aux accès concurrents sur le fichier. Une réindexation permet surtout de gagner du temps en (lecture-)écriture sur ledit fichier et minimiser un peu plus les risques ce corruption.

Oui tu peux garder les espaces... mais je te le déconseille fortement. Tant qu'à mettre les mains dans le cambouis, autant y aller à fond. Car tu auras le pb des espaces en migrant en C/S.

Les fichiers utilisés par CS sont du même format que le HF classic...

[José13680]

Merci pour ces infos, nous allons en effet gérer les espaces lors de la migration pour le futur.

Je sais que tu m'as dit que concernant SMB tu ne pouvais pas trop m'aider, mais penses-tu que notre problème, qui est finalement rare et ne se produit que sur 1 fichier HF5, puisse provenir de soucis d'hétérogénéité de protocoles SMB sur le serveur 2008 avec des clients XP et Seven ?
Penses-tu que le fait de migrer ce fichier en HF7 puisse suffire ?

En fait, j'ai l'impression que la quasi totalité des développeurs Windev ont opté pour le C/S et du coup je ne sais pas si certains utilisent encore la version Classic dans un environnement identique au mien (Postes XP et Seven et Serveur 2008 R2 tous à niveau) et si ils ne rencontrent pas de soucis ?

Aurais-tu ce genre d'infos ?

[serendib]

Juste pour info :
Une grosse appli en WD55,
Une centaine de Clients,
Certains sous Seven, beaucoup sous Serveur 2008 R2 (32 ou 64)
et aucun problèmes de fichiers corrompus.
Evidemment, c'est arrivé, mais vraiment, très rarement.
Par contre, réindexation de tous les fichiers à 2 heures du matin
chez tous les Clients (on sait jamais).

PS :Je ne ferme jamais les fichiers.

[frenchsting]

SMB, c'est au niveau du réseau (transmission de données). Tu as un problème lors de l'écriture. Pour moi, cela n'a rien à voir. Je penche plutôt sur un pb de taille de fichier/index/mmo qui grossi(ssen)t et donc qui fait que les temps de lecture/écriture sont plus long et que la probabilité d'une action simultanée sur le fichier par pls utilisateur augmente, donc la probabilité de corruption augmente.

La migration en HF 7 devrait aider car tu auras des fichiers plus petits. Attention : HF7 ne veut pas dire classic puisque dans ton cas, tu vas garder le mode de gestion 55.

L’environnement classic dans ton cas est à proscrire (trop d'utilisateurs). Il faut passer en C/S. C'est très simple lorsque tous tes fichiers sont en déjà classic.

Un bon point pour serendib.

[José13680]

Juste pour info :
Une grosse appli en WD55,
Une centaine de Clients,
Certains sous Seven, beaucoup sous Serveur 2008 R2 (32 ou 64)
et aucun problèmes de fichiers corrompus.
Evidemment, c'est arrivé, mais vraiment, très rarement.
Par contre, réindexation de tous les fichiers à 2 heures du matin
chez tous les Clients (on sait jamais).

PS :Je ne ferme jamais les fichiers.

Merci pour ce retour d'expérience.
Parmi tes clients, y en a-t-il qui ont les fichiers HF sur un W2008 R2 avec des clients Seven ET XP ? Et avec des ficheirs HF 5 de grosse taille (>= 1Go) ?

Ce qui est notre cas.

Merci.

[José13680]

SMB, c'est au niveau du réseau (transmission de données). Tu as un problème lors de l'écriture. Pour moi, cela n'a rien à voir. Je penche plutôt sur un pb de taille de fichier/index/mmo qui grossi(ssen)t et donc qui fait que les temps de lecture/écriture sont plus long et que la probabilité d'une action simultanée sur le fichier par pls utilisateur augmente, donc la probabilité de corruption augmente.

La migration en HF 7 devrait aider car tu auras des fichiers plus petits. Attention : HF7 ne veut pas dire classic puisque dans ton cas, tu vas garder le mode de gestion 55.

L’environnement classic dans ton cas est à proscrire (trop d'utilisateurs). Il faut passer en C/S. C'est très simple lorsque tous tes fichiers sont en déjà classic.

Un bon point pour serendib.

Je ne comprends pas quand tu "HF7 ne veut pas dire classic puisque dans ton cas, tu vas garder le mode de gestion 55." ?
Nous ne voulons pas garder le mode 5.5 ? Tous les fichiers que nous avons déjà mirés depuis HF 5.5 sont passés en classic ?

D'autre part, tu dis que plus le fichier est gros plus le risque le corruption de données est important ? Je ne comprends pas non plus cette affirmation ? Peux-tu préciser STP ?

[serendib]

Parmi tes clients, y en a-t-il qui ont les fichiers HF sur un W2008 R2 avec des clients Seven ET XP ?

Réponse : oui, bien sûr.


Et avec des fichiers HF 5 de grosse taille (>= 1Go) ?

Si tu parles du .FIC, non.
Taille maxi chez mon plus gros Client : 200 Mo (le .FIC)

Je ne pense pas que la taille soit une cause.
Avis perso.

[frenchsting]

Nous ne voulons pas garder le mode 5.5 ? Tous les fichiers que nous avons déjà mirés depuis HF 5.5 sont passés en classic ?

Je me suis mal exprimé. Lorsque tu migres un fichier de 55 vers classic, tu peux utiliser l'option esacesignificatif(vrai) afin de ne pas avoir à modifier (trop) ton code. Les champs et notamment les clés composées ne changent pas. Ton fichier est en classis, mais "fonctionne" comme un 55.

D'autre part, tu dis que plus le fichier est gros plus le risque le corruption de données est important ? Je ne comprends pas non plus cette affirmation ? Peux-tu préciser STP ?

Plus un fichier est gros plus les temps d'accès sont important. Tu vas mettre plus de temps à parcourir un fichier de 1 000 000 d'enregistrements que s'il en comporte 1 000. La probabilité qu'un utilisateur accède au fichier alors que celui-ci est déjà en accès pas un autre utilisateur est plus important.

Une solution pour contourner le problème est d'utiliser herreurblocage() et de faire patienter l'utilisateur "arrivant", le temps que l'utilisateur "déjà présent" puisse finir son opération.

Je ne pense pas que la taille soit une cause.
Avis perso.

Il y a la taille et le nombre d'utilisateurs en simultané sur le même fichier. Si pour tes clients, tu as un fichier partagé pour 2 utilisateurs, le "risque" n'est pas le même que si tu en a 30.

[José13680]

Bonjour,

Je suis du même avis que serendib concernant la taille, d'autant plus qu'il faut bien se rappeler qu'avant notre migration vers 2008 R2, nous n'avions jamais eu ce souci et le fichier en question a déjà été de plus grosse taille.

Concernant les accès concurrents, je ne pense pas qu'il faille faire quoi que ce soit dans le code, du moins à partir du moment où les utilisateurs ne modifient pas le même enregistrement!? Dans notre cas, c'est un fichier stockant des lignes détail de commandes (environ 1000 nouveaux enreg par jour) et même si ce problème d'accès concurrent existait, en aucun cas il provoquerait des corruptions d'index!?

Le service AD de PcSoft avec qui j'ai pas mal discuté de ce problème n'a d'ailleurs jamais évoqué le moindre souci de taille ni d'accès concourent même pour des fichiers HF5. Ce qui est sûr par contre c'est qu'ils déconseillent très fortement d'utiliser ces fichiers HF5 dans des environnements récents!

Non, je pense réellement qu'il doit y avoir un problème lié à l'utilisation sur le serveur 2008, de 2 protocoles SMB différents lors des accès au fichier (SMB1 pour les accès depuis les PC XP et SMB2 depuis les accès des PC sous Seven).

Ce qui est curieux c'est que d'autres config identiques semblent ne pas poser de PB, d'autant que nos OS serveurs sont des plus récents et à jour ?

Le tout est de savoir si le fait de passer les fichiers HF5 en Classic résoudra ou non notre souci ?


Merci.

[frenchsting]

Pour moi le smb est plus un protocole de transmission qui permet de partager une ressource. Le smb délègue ensuite l'écriture au système de fichiers.

Je penche plutôt alors vers l'enregistrement physique du fichier : taille de cluster, délai d'enregistrement, écriture décalée et autres choses que je ne maîtrise pas trop.

Si tu as ton ancien serveur, regarde sous le capot...

La corruption se produit lorsque l'enregistrement est incomplet : fic renseigné mais pas ndx par exemple.

Le passage en classic te permettra de faire un pas vers CS et il est normalement plus fiable que 55. Par contre, je ne garantis pas que cela solutionnera à 100% ton problème.

[José13680]

Pourtant, concernant SMB il semble bien que le cache implémenté dans SMB2 à partir de Windows Vista, puisse être à l'origine de ce genre de problèmes de corruption d'index sur des fichiers de bases de données de type ISAM (donc comme HF Classic) !

Plusieurs infos sur Internet relatent ces problèmes et il semblerait que Microsoft ait proposé des hotfix et une méthode de contournement consistant à ajouter la clé FileInfoCacheLigeTime = 0 dans la branche de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters

Cette méthode pourrait bien résoudre le souci mais va augmenter considérablement les échanges SMB entre le client et le serveur !

Nous ne l'avons pas encore testé car je voudrais bien comprendre exactement ce qu'il se passe et si ce contournement est toujours d'actualité.
Infos que j'ai pour l’instant beaucoup de mal à obtenir.

[frenchsting]

Je comprends mieux. Microsoft ne peut pas s'empêcher de bidouiller les standards. Cette histoire de cache me semble une bonne piste en effet.

La modification de la base de registre est réversible ? Ou il y a tout un tas de manip à faire et patchs à installer en plus ?

Si c'est simple pour revenir en arrière, tu peux essayer...

[José13680]

Je ne pense pas que ce soit irréversible mais je n'aime pas du tout l'idée de devoir par exemple désactiver un cache qui a été créé pour améliorer les échanges réseau ou pire de désactiver le protocole SMB2 pour revenir à une version beaucoup moins performante !
Certes cela résoudra très probablement mes soucis mais avant de toucher quoi que ce soit je recherche désespérément d'autres témoignages sur le sujet!
De plus je cherche, en vain pour l'instant, à obtenir de la part de Microsoft une confirmation que mon souci vient effectivement de là et que le fait de rétrograder en SMB1 de posera pas d'autres soucis.

Il faut quand même savoir que nous avons les technos derniers cris : Windows Server 2012 avec Hyper-V3 et 4 VMs sous Windows 2008 R2, le tout sur un serveur de compétition installé par des experts Microsoft il y a 2 mois!

Alors c'est sûr côté technos, HF 5.5 n'est pas ce qu'il y a de plus récent mais bon si chez d'autres cela fonctionne bien, ça doit aussi fonctionner chez nous ?!
Si les seules réponses sont soit de passer en C/S soit de rétrograder en SMB1,, personnellement cela ne me satisfait pas du tout!!