Исходные данные:
#tmp_comm имеет 345626 записи.
#counterparty имеет те же 345626 записей. #counterparty фомируется с #tmp_comm потом вызывается процедура которая заполняет колонки counterdesc, countercode .
После чего, требуется обновить столбцы таблицы #tmp_comm значениями из таблицы #counterparty.
Вопрос: как можно ускорить этот процес? Если это всё что можно выжать из такого запроса (хотя я в это не верю), то как можно исключить вариант №2 . (~2 млн. IO при апдейте)
Adaptive Server Enterprise/15.0.3/EBF 17769 ESD#4/P/Sun_svr4/OS 5.8/ase1503/2768/64-bit/FBO/Thu Aug 26 15:08:16 2010



#1
QUERY PLAN FOR STATEMENT 1 (at line 34).


STEP 1
The type of query is UPDATE.

4 operator(s) under root

|ROOT:EMIT Operator (VA = 4)
|
| |UPDATE Operator (VA = 3)
| | The update mode is deferred_varcol.
| |
| | |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Left Semi Join)
| | |
| | | |SCAN Operator (VA = 0)
| | | | FROM TABLE
| | | | #tmp_comm
| | | | 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.
| | |
| | | |SCAN Operator (VA = 1)
| | | | FROM TABLE
| | | | #counterparty
| | | | c
| | | | Using Clustered Index.
| | | | Index : ix_counterparty_temp
| | | | Forward Scan.
| | | | Positioning by key.
| | | | Keys are:
| | | | a_id ASC
| | | | t_id ASC
| | | | Using I/O Size 2 Kbytes for data pages.
| | | | With LRU Buffer Replacement Strategy for data pages.
| |
| | TO TABLE
| | #tmp_comm
| | Using I/O Size 2 Kbytes for data pages.


Parse and Compile Time 25.
Adaptive Server cpu time: 2500 ms.

==================== Lava Operator Tree ====================


Emit
(VA = 4)
r:345626 er:530267
cpu: 41500


/
Update
#tmp_comm
(VA = 3)
r:345626 er:530267
l:114274 el:0
p:0 ep:0
/
NestLoopJoin
Left Semi Join
(VA = 2)
r:345626 er:530267


/ \
TableScan IndexScan
#tmp_comm ix_counterparty_ (c)
(VA = 0) (VA = 1)
r:345626 er:345626 r:345626 er:530267
l:27435 el:27435 l:1.394e+06 el:1.383e+06
p:0 ep:3431 p:0 ep:11094

============================================================
Table: #tmp_comm scan count 0, logical reads: (regular=114274 apf=0 total=114274), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #tmp_comm scan count 1, logical reads: (regular=27435 apf=0 total=27435), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #counterparty (c) scan count 345626, logical reads: (regular=1393594 apf=0 total=1393594), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 4416

Execution Time 455.
Adaptive Server cpu time: 45500 ms. Adaptive Server elapsed time: 89840 ms.
The sort for Worktable1 is done in Serial

===
Иногда происходит еще хуже:
№2
QUERY PLAN FOR STATEMENT 1 (at line 36).


STEP 1
The type of query is UPDATE.

4 operator(s) under root

|ROOT:EMIT Operator (VA = 4)
|
| |UPDATE Operator (VA = 3)
| | The update mode is deferred.
| |
| | |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Left Semi Join)
| | |
| | | |SCAN Operator (VA = 0)
| | | | FROM TABLE
| | | | #tmp_comm
| | | | 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.
| | |
| | | |SCAN Operator (VA = 1)
| | | | FROM TABLE
| | | | #counterparty
| | | | c
| | | | Using Clustered Index.
| | | | Index : ix_counterparty_temp
| | | | Forward Scan.
| | | | Positioning by key.
| | | | Keys are:
| | | | a_id ASC
| | | | t_id ASC
| | | | Using I/O Size 2 Kbytes for data pages.
| | | | With LRU Buffer Replacement Strategy for data pages.
| |
| | TO TABLE
| | #tmp_comm
| | Using I/O Size 2 Kbytes for data pages.


Parse and Compile Time 23.
Adaptive Server cpu time: 2300 ms.

==================== Lava Operator Tree ====================


Emit
(VA = 4)
r:345626 er:525745
cpu: 42200


/
Update
#tmp_comm
(VA = 3)
r:345626 er:525745
l:2.041e+06 el:0
p:0 ep:0
/
NestLoopJoin
Left Semi Join
(VA = 2)
r:345626 er:525745


/ \
TableScan IndexScan
#tmp_comm ix_counterparty_ (c)
(VA = 0) (VA = 1)
r:345626 er:345626 r:345626 er:525745
l:28240 el:28243 l:1.383e+06 el:1.383e+06
p:0 ep:3531 p:0 ep:11094

============================================================
Table: #tmp_comm scan count 0, logical reads: (regular=2041127 apf=0 total=2041127), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #tmp_comm scan count 1, logical reads: (regular=28240 apf=0 total=28240), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #counterparty (c) scan count 345626, logical reads: (regular=1382504 apf=0 total=1382504), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 75985

Execution Time 1001.
Adaptive Server cpu time: 100100 ms. Adaptive Server elapsed time: 519233 ms.
The sort for Worktable1 is done in Serial

поправил форматирование, для более удобного чтения
==================== Lava Operator Tree ====================
#1

Table: #tmp_comm scan count 0, logical reads: (regular=114274 apf=0 total=114274), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #tmp_comm scan count 1, logical reads: (regular=27435 apf=0 total=27435), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #counterparty (c) scan count 345626, logical reads: (regular=1393594 apf=0 total=1393594), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 4416

Execution Time 455.
Adaptive Server cpu time: 45500 ms. Adaptive Server elapsed time: 89840 ms.
The sort for Worktable1 is done in Serial

#2

Table: #tmp_comm scan count 0, logical reads: (regular=2041127 apf=0 total=2041127), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #tmp_comm scan count 1, logical reads: (regular=28240 apf=0 total=28240), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #counterparty (c) scan count 345626, logical reads: (regular=1382504 apf=0 total=1382504), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 75985

Execution Time 1001.
Adaptive Server cpu time: 100100 ms. Adaptive Server elapsed time: 519233 ms.
The sort for Worktable1 is done in Serial

Спасибо за ответ.
MasterZivMaxxworld,

> Иногда происходит еще хуже:

А чего хуже-то ?
Оба плана одинаковы, и оба плана хороши для этого запроса.
Во втором случае просто таблица уехала из кэша, вот и всё.

Планы запросов действительно одинаковы.
Различия видны только в операциях логического чтения.
1) Вы уверены, что это указывает только на то что таблица уехала из кэша? Для меня в update командах, первая строка, это всегда загадка.
Если есть ссылка на объяснение, буду очень признателен.
2) Странно, что оптимизатор в обоих случаях ожидает 0 операций чтений, а реальная в 2-м случае 2 млн.

MasterZivMaxxworld,
У тебя проблема в другом -- нафига такие большие объёмы данных обрабатывать ?
Что ты потом делать будешь с этими 345626 записями?

Это один из крайних случаем. Большой клиент, для которого очень много записей.

MasterZivMaxxworld,
По запросу видно, что подставляются какие-то нужные для человека поля.
Так это можно делать потом, после того, как из 345626 записей последующие
запросы отберут несколько тысяч.

Хорошая идея (надо запомнить :) ). Но эта операция находится в подпроцедуре, временная таблица, с 345626 записями потом агригируется.

Забавно,
С точки зрение времени, мне дешевле делать insert into в новую таблицу и объединять эти две таблички...
И дешевле это в 5 раз!

QUERY PLAN FOR STATEMENT 1 (at line 83).



Parse and Compile Time 71.
Adaptive Server cpu time: 7100 ms.



Table: #tmp_comm_r scan count 0, logical reads: (regular=430925 apf=0 total=430925), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Table: #tmp_comm (t) scan count 1, logical reads: (regular=28240 apf=0 total=28240), physical reads: (regular=0 apf=0 total=0), apf IOs used=0


Table: #counterparty (c) scan count 345626, logical reads: (regular=1382504 apf=0 total=1382504), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 588

Execution Time 545.
Adaptive Server cpu time: 54500 ms. Adaptive Server elapsed time: 56040 ms.
Total writes for this command: 0