Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
У gbak есть полезная возможность - бэкап с удаленного сервера с доставкой результата на локальную машину. Очень нужна данная функциональность. Отсутствует в Firebird-Net- Provider - сохранение бэкапа только в файловой системе сервера. В родном API клиента - не нашел, похоже тоже отсутствует. Выходит gbak использует недокументированные возможности API? Просто вариант с запуском из управляемого кода gbak (а значит придется утилиты отставлять на локальную машину из дистрибутива сервера для конкретной OS) в консоле слегка кривоват, может кто что подскажет? Заранее спасибо за ответ.
Re: Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
Спасибо за ответ. On 26 июн, 11:58, Dmitri Kuzmenko wrote: > Hello, Eugeny! > > Соответственно имитация gbak через API - это ахинея. И вправду уверен? Про имитацию не было и слова. > > Просто вариант с запуском из управляемого кода gbak (а значит придется > > утилиты отставлять на локальную машину из дистрибутива сервера для > > конкретной OS) в консоле слегка кривоват, может кто что подскажет? > > кривоват чем? И зачем бэкап нужен на "локальной" машине, если голый > клиент с этим файлом бэкапа ничего сделать не может? Разве что > кроме как заресторить его на сервер. Нужен например для того, чтобы автоматический бэкап осуществлялся с другой машины(может и не одной) в сети и при этом был кросплатформенным (.Net) и не тащил за собой дистрибутивы серверов для всевозможных осей. На локальной машине бэкап нужен для более надежного хранения.
Re: активация всех индексов
On 1 июл, 12:38, Alexey Popov wrote: > Восстанавливал невосстановимый но очень нужны backup. Отключение индексов > ключём -i помогло. Теперь вопрос на будущее: как наиболее просто их всех > активировать обратно. Простой способ не подходит т.к. сначала нужно > восстаналивать PK, а потом FK Хранимые процедуры для обслуживания индексов. / **/ /Процедуры для обслуживания индексов БД/ / **/ SET TERM ^ ; -- Расчитывает селективность всех индексов CREATE OR ALTER PROCEDURE INDICES_REBUILD_SELECTIVITY AS DECLARE VARIABLE S VARCHAR(200); BEGIN /*Процедура для перерасчета селективности индексов, запускать переодически (если не было ресторинга БД), либо в случае больших изменений в БД.*/ FOR SELECT RDB$INDEX_NAME FROM RDB$INDICES INTO :S DO BEGIN S = 'SET statistics INDEX ' || S || ';'; EXECUTE STATEMENT :S; END SUSPEND; END^ -- Включает/выключает индексы в БД CREATE OR ALTER PROCEDURE INDICES_SWITCH ( ENABLE_FLAG INTEGER) AS DECLARE VARIABLE RELATION_NAME VARCHAR(256); DECLARE VARIABLE INDEX_INACTIVE INTEGER; DECLARE VARIABLE ACTION_NAME VARCHAR(50); DECLARE VARIABLE SQL VARCHAR(256); BEGIN /* Переключает состояние индексов */ /* source SQL SELECT R.RDB$CONSTRAINT_NAME, R.RDB$INDEX_NAME AS REFINDEXNAME, I.RDB $INDEX_NAME AS REALINDEX, I.RDB$RELATION_NAME, I.RDB$INDEX_INACTIVE FROM RDB$INDICES I RIGHT JOIN RDB$RELATION_CONSTRAINTS R ON I.RDB $INDEX_NAME = R.RDB$INDEX_NAME WHERE R.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY' OR R.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY' ORDER BY R.RDB$CONSTRAINT_NAME */ --Все активные переводим в неактивные (default) INDEX_INACTIVE = 0; ACTION_NAME = 'INACTIVE'; IF (ENABLE_FLAG > 0) THEN BEGIN --Перевод в активное состояние INDEX_INACTIVE = 3; ACTION_NAME = 'ACTIVE'; END FOR SELECT I.RDB$INDEX_NAME FROM RDB$INDICES I RIGHT JOIN RDB$RELATION_CONSTRAINTS R ON I.RDB$INDEX_NAME = R.RDB $INDEX_NAME WHERE (R.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY' OR R.RDB $CONSTRAINT_TYPE = 'PRIMARY KEY') AND (I.RDB$INDEX_INACTIVE = :INDEX_INACTIVE) INTO :RELATION_NAME DO BEGIN SQL = 'ALTER INDEX ' || RELATION_NAME || ' ' || ACTION_NAME; IF (SQL IS NOT NULL) THEN EXECUTE STATEMENT SQL; END END^ -- Переактивация индексов через выключение-включение CREATE OR ALTER PROCEDURE INDICES_REACTIVATE AS BEGIN EXECUTE PROCEDURE INDICES_SWITCH(0); EXECUTE PROCEDURE INDICES_SWITCH(1); END^ SET TERM ; ^ С уважением, Евгений Виноградный.
Re: расширение синтаксиса в INTO
> Я про ситуацию без FOR > я про то когда просто select into вернет 0 строк и оставит переменные в > списке INTO со старыми значениями. > Сейчас это решается путем инициализации их перед select into > а я предлагаю уменьшить количество букв. ;) А что то вроде IF (ROW_COUNT = 0) THEN ... Не подойдет? Там можно и сбросить если уж так надо ...
Re: активация всех индексов
День добрый, Dmitri Kouzmenkoю > Vinogradniy Eugeny wrote: > > / Процедуры для обслуживания индексов > > как обычно, чего-нибудь посоветуешь, частное, так > в результате сделают универсальную процедуру, на практике > бесполезную или вредную. > ХрПр года 3 как есть, несколько раз пригодилась. С другой стороны ХрПр можно обернуть в EXECUTE BLOCK и выполнить хоть через isql. В общем то, это конкретный пример того, как можно реализовать. P.S. В кривых руках любая вещь может превратиться в "грозное оружие" :)
Re: OFF: нÑжен пÑогÑаммиÑÑ
On 13 ноÑ, 17:18, ÐлекÑей ÐиÑнÑков wrote: > Ð ÑколÑко денег? ÐомпенÑаÑÐ¸Ñ Ð½Ð¾ÑÑалÑгией... :)
Re: Windows7 Ultimate 64 and Firebird 2.5 64
Dmitri Kuzmenko wrote: > Люди и так нихрена не понимают разницу, зачем их еще путать? Совершенно верно. Еще что замечу на VS под FB много кто пишет. Только в варианте Firebird ADO.NET Data Provider + Firebird. По умолчанию все проекты .net билдятся как AnyCPU, т.е. прекрасно работают на x64битных ОС в родном x64 битном режиме (реализация Firebird ADO.NET Data Provider тоже прекрасно работает в x32/x64 битном режиме). И прекрасно подключаются к x32/x64 битным серверам. Есть только проблемы при использовании embeded Firebird сервера. Т.к. его дистрибутив конкретен x32 или x64. Вот в таких вариантах и приходится либо привязывать .net приложение к конкретному процессору x86(x64) (так мы и сделали). Либо в дистрибутиве поставлять оба варианта embeded Firebird и определять выбор в строке подключения на момент соединения в зависимости от типа исполнения приложения x32/x64, но в таком случае наверное (это вопрос? к тем кто знает/пробовал) возможны чудеса с ODS БД.
