SYSTEMP Recovery - Aussie Developer Needs Help!! (AREV Specific)
At 13 DEC 1999 05:41:56AM Kevin Gray wrote:
Normally we are able to cope well with all AREV support.
This has caused us considerable concern ….. hopefully
someone else has experienced this situation.
Client had multiple power outages over a short period of
time and as a consequence a critical data table was
corrupted.
Yes, there are backup tapes but unable to recover from
these at this stage.
Specific table has been copied under a different name and
has subsequently been rectified using DUMPLH.
Regretfully, almost 1000 rows of data have been shifted
into SYSTEMP ….. some of these are old data but many
rows are recent data critical to system integrity.
We have copied SYSTEMP under a new name into a new data
directory so the data is secure.
We have created a separate table and copied some test data
from the SYSTEMP table into this table to view.
The dictionary for the base table has been copied into the
separate table and a screen has been created to enable us
to view the data.
Not all columns of data seem to be have been saved into SYSTEMP.
When we view 5 random rows of data only partial details have
been written into the SYSTEMP table.
How do we recover all of the data for the corrupt rows?
We would greatly appreciate any assistance.
Kind Regards,
Kevin Gray
Graycorp Pty Ltd ….. Australia
email [email protected]
At 13 DEC 1999 10:06AM Warren wrote:
Unfortunately in all probability it will be impossible to recover the missing data from the corrupt file.
The tape backup restore is your best bet.
If data is split between frames in a LH file and the forward/backward link pointers or record size headers are corrupted there is virtually no method to restore data integrity other than know exactly what each record contains and manually scanning and relinking the data chains.
GFE=Gone ForEver
At 13 DEC 1999 12:37PM Kevin Gray wrote:
Warren,
Thanks for your comments.
Client's worst nightmare come true!
Long day ahead!
Regards,
Kevin Gray
At 13 DEC 1999 02:55PM Richard Hunt wrote:
Kevin… what you have in the "SYSTEMP" table are "ROWS" that the fix routine had trouble with. They may be complete. They may be partial. And they may be multiples together. The best chance you have is to try to find the "ID"s for all the "ROWS" that are in the "SYSTEMP" table. Then from backup, restore the "TABLE" in a seperate location.
See then you can "COPYROW" the damaged "ROWS", from the restored "TABLE" back into the fixed table. Be sure NOT to restore the "TABLE" back to its original position, or to overwrite when restoring from backup.
Also the restored "ROWS" might have been modified by users since the last backup!!!! Be careful with that!
At 14 DEC 1999 01:32AM Kevin Gray wrote:
Firstly let me thank each person who responded ….. it
was re-assuring to say the least.
How we addressed the matter was thus….
Client had a safe backup from Thursday Evening so we
scheduled to recover from that.
We first secured the existing data tables by backing up within
a separate directory.
Next we deleted the corrupt table.
Following this we ran full VERIFYLH upon the whole of the live data
directory to eliminate risk of other tables having corruption.
This proved successful so we only had a single data table to rectify.
Retrieved the backup data directory into an alternate drive path upon the server.
Created a new user and attached that data directory.
Copied the valid data table into a separate directory then verified it.
Copied that data table into the live data directory and again verified.
Next we ran some subroutines to rollup the data from the past 2 days
transactions which restored all data to its rightful location. Data
within our package is table based so rollup was a simple matter.
Finally ran verifylh upon the table once more and all OK.
Lesson learnt by client ….. follow advice when it comes to securing
servers with UPS equipment appropriate to the system needs.
Thanks again
Kevin Gray