Discussion :

[fweiner]

Bonjour a tous

Pour ma part nous fonctionnions par le passé sur un petit As400 en V4R5

Depuis nous sommes sur Iseries Type 520 bi pro avec 1,5 TERA 36giga ram en V5R4

La refonte c'est fait tellement vite que je n'ai jamais eu le temps de faire de RECLAM STORAGE ou de REORG

Nous avons une table de plus 1 500 000 000 enregs 125 gigas a elle seul.

La base pése déjà 470 gigas au total.

Rien qu'a l'idée de l'interuption possible je ne m'engage pas vers le reclaim, pourtant il va bien falloir le faire.


QQun a t'il une expérience similaire pour en parler ?

[Hédhili Jaïdane]

Bonjour.

- Pour éviter le RCLSTG, on peut utiliser RCLDBXREF qui n'a pas besoin du mode restreint. Il fait la même chose que RCLSTG SELECT(*DBXREF) mais ne réussit pas toujours à cause d'empêchements dus au mode non restreint. Si tel est le cas, on est obligé de lancer RCLSTG pour terminer le boulot et remettre la DB en bon état.
Le RCLSTG ou RCLDBXREF ne sont pas tellement nécessaires s'il n'y a pas de pbs sur la DB.
- un RGZPFM peut s'avérer utile avec une réorg sur la clé primaire du PF.
- un CPYF aussi avec compression (*YES) pour récuperer l'espace non utilisable.
Mais ça dépend de comment les applics sont organisées et accèdent aux tables gigantesques. Des vues en partition totale par sélection par sql ou par dds peuvent être intéressantes sur une grande table.

à suivre....

[fweiner]

Merci pour ta réponse.

As tu déjà fait un rclstg *all ?
ou un reorg sur une grosse table ?

pour me donnée une idée du temps passé deçu.

Jusqu'ici sur ce serveur je n'ai fait qu'un RCLSTG *DBXREF en mode restreint qui a été assez rapide. J'ai du le faire suite a un probléme sur une clé primaire qui avait été supprimé mais qui devait subsister qq part, ce qui generée un probléme de clé en double.

(En sachant que ceci dépends de la config hard de la machine bien entendu).

[Hédhili Jaïdane]

Un RCLSTG, comme tu dis, dépend de la machine et de l'ASP et des pbs. J'ai passé des nuits blanches chez des clients (>4h), mais aussi au bout de 10mn c'est fini. Je n'ai donc aucune idée sur combien ça va durer. Un RCLDBXREF, c'est vite fait sur des tables moyennes (1000 000 enr) avec 4 ou 5 zones clés et une bonne dizaine de lf la dessus (il y a ça aussi qui joue). Comme je travaille exclusivement sur des PME/PMI, je n'ai pas d'expérience sur des tables de la taille de la tienne.

Je ne sais pas, à voir...Fais des essais avec RCLDBXREF en mode NON restreint et regarde ce que ça donne.

ça dépend aussi du pourquoi tu veux faire ça? récupérer l'espace des enregistrements supprimés ou réorganiser la DB pour des pbs de chemins?

[OverSlach34]

Bonjour,

Dans le même registre je souhaiterais avoir votre opinion sur une reprise de données après modification de format fichier.

Un historique entête est passé au toilettage ! Création de deux nouvelles zones numériques de S(11,2) qui se substituerons aux 22 premières positions d'une zone filler alphanumérique.
Deux reprises de données sont prevues. La première effectuera l'alimentation des nouveaux champs et la rab du filler. La seconde, un correctif, prendra en compte le signe contenu dans les enregistrements de l'historique ligne pour calculer le cumul montant des nouvelles zones. Les zones de montant ne sont pas signées, le contenu d'une zone informe du signe (P/N) de l'ensemble des zones montant d'un enregistrement de l'historique ligne.

Le nombre d'enregistrements contenu dans l'historique entête n'est pas le problème. J'ai effectué deux simulations du chargement de ces nouveaux champs avec un panel de 10%, le temps d'execution est faible. Il est vrai que le physique n'était rattaché qu'au logique nécessaire à la reprise.

S'agissant d'historiques de flux émis par les CPAM vers les organismes de régime complémentaire (Entête, Données d'origine, Ligne.
L'historique données d'origine est le fichier qui contient le plus grand nombre d'enregistrements; comme son nom l'indique, il contient les données reçues dans leur format d'origine.
Pour plus de détail à ce sujet, je propose d'ouvrir une nouvelle discusion ou de consulter le site internet www.ameli.fr, de cliquer sur "Documentation technique" et de télécharger les document PDF Cahier des charges NOEMIE OC (juin 2005-B), Cahier des charges NOEMIE OC (juin 2005-C) et les annexes pour vous initier à la gestion d'EDI santé !

Ces historiques ont une dizaine de vues logiques jointes, l'historique Entête a cinq vues logiques, l'historique Origine trois et l'historique Ligne seize. La majorité des vues jointes, utilisées lors de traitement Batch ou Web, sont de format restreint avec sélection et omission. Peu de vue complète !
Le trou de la sécu est à la mesure du nombre d'enregistrements contenu dans l'historique Ligne. Les développements sont effectués avec le gestionnaire de versions "ARCAD" qui effectuera le remplacement de tous les objets touchés par cette modification.

Mes questions :
1 - Pensez-vous qu'il faille attendre la fin de la reconstruction des index pour
lancer les programmes de reprise ?

2 - Existe-t-il un moyen de "programmer" la reconstruction des index une fois
la reprise des données effectuées. ?

3 - Qu'auriez vous fait à ma place ? (optimisation, organisation, etc.)

Merci !