Hi ,
We have migrated from Dollar Universe 5.0 to 5.3.3
on Linux, Solaris and AIX
We used to launch IU_RTS_V3 which launches ux_vrf_rgz_rst every week.
What should we do with 5.3.3.
-keep on IU_RTS ?
-schedule on line reorganization ?
-other ?
Vincent Pouyfaucon
Solved : Best policy for reorganization with 5.3.3 on Unix
Started by Vincent Pouyfaucon, Sep 08 2010 05:25 PM
5 replies to this topic
#1
Posted 08 September 2010 - 05:25 PM
#2
Posted 08 September 2010 - 06:19 PM
Hello Vincent,
Use the latest version of the purge: the new online purge (composed of a dynamic purge performed by the Launcher and of a non-dynamic purge performed cyclically by the IO server). Read the documentation for more details - there are some posts about it in the French and English forums (you'll be setting variable U_IO_PURGE_ENABLE to Y and defining the u_purge_param.ref file).
Michel
Use the latest version of the purge: the new online purge (composed of a dynamic purge performed by the Launcher and of a non-dynamic purge performed cyclically by the IO server). Read the documentation for more details - there are some posts about it in the French and English forums (you'll be setting variable U_IO_PURGE_ENABLE to Y and defining the u_purge_param.ref file).
Michel
#3
Posted 10 September 2010 - 09:30 AM
I understood that old purge IU_PUR is tagging lines for deletion and that reorganization delete lines in data .dta files and rebuilds Index .idx files.
Can you confirm that new online purge suppresses lines in data files and rebuilds indexes ?
Can you confirm that default values in u_purge_param.ref are something acceptable ?
I understand it keeps everything 7 days
Can you confirm that new online purge suppresses lines in data files and rebuilds indexes ?
Can you confirm that default values in u_purge_param.ref are something acceptable ?
I understand it keeps everything 7 days
men, on September 8 2010, 07:19 PM, said:
Hello Vincent,
Use the latest version of the purge: the new online purge (composed of a dynamic purge performed by the Launcher and of a non-dynamic purge performed cyclically by the IO server). Read the documentation for more details - there are some posts about it in the French and English forums (you'll be setting variable U_IO_PURGE_ENABLE to Y and defining the u_purge_param.ref file).
Michel
Use the latest version of the purge: the new online purge (composed of a dynamic purge performed by the Launcher and of a non-dynamic purge performed cyclically by the IO server). Read the documentation for more details - there are some posts about it in the French and English forums (you'll be setting variable U_IO_PURGE_ENABLE to Y and defining the u_purge_param.ref file).
Michel
#4
Posted 10 September 2010 - 11:01 AM
Hello,
The new online purge suppresses lines in data files in a similar way the uxpurge or previous version of online purge did. You still need to run online or offline reorganizations to rebuild indexes.
The default values in u_purge_param.ref are surely acceptable for some customers, but not for others - customers who wish to keep some information for longer than 7 days. You should base yourself on your current needs or/and on the existing values of your purge.
Michel
The new online purge suppresses lines in data files in a similar way the uxpurge or previous version of online purge did. You still need to run online or offline reorganizations to rebuild indexes.
The default values in u_purge_param.ref are surely acceptable for some customers, but not for others - customers who wish to keep some information for longer than 7 days. You should base yourself on your current needs or/and on the existing values of your purge.
Michel
#5
Posted 10 September 2010 - 11:02 AM
Hello again Vincent,
****
One thing though: I'm afraid I misread your initial post which clearly mentions reorganization and I've been talking purge so far...
Regarding reorganization, if you are not bothered by the downtime created by the run of the IU_RTS*, keep on using it. If this downtime bothers you, keep the IU_RTS* for cases like a file system full or system crash (let's call them recovery cases) and run the online reorganization which is far more flexible (you can reorganize area per area, some files on some days, other files on other days, etc.) as "preventive" maintenance.
Be sure to have the latest patch level for v533 if you choose to run the online reorganization.
Sorry for the confusion!
Michel
****
One thing though: I'm afraid I misread your initial post which clearly mentions reorganization and I've been talking purge so far...
Regarding reorganization, if you are not bothered by the downtime created by the run of the IU_RTS*, keep on using it. If this downtime bothers you, keep the IU_RTS* for cases like a file system full or system crash (let's call them recovery cases) and run the online reorganization which is far more flexible (you can reorganize area per area, some files on some days, other files on other days, etc.) as "preventive" maintenance.
Be sure to have the latest patch level for v533 if you choose to run the online reorganization.
Sorry for the confusion!
Michel
#6
Posted 10 September 2010 - 03:43 PM
The fact is I am bothered by the downtime.
I was cautious to use online reorganization because of what I read in documentation :
"Elle n'est ni sécurisée, ne peut pas faire l’objet d’un audit trail et ne bénéficie
pas de l'aide en ligne."
But I have the lastest patch level 24800 and I have seen it fixes some bugs of it, so I will try online reorganization uxrgz
I was cautious to use online reorganization because of what I read in documentation :
"Elle n'est ni sécurisée, ne peut pas faire l’objet d’un audit trail et ne bénéficie
pas de l'aide en ligne."
But I have the lastest patch level 24800 and I have seen it fixes some bugs of it, so I will try online reorganization uxrgz
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users













