Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
*.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning and Data Mining options
ORACLE_HOME = /opt/oracle/product/10.2
System name: Linux
Node name: dbs2
Release: 2.6.5-7.244-smp
Version: #1 SMP Mon Dec 12 18:32:25 UTC 2005
Machine: x86_64

*** 2010-04-26 10:36:47.286
Start dump data blocks tsn: 4 file#: 30 minblk 230800 maxblk 230800
buffer tsn: 4 rdba: 0x07838590 (30/230800)
scn: 0x0000.1a53fd08 seq: 0x03 flg: 0x04 tail: 0xfd080603
frmt: 0x02 chkval: 0xec57 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000000600CA00 to 0x000000000600EA00
...
Block header dump: 0x07838590
Object id on Block? Y
seg/obj: 0x14a8c csc: 0x00.1a53fd08 itc: 169 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x7838589 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000d.029.0000738a 0x008005bd.20df.01 CB-- 0 scn 0x0000.1a4af84b
0x02 0x0006.021.000266ab 0x008002d2.c995.29 C--- 0 scn 0x0000.1a4af84c
0x03 0x0009.017.000323ed 0x00802573.f816.16 C--- 0 scn 0x0000.1a4af859
0x04 0x0003.025.00031c30 0x00801c34.f149.30 C--- 0 scn 0x0000.1a4af85b
0x05 0x0008.023.00031873 0x00800414.f899.14 C--- 0 scn 0x0000.1a4af861
0x06 0x000d.00e.00007394 0x008005bd.20df.12 C--- 0 scn 0x0000.1a4af868
0x07 0x0002.019.0002f768 0x008006f3.eddb.37 C--- 0 scn 0x0000.1a4af86a
0x08 0x0003.01d.00031c5f 0x00801c34.f149.3c C--- 0 scn 0x0000.1a4af872
0x09 0x0003.021.00031c2e 0x00801c34.f149.49 C--- 0 scn 0x0000.1a4af87d
0x0a 0x000c.016.0000a4bc 0x00800b6a.2da1.46 C--- 0 scn 0x0000.1a4af883
0x0b 0x000e.009.00005687 0x008027e1.17e1.16 C--- 0 scn 0x0000.1a4af887
0x0c 0x0008.00f.00031885 0x00800414.f899.1e C--- 0 scn 0x0000.1a4af895
0x0d 0x0001.000.000268ad 0x008001c3.c72e.41 C--- 0 scn 0x0000.1a4af898
0x0e 0x0002.006.0002f759 0x008006f3.eddb.47 C--- 0 scn 0x0000.1a4af89a
0x0f 0x000d.006.0000738c 0x008005bd.20df.16 C--- 0 scn 0x0000.1a4af8a8
0x10 0x0002.014.0002f77f 0x008006f4.eddb.01 C--- 0 scn 0x0000.1a4af8ac
0x11 0x000a.00f.00032f0b 0x00801eec.fa69.33 C--- 0 scn 0x0000.1a4af8b1
0x12 0x0003.01a.00031c57 0x00801c35.f149.12 C--- 0 scn 0x0000.1a4af8ba
0x13 0x0005.023.00032b12 0x00801f7d.f7cd.4a C--- 0 scn 0x0000.1a4af8bf
0x14 0x0009.01f.000323e7 0x00802573.f816.33 C--- 0 scn 0x0000.1a4af8c6
0x15 0x0005.027.00032b10 0x00801f7e.f7cd.08 C--- 0 scn 0x0000.1a4af8c8
0x16 0x000e.015.0000568c 0x008027e1.17e1.34 C--- 0 scn 0x0000.1a4af8d6
0x17 0x0001.02b.000268b0 0x008001c4.c72e.02 C--- 0 scn 0x0000.1a4af8d9
0x18 0x0009.00f.000323ed 0x00802573.f816.51 C--- 0 scn 0x0000.1a4af8e2
0x19 0x000b.000.0001cc54 0x00800582.8ec7.08 C--- 0 scn 0x0000.1a4af8e6
0x1a 0x0003.004.00031c68 0x00801c35.f149.27 C--- 0 scn 0x0000.1a4af8f1
0x1b 0x0005.004.00032b22 0x00801f7e.f7cd.15 C--- 0 scn 0x0000.1a4af8fb
0x1c 0x0006.02c.000263ec 0x008002d2.c995.48 C--- 0 scn 0x0000.1a4af904
0x1d 0x0003.003.00031c59 0x00801c35.f149.3d C--- 0 scn 0x0000.1a4af910
0x1e 0x000d.02a.0000738e 0x008005bf.20df.0a C--- 0 scn 0x0000.1a4af919
0x1f 0x0008.01c.0003186b 0x00800417.f899.26 C--- 0 scn 0x0000.1a4af91e
0x20 0x000c.01b.0000a4b7 0x00800b6b.2da1.19 C--- 0 scn 0x0000.1a4af924
...
0x21 0x0003.017.00031c45 0x00801c35.f149.4d C--- 0 scn 0x0000.1a4af92c
0x22 0x0002.027.0002f768 0x008006f4.eddb.25 C--- 0 scn 0x0000.1a4af931
0x23 0x0005.028.00032b1a 0x00801f80.f7cd.0f C--- 0 scn 0x0000.1a4af93c
0x24 0x0007.01c.0002fba9 0x00812b1a.ec92.19 C--- 0 scn 0x0000.1a4af93f
0x25 0x0006.011.0002668b 0x008002d3.c995.08 C--- 0 scn 0x0000.1a4af941
0x26 0x0009.013.000323df 0x00802574.f816.1c C--- 0 scn 0x0000.1a4af94f
0x27 0x0003.00a.00031c42 0x00801c36.f149.0e C--- 0 scn 0x0000.1a4af95a
0x28 0x0006.02a.00026687 0x008002d3.c995.12 C--- 0 scn 0x0000.1a4af962
0x29 0x000e.01f.00005686 0x008027e1.17e1.45 C--- 0 scn 0x0000.1a4af96f
0x2a 0x0002.010.0002f790 0x008006f4.eddb.31 C--- 0 scn 0x0000.1a4af971
0x2b 0x000d.00f.00007396 0x008005bf.20df.14 C--- 0 scn 0x0000.1a4af975
0x2c 0x0007.002.0002fb9f 0x00812b1a.ec92.26 C--- 0 scn 0x0000.1a4af97a
0x2d 0x000a.011.00032f05 0x00801eed.fa69.2a C--- 0 scn 0x0000.1a4af97e
0x2e 0x000b.02e.0001cc56 0x00800582.8ec7.20 C--- 0 scn 0x0000.1a4af983
0x2f 0x000a.02c.00032f11 0x00801eed.fa69.3c C-U- 0 scn 0x0000.1a53f1f4
0x30 0x000b.028.0001cc5c 0x00800582.8ec7.2d C--- 0 scn 0x0000.1a4af99c
0x31 0x0001.00b.000268a1 0x008001c4.c72e.42 C--- 0 scn 0x0000.1a4af9a1
0x32 0x000e.02d.0000568c 0x008027e2.17e1.0e C--- 0 scn 0x0000.1a4af9a8
0x33 0x0005.016.00032b24 0x00801f80.f7cd.1f C--- 0 scn 0x0000.1a4af9ac
0x34 0x0007.000.0002f783 0x00812b1a.ec92.46 C--- 0 scn 0x0000.1a4af9bf
0x35 0x0002.018.0002f773 0x008006f4.eddb.3b C--- 0 scn 0x0000.1a4af9c1
0x36 0x000b.018.0001cc1a 0x00800582.8ec7.44 C--- 0 scn 0x0000.1a4af9c6
0x37 0x000a.006.00032f3a 0x00801eee.fa69.0a C--- 0 scn 0x0000.1a4af9ce
0x38 0x000c.017.0000a4b4 0x00800b6c.2da1.13 C--- 0 scn 0x0000.1a4af9d2
0x39 0x0007.010.0002fbe0 0x00812b1b.ec92.01 C--- 0 scn 0x0000.1a4af9dc
0x3a 0x0005.018.00032b09 0x00801f80.f7cd.44 C--- 0 scn 0x0000.1a4af9e8
0x3b 0x0001.015.000268a2 0x008001c5.c72e.08 C--- 0 scn 0x0000.1a4af9fe
0x3c 0x0006.012.0002668f 0x008002d3.c995.2d C--- 0 scn 0x0000.1a4afa02
0x3d 0x0008.00e.00031866 0x00800418.f899.20 C--- 0 scn 0x0000.1a4afa09
0x3e 0x0005.001.00032b0d 0x00801f81.f7cd.01 C--- 0 scn 0x0000.1a4afa10
0x3f 0x0001.007.000268a4 0x008001c5.c72e.2b C--- 0 scn 0x0000.1a4afa1f
0x40 0x0009.003.0003240c 0x00802574.f816.4a C--- 0 scn 0x0000.1a4afa28
0x41 0x000b.025.0001cc52 0x00800583.8ec7.1c C--- 0 scn 0x0000.1a4afa2c
0x42 0x000e.023.00005689 0x008027e2.17e1.1c C--- 0 scn 0x0000.1a4afa31
0x43 0x000a.025.00032f45 0x00801eee.fa69.1a C--- 0 scn 0x0000.1a4afa3b
0x44 0x0004.01f.0003243d 0x0080014d.f82a.3a C--- 0 scn 0x0000.1a4afa43
0x45 0x0009.012.000323e4 0x00802575.f816.14 C--- 0 scn 0x0000.1a4afa4a
0x46 0x0005.024.00032b20 0x00801f81.f7cd.0e C--- 0 scn 0x0000.1a4afa4f
0x47 0x000e.016.0000568c 0x008027e2.17e1.2e C--- 0 scn 0x0000.1a4afa55
0x48 0x0009.01b.000323fe 0x00802575.f816.22 C--- 0 scn 0x0000.1a4afa64
0x49 0x000a.021.00032f23 0x00801eee.fa69.3d C--- 0 scn 0x0000.1a4afa69
0x4a 0x0005.01a.00032b09 0x00801f81.f7cd.1c C--- 0 scn 0x0000.1a4afa6e
0x4b 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x4c 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0xa8 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0xa9 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

