🚀 go-pugleaf

Terry Poot (tp@mccall.com) writes:
>I have an Rdb database that has grown too large. The data in it has been
>trimmed down, but I need to shrink the actual files. I don't need explicit
>directions, just for someone to point me in the proper direction. Things
>I've thought off are:
>
>1) backup/restore. Does this resize the files?

Don't remember offhand, but I don't think so.

>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.

>3) rmu/copy. Does this resize the files? Can I copy one area at a time so
>that I don't need as much free space at once? Can it be done while the
>database is in use?

I don't think you can expect to resize the files with users in the
database. I don't think RMU/COPY does much resizing anyway.

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

Yes, this would probably work, but that is not what you have storage
areas for. I don't recall offhand if you have to do an IMPORT/EXPORT
here or not, but in any case, this is a more complex operation so guess
which one which take the longest time. This could be an option, however, 
if your database is huge and only one storage area is in need of compression.
  By the way, don't just delete the files, drop the storage areas first,
unless you want a corrupt data base.

-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Dabras Laiks!