Informix Database Restore
Hi, I am trying to restore a PROD database to our QA server. The QA server lost a disk, it was replaced and now we are trying to restore. We are running Informix 7.31.FD2X9 and have done this type of operation on numerous occasions. This time, I get the error below. 2011-03-14 13:15:02 21935 21933 Begin cold level 0 restore rootdbs. 2011-03-14 13:15:02 21935 21933 ERROR: Unable to write restore data to the database server: I/O write failure on : page 1048576. Is there any as to correlate between the page and the chunk which contains that page to see if there is a problem wit the chunk. We have hundreds of chunks and permissions have been verified and re-verified on all of them. Any help would be appreciated.
That's chunk #1 page #0 the first reserved page in the rootdb space. Just convert the number to hex, the five lowest order hex digits are page number in chunk and the three high order hex digits are the chunk number. 1048576 is 0x00100000 Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Mar 14, 2011 at 1:42 PM, ANTONIO VARRICCHIO < antonio.varricchio@domtar.com> wrote: > Hi, > > I am trying to restore a PROD database to our QA server. The QA server lost > a > disk, it was replaced and now we are trying to restore. We are running > Informix 7.31.FD2X9 and have done this type of operation on numerous > occasions. This time, I get the error below. > > 2011-03-14 13:15:02 21935 21933 Begin cold level 0 restore rootdbs. > 2011-03-14 13:15:02 21935 21933 ERROR: Unable to write restore data to the > database server: I/O write failure on : page 1048576. > > Is there any as to correlate between the page and the chunk which contains > that page to see if there is a problem wit the chunk. We have hundreds of > chunks and permissions have been verified and re-verified on all of them. > > Any help would be appreciated. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf307f381a51ac25049e74f077
SOLUTION -- it's never the database I asked the UNIX team to drop and re-create all Logical Volumes and ensure permissions were set correctly. Restore worked fine. Thanks for the replies