Fast recovery problem
Hi, We did have database which was in nonloggin mode and checkpoint did hang. We shutted down the informix and started it up. When we started the informix, it did perform Fast Recovery. Last checkpoint was 14.8.2014(DMY) 03:00 and this happended 15.8.2014 17:49. So all that day data went missing. My question is, is the data somewhere? inside the chunks? can it be recovered? Other question is, we did have incremental backup L0 sunday, L1 monday L2 Tuesday L1 Wednesday, L2 Thursday L1 Friday. No That L1 is wery big about 1,7G where other L1 and L2 are about 200M. Is there any way to check what is inside that L1? We assume that there is that state after the Fast Recovery(all that day data missing), but the size of that L1 is interesting. That you wery much for helping me.
If the checkpoint was incomplete, then the dirty pages would only be in= the buffer. So if the checkpoint was incomplete, then I am afraid that the= data is lost. Why are you using a no logged database? Sent from my iPad > On Aug 17, 2014, at 10:15 AM, "MATTI JAATINEN" <matti.jaatinen@norelco.fi> wrote: > > Hi, > > We did have database which was in nonloggin mode and checkpoint did h= ang. We > shutted down the informix and started it up. > When we started the informix, it did perform Fast Recovery. Last checkpoint > was 14.8.2014(DMY) 03:00 and this happended 15.8.2014 17:49. So all t= hat day > data went missing. > > My question is, is the data somewhere? inside the chunks? can it be recovered? > > Other question is, we did have incremental backup L0 sunday, L1 monda= y L2 > Tuesday L1 Wednesday, L2 Thursday L1 Friday. > No That L1 is wery big about 1,7G where other L1 and L2 are about 200= M. > > Is there any way to check what is inside that L1? We assume that ther= e is that > state after the Fast Recovery(all that day data missing), but the siz= e of that > L1 is interesting. > > That you wery much for helping me. > > > ***********************************************************************= ******** > Forum Note: Use "Reply" to post a response in the discussion forum.= >=
Hi, Problem was that in times among the logging was quite a slow compared to non logging(slow server and bad use of transactions(the developer sql)) and that's why we used unlogging. We do not have anymore unlogging, switched to nonbuffered logging :)
Smart decision! Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on 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, Aug 18, 2014 at 12:27 AM, MATTI JAATINEN <matti.jaatinen@norelco.fi> wrote: > Hi, > > Problem was that in times among the logging was quite a slow compared to > non > logging(slow server and bad use of transactions(the developer sql)) and > that's > why we used unlogging. > > We do not have anymore unlogging, switched to nonbuffered logging :) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c25eb2ef63bc0500e5c7b0