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.

 

{[ERROR] Need at least 4363 MB free space on cell. Found only 3961 MB.

I decided to patch our 1/4 Exadata and have run prerequisits:

# patchmgr -cells cell_group -patch_check_prereq

and have got the result in all cells:

ed01cel03: [ERROR] Need at least 4363 MB free space on cell. Found only 3961 MB.

The disk examination on the cell shows :
 [root@ed01cel02 ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/md5   9.9G 5.6G  3.8G   59%   /
- OS Watcher 729Мб, /opt/oracle.oswatcher/osw/archive

- the one big file in strange place, I suppose I should remove this file and all the directory _patch_hctap_:
[root@ed01cel01 _p_]# pwd
/root/_patch_hctap_/_p_

[root@ed01cel01 _p_]# ls -l

total 1241168

-rw-r--r-- 1 root root 1267945472 Aug 1 10:20 11.2.3.1.1.120607.iso

 

Looking for solution I found interesting lines in patchmgr utility:

-cleanup
Clean up all patch files and temporary content on all cells.
If this step can be done manually if patch fails by removing
directory /root/_patch_hctap_ on each cell.

O, my mistake ! I forgot to run:   ./patchmgr -cells cell_group -cleanup

before      # patchmgr -cells cell_group -patch_check_prereq

 

In patchmgr I found other similar messages:

 

- [ERROR] Patch or rollback failed. Please run cleanup before retrying.

- Only if the cleanup fails from prior launch point, use -reset_force instead of -cleanup and then retry.

 

The summary: Don't forgot to run ./patchmgr  -cleanup !

Exadata features 11.2.2.4 and 11.2.3.2: smart flash logging and write-back smart flash cache

Несколько слов про фичи системы хранения Экзадаты:

- smart flash logging (11.2.2.4)
- write-back smart flash cache (11.2.3.2)

1. 

Возможность smart flash logging появилась в версии 11.2.2.4 (октябрь 2012) и разрешает записывать redo logs в flash cache. Смысл этой возможности - ускорить commit ( = уменьшить log file sync). По команде commit log buffer пишется на жесткие диски и в flash cache одновременно. Если дисковая система перегружена, то flash cache ответит быстрее и пользовательский процесс продолжит свою работу.
Под smart flash logging -опцию выделяется 512Мб флеш кеша на каждом storage cell.
В результате smart flash logging возрастает износ flash-памяти.
Standby redo логи также покрываются этой технологией.
Для полноты картины надо сказать, что поверх физических дисков в каждом storage cell стоит RAID-контроллер с 512Мб кеш-памяти, защищенной батарейкой, поэтому запись на физические диски фактически означает запись кеш RAID-контроллера, т.е. по-идее должна выполняться достаточно быстро..
 
Эта возможность включается автоматически при создании специального объекта flashlog:

CREATE FLASHLOG [ALL [FLASHDISK]] [attribute=value] [,attribute=value] ...
Examples:
CREATE FLASHLOG ALL
CREATE FLASHLOG ALL SIZE=1G
CREATE FLASHLOG CELLDISK='fd1,fd2'
CREATE FLASHLOG CELLDISK='fd1,fd2' SIZE=1G
Отключается она удалением flashlof: "drop flashlog all".

Посмотреть параметры этого объекта можно командой list flashlog detail:

CellCLI> list flashlog detail
         name:                   bip1cel01_FLASHLOG
         cellDisk:               FD_06_bip1cel01,FD_14_bip1cel01,FD_07_bip1cel01,FD_15_bip1cel01,FD_03_bip1cel01,FD_01_bip1cel01,FD_04_bip1cel01,FD_13_bip1cel01,FD_10_bip1cel01,FD_00_bip1cel01,FD_12_bip1cel01,FD_09_bip1cel01,FD_05_bip1cel01,FD_11_bip1cel01,FD_08_bip1cel01,FD_02_bip1cel01
         creationTime:           2012-08-08T13:04:26+02:00
         degradedCelldisks:
         effectiveSize:          512M
         efficiency:             100.0
         id:                     dec8c793-bf95-4d41-978b-f8712e383282
         size:                   512M
         status:                 normal

Итак, что мы видим: FLASHLOG - это специальный объект в FC, под который отводися по 32Мб из каждого флеш диска, что составляет по 512Мб на сервер хранения.

Статистики эффективности этого объекта описаны в документации "Exadata Storage Server Software User's Guide", "7 Monitoring and Tuning Oracle Exadata Storage Server Software", "Monitoring Flash Log with Metrics" :

 

Table 7-4 Flash Log Metrics and Descriptions

Metric	Description
FL_ACTUAL_OUTLIERS	This metric shows the number of redo writes written to flash and disk that exceeded the outlier threshold.
FL_BY_KEEP	This metric shows the number of redo data bytes saved on flash due to disk I/O errors.
FL_DISK_FIRST	This metric shows the number of redo writes first written to disk.
FL_DISK_IO_ERRS	This metric shows the number of disk I/O errors encountered by Flash Log.
FL_EFFICIENCY_PERCENTAGE	This metric shows the efficiency of Flash Log expressed as a percentage.
FL_EFFICIENCY_PERCENTAGE_HOUR	This metric shows the efficiency of Flash Log over the past hour expressed as a percentage.
FL_FLASH_FIRST	This metric shows the number of redo writes first written to flash.
FL_FLASH_IO_ERRS	This metric shows the number of flash I/O errors encountered by Flash Log.
FL_FLASH_ONLY_OUTLIERS	This metric shows the number of redo writes written to flash that exceeded the outlier threshold.
FL_IO_DB_BY_W	This metric shows the number of megabytes written to hard disk by Flash Log.
FL_IO_DB_BY_W_SEC	This metric shows the number of megabytes written per second were written to hard disk by Flash Log.
FL_IO_FL_BY_W	This metric shows the number of megabytes written to flash by Flash Log.
FL_IO_FL_BY_W_SEC	This metric shows the number of megabytes written per second were written to flash by Flash Log.
FL_IO_W	This metric shows the number of writes serviced by Flash Log.
FL_IO_W_SKIP_BUSY	This metric shows the number of redo writes that could not be serviced by Flash Log because too much data had not yet been written to disk.
FL_IO_W_SKIP_BUSY_MIN	This metric shows the number of redo writes during the last minute that could not be serviced by Flash Log because too much data had not yet been written to disk.
FL_IO_W_SKIP_LARGE	This metric shows the number of large redo writes that could not be serviced by Flash Log because the size of the data was larger than the amount of available space on any flash disk.
FL_PREVENTED_OUTLIERS	This metric shows the number of redo writes written to disk that exceeded the outlier threshold. These writes would have been outliers if not for Flash Log.

Пример с продуктива:

CellCLI> list metriccurrent where objectType='FLASHLOG'
         FL_ACTUAL_OUTLIERS              FLASHLOG        0 IO requests
         FL_BY_KEEP                      FLASHLOG        0
         FL_DISK_FIRST                   FLASHLOG        45,809,503 IO requests
         FL_DISK_IO_ERRS                 FLASHLOG        0 IO requests
         FL_EFFICIENCY_PERCENTAGE        FLASHLOG        100 %
         FL_EFFICIENCY_PERCENTAGE_HOUR   FLASHLOG        100 %
         FL_FLASH_FIRST                  FLASHLOG        2,127,006 IO requests
         FL_FLASH_IO_ERRS                FLASHLOG        0 IO requests
         FL_FLASH_ONLY_OUTLIERS          FLASHLOG        5 IO requests
         FL_IO_DB_BY_W                   FLASHLOG        5,057,869 MB
         FL_IO_DB_BY_W_SEC               FLASHLOG        0.000 MB/sec
         FL_IO_FL_BY_W                   FLASHLOG        5,177,941 MB
         FL_IO_FL_BY_W_SEC               FLASHLOG        0.002 MB/sec
         FL_IO_W                         FLASHLOG        47,936,509 IO requests
         FL_IO_W_SKIP_BUSY               FLASHLOG        0 IO requests
         FL_IO_W_SKIP_BUSY_MIN           FLASHLOG        0.0 IO/sec
         FL_IO_W_SKIP_LARGE              FLASHLOG        0 IO requests
         FL_PREVENTED_OUTLIERS           FLASHLOG        17,693 IO requests


Важное значение имеют метрики, точнее их отношение:  
FL_IO_W - всего операций записи,
FL_DISK_FIRST - первым возвратил ответ диск и
FL_FLASH_FIRST - первым возвратил ответ flashlog.

Под OUTLIERS подразумеваются операции log file sync которые выполнялись более 500мс.   

2.

Вторая возможность - это write-back smart flash cache доступна начиная с версии 11.2.3.2. Он не имеет никакого отношения к smart flash logging.

 

В версии до 11.2.3.2 при поступлении команды на запись cellsrv выполняет запись на жесткие диски (а фактически, в 512Мб кеш RAID-контроллера) и затем решает - кешировать или нет эти данные в flash cache (записывать их в flash cache или нет). Таким образом, если блок может кэшироваться в flash cache, то сервер БД ждёт подтверждения от диска. Если дисковая система в данные момент занята, то сервер БД ждет ее освободждения.

Возможность write-back smart flash cache означает выполнение записи в кеш RAID-контроллера и в flash cache одновременно. Если дисковая система перегружена, то flash cache ответит быстрее.
Подчеркну еще раз (как я сам понимаю) - ВСЕ операции записи теперь вначале записываются в FC, и только потом (при необходимости) в фоновом порядке переносятся на диск!

 

В результате такой политики записи: 

- данные которые необходимо кешировать в flash cache уже находятся в нем. бесполезные данные будут перезаписаны в следующем цикле перезаписи.

- возрастает потребление и износ flash cache.

- потребление flash cache возрастает при операциях DML по причине зеркалирования в ASM. Т.е. модифицированные блоки будут кешированы в ДВУХ или ТРЕХ серверах хранения. Блоки, которые кешированы по причине SELECT (прочитанные с диска) - будут кешированы только в ОДНОМ сервере хранения (primary копия заркала), до тех пор, пока они не будут модифицированы.
 

Появление версии 11.2.3.2 совпало с выходом Экзадаты Х3-2. Т.е. 11.2.3.2 - минимальная версия для Х3-2, которая не ней доступна. А в Х3-2 Оракл в 4 раза увеличил размер flash cache который к тому же стал на 40% быстрее. Также в версии 11.2.3.2 появилось важное изменение - данные записанные в flash cache сохраняются в нем после перезагрузки сервера (persistent FC). Технология изменилась с SLC на MLC.

 

Exadata Simulator in text mode

Exadata Simulator может работать в текстовом режиме !

Ключ к его запуску: $ORACLE_HOME/rdbms/admin/tcellsim.sql


Как и ранее типичный сценарий использования Симулятора прежний:
1. Создаем SQL Tuning Set (STS).
2. Запускаем симулятор
3. Симулятор делает два прохода. В первом проходе он выполняет SQL из STS. Во втором проходе он опять выполняет SQL из STS однако в предположении, что в системе хранения присутствуют серверы хранения.
4. Выполняет сравнение двух проходов.


Вот как это выглядит в скрипте:

prompt
prompt   >> 2. Test execute statements with cell simulatin DISABLED
prompt   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BEGIN
  IF (:err = 0) THEN
    dbms_sqlpa.execute_analysis_task(
       task_name => :aname,
       execution_type => 'execute',
       execution_name => 'cell_simulation_DISABLED',
       execution_params => dbms_advisor.arglist('cell_simulation_enabled','FALSE'));
  END IF;
  -- handle exception
  EXCEPTION
   WHEN OTHERS THEN
     :err := 1;
     RAISE;
END;
/
prompt
prompt  >> 3. Test execute statements with cell simulation ENABLED
prompt  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BEGIN
  IF (:err = 0) THEN
    dbms_sqlpa.execute_analysis_task(
     task_name => :aname,
     execution_type => 'execute',
     execution_name => 'cell_simulation_ENABLED',
     execution_params => dbms_advisor.arglist('cell_simulation_enabled','TRUE'));
  END IF;
  -- handle exception
  EXCEPTION
   WHEN OTHERS THEN
     :err := 1;
     RAISE;
END;
/

 

You (oracle) are not allowed to use this program (crontab)

Сегодня выяснилось, что в Экзадате не удается создать задание для cron:

[root@ed01db01 etc]# su - oracle
[oracle@ed01db01 ~]$ crontab -l
You (oracle) are not allowed to use this program (crontab)
See crontab(1) for more information

Причем, эта беда наблюдается не только под пользователем oracle, но и под другими:

[root@ed01db01 pam.d]# useradd yu
[root@ed01db01 pam.d]# su - yu
[yu@ed01db01 ~]$ crontab -l
You (yu) are not allowed to use this program (crontab)

Металинк дает свои дельные советы, которые тоже не работают :

 

Non Root Users Are Unable To Create Crontab Entries [ID 1268765.1]

Cron Scripts Might Not Be Executed After A Fresh Install On Exadata [ID 1323999.1]

 

 

Все оказалось примитивно просто: для решения проблемы достаточно добавить oracle в /etc/cron.allow  !

 

Вспоминаем основы:

 

You can execute crontab if your name appears in the file /etc/cron.allow.
If that file does not exist, you can use crontab if your name does not appear in the file /etc/cron.deny.
If only cron.deny exists and is empty, all users can use crontab.
If neither file exists, only the root user can use crontab.

 

HCC and CPU consumption

We tested the CPU consumption for HCC and traditional segments.
We run select sum(Col1) from table  under the 10046 trace for traditional table and its compresses copies. 10046 trace shows the time in microseconds. All segments were in the SGA in order to exclude physical IO. Original table size was 16g, the compressed size is

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

Table type           Compression ratio   CPU

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

Original table            1               1

Compress for OLTP         1.8             0.8

QL                        4.9             3.3

QH                       20               3.5

AL                       20               3.5

AH                       59              11  
----------------------------------------------
            
As you can see QL, QH, AL takes 3.3-3.5 more CPU cycles (CPU time).
But we see the significant compression ratio for HCC segments.
Therefore, if any select in traditional DB spend 90% time in IO wait and 10% time in CPU
then with 10-times compression it will spend 30% on the CPU and 90/10=9% in IO = 39% of original time.

The packing time depends on the compression ratio (the more compression ratio the more time to create HCC segment).

The unpacking time not depends on the compression ratio.

HCC algorithms are:

Query Low  - LZO
Query High - ZLIB
Archive Low - ZLIB
Archive High - bzip2

CPU performace comparison

For comparison purposes we tested some modern CPU (previous post) .
Main aim is to evaluate one core.

So, we wrote two bash scripts :


 time for ((i=0;i<10000000;i++)); do :; done

((i=0)); time while (( i<10000000 )); do ((i+=1)); done


Because both test give similar results I show only one column (timings in seconds):

---------------- -----------------------------------
                 for((i=0;i<10000000;i++));do :;done
---------------- -----------------------------------
SuperMicro                         52.38-53.85     
Intel Xeon X5675 3.07GHz          sys 3.17-3.30s   
                                                   
ODA                                58.22-60.07     
Intel Xeon X5675 3.07GHz          sys 3.32-3.51s   
                                                   
Exadata                            57.80-59.20     
Intel Xeon X5675 3.07GHz          sys 3.32-3.85s   
                                                   
T4 max-ipc                          138-149.11     
2824MHz                           sys 0.005-0.012s 
                                                   
T4 max-throughput                   144.78-145.30  
2824MHz                           sys 0.004s       
                                                   
Sun SPARC Enterprise M4000          161.78         
System clock frequency: 1012 MHz  sys 0.008s       
Run MHz 2150                                       
                                                   
SunFire 240                         290.25         
SUNW,UltraSPARC-IIIi              sys 0.70s        
1503 MHz                                           
                                                   
IBM JS22 POWER6 4 ГГц               227.30         
IBM,                              sys 6.672s       
frequency 4005000000 Processor Speed               
-----------------------------------------------------

Full table here.

                                                   
Conclusions:
- we cannot see the difference between T4 max-ipc and max-throughput modes.
- T4 slowly than Intel Xeon 5675 approximately 2.5-3 times

ORA-01665: control file is not a standby control file

Today was the task : open physical standby database in read-write mode, do the write test on it and revert it back to physical standby.

I enabled flashback database on standby, open it and flashed back.
But after flashback the standby don't want to back to its standby state:

RMAN> flashback database to restore point yu1;

Starting flashback at 13.07.2012 07:19:26
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK


starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished flashback at 13.07.2012 07:19:29
 

...

RMAN> sql 'alter database mount standby database';

using target database control file instead of recovery catalog
sql statement: alter database mount standby database
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/13/2012 07:21:45
RMAN-11003: failure during parse/execution of SQL statement: alter database mount standby database
ORA-01665: control file is not a standby control file

The solution for this problem is:

ALTER DATABASE CONVERT TO PHYSICAL STANDBY DATABASE;

FAL[server]: DGID from FAL client not in Data Guard configuration

Creating another DataGuard I obtained new message in alert.log, which I never see before:

FAL[server]: DGID from FAL client not in Data Guard configuration

Obviously it is my mistake: the typo error in the log_archive_config parameter.

In one DB:
log_archive_config       = "DG_CONFIG=(p198,p199)"

In other DB
log_archive_config       = "DG_CONFIG=(f198,f199)"

After correction log_archive_config the error message disappeared.

CELL-01519 during execution onecommand

During the process of installing new Exadata we have got the message in the Storage Cell:
"
CELL-01519: Cannot talk to the Management Server (MS). Error: ; nested exception is:
HTTP transport error: javax.xml.soap.SOAPException: java.security.PrivilegedActionException: javax.xml.soap.SOAPException: Message send failed: localhost: localhost
"

This message appears by itself.
We only ran onecommand on the DB node, nothin more.
We tried "cellcli list cell" in command line - and got this message again.


The reason is simple: line "127.0.0.1 localhost.localdomain localhost" was absent in /etc/hosts.
We think that onecommand did it.
After inserting "127.0.0.1 localhost.localdomain localhost" in /etc/hosts  the cellcli was working well.

Exadata Simulator

Как разрабатывать приложение не имея Экзадаты ?

Как узнать, получит ли ваше приложение пользу от переноса на Экзадату?

 

Exadata Simulator - вот кто делает это.

Exadata Simulator - это новый функционал, появившийся в 11.2 в рамках пакета SQL Performance Analyzer. Он может предсказать в каких SQL и в каких шагах плана выполнения может быть использован Smart Scan и насколько сократится DBTime в целом для всей БД после перехода на Экзадату.

 

Доступ к Exadata Simulator возможен в текстовом режиме из SQLPLUS:

DBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER 

(

 Parameter => ‘CELL_SIMULATION_ENABLED’ -- Set it to 'TRUE' to simulate Exadata Cell effect on SQL tuning set

)

Но гораздо удобнее пользоваться через DB Control: 

Advisory Central -> Exadata Simulation