Hi Piret,

Have you attempted a  "Crash Recovery When The Normal Crash Recovery Fails” 
which rebuild schema and system keys etc as detailed in section 6.1.5.4.3. of 
the docs at:

        http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#backup

Also, do you have "Log Audit Trail" an "On-line Backups" enabled as indicated 
section 6.1.5.1.  & 6.1.5.2. of the backup docs above, which is always 
recommend such you can can always recover to the last known good state of the 
database ?

As for the "SQL Error: XXXXX : COL..: Insert stopped because out of seg data 
here or elsewhere host 0 key RDF_QUAD slice” error I have tested the previous 
test case we have for this issue with the last VOS 7.2.2 binary and it does 
still work, so if you are experiencing this error still it may be due to 
another condition, thus are you able to provide a reproducible test case for it 
?

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 8 Jan 2016, at 08:24, Piret Lattikas <piret.latti...@zerotech.ee> wrote:
> 
> Hi.
> 
> I wrote about the same problem regarding version 7.2.1 and then I was 
> told that this problem will be fixed with version 7.2.2 release. We 
> switched to version 7.2.2 as soon as it came out and for a while 
> everything was ok. Now we are experiencing the same error again:
> 
>   SQL Error: XXXXX : COL..: Insert stopped because out of seg data here 
> or elsewhere host 0 key RDF_QUAD slice 0
> 
> This error is now a blocker to us as we cannot insert any data to 
> virtuoso. After that error occured made an integrity check what failed 
> with following error (brought out the last part of it):
> 
>   .....
>   Reference to page with free remap dp = 25215714, remap = 25215714
>   Free blob page refd start = 25215704 L=25215704
>   Free blob page refd start = 25215704 L=25215705
>   Blob dump 0x7fdff00f7c48
>           bh_page 25215704
>           bh_dir_page 0
>           bh_position 0
>           bh_frag_no 0
>           bh_slice 0
>           bh_length 0d
>           bh_diskbytes 0d
>           bh_page_dir_complete 1
>           bh_all_received 0
>           bh_send_as_bh 0
>           bh_pages 0x7fdff00d00c8
>                   0:25215704
>                   1:25215705
>           bh_key_id 279
>           bh_timestamp 250554894
>   will have to set blob for col RO_LONG in key RDF_OBJ to empty
>   Reference to page with free remap dp = 25215704, remap = 25215704
>   /usr/bin/virtuoso-t() [0x8d365a]
>   /usr/bin/virtuoso-t() [0x8d36b8]
>   /usr/bin/virtuoso-t() [0x4e5053]
>   /usr/bin/virtuoso-t() [0x4e5096]
>   /usr/bin/virtuoso-t() [0x4ec5ed]
>   /usr/bin/virtuoso-t() [0x4eaaa4]
>   /usr/bin/virtuoso-t() [0x4eabc2]
>   /usr/bin/virtuoso-t() [0x4eabc2]
>   /usr/bin/virtuoso-t() [0x4eb112]
>   /usr/bin/virtuoso-t() [0x4ed5de]
>   /usr/bin/virtuoso-t() [0x5c58b7]
>   /usr/bin/virtuoso-t() [0x5d09de]
>   /usr/bin/virtuoso-t() [0x5d8a62]
>   /usr/bin/virtuoso-t(sf_sql_execute_w+0x7b) [0x5d8bdb]
>   /usr/bin/virtuoso-t() [0x8d7d97]
>   /usr/bin/virtuoso-t() [0x8de353]
>   /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7fe08d4a2182]
>   /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fe08caac47d]
>   GPF: page.c:899 out of order
> 
> So started a crash dump "virtuoso-t -c 
> /etc/virtuoso-opensource-7/virtuoso.ini +crash-dump". During crash dump 
> I can see the following lines:
> 
>   Logging page 48100000
>   Free blob page 25215659
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 9551)
>   Free blob page 25215697
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8283)
>   Free blob page 25215677
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 5270)
>   Free blob page 25215643
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 6794)
>   Free blob page 25215718
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 4252)
>   Free blob page 25215653
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8879)
>   Free blob page 25215701
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 5127)
>   Free blob page 25215691
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 5938)
>   Free blob page 25215642
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 6523)
>   Free blob page 25215712
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8115)
>   Free blob page 25215682
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 4511)
>   Free blob page 25215724
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8683)
>   Free blob page 25215732
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 7037)
>   Free blob page 25215702
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 4447)
>   Free blob page 25215680
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8778)
>   Free blob page 25215730
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8285)
>   Free blob page 25215706
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 9604)
>   Free blob page 25215669
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8278)
>   Free blob page 25215661
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8201)
>   Free blob page 25215714
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 7181)
>   Free blob page 25215704
>   Blob RO_LONG (table DB.DBA.RDF_OBJ) is reduced to 0 length (should be 
> 8429)
>   Logging page 48110000
> 
> After crash dump successfully finished, started crash dump recovery 
> "virtuoso-t -c /etc/virtuoso-opensource-7/virtuoso.ini 
> +restore-crash-dump". During recovery around 13% similar error appeared 
> and the recovered database contains much less triples than the actual one:
> 
>   ...
>       1702000 transactions, 114637279368 bytes replayed (13 %)
>   SQL Error: XXXXX : COL..: Insert stopped because out of seg data here 
> or elsewhere host 0 key RDF_QUAD_POGS slice 0
>   SQL Error: XXXXX : COL..: Insert stopped because out of seg data here 
> or elsewhere host 0 key RDF_QUAD_POGS slice 0
>   ...
> 
> Could you please offer some guidance or help on how to fix or bypass 
> this issue?
> We really cannot afford to lose any data in the database and we really 
> need the database up and running as soon as possible.
> 
> Best wishes.
> 
> Piret
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Attachment: smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Reply via email to