Re: Warm recover failure question

> But LTAPE parameter is '/dev/null'. I think the "Inconsistent Status" is > logically right whether the engine is restarted, or not. > I think so because the logical recovery cannot make the dbspace up to date.. > > Am I correct ?? You are partially correct. Without log backups, there can be no logical recovery, and the database can not recover any transactions since the last archive. The part that is incorrect is your statement that the "inconsistent status" is logically correct. The Informix archive process creates a logically consistent archive of the complete database as it existed at the beginning of the backup. It does this by taking a checkpoint at the beginning of the backup and including any logical logs with open transactions in the archive. When the restore happens, if you do not restore any log files, any transactions that were open at the beginning of the archive process are rolled back by using the logical log copies that are included within the archive. The end result is a logically consistent restored database with all data that had been committed at the time the archive began. Mark Collins mcollins@us.dhl.com

Hi, thank you for replying. Could you consider this situation ? You created a table in datadbs1 and a index for that table in datadbs2. You backuped with ontape on monday, and restore only datadbs1 on saturday with the previous archive. Then the real data in datadbs1 and the index for the data in datadbs2 can be different version(datadbs1 is 1 day late). So without logical recovery your datadbs1 is flagged as inconsistent status. I think it is same if you use onbar... mcollins@us.dhl.com wrote: > > But LTAPE parameter is '/dev/null'. I think the "Inconsistent Status" is > > logically right whether the engine is restarted, or not. > > I think so because the logical recovery cannot make the dbspace up to date.. > > > > Am I correct ?? > > You are partially correct. Without log backups, there can be no logical recovery, > and the database can not recover any transactions since the last archive. The > part that is incorrect is your statement that the "inconsistent status" is > logically correct. The Informix archive process creates a logically consistent > archive of the complete database as it existed at the beginning of the backup. It > does this by taking a checkpoint at the beginning of the backup and including any > logical logs with open transactions in the archive. When the restore happens, if > you do not restore any log files, any transactions that were open at the beginning > of the archive process are rolled back by using the logical log copies that are > included within the archive. The end result is a logically consistent restored > database with all data that had been committed at the time the archive began. > > > > Mark Collins > mcollins@us.dhl.com

Hi, thank you for replying. Could you consider this situation ? You created a table in datadbs1 and a index for that table in datadbs2. You backuped with ontape on monday, and restore only datadbs1 on saturday with the previous archive. Then the real data in datadbs1 and the index for the data in datadbs2 can be different version(datadbs1 is 5 days late). So without logical recovery your datadbs1 is flagged as inconsistent status. I think it is same if you use onbar... mcollins@us.dhl.com wrote: > > But LTAPE parameter is '/dev/null'. I think the "Inconsistent Status" is > > logically right whether the engine is restarted, or not. > > I think so because the logical recovery cannot make the dbspace up to date.. > > > > Am I correct ?? > > You are partially correct. Without log backups, there can be no logical recovery, > and the database can not recover any transactions since the last archive. The > part that is incorrect is your statement that the "inconsistent status" is > logically correct. The Informix archive process creates a logically consistent > archive of the complete database as it existed at the beginning of the backup. It > does this by taking a checkpoint at the beginning of the backup and including any > logical logs with open transactions in the archive. When the restore happens, if > you do not restore any log files, any transactions that were open at the beginning > of the archive process are rolled back by using the logical log copies that are > included within the archive. The end result is a logically consistent restored > database with all data that had been committed at the time the archive began. > > > > Mark Collins > mcollins@us.dhl.com