Oracle Lerning Library. Education

A lot of lerning videos:

http://apex.oracle.com/pls/apex/f?p=44785:1:0::NO

Wonderful !

System Statistics BUG

Рассмотрим системную статисику  на одной из промышленных систем:

SQL> set lines 1000 pages 1000
SQL> select * from aux_stats$;

SNAME              PNAME           PVAL1
------------------ --------------- -----------

SYSSTATS_MAIN      SREADTIM         60725.039
SYSSTATS_MAIN      MREADTIM        105725.525

Значения SREADTIM и MREADTIM указаны в миллисекундах.
http://docs.oracle.com/cd/E11882_01/server.112/e16638/stats.htm#i41496
Я специально сравнил со своими старыми записями.
На других продуктивах было так:


SREADTIM                7.581
MREADTIM               56.842




Значения стали различаться в 1000 раз.


Наконец пришла отгадка: "Bug 9842771 - Wrong SREADTIM and MREADTIM statistics in AUX_STATS$ [ID 9842771.8]"


Оказывается, по причине бага 9842771 в версиях 11.2 значения ошибочно показываются в 1000 раз больше, чем в предыдущих версиях. А я то сломал голову - почему в последнее время мне стали попадаться системы с медленным вводом-выводом? Баг исправлен в 11.2.0.3.


Ну и немного про DB_FILE_MULTIBLOCK_READ_COUNT, который все еще появляется в наших init-файлах. После сбора системной статистики я его всегда удаляю. MREADTIM - более правильная замена для DFMBRC.
http://docs.oracle.com/cd/E11882_01/server.112/e16638/stats.htm#PFGRF94747

Oracle Database Appliance

Итак, we have Oracle Database Appliance.
ODA contains: Oracle 11.2.0.2 EE RAC.

Let we calibrate IO:

SQL> ed

  1  DECLARE
  2    lat  INTEGER;
  3    iops INTEGER;
  4    mbps INTEGER;
  5  BEGIN
  6  -- DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
  7     DBMS_RESOURCE_MANAGER.CALIBRATE_IO (20, 10, iops, mbps, lat);
  8    DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
  9    DBMS_OUTPUT.PUT_LINE ('latency  = ' || lat);
 10    dbms_output.put_line('max_mbps = ' || mbps);
 11* end;
SQL>
SQL>
SQL> set serveroutput on
SQL> /

max_iops = 13230
latency  = 11
max_mbps = 2335

Итак, 13К IOPS - неплохо для 20 шпинделей.

Однако, как-то слишком много.
Если один шпиндель заявлен на сайте seagate.com как 3мс, то он способен обеспечить не более 330 IOPS. Следовательно, 20 дисков = 20 * 330 = 6600 IOPS - это теоретический максимум, который можно ожидать от такой системы. Однако мы имеем ровно в два раза больше !
Одно из объяснений - диски находятся под RAID-контроллером с 512Мб памяти, а на втором узле - второй контроллер со своими 512Мб. Возможно, причина в этом.

Гипотеза об SSD не нашла подтверждения. SSD диски в данной процедуре не включаются, потому что на SSD лежат только redo log files. Поэтому, даный ввод-вывод - исключительно с шпинделей. Это можно доказать, с помощью lsof:

SQL> !ps
  PID TTY          TIME CMD
23178 pts/1    00:00:00 bash
27465 pts/1    00:00:00 ps
32699 pts/1    00:00:00 sqlplus

[root@ODA01-pub1 ~]# ps -ef|grep 32699
root     31357 17543  0 14:38 pts/3    00:00:00 grep 32699
oracle   32699 23178  0 13:35 pts/1    00:00:00 sqlplus   as sysdba
oracle   32700 32699  0 13:35 ?        00:00:00 oracleODA01DB1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

[root@ODA01-pub1 ~]# lsof -p 32700|less
...
oracle  32700 oracle  256u   BLK  253,68                24412 /dev/mapper/HDD_E1_S06_984565747p1
oracle  32700 oracle  257u   BLK  253,59                23574 /dev/mapper/HDD_E0_S01_984620575p1
oracle  32700 oracle  258u   BLK  253,46                23379 /dev/mapper/HDD_E0_S04_984667927p1
oracle  32700 oracle  259u   BLK  253,36                23233 /dev/mapper/HDD_E1_S03_984701491p1
oracle  32700 oracle  260u   BLK  253,34                23208 /dev/mapper/HDD_E1_S15_979832135p1
oracle  32700 oracle  261u   BLK  253,48                23396 /dev/mapper/HDD_E0_S12_979857635p1
oracle  32700 oracle  262u   BLK  253,42                23340 /dev/mapper/HDD_E0_S17_979676671p1
oracle  32700 oracle  263u   BLK  253,70                24974 /dev/mapper/HDD_E1_S10_984691531p1
oracle  32700 oracle  264u   BLK  253,57                23554 /dev/mapper/HDD_E0_S05_984692403p1
oracle  32700 oracle  265u   BLK  253,29                23133 /dev/mapper/HDD_E1_S19_979811875p1

Итак, видно, что процесс открыл только 10 дисков.
Причем, для lgwr показываются SSD диски:

oracle  24544 oracle  256u   BLK             253,57                23554 /dev/mapper/HDD_E0_S05_984692403p1
oracle  24544 oracle  257u   BLK             253,32                23169 /dev/mapper/HDD_E1_S11_984698091p1
oracle  24544 oracle  258u   BLK             253,29                23133 /dev/mapper/HDD_E1_S19_979811875p1
oracle  24544 oracle  259u   BLK             253,40                23274 /dev/mapper/HDD_E0_S00_984624147p1
oracle  24544 oracle  260u   BLK             253,43                23353 /dev/mapper/HDD_E0_S08_984624267p1
oracle  24544 oracle  261u   BLK             253,59                23574 /dev/mapper/HDD_E0_S01_984620575p1
oracle  24544 oracle  262u   BLK             253,46                23379 /dev/mapper/HDD_E0_S04_984667927p1
oracle  24544 oracle  263u   BLK             253,34                23208 /dev/mapper/HDD_E1_S15_979832135p1
oracle  24544 oracle  264u   BLK             253,68                24412 /dev/mapper/HDD_E1_S06_984565747p1
oracle  24544 oracle  265u   BLK             253,67                24339 /dev/mapper/SSD_E0_S20_805674689p1
oracle  24544 oracle  266u   BLK             253,31                23144 /dev/mapper/SSD_E1_S22_805674773p1
oracle  24544 oracle  267u   BLK             253,28                23110 /dev/mapper/SSD_E1_S23_805674697p1
oracle  24544 oracle  268u   BLK             253,54                23468 /dev/mapper/SSD_E0_S21_805674938p1


Наткнулся на некий новый процесс CS :

