Re: прочитал тут ветку про VLDB...

У меня база не VL. Но механизм быстрого восстановления присутствует. Ночной контрольный ресторе не убивается. И в случае проблем я могу просто влить в него все репликационные пакеты сначала дня (и те тоторые пришли из других баз, и выгруженные из этой). В зависимости от скорости пальцОв,

Re: �������� ��� ����� ��� VLDB... reload

ÎÁËÁÔÉÔØ ÐÏÓÌÅÄÎÉÅ ÉÚÍÅÎÅÎÉÑ ÎÁ ÐÏÓÌÅÄÎÉÊ ÂÜËÁÐ...ÂÙÌÏ ÂÙ ×ÓÅ ÚÁÍÅÞÁÔÅÌØÎÏ... ÔÏÅÓØ Ñ ÓËÌÏÎÑÀ Ë ÎÅÏÂÈÏÄÉÍÏÓÔÉ ×ÅÓÔÉ ÌÏÇÉÞÅÓËÕÀ ÄÅÌØÔÕ Ó ÍÏÍÅÎÔÁ ÐÏÓÌÅÄÎÅÇÏ ÂÜËÁÐÁ. × ÏÐÉÓÁÎÎÏÍ ÓÌÕÞÁÅ ÏÎÁ ÓÐÁÓÅÔ. Á ÓÕÝÅÓÔ×ÕÀÝÉÊ nbackup - ÆÉÚÉÞÅÓËÉÊ (ÔÏÅÓÔØ ×ÓÅ ÏÒÉÇÉÎÁÌØÎÙÅ ËÏÓÑËÉ ÐÅÒÅÎÅÓÕÔÓÑ). ËÒÏÍÅ ÔÏÇÏ × ×ÅÔËÅ ÐÒÏ VLDB

Re: прочитал тут ветку про VLDB... reload

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

Re: прочитал тут ветку про VLDB... reload

но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ слишком устаревший. его нельзя подложить вместо рабочей базы в работу, а только потом влить изменения. основная причина - ПОСЛЕДОВАТЕЛЬНОСТЬ логических событий в базе. нарушится причинно-следственная связь. (смотрели

Re[2]: прочитал тут ветку про VLDB... reload

Привет! вот вы все ссылаетесь на быстро-доступный ближайший бэкап... но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ слишком устаревший. Хуже всего вещь, которая не может сломаться - потому, что если она все-таки сломается, ее нельзя будет починить. (С) не помню

Re: прочитал тут ветку про VLDB... reload

On Wed, 23 May 2007 12:36:40 +0400, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Для того что бы восстановить данные не нужно знать последовательность их появления. +1 Ярким примером является бэкап-рестор :) -- Сергей Смирнов.

Re: прочитал тут ветку про VLDB... reload

W W On Wed, 23 May 2007 12:36:40 +0400, Kovalenko Dmitry W [EMAIL PROTECTED] wrote: W W Для того что бы восстановить данные не нужно знать последовательность W их появления. W W +1 W Ярким примером является бэкап-рестор :) тото он индексы Fk восстанавливает апосля -- С уважением Кочмин

Re: прочитал тут ветку про VLDB... reload

