Oracle serializable isolation

Ha valóban csak egyetlen tranzakciód / session-öd fut, akkor nincs is szükséged a serializable isolation-re; még a READ UNCOMMITTED-et is használhatod, pontosan ugyanaz kell legyen az eredménye. (A saját módosításaidat mindig látod, párhuzamos tranzakció meg nincs.)

Szerintem nem véletlen, hogy a pgsql program a serializable isolation-t választotta; bizonyára van konkurencia. Lehet, hogy a pgsql-nek más a "session ütemezője" vagy mittomén, és ott ezért nincsenek ilyen hibák.

Aha, így teljesen érthető már, köszönöm az infót!

Még egy kerülő út: van egy másik megoldás, a createtemporary(blob_var, true) -> write(blob_variable, ..., clob|raw), ami talán használható lenne update helyett.
[blob_variable : lehet table.col(blob) ami rowtype eleme]

megj.:
Úgy hallottam, hogy ezt a dbms_lob pck-t átfaragják a következő verzióban.

innen

If a cursor is open, and the current SQL-transaction makes a change
  to SQL-data other than through that cursor, and the <declare cur-
  sor> for that cursor specified INSENSITIVE, then the effect of
  that change will not be visible through that cursor before it is
  closed.

Ez elegendő?

Kipróbáltam tárolt eljárásban, nálam nem volt hiba.

create table TST_BLOB
(
  ID   NUMBER not null,
  MIEZ BLOB
)
tablespace valami_data
  pctfree 10
  initrans 1
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );

create or replace package seri_blob is

  FUNCTION F_GENEREAL( P_HOWMANY NUMBER )
   RETURN NUMBER;
   
end seri_blob;
/
create or replace package body seri_blob is
 
  FUNCTION F_BEIR( P_TST_BLOB IN OUT NOCOPY TST_BLOB%ROWTYPE )
   RETURN NUMBER 
   IS
   BEGIN
     INSERT INTO TST_BLOB VALUES P_TST_BLOB;
     RETURN 0;
  END F_BEIR;
  
  --====================================================
  
  FUNCTION F_BLOB_PREPARE( P_SIZE NUMBER,
                           P_RESULT IN OUT NOCOPY TST_BLOB%ROWTYPE )
   RETURN NUMBER
   IS
     LRAW_X        RAW(8000);
     LN_ASC        NUMBER;
     I             NUMBER DEFAULT 1;
     L_ST          VARCHAR2(8000);
     LS_OUT        VARCHAR2(10) DEFAULT 'EZKERULBE';
     L_SZOVEG      VARCHAR2(8000);
   BEGIN
     WHILE I <= FLOOR(P_SIZE / LENGTH(LS_OUT)) LOOP
       L_ST := L_ST || LS_OUT ;
       I := I +1;
     END LOOP;
     LRAW_X := UTL_RAW.CAST_TO_RAW(L_ST);
     LN_ASC := LENGTH(L_ST);
     DBMS_LOB.CREATETEMPORARY(P_RESULT.MIEZ, TRUE);
     DBMS_LOB.WRITE(P_RESULT.MIEZ, LN_ASC, 1, LRAW_X);
     RETURN 0;
  END F_BLOB_PREPARE;
  
  --====================================================
  
  FUNCTION F_GENEREAL( P_HOWMANY NUMBER )
   RETURN NUMBER
   IS 
     L_ERROR_DB   NUMBER DEFAULT 0;
     L_TST_BLOB   TST_BLOB%ROWTYPE;
     L_DB         NUMBER DEFAULT 1;
     L_VAN        NUMBER;
     L_RET        NUMBER;
     SERIAL_HIBA  EXCEPTION;
     PRAGMA EXCEPTION_INIT(SERIAL_HIBA, -8177 );

   BEGIN
     COMMIT;
     SET TRANSACTION ISOLATION LEVEL SERIALIZABLE NAME 'LEAKADE'; 
     
     L_RET := F_BLOB_PREPARE( P_SIZE => 1000,
                              P_RESULT => L_TST_BLOB );
     WHILE L_DB <= P_HOWMANY LOOP
        BEGIN
          L_TST_BLOB.ID := L_DB;
          L_RET := F_BEIR( P_TST_BLOB => L_TST_BLOB );
          SELECT 1 INTO L_VAN
            FROM TST_BLOB
            WHERE ID = L_DB
          ;
        EXCEPTION WHEN SERIAL_HIBA THEN
          L_ERROR_DB := L_ERROR_DB +1;
          DBMS_OUTPUT.PUT_LINE(L_DB || ' ' ||SQLERRM);
          WHEN OTHERS THEN 
           DBMS_OUTPUT.PUT_LINE(L_DB || ' EGYEB ' ||SQLERRM);
        END;        
        L_DB := L_DB + 1;
     END LOOP;                              
     DBMS_LOB.FREETEMPORARY(L_TST_BLOB.MIEZ);
                              
     RETURN L_ERROR_DB;
  END F_GENEREAL;

  --====================================================  
  