Leaf block dump
===============
header address 100719116=0x600da0c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0xa0: opcode=0: iot flags=-C- is converted=Y
kdxconco 2
kdxcosdc 1
kdxconro 247
kdxcofbo 538=0x21a
kdxcofeo 1791=0x6ff
kdxcoavs 1253
kdxlespl 0
kdxlende 0
kdxlenxt 126059916=0x783858c
kdxleprv 126059975=0x78385c7
kdxledsz 0
kdxlebksz 4024
kdxlepnro 1
kdxlepnco 1
prefix row#0[4014] flag: -P----, lock: 0, len=10
col 0; len 7; (7): 78 6e 02 16 0e 17 01
prc 247
row#0[2439] flag: ------, lock: 0, len=9
col 0; len 6; (6): 07 83 86 b3 00 14
psno 0
row#1[2448] flag: ------, lock: 0, len=9
col 0; len 6; (6): 07 83 86 b3 00 15
psno 0
...
row#246[4005] flag: ------, lock: 0, len=9
col 0; len 6; (6): 07 83 86 f8 00 24
psno 0
----- end of leaf block dump -----
Такая картина наблюдается по многим индексам, которые работают только на вставку ключей (как правило, монотонно возрастающих) в коротких транзакциях (за раз вставляется, как правило, один ключ).
От длины и компрессии ключа не зависит.
Параллельно работает десяток сессий (в пиках десятка два).
Средняя интенсивность 5 транзакций в секунду.

