Monday, May 30, 2011

Детская загадка

Жила-была табличка на 1,5 млрд записей.
И решили мы все строки в ней пронумеровать.
И добавили мы новое поле и пронумеровали все строки.
И пронумеровались строки ...

И стали мы выбирать из нее данные по новому столбцу:
where newcolumn between X and Y; порциями по 10 млн.
И создали таким образом много табличек по 10М строк.
И создавалась одна 10М-табличка около 200 сек.

И наступил вечер и ушли мы домой.
И пришел следующий день и пришли мы на работу.
И еще раз запустили мы создание 10М-табличек.
И создавались они уже не по 200, а по 40 секунд.

Отгадай?

Ответ: ыещкфпу штвуч

Мораль сей басни такова: в 5 раз !

Thursday, May 26, 2011

Истории успеха

http://www.forrester.com/rb/Research/oracle_exadata_raises_bar_on_database_appliances/q/id/59205/t/2?src=RSS_2&cm_mmc=Forrester-_-RSS-_-Document-_-6


Австралийская финансовая группа - (Australian Financial Group, AFG) - более 2200 пользователей, оборот более 2 млн. долл/месяц.  

Приложение: Siebel
Было: SUN Fire T2000, Oracle 10.2.0.4
Стало:  1/4 Oracle Exadata
Результат: Длительность создания отчета о брокерских комиссионных платежах сократилась с 37 до менее, чем 9 часов. В среднем производительность операций возросла в 8 раз.


---------------------------------------
Sogeti USA - IT-компания, предоставляет IT-сервис в 23 штатах США.

Приложение: OEBS
Было: SUN SPARC Enterprise T5240, six processors (dual core) and 6 GB of RAM for the database server to support more than 3,000 users
Стало: 1/2 Oracle Exadata
Результат: Значительный рост производительности на пакетных- и OLTP-заданиях OEBS. В пиковые часы более 1000 пользователей. Пакетные задания, которые ранее выполнялись 70-80  минут сократились до 10 минут. Некоторые пакетные задания сократились с 30 минут до 5-10. Клонирование БД, которое ранее длилось 8-9 часов теперь выполняется за 30 минут.

----------------------------------------
Компания Forrester Research является независимой исследовательской фирмой, которая предоставляет объективные данные о рынке новых технологий, а так же осуществляющей профильные консультации уже 23 года.

CELL_OFFLOAD_PLAN_DISPLAY=ALWAYS

Х - дорогая штучка, не у всех она есть.
Спрашивается: как разработчикам отлаживать под нее свои приложения, если ее нет ?
  
Поэтому мой совет разработчикам, желающим отлаживать свой софт под Экзадату: устанавливайте параметр

            CELL_OFFLOAD_PLAN_DISPLAY=ALWAYS

Можно Alter session, можно alter system ...

С этой опцией оптимизатор станет показывать в своих планах OFFLOADING на тех шагах плана, где он считает необходимым этот offloading выполнить.

И для этого не требуется сама Экзадата, достаточно просто иметь базу 11g !
Такой подход значительно сократит для вас время непосредственной отладки приложений на Х.

В путь !

Thursday, May 19, 2011

bash ! history








Оказывается, в bash есть такая команда "!" :


# mkdir /yu
 

# ls -l /yu
total 0
 

# history |tail -3
  996  mkdir /yu
  997  ls -l /yu
  998  history |tail -3
 

