iBase.ru Forum

Доброго времени суток! Ситуация: после удаления 5 млн записей из 8 связанных таблиц Backup с Garbage collection=true не производится (это понятно), соответственно, делается Backup с GC=false, затем restore, затем снова Backup с GC=true, Restore и работа с базой продолжается. Размер базы данных после Restore в первом случае и во втором одинаков. То есть получается, что второй Backup с GC=true и Restore не нужны, но... если оставить базу в качестве рабочей после GC=false, вроде как весь "мусор" останется на прежнем месте, так? Так почему же у них размер одинаковый и стоит ли делать вторую процедуру Backup/Restore с GC=True? Все пишут, что необходимо после удаления такого количества записей чистить базу, а как, если кроме вышеописанного варианта ничего не работает(зависает на десяток часов и Sweep, и select count(*)и др.)
База на FireBird 1.0.2.908, размер 4,5 Гб
Разъясните, пожалуйста. Спасибо.

эээ. зачем второй b/r делаешь? какой, блин, "мусор останется"???
когда делается бэкап, никакой мусор в бэкап не попадает. читайте же мифы на сайте. если делать бэкап СО сборкой мусора то это означает что при ЧТЕНИИ данных бэкапом мусор БУДЕТ собираться. Если бэкап делается БЕЗ сборки мусора это значит что при чтении данных бэкапом мусор будет игнорироваться, то есть останется в БД. После рестора никакого мусора в базе принципиально быть не может, т.к. его уже нет в самом бэкапе, указана сборка мусора при бэкапе, или нет.

интересна сама идея, что в бэкапе зачем то этот мусор может понадобиться рекомендую почитать www.ibase.ru/devinfo/mga.htm

и наконец - есть мусор в базе или нет можно увидеть сбором статистики + IBAnalyst. Причем он тебе покажет % версий от объема данных, в чистом виде.

Ну наконец-то объяснили по-человечески
Большое спасибо, теперь всё будет гораздо проще.

в таких случаях я всегда спрашиваю - откуда возникла такая мысль, что в бэкапе мусор? может прочитал чего, или еще откуда.

Везде, где я читал мысль была такова:
Акцент делался не на состояние базы после Backup (BC), а именно на содержимое самого файла *.gbk. То есть, мол, ВС с GC=true не включает в себя помеченные на удаление, сбойные и др мусорные записи и что рекомендуется его делать, а если BC c GC=false, то *.gbk включает в себя элементарный запакованный слепок всей базы вместе с мусором и что после restore всё что было (вместе с мусором) выльется обратно в новую базу. Исходя из этих мыслей и делалось всё по тому странному алгоритму : BC c GC=false (т.к. с true не шло), restore, BC c GC=true(т.к. так рекомендовали), restore. Читал всё это в FAQ, статьях и на форумах различных сайтов по программированию и админстрированию БД, в т.ч. на ibase.

Сложен ли переход на FB 1.5.x с FB 1.0.2.xxx и действительно ли это необходимо при условии, что "всё работает"?
А то IBAnalyst "ругнулась" на отсутствие Services API.
Спасибо.

"включает в себя слепок вместе с мусором" - такого НИГДЕ не написано и не подразумевается. Тогда вопрос - где читал? У меня такой ерунды нигде не может быть написано. Давай разбираться, если вдруг где такая лажа - буду править.

servapi есть в классике 1.5.2.