Отчего может до максимума разрастаться ITL? Мне казалось, что Oracle более интеллектуально находит свободные слоты в ITL. Или у меня пробел в знаниях?

P.S. maxtrans дефолтный, но уже подумываю ...
26 апр 10, 17:15    [8691002]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Эталон Этанолович
Member

Откуда: Институт благородных девиц. Палата №6
Сообщений: 328
Elic
Или у меня пробел в знаниях?
Возможно. Расщепленный блок наследует число слотов от родителя


Elic
P.S. maxtrans дефолтный, но уже подумываю ...
Попробуй

P.S. Я видел и больше - что-то под 200 слотов
26 апр 10, 17:56    [8691304]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
Эталон Этанолович
Расщепленный блок наследует число слотов от родителя
Т.е. если когда-то случился "наплыв" одновременных транзакций, приведший разбуханию ITL, то мега-ITL будет тиражироваться из блока в блок?

И соответственно
Эталон Этанолович
Elic
P.S. maxtrans дефолтный, но уже подумываю ...
Попробуй
alter ... maxtrans не поможет?


И вообще, странно. Готов поклясться, что одновременных транзакций не могло быть 169.
26 апр 10, 18:13    [8691406]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
DВА
Member

Откуда:
Сообщений: 4327
Посмотри на Scn в ITL, явно они очень близко друг к другу идут, может как раз таки и "одновременно"
26 апр 10, 18:16    [8691428]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
DВА
Посмотри на Scn в ITL, явно они очень близко друг к другу идут, может как раз таки и "одновременно"
Допустим. Но в подавляющем большинстве слотов сплошные нули. Это в приведённом блоке использованных слотов много, а так максимум с десяток. Что эти нули значат?
26 апр 10, 18:37    [8691564]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 472
тынц
26 апр 10, 18:40    [8691595]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 472
Эталон Этанолович
Elic
P.S. maxtrans дефолтный, но уже подумываю ...
Попробуй

