Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Ты лучше поинтересуйся у него "что такое большие проекты ?"
Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все. Больше преимуществ нет.
Не хочу спорить с т. Пацаком в очередной раз. Мою мотивацию он уже знает.
Здравствуйте, OLEGus1, Вы писали:
КД>>Ты лучше поинтересуйся у него "что такое большие проекты ?" OLE>Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все. Больше преимуществ нет.
Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.
OLE>Не хочу спорить с т. Пацаком в очередной раз. Мою мотивацию он уже знает.
Здравствуйте, Пацак, Вы писали:
П>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий.
Классифицировать "крупность" проектов не берусь-требования очень разные.
П>Ага. "Я попробовал и мне не понравилось".
Не только "пробовал". Сопровождал довольно крупный продукт работающий с ФБ.
Здравствуйте, OLEGus1, Вы писали:
КД>>Ты лучше поинтересуйся у него "что такое большие проекты ?" OLE>Объясню. ФБ хорош как встраиваемая БД. Его преимущество относительно тогоже Оракля — отсутствие лимита на 4 гига. И все.
Это типа ответ на заданный вопрос
Низачот.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
П>>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий. OLE>Классифицировать "крупность" проектов не берусь-требования очень разные.
Однако при этом берешься классифицировать СУБД на "подходит/не подходит для крупного проекта" или "подходит/не подходит для биллинга", при этом не приводя никаких аргументов. Согласен с Дмитирием — сие не есть гут.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
П>>>Это 1) не так и 2) не ответ на вопрос, который задал Дмитрий. OLE>>Классифицировать "крупность" проектов не берусь-требования очень разные.
П>Однако при этом берешься классифицировать СУБД на "подходит/не подходит для крупного проекта" или "подходит/не подходит для биллинга"
Ты еще споришь про биллинг?
Или будешь спорить, что для описанной задачи ФБ лучший выбор?
В обоих случаях это не так.
Здравствуйте, OLEGus1, Вы писали:
OLE>Ты еще споришь про биллинг?
Что значит "еще"? В прошлый раз никакого спора не было — ты просто отставился кучей минусов и ушел от ответа.
OLE>Или будешь спорить, что для описанной задачи ФБ лучший выбор?
Мои основные требования к базам:
1) Наличие графического интерфейса администрирования
2) Возможность удаленного администрирования с Windows машины
3) Удобное управление Триггерами
4) Процедуры
5) Временные таблицы аля MSSQL — select * into #tmp
6) Ну а также желательно схожий синтакс sql с mssql
IBExpert
IBExpert + services
ХЗ что имелось в виду, управление триггерами ИМХО достаточно удобное
Имеются
Нет, но как правило успешно заменяются "селективными" процедурами
Привычка — дело наживное
Итого: критичных противоречий не вижу. Учитывая, что сейчас выбор идет между MySQL и Postgresql — Firebird в этом ряду вполне конкурентоспособен. Sybase хорош схожестью синтаксиса, но он платный, что автоматически переносит его в другую весовую категорию. И?
OLE>В обоих случаях это не так.
Здравствуйте, Пацак, Вы писали:
П>Итого: критичных противоречий не вижу. Учитывая, что сейчас выбор идет между MySQL и Postgresql — Firebird в этом ряду вполне конкурентоспособен.
Конкурентоспособен и не более. Postgresql таки пооптимальней будет, особенно если учесть:
Наша контора работает под MSSQL. В нем до 6 баз данных. В каждой из баз есть таблицы с кол-вом строк около миллиона. Работают с базами около 30 клиентских мест.
Сопровождать конструкцию на ФБ будет достаточно тяжело.
П>И как всегда — без аргументов.
Вспомним "правильные" бекапы?
И заодно отсутвие лога транзакций.
Здравствуйте, OLEGus1, Вы писали:
OLE>Конкурентоспособен и не более. Postgresql таки пооптимальней будет, особенно если учесть: OLE>
OLE>Наша контора работает под MSSQL. В нем до 6 баз данных. В каждой из баз есть таблицы с кол-вом строк около миллиона. Работают с базами около 30 клиентских мест.
OLE>Сопровождать конструкцию на ФБ будет достаточно тяжело.
Это правда, надорваться в такой ситуации очень легко.
Кстати, вчера меня просветили относительно еще одной неотъемлемой состоявляющей решения сложных систем. Оказывается кроме "Оракла, Юникса и Дорогого Адо" требуется еще "Гетерогенный Доступ". Вот так вот. Смешно? А я весь вечер просидел в задумчивости.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>Сопровождать конструкцию на ФБ будет достаточно тяжело.
Бездоказательная глупость. Сопровождают и поболее.
П>>И как всегда — без аргументов. OLE>Вспомним "правильные" бекапы?
Это те, которые тебе хотелось "по F5 но не по F5, через gbak но не через gbak, по cron'у но не по cron'у и чтоб все само собой ап, и сделалось" ? Не, лучше не надо — смешно же! Кстати специально для таких вот привередливых в FB теперь есть инкрементальный бэкап — радуйся.
OLE>И заодно отсутвие лога транзакций.
...который нафик не упал.
Еще раз — какие-нибудь серьезные претензии к применимости FB в данном конкретном случае будут? Или все так и останется на уровне "нельзя и точка"?
Здравствуйте, Пацак, Вы писали:
OLE>>И заодно отсутвие лога транзакций. П>...который нафик не упал. П>Еще раз — какие-нибудь серьезные претензии к применимости FB в данном конкретном случае будут?
Ну вот как с тобой говорить? Ты не выгодные для себя аргументы просто с негодованием отметаешь
Я сказал все, что хотел — решать человеку.
Здравствуйте, OLEGus1, Вы писали:
OLE>Ну вот как с тобой говорить? Ты не выгодные для себя аргументы просто с негодованием отметаешь
Та ты чо?! Ну давай расскажи про лог транзакций, без которого не может работать архикрупная БД аж из миллиона записей. Примеры приведи, анализ. А потом посмотрим.
Здравствуйте, Пацак, Вы писали:
П>Та ты чо?! Ну давай расскажи про лог транзакций, без которого не может работать
Работать может. Надежность снижается. И, в случае сбоя, восстанавливать сложнее.
П>архикрупная БД аж из миллиона записей.
Та ты чо?! А покажи, где сказано про то, что в базе есть миллион записей? Сказано:
В каждой из баз есть таблицы с кол-вом строк около миллиона
Вопрос: сколько таблиц в базе имеют миллион записей?
П>c бэкапом, судя по скипу, вопрос отпал?
Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива. И про то, как делать ф5 при неотключенной (использующейся) базе.
Здравствуйте, OLEGus1, Вы писали:
П>>Та ты чо?! Ну давай расскажи про лог транзакций, без которого не может работать OLE>Работать может. Надежность снижается.
А мужики-то не знают! Ну давай расскажи теперь как она снижается.
OLE>И, в случае сбоя, восстанавливать сложнее.
В случае физической порчи БД — практически однофигственно.
OLE>Вопрос: сколько таблиц в базе имеют миллион записей?
Да хоть все — каким боком тут лог транзакций? Он что, сильно зависит от таблиц с миллионом записей? А я грешным делом думал, что от количества записей, которые затрагивают транзакции.
OLE>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива.
Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то": Не лазить напрямую в метаданные кривыми ручонками.
Проверять (автоматически) сделанный бэкап на восстановимость
Юзать наряду с gbak'ом nbackup
И все! Ваши волосы тотчас же станут густыми и шелковистыми. (с) Но это конечно безумно сложная процедура — никак не под силу программисту "больших БД"!
OLE>И про то, как делать ф5 при неотключенной (использующейся) базе.
Покури уже наконец насчет инкрементального бэкапа, а то скучно с тобой разговаривать становится.
Здравствуйте, Пацак, Вы писали:
П>А мужики-то не знают! Ну давай расскажи теперь как она снижается. П>В случае физической порчи БД — практически однофигственно.
А давай вырубим серверок во время физической записи транзакции ФБ и, допустим, Postgre? А потом рассмотрим шансы и время на восстановление базы, максимально актуального состояния.
П>Да хоть все — каким боком тут лог транзакций? Он что, сильно зависит от таблиц с миллионом записей? А я грешным делом думал, что от количества записей, которые затрагивают транзакции.
Это условие тоже не оговорено в задаче. Какова активность транзакций? Ты не знаешь. А предполагаешь что-то свое. Причем заниженное.
OLE>>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива. П>Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то": П> П> Не лазить напрямую в метаданные кривыми ручонками. П> Проверять (автоматически) сделанный бэкап на восстановимость П> Юзать наряду с gbak'ом nbackup П>
Ты упустил еще один пункт:
— Не использовать ФБ в подобных задачах. Благо альтернатив полно.
OLE>>И про то, как делать ф5 при неотключенной (использующейся) базе. П>Покури уже наконец насчет инкрементального бэкапа, а то скучно с тобой разговаривать становится.
Я все это знаю. Но ты мне напоминаешь СГ в некоторых своих миссионерских порывах. Не всюду ФБ затычка.
Здравствуйте, OLEGus1, Вы писали:
OLE>А давай вырубим серверок во время физической записи транзакции ФБ и, допустим, Postgre? А потом рассмотрим шансы и время на восстановление базы, максимально актуального состояния.
Давай. Сперва о шансах: ты гарантируешь, что после этого база Postgresql самовосстановится в 100 случаев из 100? Если нет и произойдет таки физический краш — ты готов сравнить время восстановления из shadow/nbackup/gbak firebird и погзипленного скрипта постгреса?
OLE>Это условие тоже не оговорено в задаче. Какова активность транзакций? Ты не знаешь. А предполагаешь что-то свое.
Ты тоже. Причем в отличие от меня — совершенно неаргументированно и безапеляционно.
OLE>Ты упустил еще один пункт: OLE>- Не использовать ФБ в подобных задачах. Благо альтернатив полно.
Щастя нет — при достаточно малом радиусе кривизны рук (а чтоб при использовании FB не следовать поскипанным пунктам — он должен стремиться к нулю) можно заставить хреново работать любую СУБД (да и вообще любую сложную систему). Я знаю пример когда постгрес (который ты тут так усиленно расхваливаешь) полдня крутил restore базы данных, которая по идее должна быть online круглосуточно. И знаю другой пример, когда он посреди ночи выжрал 100% ресурсов и фактически застопорил работу системы, о чем стало известно только утром. Но я, в отличие от тебя, не кричу по любому поводу на весь форум "постгрес — г....", а стараюсь решать эти локальные проблемы локальными же средствами. И знаешь, как правило удается.
OLE>Я все это знаю.
То есть то, что ты тут пишешь — есть предумышленная провокация, расчитанная на неосведомленность оппонента? Круто, ничего не скажешь!
OLE>Но ты мне напоминаешь СГ в некоторых своих миссионерских порывах. Не всюду ФБ затычка.
Я, в отличие от, про "всюду" нигде не писал и не пишу. Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне, ничуть не хуже рассмотренных постгре и мускуля. А делать глобальные выводы на основании представления о сферических "больших БД" в вакууме — уволь, не тянет совершенно. Это уж как-нибудь сам.
Ку...
Re[14]: FireBird и все-все-все
От:
Аноним
Дата:
14.06.06 13:36
Оценка:
П>Я, в отличие от, про "всюду" нигде не писал и не пишу. Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне, ничуть не хуже рассмотренных постгре и мускуля. А делать глобальные выводы на основании представления о сферических "больших БД" в вакууме — уволь, не тянет совершенно. Это уж как-нибудь сам.
), оптимизатор кривой (cost based поломали теперь так и остался rule based), лога нет (drop table сделал и все никакие бэкапы не помогут, т.к. нельзя востановится на момент времени до сбоя) и т.п.
Здравствуйте, Пацак, Вы писали:
П>Но я, в отличие от тебя, не кричу по любому поводу на весь форум "постгрес — г....", а стараюсь решать эти локальные проблемы локальными же средствами. И знаешь, как правило удается.
Покажи, где я говорил, что ФБ — г....?
П>То есть то, что ты тут пишешь — есть предумышленная провокация, расчитанная на неосведомленность оппонента? Круто, ничего не скажешь!
Это не провокация. Это просто другое мнение, которое ты ну никак не хочешь признать, а только размахиваешь флагом. Но ведь есть проблемы в этой области. Ну признайся.
А руки... Если сопровождать закрытый софт... Ну и при чем тут руки то?
П>Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне
Здравствуйте, OLEGus1, Вы писали:
OLE>Покажи, где я говорил, что ФБ — г....?
Безаргументно говорить "не годится" — практически то же самое.
OLE>Это не провокация. Это просто другое мнение,
Какое нафик мнение? Ты либо прекрасно знал о функциях FB, которые могут решить твои проблемы и прикидывался незнающим (это в чистом виде провокация), либо не знал, а теперь делаешь вид, что знал (это неправда). И то и другое — весьма интересная манера вести диалог.
OLE>Но ведь есть проблемы в этой области. Ну признайся.
В какой "этой"? В области бэкапа? При грамотном его проведении — нет. При безграмотном — разумеется, и глупо ожидать другого.
OLE>А руки... Если сопровождать закрытый софт... Ну и при чем тут руки то?
Какое отношение имеет администрирование СУБД к открытости/закрытости софта? Закрытый софт не дает вам создать shadow или делать правильно бэкап базы?
П>>Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне OLE>А мое ИМХО-не подходит.
Oracle: null = ''
А>оптимизатор кривой (cost based поломали теперь так и остался rule based)
АФАИК cost based и не было никогда, а rule based именно в FB (не путать с IB) начал работать весьма неплохо. И опять же идеала нет — в том же постгресе при существовании cost based оптимизатора до недавнего времени существовал также и косяк, когда наличие с одной стороны связи, например, int4, а с другой int8 напрочь отрубало индекс в запросе и чтоб его включить обратно требовалось явное указание типа.
А>, лога нет (drop table сделал и все никакие бэкапы не помогут, т.к. нельзя востановится на момент времени до сбоя) и т.п.
Здравствуйте, Аноним, Вы писали:
П>>А она так или иначе везде есть. Нет идеальных программ, как ни крутись. А>но не в таких маштабах же !
Спорный вопрос. Косяки есть везде. Новая СУБД, на которую перешел со старой и привычной — первое время вообще кажется сплошным косяком. Постепенно привыкаешь...
П>>Oracle: null = '' А>да и это вопервых гораздо удобней, т.к. логично, а занчит меньше кода,
It depends, может быть и наоборот
А>а во вторых не противоречит ansi sql
Как раз-таки противоречит.
П>>Какое-то странное у тебя понимание бэкапа ИМХО А>почитай в оракловой документации какие бывают сбои (там хорошо разложено), fb похерит данные в 75% из описаных сбоев.
Да, но из бэкапа-то с какого перепуга их восстановить не удастся? Или под фразой "и никакие бэкапы не помогут" понималось что-то другое?
Пацак пишет:
> Да, но из бэкапа-то с какого перепуга их восстановить не удастся? Или > под фразой "и никакие бэкапы не помогут" понималось что-то другое?
Скорее всего имелось в виду восстановление на произвольный момент
времени, которое невозможно без лога. Даже при наличии страничного
инкрементального бэкапа (как в FB), восстановить можно будет только на
момент бэкапа. А если, к примеру, бэкап ночью, а восстановить надо на
момент времени 13:45? Разумеется, nbackup позволит при необходимости
значительно сократить интервалы между бэкапами, но превозносить
отсутствуие лога как великое преимущество — IMHO одно из проявлений
фанатизма.
Здравствуйте, alexgold, Вы писали:
A>Скорее всего имелось в виду восстановление на произвольный момент A>времени, которое невозможно без лога. Даже при наличии страничного A>инкрементального бэкапа (как в FB), восстановить можно будет только на A>момент бэкапа. А если, к примеру, бэкап ночью, а восстановить надо на A>момент времени 13:45? Разумеется, nbackup позволит при необходимости A>значительно сократить интервалы между бэкапами, но превозносить A>отсутствуие лога как великое преимущество — IMHO одно из проявлений A>фанатизма.
Да, спасибо, сразу не сообразил. Согласен, redo-лог в принципе штука полезная и насколько я знаю в планах у разработчиков FB есть. Хотя в случае аппаратных проблем ее и сейчас в какой-то степени может компенсировать shadow, а в случае предумышленных действий (типа упомянутой DROP TABLE) — достаточно частое использование nbackup. Да и саму ее как панацею рассматривать тоже вряд ли можно — аппаратные проблемы с винтом, на который пишется redo-лог не менее вероятны, чем с винтом базы. Более-менее надежную гарантию здесь даст только RAID. Так что хоть отсутствие подобного механизма и не "великое преимущество", но и очень уж страшным недостатком наверное считать его тоже не стоит. По крайней мере если сравнивать с предлагавшимися изначально MySQL и Postgres где restore АФАИК вообще выполняется исключительно из sql-скрипта.
OLE>>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива.
П>Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то": П> П> Не лазить напрямую в метаданные кривыми ручонками. П> Проверять (автоматически) сделанный бэкап на восстановимость
Че-то как-то несерьезно
П> Юзать наряду с gbak'ом nbackup
То же самое
П>П>И все! Ваши волосы тотчас же станут густыми и шелковистыми. (с) Но это конечно безумно сложная процедура — никак не под силу программисту "больших БД"!
Здравствуйте, Пацак, Вы писали:
П>Безаргументно говорить "не годится" — практически то же самое.
Ты отбрасываешь аргументы. А потом удивляешься.
OLE>>Это не провокация. Это просто другое мнение, П>Какое нафик мнение? Ты либо прекрасно знал о функциях FB, которые могут решить твои проблемы и прикидывался незнающим
Инкрементальный в 1.5?
А 2.0 RC по моему еще. Рабочие проекты на КС стремновато писАть.
П>И то и другое — весьма интересная манера вести диалог.
А твои постоянные переходы на личности тоже интересная манера. Про выкидывание аргументов уже говорил.
OLE>>Но ведь есть проблемы в этой области. Ну признайся. П>В какой "этой"? В области бэкапа? При грамотном его проведении — нет. При безграмотном — разумеется, и глупо ожидать другого. Не только бэкапа. И оптимизатора, и ваще организации хранилища.
OLE>>А руки... Если сопровождать закрытый софт... Ну и при чем тут руки то? П>Какое отношение имеет администрирование СУБД к открытости/закрытости софта? Закрытый софт не дает вам создать shadow или делать правильно бэкап базы?
Закрытый софт непонятно как с транзакциями работает, как результат-куча битых страничек в базе, и как следсвие невосстановимый бекап. От проверок на восстановимость проку мало, т.к. процесс бекапа и ресторе занимает продолжительное время. Актуальность упущена именно на это время.
П>>>Для данного конкретного случая при данных конкретных требованиях FB ИМХО подходит вполне OLE>>А мое ИМХО-не подходит. П> ограничившись перечислением проблем, решение которых, якобы, сам знал заранее.
Решение? Это не решение. Решение — это когда настроил и забыл. Как с сибейсом у меня было. А ФБ требует повышенного внимания.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, _d_m_, Вы писали:
П>>> Не лазить напрямую в метаданные кривыми ручонками. П>>> Проверять (автоматически) сделанный бэкап на восстановимость ___>>Че-то как-то несерьезно
П>Что именно?
Проверять бэкап на восстановимость. Это как это — сделанный бекап может не восстановиться? В каких еще СУБД такое возможно?
П>>> Юзать наряду с gbak'ом nbackup ___>>То же самое
П>Аналогично — что именно?
Использовать одновременно несколько программных средств для резервирования.
___>>Ну, здесь может помочь регулярное мытье волос
П>Именно его я и советую, а в ответ — "несерьезно".
Здравствуйте, _d_m_, Вы писали:
OLE>>>Ты мне так и не рассказал, что делать, когда база не может подняться из gbak-ного архива.
П>>Стреляться. Потому что надо было "что-то" делать до того. Перечень "чего-то": П>>[list=1] П>> Не лазить напрямую в метаданные кривыми ручонками. П>> Проверять (автоматически) сделанный бэкап на восстановимость
___>Че-то как-то несерьезно
Да, согласен, детский сад какой-то...
Да нет, даже хуже — детство с прогрессирующими параноидальными наклонностями.
И правда, чего это я, держа базу и бакапы на RAID5 из пяти винтов + три hotspare, делая ежедневные бакапы с копированием их на резервные серверы (с таким же пятым рейдом), за каким-то делаю еще и контрольный ресторе того чего я зарезервировал? Хм. Наверное потому что видел как вылетает винт у рейда? или видел как отказоустойчивый NTFS просто пишет, пишет, пишет, а потом просто не дает прочитать/удалить файл? А! Нет, наверное, потому что база хранит данные за 8 лет работы государственной конторы и о её стоимости лучше не думать?
Увы нет, просто вместо того, чтобы пространно рассуждать о проблемах администрирования Firebird-а, я потратил немного времени и написал нормальные скрипты администрирования. Слово "нормальные" расшифровывать надо? А то еще, грешным делом, подумаете о каком-то тривиальном батнике, запускаемом по расписанию.
А давайте теперь поговорим о надежности Firebird как такового. Да, надежность хреновая. Правда, когда я это говорю, почему-то думаю не о FB, а о IB5.6. Крушил базу с несчастными 70 тысячами записей. И когда мы на FB радикально перестроили базу с таблицами в которых было уже по несколько миллионов записей и база после этого осталась работоспособной, я это расцениваю как чистую случайность, соизмеримую с выигрышем в национальную лотерею. И когда, грубо говоря, без башенные казлы, из отдела сопровождения, начинают глумиться над базой во время активной работы сотни пользователей, а при этом еще не закончилась заливка пакетов репликации, мне тоже кажется, что скоро к нам придет добрый и пушистый зверь. Не, это все не так страшно. Страшно было, когда база децел выросла и сервер (я про железо) начало перегружаться при вполне нормальных 100% нагрузках на оба процессора и хорошей нагрузке на диски. Ну, работа у него такая. К сожалению, виноват оказался опять не FB. И не RAR, который спровоцировал перезагрузку сервера прямо среди бела дня. Увы. Виновного переустановили со всеми сервис паками, патчами и обновленными драйверами. Хотя, может виноваты были эти, рогатые, которые вытащили из сервера хреновину, улучшающую циркуляции воздуха над процессорами, и не поставили её назад — типа, зачем это она? Мешала добавлять очередные 4GB памяти в сервер. Короче, не догоняю — как оно до сих пор работает
И, особо ретивых, предупрежу сразу — не стоит ставить под сомнение уровень сложности самой базы данных и программного обеспечения, которое с ним взаимодействует... В отличии от невразумительных мычаний, я в состоянии вразумительно сформулировать понятие "сложная система" (хотя, скорее всего не глядя ткну в книгу, в которой есть нормальное определение) и привести конкретные примеры из своей практики проектирования, разработки и сопровождения такой системы. А также приведу примеры случаев, когда такие системы попадают в руки технического персонала не владеющего темой и как разруливать такие ситуации.
И на всякий случай, то что я тут написал не означает, что Firebird это панацея от всех болезней. Нет. Я это написал только для того, чтобы сказать, что есть реально действующая распределенная система в которых Firebird вполне справляется со своей задачей. Задачей управления базами данных. А не заменой мозгов людей, которым эти данные нужны.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>Инкрементальный в 1.5? OLE>А 2.0 RC по моему еще. Рабочие проекты на КС стремновато писАть.
Ты хотел фичу — вот тебе фича. Использовать ее или нет — это твоя личная проблема (люди RC пользуют и ничего — живы). Но говорить, что ее нет — это грешить против истины.
OLE> Не только бэкапа. И оптимизатора, и ваще организации хранилища.
И как всегда совершенно без каких-либо аргументов.
OLE>Закрытый софт непонятно как с транзакциями работает, как результат-куча битых страничек в базе, и как следсвие невосстановимый бекап.
При наличии битых страниц бэкап АФАИК попросту не сделается (причем полагаю, что не только в FB) — каким боком тут его восстановимость? И как можно добиться "кучи битых страниц" через "непонятно какую работу" с транзакциями — механизм не опишешь?
OLE>От проверок на восстановимость проку мало, т.к. процесс бекапа и ресторе занимает продолжительное время. Актуальность упущена именно на это время.
А что, где-то они выполняются моментально? На столь любимом тобой постгресе мы делали restore полдня, в течении которых система, которая должна работать круглосуточно, попросту стояла. Ты еще хочешь поговорить об актуальности?
OLE>Решение? Это не решение. Решение — это когда настроил и забыл.
Ага, только для этого надо сперва один раз настроить. А тебе, похоже, хочется чтоб все само заработало.
Здравствуйте, Пацак, Вы писали:
OLE>>А 2.0 RC по моему еще. Рабочие проекты на КС стремновато писАть. П>Ты хотел фичу — вот тебе фича. Использовать ее или нет — это твоя личная проблема (люди RC пользуют и ничего — живы)
Нда уж...Крутая отмазка. Супераргументированная!
П>При наличии битых страниц бэкап АФАИК попросту не сделается
Еще как сделается. Со свистом.
OLE>>От проверок на восстановимость проку мало, т.к. процесс бекапа и ресторе занимает продолжительное время. Актуальность упущена именно на это время. П> А что, где-то они выполняются моментально?
Не _моментально_, а _гораздо быстрее_. Если сибейс, на аналогичной базе, бэкап делает на ходу и за несколько минут, а не часов — ты, наверное, удивишься. П>На столь любимом тобой постгресе
Я не говорил что он столь мной любим. Кончай передергивать и додумывать.
Я говорил, что для подобной задачи он более целесообразен. П>мы делали restore полдня
Руки? Мозги?
OLE>>Решение? Это не решение. Решение — это когда настроил и забыл. П>Ага, только для этого надо сперва один раз настроить. А тебе, похоже, хочется чтоб все само заработало.
Не само. После. Настройки. Написания. Кучи. Скриптов. Нормально. Чтоб. Работало.
Так яснее?
С ФБ такое не выйдет.
Здравствуйте, _d_m_, Вы писали:
___>Проверять бэкап на восстановимость. Это как это — сделанный бекап может не восстановиться? В каких еще СУБД такое возможно?
Да запросто! Oracle... Было пару раз... Слава Богу, пронесло и БД в тот момент не рухнула. Собственно, она ни разу и не падала. Но невосстановимые бэкапы бывают.
___>Использовать одновременно несколько программных средств для резервирования.
Ты почитай, например, банковские инструкции... Не только бэкапы самой БД делаются, причем на другой диск и другую машину, так еще и каждая из этих машин со всем содержимым бэкапится. Иначе нельзя. Рэйды рассыпаются, диски бьются и так далее...
___>В ответ на что?
Да на твои возражения. Это ты в каком-нибудь самопале и шарашкиной конторе можешь вполне обойтись, скажем, только бэкапом базы. И то не каждый день. А в серьезных конторах бэкапы могут делаться буквально каждый час. Потому что убытки при потере данных могут быть весьма значительными, и никто на такое не соблазнится.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Наверное потому что видел как вылетает винт у рейда?
Батенька! Да вы не те рейды используете! Что бы на 5-ом при слете винта легла вся инфа?
КД>или видел как отказоустойчивый NTFS
С каких пор NTFS отказоустойчивый? Про NTFS и я могу баек нарассказывать.
КД>И когда, грубо говоря, без башенные казлы, из отдела сопровождения
А я расскажу другую байку. Про безбашенного казла проектировщика, который перепутав коннекты в офигенном поделище ИБЭксперт , проверяя свои очередные гениальные мылсищи, задропал кучу гигантских таблиц. А потом выпучив все свои глазки брызгал слюной в сторону админов и требовал _актуального_ восстановления.
КД>И, особо ретивых, предупрежу сразу — не стоит ставить под сомнение уровень сложности самой базы данных и программного обеспечения, которое с ним взаимодействует...
Исходя из верхних строк такое сомнение есть.
КД>В отличии от невразумительных мычаний, я в состоянии вразумительно сформулировать понятие "сложная система"
Ну давай. _Четкое_ (Не доспукающее неоднозначного трактования ни одного термина) определение сложной системы в студию.
КД>Я это написал только для того, чтобы сказать, что есть реально действующая распределенная система в которых Firebird вполне справляется со своей задачей. Задачей управления базами данных. А не заменой мозгов людей, которым эти данные нужны.
А понятие "стоимость сопровождения" что-нибудь говорит? Или это просто показать, что и запорожец может землю рыть?
Здравствуйте, _d_m_, Вы писали:
___>Проверять бэкап на восстановимость. Это как это — сделанный бекап может не восстановиться?
Ага. АФАИК основная причина в том, что при изменении метаданных IB не отслеживает их корректность. Соответственно, например, можно добавить NOT NULL столбец к уже заполненной данными таблице и при этом не записать ничего в соответствующее поле. Постольку, поскольку backup — это обычный читающий клиент, он такие данные благополучно схавает, а вот restore при попытке их восстановления обломается. Штука, конечно, неприятная, но не смертельная — мало кто станет проводить такие манипуляции с рабочей базой без четкого понимания того, что он делает. Да и после появления nbackup она, думаю, станет несколько менее пугающей, т.к. в его случае файл БД копируется "как есть" и так же восстанавливается.
___>В каких еще СУБД такое возможно?
По тем же причинам — не знаю, возможно и ни в каких. Вообще же в битом файле (да и вообще в битом файле) бэкапа не вижу ничего удивительного — мало ли какие чудеса случаются. Так что если речь действительно идет о "большой системе" (и, следовательно, больших бабках), принцип "береженого бог бережет" лишним точно не будет.
___>Использовать одновременно несколько программных средств для резервирования.
А ИМХО как раз логично — безопасность лишней не бывает. А до кучи еще и RAID поставить, от греха.
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Да запросто! Oracle... Было пару раз... Слава Богу, пронесло и БД в тот момент не рухнула. Собственно, она ни разу и не падала. Но невосстановимые бэкапы бывают.
Но это не _систематически_.
H_I>Да на твои возражения. Это ты в каком-нибудь самопале и шарашкиной конторе можешь вполне обойтись, скажем, только бэкапом базы. И то не каждый день. А в серьезных конторах бэкапы могут делаться буквально каждый час. Потому что убытки при потере данных могут быть весьма значительными, и никто на такое не соблазнится.
В ФБ? Каждый час? Это не смешно. Те каждый час кидаем юзерей на неопределенное время?
Здравствуйте, OLEGus1, Вы писали:
OLE>Батенька! Да вы не те рейды используете! Что бы на 5-ом при слете винта легла вся инфа?
Да как с добрым утром... Не далее, как две недели назад ковырял такой сервак. 5-й рейд, вылетел один диск. И все! Приходи кума любоваться...
OLE>С каких пор NTFS отказоустойчивый? Про NTFS и я могу баек нарассказывать.
Про отказоустойчивость, конечно, — это слишком... Но и полностью отказоустойчивых FS не бывает. Надежность 100% — это из области ненаучной фантастики. Но все же NTFS горвздо надежнее того же пресловутого FAT32. А я и такое видывал — боевая БД размером под 4 гига на FAT32... Руки бы отрывал за такое...
OLE>А я расскажу другую байку. Про безбашенного казла проектировщика, который перепутав коннекты в офигенном поделище ИБЭксперт , проверяя свои очередные гениальные мылсищи, задропал кучу гигантских таблиц. А потом выпучив все свои глазки брызгал слюной в сторону админов и требовал _актуального_ восстановления.
Проектировщика уволить. Предварительно убив его и отравив ядом. Он совсем идиот, чтоб перепутать коннекты?! Да еще и сотворить такое, не подумав десять раз, на боевой базе... М-дя... А на IBExpert не надо тянуть — инструмент шикарный... И надежный. Ты ж не ругаешь, например, бензопилу за то, что кто-то, не умея ей пользоваться, отрезал себе ногу?
Здравствуйте, OLEGus1, Вы писали:
H_I>>Да запросто! Oracle... Было пару раз... Слава Богу, пронесло и БД в тот момент не рухнула. Собственно, она ни разу и не падала. Но невосстановимые бэкапы бывают. OLE>Но это не _систематически_.
Согласен. Но есть такие косяки не только у FB. Ты ведь именно это утверждаешь, что у правильных СУБД не бывает битых бэкапов.
OLE>В ФБ? Каждый час? Это не смешно. Те каждый час кидаем юзерей на неопределенное время? Ни разу не видел кинутых пользователей... Нормально работают они при бэкапе... Хотя, конечно, да... Если какой-нибудь "умник" начнет гонять сверхтяжелую транзакцию, массированно удалять/обновлять данные... Да и то — не факт совершенно. MS SQL таким способом (да и Oracle тоже) вполне свободно ставится "на колени".
З.Ы. ИМХО до СВ уже скатились... Может, уже пора перенести?
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Да как с добрым утром... Не далее, как две недели назад ковырял такой сервак. 5-й рейд, вылетел один диск. И все! Приходи кума любоваться...
Возможно, но опять же это исключительный случай.
H_I>Про отказоустойчивость, конечно, — это слишком... Но и полностью отказоустойчивых FS не бывает. Надежность 100% — это из области ненаучной фантастики. Но все же NTFS горвздо надежнее того же пресловутого FAT32. А я и такое видывал — боевая БД размером под 4 гига на FAT32... Руки бы отрывал за такое...
ФАТ это вообще дикость. Но я не про него. Ведь есть UFS2, ext3, reiser наконец.
H_I>Он совсем идиот, чтоб перепутать коннекты?!
Тут как раз просто. Если помнишь, у Експерта коннекты хранятся в списке. А визуальность этого списка весьма неинформативна.
H_I>А на IBExpert не надо тянуть — инструмент шикарный... И надежный. Ты ж не ругаешь, например, бензопилу за то, что кто-то, не умея ей пользоваться, отрезал себе ногу?
Инструмент хорош-согласен. Что напрягает-исключения выпадающие иногда не пойми на что, ну и невозможность работы с фильтрами на большимие таблицы.
Хотя у других СУБД и такого зачастую нет.
Здравствуйте, 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>Ура!
О боже, парень, пиши еще !
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>>TABLE1 попал в бэкап. OLE>>Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>>TABLE2 попал в бэкап. OLE>Щас придеретесь, что пример не показателен. OLE>Ладно: произошло: OLE>insert into TABLE1 OLE>и insert into TABLE2
Жжошь!
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
[Sorry, skipped] OLE>> TABLE1 попал в бэкап. OLE>> Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>> TABLE2 попал в бэкап. OLE>> Ура!
КД> О боже, парень, пиши еще !
Да. Конкретная патология и товарища...
И он ещё кому-то что-то советует/не советует...
"OLEGus1" <5096@users.rsdn.ru> wrote in message news:1957084@news.rsdn.ru... > Щас придеретесь, что пример не показателен. > Ладно: произошло: > insert into TABLE1 > и insert into TABLE2
А теперь курим ман по транзакциям до просвтеления Пока транзакция не commited, gbak читает прошлые версии записей существовавшие до старта транзакции, неважно одну таблицу она затрагивает или сто.
Здравствуйте, OLEGus1, Вы писали:
П>>А что, РК принципиально неюзабилен? Если действительно очень надо? OLE>Очень надо и продукт разные вещи. "Очень надо" — это обычный костыль. М$ часто такие вещи практикует.
Так тебе шашечки?
OLE>Нет подмены понятий. Есть простой и надежный механизм (сибес) бэкапа и восстановления (к слову сказать, ни разу не пришлось делать).
А, ну тогда понятно почему вопрос о времени восстановления был обойден стороной.
OLE>Для данной задачи-не советовал и не советую.
Ну аргументируй уже наконец, что такого абсолютно несовместимого ты видишь в нем с данной конкретной задачей? А то все больше какие-то страшные истории про казлов и костыли. Почему у людей при аналогичных перечисленным параметрах работает, а у данного конкретного человека — не будет? Что за тайное знание такое у тебя есть о его системе?
OLE>Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась.
Ух, как интересно! И что же будет?
П>>Да, с последующим тестовым восстановлением. OLE>Так и представляю... Набольшой базе процесс gbak и восстановления может занять не одни сутки вообщето.
А на очень большой — столько же займет простое копирование. Но такие базы FB никто и не советовал. И к чему эти передергивания?
OLE>Ранняя стадия-это от нескольких часов?
Да. Сравни с "вообще никогда" для случая, когда невосстановимость не отслеживается. А она, как уже выяснили, может случиться на любой СУБД.
Здравствуйте, wellwell, Вы писали:
W>"OLEGus1" <5096@users.rsdn.ru> wrote in message news:1957084@news.rsdn.ru... >> Щас придеретесь, что пример не показателен. >> Ладно: произошло: >> insert into TABLE1 >> и insert into TABLE2
W>А теперь курим ман по транзакциям до просвтеления Пока транзакция не commited, gbak читает прошлые версии записей существовавшие до старта транзакции, неважно одну таблицу она затрагивает или сто.
Люди, держите меня
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Alex.Che, Вы писали:
AC>>Да. Конкретная патология и товарища... AC>>И он ещё кому-то что-то советует/не советует...
OLE>хм... я что то не так написал?
Все так. Именно так как я и ожидал, когда задал вопрос. Я жму вашу руку. Зачот.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Привет, OLEGus1!
Вы пишешь 15 июня 2006:
AC>> Да. Конкретная патология и товарища... AC>> И он ещё кому-то что-то советует/не советует...
O> хм... я что то не так написал?
— Лучше мне промолчать, — подумала Алиса.
На этот раз, так как она не произнесла ни слова, никто нечего не сказал,
но, к величайшему ее удивлению, все хором подумали:
— Лучше промолчи! (С)
Здравствуйте, OLEGus1, Вы писали:
OLE>хм... я что то не так написал?
JFYI: gbak — это обычный клиент, который при запуске стартует свою собственную читающую транзакцию и завершает ее после окончания бэкапа. Все чтения идут в ее контексте. Дальше объяснять или понятно?
PS На всякий случай, т.к. предвижу крик на эту тему: читающие транзакции в FB не блокируют базу.
Здравствуйте, Пацак, Вы писали:
П>Почему у людей при аналогичных перечисленным параметрах работает, а у данного конкретного человека — не будет? Что за тайное знание такое у тебя есть о его системе? П>Но такие базы FB никто и не советовал. И к чему эти передергивания?
Вот тебе две твои жефразы.
А база у человека, судя по всему будет не из небольших (к тому же их 6). И многочасовой бэкап ему обеспечен.
П>Да. Сравни с "вообще никогда" для случая, когда невосстановимость не отслеживается. А она, как уже выяснили, может случиться на любой СУБД.
Может. Но причины разные.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>хм... я что то не так написал?
П>JFYI: gbak — это обычный клиент, который при запуске стартует свою собственную читающую транзакцию и завершает ее после окончания бэкапа. Все чтения идут в ее контексте. Дальше объяснять или понятно?
Более того, транзакция с уровнем изоляции "повторяемое чтение". То есть хоть "обизменяйся" и "обкоммиться".
Не, какой аблом для этого, не побоюсь этого слова, реального пацана
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>А база у человека, судя по всему будет не из небольших (к тому же их 6). И многочасовой бэкап ему обеспечен.
П>Многочасовой <> многодневный
1сутки=24 часа. 24 часа это много часовой? Для кучи немаленьких баз эта цифра реальна. П>Короче опять передергивания вместо конкретных ответов.
Передергиванья как раз у тебя.
OLE>>Может. Но причины разные. П>Зато результат один.
Результат тоже разный. При неопределенном невосстанавливающемся бэкапе у ФБ такое будет и на следующих, в отличие от тогоже постгреса.
Здравствуйте, Пацак, Вы писали:
П>>>Многочасовой <> многодневный OLE>>1сутки=24 часа. 24 часа это много часовой?
П>...но не многодневный — о том и речь. OLE>>При неопределенном невосстанавливающемся бэкапе у ФБ такое будет и на следующих П>Вот именно поэтому и нужен процесс, который отследит это сразу после возникновения.
OLE>>, в отличие от тогоже постгреса. П>А, ну да — у постгреса бэдблочный винт, на который делается бэкап за это время самопроизвольно самопочинится.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Жжошь!
Хлеб купил?
4. Подключение пользователей во время процедуры восстановления
Если Вы не заблокируете доступ пользователей к базе данных в процессе её восстановления командой gbak -r[eplace] , то они будут иметь возможность, подключившись, осуществить некоторые действия по изменению данных, что, в свою очередь, приведет к порче базы данных.
OLE>4. Подключение пользователей во время процедуры восстановления
OLE>Если Вы не заблокируете доступ пользователей к базе данных в процессе её восстановления командой gbak -r[eplace] , то они будут иметь возможность, подключившись, осуществить некоторые действия по изменению данных, что, в свою очередь, приведет к порче базы данных.
OLE>Все. Терь точно ушел.
Пока!
Так ты даже не различаешь бэкап и рестор!
Удивил. А как много написал.
Да, и почитай про уровни изолированности транзакций.
Здравствуйте, OLEGus1, Вы писали:
H_I>>Да как с добрым утром... Не далее, как две недели назад ковырял такой сервак. 5-й рейд, вылетел один диск. И все! Приходи кума любоваться... OLE>Возможно, но опять же это исключительный случай.
При чем тут исключения? Я говорю о том, что такое может случиться с любым серваком. И ни FB, ни SyBase, ни Oracle, ни какой либо другой не застрахован от таких казусов. И делать регулярные бэкапы, причем на разные устройства и машины, жизненно необходимо. Причем, бэкапить как БД, так и диски машин, на которые эти бэкапы пишутся. Элементарные требования к сохранности данных.
OLE>Тут как раз просто. Если помнишь, у Експерта коннекты хранятся в списке. А визуальность этого списка весьма неинформативна.
Да ну?! А кто мешает каждому коннекту задать внятное описание? У меня вот таковые заданы. И я не путаюсь в них. И в боевую БД лезу только тогда, когда сделан ее полный бэкап, и этот бэкап проверен на восстановимость. А заодно тогда, когда в базе не остается ни одного юзера. Да и, насколько мне известно, рестор никогда не пройдет, если к БД не открыт единственный и эксклюзивный коннект.
OLE>Инструмент хорош-согласен. Что напрягает-исключения выпадающие иногда не пойми на что, ну и невозможность работы с фильтрами на большимие таблицы.
Ни разу не сталкивался... Таблица в три миллиона записей фильтруется секунд 5 на двухголовой машине с двумя гигами оперативы. Может быть, что на менее сильной машине и будут тормоза. Не проверял за отсутствием таковой...
OLE>Хотя у других СУБД и такого зачастую нет.
Да ну... У того же Oracle с использованием PL/SQL Developer при наложении фильтра на неиндексированный столбец тормоза — будь здоров... И у MS SQL тоже... Так что — не показатель. Как пример — кусочки кода из вполне боевой БД Oracle размером в 32 гига...
Вот такая вьюха:
CREATE OR REPLACE VIEW V_RQ_DATA AS
select RQ."ID",RQ."STATUS",RQ."CLIENT_ID",RQ."CREDIT_SUBTYPE_ID",RQ."DEPARTMENT_ID",
RQ."TERMINAL_ID",RQ."S_CURRENCY_TYPE_ID",RQ."R_DATE",RQ."OWS_APPL_FL",RQ."ISSUE_CARD_NUMBER",
RQ."R_UID",RQ."CONTRACT_DATE",RQ."RQ_ID",RQ."CLIENT_TYPE",RQ."COMMENT_SB",
RQ_EXCLUSIVE.GET_RQ_ATTR_N(RQ.ID,'HOUSE_DATE') HOUSE_DATE,
...
from RQ
WHERE RQ.DEPARTMENT_ID IN (SELECT DEPARTMENT_ID FROM PERMISSIONS P WHERE NAME = 'ACCESS')
AND RQ.CREDIT_SUBTYPE_ID IN (SELECT CREDIT_SUBTYPES_ID FROM PERMISSION_CT)
AND RQ.RQ_ID IS NOT NULL
Здесь вместо ... надо бы вставить еще 600 вызовов функции RQ_EXCLUSIVE.GET_RQ_ATTR_N(), да мне жаль места и трафика.
Сама функция RQ_EXCLUSIVE.GET_RQ_ATTR_N имеет вид:
FUNCTION GET_RQ_ATTR(pRQ_ID NUMBER,
pAttr_Type VARCHAR2) RETURN varchar2
is
BEGIN
FOR R IN (SELECT ATTR_VALUE
FROM RQ_ATTR
WHERE RQ_ID = pRQ_ID
AND ATTR_TYPE = pAttr_Type)
LOOP
RETURN R.ATTR_VALUE;
END LOOP;
RETURN NULL;
END;
Таблица RQ содержит порядка 8 миллионов записей, таблица RQ_ATTR — около 38 миллионов... Я бы, конечно, проектировщика убил медленной смертью в кислотной бочке за такое. Но — что имеем, как говорится... Так вот, 4-х процессорный сервак с 8 гигами оперативы на борту первые 20 записей из этой вьюхи выбирает аж за полторы минуты... Это я к тому, что инструмент разработчика (IBExpert или любой иной) вообще к скорости выборки данных не имеет никакого отношения...
Господа обладатели белых польт! Такое впечатление, что вы школьники, поймавшие нелюбимого учителя на ошибке.
Да. Признаюссь. Про режим работы gbak не знал. Теперь знаю. Спасибо за толковое разъяснение кучей смайлов
Здравствуйте, Horror_Infinity, Вы писали:
OLE>>Хотя у других СУБД и такого зачастую нет. H_I>Да ну... У того же Oracle
под "таким" имелся в виду инструмент.
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Это я к тому, что инструмент разработчика (IBExpert или любой иной) вообще к скорости выборки данных не имеет никакого отношения...
Я опять же не про это.
В Эксперте есть такая мулька, как филтр в контесте таблицы. Я не смотрел принцип его работы, но факт в том, что селект из скрипта идет на ура, а использование этого фильтра чревато сообщением "недостаточен файл подкачки"
Здравствуйте, OLEGus1, Вы писали:
OLE>Господа обладатели белых польт! Такое впечатление, что вы школьники, поймавшие нелюбимого учителя на ошибке. OLE>Да. Признаюссь. Про режим работы gbak не знал. Теперь знаю. Спасибо за толковое разъяснение кучей смайлов
Очухался?
Тогда совет — перед тем как что-то категорично утверждать задай себе простой вопрос "А не дурак ли я?".
На "режим работы gbak" кивать не надо, потому что опять киваешь мимо.
Моя реакция и число были пропорциональны количеству твоих понтов. Уж извини.
Да, и наcчет "учителя" — "не учи отца и баста" (c)
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>В Эксперте есть такая мулька, как филтр в контесте таблицы. Я не смотрел принцип его работы, но факт в том, что селект из скрипта идет на ура, а использование этого фильтра чревато сообщением "недостаточен файл подкачки"
Версия? Что-то похоже, что ты какой-то древней пользуешься... Более свежие релизы не пробовал качать? У меня версия 2006.04.23 — а это старенькая уже — и таких косяков я не наблюдал ни разу... Счас самуя свежую скачаю, проверю... Есть у меня тут табличка одна миллионов на пять записей... Придумаю фильтр посложнее...
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Здравствуйте, OLEGus1, Вы писали:
OLE>>В Эксперте есть такая мулька, как филтр в контесте таблицы. Я не смотрел принцип его работы, но факт в том, что селект из скрипта идет на ура, а использование этого фильтра чревато сообщением "недостаточен файл подкачки"
H_I>Версия? Что-то похоже, что ты какой-то древней пользуешься... Более свежие релизы не пробовал качать? У меня версия 2006.04.23 — а это старенькая уже — и таких косяков я не наблюдал ни разу... Счас самуя свежую скачаю, проверю... Есть у меня тут табличка одна миллионов на пять записей... Придумаю фильтр посложнее...
Честно говоря, уже не пользуюсь. Пользовался 2005, билд какой-не помню.
Я почти год как с ФБ не работаю.
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Пацак, Вы писали:
П>>Итого: критичных противоречий не вижу. Учитывая, что сейчас выбор идет между MySQL и Postgresql — Firebird в этом ряду вполне конкурентоспособен. OLE>Конкурентоспособен и не более. Postgresql таки пооптимальней будет, особенно если учесть: OLE>
OLE>Наша контора работает под MSSQL. В нем до 6 баз данных. В каждой из баз есть таблицы с кол-вом строк около миллиона. Работают с базами около 30 клиентских мест.
OLE>Сопровождать конструкцию на ФБ будет достаточно тяжело.
fb 1.0.2.908 4 базы 58 клиентов.
среднее колличество записей в таблицах 200000-300000
минимальное 10000 максимальное 12000000
работает без остановки с 2000 г.
клиенты сомописанные
за все время было 2 падения серверов (железа)
больше проблем не было
П>>И как всегда — без аргументов. OLE>Вспомним "правильные" бекапы? OLE>И заодно отсутвие лога транзакций.
Здравствуйте, OLEGus1, Вы писали:
OLE>Если ты не заметил, это был просто случай из жизни достойно соответствующим другому случаю из жизни (почитай тему выше), говорящий о том, что все вокруг Дмитрия, действительно идиоты. А он единственный граф Монте-Кристо в белом пальте, конечно же, всезнающий, с сундуком, набитым бисером, и не снисходящий к простым смертным, несмотря на все мольбы.
откуда сделан вывод в том, что у IB/FB бэкап постоянно битый? В статье совершенно четко приведены все случаи, когда бэкап может оказаться невосстановимым. Но это нештатные ситуации. И происходят они крайне редко.
Круто, ничего не скажешь! 
