4 replies to this topic

[Silverdollar]

HP Unix server, $U 5.2.3, offline backup followed by a reorg each week.

All works fine but have noticed space warnings now as the backup is getting biggeer and bigger. Checking the reorg also noticed a very large data file u_fmcm 50 in the production area, 146851826 bytes with correspondingly large index, 14721141 bytes.

The reorg of this structure is taking nearly 50 minutes on a fast machine. There are other structures which as also starting to creep in size, for instance u_fmhs50 - execution history is currently size 134662567 bytes.

Contacting Orsyp support and they advised using ux_raz_fic to initialise the structure. All very well and good but a couple of things.

- This seems a bit heavy handed especially as this is the production system and will involve loss of data
- This does not solve the underlying issue and this process will need to be repeated in a few months time

Is there a way to restrict how long or how much information is held in $U structures like this. In this case the structure is the Journal of Launch interventions.

Other structure that have had problems in the past but seemed to have calmed down with a patch (FX24520) were

u_fmsb50 - launches
u_fmsp50 - Launching parameter storage (provocation)
u_fmtp50 - Launching parameter storage (sessions)

[men]

Hi Silverdollar,

What type of purge are you using?

- uxpurge
- continuous purge
- both together (needs caution)

Michel

[glc]

Agreed with Michel, purges and retention should help you a lot.

Maybe we can provide you more information about them here, but $Access can help you to define it prroperly considering your production load (or maybe it will be professionnal services, I'm not sure).

Guillaume

[Silverdollar]

The only purge running would be continuous purge but it looks like the setting need to be changed as the data files are getting too big. Each week there is an offline backup and reorg.

More to the point what does this particular data file actually do? Journal of Launch Interventions???? Why does it need to be so large?

(Technical help advised reinitilising the data structure and I am yet to hear from them as to what this will do as it is deliberately deleting data and this is on the main production system.)

[men]

Hello,

I know that some data was not correctly purged by the continuous purge and that is the reason why it has been revisited and enhanced in release 533.

Tech Support should be able to confirm if file u_fmcm50 is one of these - if they don't have the information right away they should be able to get it through R&D.

u_fmcm50 only contains the information that is displayed in the "Intervention history window". Have a look in there, and if you feel you can do without it, go for the razfic. The file is inded only used like a journal of launch interventions and does not have any impact on your production. What's more, if you have activated the audit trail, you should be able to find similar information there.

If doing a razfic on this file still makes you uncomfortable, you may want to give the following a try:

Have uxpurge also run (this is the old purge that was available in the previous versions of DU and available in the IU_PUR Uproc).

For more information check this thread and be very careful that
the parameters of the uxpurge should be set higher to the ones of the purge on the fly to avoid any side effect!

Michel