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 apparent corruption in
the database. What is the current size of the trx file it a checkpoint has not
been run for 5 months ?
As general practice you should also have a regular online backup schedule in
place with audit trail logging [1] enabled, such that you can always recover
to the last known good state / transaction, especially if running in a
production environment.
[1] http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#BACKUP_AUDIT
<http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#BACKUP_AUDIT>
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
> On 17 Sep 2015, at 08:47, Balazs Varhegyi <varh1ibal...@gmail.com> wrote:
>
> 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 * Monitor: High disk read (2)
> 01:08:14 /usr/bin/virtuoso-t() [0x8d4afd]
> 01:08:14 /usr/bin/virtuoso-t() [0x8d4b78]
> ...
> 01:08:14 /usr/bin/virtuoso-t() [0x5db66c]
> 01:08:14 /usr/bin/virtuoso-t(sf_sql_execute_w+0x74) [0x5db884]
> 01:08:14 /usr/bin/virtuoso-t() [0x8d8f38]
> 01:08:14 /usr/bin/virtuoso-t() [0x8df6fc]
> 01:08:14 /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fa9b54d7182]
> 01:08:14 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fa9b4ae147d]
> 01:08:14 GPF: rltrx.c:1699 mismatched lt thread counts in lt_transact
>
> but virtuoso seems operational, it can be stopped/started, we can query the
> data.
>
> Should we worry about it?
>
> Documentation says: " If the server crashes before completing the backup
> process, then the database is indeed corrupt and needs to be recovered"
> Doc also suggests to make a crash dump but says "The database will contain
> the transactions that were committed as of the last successful checkpoint.".
> This database has been running for 6 months already.
>
> Does it mean if we do the crash dump and the last successful checkpoint was 5
> months ago, then we lose 5 months of data?
>
> Regards,
> Balazs Varhegyi
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140_______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