Если припрет, то можно и попробовать.
26 апр 10, 18:42    [8691609]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
DВА
Member

Откуда:
Сообщений: 4327
Значит либо используются в данный момент, либо не очищены.
26 апр 10, 18:55    [8691690]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
DВА
Member

Откуда:
Сообщений: 4327
DВА
Значит либо используются в данный момент, либо не очищены.

а, сори, вижу - я не про те нули :)
26 апр 10, 18:57    [8691699]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
Timur Akhmadeev
Если припрет, то можно и попробовать.
Спасибо за ссылки.
Лезть в словарь не припрёт. Похоже, буду с этим жить :(

Если я правильно понял Льюиса, то одним из альтернативных вариантов он предлагает рассмотреть coalesce. Но маленький тестик показал, что coalesce не "сжимает" ITL :|
27 апр 10, 12:04    [8694374]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Timur Akhmadeev
Member

Откуда:
Сообщений: 472
Elic
Но маленький тестик показал, что coalesce не "сжимает" ITL :|

Можно посмотреть на тест?
27 апр 10, 14:50    [8696097]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
Timur Akhmadeev
Elic
Но маленький тестик показал, что coalesce не "сжимает" ITL :|
Можно посмотреть на тест?
Мой тестик был слишком беглым. coalesce может сжимать ITL, но как-то странно.
Мне так и не удалось сжать ITL крайне "правого" (т.е. расщепляемого) блока:
create table tmp(id int constraint tmp$pk primary key);

declare
  procedure ins(n int)
  is
    pragma autonomous_transaction;
  begin
    insert into tmp(id) values (-n);
    if n > 0 then
      Ins(n - 1);
    end if;
    commit;
  end ins;
begin
  ins(100);
end;
/
insert into tmp(id) select level + (select max(id) from tmp) from dual connect by level <= 1000;
commit;
branch: 0x101285c 16853084 (0: nrow: 3, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 407 rrow: 407)
leaf: 0x101285d 16853085 (0: nrow: 400 rrow: 400)
leaf: 0x101285e 16853086 (1: nrow: 294 rrow: 294)

Block header dump: 0x0101285e
Object id on Block? Y
seg/obj: 0x1103d csc: 0x02.5c5994ec itc: 102 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x1012859 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x003b.011.00000002 0x008003d6.0001.01 CB-- 0 scn 0x0002.5c5994ec
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0x65 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x66 0x000a.02f.00003dfd 0x00801303.1d3a.07 --U- 294 fsc 0x0000.5c5994ed
alter index tmp$pk coalesce;
branch: 0x101285c 16853084 (0: nrow: 3, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 407 rrow: 407)
leaf: 0x101285d 16853085 (0: nrow: 400 rrow: 400)
leaf: 0x101285e 16853086 (1: nrow: 294 rrow: 294)

ITL без изменений.
insert into tmp(id) select level + (select max(id) from tmp) from dual connect by level <= 1000;
commit;
branch: 0x101285c 16853084 (0: nrow: 6, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 407 rrow: 407)
leaf: 0x101285d 16853085 (0: nrow: 400 rrow: 400)
leaf: 0x101285e 16853086 (1: nrow: 400 rrow: 400)
leaf: 0x101285f 16853087 (2: nrow: 400 rrow: 400)
leaf: 0x1012868 16853096 (3: nrow: 400 rrow: 400)
leaf: 0x1012861 16853089 (4: nrow: 94 rrow: 94)

Block header dump: 0x0101285e
Object id on Block? Y
seg/obj: 0x1103d csc: 0x02.5c599510 itc: 102 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x1012859 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0020.015.00000002 0x0080088b.0003.01 -BU- 1 fsc 0x0000.5c599918
0x02 0x000f.007.00000007 0x008000d4.000b.1c --U- 106 fsc 0x0000.5c599925
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0x66 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

Block header dump: 0x01012861 (забыл сдампить, но дальше видно что itc=102)
alter index tmp$pk coalesce;
branch: 0x101285c 16853084 (0: nrow: 5, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 520 rrow: 520)
leaf: 0x101285d 16853085 (0: nrow: 513 rrow: 513)
leaf: 0x101285e 16853086 (1: nrow: 513 rrow: 513)
leaf: 0x1012868 16853096 (2: nrow: 461 rrow: 461)
leaf: 0x1012861 16853089 (3: nrow: 94 rrow: 94)

В 4-ёх левых блоках ITL сжалась, а в крайнем правом - нет:

Block header dump: 0x01012861
Object id on Block? Y
seg/obj: 0x1103d csc: 0x02.5c5999bb itc: 102 flg: E typ: 2 - INDEX
brn: 1 bdba: 0x1012859 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0028.014.00000002 0x00800495.0001.01 CB-- 0 scn 0x0002.5c599924
0x02 0x000f.007.00000007 0x008000d5.000b.06 C--- 0 scn 0x0002.5c599925
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0x66 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
insert into tmp(id) select level + (select max(id) from tmp) from dual connect by level <= 1000;
commit;
branch: 0x101285c 16853084 (0: nrow: 7, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 520 rrow: 520)
leaf: 0x101285d 16853085 (0: nrow: 513 rrow: 513)
leaf: 0x101285e 16853086 (1: nrow: 513 rrow: 513)
leaf: 0x1012868 16853096 (2: nrow: 461 rrow: 461)
leaf: 0x1012861 16853089 (3: nrow: 400 rrow: 400)
leaf: 0x1012864 16853092 (4: nrow: 400 rrow: 400)
leaf: 0x1012865 16853093 (5: nrow: 294 rrow: 294)

У 3-ёх правых клонированно itc=102:

Block header dump: 0x01012865
Object id on Block? Y
seg/obj: 0x1103d csc: 0x02.5c599cb4 itc: 102 flg: E typ: 2 - INDEX
brn: 1 bdba: 0x1012859 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0013.023.00000002 0x00800091.0001.01 CB-- 0 scn 0x0002.5c599cb4
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x003e.01a.00000002 0x008003ff.0000.08 --U- 294 fsc 0x0000.5c599cf9
0x04 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0x66 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
alter index tmp$pk coalesce;
branch: 0x101285c 16853084 (0: nrow: 7, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 520 rrow: 520)
leaf: 0x101285d 16853085 (0: nrow: 513 rrow: 513)
leaf: 0x101285e 16853086 (1: nrow: 513 rrow: 513)
leaf: 0x1012868 16853096 (2: nrow: 461 rrow: 461)
leaf: 0x1012861 16853089 (3: nrow: 400 rrow: 400)
leaf: 0x1012864 16853092 (4: nrow: 400 rrow: 400)
leaf: 0x1012865 16853093 (5: nrow: 294 rrow: 294)

У 3-ёх правых ITL не сжалась
insert into tmp(id) select level + (select max(id) from tmp) from dual connect by level <= 1000;
commit;
branch: 0x101285c 16853084 (0: nrow: 10, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 520 rrow: 520)
leaf: 0x101285d 16853085 (0: nrow: 513 rrow: 513)
leaf: 0x101285e 16853086 (1: nrow: 513 rrow: 513)
leaf: 0x1012868 16853096 (2: nrow: 461 rrow: 461)
leaf: 0x1012861 16853089 (3: nrow: 400 rrow: 400)
leaf: 0x1012864 16853092 (4: nrow: 400 rrow: 400)
leaf: 0x1012865 16853093 (5: nrow: 400 rrow: 400)
leaf: 0x1012866 16853094 (6: nrow: 400 rrow: 400)
leaf: 0x1012867 16853095 (7: nrow: 400 rrow: 400)
leaf: 0x101285f 16853087 (8: nrow: 94 rrow: 94)

Склонировалось itc=102
alter index tmp$pk coalesce;
branch: 0x101285c 16853084 (0: nrow: 9, level: 1)
leaf: 0x1012860 16853088 (-1: nrow: 520 rrow: 520)
leaf: 0x101285d 16853085 (0: nrow: 513 rrow: 513)
leaf: 0x101285e 16853086 (1: nrow: 513 rrow: 513)
leaf: 0x1012868 16853096 (2: nrow: 461 rrow: 461)
leaf: 0x1012861 16853089 (3: nrow: 513 rrow: 513)
leaf: 0x1012864 16853092 (4: nrow: 513 rrow: 513)
leaf: 0x1012865 16853093 (5: nrow: 513 rrow: 513)
leaf: 0x1012867 16853095 (6: nrow: 461 rrow: 461)
leaf: 0x101285f 16853087 (7: nrow: 94 rrow: 94)

ITL сжалась у всех, кроме крайнего правого:

Block header dump: 0x0101285f
Object id on Block? Y
seg/obj: 0x1103d csc: 0x02.5c59a07b itc: 102 flg: E typ: 2 - INDEX
brn: 0 bdba: 0x1012859 ver: 0x01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x003b.01f.00000002 0x008003cf.0002.01 CB-- 0 scn 0x0002.5c59a05c
0x02 0x003b.01c.00000002 0x008003cd.0002.06 C--- 0 scn 0x0002.5c59a05e
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
...
0x66 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

И опять будет клонироваться ?! :(

Какая-то игра в салочки. Я - проигрываю.
Может оно когда-нибудь и сойдётся...
Поведение не-100%-но воспроизводимое. В разных запусках теста какие-то вариации. Мне показалось, что даже вначале у меня сошлось.
27 апр 10, 17:30    [8697514]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Elic
Member

Откуда: 1984. Следующие на оккупацию финно-угром
Сообщений: 23694
Тест проводился на

ORACLE V10.2.0.4.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.0 Service Pack 2
CPU : 2 - type 586, 2 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:1021M/3060M, Ph+PgF:2904M/6363M, VA:1550M/2047M
27 апр 10, 17:43    [8697651]     Ответить | Цитировать Сообщить модератору
 Re: ITL листьевого блока индекса - в пол блока  [new]
Wireless
Member

Откуда: 660030 -> 80303
Сообщений: 552
Elic
DВА
Посмотри на Scn в ITL, явно они очень близко друг к другу идут, может как раз таки и "одновременно"
Допустим. Но в подавляющем большинстве слотов сплошные нули. Это в приведённом блоке использованных слотов много, а так максимум с десяток. Что эти нули значат?

http://sql.ru/forum/actualthread.aspx?bid=3&tid=399125

http://sql.ru/forum/actualthread.aspx?bid=3&tid=399125&pg=2#3996928 :
Vertigo
Такой слот получается в процессе мигрирования строки в этот блок

правда, там блок таблицы, а не индекса...
27 апр 10, 23:20    [8699229]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить