есть ли необходимость и возможность почистить ITL-таблицу?

Wireless
Дата: 21.02.2007 08:14:06
Сделал дамп блока, который последний раз изменялся около недели назад.
Оказалось, что в нем 37 слотов транзакций, т.е. в блоке ими занято почти 900 байт.

blockdump
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000c.010.00005f0b 0x00802eb8.160e.3a C--- 0 scn 0x0000.2b23c688
0x02 0x000c.019.00005f09 0x00802eba.160e.03 C--- 0 scn 0x0000.2b23c7e2
0x03 0x0018.014.000004a0 0x00802d99.015c.1c C--- 0 scn 0x0000.2b23c905
...
0x1c 0x0011.027.00001c99 0x00803065.08f6.10 C--- 0 scn 0x0000.2b39c9f1
0x1d 0x0013.01b.00000acc 0x0080251a.02a4.02 C--- 0 scn 0x0000.2b23c54b
0x1e 0x000c.02c.0000600a 0x00810516.163d.3c --U- 8 fsc 0x0000.2b39d360
0x1f 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x20 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x21 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x22 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x23 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x24 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000
0x25 0x0000.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.00000000


Понимает ли Оракл, что эти транзакции уже неактивные, и учитывает
ли это место как свободное? Если нет, то как принудительно в блоках
можно инициировать уменьшение ITL-таблицы в заголовках блока?
Dimka9
Дата: 21.02.2007 08:15:50
select?
Vertigo
Дата: 21.02.2007 08:35:59
Зачем уменьшать? Если они выделились, значит это было нужно, и вероятно, будет нужно еще раз, даже если уменьшишь.
Нсколько я знаю, уменьшить только созданием другого сегмента

пс. ну или там hexedit`ы всякие :)
Wireless
Дата: 21.02.2007 08:50:04
Dimka9
select?

это та самая отложенная очистка, при которой select undo генерит? :)
Wireless
Дата: 21.02.2007 08:51:52
Vertigo
Зачем уменьшать? Если они выделились, значит это было нужно, и вероятно, будет нужно еще раз, даже если уменьшишь.
Нсколько я знаю, уменьшить только созданием другого сегмента

нет, как раз особенность этой таблицы, что периодически возникает высококонкурентое обновление некоторых "горячих" блоков... потом эти блоки становятся mostly read-only....
Dimka9
Дата: 21.02.2007 08:57:36
Wireless
это та самая отложенная очистка, при которой select undo генерит? :)

типа того

я тут еще раз вопрос перечитал и кажется что уменьшить скорее всего никак, а первый раз я про очистить писал.
Wireless
Дата: 21.02.2007 08:58:37
в недавнем топике http://www.sql.ru/forum/actualthread.aspx?tid=398609 показано, что иногда itl на этой таблице разрастается на столько, что в блоке уже для нее нет места и... возникает deadlock.
Elic
Дата: 21.02.2007 09:13:43
Wireless
в недавнем топике http://www.sql.ru/forum/actualthread.aspx?tid=398609 показано, что иногда itl на этой таблице разрастается на столько, что в блоке уже для нее нет места и... возникает deadlock.
Во-первых, возникает просто блокировка.
Во-вторых, место в ITL занимают только активные транзакции.
Чему равен initrans?
Part
Дата: 21.02.2007 09:20:58
Wireless
Dimka9
select?

это та самая отложенная очистка, при которой select undo генерит? :)


генерируется REDO, а не UNDO
SQL> drop table t;

Table dropped.

SQL> create table t(x int, pad char(100)) pctfree 90 pctused 10;

Table created.

SQL> insert into t(x) select level from dual connect by level <= 1000000;

1000000 rows created.

SQL> commit;

Commit complete.

SQL> update t set x = x + 1;

1000000 rows updated.

SQL> commit;

Commit complete.

SQL> set autotrace traceonly
SQL> select * from t;

1000000 rows selected.


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'T'




Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      93903  consistent gets
       9498  physical reads
     845100  redo size
   18046861  bytes sent via SQL*Net to client
     733825  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed

SQL> select * from t;

1000000 rows selected.


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'T'




Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      79818  consistent gets
       8820  physical reads
          0  redo size
   18046861  bytes sent via SQL*Net to client
     733825  bytes received via SQL*Net from client
      66668  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
    1000000  rows processed
Wireless
Дата: 21.02.2007 10:17:54
Elic
Во-первых, возникает просто блокировка.

В шапке trace-a DEADLOCK DETECTED.
Понятно, что обычно просто блокировка, но иногда приводит к deadlockу.
Например, сценарий может быть следующий. Две транзакции - A и B обновляют два блока - 1 и 2:

A обновляет 1, выдяеляется успешно новый ITL, больше места в 1 нет ни под один ITL.
B обновляет 2, выдяеляется успешно новый ITL, больше места в 2 нет ни под один ITL.
A пытается обновить 2, места под слот нет, сессия ждет текущие активные транзакции (B).
B пытается обновить 1, места под слот нет, сессия ждет текущие активные транзакции (A).
упс, deadlock detected.

Elic
Во-вторых, место в ITL занимают только активные транзакции.

как я написал в первом посте, блок не изменялся около недели, транзакции давно не активные :)

Elic
Чему равен initrans?

initrans 1 maxtrans 255