Patrick Santucci wrote:
>>>Or does it mean Indexes (sic) shouldn't be attached to XM? Our
>>>Programming Manager firmly believes that every time we have a system
>>>crash, we have to drop and reinstall *all* our TPI indexing -- and then
>>>reindex everything, which takes several hours. I've never encountered
>>>this before, anyone heard of it? But if TPI is not attached to XM, that
>>>might begin to explain it...

Makes sense to me.  XM can't protect the logical (or even physical)
integrity of files that aren't attached to it.  I think it's just like
using Image with "deferred output" enabled... which I gather detaches the
database from XM.  If you have a system crash while modifying the database,
there's nothing protecting the database.

I don't know any reason why database indices [SIC  ;) ] should not be
attached to XM (except Chris makes a good case below for his circumstance),
but given that they aren't attached to XM, then if the system crashes any
that might have pending writes at the time of the crash are likely busted.

To which Chris Bartram replied:
>>We had to detach our TPI indexes from the XM some time ago because of
>>stalled transaction problems. And yes, we have discovered that when we
>>restore the databases from a online-backup, we have to reindex.  Haven't
>>had to recover from a sys fail in a long time (knock on wood) but I'm
>>sure we would have to reindex then also.

If by "online-backup" you mean "zero-downtime online-backup" (some or all
of which I believe is a trademark of Orbit Software, but in this case I
mean any of the vendors' online-backup which attempts to synchronize files
without having exclusive [really "no writer"] access at least long enough
to establish the sync point) then, it's "normal" that restoring from that
backup has only the same assurances of logical and/or physical integrity
that rebooting after a system failure has.

After which John Clogg replied:
>Reindex after a restore?  Have you managed to get a coherent explanation
>as to why this is necessary?  Assuming both the database and its index
>files are successfully stored, this shouldn't be necessary.  I know some
>backup products have had the problem that specifying DBSTORE does NOT
>force all index files to be stored, so you need to use a fileset that will
>ensure that they are stored.  I also recall a problem where the creator of
>the files had to be corrected with MPEX, but I believe that was an issue
>only when moving the database to a different account.

Note that Chris said "online-backup" and presuming he meant an online
backup without downtime to establish a consistent logical synch-point, then
whatever recovery steps one would need to take after a system abort would
also need to be taken to ensure logical consistency after restoring from
such a backup.

That probably seems counter-intuitive but it's the reality.  Applications
which define logical transactions properly (ala DBXBEGIN) and which have
all associated files (spanning multiple databases and all their indices
etc) attached to one XM log should not need recovery after restoring from
an online backup.

Logical integrity doesn't come for free.  If your application doesn't
define to the system (in this case Image and XM) when a transaction begins
and ends then it's not only possible but likely to catch the application
with half an offsetting credit-debit (or analogous, as in updating indices)
posting completed by any of an application abort, a system abort or a
no-downtime-online-backup.

As a developer of Unison Software's RoadRunner for MPE (now Backpack from
ROC Software) at the time, I struggled to make clear in the manual and
release notes when "no downtime online backup" was introduced and have
personally never been satisfied that the dangers inherent in a typical
application environment were made clear enough.  The same issue confronts
all of the no-downtime-online-backup vendors to the best of my
understanding (TurboStore, BackPack nee RoadRunner, and [perhaps with a
different window of vulnerability due to an alternative technique for
determining the synch-point] Backup+), or at least it did when I worked on
RoadRunner a few years back.


P.S.  PLEASE, people, delete the garbage off the end of emails!  The
archives have all the old messages if someone wants to go re-read one (or
even all of them).  I just deleted *five* copies of the list trailer from
this reply plus a lot of other lines of uselessly quoted email at the
end.  If you insist on inserting new comments at the top of a message
(which I think is a poor choice) then *please* delete old unneeded
artifacts below it.

-- Jeff Woods
"The great thing about Open Source software is that you can
have any color screen of death that you want." -- Gavin Scott

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *