Tuesday, January 31, 2012

QDPE, FSQDPE


Oracle объявил новое расписание  выпуска патчей для Exadata, начиная с 11.2.0.3. Предыдущий ежемесячный выпуск патчей (bundle patch) изменяется на квартальный. Т.е. каждый квартал Oracle будет выпускать Quarterly Database Patch for Exadata (QDPE). Вероятно, QDPE будет выходить одновременно с critical patch update (CPU) - стандартным
ежеквартальным набором патчей для БД. Последний на сегодняшний день QDPE это #13513783 (файл p13513783_112030_Linux-x86-64.zip, 340М).

Oracle обещает также выкладывать по мере появления единичные патчи для Exadata для устранения единичных багов, (например, для исправления конккретных ошибок в серверах хранения или Infiniband-свичах и т.д.) но рекомендует дождаться QDPE и воздержаться от установки единичных патчей, если проблема не сильно беспокоит. QDPEs выпускаются только для установки поверх БД 11.2.0.3.

В дополнение к QDPE Oracle объявляет о выпуске "full stack QDPE" - ежеквартального патча для всего программно-аппаратного стека Exadata (Quarterly Full Stack Download Patch, QFSDP), который будет включать в себя последние версии ПО и прошивок для всего стека. QFSDPE содержит в своем составе QDPE.

В частности, последний январский 2012 QFSDP включает следующие версии :

    Infrastructure Software
        Exadata Storage Server version 11.2.2.4.2
        Exadata Infiniband Switch version 1.3.3-2
        Exadata PDU firmware version 1.04
    Database
        11.2.0.3 January 2012 QDPE
        Opatch 11.2.0.1.9
        OPlan
    Systems Management
        Patches for 11g OEM agents
        Management plugins for 11g OEM
        Patches for 11g OEM management server

Пока не сообщается когда появятся агенты для OEM 12c. 

Подчеркнем, что QFSDP - это не единый пачсет, а коллекция патчей,
как если бы все они были скачаны и установлены по-отдельности.
Пока еще Oracle не разработал инструмент для инсталляции QFSDPE как единого пачсета.

Последний QFSDP - январь 2012, патч номер #13551280, 2,2 Гб.

Для продуктивных систем и для систем которые находятся на последней стадии перед запуском Oracle рекомендует устанавливать эти патчсеты только после проверки на тестовой среде и не ранее, чем через 30 дней после их выхода в свет. Для тестовых систем, для систем которые находятся на ранних стадиях запуска, а также для proofs-of-concept
- пачсеты нужно ставить сразу после выхода.

Так написано в ноте 888828.1.

Wednesday, January 25, 2012

Linux IO scheduler

Linux IO scheduling controls the algorithm for processing disk IO requests in appropriate order. Choosing adequate algorithm may have big impact on the IO performance. IO scheduling is determined by the Linux kernel. From the 2.6 there are four IO schedulers:
  • Completely Fair Queuing (CFQ)
  • Deadline
  • NOOP
  • Anticipatory
The scheduler is determined by elevator option in the /boot/grub/grub.conf file:
elevator= cfq | deadline | noop | as

With 2.6 kernels, it is also possible to change the scheduler for particular devices
during runtime:
# echo deadline > /sys/block/sdb/queue/scheduler

 Steve Shaw and Martin Bach writes:
"CFQ is the default scheduler for Oracle Enterprise Linux. It balances IO requests across all available resources. The Deadline scheduler attempts to minimize the latency of IO requests with a round robin–based algorithm for real-time performance. The Deadline scheduler is often considered more applicable in a data warehouse environment, where the IO profile is biased toward sequential reads. The NOOP scheduler minimizes host CPU utilization by implementing a FIFO queue, and it can be used where IO performance is optimized at the block-device level. The Anticipatory scheduler is used for aggregating IO requests where the external storage is known to be slow, but at the cost of latency for individual IO requests. "

But in the 6.2 the default  scheduler in was changed:
"Default IO scheduler

    For the Unbreakable Enterprise Kernel, the default IO scheduler is the 'deadline' scheduler.
    For the Red Hat Compatible Kernel, the default IO scheduler is the 'cfq' scheduler. "
 http://oss.oracle.com/ol6/docs/RELEASE-NOTES-U2-en.html

Tuesday, January 24, 2012

О влиянии наблюдателя на наблюдаемые являения

Сегодня делал небольшое исследование - сравнивал производительность двух серверов.
В частности, сделал такой самый простой тест, чтобы замерить скорость одного ядра: 

set timing on

create table test (
Client_ID    NUMBER,
NAME         Varchar2(3),
FAMILY       Varchar2(5),
DOLLARS      NUMBER,
PASSWORD     Varchar2(4),
BIRTHDAY        DATE
) tablespace users;

