Здравствуйте, Horror_Infinity, Вы писали:
OLE>>Но это не _систематически_. H_I>Согласен. Но есть такие косяки не только у FB. Ты ведь именно это утверждаешь, что у правильных СУБД не бывает битых бэкапов.
Да где вы все такое утверждение увидели? Я говорю, что ФБ практически единственная СУБД, у которой эта проблема встречается постоянно.
H_I>Ни разу не видел кинутых пользователей... Нормально работают они при бэкапе...
Ээээ. Или я чегото не догоняю, или без лога транзакций реал-тайм бэкап невозможен. Данные просто посыпятся.
H_I>З.Ы. ИМХО до СВ уже скатились... Может, уже пора перенести?
Это не я. Это Пацак
Здравствуйте, OLEGus1, Вы писали:
П>>Ты хотел фичу — вот тебе фича. OLE>Нда уж...Крутая отмазка. Супераргументированная!
А отмаза "хочу чтоб была такая фича, но не буду использовать версию, где она есть" — сильно краше?
П>>При наличии битых страниц бэкап АФАИК попросту не сделается OLE>Еще как сделается. Со свистом.
Минимальный тест, приводящий к подобному крэшу с помощью обычного клиентского подключения — в студию!
OLE>Не _моментально_, а _гораздо быстрее_. Если сибейс, на аналогичной базе, бэкап делает на ходу и за несколько минут, а не часов — ты, наверное, удивишься.
Опаньки, вот так подмена понятий! Только что были бэкап и рестор, и вот уже только бэкап! Мило! Ну вернемся к старому обсуждению — какая тебе разница, сколько времени займет бэкап, если данные все равно будут актуальны на его начало? И не надо про лог транзакций — ему никто не мешает упасть вместе с базой.
П>>На столь любимом тобой постгресе OLE>Я не говорил что он столь мной любим.
Ты его советовал. Процитировать?
OLE>Руки? Мозги?
Зеркало?
OLE>Не само. После. Настройки. Написания. Кучи. Скриптов. Нормально. Чтоб. Работало. OLE>С ФБ такое не выйдет.
Выйдет.Только.Надо.Тоже.Подумать.Поработать.И.Настроить.
Пример Дмитрия Коваленко — выше по треду.
Здравствуйте, OLEGus1, Вы писали:
КД>>Наверное потому что видел как вылетает винт у рейда? OLE>Батенька! Да вы не те рейды используете!
Правда? Ой б#я, я так и знал, так и знал!
КД>>В отличии от невразумительных мычаний, я в состоянии вразумительно сформулировать понятие "сложная система" OLE>Ну давай. _Четкое_ (Не доспукающее неоднозначного трактования ни одного термина) определение сложной системы в студию.
Бисер метать? Перед кем?
КД>>Я это написал только для того, чтобы сказать, что есть реально действующая распределенная система в которых Firebird вполне справляется со своей задачей. Задачей управления базами данных. А не заменой мозгов людей, которым эти данные нужны. OLE>А понятие "стоимость сопровождения" что-нибудь говорит? Или это просто показать, что и запорожец может землю рыть?
Я смотрю, вы у нас специалист широчайшего профиля. Да, говорит.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>А я расскажу другую байку. Про безбашенного казла проектировщика, который перепутав коннекты в офигенном поделище ИБЭксперт , проверяя свои очередные гениальные мылсищи, задропал кучу гигантских таблиц.
Лучше расскажи про казла админа, который дал ему доступ к рабочей базе.
Здравствуйте, Пацак, Вы писали:
П>А отмаза "хочу чтоб была такая фича, но не буду использовать версию, где она есть" — сильно краше?
Версия и РК версии. Есть разница?
П>Только что были бэкап и рестор, и вот уже только бэкап! Мило!
Разница очень простая. Чтобы сибесовский бэкап не восстановился должно случиться чудо. Ну или, десйствительно, внештатная ситуация, тогда как с ФБ это обычное дело.
П>>>На столь любимом тобой постгресе OLE>>Я не говорил что он столь мной любим. П>Ты его советовал. Процитировать?
Вообщето это разные вещи.
OLE>>Руки? Мозги? П>Зеркало?
Мб мб.Но это опятьже нетипичная ситуация.
OLE>>Не само. После. Настройки. Написания. Кучи. Скриптов. Нормально. Чтоб. Работало. OLE>>С ФБ такое не выйдет.
П>Выйдет.Только.Надо.Тоже.Подумать.Поработать.И.Настроить.
Настроить что? Автооткидывание юзерей? Эффективное копирование по крону? Или запуск gbak? Это все _не спасет_ от невосстановимости
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>А я расскажу другую байку. Про безбашенного казла проектировщика, который перепутав коннекты в офигенном поделище ИБЭксперт , проверяя свои очередные гениальные мылсищи, задропал кучу гигантских таблиц.
П>Лучше расскажи про казла админа, который дал ему доступ к рабочей базе.
А ты расскажи про казла проектировщика, который обожает писать записки записку гену, про необходимость такого доступа.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Правда? Ой б#я, я так и знал, так и знал!
Рад помочь
КД>>>В отличии от невразумительных мычаний, я в состоянии вразумительно сформулировать понятие "сложная система" OLE>>Ну давай. _Четкое_ (Не доспукающее неоднозначного трактования ни одного термина) определение сложной системы в студию. КД>Бисер метать? Перед кем?
Так и запишем: не знаешь.
КД>>>Я это написал только для того, чтобы сказать, что есть реально действующая распределенная система в которых Firebird вполне справляется со своей задачей. Задачей управления базами данных. А не заменой мозгов людей, которым эти данные нужны. OLE>>А понятие "стоимость сопровождения" что-нибудь говорит? Или это просто показать, что и запорожец может землю рыть? КД>Я смотрю, вы у нас специалист широчайшего профиля.
Приходится. В нашей деревне узкие помирают с голода.
Здравствуйте, OLEGus1, Вы писали:
OLE>В ФБ? Каждый час? Это не смешно. Те каждый час кидаем юзерей на неопределенное время?
Потом опять будешь говорить "я все и сам знал?". Какая связь между бэкапом (который в FB представляет собой обычный коннект к базе и выполняется online) и "киданием юзерей на неопределенное время"?
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>В ФБ? Каждый час? Это не смешно. Те каждый час кидаем юзерей на неопределенное время?
П>Потом опять будешь говорить "я все и сам знал?". Какая связь между бэкапом (который в FB представляет собой обычный коннект к базе и выполняется online) и "киданием юзерей на неопределенное время"?
А теперь представь, что юзера при этом работают. Таблички там изменяют разные...
Здравствуйте, OLEGus1, Вы писали:
OLE>А ты расскажи про казла проектировщика, который обожает писать записки записку гену, про необходимость такого доступа.
Вот такая селяви: проектировщик у вас казел, админ казел, ген, очевидно, тоже казел, раз позволяет всяким казлам рыться в рабочей базе. А виноват в этом конечно Firebird.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>А ты расскажи про казла проектировщика, который обожает писать записки записку гену, про необходимость такого доступа.
П>Вот такая селяви: проектировщик у вас казел, админ казел, ген, очевидно, тоже казел, раз позволяет всяким казлам рыться в рабочей базе. А виноват в этом конечно Firebird.
Если ты не заметил, это был просто случай из жизни достойно соответствующим другому случаю из жизни (почитай тему выше), говорящий о том, что все вокруг Дмитрия, действительно идиоты. А он единственный граф Монте-Кристо в белом пальте, конечно же, всезнающий, с сундуком, набитым бисером, и не снисходящий к простым смертным, несмотря на все мольбы.
Ну а если для тебя это повод для очередной придирки... Ну что ж...
Здравствуйте, OLEGus1, Вы писали:
OLE>Версия и РК версии. Есть разница?
А что, РК принципиально неюзабилен? Если действительно очень надо?
П>>Только что были бэкап и рестор, и вот уже только бэкап! Мило! OLE>Разница очень простая. Чтобы сибесовский бэкап не восстановился должно случиться чудо.
И еще одна подмена понятий. Только что мы говорили о времени восстановления, и вот уже — о его вероятности.
П>>Ты его советовал. Процитировать? OLE>Вообщето это разные вещи.
Однако ФБ, который ты не любишь — ты не советовал.
OLE>Мб мб.Но это опятьже нетипичная ситуация.
Напротив. Скорее невосстановимый бэкап в ФБ — ситуация нетипичная. А тут — повторяется в 100 случаях из 100.
П>>Выйдет.Только.Надо.Тоже.Подумать.Поработать.И.Настроить. OLE>Настроить что?
Не настроить, а подумать и настроить. Тогда не возникнет нижеперечисленных вопросов.
OLE>Автооткидывание юзерей?
Нафиг не надо. Только не говори про "юзерей, которые таблички меняют" — читающая транзакция gbak им не помешает никоим образом.
OLE>Эффективное копирование по крону?
Как вариант, при использовании nbackup.
OLE>Или запуск gbak?
Да, с последующим тестовым восстановлением.
OLE>Это все _не спасет_ от невосстановимости
На 1.5 — это позволит отследить ее на ранней стадии, на 2.0 — спасет, см. механизм работы nbackup.
Здравствуйте, Пацак, Вы писали:
OLE>>Версия и РК версии. Есть разница? П>А что, РК принципиально неюзабилен? Если действительно очень надо?
Очень надо и продукт разные вещи. "Очень надо" — это обычный костыль. М$ часто такие вещи практикует.
П>И еще одна подмена понятий.
Нет подмены понятий. Есть простой и надежный механизм (сибес) бэкапа и восстановления (к слову сказать, ни разу не пришлось делать).
П>Однако ФБ, который ты не любишь — ты не советовал.
Для данной задачи-не советовал и не советую. Это не означает, что я не люблю ФБ, как и не означает, что я его люблю. ФБ инструмент, а инструмент надо использовать, там, где его применение оправдано.
П>Скорее невосстановимый бэкап в ФБ — ситуация нетипичная.
Люди даже утилиты шароварные пишут для восстановлении ФБ баз -значит очень типичная.
П>Только не говори про "юзерей, которые таблички меняют" — читающая транзакция gbak им не помешает никоим образом.
Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась.
П>Да, с последующим тестовым восстановлением.
Так и представляю... Набольшой базе процесс gbak и восстановления может занять не одни сутки вообщето.
П>На 1.5 — это позволит отследить ее на ранней стадии
Ранняя стадия-это от нескольких часов?
Ну и на фига мне подобные проблемы? В угоду разработчику?
[Sorry, skipped] П>> Однако ФБ, который ты не любишь — ты не советовал. O> Для данной задачи-не советовал и не советую. Это не означает, что я не люблю ФБ, O> как и не означает, что я его люблю. ФБ инструмент, а инструмент надо использовать, O> там, где его применение оправдано.
Инструментом надо владеть.
Скальпель в руках дилетанта есть гильотина!
П>>Только не говори про "юзерей, которые таблички меняют" — читающая транзакция gbak им не помешает никоим образом. OLE>Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась.
Поподробнее, пожалуйста:
— Как именно он их поменял?
— К чему это приведет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
OLE>>Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась. КД>Поподробнее, пожалуйста: КД>- Как именно он их поменял? КД>- К чему это приведет?
| TABLE1 |
PK| ID |
| NAME |
| TABLE2 |
PK| ID |
FK| IDTABLE1 |
| NAME |
Запущен процесс бэкапа. Одновременно пользователь работает с обоими таблицами (только не надо говорить что так не бывает).
TABLE1 попал в бэкап.
Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1
TABLE2 попал в бэкап.
Здравствуйте, OLEGus1, Вы писали:
OLE>TABLE1 попал в бэкап. OLE>Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>TABLE2 попал в бэкап.
Щас придеретесь, что пример не показателен.
Ладно: произошло:
insert into TABLE1
и insert into TABLE2
Здравствуйте, OLEGus1, Вы писали:
OLE>>>Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась. КД>>Поподробнее, пожалуйста: КД>>- Как именно он их поменял? КД>>- К чему это приведет?
OLE>
OLE> | TABLE1 |
OLE>PK| ID |
OLE> | NAME |
OLE> | TABLE2 |
OLE>PK| ID |
OLE>FK| IDTABLE1 |
OLE> | NAME |
OLE>
OLE>Запущен процесс бэкапа. Одновременно пользователь работает с обоими таблицами (только не надо говорить что так не бывает).
OLE>TABLE1 попал в бэкап. OLE>Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>TABLE2 попал в бэкап.
OLE>Ура!
О боже, парень, пиши еще !
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Ну вернемся к старому обсуждению — какая тебе разница, сколько времени займет бэкап, если данные все равно будут актуальны на его начало? И не надо про лог транзакций — ему никто не мешает упасть вместе с базой.
