поигрался на тестовом сервере - результат мне нравится!

cherrex_DenImperousпропущено...


на первый взгляд - супер!!!
отработало все очень шустро и с нормальным планом!
пасиба!
будем смотреть че там дальше будет.


зы
вот чего не ожидал того не ожидал!

Это не паноцея!!! Это только доказывает, что проблема в статистике.
Разбирайте статистику, что, в ней не так!!!
Оптимизатор упорно считает, что кол-во строк возвращаемое по индексу vid_doc_dat_uchet в таблице document, больше чем кол-во строк в таблице с которой делается join.

И еще, скажите какие уникальные поля(набор полей) для каждой таблицы?
document.id_doc
recv_doc.id_recv
nal_doc.id_nal_doc

но фишка еще в том что "тормоза" касаются не только этих таблиц, а практически всех...

и даже в другой базе данных на том же сервере...

итак, вчера я понаблюдал за тем что получилось, результат:
1) в половине случаев - все залетало
2) в другой половине - очень затормозилось

что сделал: там, где затормозилось делал update all statistics по касающимся тормозов таблицам
результат: после первого запуска процедур, т.е. на второй - все начинало летать

но 1! такие часть тормозов все же осталась.
этой ночью запустил update all statistics по всем таблицам - часть процедур проверил, тормозов не обнаружено.

но 2!
решил поэкспериментировать все с тем же запросиком и увидел картину, которую видел до манипуляций с удалением и обновлением статистики.
результаты:
1.

маленькая поправка - первое чтение сервер делал с диска (physical), затем из кэша
авторQUERY PLAN FOR STATEMENT 1 (at line 1).




STEP 1
The type of query is SELECT.


FROM TABLE
recv_doc
rd
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
document
d
Nested iteration.
Index : pk_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
nal_doc
nd
Nested iteration.
Index : id_recv
Forward scan.
Positioning by key.
Keys are:
id_recv 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.


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


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Table: document scan count 3923647, logical reads: (regular=4090243 apf=0 total=4090243), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: recv_doc scan count 1, logical reads: (regular=145113 apf=0 total=145113), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: nal_doc scan count 9540, logical reads: (regular=11270 apf=0 total=11270), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Server Message: Number 3631, Severity 10
Server 'sybase_ds', Line 1:
Total actual I/O cost for this command: 8493252.
Total writes for this command: 0

Execution Time 128.
SQL Server cpu time: 12800 ms. SQL Server elapsed time: 12786 ms.
(15 rows affected)

2.
вставил хинты

авторQUERY PLAN FOR STATEMENT 1 (at line 1).




STEP 1
The type of query is SELECT.


FROM TABLE
document
d
Nested iteration.
Index : vid_doc_dat_uchet
Forward scan.
Positioning by key.
Keys are:
vid_doc ASC
dat_uchet ASC
Using I/O Size 16 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


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


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


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


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Table: document scan count 1, logical reads: (regular=1583 apf=0 total=1583), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: recv_doc scan count 1938, logical reads: (regular=8216 apf=0 total=8216), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: nal_doc scan count 9540, logical reads: (regular=14575 apf=0 total=14575), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Server Message: Number 3631, Severity 10
Server 'sybase_ds', Line 1:
Total actual I/O cost for this command: 48748.
Total writes for this command: 0

Execution Time 0.
SQL Server cpu time: 0 ms. SQL Server elapsed time: 46 ms.
(15 rows affected)

