Der DSNZPARM REALSTORAGE_MANAGEMENT=AUTO hat nach meiner Auffassung bislang keinerlei Änderung und schon gar keine Verbesserung gebracht: Laut IFCID 225 hat sich der Real Storage Verbrauch kaum verändert, also nicht reduziert. Auch der Auxiliary Storage (AUX) Verbrauch blieb ähnlich – erstaunlicherweise steigt der AUX-Verbrauch jedes Wochenende -der Verdacht ist, dass der Online REORG dieses Phänomen auslöst.
was meinst Du mit „möchte diese Tabelle deleten“? Ist ein DROP TABLE damit gemeint, oder ein Mass Delete, oder ein „normaler“ DELETE einzelner Rows, searched oder positioned?
Ein DROP TABLE erhebt natürlich ganz andere Ansprüche, als ein Row-DELETE.
Nachtrag: Im der DB2 10 Installation Guide steht folgendes …
Shared memory storage requirements
Shared memory is a type of virtual storage that allows multiple address spaces to easily address storage that is common to DB2® address spaces. This memory resides above the 2 GB bar.
The shared memory object is created at DB2 startup, and all DB2 address spaces for the subsystem (DSN1DIST, DSN1DBM1, DSN1MSTR, and Utilities) are registered with z/OS® to be able to access the shared memory object.
To define the size of the shared memory and the 64-bit common area, use the HVSHARE and HVCOMMON parameters of the IEASYSxx member in the parmlib concatenation.
Restriction: Ensure that you have defined a high enough value for HVSHARE to satisfy all component requests for shared memory within the z/OS image. The default value is 510 TB. DB2 Version 10 requires 160 GB of contiguous 64-bit shared private storage for each DB2 subsystem above the 2 GB bar. This storage is virtual, and it is controlled by the z/OS HVSHARE parameter in IEASYSxx. This storage is not backed at allocation, only as it is used. You can monitor the space usage with IFCIDs 0225 and 0217.
IFCID 0225 has statistics that you can use to determine the amount of currently defined storage and how much of it is currently allocated.
Another option/work-around is first to load into a DB2 for z/OS table and then externalize/UNLOAD/DNSTIAUL the data again. DB2 differentiates between internal and external data formats (text). So, it protects decimal/integer/date/time/timestamp/… data for being translated.