DevillioВыполняю gfix.exe filename.gdb -sweep interval 0
можно было бы написать любую абракадабру с тем же успехом. У gfix нет такой опции. есть
gfix ... -housekeeping 0

Насчет тормозов на вин10 - у меня на ноуте десятка, но я не наблюдаю каких-то проблем с расширением gdb. Хотя, можно попробовать поменять, не помешает.
Если копать глубже, можно попробовать посмотреть в processmonitor, хотя если система так "перехватывает запись", то там вряд-ли что можно будет увидеть.

Devillio30-40мбс скорость копирования (с него же на него же)
у меня так копируется на ноутбуке 5-летней давности, с hdd sata II в 5000 оборотов.

Devillio,

короче, смотреть processmonitor, кто чего и куда. много процессов придется из мониторинга исключить, но в конце-концов хоть картина нарисуется, кто там и что с диском.

Devillioдля такого положения - нормально это? или что-то в программе неправильно?
база была создана сегодня 2 часа назад. И уже активна какая-то транзакция, которая (при равномерном старте 60тыс транзакций за это время) стартовала где-то часа полтора назад. А возможно, это кто-то в ИБЭксперте засел, или еще чём-то.
Devillioтам стоит рейд. в настройках винды кеширование записи отключено и не включается
боже ж ты мой. Кстати, на простецких рейдах кэширование записи надо включать у самих дисков. Иначе у самого рэйда его не включить.

Devillioсделано так, что читающая транзакция одна на почти все чтения
читающая транзакция не будет видна как Oldest Active, только если она
read
read_committed
rec_version

видимо, у вас это не так. в ИБ-ФБ любая читающая транзакция (кроме той, что с параметрами выше), способствует накоплению версий, и препятствует их "превращению" в мусор. См. статьи на ibase.ru, и в mon$transactions.

Товарищ младший сержантА ведь сию схему люди стали применять на основании существующих примеров и статеек (про Fib+, IBX...).
На Ibase и проч.
ну что за гнусные наветы. Во-первых, см. выше. Во-вторых, если "сию схему" применять без RO RC, то об этом как раз дохрена на ibase.ru написано, что делать так не надо.
Dimitry Sibiryakovчто проталкивать такую схему чревато...
как раз там, где эта схема применяется так, как сказано, никаких проблем с застреванием OAT нет. Если человек читал статьи через пень-колоду, то это его проблемы. А скорее всего - не читал.

Симонов Денисдлинные транзакции RO RC не являются большой проблемой.
они вообще не являются проблемой, и видны только в mon$attachments. В header page они влияют только на next transaction.

goldmi45Периодически такую долгоживущую транзакцию также нужно коммитить и стартовать новую.
партизан? транзакция RO RC существует уже ШЕСТНАДЦАТЬ ЛЕТ.

Симонов ДенисЯ сомневаюсь что в этом случае длинные RO RC будут такими же безобидными. Что там на этот счёт ДЕ говорил 9 декабря?
пока я не очень понял. По идее, запросы в RC будут выполняться "в микро-снапшотах", но каких-то других.
И теперь для сборки мусора проблемой будут скорее не длинные транзакции (хоть RO, хоть RW, даже snapshot), а "недофетченные запросы", т.к. "микро-снапшот" будет сохраняться до закрытия запроса (последнего фетча).

Товарищ младший сержант,

у меня на сайте написано, что для длинных транзакций надо использовать ro rc, и указано, где и как эти параметры можно прописать.
Других инструкций нет. Как можно взять идею про "длинные транзакции" и вырезать оттуда ro rc - я не знаю.
А до того, т.е. до ro rc, и для компонент, где нельзя так управлять параметрами транзакций, я и на семинарах, и в видео на ютубе - везде советую периодически "рестартовать" длинную транзакцию.
А уж что касается commitRetaining - опять же, у меня в статьях везде про это написан негатив (и про последствия).

Таким образом, получается, что было бы желание - все можно найти, прочитать и понять. Нет желания - увы.
Как можно во всем вышеописанном прочитать или услышать одну половину, и не услышать другую - для меня загадка.

Товарищ младший сержантНу и как на это реагировать бедному пеону?
тут все разжевано
http://www.ibase.ru/dbgrowth/

Симонов Денисне проще ли это делать в кэширующие датасеты и завершать транзакцию?
Я как-то имел на эту тему разговор с Владом. И он сказал, что для девелоперов умолчательным был бы лучше автокоммит. Если уж транзакциями управлять не хотят (или не умеют), так пусть за них это делает сервер.
Собственно, не имею ничего против. Только вот исторически FreeIBComponents не делали fetchall при закрытии транзакции, а тупо убивали (а не обрубали) кэш. Зачем, почему - только Грегори Диц сможет ответить.
А после него - все копировали это поведение (точно так же как бездумно копировали умолчательный no_rec_version в драйверах).

С другой стороны, хорошо стартануть транзакцию, выполнить запрос, и потихоньку фетчить. Но если там N миллионов записей в перспективе, то FetchAll при Commit, ясное дело, вызовет разрыв шаблонов (мол, опять Firebird виноват). А если обрезать буфер по коммиту, то непонятно, что с ним делать если вдруг юзер решит ехать дальше, чем считано с сервера.

MS как-то пытается приучать, что либо FetchAll, либо никак (например, в dbExpress нет датасетов, зато есть абстрактный ClientDataSet). Но наследие прошлого висит на ноге тяжелой гирей.

Впрочем, выполнять запросы с клиента без старта транзакции сервер вполне может научиться. А там и до изменения поведения компонент недалеко.