Forum
Forum Replies Created
-
AuthorPosts
-
4. Mai 2015 um 18:19 Uhr in reply to: Auxiliary Storage Leak seit RSU1405, REALSTORAGE_MANAGEMENT #7036
GernotAdministratorHat doch geholfen: Seit Änderung des DSNZPARM auf REALSTORAGE_MANAGEMENT=AUTO traten die eingangs geschilderten Probleme nicht mehr auf.
2. Dezember 2014 um 22:34 Uhr in reply to: Auxiliary Storage Leak seit RSU1405, REALSTORAGE_MANAGEMENT #6820
GernotAdministratorNachtrag II:
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.
Schau’mer mal, dann werd’n wir schon sehen!
Gruß
Gernot
GernotAdministratorHall0 Zefrim,
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.
Gruß
Gernot19. November 2014 um 17:13 Uhr in reply to: Auxiliary Storage Leak seit RSU1405, REALSTORAGE_MANAGEMENT #6781
GernotAdministratorNachtrag: 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.
Link zur Doku: http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.inst/src/tpc/db2z_sharedmemorystgreqs.dita
31. Juli 2014 um 12:38 Uhr in reply to: How to … transfer DECIMAL (packed) data between platforms (Unix ->z/OS) #6519
GernotAdministratorAnother 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.
LOAD INTO TABLE ... ASCII CODEPAGE(1252,0,0)
GernotAdministratorKay,
enjoy your holidays, return strengthened!
regards
Gernot -
AuthorPosts
