Hello!

I'm not very experienced with the background processes of space management behind DB2, so my question may be stupid.... I already searched the DB2 Administration Guide and the dbforums.com archives, but I fear I'm searching with the wrong search terms.

DB2 Version 7, runnning under OS/390.

I have a 3 big tables (each 40GB+) in 3 tablespaces and lots of the information isn't needed anymore, but should be "retrievable". I'm getting problems with the space management guys.

Now I'm unloading parts of the content with DSNUPROC and sending the SYSREC00s to MIGRATIONLEVEL2, thereafter deleting the rows in the tables.

Now the question is: when is the physical disk space behind the tablespace actually reduced? Does a REORG suffice? Is there anything else I have to do? All the tuning guides only have information about extending the tablespaces or compressing data that remains online but what about getting rid of it?

Thanks for your help!

M.

Normally a REORG will restore the size of the dataset allocation to the PRIQTY size specified in the CREATE or ALTER TABLESPACE command. Of course, if the data will not fit in the PRIQTY, then DB2 will start allocating secondary extents as specified in SECQTY.

However, if you allocated your own VSAM datasets instead of using STOPGROUPS, then the PRIQTY and SECQTY are defined in the VCAT definition outside of DB2.

If the PRIQTY is too large for the remaining data on the table, then lower this value and perform a REORG. DB2 will delete and recreate the underlying VSAM dataset as part of the REORG using the new dataset space allocations you defined.

Thanks a lot! I'm working with STOGROUPS and I'll do that. I just wasn't sure if REORG was automatically reducing the VSAM datasets.

Regards,

M.

How does this differ with tablespace allocation and reorgs on DB2 UDB running under UNIX?

Unfortunately, it is different for other DB2 platforms. DB2 for OS/390 is much easier in this regard.