не понимаю, почему я должен думать за оптимизатор??? ((((

cherrex_DenImperous,

Выложите обновленную статистику opdiag-a по этим трем таблицам.

ЗЫ: Только текстовыми файлами выложите, а то "портянки" такие читать сложно.

cherrex_DenImperous,


а такой запрос как отработает? план покажите!

мгновенно, вот так


авторQUERY PLAN FOR STATEMENT 1 (at line 1).




STEP 1
The type of query is SELECT.


FROM TABLE
document
d
Nested iteration.
Index : vid_doc_dat_uchet
Forward scan.
Positioning by key.
Keys are:
vid_doc ASC
dat_uchet ASC
Using I/O Size 16 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


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


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


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Table: document scan count 1, logical reads: (regular=1583 apf=0 total=1583), physical reads: (regular=2 apf=0 total=2), apf IOs used=0
Table: recv_doc scan count 1938, logical reads: (regular=8216 apf=0 total=8216), physical reads: (regular=79 apf=18 total=97), apf IOs used=150
Server Message: Number 3631, Severity 10
Server 'sybase_ds', Line 1:
Total actual I/O cost for this command: 21380.
Total writes for this command: 0

Execution Time 7.
SQL Server cpu time: 700 ms. SQL Server elapsed time: 656 ms.
(9540 rows affected)

а вопрос так и весит открытый и никаких интересных мыслей нету...

MasterZivOn 15.07.2011 11:54, Imperous wrote:

В таком виде перепиши запрос :

select nd.*, rd.value_recv, d.dat_uchet
from document d
inner join recv_doc rd on d.id_doc = rd.id_doc and rd.kod_recv = 27
inner join nal_doc nd on rd.id_recv = nd.id_recv
where d.dat_uchet <= "2011/06/01" and d.vid_doc = 39

и попробуй.


теперь результат другой, возможно связан с некоторой перенастройкой железа сервера
авторQUERY PLAN FOR STATEMENT 1 (at line 1).




STEP 1
The type of query is SELECT.


FROM TABLE
recv_doc
rd
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With LRU Buffer Replacement Strategy for data pages.


FROM TABLE
document
d
Nested iteration.
Index : document_id_doc_15346285101
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
nal_doc
nd
Nested iteration.
Index : id_recv
Forward scan.
Positioning by key.
Keys are:
id_recv 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.


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


Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
Table: document scan count 3924028, logical reads: (regular=4090666 apf=0 total=4090666), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: recv_doc scan count 1, logical reads: (regular=145309 apf=0 total=145309), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: nal_doc scan count 9513, logical reads: (regular=11234 apf=0 total=11234), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Server Message: Number 3631, Severity 10
Server 'sybase_ds', Line 1:
Total actual I/O cost for this command: 8494418.
Total writes for this command: 0

Execution Time 131.
SQL Server cpu time: 13100 ms. SQL Server elapsed time: 13153 ms.
(15 rows affected)

MasterZiv,

авторТы во-первых запрос норально напиши.

JOIN ... ON
JOIN ... ON
если честно, я не понимаю, чем плох мой запрос?

авторВо-вторых, может тебе вообще думать не нравится ?
Тогда ты не ту профессию избрал.
я говорил по поводу оптимизатора, когда простая ситуация и он должен я думаю больше внимания уделять индексам в зависимости от условия запроса

MasterZivOn 22.07.2011 12:42, Imperous wrote:
> FROM TABLE
> recv_doc

Таблица recv_doc -то небось маленькая ?
ВОт её он и пихает вверх плана.

совсем не маленькая... как минимум раз в 10 больше таблицы document

MasterZivOn 22.07.2011 12:45, Imperous wrote:
> JOIN ... ON
> JOIN ... ON

> если честно, я не понимаю, чем плох мой запрос?

У тебя условие ON стоит после всех JOIN-ов.
Я вот например не знаю, что должна делать в таком случае СУБД.

хм
у меня получается такая цепочка: главная (document.id_doc) -> вспомогательная (recv_doc.id_doc и recv_doc.id_recv) -> вспомогательная к вспомогательной (nal_doc.id_recv), т.е. связь айдишек именно в такой последовательности идет.

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

MasterZivOn 22.07.2011 14:34, Imperous wrote:
> хм
> у меня получается такая цепочка: главная (document.id_doc) -> вспомогательная
> (recv_doc.id_doc и recv_doc.id_recv) -> вспомогательная к вспомогательной
> (nal_doc.id_recv), т.е. связь айдишек именно в такой последовательности идет.

from tab1
join tab2 on ...
join tab3 on ...
join tab4 on ...

и так далее.

однако... :)