Hi Oscar,

cache_sharing set to ON did not save us when we had this problem. Our issue was caused by setting a DMF cache to about 400Mb. AIX handles the shared memory in 256Mb segments and to address more than one of these you have to play around with a setting known as bmaxdata. This was where the confusion arose.

Cheers
Jon

-----Original Message-----
From: Oscar Carlés [mailtoscar (AT) integra (DOT) com.py]
Sent: 07 September 2005 15:25
To: Gibson Jonathan
Cc: rob.mckenzie (AT) rogers (DOT) com; info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Corrupted tables


Jon:
As I understand, this situation (having an incorrectly configured cache...) could be prevent using cache_sharing=ON.. I mean, bassically if you use cache_sharing=OFF (the default), Ingres use dynamic memory to allocate cache space on iidbms process environment, note that others Ingres memory resources like opf, psf, qsf..., use dynamic memory also. This could overwhelm the available memory and produce the table corruption. On the other hand, if you turn cache_sharing ON, Ingres use pre allocate memory (and it checks on ingstart) from OS shared memory.

Regards

Oscar

Gibson Jonathan wrote:

Hi Rob,

We've suffered from this in the past and it was caused by having an incorrectly configured cache. Basically, the cache was slightly bigger that the memory available (it took tech support several days to come up with the necessary information on how to configure a large cache on AIX and even then I wasn't convinced it was right). The other bad news is that verifydb did not work. It was unable to address the bad pages and consequently couldn't fix the problem. Even if it had, I'd say it would be 99.9% certain of losing the data "associated" with the bad pages. We were forced to restore from a backup that was valid before the corruption occurred. We managed via auditdb to work out what new policies were entered in the period the corruption occurred in but everything else had to manually re-keyed. I'm sure given enough time and patience, you could replay all your transactions but if it's an important production database, you won't be able to afford the downtime. If you have a spare machine, then you could take a ckp now and roll that onto the spare machine so you can post process the data whilst you get your system up and running.

If it's just showing one table affected, you might be able to restore that by itself in some way (OS, table recovery or full recovery to another database and do a table copy) but you'll need to work out the logical implications regarding referential integrity of your database.

Regards
Jon

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com [mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Rob McKenzie
Sent: 06 September 2005 15:34
To: info-ingres (AT) cariboulake (DOT) com
Subject: [Info-ingres] Corrupted tables


I've been luck enough to walk into, and inherit, an site that is running an unsupported version of Ingres.. My first week here has handed me three major tables in the production system that are btree and all are having headaches. CA tech support was nice enough to advise me to run verifydb which will probably patch the tables, but we may loose data.

The vesion on Ingres is: Ingres Alpha VMS Version II 2.0/9808 (axp.vms/00)

The errors we are getting are as follows:
E_DM93A7_BAD_FILE_PAGE_ADDR Page 3832 in table a, owner: proddba, database: prodacw, has an incorrect page number: 4567.
Other page fields: page_stat 00000150,
page_log_address (00000000,00000000),
page_tran_id (0000000000000000).
Corrupted page cannot be read into the server cache.
E_DM9206_BM_BAD_PAGE_NUMBER Page number on page doesn't match its location.
E_DM920C_BM_BAD_FAULT_PAGE Error faulting a page.
E_DM9C83_DM0P_CACHEFIX_PAGE An error occurred while fixing a page in the buffer manager.

There are a few others, but they are all similar in nature to the above. I ran verifydb in report mode and it finds references to missing pages. What are peoples experiences with problems like this? Has verifydb in run mode fixed these problems without data loss and total corruption? I WILL begin working on upgrading Ingres, but I can't do it today, so in the interim I'd like to get the users running again.

Thanks,



Rob McKenzie
Phone: (905) 989-1750
Cell: (905) 715-9593
Email: rob.mckenzie (AT) rogers (DOT) com

__________________________________________________ ___________________
This message has been checked for all known viruses by bluesource. For further information visit www.blue-source.com

powered by Messagelabs




************************************************** ********************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. No one else is authorised to distribute, forward,
print, copy or act upon any information contained in this email.
If you have received this email in error, please notify the sender.

Hiscox Syndicates Limited, Hiscox Insurance Company Limited, Hiscox
Connect Limited, Hiscox Underwriting Limited and Hiscox Investment Management Limited are authorised and regulated by the Financial
Services Authority. Hiscox plc is a company registered in England
and Wales under company registration number 2837811 and registered
office at 1 Great St Helen's, London EC3A 6HX
************************************************** ********************

__________________________________________________ ___________________
This message has been checked for all known viruses by blue-source. For further information visit www.blue-source.com

powered by Messagelabs




--
Lic. Oscar Carlés Barriocanal
Director de Servicios al Cliente
Íntegra S.R.L.
Telefax: (595 21) 424473 RA

__________________________________________________ ___________________
This message has been checked for all known viruses by bluesource. For further information visit www.blue-source.com

powered by Messagelabs



__________________________________________________ ___________________
This message has been checked for all known viruses by blue-source. For further information visit www.blue-source.com

powered by Messagelabs