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.
-----Original Message-----
From: Bartram, Chris [mailto:[log in to unmask]]
Sent: Tuesday, June 19, 2001 8:07 AM
To: [log in to unmask]
Subject: Re: Image Error - Any ideas?
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.
Now that we're on 6.5 I'm hoping to relink the TPIs to the XM, but haven't
gotten a definitive answer that the 6.5 XM log file enhancements really do
solve the problem with stalled transactions (especially if the transactions
are REALLY large).
-Chris Bartram
-----Original Message-----
From: Patrick Santucci [mailto:[log in to unmask]]
Sent: Friday, June 15, 2001 12:39 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Image Error - Any ideas?
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...
Clues for the clueless, anyone?
Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Patrick Santucci
HP e3000 Systems Administrator
Cornerstone Brands, Inc.
> -----Original Message-----
> From: Mark Boyd [SMTP:[log in to unmask]]
> Sent: Thursday, June 14, 2001 2:33 pm
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Image Error - Any ideas?
>
> 3161 Index attached to XM; Turn TPI On and OFF to
repair.
>
> ...Shouldn't that have read, Turn TPI Off and On to
repair? Or, are they
> saying leaving TPI off will solve all our TPI issues?
>
> -----Original Message-----
> From: F. Alfredo Rego [mailto:[log in to unmask]]
> Sent: Thursday, June 14, 2001 10:39 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Image Error - Any ideas?
>
> At 9:39 AM -0700 6/14/01, Jeff Mikolai <[log in to unmask]>
wrote:
>
> >Any ideas? And yes, dataset 21 exists.
> >
> >Warning: An output file will be created
> >
> >TURBOIMAGE RESULT AT $00000000: RETURN STATUS = 3161
> >DBDELETE, MODE 1, ON #21 OF TRANDB.CCDATA
> >IMSAM Error 161: The file does not exist in specified
domain; the file w
> >
> >
> >An IMAGE error has occurred with the following record:
> >
> >>GET VENDOR-SWAPS (7) >OUT OUTPUT.PUB.SGAII (0)
> >
> >
> >Error: DBDELETE failed during input phase.
>
>
> Rene Woc <[log in to unmask]> sent this message directly to
Jeff (with
> copy to Adager support) and apparently forgot to send his
useful
> remarks to hp3000-L. So, here we go:
>
>
__________________________________________________________________________
> _
>
> Hi Jeff,
>
> At 10:39 AM -0600 6/14/01, Jeff Mikolai wrote:
>
> >Any ideas? And yes, dataset 21 exists.
> >
> >Warning: An output file will be created
> >
> >TURBOIMAGE RESULT AT $00000000: RETURN STATUS = 3161
> >DBDELETE, MODE 1, ON #21 OF TRANDB.CCDATA
> >IMSAM Error 161: The file does not exist in specified
domain; the file w
> >
> >
> >An IMAGE error has occurred with the following record:
> >
> >>GET VENDOR-SWAPS (7) >OUT OUTPUT.PUB.SGAII (0)
> >
> >
> >
> >Error: DBDELETE failed during input phase.
> >>
> >
>
> IMAGE return status in the 3000-range are Third-Party
Indexing errors.
>
> For 3161, file ODXERROR.PUB.DISC shows:
>
> 3161 Index attached to XM; Turn TPI On and OFF to
repair.
>
__________________________________________________________________________
> _
>
>
>
> Thanks, Rene,
>
> _______________
> | |
> | |
> | r | Alfredo
[log in to unmask]
> | e |
http://www.adager.com
> | g | F. Alfredo Rego
> | a | Manager, R & D Labs
> | d | Adager Corporation
> | A | Sun Valley, Idaho 83353-3000
U.S.A.
> | |
> |_______________|
>
> * To join/leave the list, search archives, change list
settings, *
> * etc., please visit
http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list
settings, *
> * etc., please visit
http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list
settings, *
* etc., please visit
http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
