Здравствуйте, Softwarer, Вы писали:
S>Безотносительно к автономным транзакциям — следует ли понимать так, что в ХП в FB нельзя выполнять команды start transaction / commit?
Да, управлять транзакцией внутри ХП — нельзя.
S>В итоге, если выполнение этой хранимки завершается с ошибкой, ее действия откатываются, но я вижу лог происходившего во всех подробностях. На savepoint-ах, боюсь, такого не сделать.
Да, это факт. Но ты не бойся, если нельзя — значит и не надо
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, fddima, Вы писали:
F> 5. Но если рассматривать сектор Embedded, то MSDE не является таким... OraExpress пожалуй тоже.
О! Это ты очень даже прав!.. Свежеустановленный OraExpress — это 1, 1 гига места на диске! И это экспресс?! А уж какой embedded — закачаешься просто!.. Куда там какому-то Firebird до такого embedded мегаэкспресс...
Здравствуйте, Пацак, Вы писали:
П>Список "других СУБД", позволяющих делать мгновенный бэкап в онлайне — в студию.
Где я говорил о "мгновенном"? О быстром-да. Дельфинячье передергивание слов.
П>Прок будет очень большой — ты не будешь надеяться на этот бэкап, а сделаешь новый. Либо найдешь кривизну в базе.
А прок еще проще. Просто надо выбирать другую СУБД для больших и надежных проектов.
Здравствуйте, slskor, Вы писали:
S>При insert на массивных вставках в Interbase бывает другая проблема. Описана здесь: http://www.ibase.ru/devinfo/oitoat.htm
Я весьма бегло просмотрел этот текст, поэтому позволю себе несколько замечаний, в которых в принципе не абсолютно уверен.
1. Не при "массивных вставках", а при "массивных вставках с промежуточными коммитами при наличии конкурирующих писателей".
2. Это проблема не insert-ов, но любого DML вообще.
3. Как я понял из общения с парнем, плотно занимающимся FB, выбор подходящего sweep-а и его настройка — это задача, примерно аналогичная настройке rollback segment-ов в Oracle (по сложности и влиянию на результат).
Здравствуйте, Пацак, Вы писали:
П>А можно чуть подробнее, как оно реализовано? Особенно интересует что в это время происходит с изменениями базы.
Не знаю точно как Оракл, но любая система с журналированием делает это ровно в два этапа.
1. В бакап сливается содержимое непосредственно БД.
2. После окончания первой фазы в бакап накатывается лог изменений за время бакапа, те транзакции которые успели зафиксироваться — фиксируются, те которые не успели — откатываются.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Пацак, Вы писали:
П>>А можно чуть подробнее, как оно реализовано? Особенно интересует что в это время происходит с изменениями базы. M>Не знаю точно как Оракл, но любая система с журналированием делает это ровно в два этапа. M>1. В бакап сливается содержимое непосредственно БД. M>2. После окончания первой фазы в бакап накатывается лог изменений за время бакапа, те транзакции которые успели зафиксироваться — фиксируются, те которые не успели — откатываются.
Оракл делает еще проще.
1. как есть
2. вместе в копией файлов прилагаются редо-логи, которые при восстановлении накатываются на файлы п.1
т.е. все как сказал Merle, только 2 фаза делается при восстановлении, а не при бекапе.
Здравствуйте, Пацак, Вы писали:
S>>либо частичный/полный со скоростью физического копирования файлов
П>А можно чуть подробнее, как оно реализовано? Особенно интересует что в это время происходит с изменениями базы.
Накапливаются в логе. Схема работы сервера следующая: происходящее изменение ставится в очередь на запись. Асинхронно эти изменения сбрасываются в журнал; в момент коммита сервер проверяет, что все изменения транзакции попали туда. В какой-то момент сервер переключается на запись другого журнала, а этот идет на дальнейшую обработку. Дальнейшая обработка — это в том числе отложить как очередной файл инкрементального бэкапа, в том числе переслать на standby сервер (горячий резерв с копией базы), в том числе поставить в очередь на внесение изменений в основные файлы БД.
Для бэкапа достаточно затормозить этот самый "перенос изменений в основные файлы базы". Там целостное состояние, обращение к ним со стороны сервера — только на чтение, соответственно спокойно в онлайне копируем файлы и знаем, что для того, чтобы в дальнейшем накатить на этот бэкап изменения, нужно начинать с лога номер 12345.
Итого — даем команду, если не изменяет память ALTER TABLESPACE ... BEGIN BACKUP, после чего копируем базу целиком либо только нужные tablespace-ы.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Насколько я понимаю этот термин (возможность стартовать/комитить/откатывать транзакции в триггерах, хранимых процедурах), то такого в FB нет.
Хм. Безотносительно к автономным транзакциям — следует ли понимать так, что в ХП в FB нельзя выполнять команды start transaction / commit?
КД>Зато есть точки сохранения — savepoint-ы, которые можно создавать как на клиенте так и в триггерах, хранимых процедурах.
Если в понятие savepoint в FB вкладывается тот же смысл, что и в Oracle — это не "зато"; оно само по себе хорошо, но не заменяет автономных транзакций.
Простой пример автономной транзакции — лог. То есть, я делаю примерно следующую хранимую процедуру:
create or replace procedure WriteLog ( Msg varchar2 ) is
pragma authonomous_transaction ;
begin
insert into Log ( log_id, message ) values ( log_seq.nextval, Msg ) ;
commit ;
end ;
После этого я пишу большую и сложную хранимку, в которой веду лог — например, в отладочных целях:
create or replace procedure SomeBusinessFunction ( Param1 integer, Param2 varchar2 ) is
begin
savepoint saveSomeBusinessFunction ;
WriteLog ( 'SomeBusinessFunction::Param1 = ' || Param1 || ' Param2 = ' || Param2 ) ;
.....
WriteLog ( 'SomeBusinessFunction - ok' ) ;
exception
when others then
WriteLog ( 'SomeBusinessFunction - ERROR! ' || sqlerrm ) ;
rollback to savepoint saveSomeBusinessFunction ;
end ;
В итоге, если выполнение этой хранимки завершается с ошибкой, ее действия откатываются, но я вижу лог происходившего во всех подробностях. На savepoint-ах, боюсь, такого не сделать.
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
А>> Что есть "Плохого" у Firebird?
O> Мне не нравится хранение всего в одном файле. O> Это и философски и программно неправильно.
Глубоко. Очень.
O> Особенно, в этом контекте, радуют процедуры gbak и gfix.
Здравствуйте, Alex.Che, Вы писали:
AC>Глубоко. Очень.
А что мелко? Ну и какие премущества имеет хранение всей базы в одном файле? кроме того, что теряя один файл теряешь всю базу?
AC>Ещё глубжее.
Да, тоже мелочи, делать по многу часов бэкап, а потом еще столькоже разворачивать. А еще веселее становится, когда развернуться база не может без gfix'a, или даже с ним не может.
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
AC>> Что есть "полный цикл (по документации)" ?
O> gbak
И ещё раз.
Что есть "полный цикл (по документации)" ?
AC>> И что ж там с этими "баками" ?
OLE>> Да, тоже мелочи, делать по многу часов бэкап, а потом еще столькоже разворачивать.
Угу. А про ключики gbak'a мы и не догадываемся...
OLE>> А еще веселее становится, когда развернуться база не может без gfix'a, или даже с ним не может. O> Я абсолютно все описал выше. Не виноват я в том, что не все читают по существу.
Ты нихрена не сказал "по существу".
O> Это известная дельфинячая проблема O> Отшлю, наверное на форум ib.
Здравствуйте, OLEGus1, Вы писали:
OLE>Ну sybase у меня на аналогичной базе работает. Бекап, не моментальный, но быстрый. Намного быстрее.
В online?
OLE>Но у sybasа свои недостатки
... и его ты тоже "будешь использовать только в определенном круге задач, но никак не для больших проектов "
OLE>О. Вот и ответ на главный вопрос темы. Сами дошли
Здравствуйте, OLEGus1, Вы писали:
П>>Дык! Отключи всех пользователей, останови СУБД и F5 — будут тоже минуты. OLE>Ну не хочу я Ф5. Хочу bak и fix.
F5 ты не хочешь, gbak не хочешь, инкрементальный бэкап не хочешь... Ну не хочешь — не делай, кто запрещает-то... Людей устраивает — люди пользуются.
OLE>Как ты прав. Единственная отдушина — Оракль
...да благословит его Аллах и приветствует!
OLE>Ну человек спрашивал, что выбрать...... Я помог.....
Человек вообще-то не это спрашивал, а про отличия.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
П>>>Дык! Отключи всех пользователей, останови СУБД и F5 — будут тоже минуты. OLE>>Ну не хочу я Ф5. Хочу bak и fix.
П>F5 ты не хочешь, gbak не хочешь, инкрементальный бэкап не хочешь... Ну не хочешь — не делай, кто запрещает-то..
Ну ктож так читет
OLE>>Как ты прав. Единственная отдушина — Оракль
П>...да благословит его Аллах и приветствует!
OLE>>Ну человек спрашивал, что выбрать...... Я помог.....
П>Человек вообще-то не это спрашивал, а про отличия.
Название темы: Oracle | FireBird
| это означает "или"
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Здравствуйте, Merle, Вы писали:
M>>SQL Express... Даже по ограничениям... M>>Отличаются только размером дистрибутива Сиквел 34Мб (без .Net), а Оракл ~150Мб...
H_I>Ну да... При этом у сиквела вообще нет средств администрирования, а тот же Oracle Express предоставляет WEB-интерфейс. Так что, данное преимущество MS представляется мне весьма сомнительным.
А в чем тут преимущества MS ? в размере дистрибутива на 100 метров?? Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
Здравствуйте, Mikst, Вы писали:
M>Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
Вы по-моему очень много кушать (с) Ширли-Мырли. Если сама прога — метров десять то таскать и ставить ради нее гиговый дистр — несколько неразумно ИМХО.
Привет, Mikst!
Вы пишешь 16 ноября 2005:
M>>> Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
П>> Вы по-моему очень много кушать (с) Ширли-Мырли. П>> Если сама прога — метров десять то таскать и ставить ради нее гиговый дистр — несколько неразумно ИМХО.
M> Если сама прога метров 10 то для нее пойдут и текстовые файлы (иль майскуль на худой конец). зачем монстра типа мса и ораклы??
Да, да. Совершенно согласен. "Крутизна" программы прямо пропорциональна размеру.
Здравствуйте, Mikst, Вы писали:
П>>Затем, что база может быть 10 Гиг. M>тогда и сервер на 500 метров фигня
Ы-ы-ы-ы....
То ли я плохо объясняю... Есть у тебя дистр, 10 метров. В нем все — сервер, клиент, прога, пустая база, настройки etc. Поставил, работаешь, база пухнет, становится 100 метров, гиг, два, пять... Текстовые файлы уже бы не справились, а FB — легко. При этом дистр как был махонький, так и остался, хоть диалапом качай.
Здравствуйте, Merle, Вы писали:
M>Есть там средства администрирования, только скачиваются отдельно. Весят всего несколько метров.
Ага... И нафига? Забыл я их скачать. Да и не нужны они мне. А вот пришел к клиенту — опа! Надо! А нету! И инета нету. Что делать будем?
Здравствуйте, Merle, Вы писали:
H_I>> Забыл я их скачать. Да и не нужны они мне. M>Так забыл или не нужны?
И забыл, и не нужны. Скорее, второе. Поскольку я с сиквелом редко дела имею. Чаще все же оракл. Поэтому никогда не заморачиваюсь на средства администрирования.
M>Во-первых выяснять заранее, во-вторых включать в дистрибутив, если идем к неизвестному клиенту и приложение предполагает использование средств администрирования. То есть вы, как разработчики должны решить нужно вашему заказчику вашу базу администрить или нет, а не заказчик..
Это да. Чаще всего так и бывает. Что обычно заказчику надо? ЧТоб все работало и не падало. Для этого в теневом режиме проводится бэкап. В случае сбоя — восстанавливаем точно так же молча. Благо, что сервисы есть и они очень хорошо задокументированы.
M>SQL Express позиционируется как СУБД в составе готового решения, и с этих позиций предполагается, что ваше приложение обеспечит весь необходимый функционал, благо сиквел традиционно требует минимум усилий по администрированию.
Собственно, с Ораклом тоже проблем обычно не возникает в этом плане.
M>Ну а если нет, то можно скачать тулзу отдельно, поэтому такое решение более чем оправдано. Зачем пихать в дистрибутив приложение, которое в 90% случаев окажется не нужным?
Как и для Оракла. Тем более, что вся тулза — это просто WEB-интерфейс к утилитам и SP в базе.
З.Ы. В общем, более не вижу смысла препираться. Каждая из БД имеет право на существование. И применение. Просто есть разные области их применения. Остается только выбрать, где и что применить.
Здравствуйте, Cyberax, Вы писали:
C>При этом embedded FireBird помещается в 2Мб. Сколько у нас Оракл минимум C>займет?
C>Вообще, FB — это не самая фичастая база (никто и не спорит).
Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не для этого.
Здравствуйте, Mikst, Вы писали:
M>причем даже если синтаксически все заработает, никто не гарантирует правильности работы алгоритмов (вспомните интербейз с его удалением дубликатов )
... или ORACLE с его приведением пустой строки к NULL Нет идеальных СУБД, следовательно выхода два: либо сразу во всех случаях брать оракл и не парить мозги мифическим "выбором", либо знать про возможные подводные камни и уметь обходить их. А уж что выбрать — это каждый для себя решает ИМХО.
Здравствуйте, OLEGus1, Вы писали:
OLE>Говоришь, что не дельфинист...., но не "моментально", а "быстро". Нажимать ф5 руками меня ломает, для этого есть крон, а он не будет ждать, пока все удосужаться отвалиться от базы, а рубанет по живому. И результат получится не очень.
Если по крону, то какая тебе нафиг разница — "быстро" или "медленно"? Как срабатывал он, скажем, раз в сутки — так и будет срабатывать, как сохранял данные на момент своего старта — так и будет сохранять. Или тут вопрос религиозный?
OLE>Ну и, конечно, множество недотатков у длинных транзакций уже описано выше.
... и там же выше выянилось, что для insert они неактуальны. А необходимость в биллинге постоянных массовых длинных апдейтов АФАИР так и не аргументировали.
OLE>И, раз уж инстумент позволяет пользовать всю сессию в одной транзакции, причем гораздо проще, чем в нескольких, то народ так и будет реализовывать.
Давай ты будешь говорить не за всех, а за себя? Обсуждается не наличие возможности написать прогу криво, а отсутствие возможности написать ее прямо. Тебя кто-то заставляет в биллинге делать commit_retaining и держать сессию постоянно открытой? Или "мыши плакали, кололись, но продолжали жрать кактус"? И не говори, что ты один умный и этого делать не будешь, а окружающие все дураки, так и мечтающие наступить на грабли.
Ку...
Oracle | FireBird help
От:
Аноним
Дата:
16.11.05 07:51
Оценка:
Всем добрый день.
C oracle знаком давно.
С Firebird(Interbase) не знаком.
Что есть "Плохого" у Firebird?
16.11.05 19:01: Перенесено из 'Базы данных'
Re[2]: Oracle | FireBird help
От:
Аноним
Дата:
16.11.05 08:03
Оценка:
Здравствуйте, Softwarer, Вы писали:
просто нет многого привычного "хорошего".
— Можно 1 маленький пример: это можно и легко на Oracle и нельзя
(или с большими трудностями) на FireBird
— Есть ли ограничения на обьем базы, после которого начнуться коллизии
Здравствуйте, <Аноним>, Вы писали:
А>C oracle знаком давно. А>С Firebird(Interbase) не знаком.
А>Что есть "Плохого" у Firebird?
Сравнение несколько некорректное по определению. У каждого из серверов есть плюсы и минусы. Про Firebird можно почитать здесь — много, подробно и по-русски. Из плохого, пожалуй, только отсутствие встроенных функций на версиях 1.х, но и это не критично, ибо всегда есть возможность подсунуть "внешнюю" функцию из UDF.
Здравствуйте, <Аноним>, Вы писали:
А>- Можно 1 маленький пример: это можно и легко на Oracle и нельзя А>(или с большими трудностями) на FireBird
Например, у Oracle есть табличные функции. С их помощью довольно легко вернуть столько и такие данные, которые нужны. На Firebird это не реализуемо, ибо нет у него табличных функций. Как собственно и вообще объектов. Зато есть возможность реализовать селективные SP, чего нет в Oracle.
В Oracle, например, при написании хранимок и пакетов (а пакетов в Firebird нет) ты не ограничен только PL/SQL и можешь написать его на JAVA. У Firebird этого тоже нет — только SQL и ничего больше. Но, по большому счету, этого вполне достаточно. А недостающий функционал легко реализуется с помощью UDF.
А>- Есть ли ограничения на обьем базы, после которого начнуться коллизии
Что-то в районе 32 гигов на файл. Точно не помню, но можно поискать здесь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Oracle | FireBird help
От:
Аноним
Дата:
16.11.05 08:46
Оценка:
Здравствуйте, Horror_Infinity, Вы писали:
Какие по Вашему мнению основные "-" у FireBird, помимо того, что он бесплатный.
Здравствуйте, Horror_Infinity, Вы писали:
А>>- Есть ли ограничения на обьем базы, после которого начнуться коллизии
H_I>Что-то в районе 32 гигов на файл. Точно не помню, но можно поискать здесь.
Что цифра какая-та несуразная
FireBird, начиная с релиза FB1, использует 64-битную адресацию для чтения-записи файлов.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Что цифра какая-та несуразная
Сорри. Уже давно не работал с FB по хорошему, то есть плотно. Видимо, эта инфа у меня отложилась еще со времен IB. Посыпаю голову пеплом и иду читать доку.
Здравствуйте, <Аноним>, Вы писали:
А>Каковы все же — , или это большой секрет
Нет, не секрет. Почему ты так упорно не желаешь сходить сюда и почитать?
А>Для биллинговых систем FireBird пригоден ?
Да.
А>Есть ли у FireBird средста отслеживания событий, происходящих в БД,
Да. А>автономные транзакции.
Да.
Здравствуйте, Аноним, Вы писали:
А>Хорошо пусть это +,
А>Каковы все же — , или это большой секрет
Часто народ ругает оптимизатор, хотя мне лично откровенной и неисправимой кривизны видеть не приходилось, поэтому к народу не присоединюсь.
Выполнение некоторых запросов не соответствуют стандарту (например уже упоминавшиеся
Здравствуйте, OLEGus1, Вы писали:
OLE>Кстати, больше всех рушат базу, именно дельфянячии компоненты.
А может стоит её вообще по F5 бакапить?
OLE>Не веришь? Бакни базку хотя бы в пару гиг.
Тут присутствуют люди, у которых на FB работают базы >10GB
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>А может стоит её вообще по F5 бакапить?
Ээээээ. копирование не решит вопросов с потерянными страницами. Да и пользователей отрубать надо А при биллинге такое не всегда возможно.
КД>Тут присутствуют люди, у которых на FB работают базы >10GB
Не встречал. Хотелось бы встретить. Заглянуть в глаза. И спросить как они решили проблему gfix'a
Здравствуйте, OLEGus1, Вы писали:
AC>>Да, да. Ведь именно они напрямую работают с файлом базы. AC>>Даже без сервера как такового...
OLE>а вот подход у дельфинячих компонент, кривой, позволяющий всю сессию вести на ретейнингах, что не есть правильно.
Непонял. Переведи, пожалуйста. Для темных.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
AC>> Да, да. Ведь именно они напрямую работают с файлом базы. AC>> Даже без сервера как такового...
O> Работает сервер, никто не спорит, а вот подход у дельфинячих компонент, O> кривой, позволяющий всю сессию вести на ретейнингах, что не есть правильно.
Да, да. Ведь именно компоненты сами делают ретейнинги.
Даже без программиста, как такового...
Здравствуйте, Alex.Che, Вы писали:
AC>Да, да. Ведь именно компоненты сами делают ретейнинги. AC>Даже без программиста, как такового...
От этого суть не сильно меняется Если позволяет, то кто же не будет этим пользоваться?
Но я от тебя не этого ответа жду. А про баки. Согласен ведь, что в данном случае это критично?
А еще хотелось бы видеть текущие сеансы, а еще лог транзакций, а еще........
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
AC>> Да, да. Ведь именно компоненты сами делают ретейнинги. AC>> Даже без программиста, как такового...
O> От этого суть не сильно меняется O> Если позволяет, то кто же не будет этим пользоваться?
Если есть возможность выстрелить себе в ногу,
то кто же не будет этим пользоваться?
O> Но я от тебя не этого ответа жду. А про баки. O> Согласен ведь, что в данном случае это критично?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Мне папа в детстве говорил "Доказать можно только собственную глупость"
КД>Рекомендую взять на вооружение.
Не хочу рушить мнение, навязанное ранее безусловным авторитетом, но ты не думаешь, что вера в недоказуемое, слепа?
Здравствуйте, Alex.Che, Вы писали:
O>> Но я от тебя не этого ответа жду. А про баки. O>> Согласен ведь, что в данном случае это критично?
AC>Что "ЭТО" ?
Баки, они же backupы. Причем прошедшие полный цикл (по документации), а не самострельные (Ф5)
Здравствуйте, OLEGus1, Вы писали:
OLE>От этого суть не сильно меняется Если позволяет, то кто же не будет этим пользоваться?
Согласен, коллега! Более того: раз уж база данных лежит в файле и в дельфи есть функции для работы с файлами — глупо этим не пользоваться и не писать в файл напрямую! А все эти комоненты, tcp-ip и прочее — это фигня, по нему же доку читать надо, а это неинтересно.
OLE>Но я от тебя не этого ответа жду. А про баки. Согласен ведь, что в данном случае это критично?
Ты сперва расскажи что тебя в сегодняшнем варианте бэкапа не устраивает. А там посмотрим.
Привет, OLEGus1!
Вы пишешь 16 ноября 2005:
AC>> Что "ЭТО" ? O> Баки, они же backupы. O> Причем прошедшие полный цикл (по документации), а не самострельные (Ф5)
Что есть "полный цикл (по документации)" ?
И что ж там с этими "баками" ?
Здравствуйте, OLEGus1, Вы писали: OLE>А еще хотелось бы видеть текущие сеансы, а еще лог транзакций, а еще........
Лог транзакций — вы понимаете такой, как в MS SQL Server, чтобы можно было откатываться на любую точку во времени?
Здравствуйте, OLEGus1, Вы писали:
OLE>Повторю: Во первых это очень долго.
Большая база — долгий бэкап
Маленькая база — короткий бэкап
Где-то здесь есть противоречие?
Впрочем для особо нетерпеливых в FB2 сделан инкрементальный бэкап.
OLE>Во вторых, иногда, фатально.
Раз в пятилетку и валенок стреляет. Никто не мешает проверять восстановимость бэкапа сразу после того, как он был сделан.
Здравствуйте, Alex.Che, Вы писали:
AC>Что есть "полный цикл (по документации)" ?
gbak
AC>И что ж там с этими "баками" ?
OLE>Да, тоже мелочи, делать по многу часов бэкап, а потом еще столькоже разворачивать. А еще веселее становится, когда развернуться база не может без gfix'a, или даже с ним не может.
Я абсолютно все описал выше. Не виноват я в том, что не все читают по существу. Это известная дельфинячая проблема
Отшлю, наверное на форум ib. Поиск по словам: "не восстанавливается backup"
Здравствуйте, OLEGus1, Вы писали:
КД>>Мне папа в детстве говорил "Доказать можно только собственную глупость"
OLE>Не хочу рушить мнение, навязанное ранее безусловным авторитетом, но ты не думаешь, что вера в недоказуемое, слепа?
Я вообще уже не думаю. Текущий размер базы, с которой я имею дело — 11.7GB
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Пацак, Вы писали:
П>Большая база — долгий бэкап П>Маленькая база — короткий бэкап П>Где-то здесь есть противоречие?
Противоречие самое простое. Не всегда есть время на этот "долгий" бекап. И он не долгий, а ОЧЕНЬ долгий. Необоснованно долгий.
По сравнению с другими СУБД.
П>Впрочем для особо нетерпеливых в FB2 сделан инкрементальный бэкап.
Аналогично.... Билинг... Рубим fb_inet_service, рубин inetd и в логах наслаждаемся попутками юзерей присоедениться к базе
П>Раз в пятилетку и валенок стреляет. Никто не мешает проверять восстановимость бэкапа сразу после того, как он был сделан.
Но восстановить то его все равно не получится. Так что проку от этой проверки..... Как и от бэкапа
Здравствуйте, Alex.Che, Вы писали:
AC>Угу. А про ключики gbak'a мы и не догадываемся...
Вы, наверное, и не догадываетесь
OLE>>> А еще веселее становится, когда развернуться база не может без gfix'a, или даже с ним не может. O>> Я абсолютно все описал выше. Не виноват я в том, что не все читают по существу.
AC>Ты нихрена не сказал "по существу".
А выше не существо? Битый бэкап это не существо?
AC>Отошли, отошли.
Здравствуйте, OLEGus1, Вы писали:
OLE>Противоречие самое простое. Не всегда есть время на этот "долгий" бекап. И он не долгий, а ОЧЕНЬ долгий. Необоснованно долгий. OLE>По сравнению с другими СУБД.
Список "других СУБД", позволяющих делать мгновенный бэкап в онлайне — в студию.
П>>Впрочем для особо нетерпеливых в FB2 сделан инкрементальный бэкап. OLE>Аналогично.... Билинг... Рубим fb_inet_service, рубин inetd и в логах наслаждаемся попутками юзерей присоедениться к базе
И к чему ты это сказал?
OLE>Но восстановить то его все равно не получится. Так что проку от этой проверки..... Как и от бэкапа
Прок будет очень большой — ты не будешь надеяться на этот бэкап, а сделаешь новый. Либо найдешь кривизну в базе.
Здравствуйте, OLEGus1, Вы писали:
КД>>Я вообще уже не думаю. Текущий размер базы, с которой я имею дело — 11.7GB
OLE>Думаю, что моя скоро тоже дорастет до таких размеров, но это будет лишь однобокая гордость, дабы хвастаться на форумах. А проблем гораздо больше.
Но это будут твои проблемы.
... детский сад, какой-то.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
П>>Список "других СУБД", позволяющих делать мгновенный бэкап в онлайне — в студию. OLE>Где я говорил о "мгновенном"? О быстром-да.
Здравствуйте, Пацак, Вы писали:
П>И? Список-то где?
Ну sybase у меня на аналогичной базе работает. Бекап, не моментальный, но быстрый. Намного быстрее. Но у sybasа свои недостатки
OLE>>Дельфинячье передергивание слов.
П>Я дельфи последний раз года два-три назад юзал.
Надо же, не угадал
П>Флаг в руки, кто мешает? Покупай DB2 или Oracle.
О. Вот и ответ на главный вопрос темы. Сами дошли
Оракль, кстати не такой и дорогой вообще то.
Здравствуйте, OLEGus1, Вы писали:
КД>>Но это будут твои проблемы.
OLE>А они мне нужны? Неа. Вот поэтому фаерберд буду использовать только в определенном круге задач, но никак не для больших проектов
Про флаг тут уже говорили. Поэтому скажу спасибо за очень познавательную беседу.
Да я и сам всегда и всем говорю — нас спасет Оракл. Большинство, услышав знакомое слово, радостно кивает головами.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Пацак, Вы писали:
П>В online?
нет, конечно, но речь идет не о часах фаребирда, а о минутах.
П>... и его ты тоже "будешь использовать только в определенном круге задач, но никак не для больших проектов "
Его я не планирую использовать. Вот будет чтото типа pl/sql а для субаса, тогда начну.
П>Не дошли, а послали.
Не послали, а натолкнули.
Здравствуйте, Пацак, Вы писали:
П>Список "других СУБД", позволяющих делать мгновенный бэкап в онлайне — в студию.
Oracle устроит? На выбор: либо инкрементальный бэкап, мгновенный, либо частичный/полный со скоростью физического копирования файлов (то есть потратится столько времени, сколько займет копирование файлов данных по F5).
Здравствуйте, OLEGus1, Вы писали:
П>>В online? OLE>нет, конечно,
Тогда какого ты их сравниваешь?
OLE>но речь идет не о часах фаребирда, а о минутах.
Дык! Отключи всех пользователей, останови СУБД и F5 — будут тоже минуты.
П>>... и его ты тоже "будешь использовать только в определенном круге задач, но никак не для больших проектов " OLE>Его я не планирую использовать. Вот будет чтото типа pl/sql а для субаса, тогда начну.
Ну что ж... Нет щастя в жизне (с) известная татуировка.
П>>Не дошли, а послали. OLE>Не послали, а натолкнули.
Послали-послали. Так что вперед — на оракл, и не мешай нашему интербейсному счастью.
Здравствуйте, Пацак, Вы писали:
П>Дык! Отключи всех пользователей, останови СУБД и F5 — будут тоже минуты.
Ну не хочу я Ф5. Хочу bak и fix. Что бы было по фаребедному закону
П>Ну что ж... Нет щастя в жизне (с) известная татуировка.
Как ты прав. Единственная отдушина — Оракль
П>Послали-послали. Так что вперед — на оракл, и не мешай нашему интербейсному счастью.
Ну человек спрашивал, что выбрать...... Я помог..... Теперь ему выбирать
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Но это будут твои проблемы.
OLE>А они мне нужны? Неа. Вот поэтому фаерберд буду использовать только в определенном круге задач, но никак не для больших проектов
А вот всегда интересовало, для чего использовать разные базы для разных проектов?
Лично я всегда пользую оракл, хоть для веб сайтов (иногда правда mysql. но там где нельзя оракл поставить
Какие + в пользу использования например того же firebird перед ораклом?
Здравствуйте, Mikst, Вы писали:
M>Какие + в пользу использования например того же firebird перед ораклом?
У него один плюс. Он может быть встроенным.
Но. Оракль ведь не отстает
OLE>нет, конечно, но речь идет не о часах фаребирда, а о минутах.
Стоп-стоп, у Субейса разьве бакап не онлайновый? Это на столько тривиально делается, что по идее должен быть онлайновый...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, OLEGus1, Вы писали:
OLE>>нет, конечно, но речь идет не о часах фаребирда, а о минутах. M>Стоп-стоп, у Субейса разьве бакап не онлайновый? Это на столько тривиально делается, что по идее должен быть онлайновый...
А фиг его. не пробовал. Жалко базу.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Mikst, Вы писали:
M>>Какие + в пользу использования например того же firebird перед ораклом?
П>Оракл штука большая и дорогая...
Большая понятие относительное, что значит "большая"?
дорогая — так уже бесплатный делают. (а для мелких проектов его всегда и так можно взять, всеравно никто не проверяет )
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Mikst, Вы писали:
M>>Какие + в пользу использования например того же firebird перед ораклом?
П>Оракл штука большая и дорогая...
Большая-да, но стоимость (150 у.е подкл) с лихвой окупается надежностью. Повторю: для больших проектов имеет смысл. А для небольших есть постгря. но это уже другая история
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Пацак, Вы писали:
П>>Здравствуйте, Mikst, Вы писали:
M>>>Какие + в пользу использования например того же firebird перед ораклом?
П>>Оракл штука большая и дорогая...
OLE>Большая-да, но стоимость (150 у.е подкл) с лихвой окупается надежностью. Повторю: для больших проектов имеет смысл. А для небольших есть постгря. но это уже другая история
Ну вот еще и постгря вылезла. Вот мне и интересно, я всегда и везде юзаю ораклу, только для вебов изредка майскуль чтобы на хостингах работало. И не тянет на что либо другое. Поэтому и хочется услышать аргументы тех, кто делал такой выбор.
Здравствуйте, Пацак, Вы писали:
П>Сделали уже кажись. Интересно было бы глянуть на лицензию — что можно, что нет.
Девелоперская лицензия у них всегда бесплатна была (ну может не всегда, а давно)
Но ведь тебя никто не заставляет релизиться. Так и ходи в бетах (это если чистота нужна)
Единственное ограничение-одно место(тоже условное)
Здравствуйте, Mikst, Вы писали:
M>Ну вот еще и постгря вылезла. Вот мне и интересно, я всегда и везде юзаю ораклу, только для вебов изредка майскуль чтобы на хостингах работало. И не тянет на что либо другое. Поэтому и хочется услышать аргументы тех, кто делал такой выбор.
Ну про фаребирд все не просто а очень просто. Она маленькая, в т.ч. встроенная. Сносно работает и под виндой и под никсом, И. Именно И. Очень быстро на дельфях к ней интерфес делается. Потому как фб это наследие борланда.
Постгря нравится всем, кому не нравится фб. Не распространена из-за того, что только недавно появилась версия под вынь
Мускуль прост и неплох. но не встроенный.
К ораклю, действительно нет вопросов, но дистрибутив безумно тяжелый. И ему, конечно лучше выделять сервер.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Mikst, Вы писали:
M>>Большая понятие относительное, что значит "большая"?
П>Большая — значит большая. По всем параметрам.
а FB не "большая"? Установка по умолчанию да, больше гига, но при желании обрезается помоему метров до 150 помоему.
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Mikst, Вы писали:
OLE>Ну про фаребирд все не просто а очень просто. Она маленькая, в т.ч. встроенная.
Никак до меня не дойдет значение слова "встроенная", во что?
>Сносно работает и под виндой и под никсом, И. Именно И. Очень быстро на дельфях к ней интерфес делается. Потому как фб это наследие борланда.
А что там специального кроме DBgrid и Query?
OLE>Постгря нравится всем, кому не нравится фб. Не распространена из-за того, что только недавно появилась версия под вынь
OLE>Мускуль прост и неплох. но не встроенный.
OLE>К ораклю, действительно нет вопросов, но дистрибутив безумно тяжелый. И ему, конечно лучше выделять сервер.
Один компакт, атомарная единица переноса информации. Да и про сервер, так от задач зависит.
Здравствуйте, Mikst, Вы писали:
M>Никак до меня не дойдет значение слова "встроенная", во что?
Это когда таскаешь с собой одну дллину, которая рулит локальной базой. Без сервера
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Mikst, Вы писали:
M>>а FB не "большая"? Установка по умолчанию да, больше гига, но при желании обрезается помоему метров до 150 помоему.
OLE>Эээээ. Ну у меня он 9 метров занимает. полный сервер
Здравствуйте, Mikst, Вы писали:
M>Здравствуйте, OLEGus1, Вы писали:
OLE>>Здравствуйте, Mikst, Вы писали:
M>>>а FB не "большая"? Установка по умолчанию да, больше гига, но при желании обрезается помоему метров до 150 помоему.
OLE>>Эээээ. Ну у меня он 9 метров занимает. полный сервер
M>Он это FB ?
ага
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Mikst, Вы писали:
M>>Здравствуйте, OLEGus1, Вы писали:
OLE>>>Здравствуйте, Mikst, Вы писали:
M>>>>а FB не "большая"? Установка по умолчанию да, больше гига, но при желании обрезается помоему метров до 150 помоему.
OLE>>>Эээээ. Ну у меня он 9 метров занимает. полный сервер
M>>Он это FB ? OLE>ага
Учту. Обещаю провести эксперимент по обрезанию ораклы Результаты сообщу дополнительно.
Здравствуйте, Mikst, Вы писали:
M>Никак до меня не дойдет значение слова "встроенная", во что?
Это когда твоя прога сама себе сервер, сама себе клиент. Очень удобно для небольших программулин, не требующих коллективной работы.
M>А что там специального кроме DBgrid и Query?
Компоненты доступа. Причем нескольких видов, например FibPlus.
M>Один компакт, атомарная единица переноса информации.
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Mikst, Вы писали:
M>>Учту. Обещаю провести эксперимент по обрезанию ораклы Результаты сообщу дополнительно.
OLE>А еще у оракль штатно на фре не пашет. вот это погано.
Не знал (мне по душе линух), но ведь всеравно ставится при умении.
Здравствуйте, Horror_Infinity, Вы писали:
H_I> Но в кратце — правтически аналог MSDE по условиям распространения.
SQL Express... Даже по ограничениям...
Отличаются только размером дистрибутива Сиквел 34Мб (без .Net), а Оракл ~150Мб...
Здравствуйте, Merle, Вы писали:
M>SQL Express... Даже по ограничениям... M>Отличаются только размером дистрибутива Сиквел 34Мб (без .Net), а Оракл ~150Мб...
Ну да... При этом у сиквела вообще нет средств администрирования, а тот же Oracle Express предоставляет WEB-интерфейс. Так что, данное преимущество MS представляется мне весьма сомнительным.
Здравствуйте, Mikst, Вы писали:
M>А в чем тут преимущества MS ? в размере дистрибутива на 100 метров?? Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
Об чем и речь!.. Я только вчера на установку MSDE на машину с ХРенью Хоме Епишн потратил часа полтора. Ну никак он не желал ставиться по дефолту с дефолтовым же инстансом. Вроде бы, ошибок нет, все ровно и спокойно. Но на все попытки коннека — хрен по всей морде. Причину так и не нашел. В результате замутил хитрющий инстанс, правда, пришлось на ходу переписывать скрипты установки базы и клиентской проги, на что ушло еще полтора часа... Поубивал бы! Тот же Oracle Express ставится полностью минут за 15.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Mikst, Вы писали:
M>>Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
П>Вы по-моему очень много кушать (с) Ширли-Мырли. Если сама прога — метров десять то таскать и ставить ради нее гиговый дистр — несколько неразумно ИМХО.
Если сама прога метров 10 то для нее пойдут и текстовые файлы (иль майскуль на худой конец). зачем монстра типа мса и ораклы??
Да и если на то пошло, большой размер дистра не значит большой инсталяции.
PS: можно "поставить" мскуль без инсталятора? а например простым копированием?
Здравствуйте, Mikst, Вы писали:
M>Если сама прога метров 10 то для нее пойдут и текстовые файлы (иль майскуль на худой конец). зачем монстра типа мса и ораклы??
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, Mikst, Вы писали:
M>>Если сама прога метров 10 то для нее пойдут и текстовые файлы (иль майскуль на худой конец). зачем монстра типа мса и ораклы??
П>Затем, что база может быть 10 Гиг.
Здравствуйте, Пацак, Вы писали:
П>Вы по-моему очень много кушать (с) Ширли-Мырли. Если сама прога — метров десять то таскать и ставить ради нее гиговый дистр — несколько неразумно ИМХО.
Возможно. Моменты спорные. Но мы о разных вещах говорим: гиговый дистр — это полноценный сервак. Да и не гиговый он вовсе, чуть меньше. Мы про MSDE и Oracle Express. Которые сиречь персональные версии, хотя и через сетку с ними работать тоже можно. Но Oracle предпочтительнее, поскольку он — Oracle. И кроссплатформенный к тому же, что для MS немыслимо в принципе. А если у клиента на машине Linux стоит? Мне что, заставлять его ставить MS Windows? Да ну нафиг!
Здравствуйте, Mikst, Вы писали:
H_I>>Ну да... При этом у сиквела вообще нет средств администрирования, а тот же Oracle Express предоставляет WEB-интерфейс. Так что, данное преимущество MS представляется мне весьма сомнительным.
M>А в чем тут преимущества MS ? в размере дистрибутива на 100 метров?? Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
Ну я, допустим Когда к админам приходят люди и просят установить Oracle на нотебук, как ты думаешь им нужно отвечать?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Mikst, Вы писали:
H_I>>>Ну да... При этом у сиквела вообще нет средств администрирования, а тот же Oracle Express предоставляет WEB-интерфейс. Так что, данное преимущество MS представляется мне весьма сомнительным.
M>>А в чем тут преимущества MS ? в размере дистрибутива на 100 метров?? Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта? GZ>Ну я, допустим Когда к админам приходят люди и просят установить Oracle на нотебук, как ты думаешь им нужно отвечать?
Не знаю Поставить ораклю? (зы: стоит 9ка на PII-350 и работает, чем нотебук хужее?)
GZ>С уважением, Gleb.
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Ну да... При этом у сиквела вообще нет средств администрирования, а тот же Oracle Express предоставляет WEB-интерфейс.
Есть там средства администрирования, только скачиваются отдельно. Весят всего несколько метров.
Здравствуйте, Mikst, Вы писали:
M>А в чем тут преимущества MS ? в размере дистрибутива на 100 метров??
Заметте, о преимуществах начал говорить не я, я говорил об отличиях..
M>Простите, а сейчас кто-то считает в единицах меньше 1 гигабайта?
Очень многие.
Здравствуйте, Horror_Infinity, Вы писали:
H_I> Но Oracle предпочтительнее, поскольку он — Oracle.
Правильно, повесим в рамочку, а работать все равно с сиквелом будем..
H_I> И кроссплатформенный к тому же, что для MS немыслимо в принципе. А если у клиента на машине Linux стоит? Мне что, заставлять его ставить MS Windows? Да ну нафиг!
Правильно, нафиг такого клиента!
Здравствуйте, Horror_Infinity, Вы писали:
H_I> Тот же Oracle Express ставится полностью минут за 15.
Но не везде..
Кстати, инсталлятор там все еще явовский? Вот уж за что поубивав-бы...
Здравствуйте, Mamut, Вы писали:
M>>PS: можно "поставить" мскуль без инсталятора? а например простым копированием?
M>Можно. Таким образом его ставит, например, Денвер. Да и я после переустановки системы его так "устанавливаю"
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Ага... И нафига?
Это уж тебе решать.
H_I> Забыл я их скачать. Да и не нужны они мне.
Так забыл или не нужны?
H_I> А вот пришел к клиенту — опа! Надо! А нету! И инета нету. Что делать будем?
Во-первых выяснять заранее, во-вторых включать в дистрибутив, если идем к неизвестному клиенту и приложение предполагает использование средств администрирования. То есть вы, как разработчики должны решить нужно вашему заказчику вашу базу администрить или нет, а не заказчик..
SQL Express позиционируется как СУБД в составе готового решения, и с этих позиций предполагается, что ваше приложение обеспечит весь необходимый функционал, благо сиквел традиционно требует минимум усилий по администрированию.
Ну а если нет, то можно скачать тулзу отдельно, поэтому такое решение более чем оправдано. Зачем пихать в дистрибутив приложение, которое в 90% случаев окажется не нужным?
M>>>PS: можно "поставить" мскуль без инсталятора? а например простым копированием?
M>>Можно. Таким образом его ставит, например, Денвер. Да и я после переустановки системы его так "устанавливаю"
M>Это радует. Насколько сложно это?
Ээээ. Берется папка с Мускулом и копируется Более того, можно копировать и отдельные базы (поддиректория data/имя_базы/) с сервера на сервер.
Один из способов бэкапа, кстати — это просто скопировать базу в какое-нить другое место
Здравствуйте, Mamut, Вы писали:
M>>>>PS: можно "поставить" мскуль без инсталятора? а например простым копированием?
M>>>Можно. Таким образом его ставит, например, Денвер. Да и я после переустановки системы его так "устанавливаю"
M>>Это радует. Насколько сложно это?
M>Ээээ. Берется папка с Мускулом и копируется Более того, можно копировать и отдельные базы (поддиректория data/имя_базы/) с сервера на сервер.
А всякие registry прописывать не требуется?? сервисы ставить?? и прочую дребедень?
M>Один из способов бэкапа, кстати — это просто скопировать базу в какое-нить другое место
На "лету" и что потом с этим мусорным файлом делать?
А не на лету, в оффлайне, это можно любую базу копировать.
M>>Ээээ. Берется папка с Мускулом и копируется Более того, можно копировать и отдельные базы (поддиректория data/имя_базы/) с сервера на сервер.
M>А всякие registry прописывать не требуется?? сервисы ставить?? и прочую дребедень?
Да нет, не надо. После копирования достаточно запустить поставляемый с ней же mysqladmin.
M>>Один из способов бэкапа, кстати — это просто скопировать базу в какое-нить другое место
M>На "лету" и что потом с этим мусорным файлом делать? M>А не на лету, в оффлайне, это можно любую базу копировать.
На лету я, по-моему, тоже копировал. Правда, с базой в тот момент никто не работал.
пока ждал вразумительных ответов и советов,
поставил FB 1.5, пощупал сверху...
По сравнению с ORACLE — детский лепет.
Ну а для тех кто под Delphi- берите ODAC и Оракловый клиент не нужен.
На моей памяти сам сервер под НТ работал без останова 4 года, может и продолжает работать, ушел, боле не знаю
Здравствуйте, OLEGus1, Вы писали:
OLE>Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не для этого.
1. Биллинг бывает разный.
2. Вообще вопрос был в отличиях.
3. Бывает так, что супер-мега-фичи Оракла как и MsSql оказываются не нужны.
4. Но там где нужны — светлая дорога им.
5. Но если рассматривать сектор Embedded, то MSDE не является таким... OraExpress пожалуй тоже.
OLEGus1 wrote:
> C>При этом embedded FireBird помещается в 2Мб. Сколько у нас Оракл > минимум > C>займет? > C>Вообще, FB — это не самая фичастая база (никто и не спорит). > Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не > для этого.
С чего бы? С типичными задачами биллинга даже MySQL справляется. Никаких
крутых view-шек и триггеров для этого не надо, все обычным CRUDом делается.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, OLEGus1, Вы писали:
OLE>>Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не для этого. F> 1. Биллинг бывает разный. F> 2. Вообще вопрос был в отличиях. F> 3. Бывает так, что супер-мега-фичи Оракла как и MsSql оказываются не нужны. F> 4. Но там где нужны — светлая дорога им. F> 5. Но если рассматривать сектор Embedded, то MSDE не является таким... OraExpress пожалуй тоже.
Все хорошо, но! Сейчас супер-мега фичи может быть и не нужны, а что будет дальше? Никто не знает.
Лично я выбираю сразу оракле и не парюсь, конечно если embedded действительно необходим (широкое распостранение проги например) то это уже является одним из решающих факторов, но а если прога пишется чтобы ставить ее по заказу ограниченному кругу заказчиков, то тут (IMHO) нет особого смысла выделываться с ембеддед, дабы потом не изобретать нечто (например делать многопользовательскую систему).
Mikst wrote:
> Все хорошо, но! Сейчас супер-мега фичи может быть и не нужны, а что > будет дальше? Никто не знает.
А вы сразу кластерный Oracle 10g ставите? Или предпочитаете брать
мейнфреймы от IBM?
Если уж чего-то совсем страшное надо будет делать, то поменять
использование MySQL на что-то другое — проблем больших не составит. А
Oracle стоит $5000, между прочим.
Здравствуйте, Cyberax, Вы писали:
C>Если уж чего-то совсем страшное надо будет делать, то поменять C>использование MySQL на что-то другое — проблем больших не составит.
Это, кстати, несколько сомнительно.
C>Oracle стоит $5000, между прочим.
А вот тут уже чертовски интересно, откуда Вы взяли эту цифру. Если попыхтеть, можно будет получить лицензию именно такой стоимости, но крайне уж цифра нетипична.
Здравствуйте, Cyberax, Вы писали:
C>Mikst wrote:
>> Все хорошо, но! Сейчас супер-мега фичи может быть и не нужны, а что >> будет дальше? Никто не знает.
C>А вы сразу кластерный Oracle 10g ставите? Или предпочитаете брать C>мейнфреймы от IBM?
С обычного оракла перейти на кластерный, действительно не проблема, а вот с MySQL на оракл (как впрочем слюбой бд на любую другую) уже сложнее. Если конечно в приложении кроме insert select больше ничего нет, то не вопрос.
C>Если уж чего-то совсем страшное надо будет делать, то поменять C>использование MySQL на что-то другое — проблем больших не составит. А C>Oracle стоит $5000, между прочим.
КУпиту у меня за половину стоимости отдам а сам возьму бесплатный, ну или на крайняк ровно в 10 раз дешевле.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Здравствуйте, Mikst, Вы писали:
M> Если конечно в приложении кроме insert select больше ничего нет, то не вопрос.
Да не скажите. Вот буквально пару дней назад некий мигрант искал, где же в Oracle оператор, если не изменяет память, INSERT DELAYED. А оказалось, что ему этот оператор вообще не нужен.
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Mikst, Вы писали:
M>> Если конечно в приложении кроме insert select больше ничего нет, то не вопрос.
S>Да не скажите. Вот буквально пару дней назад некий мигрант искал, где же в Oracle оператор, если не изменяет память, INSERT DELAYED. А оказалось, что ему этот оператор вообще не нужен.
Я имел ввиду, что используются ТОЛЬКО конструкции типа insert into table (bla,bla,bla) values(bla,bla);
и все. никаких _вольностей и расширений_
Здравствуйте, Mikst, Вы писали:
M>Здравствуйте, Softwarer, Вы писали:
S>>Здравствуйте, Mikst, Вы писали:
M>>> Если конечно в приложении кроме insert select больше ничего нет, то не вопрос.
S>>Да не скажите. Вот буквально пару дней назад некий мигрант искал, где же в Oracle оператор, если не изменяет память, INSERT DELAYED. А оказалось, что ему этот оператор вообще не нужен.
M>Я имел ввиду, что используются ТОЛЬКО конструкции типа insert into table (bla,bla,bla) values(bla,bla); M>и все. никаких _вольностей и расширений_
причем даже если синтаксически все заработает, никто не гарантирует правильности работы алгоритмов (вспомните интербейз с его удалением дубликатов )
Softwarer wrote:
> C>Если уж чего-то совсем страшное надо будет делать, то поменять > C>использование MySQL на что-то другое — проблем больших не составит. > Это, кстати, несколько сомнительно.
Мы так делали, из проблем вспоминается только то, что в MySQL был слегка
другой синтаксис для bulk insert.
> C>Oracle стоит $5000, между прочим. > А вот тут уже чертовски интересно, откуда Вы взяли эту цифру. Если > попыхтеть, можно будет получить лицензию именно такой стоимости, но > крайне уж цифра нетипична.
Mikst wrote:
> C>Если уж чего-то совсем страшное надо будет делать, то поменять > C>использование MySQL на что-то другое — проблем больших не составит. А > C>Oracle стоит $5000, между прочим. > КУпиту у меня за половину стоимости отдам а сам возьму бесплатный, ну > или на крайняк ровно в 10 раз дешевле.
Серьезно? Официальную процессорную лицензию с тех. поддержкой?
Здравствуйте, Cyberax, Вы писали:
C>Mikst wrote:
>> C>Если уж чего-то совсем страшное надо будет делать, то поменять >> C>использование MySQL на что-то другое — проблем больших не составит. А >> C>Oracle стоит $5000, между прочим. >> КУпиту у меня за половину стоимости отдам а сам возьму бесплатный, ну >> или на крайняк ровно в 10 раз дешевле.
C>Серьезно? Официальную процессорную лицензию с тех. поддержкой?
А кто говорил про процессорную еще и с тех поддержкой? Мы же говорим об оракле как о заменителе Mysql — так для этого и что попроще сойдет.
Или к mysql тоже поддержка прилагается (он вроде тоже перестает бесплатным быть)
Здравствуйте, Cyberax, Вы писали:
C>Мы так делали,
Хм. Из разового эксперимента может следовать возможность проблем, но не может — невозможность
Все же вопрос, что именно делали. Я как-то приспосабливал программу Perl+MySQL, чтобы она запустилась на Oracle — на простенькую вещь из нескольких тысяч строк и нескольких таблиц ушел почти день.
Ну а из общих соображений — прямо скажем, разницы хватает, а проблемы переноса софта на другой сервер обсуждались тысячекратно.
C> из проблем вспоминается только то, что в MySQL был слегка другой синтаксис для bulk insert.
Хм. Признаться, не знал о наличии в Oracle специального синтаксиса для bulk insert, доступного не из хранимого кода.
C>http://www.oracle.com/corporate/pricing/eplext.pdf C>"Standard Edition One — $4995".
Mikst wrote:
> C>Серьезно? Официальную процессорную лицензию с тех. поддержкой? > А кто говорил про процессорную еще и с тех поддержкой? Мы же говорим > об оракле как о заменителе Mysql — так для этого и что попроще сойдет.
Персональная/lite-линцезия скорее всего не подойдет. Дальше у нас идут
уже коммерческие лицензии.
> Или к mysql тоже поддержка прилагается (он вроде тоже перестает > бесплатным быть)
Он сам бесплатен, а поддержка в разы дешевле будет.
Softwarer wrote:
> C>Мы так делали, > Хм. Из разового эксперимента может следовать возможность проблем, но > не может — невозможность > Все же вопрос, что именно делали. Я как-то приспосабливал программу > Perl+MySQL, чтобы она запустилась на Oracle — на простенькую вещь из > нескольких тысяч строк и нескольких таблиц ушел почти день.
В MySQL нет view'шек, триггеров, хранимых процедур — поэтому надо
править только запросы. В силу их примитивности это тоже обычно несложно.
> C> из проблем вспоминается только то, что в MySQL был слегка другой > синтаксис для bulk insert. > Хм. Признаться, не знал о наличии в Oracle специального синтаксиса для > bulk insert, доступного не из хранимого кода.
Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном
INSERT это делать.
Здравствуйте, Cyberax, Вы писали:
>> Хм. Признаться, не знал о наличии в Oracle специального синтаксиса для >> bulk insert, доступного не из хранимого кода.
C>Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном C>INSERT это делать.
Что "это"? Я всю жизнь считал, что синтаксис insert и bulk insert в Oracle никак не отличается, если не считать дополнительно введенного в PL/SQL оператора forall. Можете показать, что вы писали на MySQL и на Oracle (по несколько строк, просто чтобы понять)?
Softwarer wrote:
> C>Ну так и сделали, собственно говоря. Просто в MySQL можно в обычном > C>INSERT это делать. > Что "это"? Я всю жизнь считал, что синтаксис insert и bulk insert в > Oracle никак не отличается, если не считать дополнительно введенного в > PL/SQL оператора forall. Можете показать, что вы писали на MySQL и на > Oracle (по несколько строк, просто чтобы понять)?
Было что-то типа "INSERT INTO table1 VALUES (12,231,45), (243,435,123),
...." в Оракле оно так не заработало. Еще были маленькие проблемы с
разными именами типов, но больше ничего не вспомню такого фатального.
Softwarer wrote:
> C>Было что-то типа "INSERT INTO table1 VALUES (12,231,45), (243,435,123), > За такое оракловские админы склонны отрывать разработчикам руки, если > дотянутся
Почему, кстати? Вроде бы ничего особого — для bulk'ов вполне сойдет.
> C> но больше ничего не вспомню такого фатального. > Фатального нет, но чем сложнее проект — тем сложнее переносить.
Здравствуйте, Cyberax, Вы писали:
>> За такое оракловские админы склонны отрывать разработчикам руки, Почему, кстати? Вроде бы ничего особого — для bulk'ов вполне сойдет.
Потому что неиспользование bind variables в данном случае приводит к совершенно напрасным тратам процессора и памяти.
>> Фатального нет, но чем сложнее проект — тем сложнее переносить. C>Но это не причина сразу его делать на Оракуле.
Здравствуйте, Cyberax, Вы писали:
>> C> но больше ничего не вспомню такого фатального. >> Фатального нет, но чем сложнее проект — тем сложнее переносить.
C>Но это не причина сразу его делать на Оракуле.
Совершенно справедливо: каждому серверу — собственная ниша, где именно он и нужен будет. Честно — ну не понимаю я людей, которые стараются воткнуть везде и непременно Оракла только потому, что это круто. А в чем тут крутость? Для огромного множества задач вполне сойдет и MS SQL, если не Firebird. Хотя, если оправдывать установку Оракла кривостью своих рук и неумением переписать код так, чтоб он работал, а не глючил, тогда конечно... Но, может быть, тогда нужно будет просто выгнать разработчика?
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Здравствуйте, Cyberax, Вы писали:
>>> C> но больше ничего не вспомню такого фатального. >>> Фатального нет, но чем сложнее проект — тем сложнее переносить.
C>>Но это не причина сразу его делать на Оракуле.
H_I>Совершенно справедливо: каждому серверу — собственная ниша, где именно он и нужен будет. Честно — ну не понимаю я людей, которые стараются
воткнуть везде и непременно Оракла только потому, что это круто. А в чем тут крутость?
Не потому что круто, а потому что в будущем проблем не вызывает.
Для огромного множества задач вполне сойдет и MS SQL,
я бы понял если бы сказали "вполне сойдет и My SQL", а так получается что MS жалкая пародия на базу гыгы
если не Firebird. Хотя, если оправдывать установку Оракла кривостью своих рук и неумением переписать код так, чтоб он работал, а не глючил, тогда конечно... Но, может быть, тогда нужно будет просто выгнать разработчика?
Все СУБД разные. часто вижу топики, был Access хотим MS, был ХХ хотим YY потому что XX уже не справляется. Так вот зачем заранее себе яму копать? Я использую две базы MySQL и oracle. Какой мне резон разбираться еще с десятком заведомо менее "фичастых" СУБД, а потом сидеть и думать, блин, а вот в оракле я бы так написал и красота, а тут сиди и велосипед изобретай. Если я точно знаю кто ничего такого никогда не понадобится , (для веба обычно) ставлю mysql и вперед, хватает по самые помидоры. В итоге никогда не имел геммороя с переписывание приложений под другую субд, из-за того что ранее выбранная стухла.
Здравствуйте, Mikst, Вы писали:
M>я бы понял если бы сказали "вполне сойдет и My SQL", а так получается что MS жалкая пародия на базу гыгы Да в общем-то что-то типа того. MS плохо держит нагрузку. Хотя, это возможно от кривости проектирования БД. Но БД не моя, и менять что-то внутри нее я не имею права. И получается, что при числе коннектов всего лишь 100-110 — тормоза. Не сильные, но неприятные. Аналогичные запросы на Oracle при том же числе коннектов выполняются в 3-4 раза быстрее. И это без специальной оптимизации. Да и функционал MS SQL все же бедноват.
Но я не про то. Я про то, что каждому серверу — свой круг выполняемых задач. Лично я тоже выбираю Oracle. Не по причине крутости, а по причине простоты реализации многих модулей. Я как-то привык, что есть пакеты. И я не ковыряюсь в тысячах ХП в поисках нужной. Процедуры/функции объединены в пакеты, пакеты объединены в бизнесы — и всех забот.
З.Ы. Предлагаю прекратить бесплодный спор. Выбор СУБД — это исключительно личное дело.
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Но я не про то. Я про то, что каждому серверу — свой круг выполняемых задач. Лично я тоже выбираю Oracle. Не по причине крутости, а по причине простоты реализации многих модулей. Я как-то привык, что есть пакеты. И я не ковыряюсь в тысячах ХП в поисках нужной. Процедуры/функции объединены в пакеты, пакеты объединены в бизнесы — и всех забот.
H_I>З.Ы. Предлагаю прекратить бесплодный спор. Выбор СУБД — это исключительно личное дело.
Так об этом я и не спорил. Мне просто было интересно почему некоторые начинают думать так "я вот раьнше делала на Оракле (читай любой мощной СУБД-МСУБД ), а теперь мне задачку надо простеньку сделать, зачем мне МСУБД, когда можно взять мСУБД (мини), а потом обрести гемморой при расширении и наступить на грабли при изучении новой системы.
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Cyberax, Вы писали:
C>>При этом embedded FireBird помещается в 2Мб. Сколько у нас Оракл минимум C>>займет?
C>>Вообще, FB — это не самая фичастая база (никто и не спорит).
OLE>Блин, ну сколько можно. Человеку СУБД нужна для биллинга. Фаребирд не для этого.
А я таки согласен, что Firebird плохо подходит для биллинга. Если не ошибаюсь, задачи биллинга подразумевают массированные вставки данных. На таких задачах классические версионники, к числу которых относится Firebird, — не самый лучший выбор. Это связано с тем, каким образом данная СУБД хранит версии записей и делает операцию commit.
При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает. Если постановка задачи подразумевать какую-то фиксированную скорость в TPC, то в случае Firebird можно крепко огрестись. С PostgreSQL, кстати, похожая ситуация.
Цитата из Дмитрия Кузьменко, известнейшего авторитета по Interbase/Firebird:
Накопление мусора, конечно, влияет на производительность. Влияние может быть либо сильным либо слабым, все зависит как от количества накопленного мусора, так и от действий приложений. Известны редкие случаи, когда приложения удерживают активными очень много транзакций и производят очень много обновлений, и из-за накапливания мусора сервер начинает работать настолько медленно, что приходится его рестартовать (см. статью). Причем, замедление происходит как от чтения большого количества версий записей, так и от попыток их собрать как мусор. Больше всего влияет на скорость сборки мусора наличие неуникальных индексов — но эта проблема решена в InterBase 7.1 и Firebird 2.0.
Здравствуйте, slskor, Вы писали:
S>При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает.
Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Softwarer, Вы писали: А>просто нет многого привычного "хорошего".
А>- Можно 1 маленький пример: это можно и легко на Oracle и нельзя А>(или с большими трудностями) на FireBird
Из остро необходимого для бизнес-задач — standby-сервер.
Здравствуйте, Softwarer, Вы писали:
S>Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?
Боюсь, что при INSERT — никак он не накапливается. Но подмечено, что массированная вставка большого количества данных в коротких транзакциях сильно тормозит. Выход — делать длинную транзакцию на большое количество инсертов. Однако, до коммита эти данные будут не видны (ну, если исключить "грязное чтение"). К тому же, если на таблице много индексов, то перестройка их тоже займет немало времени. ИМХО.
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, slskor, Вы писали:
S>>При частых операциях insert/update мусор в Interbase/Firebird накапливается быстрыми темпами, производительность довольно быстро падает.
S>Боюсь, я не авторитет по IB, поэтому прошу пояснить: с какой стати при insert накапливается мусор?
Ха, вы поймали меня =) Действительно, мусор накапливается при update. При insert на массивных вставках в Interbase бывает другая проблема. Описана здесь: http://www.ibase.ru/devinfo/oitoat.htm
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Боюсь, что при INSERT — никак он не накапливается. Но подмечено, что массированная вставка большого количества данных в коротких транзакциях сильно тормозит. Выход — делать длинную транзакцию на большое количество инсертов. Однако, до коммита эти данные будут не видны (ну, если исключить "грязное чтение"). К тому же, если на таблице много индексов, то перестройка их тоже займет немало времени. ИМХО.
Это уже никак не зависит от "классического версионника" и прочих подобных факторов. Это уже объективная задача, трудная в любой архитектуре. По крайней мере до 10gR2 "массированная вставка большого количества данных в коротких транзакциях" и ораклу будет ой как не по душе. В 10gR2 вроде бы сделали BATCH COMMIT, что может быть поможет в таких случаях (личных впечатлений пока нет).
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Horror_Infinity, Вы писали:
H_I>>Боюсь, что при INSERT — никак он не накапливается.
S>Это уже никак не зависит от "классического версионника" и прочих подобных факторов.
Подчеркиваю, в оригинальном письме было "insert/update" написано. Что подразумевает не только массированную вставку, но и массированные изменения. И не надо переводить тему на более удобное для вас поле боя.
Здравствуйте, slskor, Вы писали:
S>Подчеркиваю, в оригинальном письме было "insert/update" написано.
Безусловно. Если уж хотите влететь и с update-ом — давайте про него.
S>И не надо переводить тему на более удобное для вас поле боя.
Итак — не затруднит ли Вас показать, где именно в задачах биллинга требуются "массовые update-ы", раз уж мы разобрались с insert-ами, и теперь только этим Вы обуславливаете непригодность FB для биллинга?
Наверное, стоит для начала определить, что есть "массовый" в контексте обсуждаемого вопроса. Насколько я понимаю, для этого операция должна быть регулярной и частой, во-вторых, нужно выбрать что-нибудь типа
— не менее N% от всех DML-операций по серверу в целом
— не менее N update-ов в рамках одной бизнес-функции
— не менее N конкурирующих пользователей, выполняющих по K апдейтов в рамках бизнес-функции
Здравствуйте, Softwarer, Вы писали:
S>Итак — не затруднит ли Вас показать, где именно в задачах биллинга требуются "массовые update-ы", раз уж мы разобрались с insert-ами, и теперь только этим Вы обуславливаете непригодность FB для биллинга?
То есть по-вашему биллинг — это только вставки? Было у меня как-то ТЗ на руках, в котором заказчик хотел 5 млн. операций вставки в день. Отчеты на несколько ближайших дней должны были быть детальными. Кроме того, должны были быть отчеты с аггрегированными данными за несколько лет в разных разрезах. Данная задача решаема только лишь на insert/select с приемлемой производительностью?
Здравствуйте, slskor, Вы писали:
S>То есть по-вашему биллинг — это только вставки?
Не перекладывайте на меня бремя доказательства. Вы выдвинули утверждение — Вы и доказывайте, что оно имеет место быть истинным. Обосновываете свою точку зрения массовыми апдейтами — значит, покажите, что они необходимы, причем именно массовые.
Например, пока что довольно забавно смотрится увязывание массовых апдейтов с расчетом агрегатов (такое впечатление, что Вы подразумеваете перерасчет агрегатов по каждому факту поступления новой записи).
S>Было у меня как-то ТЗ на руках,
Вполне нормальная постановка задачи, имхо.
S> Данная задача решаема только лишь на insert/select с приемлемой производительностью?
Прежде всего повторюсь, что бремя доказательства лежит на Вас.
Если Вы спрашиваете моего мнения, то "только лишь" — в смысле "ни одного апдейта нигде и никогда вообще" — не знаю, решаема или нет, но это извращение. Если же "без массовых апдейтов" — безусловно, решаема.
slskor wrote:
> S>Итак — не затруднит ли Вас показать, где именно в задачах биллинга > требуются "массовые update-ы", > Еще один пример: http://www.etracker.de > Попробуйте реализовать то же самое без аггрегирования данных, > поступающих в высоком темпе.
Лично делал подобное. Данные сначала складывались в очередь (сохраняемую
на диске в своем ОЧЕНЬ быстром формате), затем данные из этой очереди
затем скармливались системе правил, которая уже писала их в БД и делала
другие задачи.
При этом тоже был необходим real-time мониторинг некоторых потоков.
Решили очень просто — те потоки, которые в данный момент мониторились,
просто скармливались напрямую системе правил.
В качестве приятного дополнения была еще устойчивость к сбоям сервера БД.
Здравствуйте, slskor, Вы писали:
S>А я таки согласен, что Firebird плохо подходит для биллинга. Если не ошибаюсь, задачи биллинга подразумевают массированные вставки данных.
А я таки против Уже говорил, что биллинг бывает разный. Конкретики здесь насколько я помню никто особенной не приводил, разве, что... ОраЭкспресс разворачивается в гигабайт. От радость та какая... И тут возникает вопрос — откуда у "корпоративной" АТС на 100 номеров — массированные вставки данных?! А админы спят и видят, как бы все номера updat-ами перетосовать.
А такие маленькие программки которые пишут себе спокойно в Access (ох боже мой, ну почему не Firebird?!)... весьма находят применение.
Здравствуйте, Пацак, Вы писали:
П>Не вижу противоречий. Только не начинай опять старую песню "хочу моментально" — чудес не бывает.
Да что ж ты так любишь передергивать слова?
Говоришь, что не дельфинист...., но не "моментально", а "быстро". Нажимать ф5 руками меня ломает, для этого есть крон, а он не будет ждать, пока все удосужаться отвалиться от базы, а рубанет по живому. И результат получится не очень.
Ну и, конечно, множество недотатков у длинных транзакций уже описано выше. И, раз уж инстумент позволяет пользовать всю сессию в одной транзакции, причем гораздо проще, чем в нескольких, то народ так и будет реализовывать.
Слова, пустые слова, подумал Стормгрен. Слова, за которые прежде люди дрались и умирали, но никогда больше не станут за них ни умирать, ни драться. И от этого мир станет лучше.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Horror_Infinity, Вы писали:
H_I>> Тот же Oracle Express ставится полностью минут за 15. M>Но не везде.. M>Кстати, инсталлятор там все еще явовский? Вот уж за что поубивав-бы...
Чем явовский инсталлер-то не угодил? Не тормознутее(и гораздо менее глючный), чем ms installer. Да и не уйдут они от него — он один на все оси, а иначе для каждой свой писать надо...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Мы уже победили, просто это еще не так заметно...
Людей устраивает — люди пользуются.
Битый бэкап это не существо?
Причину так и не нашел. В результате замутил хитрющий инстанс, правда, пришлось на ходу переписывать скрипты установки базы и клиентской проги, на что ушло еще полтора часа... Поубивал бы! Тот же Oracle Express ставится полностью минут за 15.
Играет silent 
