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.