powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
25 сообщений из 33, страница 1 из 2
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500020
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

Сабж.

разглядывая картинки в "Episode 2 - Page Types ", так и не въехал, по каким признакам коннект должен смекнуть, что страница с данными устарела и её надо бы перечитать с диска.
Контрольной суммы там нету. Момента времени - тоже.

И второй вопрос (оффтоп, но отдельную тему по нему нет смысла создавать).
Из рисунка (см аттач, скопировал его сюда) и объяснений к нему:Ann
As more data is stored on the page, the index grows downward.

The data - records, blobs, and fragments - start at the end of the page and go upward.- следует, что если на страницу размером 4096 байт были записаны 80 раз строки длиной по 50 байт (к примеру, двадцатью отдельными транзакциями), то более "поздние" строки лягут ближе к началу страницы - это так или нет ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500061
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS.
Заметил еще вот что.
Если
1) коннект_1 сделал вычитку данных (напр., select * from t where id between 7894561 and 7894570;),
2) коннект_2 изменил страницы хранения этих данных, но НЕ завершил транзакцию,
- то повторная вычитка коннектом_1 этих же строк приводит всегда к reads > 0, т.е. он таки лезет на диск за этой страницей (хотя коннект_2 не выполнил еще ни commit ни rollback).

Выполнение коннектом_2 отмены транзакции также приведет к тому, что коннект_1 при перечитывании этих строк полезет на диск (reads опять >0).
Это работает как при snapshot, так и при read committed record_version.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500072
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
через лок-менеджер. Если коннект владеет блокировкой, то страница в его кеше валидна. Если потерял блокировку, то ее надо перечитать.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500074
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Таблоид]более "поздние" строки лягут ближе к началу страницы - это так или нет ?/quot]
все верно, насколько я помню
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500075
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

ну так 2 коннект вытесняет данные из кеша. Ты же не думаешь, что данные попадают в кеш по коммиту?

Таблоидпо каким признакам коннект должен смекнуть, что страница с данными устарела и её надо бы перечитать с диска.

Когда он не находит её в кеше перечитывает с диска.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500077
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис
Когда он не находит её в кеше перечитывает с диска.

Тут ступил, ответил не на то.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500082
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидповторная вычитка коннектом_1 этих же строк приводит всегда к reads > 0, т.е. он таки лезет на диск за этой страницей (хотя коннект_2 не выполнил еще ни commit ни rollback)
работа с кешем практически не пересекается с транзакционным механизмом, они на разных уровнях находятся
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500138
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrчерез лок-менеджер. Если коннект владеет блокировкой, то страница в его кеше валидна. Если потерял блокировку, то ее надо перечитать.Хорошо, вот сценарий:
0. DDL:
Код: sql
1.
2.
3.
4.
5.
6.
7.
create table t(id int, s varchar(36));
create sequence g; 
commit;
insert into t select gen_id(g,1), uuid_to_char(gen_uuid()) from rdb$types,rdb$types,rdb$types rows 10000000;
commit;
create index t_id on t(id);
commit;



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
 step 1. Коннект-1: 
SQL> out nul;
 -- предварит. вычитка в память страницы, её статистика нам не нужна:
SQL> select * from t where id between 7894561 and 7894570;
SQL> set stat on;
-- теперь читаем снова и обращаем внимание, что reads = 0 - это гут, всё прочиталось только из памяти:
SQL> select * from t where id between 7894561 and 7894570 for update with lock;
Buffers = 256
 Reads = 0 
Writes 0
Fetches = 254
-- коммит/роллбак не делаем, держим записи заблокированными.
-- Мы ведь при этом владеем блокировкой в ЛМ ?

 step 2. Коннект-2: 
SQL> commit; set transaction no wait;
SQL> update t set s='upd at '||cast('now' as timestamp) where id between 7894561 and 7894570;
-- всё правильно, обламываем его:
Statement failed, SQLSTATE = 40001
lock conflict on no wait transaction
-deadlock
-update conflicts with concurrent update
-concurrent transaction number is 34

 step 3. Коннект-1: 
