iBase.ru Forum

FB 1.5.1 SS под W2k
В firebird.conf установлено
DatabaseAccess = Restrict c:\database

Запускаем:
gbak -c c:\temp\db.fbk c:\temp\db.fdb

Получаем ожидаемое:
gbak: ERROR: Access to database "C:\TEMP\DB.FDB" is denied by server administrator

Повторяем попытку:
gbak -c c:\temp\db.fbk c:\temp\db.fdb

Получаем:
gbak: opened file c:\temp\db.fbk
gbak: transportable backup -- data in XDR format
gbak: backup file is compressed

... и процесс виснет намертво.
Более того, после этого вообще невозможно соединиться с любой БД.
Соединения, установленные до того работают, а новые установить нельзя.
Помогает только рестарт сервиса. Причем в момент рестарта вылетает
"fbserver.exe вызвало ошибку бла-бла".
В firebird.log пусто.

Явная бага, подтверждаю. Попытаемся включить фикс в 1.5.2.

dimitr писал(а):Явная бага, подтверждаю. Попытаемся включить фикс в 1.5.2.

Более того, в некоторых случаях, который я сечас пытаюсь локализовать, gbak (gbak version LI-V1.5.1.4481 Firebird 1.5) наглухо виснет при попытке собрать backup базы. Вот подробности:

В проекте есть база, она довольно небольшая (800 Мб). При этом до мигрирования с IB6.5 проблем с ней не наблюдалось. Когда перешли на FB (CS linux SUSE, win XP en sp 2) появились неприятные проблемы: процесс начинается и замирает на 24-том мегабайте. В таком состоянии коллапса провисает на несколько часов (или даже пару-тройку дней). Стоит заметить, что в результате файл, все же, создается.

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

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

В свое сремя пробовали такой "провисший" файл восстанавливать на IB 6.5 - тогда backup проходил нормально (около 40 минут). И этим же gbak'ом можно было собирать и с FB 1.5 win, однако с недавнего времени и это стало невозможным. При том, что структура не менялась, проблема однозначно в данных. Вопрос в том каких и где. Но самое важное - как от этого избавиться.

На SS пробовали?

забей на локальный коннект. пиши

gbak -c c:\temp\db.fbk localhost:c:\temp\db.fdb

dimitr писал(а):На SS пробовали?

Будет откровенно тормозить на машинках с HT, что просто недопустимо по условию.

kdv писал(а):забей на локальный коннект. пиши
gbak -c c:\temp\db.fbk localhost:c:\temp\db.fdb

