🚀 go-pugleaf

In article <1992Jul29.091451.3169@otago.ac.nz>, cscdba@otago.ac.nz (Donald
Ellis) writes:
>In article <1992Jul26.091514.21517@enea.se>, sommar@enea.se (Erland Sommarskog)
>writes:
>> Terry Poot (tp@mccall.com) writes:
>>>2) Import/export. Sounds like a slow process.
>> 
>> Well, you have a large file with a lot of holes in which you want to
>> remove. Does that sound like a fast process to you. IMPORT/EXPORT
>> is the standard method to handle this problem, as far as I know.
>Agreed

Sounds like the consensus. Unfortunately it means a working weekend trip to NYC.
I have no idea if it could do it overnight, and the DB has to be up during
normal weekday office hours. 

>>>3) Create new areas and use change storage map to move the data,
>>>then delete the old files. Same questions as above.

>If you want to take this path I would be inclined to create the new storage
>areas, unload the data using RMU/UNLOAD, delete the rows of the table you have
>just unloaded, then use ALTER STORAGE MAP to store the table in the new
>storage area then use RMU/LOAD to reload the data into the table. 

That defeats the whole purpose, which was to do it unattended and without taking
the database down (to avoid the aforementioned trip). I thought Rdb would move
the data without the unload/load.

>When you have
>transferred all the tables into the new storage area(s) then DROP STORAGE AREA
>to get rid of the old large files. If you don't have many tables this is a
>viable way of doing this but EXPORT/IMPORT would still be my first choice. 

Only 3 tables and 3 indices. Most of the data is in segmented strings in 2 of
the tables. The segmented string area is the one in the most need of shrinking,
though the others are bloated in similar proportion to the size they should be.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA