Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
-2-
bdsm_sql
однако обращение к типам с удаленной бд вроде как может начать распределенную транзакцию.
любое обращение к оракловому дблинку начинает распределенную транзакцию. но можешь сделать гетерогенное соединение, в котором можно указать тип "распределенности".

bdsm_sql
однако insert /*+ append */ into x select * from y@remote успешно работает
где x plsql-переменная?


x - таблица

автор
любое обращение к оракловому дблинку начинает распределенную транзакцию

не-а

SQL> explain plan for
  2  insert /*+ append */ into dist_test select * from dual@pip_test_link
  3  /

Explained

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2098243032
--------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     | I
--------------------------------------------------------------------------------
|   0 | INSERT STATEMENT |           |     1 |     2 |     2   (0)| 00:00:01 |
|   1 |  LOAD AS SELECT  | DIST_TEST |       |       |            |          |
|   2 |   REMOTE         | DUAL      |     1 |     2 |     2   (0)| 00:00:01 | P
--------------------------------------------------------------------------------
Remote SQL Information (identified by operation id):
----------------------------------------------------
   2 - SELECT /*+ OPAQUE_TRANSFORM */ "DUMMY" FROM "DUAL" "DUAL" (accessing
       'PIP_TEST_LINK' )

16 rows selected

SQL> insert into dist_test@pip_test_link values(1)
  2  /

1 row inserted

SQL> explain plan for
  2  insert /*+ append */ into dist_test select * from dual@pip_test_link
  3  /

Explained

SQL> select * from table(dbms_xplan.display)
  2  /

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1788691278
--------------------------------------------------------------------------------
| Id  | Operation                | Name      | Rows  | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |           |     1 |     2 |     2   (0)| 00:0
|   1 |  LOAD TABLE CONVENTIONAL | DIST_TEST |       |       |            |
|   2 |   REMOTE                 | DUAL      |     1 |     2 |     2   (0)| 00:0
--------------------------------------------------------------------------------
Remote SQL Information (identified by operation id):
----------------------------------------------------
   2 - SELECT /*+ OPAQUE_TRANSFORM */ "DUMMY" FROM "DUAL" "DUAL" (accessing 'PIP

15 rows selected

SQL> rollback
  2  /

Rollback complete
SQL>


в первом случае обычная транзакция, в которой возможен pdml
во втором распределенная
21 сен 12, 09:13    [13199758]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
xtender
bdsm_sql,

автор
In the following, we do not have a distributed transaction when we just insert /*+ append */ into local_table select * from remote@table; - we just have a single site transaction.
это неверно, и легко проверяется:
create table xt_test as select * from all_users where 1=0;
insert into xt_test select * from all_users@remote;
select * from v$lock l where l.type='DX' and sid=sys_context('userenv','sid');
rollback;
insert/*+ append */ into xt_test select * from all_users@remote;
select * from v$lock l where l.type='DX' and sid=sys_context('userenv','sid');
rollback;
Оба инсерта покажут DX'ы


DX сдается мне не показатель..

SQL> insert into dist_test select * from dual@pip_test_link
  2  /

1 row inserted

SQL> select * from v$lock where type = 'DX' and sid = sys_context('userenv', 'sid')
  2  /

ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
5DC40740 5DC4076C        584 DX           58          0          4          0          0          0

SQL> rem как будто началась распределенная транзакция

SQL> insert /*+ append */ into dist_test2 select * from dual@pip_test_link
  2  /

1 row inserted

SQL> select * from dist_test2
  2  /

select * from dist_test2
ORA-12838: cannot read/modify an object after modifying it in parallel

SQL> rem однако pdml работает

SQL> rollback
  2  /

Rollback complete

SQL> insert into dist_test@pip_test_link values(1)
  2  /

1 row inserted

SQL> select * from v$lock where type = 'DX' and sid = sys_context('userenv', 'sid')
  2  /

ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
-------- -------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
5DC40828 5DC40854        584 DX            2          0          4          0          0          0

SQL> rem тоже распределенная

SQL> insert /*+ append */ into dist_test2 select * from dual@pip_test_link
  2  /

1 row inserted

SQL> select * from dist_test2
  2  /

DUMMY
-----
X

SQL> rem но PDML не работает (как и заявлено для распределенных транзакций)

SQL> rem как так
SQL>
21 сен 12, 09:28    [13199797]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
bdsm_sql,

это не pdml:
+
 >> alter session disable parallel dml;

Session altered.

 >> insert/*+ append */ into xt_test select * from all_users@remote;

17254 rows created.

 >> select * from xt_test where rownum<10;
select * from xt_test where rownum<10
              *
ERROR at line 1:
ORA-12838: cannot read/modify an object after modifying it in parallel

да и имхо вывод неправильный. Показатель не включение/выключение direct path insert, т.к. его скорее всего просто разрешили для insert/*+ append */ select .. from ...@remote.
21 сен 12, 09:46    [13199934]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
PDML - так сказать условное название direct-path insert. может ввело тебя в заблуждение.
то что ты запретил pdml не запрещает direct-path insert.
21 сен 12, 10:03    [13200040]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
а вывод лично у меня такой. де-факто распределенная транзакция при select from @ не начинается, не смотря на локи DX. то есть двух-фазового коммита по окончании не происходит
21 сен 12, 10:04    [13200047]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
а так же
SQL> select * from v$transaction@pip_test_link
  2  /

ADDR         XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS           START_TIME           START_SCNB START_SCNW START_UEXT START_UBAFIL START_UBABLK START_UBASQN START_UBAREC SES_ADDR       FLAG SPACE RECURSIVE NOUNDO PTX NAME                                                                             PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN PTX_XIDSLT PTX_XIDSQN     DSCN-B     DSCN-W  USED_UBLK  USED_UREC     LOG_IO     PHY_IO     CR_GET  CR_CHANGE START_DATE   DSCN_BASE  DSCN_WRAP  START_SCN DEPENDENT_SCN XID              PRV_XID          PTX_XID
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------- ------------ ------------ ------------ ------------ -------- ---------- ----- --------- ------ --- -------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ------------- ---------------- ---------------- ----------------
5EFA7D60         10         29     215865          7       8616      31338         37 ACTIVE           09/18/12 17:14:05    1849026198          0          2            7         8616        31338           36 5F4BB088       3587 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0          0          1          2         11          4         20          0 9/18/2012 5          0          0 1849026198             0 0A001D00394B0300 0000000000000000 0000000000000000

-- висит какая-то с 18 сентября, не важно

SQL> insert into dist_test@pip_test_link values(1)
  2  /

1 row inserted

SQL> select * from v$transaction@pip_test_link
  2  /

ADDR         XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS           START_TIME           START_SCNB START_SCNW START_UEXT START_UBAFIL START_UBABLK START_UBASQN START_UBAREC SES_ADDR       FLAG SPACE RECURSIVE NOUNDO PTX NAME                                                                             PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN PTX_XIDSLT PTX_XIDSQN     DSCN-B     DSCN-W  USED_UBLK  USED_UREC     LOG_IO     PHY_IO     CR_GET  CR_CHANGE START_DATE   DSCN_BASE  DSCN_WRAP  START_SCN DEPENDENT_SCN XID              PRV_XID          PTX_XID
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------- ------------ ------------ ------------ ------------ -------- ---------- ----- --------- ------ --- -------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ------------- ---------------- ---------------- ----------------
5EFA7D60         10         29     215865          7       8616      31338         37 ACTIVE           09/18/12 17:14:05    1849026198          0          2            7         8616        31338           36 5F4BB088       3587 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0          0          1          2         11          4         20          0 9/18/2012 5          0          0 1849026198             0 0A001D00394B0300 0000000000000000 0000000000000000
5EFB8DF4          7         24     224062          7       1233      30403          5 ACTIVE           09/21/12 10:14:06    1850061851          0          2            7         1233        30403            5 5F440478    4201987 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0          0          1          1          8          0          1          0 9/21/2012 1          0          0 1850061851             0 070018003E6B0300 0000000000000000 0000000000000000

-- теперь две

SQL> rollback
  2  /

Rollback complete

SQL> insert into dist_test select * from dual@pip_test_link
  2  /

1 row inserted

SQL> select * from v$transaction@pip_test_link
  2  /

ADDR         XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS           START_TIME           START_SCNB START_SCNW START_UEXT START_UBAFIL START_UBABLK START_UBASQN START_UBAREC SES_ADDR       FLAG SPACE RECURSIVE NOUNDO PTX NAME                                                                             PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN PTX_XIDSLT PTX_XIDSQN     DSCN-B     DSCN-W  USED_UBLK  USED_UREC     LOG_IO     PHY_IO     CR_GET  CR_CHANGE START_DATE   DSCN_BASE  DSCN_WRAP  START_SCN DEPENDENT_SCN XID              PRV_XID          PTX_XID
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------- ------------ ------------ ------------ ------------ -------- ---------- ----- --------- ------ --- -------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ------------- ---------------- ---------------- ----------------
5EFA7D60         10         29     215865          7       8616      31338         37 ACTIVE           09/18/12 17:14:05    1849026198          0          2            7         8616        31338           36 5F4BB088       3587 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0          0          1          2         11          4         20          0 9/18/2012 5          0          0 1849026198             0 0A001D00394B0300 0000000000000000 0000000000000000

-- опять одна

SQL>
21 сен 12, 10:18    [13200128]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
Посмотри чем твой пример отличается от примера Льюиса, мне кажется что проблема в динамике. Попробуй оставить коммит только после первого фетча. Либо как вариант делай балк коллект в промежуточный массив с коммитами перед пайпом в цикле - так число коммитов будет поменьше.
21 сен 12, 12:27    [13201144]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
_Nikotin
Попробуй оставить коммит только после первого фетча.

оно поможет но чревато 01555

_Nikotin
Либо как вариант делай балк коллект в промежуточный массив с коммитами перед пайпом в цикле - так число коммитов будет поменьше.

так и буду наверное делать.. самое оптимальное, мне кажется
21 сен 12, 12:51    [13201351]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
_Nikotin
Посмотри чем твой пример отличается от примера Льюиса, мне кажется что проблема в динамике. Попробуй оставить коммит только после первого фетча. Либо как вариант делай балк коллект в промежуточный массив с коммитами перед пайпом в цикле - так число коммитов будет поменьше.
что-то я не понял ни первого, ни второго. с insert/*+ append */ же даже открыть курсор не получится.
21 сен 12, 13:17    [13201698]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
xtender
_Nikotin
Посмотри чем твой пример отличается от примера Льюиса, мне кажется что проблема в динамике. Попробуй оставить коммит только после первого фетча. Либо как вариант делай балк коллект в промежуточный массив с коммитами перед пайпом в цикле - так число коммитов будет поменьше.
что-то я не понял ни первого, ни второго. с insert/*+ append */ же даже открыть курсор не получится.

если автономка то получится. но нужен коммит до pipe
21 сен 12, 13:19    [13201725]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
bdsm_sql,

ааа, ясно... я то даже не рассматривал автономки
21 сен 12, 13:25    [13201831]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
Не жги больше
Guest
Пациент слишком резко меняет показания:
Алло, гараж
В 11g все, что меньше 2% buffer cache, и читается через FULL - в кеш вообще не попадает, а читается через direct path read
=>
сам кончай
This means any object (table) smaller than 2% of the buffer cache will be read via the buffer cache and not using direct path read. And tables larger than 2% of the buffer cache are read via direct path read and not via buffer cache.
=>
цитата потёртая модератором
http://afatkulin.blogspot.com/2012/07/serial-direct-path-reads-in-11gr2-and.html
observed for 11G:
Serial direct path reads start at _small_table_threshold*5.
Serial direct path reads stop when 50% of the table blocks are cached.
Serial direct path reads stop when 25% of the table blocks are dirty.
Что говорит о том, что сеанс интенсивной психтоерапии методом "натыкать в собственное г-но" дал плоды. Как минимум пациент за 3 месяца научился искать и читать.

Однако пациент продолжает бредить прокачкой гигабайтов блоков в SGA...
как ты заставишь холодно стартованный инстанс прокачать все нужные гигабайты блоков в SGA, не расслабляйся, у тебя все получится. Сделаешь через PL/SQL SELECT * FROM и пройдешь весь курсор, да?
Если adaptive serial direct reads решит, что таблица слишком большая для кеша, то будет читаться через direct.
Что никак не относится к истории болезни:
Алло, гараж
В 11g все, что меньше 2% buffer cache, и читается через FULL - в кеш вообще не попадает, а читается через direct path read
21 сен 12, 13:29    [13201896]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
Не жги больше
Guest
Это меня переклинило, ребята извините ;-)
21 сен 12, 13:30    [13201915]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
параллельная вселенная..
21 сен 12, 13:58    [13202208]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
сырбор
Guest
bdsm_sql
параллельная вселенная..