-- блокировка записей, полученная на шаге-1, НЕ снята!
SQL> select * from t where id between 7894561 and 7894570;
Buffers = 256
 Reads = 1 
Writes 0
Fetches = 254

Повторяю еще раз шаги 2 и 3 - получаю всё время в коннекте -1 число reads = 1 .
То же самое при обычном update ... where id between ...

Таким обр., каждый раз, когда залоченные "нами" записи кто-то другой хочет изменить, "мы" (коннект-1) при обращении к соотв-щей странице всё равно лезем на диск.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500152
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисну так 2 коннект вытесняет данные из кеша. Ты же не думаешь, что данные попадают в кеш по коммиту?с какого будуна коннект-2 вытолкнет страницу из ЧУЖОГО кеша ? (посмотри сабж топега! Классик и СуперКлассик - там же кеши у всех "свои")
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500155
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrработа с кешем практически не пересекается с транзакционным механизмом, они на разных уровнях находятсятогда как объяснить, что аз есмьВыполнение коннектом_2 отмены транзакции также приведет к тому, что коннект_1 при перечитывании этих строк полезет на диск (reads опять >0).
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500160
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидболее "поздние" строки лягут ближе к началу страницы - это так или нет ?все верно, насколько я помнюА тогда правильно ли я понимаю, что db_key отражает удалённость записи не от "верха", а именно от "подвала" страницы (если смотреть на вышеприведенный рисунок с "Эппизодов"):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SQL> create table t2(id int, s varchar(50)); commit;
SQL> insert into t2 values(1, rpad('',30,'row #1'));
SQL> insert into t2 values(2, rpad('',30,'row #2'));
SQL> insert into t2 values(3, rpad('',30,'row #3'));
SQL> insert into t2 values(4, rpad('',30,'row #4'));
SQL> insert into t2 values(5, rpad('',30,'row #5'));
SQL> select rdb$db_key,id,s from t2;

DB_KEY                     ID S
================ ============ ================================
810000000 1 000000            1 row #1row #1row #1row #1row #1
810000000 2 000000            2 row #2row #2row #2row #2row #2
810000000 3 000000            3 row #3row #3row #3row #3row #3
810000000 4 000000            4 row #4row #4row #4row #4row #4
810000000 5 000000            5 row #5row #5row #5row #5row #5
-- ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500204
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТаким обр., каждый раз, когда залоченные "нами" записи кто-то другой хочет изменить, "мы" (коннект-1) при обращении к соотв-щей странице всё равно лезем на диск.
конечно, т.к. "хочет изменить" = "берет эксклюзивную блокировку на страницу", а мы ее теряем
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500207
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидс какого будуна коннект-2 вытолкнет страницу из ЧУЖОГО кеша ?
не вытолкнет, но пометит инвалидной и требующей перечитки самим коннектом-1
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500216
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидправильно ли я понимаю, что db_key отражает удалённость записи не от "верха", а именно от "подвала" страницы
в общем случае, он вообще никак не отражает положение записи на странице, т.к. адресует логический слот. При последовательном заполнении все будет как ты сказал, после первых же удалений это уже не факт.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500258
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr"хочет изменить" = "берет эксклюзивную блокировку на страницу ", а мы ее теряем Кажись, дошло: когда я делаю select for update with lock / update или delete даже одной записи, то он делает низкоуровневую кратковременную excl-блокировку всей страницы, после чего тут же отпускает её (это и есть "мы её теряем").
Это так ? И если да, то получается, я могу заставить все аттачи с незакоммиченными update/delete-транзакциями перечитывать по-новой страницы с диска, даже если они залочили ВСЕ записи таблицы - если буду делать вот такое "идиотство":
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
commit;
set transaction no wait;
set term ^
execute block as
declare v_id type of column t.id;
declare v_f01 type of column t.f01;
begin
  for select f01,id from t into v_f01, v_id do
  begin
    begin
      update t set f01=f01 where id = v_id;
      when any do begin end
    end
  end