но понимаете, в некоторых случаях бэкап даже пятиминутной давности - УЖЕ слишком устаревший. его нельзя подложить вместо рабочей базы в работу, а только потом влить изменения. основная причина - ПОСЛЕДОВАТЕЛЬНОСТЬ логических событий в базе. нарушится причинно-следственная связь. (смотрели

Re: прочитал тут ветку про VLDB... reload

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

Re: прочитал тут ветку про VLDB... reload

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

Re: прочитал тут ветку про VLDB... reload

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

Re: прочитал тут ветку про VLDB... reload

Hello, Алексей! Кравченко Алексей wrote: суть в самой проблеме отсутствия online-механизмов их не может быть. ты вот предложил не менять базу на время ремонта. А откуда ты будешь ЧИТАТЬ поврежденные страницы или структуры данных? вот вы все ссылаетесь на быстро-доступный ближайший

Re: vldb

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

�������� ��� ����� ��� VLDB...

ËÁËÁÑ ÍÏÖÅÔ ÂÙÔØ ÒÅÞØ Ï VLDB... ËÁËÂÙ ÐÏËÁ ÐÏ×ÒÅÖÄÅÎÉÊ âä ÎÅÔ - ×ÓÅ ÈÏÒÏÛÏ É ÚÁÍÅÞÁÔÅÌØÎÏ... ÎÏ ËÏÇÄÁ ÓÌÕÞÁÅÔÓÑ ÐÏ×ÒÅÖÄÅÎÉÅ ÕÕÕ ÐÒÉ×ÅÄÕ Ó×ÏÊ ÐÒÉÍÅÒ... ËÏÍÕ ÌÅÎØ ÞÉÔÁÔØ - ÍÏÇÕÔ ÐÅÒÅÊÔÉ × ËÏÎÅÃ Ë òåúàíå ### ÏÂßÅÍ ÂÁÚÙ ÷óåçï 6 ÇÉÇÏ× (ÐÏ ÏÔÎÏÛÅÎÉÀ Ë VLDB - ÍÅÌÏÞÅ×ËÁ

Re: прочитал тут ветку про VLDB...

(по минимуму) было бы часа 3 а это - БОЛЬШОЙ простой ССЗБ ## РЕЗЮМЕ: на мой взгляд очень не хватает возможностей для ремонта, восстановления без отрыва от производства на мой взгляд перед тем, как иметь дело с VLDB, нужно таки поиметь соотв. железо, составить

Re: прочитал тут ветку про VLDB...

On Tue, 22 May 2007 16:44:20 +0400, Кравченко Алексей [EMAIL PROTECTED] wrote: дроп 7 индексов +60 мин Разве так бывает? :o -- Сергей Смирнов.

Re: прочитал тут ветку про VLDB...

отремонтированной, запустить 4) alter database end backup (влить дельту в базу) короче нехватает всяких там hot-фишек в сад. я понимаю, что я мало чего понимаю, ну вот хотелосьбы без этого FB нельзя подпускать к VLDB... это ваше железо нельзя к 6-ти гиговым базам подпускать. извините, если грубо, но

Re: прочитал тут ветку про VLDB...

на мой взгляд перед тем, как иметь дело с VLDB, нужно таки поиметь соотв. железо, составить нормальный план действий на случай сбоев, отработать его на стенде (!) и придерживаться его, а не метаться туда-суда Согласен. без этого FB нельзя подпускать к VLDB... VLDB никто не чинит

Re: vldb

Hello, Vlad! Dmitri Kuzmenko wrote: Дык это я со слов Todd'а в ответ тебе в b.p.i.g ;) все правильно. Механика именно такая. В IB2007UpdateGuide написано туманно, однако то, что при нехватке места в temp обламывается только online dump, говорит о том, что в page appendix file

Re: vldb

Hello, freemanzav! freemanzav wrote: И очень жаль. Ведь несложно же сделать хотя бы восстановление в уже существующий нулевой бэкап, чтобы избежать его копирования. нашел сравнение - эта операция похожа на gbak -r. которая в массе убивает базу. пусть даже некоторые ключом -r пользуются

Re: vldb

и нифиган у тебя не получится, потому что рестор нбэкап делает всегда целиком. то есть или только уровень 0 или 0+1 или 0+1+2 но никогда не 0+1, а потом +2. Т.е. никак не возможно сначала заресторить уровень 0, а потом на него накатить инкремент 1. Поэтому держать под рукой полуресторенный

Re: vldb

Boulitchev Aleksey wrote: отстой и дерьмище :( Спасибо большое. ну что стоило разбить восстановление на этапы? Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. -- Дмитрий Еманов

Re: vldb

On Tue, 08 May 2007 09:55:04 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote: И очень жаль. Ведь несложно же сделать хотя бы восстановление в уже существующий нулевой бэкап, чтобы избежать его копирования. нашел сравнение - эта операция похожа на gbak -r. которая в массе убивает базу. пусть

Re: vldb

Hi Dmitry Yemanov пишет: Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. Можно проблемму поподробнее? Если у нас есть бекап уровня 3 от 1.1.2007 и бекап уровня 3 от 1.2.2007, то тогда бекап от 1.2.2007 должен содержать все

Re: vldb

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

Re: vldb

freemanzav ... Ведь несложно же сделать хотя бы восстановление в уже существующий нулевой бэкап, чтобы избежать его копирования. А если таки доку до конца прочитать ? -- Хорсун Влад

Re: vldb

Dmitri Kuzmenko пишет: shadow уже не канает. не стоит оно того. А можно подробнее почему?

Re: vldb

отстой и дерьмище :( Спасибо большое. :) копирайт забыл поставить ну что стоило разбить восстановление на этапы? Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. неа. делаем бакап уровень 0 тут же начинаем его

Re: vldb

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

Re: vldb

Dmitry Yemanov пишет: Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. Например так: Пусть возможно держать базу в полуресторенном состоянии. Пусть в этом состоянии можно или накатить дельту следующего уровня, или перевести в

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

Dmitry Yemanov ... Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. Ну, каждая последующая дельта уровня 3 содержит в себе все изменения всех предыдущих дельт уровня 3, сделанных от одного и того же уровня 2. Так что в

Re: vldb

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

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

Re: vldb

WildSery пишет: Но ведь ключ-то есть! ;) Уже почти нет. -- С уважением, Андрей Еремин.

