Уровни изоляции в Юконе

Forum rules
Alex Shtern
Posts: 9
Joined: 14 Oct 2004 19:24
Location: CA

Post by Alex Shtern »

Очень интересный topic, пожалуй один из самых интересных на етом форуме ...

Из того что здесь написано, выглядит что Yukon SI больше напоминает
Interbase/FireBird row versioning - только у них old row versions
хранятса прямо в data blocks и вообше нет Redo Log -
hot backup делают через row versioning :-)

Правда соответственно у них нет и point-in-time recovery.

Вообше то, хоть ето и не тема топика но у меня есть
один коментарий к тому что сказал tengiz об Oracle.

Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука
как ITL interested transactions list и там записаны
ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans)
транзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL -
так что Oracle всегда знает какие rows in data page has been modified.
Top
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

Post by tengiz »

Alex Shtern wrote:Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука как ITL interested transactions list и там записаны ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans) ранзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL - так что Oracle всегда знает какие rows in data page has been modified.

Alex, когдя я написал, что в Oracle "строки не имеют метки последней транзакции, метку транзакции имеет сама страница, также есть внутристраничный кеш с некоторой информацией о последних транзакциях (глубина этой мини-истории - настраиваемый параметр)" именно ITL я и имел в виду. Однако ввиду ограниченной глубины этой истории при интенсивном обновлении страницы "Oracle не всегда может точно определить есть ли нужная версия строки на текущей странице" по причине того, что для читающей транзакции одинаково важно иметь информацию как об активных тразнакциях, модифицирующих страницу (информация о всех из них действительно имеется в ITL - , кстати, это одно из узких мест Oracle - жёсткое ограничение на количество активных транзакций модифицирующих конкретную страницу), так и о зафиксированных до того, как читающая транзакция началась (а вот этого уже никто не гарантирует).
Cheers
Top
Alex Shtern
Posts: 9
Joined: 14 Oct 2004 19:24
Location: CA

Post by Alex Shtern »

Ok tengiz,

Ето все ето чистая правда с точки зрения теории баз данных.

к тому же с удовольствием прочитал те главы из
CONCURRENCY CONTROL AND RECOVERY IN DATABASE SYSTEMS
которые ты где то советовал ...

Да, в Oracle, только до 255 трансакзий могут одновремено
модифицировать страницы в 8-32кб. страницы в 2 и 4 кб редко
кто использует ..

Ну скажем на практике, 2 года назад я учацтвовал в benchmark в
Sun Labs (Oregon) на Sun Fire 15K
with 106 CPUs и видел, как то раз, 16 активных трансакзий на block.

Ну и к тому же в Oracle 10g добавилась такая вещь как
guaranteed undo retention которая решит большую часть реально
связанных с етим проблем, пусть и за счет болшего количества
disk space, чем ето сделано в Yukon.
Top
vc
Уже с Приветом
Posts: 664
Joined: 05 Jun 2002 01:11

Post by vc »

Alex Shtern wrote:....

Правда что строки не имеют метки последней транзакции, метку транзакции имеет сама страница, но в странице на самом деле есть такая штука
как ITL interested transactions list и там записаны
ВСЕ uncommited (и может быть кое какие commited - ето зависит от initrans)
транзакции, которые модифицируют данные на етой странице а каждая модифицированная row has byte with transaction slot number in the ITL -
так что Oracle всегда знает какие rows in data page has been modified.


This is incorrect. Oracle timestamps the entire block, not individual rows so the block has to be reconstructed as a whole. ITLs do not contain information about all the rows, they contain information about transactions modifying the block. Besides, there are fewer ITLs (usually) in the block than there are rows.

VC
Top
Alex Shtern
Posts: 9
Joined: 14 Oct 2004 19:24
Location: CA

Post by Alex Shtern »

VC,

ITLs do not contain information about all the rows but each row header for
locked row contains byte - this byte is a number of Interester Transaction Slot
in the ITL . :lol:

И если бы ты прочитал прошлое сообшение, то увидел бы
что именно ето там и написано :umnik1:
Top
User avatar
tengiz
Уже с Приветом
Posts: 4468
Joined: 21 Sep 2000 09:01
Location: Sammamish, WA

Post by tengiz »

Alex Shtern wrote:ITLs do not contain information about all the rows but each row header for locked row contains byte - this byte is a number of Interester Transaction Slot in the ITL.

Alex - Вы придираетесь не по делу. VC имел в виду другое: как только ITL слот переиспользуется новой транзакцией, во всех строках блока, указывающих на этот слот, байт-индекс ITL слота последней блокировавшей эти строки транзакции безжалостно обнуляется и информация о том, кто трогал эти строки (и трогал ли вообще) безвозвратно теряется. Поэтому в таких случаях Oracle вынужден делать реконструкцию блока даже если нужная версия строки реально находится в текущем блоке.
Cheers
Top
vc
Уже с Приветом
Posts: 664
Joined: 05 Jun 2002 01:11

Post by vc »

Alex Shtern wrote:VC,

ITLs do not contain information about all the rows but each row header for
locked row contains byte - this byte is a number of Interester Transaction Slot
in the ITL . :lol:

И если бы ты прочитал прошлое сообшение, то увидел бы
что именно ето там и написано :umnik1:


A little knowledge is a dangerous thing...

Code: Select all

create table t1 (x varchar2(10)); -- table with two ITL slots (the default)


-- Row one
insert into t1 values('ROW ONE');
commit;

-- Block dump:

scn: 0x0000.207b8fd2 seq: 0x01 flg: 0x02 tail: 0x8fd20601
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0001.018.0001d45f  0x0080000a.0ce5.0e  --U-    1  fsc 0x0000.207b8fd2
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000

block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45

-- the transaction took slot 1 and the row lock byte points at slot 1: lb = 0x1
--

-- Insert row  two
insert into t1 values('ROW TWO');
commit;

scn: 0x0000.207b9076 seq: 0x01 flg: 0x02 tail: 0x90760601
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0001.018.0001d45f  0x0080000a.0ce5.0e  --U-    1  fsc 0x0000.207b8fd2
0x02   0x000a.022.00018db4  0x0080009e.0b4a.13  --U-    1  fsc 0x0000.207b9076
 
block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45
tab 0, row 1, @0x1f82
tl: 11 fb: --H-FL-- lb: 0x2  cc: 1
col  0: [ 7]  52 4f 57 20 54 57 4f


-- the new transaction took slot 2 and the row lock byte points at slot 2: lb = 0x2
--

-- Insert row three
insert into t1 values('ROW THREE');
commit;

scn: 0x0000.207b90cf seq: 0x01 flg: 0x02 tail: 0x90cf0601

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0004.00c.0001baf5  0x00800235.0a54.4c  --U-    1  fsc 0x0000.207b90cf
0x02   0x000a.022.00018db4  0x0080009e.0b4a.13  C---    0  scn 0x0000.207b9076
 
block_row_dump:
tab 0, row 0, @0x1f8d
tl: 11 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 7]  52 4f 57 20 4f 4e 45
tab 0, row 1, @0x1f82
tl: 11 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [ 7]  52 4f 57 20 54 57 4f
tab 0, row 2, @0x1f75
tl: 13 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [ 9]  52 4f 57 20 54 48 52 45 45

-- the new transaction over-wrote slot 1 and the row 3 lock byte points at slot 1: lb = 0x1
-- the lock bytes for rows 1 and 2 were zeroed.
Top

Return to “Вопросы и новости IT”