date:20070508

Hello, Vlad!

Vlad Horsun wrote:

Насколько я понял, не так. БД модифицируется как и раньше, но предыдущие
образы страниц (до их модификации) сначала идут в отдельный файл из которого
попадают в дамп

Дык это я со слов Todd'а в ответ тебе в b.p.i.g ;)

что-то я пропустил. В любом случае:

"Когда страница обновляется во время работы дампа, ее старая
копия помещается в page appendix file. Когда дамп читает
страницу, и обнаруживает что ее временная метка больше чем
время старта дампа, то он пропускает эту страницу, т.к. знает,
что ее старое содержимое будет в page appendix file.
Когда дамп завершил копирование страниц БД, он считывает все
страницы из page appendix file и помещает их в дамп".

Тут не без фантазий, имхо, но в целом принцип виден

так принцип мог быть и такой как я описал. хотя м.б. сложнее
в реализации. Действительно, проще старые страницы с их номерами
кидать в page appendix file, чем туда кидать новые страницы а при чтении
для обычной работы БД на время дампа их оттуда выколупывать.

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

кстати, видел презентуху Чарли Каро?

Там где Шрирам начинает ? Да, но Чарли я слушать не смог. Мой ух
его совершенно не понимает.

жаль. вот я Шрирама слушать не могу, ухо режет. А Чарли очень даже
внятно все объясняет. я попробую по его мотивам сделать комментарии
в переводимом IB2007UpdateGuide.

Дык посмотри, повтори и нам расскажи ;)

ладно.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb

2007-05-08 Пенетрантность Vlad Horsun

"Dmitri Kuzmenko" ...
>
> Hello, Vlad!
>
> Horsun Vlad wrote:
>
> > Насколько я понял, не так. БД модифицируется как и раньше, но предыдущие
> > образы страниц (до их модификации) сначала идут в отдельный файл из которого
> > попадают в дамп
>
> свят-свят. надо будет проверить. А то я как ни спрошу на форуме,
> все молчат. или какой-нибудь идиотизм отвечают. прямо беда,
> умный вопрос ведь задать невозможно.

Дык это я со слов Todd'а в ответ тебе в b.p.i.g ;)

---
The solution is that if a page is updated while a dump is running the
before image of the page is written to the page appendix file. When the
dump tries to read the updated page it discovers that the timestamp on
the page is greater than the start time of the dump. Therefore the dump
skips this page because it knows that the page is in the page appendix.
When the dump as finished it gets all of the pages from the page
appendix file and adds them to the dump.

Warning: This may not be correct. It is based on a combination of
things I have been told and some inference on my part.

--
Bill Todd (TeamB)
---

Тут не без фантазий, имхо, но в целом принцип виден

> кстати, видел презентуху Чарли Каро?

Там где Шрирам начинает ? Да, но Чарли я слушать не смог. Мой ух
его совершенно не понимает.

> Когда он из обновляемого
> в онлайне архива журнала в онлайне же НАКАТЫВАЕТ ИЗМЕНЕНИЯ НА КОПИЮ
> БАЗЫ, и показывает разный select count при этом? Чума.
> я никак не соберусь третий раз посмотреть. А то после первых
> двух все равно остается ощущение чуда и одновременно надувательства
> (ну вы знаете, как с фокусами).

Дык посмотри, повтори и нам расскажи ;)

--
Хорсун Влад



--~--~-~--~~~---~--~~
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы 
"gmane.comp.db.firebird.russian" на группах Google.
 Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ru-firebird@googlegroups.com
 Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: [EMAIL 
PROTECTED]
 Дополнительные варианты находятся на странице группы 
http://groups.google.com/group/ru-firebird?hl=ru
-~--~~~~--~~--~--~---

Re: vldb



Hello, Vlad!

Horsun Vlad wrote:


Насколько я понял, не так. БД модифицируется как и раньше, но предыдущие
образы страниц (до их модификации) сначала идут в отдельный файл из которого
попадают в дамп


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

кстати, видел презентуху Чарли Каро? Когда он из обновляемого
в онлайне архива журнала в онлайне же НАКАТЫВАЕТ ИЗМЕНЕНИЯ НА КОПИЮ 
БАЗЫ, и показывает разный select count при этом? Чума.

я никак не соберусь третий раз посмотреть. А то после первых
двух все равно остается ощущение чуда и одновременно надувательства
(ну вы знаете, как с фокусами).

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: OFF: Ð¡Ð¾ÑÑÐ¸ Ð½Ðµ ÑÐ´ÐµÑÐ¶Ð°Ð»ÑÑ ...

2007-05-08 Пенетрантность Weber Eugen




On 08.05.2007, at 15:42, ÐÐ¾Ð½ÑÑÐ°Ð½ÑÐ¸Ð½ wrote:



ÐÑ ÐµÑÐ»Ð¸ ÑÑÐ¾ Ð½Ðµ "ÑÑÐºÐ°", ÑÐ¾ ...
ÐÐ¾ÑÐ¾ÑÐµ Ð¿Ð¾Ð²ÐµÑÐ¸ÑÑÑ - ÑÐ¸ÑÐ°ÐµÐ¼ ÑÐ°Ð¼Ð¸ ...
http://stfw.ru/page.php?id=4812


Ð¥Ðµ, Ð° Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐ¸ MacOS ÑÑÐ¾ ÑÐ¸Ð¿Ð° Ð¼Ð°Ð½ÑÑÐºÐ¸-Ð¸Ð·Ð²ÑÐ°ÑÐµÐ½ÑÑ? :)

Re: Непонятная проблема с FB2

2007-05-08 Пенетрантность Vladimir A.Bakhvaloff




Тебе добавить номер BLR-контекста данной сортировки ? :)))


А ещё при парсинге нельзя никак определить что среди полей есть блоб?


 AK>>> ÃÃÃ ÃÃÃÃÃÃ ÃÃÃ ÃÃÃ ÃÃÃÃÃÃÃ ÃÃÃÃ. ÃÃÃ ÃÃÃÃÃ. ;)
 Ã«>> ... ÃÃÃ ÃÃ ÃÃÃÃÃ ÃÃÃÃÃÃ "ÃÃÃÃÃÃÃÃ" ;)
 Alexandr> ÃÃ Ã ÃÃÃ Ã ÃÃÃÃÃ, ÃÃÃÃÃÃÃ Ã ÃÃÃÃÃÃ ÃÃÃ ÃÃÃ ÃÃÃÃÃ.

...ÃÃÃÃ, ÃÃÃ ÃÃ ÃÃÃÃÃÃÃÃ ÃÃÃÃÃ Ã ÃÃÃÃÃ ÃÃÃÃÃ...%)

---
E-mail: bobbakhspbru ICQ: 12861767 (1608235)
np: The B-52's - There's A Moon In The Sky (Called The Moon) (from "The 
B-52's" - 1979)

Re: OFF: Ð¡Ð¾ÑÑÐ¸ Ð½Ðµ ÑÐ´ÐµÑÐ¶Ð°Ð»ÑÑ ...

2007-05-08 Пенетрантность Alexandr Kochmin



Ð>
AK>> ÑÑÐ° ÑÑÑÐ»ÐºÐ° ÑÑÑ ÑÐ¶Ðµ ÑÐµÐ³Ð¾Ð´Ð½Ñ Ð±ÑÐ»Ð°. ÐÐ¸Ñ ÑÐµÑÐµÐ½. ;)
Ð>
Ð> ... Ð¼Ð½Ðµ Ð¿Ð¾ Ð°ÑÑÐºÐµ ÑÐ¿ÐµÑÐ²Ð° "Ð´Ð¾Ð»Ð¾Ð¶Ð¸Ð»Ð¸" ;)

