Reducing Pages HIGHWATER mark
in [DB2]
|
From: p175 on 16 Aug 2006 00:06 I've also checked the consistency flag after deactivating and it is set to yes so it appears everything should be fine. I have no idea why there would be pending pages.
From: p175 on 16 Aug 2006 00:34 Here's a listing from DB2DART *after* having run a job that included all the recommendations. What I don't understand is the highwater mark does't correspond to step 1 and subsequent tables. It starts with listing 106665 extents, but in step 1 says that the current is 6161 and reduces this by the dat object size in subsequent steps. Obviously what I need is to reclaim the 101176 extents below HWM. -------------------------------------------------------------------------------------------- Highwater Mark: 2559960 pages, 106665 extents (extents #0 - 106664) Lower highwater mark processing - phase start. Current highwater mark: 106664 Desired highwater mark: 0 Number of used extents in tablespace: 5489 Number of free extents below original HWM: 101176 Number of free extents below desired HWM: 0 Number of free extents below current HWM: 101176 Step #1: Object ID = 274 => Offline REORG of this table using the LONGLOBDATA option (do not specify a temporary tablespace). Table: DB2ADMIN.T1 DAT object size: 440 INX object size: 0 XDA object size: 0 LF object size: 0 LOB object size: 0 LOBA object size: 0 BMP object size: 0 Total size of object parts: 440 Minimum number of extents that will move by this operation: 440 Current highwater mark: 6161 Desired highwater mark: 0 Number of used extents in tablespace: 5489 Number of free extents below original HWM: 101176 Number of free extents below desired HWM: 0 Number of free extents below current HWM: 673 Step #2: Object ID = 526 => Offline REORG of this table using the LONGLOBDATA option (do not specify a temporary tablespace). Table: DB2ADMIN.T2 DAT object size: 430 INX object size: 0 XDA object size: 0 LF object size: 0 LOB object size: 0 LOBA object size: 0 BMP object size: 0 Total size of object parts: 430 Minimum number of extents that will move by this operation: 430 Current highwater mark: 5673 Desired highwater mark: 0 Number of used extents in tablespace: 5489 Number of free extents below original HWM: 101176 Number of free extents below desired HWM: 0 Number of free extents below current HWM: 185 Step #3: Object ID = 260 => EXPORT all data from table, drop the table, disconnect, reconnect, recreate the table, and LOAD the data back into the table. Table: DB2ADMIN.T3 DAT object size: 265 INX object size: 0 XDA object size: 0 LF object size: 0 LOB object size: 0 LOBA object size: 0 BMP object size: 0 Total size of object parts: 265 Minimum number of extents that will move by this operation: 265 Current highwater mark: 5488 Desired highwater mark: 0 Number of used extents in tablespace: 5489 Number of free extents below original HWM: 101176 Number of free extents below desired HWM: 0 Number of free extents below current HWM: 0 Final highwater mark: Extent #5488 (5489 extents, 131736 pages). ** This cannot be lowered further as there are not enough free extents to move the object holding the highwater mark. Lower highwater mark processing - phase end. Highwater mark processing - phase end.
From: p175 on 17 Aug 2006 01:53 Anyone ?
From: Josh Tiefenbach on 17 Aug 2006 02:17
> Here's a listing from DB2DART *after* having run a job that included > all the recommendations. What I don't understand is the highwater mark > does't correspond to step 1 and subsequent tables. It starts with > listing 106665 extents, but in step 1 says that the current is 6161 and > reduces this by the dat object size in subsequent steps. > > Obviously what I need is to reclaim the 101176 extents below HWM. Frankly, I'm a little confused by all the data that your dumping out - I really dont have a clear idea whats going on. Have you tried running db2dart with the option which prints out each extent in the tablespace, its free/used status, and which object owns it, if its in use? I believe its /LHWM - dont have the docs in front of me at the moment. Its possible that the HWM is being held up by a system page that cant be moved - but I would have thought that dart would have mentioned that. jsoh |