Incomplete/missing db dumps using proutil

[eddiej]

We were doing a db dump & load recently and encounterd 2 problems during the dump process.

First, one table didn't dump completely. It should have dumped about 270,000 records and only dumped about 135,000.

Second, a table that should have been dumped was not dumped at all.

The dumps were run from the db (Unix) side by utilizing the Progress proutil command. Also, the proutil commands for each table dump were run from a shell script. All dump activity was written to a log file. In each of these cases, no error message were generated to the log file.

We've used these scripts before, and have never had any problems. Has anyone ever encountered this before??

-Ed

 

[Lee Curzon]

Are you saying the script consisted of several proutil commands which completed at random? This sounds very unlikely, and I have no ideas.

Or are you saying the script (say) failed to execute the last two commands properly - eg. one command exited halfway through, the last failed to execute completely.

If the latter is the case (ie. the script simply exited early), were you running the script via a parent process (eg. a telnet session) which was exited before the script finished? This may have propogated an exit to the script process.

If this is the case, see KB p60864 for a clearer explanation and solution.

 

[methyl]

There are many ways to get a short dump. A bad or empty primary index is one. Note that proutil dumps in primary index order.
If you can take the database down, try a database analysis (proutil -C dbanalys) to get a basic check of the database and a definitive record count.

Run an index check (proutil -C idxcheck) on each suspect table.
(If you get errors, see Progress Solution 27066 for the repair side and warning about backup before fix).

I once bulk loaded the same table twice to find that it appends rather than overwrites. After an error-strewn index run got one record count from a unique primary key and double the record count from a non-unique secondary key.

We've mislaid a table before when the dump filename in the schema is not unique, or when the dump filename in the schema is not lower case. However a short dump when you hit o/s limits usually gives an error message.