Это была параллельная вставка...
21 сен 12, 14:00    [13202235]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
С вашего позволения, продолжу тему... :)
bdsm_sql
PDML - так сказать условное название direct-path insert. может ввело тебя в заблуждение.
то что ты запретил pdml не запрещает direct-path insert.
не ввело в заблуждение, я, наоборот, показал, что direct path insert не pdml.

bdsm_sql
а вывод лично у меня такой. де-факто распределенная транзакция при select from @ не начинается, не смотря на локи DX. то есть двух-фазового коммита по окончании не происходит

bdsm_sql
а так же...
интересный, но неправильный вывод, особенно учитывая, что изначально проблема как раз из-за ругани на распределенную транзакцию при select from dblink :)
На самом деле, транзакция является распределенной независимо от наличия dml.
+ Пример
--- Выполняем на одной:
DB11G/XTENDER> select
  2     gt.FORMATID
  3    ,gt.BRANCHID
  4    ,gt.BRANCHES
  5    ,gt.REFCOUNT
  6    ,gt.PREPARECOUNT
  7    ,gt.STATE
  8    ,gt.FLAGS
  9    ,gt.COUPLING
 10  from v$global_transaction gt;

no rows selected

DB11G/XTENDER> save gt
Created file gt.sql

-- селектим с дблинка:
DB11G/XTENDER> select * from v$version@db11203;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

