|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vova Aksionov 2:5020/400 05 Jan 2003 09:46:29
To : Sergey Prach
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
On Fri, 3 Jan 2003 10:16:27 +0000 (UTC), "Sergey Prach"
<slprach@kot.poltava.ua> wrote:
>> 1. Дельты записей (версии) ничем не отличаются от самих записей по
>> технологии хранения - и лежать могут на любой странице - нет
>> необходимости предварительного резервирования места именно под версии.
>
> Да какая разница где они хранятся (вы мои месаги читать умеете) - все
>равно под них нужно место, а значит идет эскалация дисковых операций.
Если я правильно помню у кого-то было предположение что версии могут
храниться только на той же странице где и так сказать основная запись
- и могут быть проблемы если места на этой же странице не окажется.
Я просто говорю что не обязательно на той же странице - а на общих
основаниях.
...
> Это уже больше похоже на правду. Кто бы мне еще объяснил реализацию
>технологии snapshot, которая не требует выполнения процедуры создания
>полного снимка БД?
А зачем его делать - пролный снимок? Сама база и есть этот снимок.
Когда ее начинают изменять после старта snapshot-транзакции -
создаются версии записей. А старые версии, которые существовали на
момент старта snapshot-транзакции просто не удаляются при сборке
мусора - так как есть заинтересованная в них транзакция.
При выдаче данных snapshot-транзакцией так же смотрится а не была ли
эта запись (версия) вставлена после старта snapshot-транзакции
(определяется по номеру транзакции) - и если она была вставлена позже
- то она ингорируется. Т.е. снимок делается только для тех записей
которые изменяются после старта snapshot-транзакции. Т.е. если после
ее старта никаких записей не изменялось - то никаких лишних версий от
просто наличия snapshot-транзакции не появляется. Причем речь идет
только про ИЗМЕHЕHИЕ записей (или удалении) - операция вставки делает
единственную версию.
Понятно объяснил?
>> Самый яркий пример - select count(*) from table -
>> у IB происходит полный перебор всех записей и всех их версий - и на
>> миллионных таблицах может длиться минутами, в то время как на
>> блокировочниках это выдается мнгновенно.
>
> А это ну уж очень похоже на горькую правду, с сухим остатком. Вот только
>смысл в индексах резко теряется, если они содержат мусор.
Это не горькая правда - это просто правда. Если об этом знать заранее
то просто проектируешь по другому. Hа самом деле
select count(*) from table
требуется так же часто как goto в паскале - дело привычки.
Что бы не было много мусорых версий надо еще при проектировании
избегать массовых удалений и обновлений, и принимать меры к сборке
мусора исходя из конкретных условий работы - например днем мусор не
собирается а собирается весь ночью по шедулеру, или наоборот, штатный
режим - мусор собирает следующая транзакция.
Собственно что такое "мусорная версия" - это версия записи в чтении
которой никто больше не заинтересован. Hад этим надо думать - все в
общем-то просто но только если с пеленок с версионником. Если пришел с
блокировочника - все поначалу выглядит неестественно и странно.
Пока.
-------------
Vova Aksionov
Novosibirsk
--- ifmail v.2.15dev5
* Origin: Sinor-NMTS (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