end^
set term ;^
rollback;

- так ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500270
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrПри последовательном заполнении все будет как ты сказал, после первых же удалений это уже не факт.я именно про последовательное заполнение и говорю.
Значит, db_key = 810000000 1 000000 будет у записи, которая ближе к ПОДВАЛУ страницу, а 810000000 5 000000 - у записи, которая ближе к её ВЕРХУ.
Но тогда при вычитке страницы в память (от ВЕРХА к ПОДВАЛУ) мы должны были бы при увидеть эти строки в "перевернутом" порядке:
Код: plaintext
1.
2.
3.
4.
5.
6.
DB_KEY                     ID S
================ ============ ===================
8100000005000000            5 row #5row #5row #5row #5row #5
8100000004000000            4 row #4row #4row #4row #4row #4
8100000003000000            3 row #3row #3row #3row #3row #3
8100000002000000            2 row #2row #2row #2row #2row #2
8100000001000000            1 row #1row #1row #1row #1row #1
Почему этого не происходит ? Страница как читается, "задом наперёд", что ле ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500273
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

так, только перечитываться страницы будут по необходимости (при следующем обращении)
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500278
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидпри вычитке страницы в память (от ВЕРХА к ПОДВАЛУ)
я не знаю, о чем ты. Страница в память читается единым блоком.
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500297
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидпри вычитке страницы в память (от ВЕРХА к ПОДВАЛУ)
я не знаю, о чем ты. Страница в память читается единым блоком.я о том, что 10 записей длиной по 100 каждая будут представлены на странице не в виде одной "неделимой атомарной точки", а именно как 10 последовательностей по 100 байт каждая.
Первая послед-сть в 100 байт была сохранена возле "подвала", вторая - "над первой" и т.д.
А как их будет вычитывать оттуда движок, в каком порядке ? От заголовка вниз к подвалу или также, как они были сохранены, т.е. от подвала вверх ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500314
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА как их будет вычитывать оттуда движок, в каком порядке ?
в порядке возрастания dbkey
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500320
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидА как их будет вычитывать оттуда движок, в каком порядке ?в порядке возрастания dbkeyМеньшие dbKey лежат возле подвала страницы (она так заполняется, когда изначально пустая). Значит, движок будет читать страницу "задом наперёд", от подвала к верху. То есть - против порядка, в котором байты этой страницы пролетают под головкой диска.
Это так или нет ?
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500323
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

забудь про головку диска, вся страница уже в памяти и пофиг в каком порядке из нее дергать байты
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500346
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrзабудь про головку диска, вся страница уже в памяти и пофиг в каком порядке из нее дергать байтыЭто как это ? Что за чудеса ? Кто-то же должен её с диска в память-то прочитать ?..
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500383
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидdimitrзабудь про головку диска, вся страница уже в памяти и пофиг в каком порядке из нее дергать байтыЭто как это ? Что за чудеса ? Кто-то же должен её с диска в память-то прочитать ?..

Толсто троллишь :) С диска оно приходит блоками контроллера диска/контроллера рэйда/кэша операционки. Каких оно там размеров никто уже тебе точно и не скажет. У приличных людей размеры этих блоков стремятся к размерам страницы БД
...
Рейтинг: 0 / 0
Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
    #38500387
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

еще раз - в кеш страница с диска читается одним куском , как при этом бегают головки HDD - пофиг. Читать и распаковывать записи (хоть первую, хоть последнюю, хоть все подряд) начинаем когда вся страница уже в памяти. Ну и какая тут нафиг разница, в "голове" или в "хвосте" страницы лежит искомая запись? И читать их "вверх" по байтам или "вниз"? Ты до какого-то бреда уже докопался, ей богу.
...
Рейтинг: 0 / 0
25 сообщений из 33, страница 1 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Classic & SuperClassic: как коннект узнаёт, что ему надо перечитать страницу в свой кеш ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]