[root@ODA01-pub1 ~]# ps -ef|grep ora_cs
oracle   13805     1  2 15:08 ?        00:00:08 ora_cs00_ODA01DB1
oracle   13807     1  2 15:08 ?        00:00:08 ora_cs01_ODA01DB1
oracle   13810     1  2 15:08 ?        00:00:08 ora_cs02_ODA01DB1
oracle   13812     1  2 15:08 ?        00:00:08 ora_cs03_ODA01DB1
oracle   13814     1  2 15:08 ?        00:00:08 ora_cs04_ODA01DB1
oracle   13816     1  2 15:08 ?        00:00:08 ora_cs05_ODA01DB1
oracle   13818     1  2 15:08 ?        00:00:07 ora_cs06_ODA01DB1
oracle   13820     1  2 15:08 ?        00:00:07 ora_cs07_ODA01DB1
oracle   13822     1  2 15:08 ?        00:00:07 ora_cs08_ODA01DB1
oracle   13824     1  2 15:08 ?        00:00:07 ora_cs09_ODA01DB1
oracle   13826     1  2 15:08 ?        00:00:07 ora_cs0a_ODA01DB1
oracle   13828     1  2 15:08 ?        00:00:07 ora_cs0b_ODA01DB1
oracle   13830     1  2 15:08 ?        00:00:06 ora_cs0c_ODA01DB1
oracle   13832     1  2 15:08 ?        00:00:06 ora_cs0d_ODA01DB1
oracle   13834     1  2 15:08 ?        00:00:06 ora_cs0e_ODA01DB1
oracle   13836     1  2 15:08 ?        00:00:06 ora_cs0f_ODA01DB1
oracle   13838     1  2 15:08 ?        00:00:06 ora_cs0g_ODA01DB1
oracle   13840     1  2 15:08 ?        00:00:06 ora_cs0h_ODA01DB1
oracle   13843     1  2 15:08 ?        00:00:05 ora_cs0i_ODA01DB1
oracle   13848     1  2 15:08 ?        00:00:05 ora_cs0j_ODA01DB1
oracle   13851     1  2 15:08 ?        00:00:06 ora_cs0k_ODA01DB1
oracle   13854     1  2 15:08 ?        00:00:06 ora_cs0l_ODA01DB1
oracle   13857     1  2 15:08 ?        00:00:05 ora_cs0m_ODA01DB1
oracle   13865     1  2 15:08 ?        00:00:05 ora_cs0n_ODA01DB1

Как оказалось, это некий новый "I/O Calibration Process":
"CSnn slave processes are started on execution of the DBMS_RESOURCE_MANAGER.CALIBRATE_IO() procedure. There is one slave process per CPU on each node of the database."

http://docs.oracle.com/cd/E11882_01/server.112/e24448/bgprocesses.htm

Причем, процесс калибрации выполняется на двух узлах кластера одновременно.

Какие приложения будут хорошо переноситься на Экзадату ?

В ряде случаев, тестирования приложений на Экзадате оказываются неуспешными. Т.е. приложение в Экзадате работает медленнее, чем на менее производительных серверах.
Иными словами: какими критериями можно выявить приложения, которые не получат пользы от  переноса на Экзадату?

Не претендуя на полноценное решение вопроса, пока могу указать два критерия:

1. К моменту переноса на Экзадату приложение должно успешно работать в RAC 11.2. Если приложение в RAC 11.2 никогда не тестировалось, то гарантий того, что оно взлетит на Экзадате нет. В большинстве случаев станет только хуже.

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

Одним словом, пункты 1 и 2 можно объединить словом МАСШТАБИРУЕМОСТЬ. 

Итак, идеальное приложение для Экзадаты должно обладать отличным масштабированием и при этом его производительность должна быть ограничена только возможностями старого оборудования. И в первую очередь это ввод/вывод, т.е. Экзадата даст приложению мощный ввод-вывод и приложение должно уметь его использовать на полную катушку.

Такое приложение - хороший кандидат на погружение в Экзадату.

Huge Pages & Exadata

I decied to use Huge Pages in our Exadata and just opened /etc/sysctl.conf with vi but …

... vm.nr_hugepages was commented :

# bug 8268393 remove vm.nr_hugepages = 2048

I Пришлось пойти на металинк. Нота относится к Экзадате на НР:

Вот о чем речь:

-----------------------------------------------------

Disable Hugepages on the Database Servers

The current database image allocates 4G of hugepages that in many cases do not get used for various reasons. Some common examples of why the hugepages aren't used are:

• Allocation requested at SGA creation time is larger than the hugepage config
• Automatic Memory Management is being used which cannot leverage hugepages
• The oracle user cannot lock the requested amount of memory because the memlock limit is either not specified or under-configured in /etc/security/limits.conf

Considering these issues, and the lack of benefit for a Data Warehouse environment, it is recommended that hugepages be disabled on the database servers.

Please note that hugepages should   NEVER   be disabled on the Exadata cells.

Bug 8268393 has been filed to make this change permanent in the database side image, and includes steps to do this manually in the work-around section.

