Archivage de données (Gros fichiers de prod)

**fweiner** · 18/06/2008, 17h19

Bonjour a tous

J'ai un très gros fichiers :

144 Gigas
1 612 288 890 enregs
9 Index

Il faut en supprimer 500 000 000 et le fichier est utilisé 7j/7

J'ai testé le fait de sortir via CPYF d'une vue crée pour l'occasion, les enregs concernés pour sauvegarde/Archivage. (Fait)

J'ai testé un pgm en SQLRPGLE qui lit ma vue (Natif) et fait du delete + commit en SQL a l'enreg sur la table avec la clé primaire, pendant un temps paramétrable. (Ceci est La solution que j'avais choisis pour ne pas locker la table seulement celle ci ce révèle beaucoup trop longue 2 900 000 enregs en par groupe de 12h)

J'avais imaginer faire du cpyf vers une copie de ma table vide pour n'avoir au final que les enregs qui m'intéresse et remplacer l'une par l'autre a un instant T, mais ceci pose le problème de l'identifiant de niveau fichier qui est stocker dans les objets pgm. (Donc signifiant une recompile de trop nombreux pgm + une copie + rée indexation (sur les 1 100 000 000 enregs pour le coup contrairement a mes 500 000 000) (C'est surement la solution qui me semble la plus rapide malheureusement mais il faut que ceci tiennent en temps pour qu'il n'y ai pas eu de mise a jour sur la table d'origine entre temps)

Qu'en pensez vous ? une autre idée ?

**K2R400** · 18/06/2008, 17h30

Envoyé par fweiner

J'avais imaginer faire du cpyf vers une copie de ma table vide pour n'avoir au final que les enregs qui m'intéresse et remplacer l'une par l'autre a un instant T, mais ceci pose le problème de l'identifiant de niveau fichier qui est stocker dans les objets pgm.

un CPYF ne change pas le niveau de format !!!!!
Et avec une requête SQL tout simplement ?
Mais il va falloir faire un RGZPFM a un moment ou un autre si tu utilises pas le CPYF

**fweiner** · 18/06/2008, 17h51

Eh oui

c'est pour ça que j'ai tendance a pensé que je m'en sortirai mieux avec un CPYF

Car les test de RGZPFM que j'ai pu faire sur une autres partitions malheureusement saturée ont révélé des durées exponentiels.
Je n'en ai laisser aboutir aucun vu les temps.

Tu est sur du coup pour l'Id de niveau de fichier avec un cpyf.
Ce serez super ca.
Il me resterez a tester le temps du CPYF sur la plus grosse partie de mon fichier.

**K2R400** · 19/06/2008, 08h38

Envoyé par fweiner

Tu es sur du coup pour l'Id de niveau de fichier avec un cpyf ?

Le niveau de format d'un fichier est un calcul basé sur :

- Le nom du format
- le nom des zones et leurs descriptions (hors text, colhdg)
- les éventuelles clés (et Select Omit)

Un CPYF ne changera pas le niveau de format avec CRTFILE(*YES).
Fais l'essai en ne copiant qu'un enreg : NBRRCDS(1) tu seras rassuré.

**fweiner** · 19/06/2008, 10h14

Merci pour ton niveau de précision.

c'est vraiment super appréciable d'avoir ce genre de réponse.

Justement j'avais générée une copie de mes objets File + index, mais a partir des Dll sql ce qui pour le coup a changer mon niveau de fichier, mais pas mon id niveau de format.

Lequel pose probléme au objet PGM Id niveau de format ou id niveau de fichier ?

Et qu'en est t'il des ID de niveau fichier et format lorsque l'on fait un CRTDUPOBJ sans les données pour faire par la suite le CPYF

**K2R400** · 19/06/2008, 10h20

On se moque de l'ID de fichier, ce qui importe c'est l'ID de format.
Attention, créer un fichier avec des DDS et le même avec des DDL (SQL) donnera un niveau de format différent car en SQL, le format = le fichier, pas en DDS.

Par contre pour les Index ou vues vs LF DDS, le niveau de format sera le même à description égale.

Un CRTDUPOBJ et CPYF donne le même niveau de format que l'origine.
le niveau de fichier peut changer mais celà n'a pas d'importance pour les PGM.

**fweiner** · 19/06/2008, 10h59

Merci encore pour ces éclaircissements.

Mais par rapports a la questions d'origine que penses tu sur la meilleur approche en terme de performance et surtout d'efficacité contenu de l'activité de la table ?

**K2R400** · 19/06/2008, 11h10

Un CPYF est une bonne solution car il présente l'avantage de ne pas faire de RGZPFM par la suite.
Par contre, il sera conseillé que personne n'utilise le fichier au moment ou il faudra le renommer, sans oublier de le journaliser à nouveau.

Sinon, le DELETE SQL sera plus performant mais il vaut mieux au préalable stopper la journalisation du fichier (ENDJRNPF).
Par contre, il est fortement conseillé de faire après un RGZPFM suivi du redémarrage de la journalisation.

**fweiner** · 19/06/2008, 11h19

Merci pour ta réponse.

Je vais testé mon pgm qui fait du delete sql sans la journalisation sur la partition de DEV pour voir si cela change beaucoup le temps de traitement. (Pour infos)

Mais je n'imagine pas une si grosse différence, et cela signifierai que je ne peut faire du delete que le week end car il m'est impossible de couper la journalisation a un autre moment. De plus avec cette solution il me reste l'interrogation sur la durée du RZGPFM.

Je pense partir sur la solution par CPYF et changement de nom du fichier.

Une dernière question puis je tacherai de ne plus te perturbé.

Pense que que la gestion des index (reconstruction complète pour le coup) lors de la copie via CPYF aura un rapport équivalent ou différent en terme de perf qu'un RGZPFM suite a du delete ?

**K2R400** · 19/06/2008, 11h37

Logiquement, je pense que les temps seront comparables, car souterrainement il va faire les mêmes opérations.
Le Prb du CPYF vs SQL est qu'il faut créer une table temporaire, donc de l'espace disque sera necessaire.

Faire un CPYF des données dans un nouveau fichier récepteur.
Supprimer l'ancien fichier et ses logiques.
renommer le fichier avec l'ancien nom.
recompiler les logiques (1).

(1) Pour cette dernière opération, je te conseille de faire plutôt des create index plutôt qu'utiliser les DDS pour les LF avec clé.
Je ne parle pas des LF DDS ayant un nom de format différent du PF ou avec des Select/Omit.
Entre un create index et un LF DDS, le niveau de format sera le même, par contre en terme de perfs, pas photo !