Re: vldb

Horsun Vlad ... Dmitry Yemanov ... Расскажи, как ты видишь накат на базу инкрементов уровня 3 один за другим, если все они содержат дельту от уровня 2. Ну, каждая последующая дельта уровня 3 содержит в себе все изменения всех предыдущих дельт уровня 3, сделанных от одного и того же

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 Ты меня не понял. Где гарантия, что

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 это

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 Ты меня не понял. Где гарантия,

Re: vldb

Не. Текстовый файл это не наш путь. Тем более что вся информация у нас есть в более доверенных источниках. Квантовые коты? Кто возьмётся это делать ? Там не много :) Проще заплатить. У нас - дельфинарий. -- Булычев Алексей http://www.stella-npf.ru

Re: vldb

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

Re: vldb

Не. Текстовый файл это не наш путь. Тем более что вся информация у нас есть в более доверенных источниках. Квантовые коты? Обычные - я же написал что где лежит и как это взять. Так что задача вполне решаема и не сложна Кто возьмётся это делать ? Там не много :) Проще

Re: vldb

Hello, Tonal! Tonal wrote: shadow уже не канает. не стоит оно того. А можно подробнее почему? shadow имеет два аспекта: 1. зеркалирование БД. С этим вполне справляется любой RAID1 2. возможность украсть shadow как копию БД. Но при этом сервер просто обязательно выключать. Кроме того,

Re: vldb

Hello, Николай! Николай Пономаренко wrote: А доклады будут доступны? Может в двух словах - что круто? То, что ПОЛУЧИЛОСЬ, или ТО что получилось? доклады должны быть выложены там же, тем более что у Бартунова доклад в виде pdf. а у него получился очень качественный целиком настраиваемый

Re: vldb

Hello, freemanzav! freemanzav wrote: Читать про ключ -N и про механизмы работы до просветления ; Да, но только инкременты не накатишь. разумеется. кто мешает скопировать этот файл, и над ним делать все что хочешь? У онлайн-дампа то же самое, примерно - если его перевести в read/write,

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

Hello, Janex! Janex wrote: И ешё мысль одна стукнула в голову - а незя ли сделать так что при инкрементном бекапе идёт ешё проверка целостности бази ? Хотя, например, неприсутствуют ли бытие индекси или чтото другое битое ? вряд ли. битые страницы (кривая контрольная сумма) обнаруживаются

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

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

Re: vldb

Hello, Vlad! Vlad Horsun wrote: Насколько я понял, не так. БД модифицируется как и раньше, но предыдущие образы страниц (до их модификации) сначала идут в отдельный файл из которого попадают в дамп Дык это я со слов Todd'а в ответ тебе в b.p.i.g ;) что-то я пропустил. В любом

vldb

Hello, All! Был я на Корпоративных СУБД 2007. Мед-пиво пил, на доклады ходил, а отчет не написал. И не напишу. Вместо этого по мотивам своего неудачного (с моей точки зрения) накатал статейку по поводу Больших Баз Данных. www.ibase.ru/devinfo/vldb.htm комментарии? -- Dmitri Kouzmenko,

Re: vldb

/vldb.htm DK комментарии? По моему скромному разумению, статья о новых методах backup-restore IB/FB, но никак не о VLDB, как таковых вааще. Отсюда и невосприятие аудиторией. -- With best regards, Alex Cherednichenko.

Re: vldb