5 rows selected.
-- смотрим и видим, что распределенная открылась:
DB11G/XTENDER> @gt

  FORMATID BRANCHID             BRANCHES   REFCOUNT PREPARECOUNT STATE                                FLAGS COUPLING
---------- ------------------ ---------- ---------- ------------ -------------------------------------- ---------- ---------------
    306206 0000                        1          1            0 [ORACLE COORDINATED]ACTIVE             512 TIGHTLY COUPLED

1 row selected.
-- Вторая: смотрим и видим, что распределенная транзакция тоже видна:
ORCL/SYS> @gt

  FORMATID BRANCHID                                      BRANCHES   REFCOUNT PREPARECOUNT STATE                          FLAGS  COUPLING
---------- ------------------------------------------- ---------- ---------- ------------ ------------------------------ ------ ---------------
    306206 44423131475B31352E392E3136345D5B312E345D             1          1            0 [ORACLE COORDINATED]ACTIVE     512    TIGHTLY COUPLED

1 row selected.
-- коммитим в первой:
DB11G/XTENDER> commit;

Commit complete.
-- проверяем и видим, что распределенная исчезла:
DB11G/XTENDER> @gt

no rows selected
-- смотрим на удаленной и видим, что тоже закрылась:
ORCL/SYS> @gt

no rows selected

Но зато от наличия dml зависит не только появление в v$transaction, но и даже поведение коммита - в случае отсутствия dml на ремоуте при коммите будет на самом деле бесполезный роллбэк.
+ Пример из трассы с select * from dual@dblink
PARSING IN CURSOR #47179757228384 len=36 dep=0 uid=91 oct=3 lid=91 tim=1348272147450933 hv=1379735851 ad='82f2bf08' sqlid='1yjrk4593u69b'
SELECT "A1"."DUMMY" FROM "DUAL" "A1"
END OF STMT
PARSE #47179757228384:c=0,e=140,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=272002086,tim=1348272147450932
EXEC #47179757228384:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=272002086,tim=1348272147451057
WAIT #47179757228384: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1348272147451081
FETCH #47179757228384:c=0,e=156,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=1,plh=272002086,tim=1348272147451254
STAT #47179757228384 id=1 cnt=1 pid=0 pos=1 obj=116 op='TABLE ACCESS FULL DUAL (cr=2 pr=0 pw=0 time=125 us cost=2 size=2 card=1)'
WAIT #47179757228384: nam='SQL*Net message from client' ela= 618 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1348272147451939
FETCH #47179757228384:c=0,e=8,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=272002086,tim=1348272147452038
WAIT #47179757228384: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1348272147452070

*** 2012-09-22 04:02:33.246
WAIT #47179757228384: nam='SQL*Net message from client' ela= 5794497 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1348272153246686
CLOSE #47179757228384:c=0,e=15,dep=0,type=0,tim=1348272153247025
XCTEND rlbk=1, rd_only=1, tim=1348272153247259
WAIT #0: nam='SQL*Net message to client' ela= 7 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1348272153247812
22 сен 12, 04:06    [13205735]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Ровно такая же ситуация и у insert select from @dblink, как с append так и без него
22 сен 12, 04:11    [13205740]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
bdsm_sql,

собственно, как workaround надо в функции в автономке делать rollback, т.к. по факту там все равно rollback при коммите.
22 сен 12, 11:17    [13205950]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
xtender
bdsm_sql,

собственно, как workaround надо в функции в автономке делать rollback, т.к. по факту там все равно rollback при коммите.

Вопрос только в том почему у Льюиса все работает без автономок.
22 сен 12, 12:07    [13206042]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
_Nikotin
xtender
bdsm_sql,

собственно, как workaround надо в функции в автономке делать rollback, т.к. по факту там все равно rollback при коммите.

Вопрос только в том почему у Льюиса все работает без автономок.
у него же пример с автономкой, больше интересно почему она не выдает ошибки об отсутствии роллбэка или коммита. Имхо два варианта: либо в 11.1 можно не коммитить/роллбэкать в автономке если только нет dml вообще(игнорируя или анализируя состояние транзакции при обращении к дблинку, проверить не на чем - 11.1 нет под рукой), либотранзакция закрывается неявно при закрытии курсора
22 сен 12, 13:56    [13206286]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 10045
_Nikotin
Вопрос только в том почему у Льюиса все работает без автономок.


Льюис не учел линк на удаленку != линк на себя (loopback). Линк на себя оставляет нас с локальной транзакцией. Как только мы имеем удаленку транзакция становится распределенной:

SQL> connect scott@sol10
Enter password: *****
Connected.
SQL> create or replace
  2    function pipe_fun  
  3      return myArrayType  
  4      pipelined   
  5      as  
  6      begin  
  7        for r1 in (  
  8                   select  /*+ driving_site(t2) */  
  9                           t1.val  t1_val,  
 10                           t2.val  t2_val  
 11                     from  t1               t1,  
 12                           t2@sol10 t2  
 13                     where t2.id = t1.id  
 14                  ) loop  
 15          pipe row (myScalarType(r1.t1_val, r1.t2_val));  
 16        end loop;  
 17        return;  
 18  end;  
 19  / 

Function created.

SQL> alter table t3 nologging
  2  /

Table altered.

SQL> insert /*+ append */
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  

1000 rows created.

SQL> commit
  2  /

Commit complete.

SQL> alter table t3 logging
  2  /

Table altered.

SQL> connect scott@orcl
Enter password: *****
Connected.
SQL> drop table t2 purge;

Table dropped.

SQL> create table t2
  2    as  
  3      select  rownum              id,  
  4              lpad(rownum,15,'y') val  
  5        from  all_objects  
  6        where rownum <= 1000;  

Table created.

SQL> connect scott@sol10
Enter password: *****
Connected.
SQL> create or replace
  2    function pipe_fun  
  3      return myArrayType  
  4      pipelined   
  5      as  
  6      begin  
  7        for r1 in (  
  8                   select  /*+ driving_site(t2) */  
  9                           t1.val  t1_val,  
 10                           t2.val  t2_val  
 11                     from  t1               t1,  
 12                           t2@orcl t2  
 13                     where t2.id = t1.id  
 14                  ) loop  
 15          pipe row (myScalarType(r1.t1_val, r1.t2_val));  
 16        end loop;  
 17        return;  
 18  end;  
 19  / 

Function created.

SQL> alter table t3 nologging
  2  /

Table altered.

SQL> insert /*+ append */
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  
    from  table(pipe_fun)
                *
ERROR at line 4:
ORA-12840: cannot access a remote table after parallel/insert direct load txn
ORA-06512: at "SCOTT.PIPE_FUN", line 6


SQL> commit
  2  /

Commit complete.

SQL> alter table t3 logging
  2  /

Table altered.

SQL> alter table t3 nologging
  2  /

Table altered.

SQL> insert
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  

1000 rows created.

SQL> 


