Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Оптимизация команды Update двух временных таблиц по 350000 строк. / 8 сообщений из 8, страница 1 из 1
28.05.2012, 17:19
    #37814863
Maxxworld
Maxxworld
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Исходные данные:
#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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
set statement_cache off

select * into #tmp_comm  from tempdb..tmp_comm  
select * into #counterparty from tempdb..counterparty

create unique clustered index ix_counterparty_temp on #counterparty(a_id, t_id, counterdesc, countercode)

update 	#tmp_comm
set 	brname1 		= c.counterdesc,
		broker_name	= c.counterdesc,		
		brk      	= c.countercode,
		counterparty 	= c.countercode		
from #counterparty c 
where c.a_id = #tmp_comm.a_id 
  and c.t_id = #tmp_comm.t_id


#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
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.05.2012, 17:31
    #37814897
Maxxworld
Maxxworld
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
поправил форматирование, для более удобного чтения
==================== Lava Operator Tree ====================
#1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
==================== 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
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
==================== 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
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.05.2012, 14:25
    #37816375
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Maxxworld,

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

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

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

По запросу видно, что подставляются какие-то нужные для человека поля.
Так это можно делать потом, после того, как из 345626 записей последующие
запросы отберут несколько тысяч.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.05.2012, 17:04
    #37816743
Maxxworld
Maxxworld
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Спасибо за ответ.
MasterZivMaxxworld,

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

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

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

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

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

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

Хорошая идея (надо запомнить :) ). Но эта операция находится в подпроцедуре, временная таблица, с 345626 записями потом агригируется.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2012, 14:30
    #37818026
Maxxworld
Maxxworld
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Забавно,
С точки зрение времени, мне дешевле делать insert into в новую таблицу и объединять эти две таблички...
И дешевле это в 5 раз!

QUERY PLAN FOR STATEMENT 1 (at line 83).

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
    STEP 1
        The type of query is INSERT.

 4 operator(s) under root

       |ROOT:EMIT Operator (VA = 4)
       |
       |   |INSERT Operator (VA = 3)
       |   |  The update mode is direct.
       |   |
       |   |   |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Inner Join)
       |   |   |
       |   |   |   |SCAN Operator (VA = 0)
       |   |   |   |  FROM TABLE
       |   |   |   |  #tmp_comm
       |   |   |   |  t
       |   |   |   |  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_r
       |   |  Using I/O Size 2 Kbytes for data pages.


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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
==================== Lava Operator Tree ====================

                                     
                                    Emit
                                    (VA = 4)
                                    r:345626 er:540535
                                    cpu: 54500


                         /
                        Insert
                        #tmp_comm_r
                        (VA = 3)
                        r:345626 er:540535
                        l:430925 el:4805
                        p:0 ep:4805

             /
            NestLoopJoin
            Inner Join
            (VA = 2)
            r:345626 er:540535

 /                      \
TableScan               IndexScan
#tmp_comm (t)           ix_counterparty_ (c)


(VA = 0)                (VA = 1)
r:345626 er:345626      r:345626 er:540535

l:28240 el:28243        l:1.383e+06 el:1.383e+06
p:0 ep:3531             p:0 ep:11094
============================================================


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
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2012, 12:45
    #37819398
cherrex_Den
cherrex_Den
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Maxxworld,

Интересно! А вы проверьте количество страниц в таблице #tmp_comm до и после апдэйта. А также #tmp_comm_r после инсерта!

Подозреваю, что разница такая из-за forwarded row. Попробуте поиграться с exp_row_size при создании времянки #tmp_comm перед апдэйтом. Скорее всего добьетесь такойже производительности и при инсерте.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.06.2012, 20:44
    #37822107
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
MaxxworldХорошая идея (надо запомнить :) ). Но эта операция находится в подпроцедуре, временная таблица, с 345626 записями потом агригируется.

Тем более. Не хочешь подставить это всё ПОСЛЕ агрегации ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.06.2012, 20:46
    #37822111
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Оптимизация команды Update двух временных таблиц по 350000 строк.
Про кэш наврал.
Там у тебя только логические чтения.
Только почему -- я ума не приложу.

А про forwarded rows ... какая схема блокирования таблиц ? DOL, APL ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Оптимизация команды Update двух временных таблиц по 350000 строк. / 8 сообщений из 8, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 416ms
Закрыть
start [/forum/topic.php?fid=55&mobile=1&tid=2010124]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 67ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 40ms
get tp. blocked users:
 1ms
others: 265ms
total:  416ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]