www.ibase.ru/devinfo/vldb.htm комментарии? NBackup - бэкап уровня 0 не является базой, поэтому минимальное время восстановления равно времени воссоздания базы из имеющегося набора уровня 0 и инкрементов уровня 1, 2 и так далее. В обоих случаях обновление дампа или построение инкремента

Re: vldb

Hello, Alexey! Boulitchev Aleksey wrote: восстановление можно делать заблаговременно на резервный сервер и накатывать на него изменения по мере их поступления само-собой если не ошибаюсь, пцаны думают в сторону частичного чтения БД при создании инкремента поуа все туманно. нет ни слова

Re: vldb

Hello, Alex! Alex Cherednichenko wrote: DK www.ibase.ru/devinfo/vldb.htm DK комментарии? По моему скромному разумению, статья о новых методах backup-restore IB/FB, но никак не о VLDB, как таковых вааще. мне про vldb вообще нет никакого смысла писить или говорить. Отсюда и

Re: vldb

Hello, All! Был я на Корпоративных СУБД 2007. Мед-пиво пил, на доклады ходил, а кстати, вот чего торкнуло, так это доклад про новую, еще не внедренную в сервер систему полнотекстового поиска для PostgreSQL. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb

Dmitri Kuzmenko wrote: кстати, вот чего торкнуло, так это доклад про новую, еще не внедренную в сервер систему полнотекстового поиска для PostgreSQL. Чем торкнуло-то? Бартунов рассказывал? -- Дмитрий Еманов

Re: vldb

Привет! www.ibase.ru/devinfo/vldb.htm комментарии? Ну статейка вопросов не вызывает (именно по существу). Хотя я бы ее назвал обзорной, так как детальной информации там немного - по большей мере обитателям данной конфы более-менее знакомо все. Или так и задумывалось? -- Best regards,

Re: vldb

Прочитав статю, коментариев и доку про NBackup появился один интересныи (по краинеи мере мне :) )вопрос: Если при инкрементальном бекапе юзери работают и все изменения вносятся в делта фаил, то, например, запихнутые в базу записи во время бекапа выдни срацу юзеру (и другим после коммита) или

Re: vldb

Здравствуйте, Dmitri. Вы писали 7 мая 2007 г., 18:58:36: комментарии? Собственно, если дамп делается по сети на резервный сервер, то скорость восстановления такой БД почти равна нулю. Время восстановления равно нулю, а скорость - бесконечности :) По поводу NBackup - я его не щупал еще но

Re: vldb

Владимир Аксенов wrote: мы можем взять базу суточной давности и накатить на нее инкрементов за последние сутки, либо, если за последние сутки было логическое повреждение - накатить только часть инкрементов. Нельзя на базу накатывать инкременты. -- Дмитрий Еманов

Re: vldb

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

Re: vldb

Hello, Dmitry! Dmitry Yemanov wrote: кстати, вот чего торкнуло, так это доклад про новую, еще не внедренную в сервер систему полнотекстового поиска для PostgreSQL. Чем торкнуло-то? Бартунов рассказывал? он. круто получилось. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: vldb

Hello, Sergey! Sergey Mereutsa wrote: Ну статейка вопросов не вызывает (именно по существу). Хотя я бы ее назвал обзорной, так как детальной информации там немного - по большей мере обитателям данной конфы более-менее знакомо все. Или так и задумывалось? именно. детали по nbackup описаны в

Re: vldb

Hello, Dmitri! You wrote on Tue, 08 May 2007 09:42:35 +0400: кстати, вот чего торкнуло, так это доклад про новую, еще не внедренную в сервер систему полнотекстового поиска для PostgreSQL. Чем торкнуло-то? Бартунов рассказывал? DK он. круто получилось. А доклады будут доступны? Может в

Re: vldb

Hello, Владимир! Владимир Аксенов wrote: некоторое время назад. Можно этот shadow восстанавливать не сразу а с задержкой на сутки допустим - тогда в случае поломки основной базы мы можем взять базу суточной давности и накатить на нее инкрементов за последние сутки, либо, если за последние

Re: vldb

Hello, Freemanzav! freemanzav wrote: Нельзя на базу накатывать инкременты. И очень жаль. Ведь несложно же сделать хотя бы восстановление в уже существующий нулевой бэкап, чтобы избежать его копирования. это уже обсуждали. уровень 0 является базовой частью для кучи инкрементов 1, 2 и так