Hi Balazs,
Yes, a crash-dump and restore can always being performed to attempt recovery of
the database …
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.l
Just realized we can make checkpoint anytime too, so we should be able
to resolve the corrupt database with "crash_dump" without losing any
data, right?
On 17/09/15 10:47, Balazs Varhegyi wrote:
Hi,
We did an integrity check for the first time with " backup
'/dev/null'" and it stopped with:
Hi Balazs,
If you say the database is still running normally and it is just the integrity
check that is giving the GPF error below, then you should be able to run a
checkpoint to commit any pending transaction in the log to the database file
then you can do the crash dump and restore to fix the
Hi,
We did an integrity check for the first time with " backup '/dev/null'"
and it stopped with:
19:41:49 Dumping the schema tables
19:41:49 Dumping the registry
19:41:49 Dumping the schema done
21:58:12 * Monitor: High disk read (2)
22:00:54 * Monitor: High disk read (2)
01:07:34 * Monit