Ð½Ñ Ñ ÑÐ°Ðº Ð¸ Ð¿Ð¾Ð½ÑÐ», Ð¿Ð¾ÑÑÐ¾Ð¼Ñ Ð¸ ÑÐºÐ°Ð·Ð°Ð» ÑÑÐ¾ Ð¼Ð¸Ñ ÑÐµÑÐµÐ½.

--
Ð¡ ÑÐ²Ð°Ð¶ÐµÐ½Ð¸ÐµÐ¼
ÐÐ¾ÑÐ¼Ð¸Ð½ ÐÐ»ÐµÐºÑÐ°Ð½Ð´Ñ
Firebird Foundation associate member #257

Re[2]: OFF: Ð¡Ð¾ÑÑÐ¸ Ð½Ðµ ÑÐ´ÐµÑÐ¶Ð°Ð»ÑÑ ...

2007-05-08 Пенетрантность ÐÐ¾Ð½ÑÑÐ°Ð½ÑÐ¸Ð½


AK> ÑÑÐ° ÑÑÑÐ»ÐºÐ° ÑÑÑ ÑÐ¶Ðµ ÑÐµÐ³Ð¾Ð´Ð½Ñ Ð±ÑÐ»Ð°. ÐÐ¸Ñ ÑÐµÑÐµÐ½. ;)

... Ð¼Ð½Ðµ Ð¿Ð¾ Ð°ÑÑÐºÐµ ÑÐ¿ÐµÑÐ²Ð° "Ð´Ð¾Ð»Ð¾Ð¶Ð¸Ð»Ð¸" ;)

Ð¡ ÑÐ²Ð°Ð¶ÐµÐ½Ð¸ÐµÐ¼,
ÐÐ¾Ð½ÑÑÐ°Ð½ÑÐ¸Ð½ ÐÑÐ¸Ð³Ð¾ÑÑÐµÐ²Ð¸Ñ.
===

Re: GSTAT в FB 2.01

2007-05-08 Пенетрантность Кузнецов Евгений



Dmitry Yemanov wrote:
Связано с предыдущим. Напиши мне в почту, я тебе на днях дам на 
тестирование исправленный вариант GSTAT.


Хорошо, спасибо.

С уважением, Евгений.

OFF: Ð¡Ð¾ÑÑÐ¸ Ð½Ðµ ÑÐ´ÐµÑÐ¶Ð°Ð»ÑÑ ...

2007-05-08 Пенетрантность ÐÐ¾Ð½ÑÑÐ°Ð½ÑÐ¸Ð½


Hi, Ð¼Ð½Ð¾Ð³Ð¾ÑÐ²Ð°Ð¶Ð°ÐµÐ¼ÑÐ¹ All!

ÐÑ ÐµÑÐ»Ð¸ ÑÑÐ¾ Ð½Ðµ "ÑÑÐºÐ°", ÑÐ¾ ...
ÐÐ¾ÑÐ¾ÑÐµ Ð¿Ð¾Ð²ÐµÑÐ¸ÑÑÑ - ÑÐ¸ÑÐ°ÐµÐ¼ ÑÐ°Ð¼Ð¸ ...
http://stfw.ru/page.php?id=4812


Ð¡ ÑÐ²Ð°Ð¶ÐµÐ½Ð¸ÐµÐ¼,
ÐÐ¾Ð½ÑÑÐ°Ð½ÑÐ¸Ð½ ÐÑÐ¸Ð³Ð¾ÑÑÐµÐ²Ð¸Ñ.
===

Re: GSTAT в FB 2.01

2007-05-08 Пенетрантность Кузнецов Евгений



Да, забыл упомянуть - 2.0.1 СS
Проблема уже поднималась здесь 
http://forum.ibase.ru/phpBB2/viewtopic.php?t=2740&highlight=gstat

но в 2.0.1 как раз собирались исправить

С уважением, Евгений

Re: GSTAT в FB 2.01

2007-05-08 Пенетрантность Dmitry Yemanov



Кузнецов Евгений wrote:


Что есть
Win2k SP4 + Update Rollup
IB 4.2.1 на порту 3050
FB 1.5.4 на 3070
FB 2.0.1 на 3100
FB 1.5.4 и FB 2.0.1 запущены как сервисы (сервис FB 2.0.1 проходит под
именем FirebirdServer201)
В реестре прописаны только сервисы, ветку Firebird Project хоронил.
В System32 лежит gds32.dll от FB 1.5.3, но влияния на проблему не 
оказывает.


Окопался (DatabaseAccess = None), в aliases.conf указал
employee = c:\Program
Files\Firebird\Firebird_2_0\examples\empbuild\EMPLOYEE.FDB

Пробую получить статистику. Первой неожиданностью стала чувствительность
localhost к регистру


Можно поправить :-)


Ну ладно, все равно gstat -h запущенного сервера не требует, можно имя
хоста не указывать.


Обычно и не нужно его указывать. Эта фича была нужна только для 1.5 CS, 
в котором не было локального протокола.



Но вот чтобы получить статистику data and index pages для IBAnalyst уже
нужно соединение с сервером. Пробую
gstat -a localhost/3100:employee - "Не удается найти указанный файл.",
хотя в gstat от FB 1.5 указание порта воспринимается нормально


Да, вроде отломилось это в 2.0. Попробуем восстановить.


Хорошо, пусть
gstat -a localhost:employee
В конце пишет
Database file sequence:
File c:\Program
Files\Firebird\Firebird_2_0\examples\empbuild\EMPLOYEE.FDB is the only file
Access to database "C:\PROGRAM
FILES\FIREBIRD\FIREBIRD_2_0\EXAMPLES\EMPBUILD\EMPLOYEE.FDB" is denied by
server administrator


Связано с предыдущим. Напиши мне в почту, я тебе на днях дам на 
тестирование исправленный вариант GSTAT.



--
Дмитрий Еманов

Re: Firebird 2 Embedded

2007-05-08 Пенетрантность Fanis

On 3 май, 21:50, "Andrew Holubovski" <[EMAIL PROTECTED]> wrote:
> Скажите, пожалуйста, можно ли заставить программу использующую Firebird 2
> Embedded запуститься из зашаренной на сервере папки? Или все таки прога
> должна лежать локально на винте?

embedded используется только локально - без шар и прочих попыток
обратиться извне к БД. Почему embedded, если возможно
многопользование? Тут явно неправильное решение - собственно, я сам
ставлю флажок "локальная БД" для использования Embedded и возможность
выбора BasePath, если таки требуется иное.

procedure Tdm.DataModuleCreate(Sender: TObject);
begin
  if iniData.isLoc=1 then  //isLoc считывается при старте в реестре
  Base.DatabaseName:=AppPath+'data\alko_one.gdb' else // здесь жестко
