Fix oncheck -pT WARNING messages?
Posted in 2018
Topics: Installation, Setup & Upgrades, Data Types & Schema Design
IDS 12.10.FC3
Solaris 10 1/13
This thread follows from a previous thread:
http://members.iiug.org/forums/ids/index.cgi/read/41114
in which there was an issue of Server Studio space usage reporting that I
didn't understand, and output of oncheck -pT that I also didn't understand.
Because this lvarchar issue seems like it may have been corrected in a later
version of IDS (and also just because it's been 4 or 5 years since we
upgraded), I decided to upgrade from IDS 12.10.FC3 to 12.10.FC11. Then, I'll
revisit this space issue and see if it is still an issue.
So, I plan to do an in-place upgrade.
I ran "oncheck -pt <database>", and no issues are reported. I ran "oncheck -pT
<database>" and get about 1 million "WARNING: data page <whatever> in
tablespace <whatever> appears to be more or less full than is indicated in the
bitmap" in various tables.
There were no ERROR messages.
Is there any danger? Should I run 'oncheck -pT -y <database>' before doing the
in-place upgrade?
Thank you.
DG
P.S. This database only produces the oncheck -pT WARNINGs on our production
server. When I dbexport/dbimport that database to another server, there are
zero oncheck WARNINGs about size of data pages. The WARNINGs only appear in
the original database.
It appears that the WARNINGs about bitmap size didn't impede the in-place upgrade. I restored an archive of production into an instance on another machine, then did the in-place upgrade on that. Seems to be just fine. DG
Check https://www-01.ibm.com/support/docview.wss?uid=swg21675845 . Maybe it a applies to your case.
Hi, probably your problem relates to defect: IT00781 EVEN WITH THE FIXES FOR IC98053 AND IC98529 THE ONCHECK -CD CAN REPORT WARNING: DATA PAGE APPEARS TO BE MORE OR LESS FULL This was fixed in 11.70.xC8W1 and I think it was also a bug in early 12.10 releases. I would expect that the table reporting the error has one of more varchar columns and I don't think it matters what you set MAX_FILL_DATA_PAGES to. I think the main consequence of the defect is that bitmap pages that should indicate the pages they describe are full do not and, therefore, the engine can end up inspecting the data pages to look for empty space rather than skipping past them. This can slow down inserts when all the extents for a table or index are nearly full; if the tables are large the slow down can be quite considerable. If you didn't see this defect there is nothing to worry about and I can see from your other post that your upgrade went well. Ben.