Метод распараллеливания DML, который можно встретить при обновлении OEBS, и как с этим бороться

Намедни, накатывая очередное обновление OEBS в части бд, Иван Постников обратил внимание на странно захинтованные запросы вида:

SELECT /*+ rowid(cust_accts) */
...
  FROM HZ_CUST_ACCOUNTS CUST_ACCTS
 WHERE ORIG_SYSTEM_REFERENCE IS NOT NULL
   AND STATUS IN ('A', 'I')
   AND CUST_ACCTS.CUST_ACCOUNT_ID NOT IN
       (SELECT /*+ HASH_AJ */
         OSR.OWNER_TABLE_ID
          FROM HZ_ORIG_SYS_REFERENCES OSR
         WHERE OSR.OWNER_TABLE_NAME = 'HZ_CUST_ACCOUNTS'
           AND CUST_ACCTS.ORIG_SYSTEM_REFERENCE = OSR.ORIG_SYSTEM_REFERENCE
           AND OSR.STATUS = 'A')
   AND ROWID BETWEEN :b2 AND :b1

, выполняющиеся неразумное время пачками по несколько десятков штук Читать далее

И ещё про 12c SQL Directives, Extended statistics и инвалидацию PL/SQL

Лёня, чувствую, что наш опыт использования 12c местами опережает международные стандарты)

Вот с полгода назад столкнулись, обследовали / нашли workaround, ты создание патча 19450314 у бусурман доброжелательных сотрудников MOS истребовал и всю проблему изучил/расписал в подробностях — Extended statistics и invalid objects

А иностранные люди продолжают сталкиваться c проблемой вновь

Предлагаю делать публикации на латыни — языке международного общения эскулапиев!

In vino veritas in aqua sanitas, как говорится

Всех с наступающими Рождественско-Новогодними праздниками!

ORA-00600: [ksxp_rm_can_switch4]

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


[root@appl1.oebs.yandex.net]:~# /opt/oracle/product/grid/11.2.0.4/rootupgrade.sh
...
OLR initialization - successful
Replacing Clusterware entries in inittab
Start of resource "ora.asm" failed
CRS-2672: Attempting to start 'ora.drivers.acfs' on 'appl1'
CRS-2676: Start of 'ora.drivers.acfs' on 'appl1' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'appl1'
CRS-5017: The resource action "ora.asm start" encountered the following error:
ORA-00600: internal error code, arguments: [ksxp_rm_can_switch4], [196609], [197124], [], [], [], [], [], [], [], [], []
Failed to start Oracle Grid Infrastructure stack
Failed to start ASM at /opt/oracle/product/grid/11.2.0.4/crs/install/crsconfig_lib.pm line 1339.

Читать далее

Как ведет себя standby после failover primary database

Пришлось тут на днях выполнить failover на один из standby. Были опасения, как себя поведет второй standby после такого. Оказалось, ничего страшного, даже процесс MRP был перезапущен автоматически.

Ниже фрагмент alert.log:

Media Recovery Waiting for thread 1 sequence 17950
Tue Apr 08 12:29:49 2014
RFS[1]: Assigned to RFS process 32052
RFS[1]: Opened log for thread 1 sequence 25 dbid 965167768 branch 844331483
A new recovery destination branch has been registered
RFS[1]: Standby in the future of new recovery destinationBranch(resetlogs_id) 844331483
Incomplete Recovery SCN: 17347307
Resetlogs SCN: 17347308
Standby Became Primary SCN: 17347305
RFS[1]: New Archival REDO Branch(resetlogs_id): 844331483 Prior: 833198555
RFS[1]: Archival Activation ID: 0x39a01d0e Current: 0x39871096
RFS[1]: Effect of primary database OPEN RESETLOGS
RFS[1]: Managed Standby Recovery process is active
RFS[1]: Incarnation entry added for Branch(resetlogs_id): 844331483 (IDM1)
Tue Apr 08 12:29:50 2014
Setting recovery target incarnation to 3
Archived Log entry 17945 added for thread 1 sequence 25 rlc 844331483 ID 0x39a01d0e dest 3:
Tue Apr 08 12:29:52 2014
MRP0: Incarnation has changed! Retry recovery...
Errors in file /opt/oracle/base/diag/rdbms/idm/IDM1/trace/IDM1_pr00_30363.trc:
ORA-19906: recovery target incarnation changed during recovery
Recovery interrupted!
Tue Apr 08 12:29:52 2014
started logmerger process
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 32 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Tue Apr 08 12:29:53 2014
Media Recovery Waiting for thread 1 sequence 1
Fetching gap sequence in thread 1, gap sequence 1-24
Tue Apr 08 12:30:54 2014

В логе. Второй standby на всякий случай был выключен в момент failover. Спустя некоторое время его включили обратно, primary передал на него очередной журнал (25-й по счету). Standby увидел, что в в нем новая инкарнация, добавил её в controlfile, переключился на неё, рестартовал процесс mrp, и запросил по механизму FAL пропущеные 24 лога. И все это автоматически🙂

Читать далее

Downgrade compatibility.rdbms

Итак, допустим вы изменили compatibility.rdbms в большую сторону прежде чем успели обновить бинарники RDBMS и по какой-то причине у вас нет пока возможности их обновить. Было бы очень замечательно откатить свои зменения, потому как бинарники не смогут смонтировать дисковую группу у которой версия выше. Но, как заверяют нас уважаемые издания, различные крутые перцы и сам оракл, это НЕВОЗМОЖНО!

(http://www.dba-oracle.com/t_11g_new_asm_attributes.htm)
(http://www.pythian.com/blog/oracle-11g-asm-diskgroup-compatibility/)

Но, как нам удалось выяснить, это все же возможно.

Читать далее

Производительность mdraid 1+0

В Vertica есть встроенные средства анализа производительности дисковой подсистемы.

Мне стало интересно, а какие цифры эти утилиты покажут на нашем софтварном mdraid 1+0?

Запустив команду и подождав около часа, я получил результаты:


SELECT MEASURE_LOCATION_PERFORMANCE('/opt/dwh/dwh/v_dwh_node0005_data' , 'v_dwh_node0005');

Throughput : 246 MB/sec. Latency : 318 seeks/sec

При этом простой тест скорости ввода-вывода на одном диске показывает


# hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 19598 MB in 2.00 seconds = 9813.93 MB/sec
Timing buffered disk reads: 512 MB in 3.01 seconds = 169.99 MB/sec

Странность здесь в том, что утилитой hdparm скорость одного диска 170 MB/sec, а скорость чтения vertica массива из 4-х дисков 246 MB/sec

Читать далее

Диагностика проблем сетевых соединений с использованием Oracle wait event интерфейса

Беда пришла, как обычно, откуда не ждали — т.е. неизвестно откуда:

sqlnet_bad

— ось ординат на графике мониторинга отражает резко увеличившееся время выполнения некоего набора критически важных запросов и процедур

Ну и поскольку кроме графика из логов приложения получить никакой дополнительной информации не было решительно никакой возможности — пришлось нам с Дмитрием Якубеней искать причины возникновения проблем средствами Oracle

При рассмотрении AWR на втором месте в топе было замечено нехарактерное для системы ожидание SQL*Net more data from client: Читать далее