прописанный локальный Path
  Base.DatabaseName:=iniData.BasePath; // а здесь может быть и
192.168.0.1:c:\FB2\alko_one.gdb
  Base.Connected:=true;
  if not trR.InTransaction then trR.StartTransaction;
  ResetAllGen;
end;

Собственно, здесь описан механизм выбора "локально-сетевой".

> P.S. Сорри за глупый вопрос - это моя первая попытка заюзать FB embedded.
> Похоже придется менять коней на переправе и забыть о Firebird, как о
> локальной БД :-(

А вот это для местных совсем не интересно. Программирование - это адов
труд.
Иногда лучше торговать пивом :-)

GSTAT в FB 2.01

2007-05-08 Пенетрантность Кузнецов Евгений



Доброго времени суток!

Обнаружил некоторые странности в работе GSTAT в 2.0.1.12855

Что есть
Win2k SP4 + Update Rollup
IB 4.2.1 на порту 3050
FB 1.5.4 на 3070
FB 2.0.1 на 3100
FB 1.5.4 и FB 2.0.1 запущены как сервисы (сервис FB 2.0.1 проходит под
именем FirebirdServer201)
В реестре прописаны только сервисы, ветку Firebird Project хоронил.
В System32 лежит gds32.dll от FB 1.5.3, но влияния на проблему не оказывает.

Окопался (DatabaseAccess = None), в aliases.conf указал
employee = c:\Program
Files\Firebird\Firebird_2_0\examples\empbuild\EMPLOYEE.FDB

Пробую получить статистику. Первой неожиданностью стала чувствительность
localhost к регистру
gstat -h Localhost:employee
возвращает
"Не удается найти указанный файл."
Ну ладно, все равно gstat -h запущенного сервера не требует, можно имя
хоста не указывать.
Но вот чтобы получить статистику data and index pages для IBAnalyst уже
нужно соединение с сервером. Пробую
gstat -a localhost/3100:employee - "Не удается найти указанный файл.",
хотя в gstat от FB 1.5 указание порта воспринимается нормально

Хорошо, пусть
gstat -a localhost:employee
В конце пишет
Database file sequence:
File c:\Program
Files\Firebird\Firebird_2_0\examples\empbuild\EMPLOYEE.FDB is the only file
Access to database "C:\PROGRAM
FILES\FIREBIRD\FIREBIRD_2_0\EXAMPLES\EMPBUILD\EMPLOYEE.FDB" is denied by
server administrator

Вроде бы должен ругаться на unavailable database? IB 4.2.1 shutdown я
уже делал, не помогает.

В трекере подобных багов не обнаружил.
В RN нашел только
(CORE-959) gstat would not work using the localhost connection string.
Since v1.5, it has been possible to run gstat using a pseudo-remote
connection string (localhost:) but it
was broken in v2.0.

Кто-нибудь сталкивался с подобным? Это действительно ошибка в gstat, или
виноват я сам со своим зоопарком?

P.S. -user, -password я, конечно, указываю, но до их проверки дело, 
похоже, не доходит


С уважением, Евгений

Re[2]: Втроник перед 9

2007-05-08 Пенетрантность Max Rezanov


Hello Boulitchev,

Tuesday, May 8, 2007, 4:11:08 PM, you wrote:
>> http://stfw.ru/page.php?id=4812
BA> не те газеты читаете :)
BA> http://www.idiot.ru/2007/05/08/segodnya-slushaet-on-dzhaz/#comments

Уффф!!!
Ну слава богу :




  Тема Дня: Ты, pабота, нас не бойся, мы тебя не тpонем.
  До не скорой встречи в аду,
 Maxmailto:[EMAIL PROTECTED]

Re: vldb


"Dmitri Kuzmenko" ...
>
> Hello, Roman!
>
> Roman Rokytskyy wrote:
>
> > 1. убиваем первый хост (напр. вырубаем питание)
> >
> > 2. после рестарта смотрим на отличия в состояниях базы на первом и
> > втором хостах. Есть отличия - наиболее вероятно идет асинхронное
> > копирование. Нет отличий - синхронное.
>
> да не будет отличий. я зуб не дам, но механика должна быть та
> же самая что и у nbackup - на время копирования файл базы лочится
> и не модифицируется.

Насколько я понял, не так. БД модифицируется как и раньше, но предыдущие
образы страниц (до их модификации) сначала идут в отдельный файл из которого
попадают в дамп

-- 
Хорсун Влад

Re: vldb

ребята, вы пытаетесь пристебать почти ненужную функциональность.
Почему?
Потому что, допустим у вас база 50 гиг.
И на нормальных дисках она копируется 10 минут.
Если больше, то вы сами себе строите проблемы.

Дальше. Допустим, даже последующие инкременты имеет такой же размер,
то есть 50 гиг.
Буквально восстановление такой БД ЦЕЛИКОМ из бэкапа 0 и инкрементов
займет 20-25 минут. Вы пытаетесь сократить это время до 10 минут.

Я понимаю, что это может быть важно, но не могу избавиться
от сомнений по этому поводу.

я в н-бакапах человек темный, глянул вроде хорошо, ан нет работает не так,
как я думал

сейчас покурю время восстановления бд из бакапа уровня 0

таки имеет смысл при большой БД и ма-а-а-леньких инскрементах.

есть ли смысл -use_all_space (NO_RESERVE) для баз с редкими update и
исключительно редкими delete?

--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb

Hello, Roman!

Roman Rokytskyy wrote:

1. убиваем первый хост (напр. вырубаем питание)

2. после рестарта смотрим на отличия в состояниях базы на первом и
втором хостах. Есть отличия - наиболее вероятно идет асинхронное
копирование. Нет отличий - синхронное.

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

насчет shadow - может быть, но я нынче ей уже не фанат :-)

"сэр, вы просто не умеете их готовить! (c)"

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

У меня конечно знания исключительно теоретические, но задницей чуствую,
что на нем можно очень неплохой hot standby. Вопрос только в том, нужно
ли это пользователям.

hot не получается. сервак надо останавливать все равно. а в случае
ресета "недопись" что в базе, что в shadow приведет к одинаковым
результатам.

Вообще, конечно, механизма "тиражирования" изменений в онлайне
на другой сервер кроме как shadow + nfs нет (у нас).

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Втроник перед 9




http://stfw.ru/page.php?id=4812


не те газеты читаете :)

http://www.idiot.ru/2007/05/08/segodnya-slushaet-on-dzhaz/#comments


--
Булычев Алексей
http://www.stella-npf.ru

Off: Втроник перед 9

2007-05-08 Пенетрантность Max Rezanov


Hello All,

Tuesday, May 8, 2007, 11:08:13 AM, you wrote:

Походу совсем плохо с головами у уродов

http://stfw.ru/page.php?id=4812



  Тема Дня: Попpобуй "Ку", "Ку", попpобуй "Ы-ку", "Ы-ку"
  До не скорой встречи в аду,
 Maxmailto:[EMAIL PROTECTED]

Re: Непонятная проблема с FB2


"sasha" ...
>
> > Гм, ты вроде не первый день в танке, а тут на броневик вылез ;)
>
> Там фигня ж в том что в оригинальном запросе был ORDER BY и что другое я
> мог подумть сходу? Не ту ошибку сервер валит таки, не ту ...