SY.
P.S. sol10 -10.2.0.4.0, orcl - 11.2.0.1.0

Сообщение было отредактировано: 22 сен 12, 15:05
22 сен 12, 14:12    [13206321]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
по-твоему это говорит о распределенной транзакции?
автор
ORA-12840: cannot access a remote table after parallel/insert direct load txn

но по факту да, верно - льюис этого не учел
22 сен 12, 21:46    [13207668]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
SY
Member

Откуда: Middlebury, CT USA
Сообщений: 10045
bdsm_sql
по-твоему это говорит о распределенной транзакции?


Тебе уже несколько раз и несколько человек сказали - распределенная транзакция это транзакция с одним или более удаленных или распределенных стейтментов. A распределенный стейтмент это стейтмент обращающийся к данным двух или более отличных узлов/экземпляров распределенной базы данных:

SQL> connect scott@sol10
Enter password: *****
Connected.
SQL> create or replace
  2    function pipe_fun  
  3      return myArrayType  
  4      pipelined   
  5      as  
  6      begin  
  7        for r1 in (  
  8                   select  /*+ driving_site(t2) */  
  9                           t1.val  t1_val,  
 10                           t2.val  t2_val  
 11                     from  t1               t1,  
 12                           t2@sol10         t2  
 13                     where t2.id = t1.id  
 14                  ) loop  
 15          pipe row (myScalarType(r1.t1_val, r1.t2_val));  
 16        end loop;  
 17        return;  
 18  end;  
 19  / 

Function created.

SQL> alter table t3 nologging
  2  /

Table altered.

SQL> insert /*+ append */
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  

1000 rows created.

SQL> select  FORMATID,
  2          BRANCHID,
  3          BRANCHES,
  4          REFCOUNT,
  5          PREPARECOUNT,
  6          STATE,
  7          FLAGS,
  8          COUPLING
  9    from  v$global_transaction;

no rows selected

SQL> create or replace
  2    function pipe_fun  
  3      return myArrayType  
  4      pipelined   
  5      as  
  6      begin  
  7        for r1 in (  
  8                   select  /*+ driving_site(t2) */  
  9                           t1.val  t1_val,  
 10                           t2.val  t2_val  
 11                     from  t1               t1,  
 12                           t2@orcl          t2
 13                     where t2.id = t1.id  
 14                  ) loop  
 15          pipe row (myScalarType(r1.t1_val, r1.t2_val));  
 16        end loop;  
 17        return;  
 18  end;  
 19  /

Function created.

SQL> insert /*+ append */
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  
    from  table(pipe_fun)
                *
ERROR at line 4:
ORA-12840: cannot access a remote table after parallel/insert direct load txn
ORA-06512: at "SCOTT.PIPE_FUN", line 6

SQL> insert
  2    into t3  
  3    select  *  
  4      from  table(pipe_fun)  
  5  /  

1000 rows created.

SQL> select  FORMATID,
  2          BRANCHID,
  3          BRANCHES,
  4          REFCOUNT,
  5          PREPARECOUNT,
  6          STATE,
  7          FLAGS,
  8          COUPLING
  9    from  v$global_transaction;

  FORMATID
----------
BRANCHID
--------------------------------------------------------------------------------------------------------------------------------
  BRANCHES   REFCOUNT PREPARECOUNT STATE                   FLAGS COUPLING
---------- ---------- ------------ ------------------ ---------- ---------------
    306206
0000
         1          1            0 ACTIVE                      0 TIGHTLY COUPLED


SY.

Сообщение было отредактировано: 22 сен 12, 22:20
22 сен 12, 22:17    [13207776]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
да не об этом речь!

я к тому что ограничение о том что "нельзя обращаться к remote table после direct-path insert" самодостаточно, ты его позиционируешь как доказательство того что началась распределенная транзакция. это неверно.
22 сен 12, 22:33    [13207829]     Ответить | Цитировать Сообщить модератору
 Re: проблемка - pipelined с remote внутри, direct-path insert  [new]
bdsm_sql
Member

Откуда:
Сообщений: 948
насчет же v$global_transaction - да, по ходу она все же есть

видимо разные ограничения для разных случаев - в частности когда все удаленные ноды отвечают в prepare phase "Read-only"
22 сен 12, 22:35    [13207836]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить