Exadata

Thursday, January 12, 2012

3 TB High Capacity disks

Oracle сообщает, что в новых продаваемых устройствах при заказе дисков High Capacity будут устанавливаться 3TB диски. Под устройствами понимается:

Exadata Database Machine,
Exadata Storage Expansion Rack,
SuperCluster и
отдельный Exadata Storage server.

:) "There is no price change as a result of these 3TB drives."

Новые диски :

на 50% увеличивают емкость системы хранения (как сырую емкость, так и доступную пользователям после зеркалирования),
пропускная способность возрастет на 28% (Disk Throughput excluding flash),
IOPS возрастет на 12% (Disk IOPS excluding flash).

Таким образом, с нового года Full Rack with 3TB drives:

Raw capacity = 504 TB
Usable capacity after ASM normal redundancy = 224 TB
Disk Throughput (excluding flash) = 18 GB/s
Disk IOPS (excluding flash) = 28K

Новые диски требуют Exadata storage server software версии 11.2.2.4.2.
Для High Performance-моделей Оракл будет продолжать использовать 600GB диски.
Пользователи купившие ранее 2TB НС-модели будут получать 2TB диски при их отказе (замена по сервису).

Wednesday, December 28, 2011

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().

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

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

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

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 в данном случае вам ничем помочь не сможет.