Тебе добавить номер BLR-контекста данной сортировки ? :)))

-- 
Хорсун Влад

Re: Непонятная проблема с FB2




Гм, ты вроде не первый день в танке, а тут на броневик вылез ;)


Там фигня ж в том что в оригинальном запросе был ORDER BY и что другое я 
мог подумть сходу? Не ту ошибку сервер валит таки, не ту ...

Re: Непонятная проблема с FB2




Да, пробуй, - блобы ведь со строками взаимозаменяемы ;)


Работает, слава богу и всем кто это делал :-)

Не удобно, конечно, что нельзя домену сделать ALTER из VARCHAR в BLOB 
TEXT и чтобы оно само всё переделалось/перестроилось как надо :-)

Re: vldb

2007-05-08 Пенетрантность Roman Rokytskyy

И еще (правда, тут я могу очень! ошибаться) online dump все-же
асинхронный. То-есть возврат из ф-ции записи страницы на диск не
привязан к результату передачи этой же страницы по сети на удаленный
сервер. Если по какой-то причине ОС не даст достаточно квантов времени

не, Борланд рекомендует и дамп и архивы журнала через сеть делать.
Деталей реализации не знаю, но у онлайн-дампа в конце происходит
"накат" измененных за время копирования страниц (page appendix file).

Идея для теста (если время и желание будет):

0.(а) имеем два хоста, на одном активно апдейтится база (нужно часто
делать commit, но не слишком часто - так, чтоб в транзакции
модифицировалось несколько страниц). сервер работает с приоритетом above
normal.

0.(б) На приоритете normal крутится какая-то фигня, которая жрет весь
CPU что ей дают.

0.(в) На приоритете below normal крутится gbak, который реплицирует базу
на соседнюю машину.

1. убиваем первый хост (напр. вырубаем питание)

насчет shadow - может быть, но я нынче ей уже не фанат :-)

"сэр, вы просто не умеете их готовить! (c)"

Re: Re[4]: Vista, блин

2007-05-08 Пенетрантность Yuris W. Auzinsh


"Yuris W. Auzinsh" ...
> Здравствуйте, Vlad Horsun.
>
> Недавно (2 мая 2007 г., 18:13:27) Вы писали:
>
> VH> Или пускай как службу, или дай юзеру SeCreateGlobalPrivilege
> Почему  низя  сразу  проверить  все  необходимые  привилегии  и  права
> необходимые для полноценной работы сервера?
>
> Или это бантики и они будут потом?

Ну вот нету у юзера привилегий (а они нужны) - что делать ?

Отказаться от сущ. механизма, который требует этих привелегий,
нельзя, т.к. можно поломать БД, а переделать на другой не так просто.

-- 
Хорсун Влад

Re[4]: Vista, блин

Здравствуйте, Vlad Horsun.

Недавно (2 мая 2007 г., 18:13:27) Вы писали:

VH> Или пускай как службу, или дай юзеру SeCreateGlobalPrivilege
Почему  низя  сразу  проверить  все  необходимые  привилегии  и  права
необходимые для полноценной работы сервера?

Или это бантики и они будут потом?

-- 
  Удачи...
   
   Yuris W. Auzinsh aka Zuz,
   ICQ UIN: 5 8 2 5 6 3 7 4,
   e-mail : zuz(аt)mail.ru



--~--~-~--~~~---~--~~
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы 
"gmane.comp.db.firebird.russian" на группах Google.
 Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ru-firebird@googlegroups.com
 Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: [EMAIL 
PROTECTED]
 Дополнительные варианты находятся на странице группы 
http://groups.google.com/group/ru-firebird?hl=ru
-~--~~~~--~~--~--~---

Re: vldb



Hello, Roman!

Roman Rokytskyy wrote:

И еще (правда, тут я могу очень! ошибаться) online dump все-же 
асинхронный. То-есть возврат из ф-ции записи страницы на диск не 
привязан к результату передачи этой же страницы по сети на удаленный 
сервер. Если по какой-то причине ОС не даст достаточно квантов времени 


не, Борланд рекомендует и дамп и архивы журнала через сеть делать.
Деталей реализации не знаю, но у онлайн-дампа в конце происходит
"накат" измененных за время копирования страниц (page appendix file).

насчет shadow - может быть, но я нынче ей уже не фанат :-)

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb

2007-05-08 Пенетрантность Alex Cherednichenko


"Boulitchev Aleksey" ...
>
> >> что значит "только максимального"?
> >
> >Если накатывали инкременты уровня 1, 2 и 3 то потом накатывать можно
> > или уровень 4
>
> >или новый уровень 3, основанный на последнем накаченном
> > уровне 2.
>
> гонишь?

пАчему ? Или это не нужно ? :)

> >> с историей восстановления - легко делается накат след. уровня.
>
> читать: только след уровня

Для этого у нас уже сейчас всё есть

> >И в результате легко получаем кашу в БД, причём проверить это
> > в процессе рестора невозможно. Давай текстовые файлики на этой
> > оптимистической ноте забудем навсегда
>
> я всегда был против aliases.conf и firebird.conf !

Сотри их отовсюду :)

-- 
Хорсун Влад

Re: Непонятная проблема с FB2


Привет, Horsun!
Вы пишешь  08 мая 2007:

[Sorry, skipped] 
 HV> Гм, ты вроде не первый день в танке, а тут на броневик вылез ;)

В мемориз! (С)  :)))

--
With best regards, Alex Cherednichenko.

Re: Непонятная проблема с FB2

2007-05-08 Пенетрантность Dmitry Yemanov



sasha wrote:


А что такого? По твоему в сервере всё в поряде?


Абсолютно.

Вы ведь говорили что 
блобы заменят строки


А индексные ключи заодно растянутся до десятков гигабайт? В сад.


--
Дмитрий Еманов

Re: Непонятная проблема с FB2


"Dmitry Yemanov" ...
>
> Horsun Vlad wrote:
> >
> > Никогда они не сортировались
>
> Сортировались, увы. По BlobID :-)

Я в курсе ;)

-- 
Хорсун Влад

Re: Непонятная проблема с FB2


"sasha" ...
>
> > Никогда блобы не будут сортироваться. В сервере в этом плане всё в 
> > порядке
>
> Ну а хотя бы индкс по SUBSTRING для блоба я смогу построить? Для
> варчаров у меня так везде есть.

Да, пробуй, - блобы ведь со строками взаимозаменяемы ;)

> > Да
>
> Это ты знаешь, а со стороны оно не кажется логичным.

Гм, ты вроде не первый день в танке, а тут на броневик вылез ;)

-- 
Хорсун Влад

Re: vldb




что значит "только максимального"?


   Если накатывали инкременты уровня 1, 2 и 3 то потом накатывать можно
или уровень 4



или новый уровень 3, основанный на последнем накаченном
уровне 2.


гонишь?


с историей восстановления - легко делается накат след. уровня.


читать: только след уровня


   И в результате легко получаем кашу в БД, причём проверить это
в процессе рестора невозможно. Давай текстовые файлики на этой
оптимистической ноте забудем навсегда


я всегда был против aliases.conf и firebird.conf !

--
Булычев Алексей
http://www.stella-npf.ru

Re: Непонятная проблема с FB2




Никогда блобы не будут сортироваться. В сервере в этом плане всё в порядке


Ну а хотя бы индкс по SUBSTRING для блоба я смогу построить? Для 
варчаров у меня так везде есть.



Да


Это ты знаешь, а со стороны оно не кажется логичным.

Re: Непонятная проблема с FB2

2007-05-08 Пенетрантность Dmitry Yemanov



Horsun Vlad wrote:


Никогда они не сортировались


Сортировались, увы. По BlobID :-) Щаз я это прикрыл.


--
Дмитрий Еманов

Re: vldb




ребята, вы пытаетесь пристебать почти ненужную функциональность.
Почему?
Потому что, допустим у вас база 50 гиг.
И на нормальных дисках она копируется 10 минут.
Если больше, то вы сами себе строите проблемы.

Дальше. Допустим, даже последующие инкременты имеет такой же размер,
то есть 50 гиг.
Буквально восстановление такой БД ЦЕЛИКОМ из бэкапа 0 и инкрементов
займет 20-25 минут. Вы пытаетесь сократить это время до 10 минут.

Я понимаю, что это может быть важно, но не могу избавиться
от сомнений по этому поводу.


я в н-бакапах человек темный, глянул вроде хорошо, ан нет работает не так, 
как я думал

сейчас покурю время восстановления бд из бакапа уровня 0

--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb


"Boulitchev Aleksey" ...
>
> >> портить-то  надо только NBACKUP, ну может чуть ODS продвинуть до списка
> >> страниц, попорченных со времени последнего NBACKUPa  :)
> >
> >Если не заморачиваться с доступностью stalled БД в read-only
> > режиме и накатывать инкременты только максимального уровня, то
> > действительно - достаточно менять только nbackup
>
> текстовые файлики рулят :)

Храните в них свои данные ;)

> что значит "только максимального"?

Если накатывали инкременты уровня 1, 2 и 3 то потом накатывать можно
или уровень 4 или новый уровень 3, основанный на последнем накаченном
уровне 2.

Последнее утверждение ещё требует доосмысления, возможно только 4-ый
уровень можно будет накатить, я детально не проверял ещё.

> с историей восстановления - легко делается накат след. уровня.

И в результате легко получаем кашу в БД, причём проверить это
в процессе рестора невозможно. Давай текстовые файлики на этой
оптимистической ноте забудем навсегда

-- 
Хорсун Влад

Re: Непонятная проблема с FB2




Мамаша, вы будете смеяться, но таки да! (С)
Ибо так устроен DISTINCT


Мне как человеку не знакомому с кодом это кажется странным. Сразу 
возникают вопросы:


1) зачем сортировать значения, а не их хеши например (например 
складывать все ключи во что-то типа Distionary> где б 
на каждый хеш хранились все варианты значений


2) Сообщение не в тему

3) Я посмотрел - в 2.0 DISTINCT глотается на ура и ничего не делает. Баг 
получается.

Re: Непонятная проблема с FB2

2007-05-08 Пенетрантность Alex Cherednichenko


"sasha" ...
>
> > Головом думать надо, перед тем как писать репорты. Хвастунову пиши...
>
> А что такого? По твоему в сервере всё в поряде? Вы ведь говорили что
> блобы заменят строки, а что мы имеем в этом случае.

Никогда блобы не будут сортироваться. В сервере в этом плане всё в порядке

> Я упростил запрос до
>
> select distinct RDB$TRIGGER_SOURCE from RDB$TRIGGERS
>
>
> 1) Я тут где-то что-то сортирую?

Да

> 2) Даже если бы хотел сортировать, то это как-то не вяжется с идеей
> полной замены строк на блобы, т.к. RDB$TRIGGER_SOURCE BLOB SUB_TYPE TEXT
> CHARACTER SET UNICODE_FSS.

Если бы была идея _полной_ замены то или строки, или блобы стали бы
вообще не нужны. Не нужно фанатизма :)

> PS Хвастунову я напишу отдельно.

Угу, его тряси

-- 
Хорсун Влад

Re: Непонятная проблема с FB2


Привет, sasha!
Вы пишешь  08 мая 2007:

 s> Я упростил запрос до
 s> select distinct RDB$TRIGGER_SOURCE from RDB$TRIGGERS
 s> 1) Я тут где-то что-то сортирую?

Мамаша, вы будете смеяться, но таки да! (С)
Ибо так устроен DISTINCT

--
With best regards, Alex Cherednichenko.

Re: vldb




портить-то  надо только NBACKUP, ну может чуть ODS продвинуть до списка
страниц, попорченных со времени последнего NBACKUPa  :)


   Если не заморачиваться с доступностью stalled БД в read-only
режиме и накатывать инкременты только максимального уровня, то
действительно - достаточно менять только nbackup


текстовые файлики рулят :)

что значит "только максимального"?

с историей восстановления - легко делается накат след. уровня.

--
Булычев Алексей
http://www.stella-npf.ru

Re: Непонятная проблема с FB2




Головом думать надо, перед тем как писать репорты. Хвастунову пиши...


А что такого? По твоему в сервере всё в поряде? Вы ведь говорили что 
блобы заменят строки, а что мы имеем в этом случае.


Я упростил запрос до

select distinct RDB$TRIGGER_SOURCE from RDB$TRIGGERS


1) Я тут где-то что-то сортирую?
2) Даже если бы хотел сортировать, то это как-то не вяжется с идеей 
полной замены строк на блобы, т.к. RDB$TRIGGER_SOURCE BLOB SUB_TYPE TEXT 
CHARACTER SET UNICODE_FSS.


PS Хвастунову я напишу отдельно.

Re: vldb


"Dmitri Kuzmenko" ...
>
> Hello, Vlad!
>
> Horsun Vlad wrote:
>
> > Хотя... у нас есть RDB$BACKUP_HISTORY, в которой вроде должны быть
> > необходимые нам записи о бекапах предыдущего уровня... Нужно ещё покурить
> > эту тему ;)
>
> я тебе больше скажу. этот бэкап-хистори надо чистить.

Зачем ? И это вроде не запрещено : хочешь - чисти сам.

> поэтому
> получается, что при первом коннекте к БД сервер должен проверять
> наличие бэкапов и отсутствующие килять.

С какой стати ?

> Иначе через некоторое время таблица сильно вырастет, а ее
> надо будет как-то чистить.

Не смеши мои тапочки :) Лучше научиться TIP чистить :)

-- 
Хорсун Влад

Re: vldb


"Boulitchev Aleksey" ...
> >Вот сейчас придёт злобный Еманов и похерит это всё до 3.х ;)
>
> портить-то  надо только NBACKUP, ну может чуть ODS продвинуть до списка
> страниц, попорченных со времени последнего NBACKUPa  :)

Если не заморачиваться с доступностью stalled БД в read-only
режиме и накатывать инкременты только максимального уровня, то
действительно - достаточно менять только nbackup

-- 
Хорсун Влад

Re: vldb



Hello, Janex!

Janex wrote:


И ешё мысль одна стукнула в голову - а незя ли сделать так
что при инкрементном бекапе идёт ешё проверка целостности бази ?
Хотя, например, неприсутствуют ли бытие индекси или
чтото другое битое ?


вряд ли. битые страницы (кривая "контрольная сумма") обнаруживаются
сервером и так. все остальное требует специального анализа,
например как это делает IBFirstAid. При этом повреждения на уровне
записей все равно не видны. Так что нафиг.
Сделал нбэкап уровня 0 - проверь на нем создание БД, и обычный
бэкап-рестор. О чем я в статье и написал.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb

Hello, Tonal!

Tonal wrote:

Соответственно рестор:
После бэкапа 0го уровня делаем "полурестор"
После бэкапа 1го уровня копируем последний "полурестор" 0го уровня и
накатываем на него дельту - получаем полурестор 1го уровня.
После бэкапа 2го уровня копируем последний "полурестор" 1го уровня и
накатываем на него дельту - получаем полурестор 2го уровня.

Я понимаю, что это может быть важно, но не могу избавиться
от сомнений по этому поводу.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Непонятная проблема с FB2


"sasha" ...
>
> >> isc_invalid_sort_datatype
> >> Низзя сортировать блобы
>
> Ага, учитывая то что в RDB$RELATION_CONSTRAINTS блобами и не пахнет и
> виноват похоже DISTINCT, напишу багрепорт...

Головом думать надо, перед тем как писать репорты. Хвастунову пиши...

-- 
Хорсун Влад

Re: vldb




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

Иначе через некоторое время таблица сильно вырастет, а ее
надо будет как-то чистить.


эта, оно при бакапе нулевого уровня должно килять все

--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb

2007-05-08 Пенетрантность Roman Rokytskyy

Таким образом, при наличии online dump и nbackup,
которые выполняются В ОНЛАЙНЕ и делают почти то же самое,
смысл в мороке с shadow отпадает напрочь.

Позволь не согласится.

Shadow позволяет зеркалировать также на сетевой диск (NFS), что при
гигабитной сети очень даже реальный вариант (отсылаю к Пешкову за
деталями). То-есть это тот же online dump, только вид сбоку. А если
добавить к инсталляции еще failure detector, который при крэше primary
перенаправит запросы на hot-standby, то получиться high-availability
solution.

Ну а если же передача страниц синхронная, то этот online dump ничем от
shadow не отличается - только вместо обычного NFS используется
собственный сетевой протокол.

Роман

Re: vldb



Hello, Vlad!

Horsun Vlad wrote:


Хотя... у нас есть RDB$BACKUP_HISTORY, в которой вроде должны быть
необходимые нам записи о бекапах предыдущего уровня... Нужно ещё покурить
эту тему ;)


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

Иначе через некоторое время таблица сильно вырастет, а ее
надо будет как-то чистить.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Непонятная проблема с FB2


"sasha" ...
>
> > isc_invalid_sort_datatype
> > Низзя сортировать блобы
>
> А как же так? В 2.0 можно было, а тут нельзя? Может там какой-то бажок
> закрался?

Никогда они не сортировались

-- 
Хорсун Влад

Re: vldb



Hello, freemanzav!

freemanzav wrote:


   Читать про ключ -N и про "механизмы работы" до просветления ;


Да, но только инкременты  не накатишь.


разумеется. кто мешает скопировать этот файл, и над ним делать
все что хочешь? У онлайн-дампа то же самое, примерно - если его
перевести в read/write, то "связь" с базой теряется и дальше
"накатывать" изменения на этот файл нельзя.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: ну, как бы перпая пятница сегодня на наделе. может баян.

2007-05-08 Пенетрантность Slava Ekimov



Да не может, а нескольколетний :-)

Re: vldb



Hello, Николай!

Николай Пономаренко wrote:


А доклады будут доступны?
Может в двух словах - что круто?
То, что ПОЛУЧИЛОСЬ, или ТО что получилось?


доклады должны быть выложены там же,
тем более что у Бартунова доклад в виде pdf.

а у него получился очень качественный
целиком настраиваемый настоящий полнотекстовый
поиск по БД. Жаль, что я не записывал аудио доклада.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb



Hello, Tonal!

Tonal wrote:


shadow уже не канает. не стоит оно того.


А можно подробнее почему?


shadow имеет два аспекта:

1. зеркалирование БД. С этим вполне справляется любой RAID1
2. возможность "украсть" shadow как копию БД. Но при этом
сервер просто обязательно выключать.

Кроме того, рестор ключом -k убивает существующие shadow,
даже если база ресторится на этом же сервере в файл
с другим именем.

Таким образом, при наличии online dump и nbackup,
которые выполняются В ОНЛАЙНЕ и делают почти то же самое,
смысл в мороке с shadow отпадает напрочь.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Непонятная проблема с FB2




isc_invalid_sort_datatype
Низзя сортировать блобы


Ага, учитывая то что в RDB$RELATION_CONSTRAINTS блобами и не пахнет и 
виноват похоже DISTINCT, напишу багрепорт...

Re: vldb



>Не. Текстовый файл это не наш путь. Тем более что вся информация у 
> нас

> есть
> в более доверенных источниках.

Квантовые коты?


   Обычные - я же написал что где лежит и как это взять.
Так что задача вполне решаема и не сложна


>Кто возьмётся это делать ? Там не много :)

Проще заплатить. У нас - дельфинарий.



   Вот сейчас придёт злобный Еманов и похерит это всё до 3.х ;)


портить-то  надо только NBACKUP, ну может чуть ODS продвинуть до списка 
страниц, попорченных со времени последнего NBACKUPa  :)



--
Булычев Алексей
http://www.stella-npf.ru

Re: Непонятная проблема с FB2




isc_invalid_sort_datatype
Низзя сортировать блобы


А как же так? В 2.0 можно было, а тут нельзя? Может там какой-то бажок 
закрался?

Re: vldb


"Boulitchev Aleksey" ...
>
> >Не. Текстовый файл это не наш путь. Тем более что вся информация у нас
> > есть
> > в более доверенных источниках.
>
> Квантовые коты?

Обычные - я же написал что где лежит и как это взять.
Так что задача вполне решаема и не сложна

> >Кто возьмётся это делать ? Там не много :)
>
> Проще заплатить. У нас - дельфинарий.

Вот сейчас придёт злобный Еманов и похерит это всё до 3.х ;)

-- 
Хорсун Влад

Re: vldb



   Не. Текстовый файл это не наш путь. Тем более что вся информация у нас 
есть

в более доверенных источниках.


Квантовые коты?


   Кто возьмётся это делать ? Там не много :)


Проще заплатить. У нас - дельфинарий.

--
Булычев Алексей
http://www.stella-npf.ru

Re: Непонятная проблема с FB2


"sasha" ...
>
> Привет!
>
> Я хожу экспертом в базу FB 2.1 клиентом от 2.0.
>
> В эксперте для представленирй есть штука под названием "Скрипт пересоздания"
>
> Когда я открываю эту вкладку, сервер обламывается на запросе
>
> select distinct A.RDB$CONSTRAINT_NAME,
> A.RDB$CONSTRAINT_TYPE,
> A.RDB$RELATION_NAME,
> C.RDB$TRIGGER_SOURCE,
> D.RDB$DEPENDED_ON_NAME
> from RDB$RELATION_CONSTRAINTS A, RDB$CHECK_CONSTRAINTS B, RDB$TRIGGERS
> C, RDB$DEPENDENCIES D
> where (A.RDB$CONSTRAINT_TYPE = 'CHECK') and
> (A.RDB$CONSTRAINT_NAME = B.RDB$CONSTRAINT_NAME) and
> (B.RDB$TRIGGER_NAME = C.RDB$TRIGGER_NAME) and
> (C.RDB$TRIGGER_TYPE = 1) and
> --(D.RDB$DEPENDED_ON_NAME = 'WBSPermissions') and
> (D.RDB$DEPENDENT_NAME = C.RDB$TRIGGER_NAME)
> order by A.RDB$RELATION_NAME, A.RDB$CONSTRAINT_NAME
>
> ошибка
>
> Firebird error.
> unknown ISC error 335544869.

isc_invalid_sort_datatype
Низзя сортировать блобы

> Собственно вопрос не только в том почему это, а ещё и в том где взять
> доку с кодами ошибок для 2.1. У меня есть документ
> fb_1_5_errorcodes.pdf, а есть ли где-то аналогичный для 2.1 ?

Будет в релизнотах.

-- 
Хорсун Влад

Непонятная проблема с FB2



Привет!

Я хожу экспертом в базу FB 2.1 клиентом от 2.0.

В эксперте для представленирй есть штука под названием "Скрипт пересоздания"

Когда я открываю эту вкладку, сервер обламывается на запросе

select distinct A.RDB$CONSTRAINT_NAME,
A.RDB$CONSTRAINT_TYPE,
A.RDB$RELATION_NAME,
C.RDB$TRIGGER_SOURCE,
D.RDB$DEPENDED_ON_NAME
from RDB$RELATION_CONSTRAINTS A, RDB$CHECK_CONSTRAINTS B, RDB$TRIGGERS 
C, RDB$DEPENDENCIES D

where (A.RDB$CONSTRAINT_TYPE = 'CHECK') and
(A.RDB$CONSTRAINT_NAME = B.RDB$CONSTRAINT_NAME) and
(B.RDB$TRIGGER_NAME = C.RDB$TRIGGER_NAME) and
(C.RDB$TRIGGER_TYPE = 1) and
--(D.RDB$DEPENDED_ON_NAME = 'WBSPermissions') and
(D.RDB$DEPENDENT_NAME = C.RDB$TRIGGER_NAME)
order by A.RDB$RELATION_NAME, A.RDB$CONSTRAINT_NAME

ошибка

Firebird error.
unknown ISC error 335544869.


Собственно вопрос не только в том почему это, а ещё и в том где взять 
доку с кодами ошибок для 2.1. У меня есть документ 
fb_1_5_errorcodes.pdf, а есть ли где-то аналогичный для 2.1 ?

Re: vldb


"Boulitchev Aleksey" ...
>
> >> C:\Databases> nbackup -R inventory.fdb
> >> inventory_0-Mar-2006.nbk -НЕДОРЕСТОР
> >>  >> inventory.restore.hist
> >>
> >> C:\Databases> nbackup -ПРОДОЛЖЕНИЕ inventory.restore.hist
> >> inventory_1-Mar-2006.nbk -НЕДОРЕСТОР >> inventory.restore.hist.2
> >
> >Ты меня не понял. Где гарантия, что inventory_1-Mar-2006.nbk это
> > инкремент 1-го уровня, сделанный именно от inventory_0-Mar-2006.nbk ?
>
> > А в твоей inventory.restore.hist нет заголовка с inventory_0.backup_guid.
> >
> >Теперь понятно ?
>
> inventory.restore.hist - текстовый файл
> -
> [level0]
> Backup_name=inventory_0.nbk
> GUID= 
> CHECKSUM= ..
> [level1]
> Backup_name=inventory_1.nbk
> GUID= 
> CHECKSUM= ..
> и все-все, что надо
> -
>
> вместо того, чтобы иметь всю информацию о наборе кусочков нбакапа, можно из
> оперативной памяти, положить ее в файлик и пользовать по мере надобности.

Не. Текстовый файл это не наш путь. Тем более что вся информация у нас есть
в более доверенных источниках.

Кто возьмётся это делать ? Там не много :)

-- 
Хорсун Влад

Re: vldb



C:\Databases> nbackup -R inventory.fdb 
inventory_0-Mar-2006.nbk -НЕДОРЕСТОР

 >> inventory.restore.hist

C:\Databases> nbackup -ПРОДОЛЖЕНИЕ inventory.restore.hist
inventory_1-Mar-2006.nbk -НЕДОРЕСТОР >> inventory.restore.hist.2


   Ты меня не понял. Где гарантия, что inventory_1-Mar-2006.nbk это
инкремент 1-го уровня, сделанный именно от inventory_0-Mar-2006.nbk ?



А в твоей inventory.restore.hist нет заголовка с inventory_0.backup_guid.

   Теперь понятно ?


inventory.restore.hist - текстовый файл
-
[level0]
Backup_name=inventory_0.nbk
GUID= 
CHECKSUM= ..
[level1]
Backup_name=inventory_1.nbk
GUID= 
CHECKSUM= ..
и все-все, что надо
-

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




--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb


"Boulitchev Aleksey" ...

> C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk -НЕДОРЕСТОР
>  >> inventory.restore.hist
>
> C:\Databases> nbackup -ПРОДОЛЖЕНИЕ inventory.restore.hist
> inventory_1-Mar-2006.nbk -НЕДОРЕСТОР >> inventory.restore.hist.2

Ты меня не понял. Где гарантия, что inventory_1-Mar-2006.nbk это
инкремент 1-го уровня, сделанный именно от inventory_0-Mar-2006.nbk ?

Когда мы имеем в одной команде оба
inventory_0-Mar-2006.nbk и inventory_1-Mar-2006.nbk

мы сравниваем inventory_0.backup_guid и inventory_1.prev_guid
(эти поля живут в заголовках бекапов)

А в твоей inventory.restore.hist нет заголовка с inventory_0.backup_guid.

Теперь понятно ?

Хотя вот возникла мысль искать inventory_0.backup_guid в RDB$BACKUP_HISTORY,
по идее там он есть. Это должен быть последний по времени бекап уровня 0.
Но для этого нужно как минимум разрешить работать с inventory.restore.hist в
read-only режиме и иметь запущенный и работающий сервер

-- 
Хорсун Влад

Re: vldb


"Horsun Vlad" ...
>
> "Dmitry Yemanov" ...
>
> > Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за
> > другим, если все они содержат дельту от уровня 2.
>
> Ну, каждая последующая дельта уровня 3 содержит в себе все изменения
> всех предыдущих дельт уровня 3, сделанных от одного и того же уровня 2.
> Так что в принципе это должно быть возможно, для этого stalled БД должна
> содержать в себе GUID'ы бекапов всех уровней, которые на неё накатывались.
> По одному для каждого уровня. Это даст возможность контролировать допустимость
> наката конкретной дельты. При переводе БД из stalled в normal режим эта
> инф-ция удаляется.

Хотя... у нас есть RDB$BACKUP_HISTORY, в которой вроде должны быть
необходимые нам записи о бекапах предыдущего уровня... Нужно ещё покурить
эту тему ;)

-- 
Хорсун Влад

Re: vldb

2007-05-08 Пенетрантность Andrei Yeryomin



WildSery пишет:

