Re: Discussion: Is a server with truncated logs safe?

This is my personal opinion. Not my professional opinion nor my employer view. If the logs were "truncated" you should have the database in a perfectly consistent state, but "in the past". You will have problems if your system communicate with others, they may have received information from it that currently it doesn't have. Or that the other systems assume they have sent information to yours that it currently does not recognize. Also some users may find strange things, like having invoices printed that are not stored on the system etc. Note that an export/import of the system will not solve any of the above... Ideally you should at least run complete onchecks... but these also take time and may cause outage. What you should also proceed is to find the root cause (if possible). If it's caused by a bug, you should upgrade ASAP. If the root cause was the server crash (and this caused corruption) than the recommendation would certainly be to export/import. Finally, there is a difference between "truncate the logs" and "tweak the logs". Technical support can truncate the whole logical log, leaving your system in a certain point in time, or eliminate some LL records that are causing problems. What was done may influence the decision to export/import Regards. On Thu, May 5, 2011 at 12:08 PM, Jarrod Teale <Jarrod.Teale@fonterra.com>wrote: > So today we had the mother of all nasty scenarios. > > The server crashed and when restarting said “Cannot roll forward from > checkpoint, contact IBM support”. > > Logical logs were in a mess. Not good. So IBM dial in and truncate the logs > and sort the system out so it starts – yeah for onlog J > > They recommend not using the database anymore, but unloading everything and > moving it to a new instance to ensure consistency. > > > > I buy the argument completely and it is the right thing to do. > > > > But... The issue I have is this – we can’t really afford the downtime until > the milk season winds down for winter in a month or two. > > So... my question. > > What is the consensus about running on a database that has been log > truncated? > > > > I want opinion on how urgent the full server rebuild is. > > If we have to do it today, then we need to try to find a way to do it with > as little downtime as possible because the plant will still be running. This > will be VERY complicated and basically the definition of annoying. > > > > On your marks, get set, discuss... > > > > Thanks > > > > Jarrod Teale > > [image: Fonterra 70px wide] > > Process Information Manager > > Automation and Process Control > > jarrod.teale@fonterra.com > direct +64 7 850 7525 (ext 77525), mobile +64 21 968 364, fax +64 7 849 > 7855 > Fonterra Co-operative Group Limited > PO Box 459, Hamilton, 3240, Automation and Process Control, Fonterra Te > Rapa, SH1, Hamilton, New Zealand > > [image: droplet-03] > > > > ------------------------------ > DISCLAIMER > This email contains information that is confidential and which may be > legally privileged. If you have received this email in error, please notify > the sender immediately and delete the email. This email is intended solely > for the use of the intended recipient and you may not use or disclose this > email in any way. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Hello Jarod, -> They recommend not using the database anymore, but unloading everything and -> moving it to a new instance to ensure consistency. -> I buy the argument completely and it is the right thing to do. -> But... The issue I have is this – we can’t really afford the downtime until -> the milk season winds down for winter in a month or two. If a chunkfree list is a mess eq it does not count space allocated for a table which has claimed space you could end up having tables overlap which is one of the more serious scenarios that could happen. You will end up with major corruption and maybe with another crash having TS zero the logs again. It is time to bite the bullit and unload all recreate the instance and reload. Ask yourself the question if you can afford to run the risk. ( i would not take the risk!!!!!!!) dbexport may be used for it dependant on the db's size ; import may fail due to a incorrect row count.-->> check it. maybe Arts stuff or Jonathans stuff can help you here... Superboer.