Код: Выделить всё
update TABLE set field = 9Код: Выделить всё
Writes from cache to disk = 0
Fetches from cache = 54 334Код: Выделить всё
Writes from cache to disk = 7 430
Fetches from cache = 118 119в чём эти own problems заключаются и с чем я должен быть so much carefull? и кстати это нормально если у меня параллельно часть транзакций будет с savepoints, а часть без??Because the option can create its own problems by inhibiting the advance of the OIT, it should be used with caution, of course. The developer will need to take extra care about database housekeeping, particularly with respect to timely sweeping.
www.ibase.ru/devinfo/garbage.htmв чём эти own problems заключаются и с чем я должен быть so much carefull? и кстати это нормально если у меня параллельно часть транзакций будет с savepoints, а часть без??
www.ibase.ru/devinfo/sweep.htmнасколько я понял если сборка мусора пройдет в перерывах между обработкой действий юзверя, то собсно время на эту обработку должно уйти меньше. т.е. с точки зрения конечного результата оно будет работать якобы быстрее. вопрос: как гарантировано "спровоцировать" сборку мусора? через api?
объясните плз такую весчь:
Если не ошибаюсь сейвпоинты являются составляющей транзакций, но никак не наоборот. Если retaining фактически завершает транзакцию, то он же должен очистить стек сейвпоинтов? или этот стек входит в контекст транзакции и передаётся по наследству при retaining?Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log
Нужно ли это понимать так, что мусорные версии не становяться мусором и не будут собраны до тех пор, пока не будет вызван Commit?Кроме того, транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted.
да, так это нужно понимать.Нужно ли это понимать так
разумеется. версия идентифицируется номером транзакции, ее создавшей. Соответственно, не может быть трех версий с одинаковым идентификатором.1. если не-commited значение может быть только одно, то значит после трёх апдейтов подряд в одной транзакции у мну будет одна версионная запись?
не знаю, где аналогия. При удалении записи будет создана версия с признаком удаления. При создании записи будет новая запись. При ее обновлении - еще версия у новой записи.2. по аналогии получаеца если я удаляю запись, потом инсертю новую и потом её обновляю, то должно быть две версионных записи - одна на удалённую и одна по сути дельта от пустой.
какой еще мусор после commit??? нифига не читал.И после комита они станут мусором?
кстати, ты не в том порядке это читаешь.тяжеловато чтото переварить это всё
вообще я уже весь раздел транзакций по несколько раз перечитал ))кстати, ты не в том порядке это читаешь.
аналогия в работе с версиями записей. кароче всё правильно, только упустил что инсерт тоже создаёт свою версию.не знаю, где аналогия
я имел в виду, что единственная ситуация когда версии записей становятся мусором и могут быть удалены - это перевод транзакции в подтверждённое состояние. а пока транзакция активна в любом случае живут ВСЕ созданные в этой транзакции версии. Верно?какой еще мусор после commit???
Нет, блокировок там нет. просто пытался упростить алгоритм, но производительность слишком упала. так что пришлось переделать расчёт и уменьшить количество модификаций.Кстати, неясно, зачем тебе понадобилось массовый апдейт одних и тех же записи в одной транзакции делать. Блокируешь?
не так. пока активна транзакция, которая МОЖЕТ прочитать нужную ей версию, версии удерживаются от сборки мусора.я имел в виду, что единственная ситуация когда версии записей становятся мусором и могут быть удалены - это перевод транзакции в подтверждённое состояние. а пока транзакция активна в любом случае живут ВСЕ созданные в этой транзакции версии. Верно?
при чем тут сэйвпойнты??? не надо думать про версии и мусор вместе с сэйвпойнтами. Сэйвпойнты - это внутренний механизм сервера, который предназначен для ОТКАТА изменений. В базе, на диске, никаких сэйвпойнтов нет - они есть только в памяти.так как быть с сейвпоинтами? Если retaining фактически завершает транзакцию, то он же должен очистить стек сейвпоинтов? или этот стек входит в контекст транзакции и передаётся по наследству при retaining?
тьфу, блин. вот опять, не читал ты garbage.htm . Там же написано, что мусорные версии удаляются только при чтении или обновлении. Накой фиг серверу проверять мусор во всей таблице, если конкретный запрос например обращается только к ЧАСТИ таблицы? Опять же, в garbage.htm этот момент ОПИСАН СПЕЦИАЛЬНО!!!и кстати ещё такой момент. если policy = cooperative и мы удаляем записи, то что будет считаться обращением к удалённым записям, которое должно инициировать сборку мусора? любое обращение к таблице? или то что переберает всю таблицу аля select count?
может, тебе надо временные таблицы FB 2.1 ? там нет никакого мусора, версий и т.п.просто пытался упростить алгоритм, но производительность слишком упала. так что пришлось переделать расчёт и уменьшить количество модификаций.
та нормально я читаю, просто разобраться с этим не так просто, как хотелось бы... сори, может спрашиваю нетак, просто иногда очень нуна услышать ту же мысль но другими словами. зато теперь я начинаю понимать каким образом оно работаетче-то ты фигово читаешь. никак у тебя не складывается, и читаешь ты явно мимо, с пропусками.
- т.е. получаеца что ретейнинг тут не при чём, а лимит сейвпоинтов может быть превышен просто из-за слишком большого количества операций? т.е. того же эффекта можно достигнуть просто запустив в цикле update по таблице записей эдак на 5М?Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log
подожди, наверно я не удачно описал.тьфу, блин. вот опять, не читал ты garbage.htm . Там же написано, что мусорные версии удаляются только при чтении или обновлении. Накой фиг серверу проверять мусор во всей таблице, если конкретный запрос например обращается только к ЧАСТИ таблицы? Опять же, в garbage.htm этот момент ОПИСАН СПЕЦИАЛЬНО!!!и кстати ещё такой момент. если policy = cooperative и мы удаляем записи, то что будет считаться обращением к удалённым записям, которое должно инициировать сборку мусора? любое обращение к таблице? или то что переберает всю таблицу аля select count?
не видел ещё таких, пасиб посмотрю...может, тебе надо временные таблицы FB 2.1 ? там нет никакого мусора, версий и т.п.
примерно так. правда, ошибка и ее причины выявлены не по коду, а по откликам. так что указанная ошибка появляется именно в указанной ситуации.т.е. получаеца что ретейнинг тут не при чём
где у каждой записи пара триггеров, которые что-нибудь еще делают с другими таблицами, где опять есть тригггеры...запустив в цикле update по таблице записей эдак на 5М?
ручной или авто-свип ВСЕГДА является сборкой мусора, принудительной, поэтому в контесте ТИПА сборки мусора о нем говорить нельзя.Во-первых - если политика cooperative, то фонового процесса нет и сборка мусора осуществляется либо а) при чтении/обновлении данных либо б) при авто sweep'e.
окпредположим что автосвип мы отключили, т.е. мусор может быть удалён только при чтении/обновлении.
стартует транзакция, в этой транзакции выполняется запрос, который обращается к этим записям. при чтении версий (select/update) сервер проверит их на мусорность, и если нет других транзакций которые заинтересованы в старых версиях, то записи будут удалены.Вопрос: верно ли во-первых, и если да то когда и при каком запросе будут собраны мусорные записи от удалённых записей?
если хоть одна удаленная запись попадает под такое условие - "у нее" и будет собран мусор.сделаю select * from table where id = 15 это приведёт к сборке мусора от удалённых записей??
есть запись. У НЕЕ могут быть версии. Если ЭТУ ЗАПИСЬ читают или обновляют, и среди ЕЕ версий обнаруживаются мусорные, то ТОЛЬКО ЭТИ мусорные версии будут удалены.млин, НИКТО НЕ СОБИРАЕТ. О чем и написано в garbage.htm !!!соответственно кто тогда собирёт мусор от удалённых записей??
Вот!! Вот этого мне и не хваталоесли хоть одна удаленная запись попадает под такое условие - "у нее" и будет собран мусор.сделаю select * from table where id = 15 это приведёт к сборке мусора от удалённых записей??
Просто я никак не мог понять что значит читать или обновлять удалённые записи. А разница получается в управлении версиями и тем, какую версию считать актуальной в конкретно взятом контексте. Просто на малых выборках и при малой конкурентности об этом механизме мона и не вспоминать, разницы в производительности всё равно не будет. А вот на большом объёме и при большой нагрузке это всё нуна держать в уме - и количество версий которые плодят разные операции, и когда и как будет проходить сборка мусора, и распределение объёма операций по транзакциям. Тогда в результате производительность может меняться на порядки. По идее в конечном счёте это всё имеет смысл учитывать именно ради производительности, имхо архитектура при высокой конкурентности это уже несколько о другом и вообще другой разговор. 
мда.Просто я никак не мог понять что значит читать или обновлять удалённые записи.
Разумеется. Есть записи, у записей - версии. Сервер читает пакет версий одной записи, затем смотрит какую версию можно показывать данной транзакции.Если говорить другими словами, то получается что на уровне внутреннего представления данных движок оперирует не набором записей, а набором различных версий
Видимость версий описана в www.ibase.ru/devinfo/mga.htmпричем в каждом отдельном случае запись будет представлена одной из версий в зависимости от того, какой TIP использует транзакция, какие ещё транзакции работают с версиями этой записи и т.д.
разумеется. с поправкой - мусор, он и в африке мусор. у версии разумеется есть ключи в индексах. Когда версия становится мусорной, то же и с ключами происходит. Только у ключей нет идентификаторов транзакций.например теже индексы строяться по всем версиям записи и тогда понятно откуда берётся мусор в индексах
для того я и сделал IBAnalyst, чтобы все это можно было смотреть визуально.А вот на большом объёме и при большой нагрузке
не согласен. потому что любая долгоживущая транзакция приводит к росту числа версий, если конечно данные обновляются и удаляются. В любой системе - с одним пользователем или 500, в базе 100мб или 100гб.имхо архитектура при высокой конкурентности это уже несколько о другом и вообще другой разговор.
уже почти все окЕсли я сейчас в чём ошибся - пристрелите меня нахрен.
да, было б неплохо, но пока будем постигать на практикена самом деле, проще все это объяснять вживую, на курсах.
кстати, теперь я на 95% уверен откуда "периодические необъяснимые тормоза" у одного клиента с довольно старой и кривоватой системой. и база растёт не пропорционально, и бэкапом от 40% до 60% размера убиваецо. наверняка дето мусор зависает, теперь есть куда копать...