Но ведь ключ-то есть!  ;)


Уже почти нет.

--
С уважением,
 Андрей Еремин.

Re: Firebird и Ado.Net



А у меня с 64-битным фреймвёком никакой DDEX никуда не добавился :-(

Re: vldb



C:\Databases> nbackup -R inventory.fdb 
inventory_0-Mar-2006.nbk -НЕДОРЕСТОР


   Почему НЕДО ? Нормальный рестор ;)


потому что с БД запрещено работать, можно только восстанавливать дальше



C:\Databases> nbackup -R inventory.fdb 
inventory_1-Mar-2006.nbk -НЕДОРЕСТОР


C:\Databases> nbackup -R inventory.fdb inventory_2-Mar-2006.nbk


   Невозможно сейчас контролировать допустимость этих вот операций. 
Поэтому
всё делается одной командой : инф-ция о бекапах лежит в них самих и только 
имея

их все одновременно под рукой можно определить их совместность


ок

C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk -НЕДОРЕСТОР 
>> inventory.restore.hist


C:\Databases> nbackup -ПРОДОЛЖЕНИЕ inventory.restore.hist 
inventory_1-Mar-2006.nbk -НЕДОРЕСТОР >> inventory.restore.hist.2


C:\Databases> nbackup -ПРОДОЛЖЕНИЕ inventory.restore.hist.2 
inventory_2-Mar-2006.nbk



--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb


"Boulitchev Aleksey" ...
>
> >> Я про это :
> >> Ведь несложно же сделать хотя бы восстановление в уже
> >> существующий нулевой бэкап, чтобы избежать его копирования.
> >>
> >> А ты про что ?
> >
> > inventory_1-Mar-2006.nbk будет копироваться , а ведь его можно просто
> > переименовать.
>
> защита от дураков, видимо

Нет

> но что мешает сделать
>
> > C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk
> > inventory_1-Mar-2006.nbk inventory_1-Mar-2006_2.nbk
>
> C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk -НЕДОРЕСТОР

Почему НЕДО ? Нормальный рестор ;)

> C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk -НЕДОРЕСТОР
>
> C:\Databases> nbackup -R inventory.fdb inventory_2-Mar-2006.nbk

Невозможно сейчас контролировать допустимость этих вот операций. Поэтому
всё делается одной командой : инф-ция о бекапах лежит в них самих и только имея
их все одновременно под рукой можно определить их совместность

--
Хорсун Влад

Re: vldb


"Dmitry Yemanov" ...

> Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за
> другим, если все они содержат дельту от уровня 2.

Ну, каждая последующая дельта уровня 3 содержит в себе все изменения
всех предыдущих дельт уровня 3, сделанных от одного и того же уровня 2.
Так что в принципе это должно быть возможно, для этого stalled БД должна
содержать в себе GUID'ы бекапов всех уровней, которые на неё накатывались.
По одному для каждого уровня. Это даст возможность контролировать допустимость
наката конкретной дельты. При переводе БД из stalled в normal режим эта
инф-ция удаляется.

Со stalled БД также должна быть возможность работы в read-only режиме.

-- 
Хорсун Влад

Re: vldb




Я про это :
Ведь несложно же сделать хотя бы восстановление в уже
существующий нулевой бэкап, чтобы избежать его копирования.

А ты про что ?


inventory_1-Mar-2006.nbk будет копироваться , а ведь его можно просто
переименовать.


защита от дураков, видимо

но что мешает сделать


C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk
inventory_1-Mar-2006.nbk inventory_1-Mar-2006_2.nbk


C:\Databases> nbackup -R inventory.fdb inventory_0-Mar-2006.nbk -НЕДОРЕСТОР

C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk -НЕДОРЕСТОР

C:\Databases> nbackup -R inventory.fdb inventory_2-Mar-2006.nbk



--
Булычев Алексей
http://www.stella-npf.ru

Re: vldb


"freemanzav" ...
>
>
> Horsun Vlad:
> > "freemanzav" ...
> >
> > > Да, но только инкременты  не накатишь.
> >
> > Я про это :
> > Ведь несложно же сделать хотя бы восстановление в уже
> > существующий нулевой бэкап, чтобы избежать его копирования.
> >
> > А ты про что ?
>
> C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk
> inventory_3-Mar-2006.nbk inventory_3-Mar-2006_2.nbk
>
> inventory_1-Mar-2006.nbk будет копироваться , а ведь его можно просто
> переименовать.

Т.е. накат дельт на месте ? Такого нет.

Вообще все эти проблемы несколько надуманные, имхо. Делаем очередной бекап,
переносим его на резервный сервер, и тут же восстанавливаем свежую копию БД из
имеющихся там же инкрементов.
Это не будет работать только если очередной инкрементальный бекап создаётся
раньше, чем успевает восстановиться БД от предыдущего.

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

Это ко всем относится :)

-- 
Хорсун Влад

Re: vldb

2007-05-08 Пенетрантность freemanzav



Horsun Vlad:
> "freemanzav" ...
>
> > Да, но только инкременты  не накатишь.
>
> Я про это :
> Ведь несложно же сделать хотя бы восстановление в уже
> существующий нулевой бэкап, чтобы избежать его копирования.
>
> А ты про что ?

C:\Databases> nbackup -R inventory.fdb inventory_1-Mar-2006.nbk
inventory_3-Mar-2006.nbk inventory_3-Mar-2006_2.nbk

inventory_1-Mar-2006.nbk будет копироваться , а ведь его можно просто
переименовать.

Re: vldb


"freemanzav" ...

> Да, но только инкременты  не накатишь.

Я про это :
Ведь несложно же сделать хотя бы восстановление в уже
существующий нулевой бэкап, чтобы избежать его копирования.

А ты про что ?

--
Хорсун Влад

Re: vldb

2007-05-08 Пенетрантность freemanzav



Horsun Vlad:
> "freemanzav" ...
> >
> >
> > Horsun Vlad:
> > > "freemanzav" ...
> > >
> > > > Ведь несложно же сделать хотя бы восстановление в уже
> > > > существующий нулевой бэкап, чтобы избежать его копирования.
> > >
> > > А если таки доку до конца прочитать ?
> > А что, такая возможность появилась? Я читал
> > http://www.firebirdsql.org/manual/nbackup-backups.html,
> > нет там вроде такого.
>
> http://www.firebirdsql.org/manual/ru/nbackup-lock-unlock-ru.html
>
> Читать про ключ -N и про "механизмы работы" до просветления ;
Да, но только инкременты  не накатишь.

Re: vldb


"Horsun Vlad" ...
>
> "freemanzav" ...
> >
> >
> > Horsun Vlad:
> > > "freemanzav" ...
> > >
> > > > Ведь несложно же сделать хотя бы восстановление в уже
> > > > существующий нулевой бэкап, чтобы избежать его копирования.
> > >
> > > А если таки доку до конца прочитать ?
> > А что, такая возможность появилась? Я читал
> > http://www.firebirdsql.org/manual/nbackup-backups.html,
> > нет там вроде такого.
>
> http://www.firebirdsql.org/manual/ru/nbackup-lock-unlock-ru.html
>
> Читать про ключ -N и про "механизмы работы" до просветления ;

-F конечно, а не -N


-- 
Хорсун Влад

Re: vldb