OLTP on Exadata and ODA

Интересная презентация на тему пригдоности Экзадаты и ODA для OLTP-задач:

http://fritshoogland.files.wordpress.com/2013/04/exadata-and-oltp-v2-as43.pdf

Презентация немного устаревшая – еще про Х2-2 и не учитывает WriteBack Smart Flash Cache, но тем не менее весьма полезная.

error: Zip file too big (greater than 4294959102 bytes)

The customer send us the dump for Exadata POC and this dump is unavailable to unzip :

[root@ed01db01 ]# unzip dmp.zip
error:  Zip file too big (greater than 4294959102 bytes)
Archive:  dmp.zip
warning [dmp.zip]:  10149171547 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [dmp.zip]:  start of central directory not found;
  zipfile corrupt.
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)
Our unzip version is:

[root@ed01db01 ]# unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

The solution 1:

[root@ed01db01 ttelek]# funzip dmp.zip > dmp.dmp
[root@ed01db01 ttelek]# ls -l

-rw-r--r-- 1 root   root 65195868160 May 13 11:24 dmp.dmp
-rw-r----- 1 oracle dba  14444138961 May 12 00:03 dmp.zip
[root@ed01db01 ttelek]# funzip
fUnZip (filter UnZip), version 3.94 of 17 February 2002
usage: ... | funzip [-password] | ...
       ... | funzip [-password] > outfile
       funzip [-password] infile.zip > outfile
       funzip [-password] infile.gz > outfile
Extracts to stdout the gzip file or first zip entry of stdin or the given file.
Our conclusion: the Exadata has the funzip by default, we don't install it intentionally.

The solution 2:

[root@ed01db01 ]# zcat dmp.zip > dmp.dmp

Exadata has zcat by default.

 

ORA-30094: failed to find the time zone data file for version ... in $ORACLE_HOME/oracore/zoneinfo

We have the one 11.2.0.3 DB + latest time zone installed on it - version 19.
Imagine our surprise when we've got the message during the import:

ORA-39097: Data Pump job encountered unexpected error -30094
ORA-39065: unexpected master process exception in DISPATCH
ORA-30094: failed to find the time zone data file for version 17 in $ORACLE_HOME/oracore/zoneinfo


Why ? How it is possible ? Why Oracle not used latest time zone ?

We don't know, but we have the solution :



download the appropriate version of the DST (version 17 for our case, p12949905_112030_Linux-x86-64.zip) and unzip it somewhere:

[oracle@ed01db01 DST]$ unzip p12949905_112030_Linux-x86-64.zip
Archive:  p12949905_112030_Linux-x86-64.zip
   creating: 12949905/
  inflating: 12949905/README.txt
  inflating: 12949905/README.html
   creating: 12949905/files/
   creating: 12949905/files/oracore/
   creating: 12949905/files/oracore/zoneinfo/
  inflating: 12949905/files/oracore/zoneinfo/readme_17.txt

   creating: 12949905/files/oracore/zoneinfo/little/
  inflating: 12949905/files/oracore/zoneinfo/little/timezone_17.dat
  inflating: 12949905/files/oracore/zoneinfo/little/timezlrg_17.dat
  inflating: 12949905/files/oracore/zoneinfo/timezone_17.dat

   creating: 12949905/files/oracore/zoneinfo/big/
  inflating: 12949905/files/oracore/zoneinfo/big/timezone_17.dat
  inflating: 12949905/files/oracore/zoneinfo/big/timezlrg_17.dat
  inflating: 12949905/files/oracore/zoneinfo/timezlrg_17.dat

   creating: 12949905/etc/
   creating: 12949905/etc/config/
  inflating: 12949905/etc/config/inventory.xml
  inflating: 12949905/etc/config/actions.xml
  inflating: 12949905/etc/config/deploy.xml
   creating: 12949905/etc/xml/
  inflating: 12949905/etc/xml/GenericActions.xml
  inflating: 12949905/etc/xml/ShiphomeDirectoryStructure.xml


 
As we know, Oracle hold the time zone files in $OH/oracore/zoneinfo.
Therefore, simply copy red files from patch into $OH/oracore/zoneinfo directory.
Don't forget about directory structure and save latest $OH/oracore/zoneinfo/readme_19.txt (don't copy old readme_17.txt file from patch into your $OH)