insert into test
select
   rownum ID,
   DBMS_RANDOM.STRING ('A',3),
   DBMS_RANDOM.STRING ('A',5),
   DBMS_RANDOM.VALUE (0,1000),
   DBMS_RANDOM.STRING ('X',4),
   SYSDATE-DBMS_RANDOM.VALUE (6000,30000)
from dual connect by rownum <= 1000000;

select sum(bytes)/1048576 from user_segments where segment_name='TEST';

SUM(BYTES)/1048576
------------------
                61

select count(*) from test;
select count(*) from test;
select count(*) from test;
select count(*) from test;


Табличка была целиком в памяти и время выполнения запроса стаблизировалось на цифре 10-20мс как на исходной так и второй системах:

SQL> set timing on
SQL> select count(*) from test;
select count(*) from test;
select count(*) from test;

  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.03
SQL>
  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.02
SQL>
  COUNT(*)
----------
   1000000

Elapsed: 00:00:00.01


Для того, чтобы повысить точность измерений решили включить трассировку и посмотреть время в микросекундах. После включения трассировки
alter session set events '10046 trace name context forever';
значения на обоих узлах стали 50-60мс:

PARSING IN CURSOR #139778252768168 len=25 dep=0 uid=84 oct=3 lid=84 tim=1327404119420870 hv=297253644 ad='2a99a2da8' sqlid='7b2twsn8vgfsc'
select count(*) from test
END OF STMT
PARSE #139778252768168:c=0,e=80,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420868
EXEC #139778252768168:c=0,e=30,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=1950795681,tim=1327404119420975
FETCH #139778252768168:c=52992,e=54137,p=0,cr=7729,cu=1,mis=0,r=1,dep=0,og=1,plh=1950795681,tim=1327404119475172
STAT #139778252768168 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=7729 pr=0 pw=0 time=54134 us)'
STAT #139778252768168 id=2 cnt=1000000 pid=1 pos=1 obj=107338 op='TABLE ACCESS FULL TEST (cr=7729 pr=0 pw=0 time=75924 us cost=2093 size=0 card=1013983)'


Вот какое влияние оказывает трассировка на трассируемый процесс.

Monday, January 23, 2012

Configuring FTP on Exadata

 На Экзадате нет FTP. Как решить проблему - советы сотрудника Оракла:

http://blogs.oracle.com/AlejandroVargas/entry/configuring_ftp_on_exadata

Monday, January 16, 2012

Subject: Приглашение на форум

 

Из текста приглашения: 
"На данный момент в Москве открыто 3 демо-центра Oracle Exadata Database Machine, более 10 компаний приобрели машину баз данных ".

Friday, January 13, 2012

Exadata 96 -> 144 RAM MHz



As you know Exadata is equipped by default with 96g RAM DDR3-1333MHz. Each CPU has 3-channel memory controller, each controller can address to 2 DIMM at 1333MHz. You can see this in the photo: two DIMM line and one white free slot/

But it is 144g configuration which uses the free slot. In such configuration RAM frequency is 800MHz, see documentation:



Therefore, after adding memory customer will have performance slowness at 40% !

Экзадата изначально поставляется с памятью 96g. И в этом случае частота памяти 1333МГц. На фото показана данная конфигурация: в центре - два ЦПУ, около каждого ЦПУ своя память. Видно 3 банка, в каждом банке стоят по 2 планки по 8Гб и одна белая заглушка.

Оракл позволяет довести объем физической памяти на сервере до 144Гб путем установки еще одной планки 8Гб на место заглушки. Однако фокус в том, что в этой конфигурации память работает на частоте 800МГц. Таким образом, заказчик добавив памяти может получить снижение производительности на 40% .

Ключевой момент (смотрим в доке) :
TABLE 4-2 Memory Conside rations and Limitations
3x of the same kind of DIMMs per channel = 800 MHz  
2x of the same kind of DIMMs per channel = 1333 MHz


В документе exalogic-hardware-overview-345531.pdf на странице 3 явно сказано "the X4170M2 is equipped with exactly 96GB of RAM; the maximum amount of RAM enabling the higher memory bus speed of 1333 MHz. Although the X4170M2 has a max capacity of 144GB, increasing memory beyond the 96Gb barrier requires a 40% drop in the memory bus speed to 800Mhz":





Does DEALLOCATE UNUSED or SHRINK SPACE will free space occupied by LOB segment?

Lets check how it works. My env is DB 19.20@Linux-x64 1) I created the table with 4 LOB columns of 4 different LOB types: BASICFILE BLOB, BA...