Schnizzled Blob
IDS 10.00.UC8 Solaris 10 I don't think this is an issue but I can't remember if there is anything I can do - I saw these messages (warnings) during our last backup (abridged): Archive detects that page 291:80343 is corrupt. Archive detects that page 291:80343 is corrupt. 52623400: 00000000 00000000 00000000 00000000 ........ ........ 52623410 * There were a few others. The chunk belongs to a blobspace. What the pages all have in common is they follow a set of valid blob pages and appear to be former blobs that were deleted. Our blob page size is 4K - if I dump the 2 pages before the reported corrupt page I see a valid set of blob pages then I dump the reported page and it is all zeros. I don't recall that we zero out blob pages when we delete the row that refs it... ideas? MM
When IDS restores a page from the archive tape it places them where the page address of tape specifies. If this page address is wrong for whatever reason and IDS does not fix it then it could corrupt another page. Hence when we take an archive we ensure all pages address are correct when plaicing the data on tape. If we have to fixup a page address because it is wrong then you will see the following message Archive detects that page 291:80343 is corrupt. Off the top of my head I am not aware of cases when we remove the page header from blob pages. In fact the way IDS writes blobs this is very hard to see ever happening. John F. Miller III STSM, Support Architect miller3@us.ibm.com 503-578-5645 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 10/22/2009 09:51:58 AM: > [image removed] > > Schnizzled Blob [17687] > > MIKE MAGIE > > to: > > ids > > 10/22/2009 09:53 AM > > Sent by: > > ids-bounces@iiug.org > > Please respond to ids > > IDS 10.00.UC8 > Solaris 10 > > I don't think this is an issue but I can't remember if there is > anything I can > do - > > I saw these messages (warnings) during our last backup (abridged): > > Archive detects that page 291:80343 is corrupt. > Archive detects that page 291:80343 is corrupt. > 52623400: 00000000 00000000 00000000 00000000 ........ ........ > 52623410 * > > There were a few others. The chunk belongs to a blobspace. What the pages all > have in common is they follow a set of valid blob pages and appear to be > former blobs that were deleted. Our blob page size is 4K - if I dump the 2 > pages before the reported corrupt page I see a valid set of blob pages then I > dump the reported page and it is all zeros. I don't recall that we zero out > blob pages when we delete the row that refs it... ideas? > > MM > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
So would you guess that we will continue to see the warnings? The instance that is producing the errors WAS restored fairly recently from another instance's backup. I just want the messages to go away as I am fairly certain the table is fine - it is accessed a ton, if there were any real issues with it we would have known by now.