For example:

[oracle@ed01db01 zoneinfo]$ rm /store/DST/12949905/files/oracore/zoneinfo/readme_17.txt
[oracle@ed01db01 zoneinfo]$ ls -l /store/DST/12949905/files/oracore/zoneinfo/*
-rw-rw-rw- 1 oracle oinstall 779003 Oct 14  2011 /store/DST/12949905/files/oracore/zoneinfo/timezlrg_17.dat
-rw-rw-rw- 1 oracle oinstall 341718 Oct 14  2011 /store/DST/12949905/files/oracore/zoneinfo/timezone_17.dat

/store/DST/12949905/files/oracore/zoneinfo/big:
total 1108
-rw-rw-rw- 1 oracle oinstall 779003 Oct 14  2011 timezlrg_17.dat
-rw-rw-rw- 1 oracle oinstall 341718 Oct 14  2011 timezone_17.dat

/store/DST/12949905/files/oracore/zoneinfo/little:
total 1108
-rw-rw-rw- 1 oracle oinstall 779003 Oct 14  2011 timezlrg_17.dat
-rw-rw-rw- 1 oracle oinstall 341718 Oct 14  2011 timezone_17.dat
 
[oracle@ed01db01 zoneinfo]$  cd $OH/oracore/zoneinfo
[oracle@ed01db01 zoneinfo]$ cp -r /store/DST/12949905/files/oracore/zoneinfo/* .
[oracle@ed01db01 zoneinfo]$ ls -l
total 15680
drwxr-xr-x 2 oracle oinstall   4096 May  8 12:33 big
drwxr-xr-x 2 oracle oinstall   4096 May  8 12:33 little
-rwxrwxrwx 1 oracle oinstall   7395 Dec 31 12:11 readme_19.txt
-rw-r--r-- 1 oracle oinstall   6068 Jun  7  2010 readme.txt
-rw-r--r-- 1 oracle oinstall  31525 Jun  7  2010 timezdif.csv
-rw-r--r-- 1 oracle oinstall 792894 Aug 18  2011 timezlrg_10.dat
-rw-r--r-- 1 oracle oinstall 787272 Aug 18  2011 timezlrg_11.dat
-rw-r--r-- 1 oracle oinstall 785621 Aug 18  2011 timezlrg_12.dat
-rw-r--r-- 1 oracle oinstall 782475 Aug 18  2011 timezlrg_13.dat
-rw-r--r-- 1 oracle oinstall 791430 Aug 18  2011 timezlrg_14.dat
-rw-r--r-- 1 oracle oinstall 779003 May  8 12:33 timezlrg_17.dat
-rwxr-xr-x 1 oracle oinstall 785786 Dec 31 12:11 timezlrg_19.dat
-rw-r--r-- 1 oracle oinstall 493675 Aug 18  2011 timezlrg_1.dat
-rw-r--r-- 1 oracle oinstall 507957 Aug 18  2011 timezlrg_2.dat
-rw-r--r-- 1 oracle oinstall 527717 Aug 18  2011 timezlrg_3.dat
-rw-r--r-- 1 oracle oinstall 531137 Aug 18  2011 timezlrg_4.dat
-rw-r--r-- 1 oracle oinstall 587487 Aug 18  2011 timezlrg_5.dat
-rw-r--r-- 1 oracle oinstall 586750 Aug 18  2011 timezlrg_6.dat
-rw-r--r-- 1 oracle oinstall 601242 Aug 18  2011 timezlrg_7.dat
-rw-r--r-- 1 oracle oinstall 616723 Aug 18  2011 timezlrg_8.dat
-rw-r--r-- 1 oracle oinstall 801410 Aug 18  2011 timezlrg_9.dat
-rw-r--r-- 1 oracle oinstall 345637 Aug 18  2011 timezone_10.dat
-rw-r--r-- 1 oracle oinstall 345356 Aug 18  2011 timezone_11.dat
-rw-r--r-- 1 oracle oinstall 345024 Aug 18  2011 timezone_12.dat
-rw-r--r-- 1 oracle oinstall 344425 Aug 18  2011 timezone_13.dat
-rw-r--r-- 1 oracle oinstall 344448 Aug 18  2011 timezone_14.dat
-rw-r--r-- 1 oracle oinstall 341718 May  8 12:33 timezone_17.dat
-rwxr-xr-x 1 oracle oinstall 343167 Dec 31 12:11 timezone_19.dat
-rw-r--r-- 1 oracle oinstall 274427 Aug 18  2011 timezone_1.dat
-rw-r--r-- 1 oracle oinstall 274900 Aug 18  2011 timezone_2.dat
-rw-r--r-- 1 oracle oinstall 286651 Aug 18  2011 timezone_3.dat
-rw-r--r-- 1 oracle oinstall 286264 Aug 18  2011 timezone_4.dat
-rw-r--r-- 1 oracle oinstall 286310 Aug 18  2011 timezone_5.dat
-rw-r--r-- 1 oracle oinstall 286217 Aug 18  2011 timezone_6.dat
-rw-r--r-- 1 oracle oinstall 286815 Aug 18  2011 timezone_7.dat
-rw-r--r-- 1 oracle oinstall 302100 Aug 18  2011 timezone_8.dat
-rw-r--r-- 1 oracle oinstall 351525 Aug 18  2011 timezone_9.dat
[oracle@ed01db01 zoneinfo]$

Oracle & Intel Alliance

Надо почитать этот сайт : http://www.intelalliance.com/oracle/home.aspx

ORA-15055: unable to connect to ASM instance, ORA-01031: insufficient privileges

The today issue:
after installation GI and DB with role separation (grid and oracle) the DB cannot connect to ASM instance.

The DB process dedicated to connect to ASM is ASMB process. So, lets goo into the
$ORACLE_BASE/diag/rdbms/$DB/$SID/trace
and look $SID_asmb_$PID.trc files:

WARNING: failed to start ASMB (connection failed) state=0x1

In alert log you can see:
Thu Mar 21 13:18:29 2013
WARNING: ASM communication error: op 16 state 0x40 (1031)
ERROR: slave communication error with ASM
This means that grid user has not in asmadmin group. What you need is :
usermod -g oinstall -G dba,asmadmin  grid

But we still cannot connect to ASM, DB alert log still shows:

ORA-15055: unable to connect to ASM instance
ORA-01031: insufficient privileges

So, we need 2nd modification - add user oracle to asmdba group:
usermod -g oinstall -G dba,asmdba  oracle

Now all works and we see

NOTE: initiating MARK startup
Starting background process MARK
ORACLE_BASE from environment = /u01/app/oracle/
Thu Mar 21 14:08:07 2013
MARK started with pid=21, OS id=4206
NOTE: MARK has subscribed
Thu Mar 21 14:08:08 2013
ALTER DATABASE   MOUNT
 

oracleasm createdisk [FAILED]

The today error was:

# /etc/init.d/oracleasm createdisk VOL1 /dev/sdb1
Marking disk "VOL1" as an ASM disk:               [FAILED]

What is the reason for  [FAILED] ?
The disks are:
# ls -l /dev/sdb*
brw-rw----. 1 root disk 8, 16 Mar 19 11:47 /dev/sdb
brw-rw----. 1 root disk 8, 17 Mar 19 11:58 /dev/sdb1


The solution is DISABLE SELINUX !

The dot in the brw-rw----. <- is the symptom of selinux.

After SELINUX=disabled in /etc/selinux/config +reboot the server we have

# ls -l /dev/sdb*
brw-rw---- 1 root disk 8, 16 Mar 19 13:52 /dev/sdb
brw-rw---- 1 root disk 8, 17 Mar 19 14:01 /dev/sdb1

and oracleasm configuration works:

# /etc/init.d/oracleasm createdisk VOL1 /dev/sdb1
Marking disk "VOL1" as an ASM disk:                [  OK  ]

 

ODA X3-2

Вышла ODA Х3-2.   Изменения:

             Было          Стало            Всего в новой ODA
------ --------------- -------------------- -----------------
CPU:   12 core/server    16 core/server        32 core
           2*6core          2*8core

RAM:        96g          256g/server           512g

Disks:
Hard:    20* 600g         20* 900g              18T
SSD:      4*  73g          4* 200g             800g
------ --------------- -------------------- -----------------

Не сбылись наши мечты о :
- HCC на ODA
- Standard Edition на ODA.

Однако, поскольку на ODA возможна виртуализация, то есть возможность поднять виртуалку с SE и вообще любыми версиями СУБД и (да и вообще с любым софтом). Также с учетом виртуализации можно поднять на ODA и сервера приложений.





 

Exadata Documentation = patch 10386736

As we know, the Exadata documentation is stored in the storage cell in /usr/share/doc/oracle/Exadata.
But I recommend you to download the patch 10386736.
You'll be surprised.
 

Drives order in Storage Cells

Oracle changed the disk order in the Exadata Storage Server from columnar to row.

Old order:

 

New order:

 

 

The drives in the Exadata Storage Server with Sun Server X3-2L Servers are numbered from left to right in each row. The drives in the bottom row are numbers 0, 1, 2, and 3. The drives in the middle row are numbers 4, 5, 6, and 7. The drives in the top row are numbers 8, 9, 10, and 11.

The drives in the Exadata Storage Server with Sun Fire X4270 M2 Servers and earlier servers were numbered from the lower left to the top, such that the drives in the leftmost column were 0, 1, and 2. The drives in the next column were 3, 4, and 5. The drives in the next column were 6, 7, and 8. The drives in the rightmost column were 9, 10, and 11. The following table shows the disk layout for the hard disk drives in Exadata Storage Server with Sun Server X3-2L Servers and Exadata Storage Server with Sun Fire X4270 M2 Servers.

 

HCC on the Pillar Axiom

Oracle позволяет использовать HCC-компрессию не только на Экзадате, но и на ZFS storage appliance и на Pillar Axiom.  Если в качестве сервера взять T4 + Solaris 11, то получится отличная платформа для консолидации данных: много потоков и НСС впридачу!

Покажем работающи пример :

0. Берем сервер Т4, инсталлируем на нем Солярис 11. На Axiom создаем LUN и презентуем его серверу - все как всегда.

1. Компрессия возможна только на сырых томах (не на файловой системе), поэтому используем ASM, поэтому поэтому первым делом инсталлируем GI.

2. Для HCC требуется версия GI не ниже 11.2.3.0.3. В более ранних версиях оно не работает. Поэтому я взял последний PSU от January 2013 - ставим его на GI.

3. В ASM cоздаем дисковую группу. Для данной группы устанавливаем два обязательных параметра:
alter diskgroup data set attribute 'compatible.asm'='11.2.0.3';
alter diskgroup data set attribute 'storage.type'='AXIOM';

Если некоторая дисковая группа уже создана и в ней уже лежит БД, то ничего страшного - надо остановить БД и установить параметры. Причем, первый параметр - 'compatible.asm' - можно менять без остановки БД, он динамический.

 4. Инсталлируем бинарники СУБД: опять берем последнюю версию - 11.2.0.3 - и последний PSU - January 2013. Инсталлируем Оракл и создаем БД на нашей дисковой группе.

Готово!




Статисика показывает, что около 75% данных в базе относятся к закрытым периодам - прошлый год, квартал.
Еще 20% - это активные данные, которые иногда меняются.
Еще 5% - это горячие данные, активно изменяющиеся.

Первая категория данных - это хорошие кандидаты на НСС. Если их пожать, например, в 10 раз, то объем базы значительно сократится. Затраты ЦПУ возрастают в 3 раза, но ввод-вывод сократится в 10 раз. В общем, прирост производительности налицо.
Вторую категорию можно объявить как OLTP Compression  - затрат ЦПУ практически никаких, а объемы уменьшаются в два раза.
Третью категорию оставляем как есть.

 

exec dbms_stats.gather_system_stats('EXADATA');

Новая опция появилась в сборе системной статистики:
exec dbms_stats.gather_system_stats('EXADATA');

На какие параметры она влияет? Возьмем базу, в которой никогда системная статистика не собиралась, соберем ее и посмотрим, какие параметры изменились:

SQL> select * from aux_stats$;
SNAME           PNAME            PVAL1 PVAL2
--------------- ----------- ---------- ----------------
SYSSTATS_INFO   STATUS                 COMPLETED
SYSSTATS_INFO   DSTART                 11-30-2012 18:21
SYSSTATS_INFO   DSTOP                  11-30-2012 18:21
SYSSTATS_INFO   FLAGS                1
SYSSTATS_MAIN   CPUSPEEDNW  2588.93427
SYSSTATS_MAIN   IOSEEKTIM           10
SYSSTATS_MAIN   IOTFRSPEED        4096
SYSSTATS_MAIN   SREADTIMSYSSTATS_MAIN   MREADTIMSYSSTATS_MAIN   CPUSPEED
SYSSTATS_MAIN   MBRC
SYSSTATS_MAIN   MAXTHR
SYSSTATS_MAIN   SLAVETHR
13 rows selected.

SQL> set timing on
SQL> exec dbms_stats.gather_system_stats('EXADATA');
PL/SQL procedure successfully completed.
Elapsed: 00:00:37.97
SQL> select * from aux_stats$;
SNAME           PNAME            PVAL1 PVAL2
--------------- ----------- ---------- ----------------
SYSSTATS_INFO   STATUS                 COMPLETED
SYSSTATS_INFO   DSTART                 01-14-2013 15:06
SYSSTATS_INFO   DSTOP                  01-14-2013 15:06
SYSSTATS_INFO   FLAGS                1
SYSSTATS_MAIN   CPUSPEEDNW        2586
SYSSTATS_MAIN   IOSEEKTIM            3
SYSSTATS_MAIN   IOTFRSPEED      164076
SYSSTATS_MAIN   SREADTIM
SYSSTATS_MAIN   MREADTIM
SYSSTATS_MAIN   CPUSPEED
SYSSTATS_MAIN   MBRC               128
SYSSTATS_MAIN   MAXTHR
SYSSTATS_MAIN   SLAVETHR
13 rows selected.

MBRC = 128 * 8K = 1M.

Интересно, команда dbms_stats.gather_system_stats('EXADATA') измеряет ли что-то или записывает одни и те же данные? Для продолжения эксперимента возьмем вторую БД с другим размером блока (32К) и повторим запуск:

SNAME          PNAME            PVAL1 PVAL2
-------------- ----------- ---------- ----------------
SYSSTATS_INFO  STATUS                 COMPLETED
SYSSTATS_INFO  DSTART                 12-21-2012 11:34
SYSSTATS_INFO  DSTOP                  12-27-2012 10:38
SYSSTATS_INFO  FLAGS                1
SYSSTATS_MAIN  CPUSPEEDNW  2602.46361
SYSSTATS_MAIN  IOSEEKTIM           10
SYSSTATS_MAIN  IOTFRSPEED        4096
SYSSTATS_MAIN  SREADTIM          .708
SYSSTATS_MAIN  MREADTIM         5.327
SYSSTATS_MAIN  CPUSPEED          2591
SYSSTATS_MAIN  MBRC                11
SYSSTATS_MAIN  MAXTHR
SYSSTATS_MAIN  SLAVETHR

SQL> exec dbms_stats.gather_system_stats('EXADATA');
PL/SQL procedure successfully completed.

SQL> select * from aux_stats$;
SNAME          PNAME            PVAL1 PVAL2
-------------- ----------- ---------- ----------------
SYSSTATS_INFO  STATUS                 COMPLETED
SYSSTATS_INFO  DSTART                 01-14-2013 15:21
SYSSTATS_INFO  DSTOP                  01-14-2013 15:21
SYSSTATS_INFO  FLAGS                1
SYSSTATS_MAIN  CPUSPEEDNW        2580
SYSSTATS_MAIN  IOSEEKTIM            3
SYSSTATS_MAIN  IOTFRSPEED      235038
SYSSTATS_MAIN  SREADTIM          .708
SYSSTATS_MAIN  MREADTIM         5.327
SYSSTATS_MAIN  CPUSPEED          2591
SYSSTATS_MAIN  MBRC                32
SYSSTATS_MAIN  MAXTHR
SYSSTATS_MAIN  SLAVETHR


Очевидно, что поменялись те же самые 4 параметра.
MBRC получился тот же самый: 32*32К= 1M, а вот IOTFRSPEED подрос.
На CPUSPEED, SREADTIM и MREADTIM опция 'EXADATA' не влияет.

 

Latency Numbers Every Programmer Should Know

Интересная ссылка про относительное время доступа к данным :

http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html

У меня в IE не открылась, пробуйте что-то другое.

256g RAM per DB node with no price changes

CRS-2674: Start of 'ora.net1.network' on 'ed02dbadm02' failed

Accidentally Exadata was installed with wrong netmask 255.255.255.0 instead of 255.255.254.0.

How to correct this mistake easily ?

Solution:

Correct manually client net /etc/sysconfig/network-scripts/ifcfg-bondeth0
and set right    NETMASK=255.255.254.0

And same for mgmt net: ifcfg-eth0

then    ... service network restart ...

As a result we obtained errors in clusterware components:

[root@ed02dbadm01 ~]# crsctl start resource ora.LISTENER.lsnr
CRS-2672: Attempting to start 'ora.net1.network' on 'ed02dbadm01'
CRS-2672: Attempting to start 'ora.net1.network' on 'ed02dbadm02'
CRS-2674: Start of 'ora.net1.network' on 'ed02dbadm01' failed
CRS-2674: Start of 'ora.net1.network' on 'ed02dbadm02' failed
CRS-4000: Command Start failed, or completed with errors.
[root@ed02dbadm01 ~]#
[root@ed02dbadm01 ~]# crsctl start resource ora.net1.network
CRS-2672: Attempting to start 'ora.net1.network' on 'ed02dbadm01'
CRS-2672: Attempting to start 'ora.net1.network' on 'ed02dbadm02'
CRS-2674: Start of 'ora.net1.network' on 'ed02dbadm01' failed
CRS-2674: Start of 'ora.net1.network' on 'ed02dbadm02' failed
CRS-4000: Command Start failed, or completed with errors.

The root cause is the 'ora.net1.network' component.
Look at it carefully:
[root@ed02dbadm01 ~]# crsctl stat res ora.net1.network -p
...
USR_ORA_IF=bondeth0
USR_ORA_NETMASK=255.255.255.0
USR_ORA_SUBNET=172.31.4.0
...

And correct the USR_ORA_NETMASK=255.255.255.0:

# crsctl modify resource ora.net1.network -attr "USR_ORA_NETMASK=255.255.254.0"


And now the problem is solved :

ora.LISTENER.lsnr
               ONLINE  ONLINE       ed02dbadm01
               ONLINE  ONLINE       ed02dbadm02

ora.net1.network
               ONLINE  ONLINE       ed02dbadm01
               ONLINE  ONLINE       ed02dbadm02
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       ed02dbadm02
ora.LISTENER_SCAN2.lsnr
      1        ONLINE  ONLINE       ed02dbadm01
ora.LISTENER_SCAN3.lsnr
      1        ONLINE  ONLINE       ed02dbadm01
ora.ed02dbadm01.vip
      1        ONLINE  ONLINE       ed02dbadm01
ora.ed02dbadm02.vip
      1        ONLINE  INTERMEDIATE ed02dbadm01              FAILED OVER
ora.scan1.vip
      1        ONLINE  ONLINE       ed02dbadm02
ora.scan2.vip
      1        ONLINE  ONLINE       ed02dbadm01
ora.scan3.vip
      1        ONLINE  ONLINE       ed02dbadm01


Don't forget change netmask in the ILOM.




 

ORA-00439: feature not enabled: Server Flash Cache

Порекомендовал я на одной БД воспользоваться преимуществами флеш кеша.
http://docs.oracle.com/cd/E11882_01/server.112/e25494/memory005.htm#BABHEDBH

Заказчик купил карточку, задал параметры

db_flash_cache_file=/ssd/flashfile.dbf
db_flash_cache_size=36g
И перестартовал БД.  В результате получилось:

ORA-00439: feature not enabled: Server Flash Cache

Оказывается - баг:  Bug 12949806 - FLASH CACHE CHECK IS AGAINST ENTERPRISE-RELEASE  !
Сейчас против этого бага Оракл предлагает патч 12949806.
Окончательно бещают исправить в 11.2.0.4.