Slow UPDATE

По поводу вчерашнего медленного UPDATE.

Мы запускаем UPDATE над идентичными данными на двух серверах - Oracle Database Appliance (ODA) и старенький сервер. В табличке ровно 10 млн строк. Выражение, которое мы тестируем предельно простое:

UPDATE TAB1
SET COL1 = COL1
, COL2 = COL2
, COL3 = COL3
, COL4 = COL4

Старенький сервер это 4-ядерный XEON 2.66 cache 4m , RAM 4g (533MHz).

ODA это два 6-ядерных Xeon 3.06 cache 12M, RAM 96g (1333MHz).

При этом старенький сервер опережает ОДУ со счетом 13 минут против 21.

Базы в обоих случаях 11.2.0.2. Никакого шифрования ТП нет.

Вся табличка находится в SGA, физические чтения из датафайлов отсутствуют.

Всяческие ожидания также отсутствуют. В обоих случаях 95% сессия проводит на ЦПУ.

Вот такая картина на ODA:

Top 5 Timed Foreground Events

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
DB CPU		1,360		95.19
gc current grant 2-way	90,294	38	0	2.69	Cluster
gc current block 2-way	67,051	36	1	2.54	Cluster
reliable message	6,016	5	1	0.35	Other
gc cr multi block request	1,085	4	3	0.26	Cluster

Поскольку ожидания отсутсвуют как класс, то для выяснения чем занмается процесс на ЦПУ сделали несколько снимков pstack-ом на старом и новом серверах. Слева ODA, справа - старый сервер:

#0  0x000000000909080d in kdr4chk ()      
#1  0x000000000908b9ce in kdb4chk1 ()     
#2  0x000000000908a493 in kd4chk ()       
#3  0x0000000008f55266 in kdgchk ()       
#4  0x0000000008dd7b0b in ktbdbchk ()     
#5  0x0000000008ded010 in kcbchk_ctx ()   
#6  0x0000000008f8fc93 in kco_blkchk ()   
#7  0x0000000008f8e989 in kcoapl ()       
#8  0x0000000008e0d8ab in kcbapl ()       
#9  0x0000000008f95c4e in kcrfw_redo_gen ()                                                                  
                                                                                                             
#10 0x0000000000e4540c in kcbchg1_main ()       #0  0x0021f7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#11 0x0000000008e0dbfb in kcbchg1 ()            #1  0x002c7342 in times () from /lib/tls/libc.so.6           
#12 0x0000000008dcc876 in ktuchg2 ()            #2  0x0fcc9754 in sltrgatime64 ()                            
#13 0x0000000008dd7093 in ktbchg2 ()            #3  0x0fac31b5 in kcbchg1_main ()                            
#14 0x0000000008d8afef in kddchg ()             #4  0x0fac206b in kcbchg1 ()                                 
#15 0x000000000488ed65 in kdblccovwr ()         #5  0x0fa94300 in ktuchg2 ()                                 
#16 0x00000000048908e8 in kdblcovw ()           #6  0x0fa9d60a in ktbchg2 ()                                 
#17 0x0000000008d82d52 in kduurp ()             #7  0x0fa56b58 in kddchg ()                                  
#18 0x0000000008d7fb66 in kdusru ()             #8  0x087c65db in kddlok ()                                  
#19 0x0000000008d78c14 in kauupd ()             #9  0x087c4cad in kddlkr ()                                  
#20 0x0000000008f3f7f6 in updrow ()             #10 0x0fc02392 in updrow ()                                  
#21 0x00000000023cd72c in qerupFetch ()         #11 0x09d19442 in qerupFetch ()                              
#22 0x0000000001e989ee in updaul ()             #12 0x09830eaa in updaul ()                                  
#23 0x0000000001e9686e in updThreePhaseExe ()   #13 0x0982f56f in updThreePhaseExe ()                        
#24 0x0000000001e9616d in updexe ()             #14 0x0982e85a in updexe ()                                  
#25 0x0000000008ed2a96 in opiexe ()             #15 0x0fb80330 in opiexe ()                                  
#26 0x0000000001b1816b in kpoal8 ()             #16 0x09517c5d in kpoal8 ()                                  
#27 0x000000000172dded in opiodr ()             #17 0x0fb7afb7 in opiodr ()                                  
#28 0x00000000090600b1 in ttcpip ()             #18 0x0fcf013e in ttcpip ()                                  
#29 0x000000000171c86e in opitsk ()             #19 0x091cdb0e in opitsk ()                                  
#30 0x000000000172150e in opiino ()             #20 0x091d17d7 in opiino ()                                  
#31 0x000000000172dded in opiodr ()             #21 0x0fb7afb7 in opiodr ()                                  
#32 0x00000000017187c4 in opidrv ()             #22 0x091c9fbb in opidrv ()                                  
#33 0x0000000001d8fa77 in sou2o ()              #23 0x09747df4 in sou2o ()                                   
#34 0x0000000000a07d05 in opimai_real ()        #24 0x0854f0a3 in opimai_real ()                             
#35 0x0000000001d94f20 in ssthrdmain ()         #25 0x0974cdce in ssthrdmain ()                              
#36 0x0000000000a07c71 in main ()               #26 0x0854f01f in main ()                                    

Pstack - показывает OPI-вызовы снизу вверх. Т.е. нижняя строка - это заголовок программы, функция main().

Из сравнения стала видна разница:

#0  0x000000000909080d in kdr4chk ()       
#1  0x000000000908b9ce in kdb4chk1 ()      
#2  0x000000000908a493 in kd4chk ()        
#3  0x0000000008f55266 in kdgchk ()        
#4  0x0000000008dd7b0b in ktbdbchk ()      
#5  0x0000000008ded010 in kcbchk_ctx ()    
#6  0x0000000008f8fc93 in kco_blkchk ()    
#7  0x0000000008f8e989 in kcoapl ()        
#8  0x0000000008e0d8ab in kcbapl ()        
#9  0x0000000008f95c4e in kcrfw_redo_gen ()

А точнее, набор функций:

kdr4chk  
kdb4chk1
kd4chk
kdgchk
ktbdbchk
kcbchk_ctx 
kco_blkchk   

В имени каждой функции заметны буковки chk = CHECK.

Поэтому следующим шагом на обоих инстансах была выполнена команда:

На старом сервере:

SQL> show parameter db_block_check

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
db_block_checking                    string      FALSE
db_block_checksum                    string      TYPICAL

А в инит файле БД на ODA стоит:

db_block_checksum    = "FULL"

db_block_checking      = "FULL"

Отключаем эти настройки - побеждает ОДА со счетом 8 мин против 13:

 

Резюме:
- На ODA БД по-умолчанию создается с чрезвычайно затратными настройками. Отключение их позволяет значительно повысить скорость транзакций. Лицензия на ODA не запрещает пользователю создать свою БД со своими настройками.
-  Применение настроек

db_block_checksum    = "FULL"

db_block_checking      = "FULL"
 замедляет транзакции в 3-4 раза.

- команда pstack является мощным инструментом для исследования производительности в тех случаях, когда процесс все делает на ЦПУ, но непонятно, чем он там реально занимается. Курс Оракла по Performance Tuning в данном случае вам ничем помочь не сможет.