-----------------------------------------------------

В общем:

-  упреки от пользователей, нежелающих разобраться почему не стартует их БД +

- несовместимость  АММ с большими страницами

заставили Оракл отказаться от этого функционала и Оракл даже специально оформил якобы баг, чтобы запретить большие страницы на Экзадате.

Жалко, это очень полезный функционал. Особенно для больших систем.

В чем-то Оракл здесь неправ. Большие страницы приносят свою пользу в больших системах.

В общем, если включить HugePages, то ошибок не будет.

Single point of failure

Ф-Центр сообщает:
-----------------------------------
От наводнения в Таиланде пострадала компания Nidec - производство моторов для вращения дисков и подшипников для моторов (70 % - 80 % всех двигателей для HDD). И это уже не говоря о производстве подшипников, которое там чуть ли не стопроцентное.

Если потоп продолжится и будет набирать силу, уже через месяц индустрию производства ПК может поразить убийственный дефицит накопителей. Инвентарные запасы у производителей ноутбуков не превышают четырёх недель, а чаще — две-три недели. Если встанет Nidec — встанет всё. Зато какая открывается перспектива для флэш-винчестеров !

--------------------------------

Если диски станут дорогими, то какой спрос возникнет на НСС-компрессию !

http://money.msn.com/business-news/article.aspx?feed=PZ&Date=20111021&ID=14419145

Exadata Flash Cache contains only ONE copy of database block

There is only copy of database block in flash cache in all Exadata because the reading occurs only from 1st mirror in ASM. There is no doubling data in the flash cache so no waste of FC-space occurs.

HCC

Thanks to Tanel:

QUERY LOW - uses the LZO compression algorithm. Fastest.
QUERY HIGH - uses the ZLIB (gzip) compression algorithm.
ARCHIVE LOW - uses the ZLIB (gzip) compression algorithm, but at a higher compression level than QUERY HIGH.
ARCHIVE HIGH - uses Bzip2 compression. This is the highest level of compression available but is  most CPU-intensive.

11.2.0.3 New Features

Следуем простому старому правилу: 1 час каждый рабочий день посвящать чтению документации. Сегодня:
http://download.oracle.com/docs/cd/E11882_01/server.112/e22487/chapter1_11203.htm

Итак, что мы видим в новых возможностях 11.2.0.3?

- Support Hybrid Columnar Compression on Pillar Axiom and Sun ZFSSA - гибридно-столбцевая компрессия широко шагает по планете и теперь поддерживается на новых железках. Но для этого нужно стаивить 11.2.0.3.


- В своих тренингах по Экзадате я уже рассказывал, что процессоры Intel Xeon 5600 и выше (которые используются в Экзадате) - это революция, по сравнению с 5500 и предыдущими. В частности, они оснащены аппаратным модулем шифрования. А аппаратное шифрование на порядок быстрее программного. И есть ноты, которые подтверждают, что Оракл 11.2 использует это самое аппаратное шифрование. В новых ядрах Т4 тоже была расширена аппаратная криптография и СУБД Oracle ее использует:

" 3.1.3 TDE Hardware Acceleration for Solaris
Transparent Data Encryption (TDE) can automatically detect whether the database host machine includes specialized cryptographic silicon that accelerates the encryption or decryption processing. When detected, TDE uses the specialized silicon for cryptographic processing accelerating the overall cryptographic performance significantly.
In prior releases, cryptographic hardware acceleration for TDE was only available on Intel Xeon, and only for Linux. With release 11.2.0.3 and later releases, it works with the current versions of Solaris 11 running on both SPARC T-Series and Intel Xeon.
"

Облака переходят в атаку

1. cloud.oracle.com
2. http://www.cnews.ru/news/top/index.shtml?2011/10/07/459022

Oracle Enterprise Manager 12c

Облака наступают:

http://www.cnews.ru/news/line/index.shtml?2011/10/06/458708

http://www.oracle.com/technetwork/oem/grid-control/downloads/index.html