есть запрос на Sybase ACE 12.5
select karta.idv, nsi_nom.name, prim_bux.prim_sto, osta_bux.ost_sto,
document.id_doc, recv_doc.id_recv
from document
inner join recv_doc
inner join karta
inner join nsi_nom on nsi_nom.id_nom = karta.id_nom
inner join prim_bux on prim_bux.id_karta = karta.id_karta and
prim_bux.dat_dv = convert(datetime, '01/06/2007')
inner join osta_bux on osta_bux.id_karta = karta.id_karta and
osta_bux.dat_dv = convert(datetime, '01/06/2007')
on karta.id_karta = convert(int, recv_doc.value_recv)
on recv_doc.id_doc = document.id_doc
where document.id_doc = 2007000533

при выполнении в advantage выполняется мгновенно
при выполнении через ODBC выполняется 50 минут

при изменении даты на меньшую, например 01.03.2007, и в advantage и через ODBC выполняется мгновенно.

количество возращаемых записей +- 8000 для любой даты.

запрос запрос работает уже полгода, проблем не было

Вопрос : в чем могут быть причины, че смотреть, куда лезть.

вот такой вот план запроса

STEP 1
The type of query is SELECT.


FROM TABLE
document
Nested iteration.
Index : document_id_doc_15346285101
Forward scan.
Positioning by key.
Index contains all needed columns. Base table will not be read.
Keys are:
id_doc ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.


FROM TABLE
recv_doc
Nested iteration.
Index : id_doc
Forward scan.
Positioning by key.
Keys are:
id_doc ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
karta
Nested iteration.
Index : karta_id_kar_6351493082
Forward scan.
Positioning by key.
Keys are:
id_karta ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
nsi_nom
Nested iteration.
Index : nsi_nom_id_nom_21266306192
Forward scan.
Positioning by key.
Keys are:
id_nom ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 2 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
prim_bux
Nested iteration.
Index : dat_dv_id_karta_prim_sto
Forward scan.
Positioning by key.
Index contains all needed columns. Base table will not be read.
Keys are:
dat_dv ASC
id_karta ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.


FROM TABLE
osta_bux
Nested iteration.
Index : dat_dv_id_karta_ost_sto
Forward scan.
Positioning by key.
Index contains all needed columns. Base table will not be read.
Keys are:
dat_dv ASC
id_karta ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.


Server Message: Number 3630, Severity 10
Server 'storm_ds', Line 1:
Total estimated I/O cost for statement 1 (at line 1): 4836.

Если кому интересно - удалила индекс dat_dv_id_karta(который используется в плане запроса) и создала его заново с теми же параметрами, что и были - no clustered, no unique, no suspect, fill faktor = 80. И все заработало! Ура! Но в чем все - таки проблема, почему "запортился" индекс?

Кста, забыла сказать, что перед удалением и созданием индекса заново было сделано : dbcc reindex, tablealloc, checktable, indexalloc, checkdb и ничего не помогало. Не верится, что индексы просто так берут и ломаются, должна же быть причина.

а не может ли поломка индексов быть связана с железом, или с тем, что изменили настройки БД, или с тем, что сисадмин поставил новую версию linuxа, или с неустойчивой работой сетки? мне важно знать, что может в принципе повлиять на объект sybase-a.

Работало, но ненормально - один и тот же запрос в зависимости от даты работал по - разному из ODBC, а в advantage - одинаково. т.е. похоже, что планы выполнения запроса в ODBC и в advantage разные. и после update statistics (удаления и создания индекса) все заработало и в ODBC и в advantage.