Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Thomas J. Girsch saw oncheck -cD errors on nearly every record of a multi-million row table. Art Kagel said it was not a real problem since oncheck repaired the damage, possibly from bitmap pages not flushed after a crash, and noted one bitmap page can cover over 10 million rows. bozon asked whether two instances shared the same space. Girsch had heard it was harmless unless it persists.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Art S. Kagel — — source: Usenet: comp.databases.informix
On Aug 26, 11:36 pm, "Thomas J. Girsch" <tgir...@NOSPAM.gmail.com>
wrote:
> All:
>
> I'm seeing bazillions of these errors on some tables when I run oncheck -cD:
>
> WARNING: data page 0xe495 in tablespace 0x4f00002 appears to be
>
> more or less full than is indicated in the bitmap.
>
> Bitmap mode: 0xc, Calculated mode: 0x4.
>
> WARNING: The bitmap mode for page 0xe495 has been reset from 0xc to 0x4.
>
> Anything to worry about?
>
> Thanks,
>
> - TJG
Not a real problem. The oncheck repaired the damage. Could be that a
crash or non-standard shutdown in the past caused modified bitmap
pages to not be flushed to disk.
Art S. Kagel
Art S. Kagel wrote:
>
> Not a real problem. The oncheck repaired the damage. Could be that a
> crash or non-standard shutdown in the past caused modified bitmap
> pages to not be flushed to disk.
>
> Art S. Kagel
>
I can't imagine that would be it. It occurred for nearly every record
in a table with millions of rows. But I've heard other reports that
it's nothing to worry about unless it persists.
Thanks,
- TJG
On Aug 28, 12:20 am, "Thomas J. Girsch" <tgir...@NOSPAM.gmail.com>
wrote:
> Art S. Kagel wrote:
>
> > Not a real problem. The oncheck repaired the damage. Could be that a
> > crash or non-standard shutdown in the past caused modified bitmap
> > pages to not be flushed to disk.
>
> > Art S. Kagel
>
> I can't imagine that would be it. It occurred for nearly every record
> in a table with millions of rows. But I've heard other reports that
> it's nothing to worry about unless it persists.
>
> Thanks,
>
> - TJG
You don't have 2 instances sharing the same space do you? Otherwise I
agree with what you have heard.
↪ replying to Thomas J. Girsch
Art S. Kagel — — source: Usenet: comp.databases.informix
On Aug 28, 12:20 am, "Thomas J. Girsch" <tgir...@NOSPAM.gmail.com>
wrote:
> Art S. Kagel wrote:
>
> > Not a real problem. The oncheck repaired the damage. Could be that a
> > crash or non-standard shutdown in the past caused modified bitmap
> > pages to not be flushed to disk.
>
> > Art S. Kagel
>
> I can't imagine that would be it. It occurred for nearly every record
> in a table with millions of rows. But I've heard other reports that
> it's nothing to worry about unless it persists.
But each bitmap page describes over 4000 pages and depending on
pagesize and rowsize a single bitmap page can affect more than
10million rows!
Art S. Kagel
Your privacy choices
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.