Hello,
we had a power failure on some of our boxes and some Dollar Universe index files got damaged (Unix / Windows).
We ran a reorganization which took between 15 minutes and 2 hours - which was too long.
Why was the reorganization so long? How to improve it?
We use several Areas on some boxes, but only wanted to reorganize the production Area. Is there a way to do so?
Any insight greatly appreciated!
1
2 replies to this topic
#2
-
- Root Admin
-
- 4,389 posts
Hero Member
- Gender:Male
- Location:Europe
Posted 22 January 2009 - 12:30 PM
Hello,
basically, the offline reorganization does not allow to reorganize an Area only. On the other hand, the online reorganization does allow it - but we would definitely recommend the use of the offline reorganization in such a case, as it does not require the presence of the IO Server.
This being said, the offline reorganization is nothing but a script (ux_vrf_rgz_rst) and files to be reorganized are hard-coded in it.
So you have a workaround that would consist in duplicating this script, and commenting the lines for the files / Areas you don't want to reorganize in an emergency case like yours.
The duration of the reorganization depends on various elements:
- the size of the $U data files
- the free space available on the disk(s) where $U is installed and on the disk where the temporary directory used during the reorganization resides
- the global load on the box...
The size of $U data files depends on:
- the size of the IT operations
- the purge settings (number of days kept) and its frequency
- the frequency of the reorganization
You also have to consider the "tuning" of the IT operations. For example, if a job is "conditioned" checked by the Launcher 10 or 20 times before being able to kick off, this means that it is scheduled too early (as the conditions it needs are not met yet), and there will be as many records in the history files. Logical Resources can also be very consuming in this respect.
Michel
basically, the offline reorganization does not allow to reorganize an Area only. On the other hand, the online reorganization does allow it - but we would definitely recommend the use of the offline reorganization in such a case, as it does not require the presence of the IO Server.
This being said, the offline reorganization is nothing but a script (ux_vrf_rgz_rst) and files to be reorganized are hard-coded in it.
So you have a workaround that would consist in duplicating this script, and commenting the lines for the files / Areas you don't want to reorganize in an emergency case like yours.
The duration of the reorganization depends on various elements:
- the size of the $U data files
- the free space available on the disk(s) where $U is installed and on the disk where the temporary directory used during the reorganization resides
- the global load on the box...
The size of $U data files depends on:
- the size of the IT operations
- the purge settings (number of days kept) and its frequency
- the frequency of the reorganization
You also have to consider the "tuning" of the IT operations. For example, if a job is "conditioned" checked by the Launcher 10 or 20 times before being able to kick off, this means that it is scheduled too early (as the conditions it needs are not met yet), and there will be as many records in the history files. Logical Resources can also be very consuming in this respect.
Michel
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
