I haven't worked with Informix, but for Oracle/SQL-Backtrack
restores (on AIX), an attempt to restore the db back to an earlier
point in time, either based on a date timestamp or on
the System Change Number (a change commit point similar
to DB2's Relative Byte Address), will result in SQL to
'ALTER DATABASE OPEN RESETLOGS'.  The RESETLOGS
basically creates a new incarnation of the database.  If you
then back it up via SQL-Backtrack, and subsequently request
another restore, (assuming your earlier backups are still available
in TSM), SQL-Backtrack will prompt you to select the specific
incarnation you want to restore.  With Oracle, this point-in-time
recovery is only available if the redo logs are being
archived off before they get overwritten (the redo logs are
circular). It sounds like the Informix 'logical' redologs
correspond to Oracle archive logs.

I don't know how germaine this is to your situation, but hope
it helps conceptually.


>>> fmolero AT YAHOO DOT COM 4/6/01 7:24:09 AM >>>
Hi colleagues,
I have a very extrange problem using the SQL Bactrack
to restore the Informix database. I don't know if it
is a problem or it is my unknoledge which causes my
alarm. In addition, I don't know if this problem
happens only in my environemnt or it occurs all SQL
BACKTRACK installations.
I am going to explain the exactly problem:

   The db has 6 redologs: 15, 16, 17, 18, 19, 20. If I
restore  the database until logical log number 16 and
then I start the db, a new logical log number 17 gets.
If later on I wish to restore the database until
logical log number 19. I find that SQL BACKTRACK tries
to do the restore using the just-created logical log
number 17, instead of the old number 17 that it really
needs.
Obviously the db cannot restore up to 19 logical log
because the active logical log number 17 does not
contain neccesary info (the info contained by old
redolog number 17)

Any ideas ???