OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: AK System error: VAK724 1 with 7.5.0.30

From: Marcin P (protectedpoczta.onet.pl)
Date: Tue Nov 08 2005 - 09:12:34 CST


Hello Gert,
Thank you very much for your interest.
"select * from version" gives me:
Linux 2.6.11 #1 Mon Nov 7 19:04:30 CET 2005 i686 32 Kernel 7.5.0
Build 030-121-100-791 7 5 0 30 fast

There is already an index on the field STATUS_ID.
When it comes to trace - I'll send it on your email in a moment.
Thanks in advance,

Marcin Pytel

--

Uzytkownik "Grossmann, Gert" <gert.grossmannsap.com> napisal w wiadomosci
news:9A33D7528D46DF47B0C0630618F3E68403FA9438dewdfe12.wdf.sap.corp...
Please provide us with accurate kernel version from "select * from version"

Addnl. reproduce the error and create a readable trace output:

0) dbmcli -d <dbname> -u <dbm,dbm> util_execute diagnose vtrace clear
1) dbmcli -d <dbname> -u <dbm,dbm> util_execute diagnose vtrace default
optimize on
2) provoke error
3) dbmcli -d <dbname> -u <dbm,dbm> trace_flush
4) dbmcli -d <dbname> -u <dbm,dbm> trace_prot akbems
5) dbmgetf -d <dbname> -u <dbm,dbm> -k KNLTRCPRT -f <local file name>
6) dbmcli -d <dbname> -u <dbm,dbm> util_execute diagnose vtrace default
optimize off

For further investigation give SQL definition of TALD_ADMIN.CONTACTS,
TALD_ADMIN.CONTACTS, TALD_ADMIN.REQUESTS.

Thanks, Gert

PS: perhaps try to create an index on STATUS_ID to avoid this error
(http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=0&ErrorID=1135891)

-----Ursprüngliche Nachricht-----
Von: news [mailto:newssea.gmane.org] Im Auftrag von Marcin P
Gesendet: Dienstag, 8. November 2005 09:53
An: maxdblists.mysql.com
Betreff: AK System error: VAK724 1 with 7.5.0.30

Hello,
After migration from 7.3 to 7.5.0.30 I keep receiving
"General error;-9404 POS(1) System error: AK System error: VAK724 1"
after executing the query below, which is very similar to
http://archives.neohapsis.com/archives/dev/sapdb/2005-q1/0830.html
I did a quick search and it seems to me that the bug was already fixed,
as we can read at:
http://dev.mysql.com/doc/maxdb/changes/changes_7.5.00.26.html

I have also tried to set OPTIM_INV_ONLY parameter to 'No" but
it hasn't helped either.
The query is:

SELECT DISTINCT
R.REC_ID, R.REQUEST_ID
FROM
TALD_ADMIN.CONTACTS C,TALD_ADMIN.CONTACTS Z, TALD_ADMIN.REQUESTS R
WHERE
(Z.CONTACT_ID = R.CALLER_ID)
AND (C.CONTACT_ID = R.CONTACT_ID)
AND (((STATUS_ID='ZAMKNIÊTE')
   AND(CLOSE_DATE <=SUBDATE(DATE,90)
   AND CLOSE_DATE IS NOT NULL ))
  OR ((OPEN_DATE <=SUBDATE(DATE,90)) AND STATUS_ID='ANULOWANE'))

and the EXPLAIN for it gives me:
C INDEX002 INDEX SCAN 141
                     ONLY INDEX ACCESSED
R IDX_CONTACT_ID JOIN VIA INDEXED COLUMN 3634
Z INDEX002 JOIN VIA INDEXED COLUMN 141
                          NO TEMPORARY RESULTS CREATED
                          RESULT IS COPIED , COSTVALUE IS 5349

what looks rather OK.
Has anyone any idea what could be the reason for this error and how to
workaround it?
Best regards,

Marcin Pytel

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/maxdb?unsub=gert.grossmannsap.com

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/maxdb?unsub=gcdm-maxdbm.gmane.org

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb