Tom:
I think I know why the blob pages are not being freed. Unlike BLOBSPACE blobs, for TABLESPACE blobs, if the blob entry is smaller than a page multiple blobs are stored on a page. If when you deleted the old rows their blobs were on pages that still have other blobs on them, those pages couldn't be freed. It may be that the REPACK code doesn't move the blobs to consolidate them onto fewer pages. If so, when the details from the oncheck come in, they will show lots of free space on blob pages.
Anyone at HCL want to comment?
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com------------------------------
Original Message:
Sent: Tue March 08, 2022 03:25 PM
From: TOM GIRSCH
Subject: Repack/Shrink With In-Table BYTE Columns
Preliminary output (waiting for the detailed stuff to complete):
Number of pages allocated 12281265
Number of pages used 12281265
Number of data pages 812482
Number of rows 27955341
Looks like it isn't freeing up the blobpages.
Tom Girsch
Lead System Architect
Auto Europe Group
tgirsch@autoeurope.com
Office #207-842-2139
" If you think there is something more important than a Client ... think again "
Original Message:
Sent: 3/8/2022 3:12:00 PM
From: Art Kagel
Subject: RE: Repack/Shrink With In-Table BYTE Columns
Tom:
What does the oncheck -pT report show?
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
Original Message:
Sent: Tue March 08, 2022 03:05 PM
From: TOM GIRSCH
Subject: Repack/Shrink With In-Table BYTE Columns
All:
I have a couple of tables that have millions of records and each of which has one BYTE column stored in-table. I've deleted over a million records from each of them (probably accounting for about 35% of the total records in the table) and then did 'table repack shrink,' which claims to have succeeded. However, no space was actually reclaimed. The records were inserted years ago and we back up logical logs on an ongoing basis, so I can't imagine the must-also-back-up-the-log thing is an issue. I've done the same thing with several other tables that do not contain BYTE or TEXT types and the space reduction was immediately apparent for those. EXTENT and NEXT sizes are sufficiently small that we should see plenty of space freed up. I ran the repack shrink multiple times and still nothing.
Has anyone else encountered anything like this? Am I looking at a bug? Missing something obvious?
IDS 14.10.FC7W1 on Linux x86_64
TIA,
- TJG
------------------------------
TOM GIRSCH
------------------------------
#Informix