end seri_blob;
/

így teszteltem:

DECLARE
  L_RET NUMBER;
BEGIN
  L_RET := seri_blob.f_genereal(p_howmany => 100 );
END;

adtam neki 10000-et is, akkor sem láttam hibát.

Ezzel kéne megpróbálni. Ha megy a reprodukálás, akkor szerintem simán bejelenthető a supporton. Persze előtte ki kéne próbálni megemelt initrans-szal is.

Mellesleg nekem 10.2.0.3-n 32KB-s blokkmérettel nem jelentkezik a probléma még 10000 rekordnál se.


drop table p2;
drop table proba;


create table proba( kulcs varchar(24) not null primary key,
megjegyzes varchar(128) );
create table p2 ( kulcs varchar(24) not null
references proba(kulcs), megjegyzes2 varchar(128) );
create index p2_kulcs on p2 (kulcs);

alter session set isolation_level=SERIALIZABLE;

insert into proba (kulcs,megjegyzes) values ('abcdefghijkl/00000001', 'abcdefghijkl/00000001');
insert into p2 (kulcs, megjegyzes2) values ('abcdefghijkl/00000001', 'abcdefghijkl/xx');
commit;
insert into proba (kulcs,megjegyzes) values ('abcdefghijkl/00000002', 'abcdefghijkl/00000002');
insert into p2 (kulcs, megjegyzes2) values ('abcdefghijkl/00000002', 'abcdefghijkl/xx');
commit;

Csak úgy vaktában, megújult érdeklődéssel: a végrehajtási terv mind a 286 esetben azonos?

Oracle 10g XE 32bit, Win7 32bit "szerver", default minden beállítás, előjött ugyanez.
Több insertnél, a 288.-nál is előjött.
Csináltam egy olyan változatot, aminek egy commit van a legvégén, ott a 286.-tól nem tud commitolni.

Ha átírom az egészet úgy, hogy begin-end blokkban legyen, és alter session helyett a set transaction isolation level SERIALIZABLE; paranccsal állítok, akkor:

Egy commit a végén verzió:
https://gist.github.com/880583/8f3a1cc3cd29b6cdfbdd529ab3220021216b72e9
Eredmény: 286. sortól elromlik

Minden UPDATE után külön commit:
https://gist.github.com/880583/da0d5c0dea221009d792fdf665ce100b81ca98e0
Eredmény: mind jó. Nem jó. Mert ugye mind külön tranzakció.

Itt az a verzió, ami ugyanúgy működik, mint a tied, de begin-end-es:
https://gist.github.com/880583/b08b80c563c52675dd4f3ac9f9e9dce3b664624b
Ez elszáll
ORA-08177: can't serialize access for this transaction
ORA-06512: at line 866
kivétellel.

ROWDEPENDENCIES használata elvileg (gyakorlatilag nem ritkult nálam) ritkítja az ilyen eseteket:

create table proba( kulcs varchar(24) not null, megjegyzes varchar(128) ) initrans 10 rowdependencies pctfree 5;

http://stackoverflow.com/questions/2326750/randomly-getting-ora-08177-w… illetve http://deniskrjuchkov.blogspot.com/2010/02/oracle-challenge.html itt is ezzel küzdöttek. (megoldás itt sincs)