|
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 (protected
poczta.onet.pl)
Date: Tue Nov 08 2005 - 09:12:34 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.grossmann
sap.com> napisal w wiadomosci
news:9A33D7528D46DF47B0C0630618F3E68403FA9438
dewdfe12.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:news
sea.gmane.org] Im Auftrag von Marcin P
Gesendet: Dienstag, 8. November 2005 09:53
An: maxdb
lists.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.grossmann
sap.com
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/maxdb?unsub=gcdm-maxdb
m.gmane.org
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]