# !996    <-- Используем номер команды
mkdir /yu
mkdir: cannot create directory `/yu': File exists


# history |tail -5
  994  mkdir /yu
  995  su - oracle
  996  ls -l /yu
  997  ls -ld /yu
  998  history |tail -5
# !history     <--  Используем название команды
history |tail -5
  995  su - oracle
  996  ls -l /yu
  997  ls -ld /yu
  998  history |tail -5
  999  history |tail -5
# !l       <-- можно вообще указать только первый символ
ls -ld /yu
drwxr-xr-x 2 root root 4096 May 19 12:52 /yu



Можно запоминать историю в свой файл: HISTFILE=/home/yu/my_history
Можно запретить сохранять историю:   SAVEHIST=0
Можно ограничить размер: HISTSIZE=100


Можно игнорировать некоторые команды: HISTIGNORE="ls:mkdir:ps:history*:[ \t]*"
Через : указывается список команд, а [ \t] - означает не записывать в историю команды, начинающиеся с пробела:


# history |tail -5
  107  export HISTIGNORE="ls:mkdir:ps:history*:[ \t]*"
  108  asb
  109  sdf
  110  dfg
  111  qwe
# ls
# mkdir /yu2
#  tail -10 MegaSAS.log
# history |tail -5
  108  asb
  109  sdf
  110  dfg
  111  qwe
  112  mkdir /yu2


Видим, что команды "ls", " tail" - не попали в историю, а "mkdir /yu2" - попала, потому что мы запретили только mkdir, а не mkdir*


Еще одна опция называется cmdhist - сохранять ли в истории команды набранные через ; как одну команду (def) или как несколько команд, включается/отключается  
shopt -s/u cmdhist




Эксперименты с компрессией


Попробовал сделать две таблицы из одного дампа:HCCAH archive high и 
HCCQH - query high.

Сам дамп 20g ( создавался с опцией expdp COMPRESS=Y)
Табличка без сжатия = 500g.

И прогнал по обеим select count(*) from &1;


Таблица            HCC            Size         count(*)
----------------------------------------------------------------------------------
HCCQH        query high         139g         13 s
HCCAH        archive high       129g          25 s
-------------------------------------------------------------------------------------

Выигрыш в сжатии небольшой, а скорость запросов падает заметно.
Вывод: буду рекомендовать HCC query high. 


select NUM_ROWS,BLOCKS,AVG_ROW_LEN from dba_tables where table_name='HCCQH';

NUM_ROWS     BLOCKS   AVG_ROW_LEN
---------- ---------- -----------
1866884241   18238956         227


Чтобы посчитать объем данных который потребуется на диске среднюю длину строки умножаем на кол-во строк

select round( NUM_ROWS * AVG_ROW_LEN /1024/1024/1024) as GB from dba_tables where table_name='HCCQH';

        GB
 ---------
       395
 
А теперь смотрим объем таблицы исходя из кол-ва блоков:

select round( BLOCKS /1024/1024/1024) as GB from dba_tables where table_name='HCCQH';

       GB
---------
      139

Получается, 395g строк помещаются в 139g блоков.




 

Friday, May 6, 2011

Первые сложности

Как оказалось, Линукс на Экзадате был поставлен с минимальным набором пакетов.
Screen - нет, vnc - нет, yum - чтобы поставить предыдущие два - тоже нет.
Пришлось качать образ и устанавливать пакеты с него.

Со screen все было очень легко :
# rpm -qa|grep screen
# rpm -i screen-4.0.3-1.el5_4.1.x86_64.rpm
warning: screen-4.0.3-1.el5_4.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
# rpm -qa|grep screen
screen-4.0.3-1.el5_4.1
А вот с vnc - начались проблемы с зависимостями. Говоришь ему rpm -i vnc-server* а тебе в ответ - не хватает ... пакетов, и вывод на пол-экрана. Добавляешь перечисленные названия пакетов - а тебе в ответ - не хватает, и еще - еще два экрана. В общем, дальше 4 итерации я не продвинулся.

Поэтому  правильный ответ:

# rpm -Uvh --nodeps                            \
> chkfontpath-1.10.1-1.1.x86_64.rpm            \
> libfontenc-1.0.2-2.2.el5.x86_64.rpm          \
> libXfont-1.2.2-1.0.3.el5_1.x86_64.rpm        \
> libXfontcache-1.0.2-3.1.x86_64.rpm           \
> libXTrap-1.0.0-3.1.x86_64.rpm                \
> xorg-x11-fonts-base-7.1-2.1.el5.noarch.rpm   \
> xorg-x11-font-utils-7.1-2.x86_64.rpm         \
> xorg-x11-server-utils-7.1-4.fc6.x86_64.rpm   \
> xorg-x11-twm-1.0.1-3.1.x86_64.rpm            \
> xterm-215-8.el5_4.1.x86_64.rpm               \
> vnc-server-4.1.2-14.el5_3.1.x86_64.rpm
warning: chkfontpath-1.10.1-1.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ########################################### [100%]
   1:libfontenc             ########################################### [  9%]
   2:libXfont               ########################################### [ 18%]
   3:xorg-x11-font-utils    ########################################### [ 27%]
   4:libXTrap               ########################################### [ 36%]
   5:libXfontcache          ########################################### [ 45%]
   6:chkfontpath            ########################################### [ 55%]
   7:xorg-x11-server-utils  ########################################### [ 64%]
   8:xterm                  ########################################### [ 73%]
   9:xorg-x11-twm           ########################################### [ 82%]
  10:xorg-x11-fonts-base    ########################################### [ 91%]
  11:vnc-server             ########################################### [100%]

ORA-01405: fetched column value is NULL after upgrade from 12.1 to 18c

SYMPTOMs: After upgrade 12.1.0.2 -> 18.6 we obtained at any SQL (select and DML) : ORA-00604: error occurred at recursive SQL level ...