Oracle mechanics

13.09.2015

ORA-12850 в многоинстансных запросах

Filed under: Oracle,RAC,shared pool — Игорь Усольцев @ 02:09
Tags:

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

11.2.0.3@INST1 SQL> @lock_tree
11.2.0.3@INST1 SQL> @lock_tree
with
*
ERROR at line 1:
ORA-12850: Could not allocate slaves on all specified instances: 2 needed, 0 allocated

— при втором и последующих выполнениях

Разработчики по этому поводу — How To Diagnose ORA-12850 Could Not Allocate Slaves On All Specified Instances(Doc ID 1350377.1):

In case you know the SQL that caused the ORA-12850, experienced DBAs/developers can purge the SQL from the library cache on all nodes and try to execute the SQL again

— отсылают к использованию DBMS_SHARED_POOL.PURGE, что не всегда приносит желаемый эффект, т.е. проблемный курсор из Shared Pool-ов инстансов (а точнее, из его видимой через GV$SQL части) после такой очиски «исчезает», но практически это может не решить проблемы, и ошибка ORA-12850 проявится при очередном выполнении

Поскольку ошибка связана с попытками повторного использования курсора, проблему можно решить сделав курсоры уникальными, например, в скрипте LOCK_TREE.SQL следующим образом:

col SDATE for a21 NOPRI
col CHAR_DATE new_value SYS_DATE

SET TERMOUT OFF

select to_char(sysdate,'dd.mm.yyyy hh24:mi:ss') CHAR_DATE from dual;

SET TERMOUT ON

select '&&SYS_DATE' as SDATE...

— что вполне допустимо для нечасто (и не чаще раза в 1 секунду) выполняемого диагностического скрипта — «и заинька прыгает снова«:

11.2.0.3@INST1 SQL> @lock_tree
11.2.0.3@INST1 SQL> @lock_tree
11.2.0.3@INST1 SQL> @lock_tree

BLOCKING_TREE        Event name                     REQ_OBJECT                      LAST_CALL_ET  SECS_IN_WAIT BLOCK_SESSTAT PDM SQL_ID        OSUSER  SPID   CLNT_HOST CLNT_PID  CLNT_PORT SQL_TEXT                             REQ_ROWID
-------------------- ------------------------------ ------------------------------- ------------ ------------- ------------- --- ------------- ------- ------ --------- -------- ---------- ------------------------------------ ------------------
INST#1 SID#170       SQL*Net message from client    TABLE PARTITION UFF.EXPORT               361           361     NO HOLDER  NO gp69w2274pw2a uff     19632  host2g    31239         45348 SELECT order.id AS order_id, order.p AAKFp1ACKAADYj6AAA
  INST#1 SID#4405    enq: TX - row lock contention  TABLE PARTITION UFF.EXPORT               362           362         VALID  NO 73qhtmwmtat18 uff     19744  host3g    9561          35064 MERGE INTO EXPORT EXP USING (SELECT  AAKFp1ACKAADYj6AAV
    INST#1 SID#3293  enq: TX - row lock contention  TABLE PARTITION UFF.ORDER_CACHE          361           361         VALID  NO ay0gdgrf2nm3g uff     19853  host2g    31239         45613 MERGE INTO UFF.ORDER_CACHE TC USING  AAKFpxACmAAGA2dAAO

— в смысле, теперь скрипт не вызывает ошибок

2 комментария »

  1. Такая ситуация может возникнуть при установленном параметре cursor_sharing в значение отличное от EXACT. Установите cursor_sharing=EXACT и не надо делать никаких ухищрений чтобы курсоры были разными.

    комментарий от vvd — 01.10.2015 @ 12:48 | Ответить

    • параметр был и остаётся в значении:

      SQL> @param cursor_sharing
       
      NAME            VALUE  DSC
      --------------- ------ -------------------
      cursor_sharing  EXACT  cursor sharing mode

      комментарий от Игорь Усольцев — 01.10.2015 @ 12:59 | Ответить


RSS feed for comments on this post. TrackBack URI

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Блог на WordPress.com.

%d такие блоггеры, как: