Greetings All,



I recently found it necessary to recover an inconsistent dB where the
checkpoint was flagged as a good one, but re-applying the journals failed

With 'redo error' so the completion of the rollfowarddb process was still an
inconsistent db.



Further investigation found that there was only one table with this error,
so we ran auditdb -table=schedules >file.txt to capture all transactions
against the table,

Then run rollforwarddb verbose to get the failurepoint, identified it in the
auditdb output file, then

Finally run rollforwarddb with the ignore flag so the final result was a
fully restored and up to date dB with the exception of the

one table, which was then made physically and logically consistent, then
manually had to read the statements from the relevant point in the auditdb
output file and reapply them



The output from auditdb is not the clearest / easiest to read and
understand.





What I think would be a really useful addition to auditdb would be something
like "-SQL" as an option

Whereby auditdb would format its output into a correctly sequenced set of
SQL statements that

Could be manually applied via sql or isql



When I initially found the fail point in the auditdb output file, it was on
page 4 of 26

So most of the recovery time was spent working the output file to identify
and apply each transaction.







Thoughts??









Cheers





Richard

/***************************\

\***************************/

Hi Richard,



Have you looked at Ingres Journal Analyser?



It can generate recovery SQL for single record updates through to complete
transactions over a range of dates.

It can also run the SQL through the interface. I chose to save the SQL to a
separate file then ran it myself.



The user interface requires a bit of practice.

Watch for performance problems when running over a big date range.

I suggest trying it on a small date range, single table update first.



Paul











From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Richard
Harden
Sent: Wednesday, 15 June 2011 1:39 PM
To: 'Ingres and related product discussion forum'
Subject: [Info-Ingres] Thoughts on a possible additional flag to auditdb



Greetings All,



I recently found it necessary to recover an inconsistent dB where the
checkpoint was flagged as a good one, but re-applying the journals failed

With 'redo error' so the completion of the rollfowarddb process was still an
inconsistent db.



Further investigation found that there was only one table with this error,
so we ran auditdb -table=schedules >file.txt to capture all transactions
against the table,

Then run rollforwarddb verbose to get the failurepoint, identified it in the
auditdb output file, then

Finally run rollforwarddb with the ignore flag so the final result was a
fully restored and up to date dB with the exception of the

one table, which was then made physically and logically consistent, then
manually had to read the statements from the relevant point in the auditdb
output file and reapply them



The output from auditdb is not the clearest / easiest to read and
understand.





What I think would be a really useful addition to auditdb would be something
like "-SQL" as an option

Whereby auditdb would format its output into a correctly sequenced set of
SQL statements that

Could be manually applied via sql or isql



When I initially found the fail point in the auditdb output file, it was on
page 4 of 26

So most of the recovery time was spent working the output file to identify
and apply each transaction.







Thoughts??









Cheers





Richard

/***************************\

\***************************/

Hi Paul,



No I hadn't,



But I will now thanks









Cheers





Richard

/***************************\

\***************************/



From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Paul
White
Sent: Wednesday, 15 June 2011 5:01 p.m.
To: 'Ingres and related product discussion forum'
Subject: Re: [Info-Ingres] Thoughts on a possible additional flag to auditdb



Hi Richard,



Have you looked at Ingres Journal Analyser?



It can generate recovery SQL for single record updates through to complete
transactions over a range of dates.

It can also run the SQL through the interface. I chose to save the SQL to a
separate file then ran it myself.



The user interface requires a bit of practice.

Watch for performance problems when running over a big date range.

I suggest trying it on a small date range, single table update first.



Paul











From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Richard
Harden
Sent: Wednesday, 15 June 2011 1:39 PM
To: 'Ingres and related product discussion forum'
Subject: [Info-Ingres] Thoughts on a possible additional flag to auditdb



Greetings All,



I recently found it necessary to recover an inconsistent dB where the
checkpoint was flagged as a good one, but re-applying the journals failed

With 'redo error' so the completion of the rollfowarddb process was still an
inconsistent db.



Further investigation found that there was only one table with this error,
so we ran auditdb -table=schedules >file.txt to capture all transactions
against the table,

Then run rollforwarddb verbose to get the failurepoint, identified it in the
auditdb output file, then

Finally run rollforwarddb with the ignore flag so the final result was a
fully restored and up to date dB with the exception of the

one table, which was then made physically and logically consistent, then
manually had to read the statements from the relevant point in the auditdb
output file and reapply them



The output from auditdb is not the clearest / easiest to read and
understand.





What I think would be a really useful addition to auditdb would be something
like "-SQL" as an option

Whereby auditdb would format its output into a correctly sequenced set of
SQL statements that

Could be manually applied via sql or isql



When I initially found the fail point in the auditdb output file, it was on
page 4 of 26

So most of the recovery time was spent working the output file to identify
and apply each transaction.







Thoughts??









Cheers





Richard

/***************************\

\***************************/