tmpcorr has over 200 extents? What is it?
Posted in 2008
Hello all. I recently ran a query on sysmaster:sysextents and got
some unexpected results. I have searched for information about the
results I got and have yet to be successful. I was hoping one of the
learned readers of this group could offer some insight and confim if
my theory is complete bollocks or not.
IDS 9.40.UC7 on Linux. I know I should upgrade but this instances
days are numbered.
DATABASE sysmaster;SELECT
TRIM(tabname) as tabname,
count(*) as ext_cnt
FROM sysextents
WHERE
dbsname="winner"
GROUP BY 1
ORDER BY 2 DESC
The first item returned is:
tabname tmpcorr
ext_cnt 209
Yikes, lots of extents, too many, way too many. Looks like the table/
index needs to be reorged with new extent sizes, however a dbschema of
the entire database greping for the word "tmpcorr" returns zero
results. The oncheck -pe results show that all of the extents for
this object reside in temp dbspaces. I am guessing these extents are
the remnants of temporary tables? Since I can't really drop the table
"tmpcorr", any recommendations on how I could get rid of these after
images (If that is in fact what they are)?
Clancy wrote:
> Hello all. I recently ran a query on sysmaster:sysextents and got
> some unexpected results. I have searched for information about the
> results I got and have yet to be successful. I was hoping one of the
> learned readers of this group could offer some insight and confim if
> my theory is complete bollocks or not.
>
> IDS 9.40.UC7 on Linux. I know I should upgrade but this instances
> days are numbered.
>
> DATABASE sysmaster;> SELECT
> TRIM(tabname) as tabname,
> count(*) as ext_cnt
> FROM sysextents
> WHERE
> dbsname="winner"
> GROUP BY 1
> ORDER BY 2 DESC
>
>
> The first item returned is:
> tabname tmpcorr
> ext_cnt 209
>
>
> Yikes, lots of extents, too many, way too many. Looks like the table/
> index needs to be reorged with new extent sizes, however a dbschema of
> the entire database greping for the word "tmpcorr" returns zero
> results. The oncheck -pe results show that all of the extents for
> this object reside in temp dbspaces. I am guessing these extents are
> the remnants of temporary tables? Since I can't really drop the table
> "tmpcorr", any recommendations on how I could get rid of these after
> images (If that is in fact what they are)?
Yes, it is a temp table. No worries it will clean itself up and while
it exists it's only hurting the app that created it. You may want to
search your source code for the app that built the table to add an
EXTENT SIZE...NEXT SIZE clause to the create, but otherwise, you're good.
Art S. Kagel
Oninit
===========================================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.oninit.com/home/disclaimer.php
===========================================================================================