Несмешно. Совершенно. Вопрос не в том, чтобы восстановить базу через локальный или удаленный коннект (кстати, в примере таки локальный, если верить документации и правилам работы самого gbak'а).

Вопрос в том, как получить этот fbk (gbk) файл, если база перевалила под 800М, а gbak зависает при снятии архивной копии на 6-7 часов или 2-3 дня ничего не делая.

Что-то мне здается все это из-за внутренних попыток оптимизации запросов.

Anonymous писал(а): Несмешно. Совершенно. Вопрос не в том, чтобы восстановить базу через локальный или удаленный коннект (кстати, в примере таки локальный, если верить документации и правилам работы самого gbak'а).

локальный коннект это коннект не по сети. localhost - сетевой коннект.
по поводу "несмешно" - я разве кого то хотел рассмешить? У тебя проблема, я предложил путь ее ОБХОДА.

Вопрос в том, как получить этот fbk (gbk) файл, если база перевалила под 800М, а gbak зависает при снятии архивной копии на 6-7 часов или 2-3 дня ничего не делая.

800 мегабайт - это мало. в том смысле что бэкап с -g должен проходить со свистом. попробуй коннект через localhost.

Что-то мне здается все это из-за внутренних попыток оптимизации запросов.

не вижу связи между проблемой с локальным коннектом и оптимизатором.

Anonymous писал(а):

dimitr писал(а):На SS пробовали?

Будет откровенно тормозить на машинках с HT, что просто недопустимо по условию.

Щаз буду грязно ругаться. Я спросил, пробовали ли вы, а не предлагал использовать это в повседневной работе. Ответ на мой вопрос поможет диагностировать проблему. То же самое относится к предложению kdv по поводу сетевого коннекта.

dimitr писал(а):Щаз буду грязно ругаться. Я спросил, пробовали ли вы, а не предлагал использовать это в повседневной работе. Ответ на мой вопрос поможет диагностировать проблему. То же самое относится к предложению kdv по поводу сетевого коннекта.

Если угодно - оба пути не помогают. Смысл в том, что и сборка базы без уборки мусора - не дело. Так можно и просто скопировать. Вопрос в том, как именно в _этих_ условиях сделать бэкап в обозримое время и с уборкой мусора, а не через сутки-вторые и как получится.

С таким же успехом, простите, можно порекомендовать оракл. Нужно решение, а не советы по смене платформы. Потому и не смешно.

kdv писал(а): локальный коннект это коннект не по сети. localhost - сетевой коннект.

Если обратить внимание на то, как работает сетовой и несетевой коннект gbak'а, то можно увидиеть, что разницы практически нет - в обоих случаях выполняются запросы к базе.

kdv писал(а): 800 мегабайт - это мало. в том смысле что бэкап с -g должен проходить со свистом. попробуй коннект через localhost.

Что мало - факт, потому и такое удивление на gbak. Сборка бэкапа без сборки мусорных данных - это уже не бэкап, а просто разгильдяйство. Полагаться на то, что сборка мусора быдет выполнена с первым запросом - это полагаться на то, что пользователь готов часами ждать своих результатов. А таких пользователей еще не придумали.

kdv писал(а):не вижу связи между проблемой с локальным коннектом и оптимизатором.

См. выше. Но я бы еще к этому добавил сомнения о блокировках..

Anonymous писал(а):
Если угодно -

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

Anonymous писал(а): Смысл в том, что и сборка базы без уборки мусора - не дело. Так можно и просто скопировать. Вопрос в том, как именно в _этих_ условиях сделать бэкап в обозримое время и с уборкой мусора, а не через сутки-вторые и как получится.

С таким же успехом, простите, можно порекомендовать оракл. Нужно решение, а не советы по смене платформы. Потому и не смешно.

Смысл вообще-то в том, как писать приложения, чтобы мусор не собирался. И как собравшийся убирать в то время, когда это удобно, а не первым или ещё каким запросом и не на снятии копии. Потому что обычно он накапливается от задержки OIT по причине роллбака и ситуацию может поправить только sweep, а gbak в такой ситуации только тратит попусту время в бесплодных попытках. Поэтому не особо крутые разработчики выполняют быстрое снятие бакап-копии без сборки мусора, а мусор собирают в удобное время (например по ночам и ежесуточно, чтоб его там не копились тонны) при помощи gfix. И тратят на это время от 1 минуты до 12 на 10+ гигабайтных базах. И не жужжат.

Anonymous писал(а): Если обратить внимание на то, как работает сетовой и несетевой коннект gbak'а, то можно увидиеть, что разницы практически нет - в обоих случаях выполняются запросы к базе.

прямо так и хочется сказать - "да ты что!"
однако, я думаю, что до "запросов к базе" дело в данном случае не доходит. Локальный и сетевой коннекты, видите ли, осуществляются по разному, и обрабатываются разным кодом клиента и сервера.

Anonymous писал(а): Что мало - факт, потому и такое удивление на gbak. Сборка бэкапа без сборки мусорных данных - это уже не бэкап, а просто разгильдяйство. Полагаться на то, что сборка мусора быдет выполнена с первым запросом - это полагаться на то, что пользователь готов часами ждать своих результатов.

откуда такая категоричность??? На одном биллинге, даже если он порождает тонны мусора, свет клином не сошелся - есть и другие задачи, в которых все совершенно не так. Делать бэкап СО сборкой мусора - это вообще то наоборот, разгильдяйство. Потому как в силу вышеупомянутых причин эта самая сборка мусора может очень сильно замедлить процесс бэкапа. А получение бэкапа - это как раз более первоочередная задача, чем сборка какого-то там мусора, который в нормальных приложениях должен (и обычно так и делает) собираться сам, без проблем.

Собственно, есть куча вариантов по изготовлению бэкапа - со сборкой мусора, без, со sweep, с ежедневным restore, и т.п. Поэтому Ваши утверждения являются чересчур однобокими, увы.

Anonymous писал(а):

kdv писал(а):не вижу связи между проблемой с локальным коннектом и оптимизатором.

См. выше. Но я бы еще к этому добавил сомнения о блокировках..

куда смотреть выше, и при чем тут блокировки?

И кроме того я бы попросил. Я работаю с Interbase с 1994 года, и не просто работаю, а еще и общаюсь с людьми, которые тоже используют IB/FB. И поэтому имею кое-какой накопленный, не просто свой, а вообще, опыт по работе различных систем на IB/FB. Я не хочу сказать, что мои утверждения являются бесспорными, но тыкать мне механизмом gbak и особенно "черезвычайной необходимостью сборки мусора при backup" пожалуйста не надо.

Katurov писал(а): В проекте есть база, она довольно небольшая (800 Мб). При этом до мигрирования с IB6.5 проблем с ней не наблюдалось. Когда перешли на FB (CS linux SUSE, win XP en sp 2) появились неприятные проблемы: процесс начинается и замирает на 24-том мегабайте. В таком состоянии коллапса провисает на несколько часов (или даже пару-тройку дней). Стоит заметить, что в результате файл, все же, создается.

кстати, по поводу "оптимизатора". gbak выполняется в две фазы - первая это сборка и запись в бэкап метаданных. и вторая - считывание данных из пользовательских таблиц.
Так вот, первую фазу опустим, а во второй как раз все таблицы можно сказать что вычитываются банальным select * from table. у таких запросов, известно, план - натуральный перебор. т.е. никакой "оптимизации" или работы оптимизатора тут вообще нет.

Про "24-ый мегабайт" - если gbak запускается с ключом -v и -y <filename>, то можно регулярно заглядывать в <filename> и смотреть. в каком именно месте происходит "провисание".
А дальше уже смотреть, что это за таблица, и даже что это за данные, и разбираться с проблемой.

Katurov писал(а): В свое сремя пробовали такой "провисший" файл восстанавливать на IB 6.5 - тогда backup проходил нормально (около 40 минут).

40 минут для 800 мегабайт - это ненормально.