Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 15   вперед  Ctrl
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Basil A. Sidorov
Yo.!
до сих пор не понимаю как под виндой оракл хом задать.
Никак. В буквальном смысле этого слова. Надо запустить OUI и удалить "ссылки на домики" из глобального окружения.

Чувак, ты не поверишь: set ORACLE_HOME=file_path
27 сен 14, 01:53    [16628577]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11469
Apex
Имелось в виду, что эти блоки не обязаны быть сброшенны в файлы сразу по команде commit, этот процесс растянут по времени, что позволяет сгладить пиковую нагрузку.
Я всё это понимаю, но точно также этот процесс растянут и при ForceWrite=Off у FB.
В конце-концов, времена, когда "винды линейки 9x" могли сутками не сбрасывать "грязные" кластеры на диск - давно прошли.
Сценарий интенсивных чтений-записей отлажен на файловых серверах, как минимум, к середине девяностых и "возбуждаться" на отложенную запись сейчас - немного странно.
27 сен 14, 07:41    [16628686]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11469
Apex
Чувак, ты не поверишь: set ORACLE_HOME=file_path
Я несколько о другом.
Если делается несколько установок, то в глобальных переменных ничего не должно быть.
Остальное прекрасно разруливается при запуске приложений конкретного "домика".
27 сен 14, 07:46    [16628688]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Basil A. Sidorov
Я всё это понимаю, но точно также этот процесс растянут и при ForceWrite=Off у FB.

Т.е. вы предлагаете вопрос целостности данных целиком и полностью делегировать железу?

Basil A. Sidorov
В конце-концов, времена, когда "винды линейки 9x" могли сутками не сбрасывать "грязные" кластеры на диск - давно прошли.

Да при чем здесь это? Да хоть на секунду до сбоя задержался грязный блок в кэшэ в то время как пользователь увидел Transaction commited и все, система уже ненадежна, важные данные ей не доверишь.

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

Простите, не напомните, и как часто у нас файловые сервера используются для транзакционныхз приложений?
27 сен 14, 08:58    [16628727]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Apex
sphinx_mv
пропущено...
Серверу (как классу) не первый десяток лет, но о "больших БД" на оном можно узнать только на "широко известных в узких кругах" конференциях... Из этого непосредственно следует вывод: реализаций действительно серьезных систем на firebird не так много (как это представляют его фанаты) - их количество теряется на "уровне шума"...

Тем не менее это не означает, что реализаций нет, правда? Они есть, они работают. Проблемы тоже есть, но они решаются. А уж для обозначенных выше размера базы и кол-ва пользователей, так вообще без проблем потянет. Другое дело, что там и недорогой SEO Oracle уж точно справится. Т.е. по-сути цена вопроса это от 5к долларов за ядро.
от 5к за сокет. SEO и SE лицензируются по сокетам.
27 сен 14, 10:05    [16628793]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Apex
Да хоть на секунду до сбоя задержался грязный блок в кэшэ в то время как пользователь увидел Transaction commited и все, система уже ненадежна

тут не хватает оговорки насчет надежности / отказоустойчивости оного кеша. Иначе все существующие СУБД можно скопом назвать ненадежными.
27 сен 14, 10:24    [16628813]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
dimitr
Apex
Да хоть на секунду до сбоя задержался грязный блок в кэшэ в то время как пользователь увидел Transaction commited и все, система уже ненадежна

тут не хватает оговорки насчет надежности / отказоустойчивости оного кеша. Иначе все существующие СУБД можно скопом назвать ненадежными.
У Oracle redo логи пишутся на диск без кэша. Поэтому они пишутся последовательно и на отдельные диски. Эти же redo логи могут (опять же без кэша) перелетать на standby, и там перед окончание транзакции писаться на диск.
27 сен 14, 11:16    [16628864]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
P.S. Все же отдельный redo придуман не зря - эту идею используют почти все реляционные СУБД (Oracle, DB2, MSSQL, MySQL InnoDB, PostrgreSQL, Informix....). Они дают OLTP-базе очень серьезные преимущества
27 сен 14, 11:18    [16628868]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Alexander Ryndin
У Oracle redo логи пишутся на диск без кэша

без файлового кеша ОС. Это не отменяет наличие кешей на более низких уровнях.
27 сен 14, 11:24    [16628877]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Alexander Ryndin
Они дают OLTP-базе очень серьезные преимущества

они "забесплатно" дают серьёзные бонусы (log shipping, PITR и т.п.) - это очевидно. Но вот с т.з. производительности, преимущества заканчиваются при переходе от шпинделей к SSD.
27 сен 14, 11:28    [16628886]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Alexander Ryndin
Все же отдельный redo придуман не зря - эту идею используют почти
все реляционные СУБД

А теперь вспомни когда он был придуман. И чем современные СХД отличаются от тогдашних
магнитных барабанов.

Posted via ActualForum NNTP Server 1.5

27 сен 14, 12:07    [16628920]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
dimitr
Apex
Да хоть на секунду до сбоя задержался грязный блок в кэшэ в то время как пользователь увидел Transaction commited и все, система уже ненадежна

тут не хватает оговорки насчет надежности / отказоустойчивости оного кеша. Иначе все существующие СУБД можно скопом назвать ненадежными.

Речь шла про "времена, когда "винды линейки 9x" могли сутками не сбрасывать "грязные" кластеры на диск - давно прошли.", а так же про "ForceWrite=Off". Причем здесь аппаратный кэш, на который ссылаетесь уже вы? В рамках обозначенного выше контекста, мои рассуждения остаются справедливыми без всяких оговорок.

Кроме того, даже с учетом оговорки никто не мешает выделить для redo log'ов отдельную группу дисков без всяких аппаратных кэшей. В общем, я придерживаюсь мнения, что наличие транзакционных логов дает большое преимущество не только в функционале, но и надежности и производительности. Другое дело, что если отойти от очевидных концептуальных преимуществ и перейти в практическим вопросам, то логи и правда не всегда нужны. Например, то, что пишет ТС: 50 пользователей и 200Гб это ерунда в том числе и для FB. Я видел куда более нагруженные и бОльшие по объему базы на FB, которые вполне себе работали в продакшене.
27 сен 14, 12:15    [16628929]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Apex
никто не мешает выделить для redo log'ов отдельную группу дисков без всяких
аппаратных кэшей.

Ага, вот всегда так: как логи Оракула, так "выделить отдельную группу дисков". А как база
Firebird, так ужастики о дёргающихся головках одного-единственного диска. Ню-ню...

Posted via ActualForum NNTP Server 1.5

27 сен 14, 12:26    [16628946]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11469
Apex
Т.е. вы предлагаете вопрос целостности данных целиком и полностью делегировать железу?
Я предлагаю не использовать двойных стандартов в отсутствии личной заинтересованности.
Отложенная запись - не вселенское зло.
Да при чем здесь это? Да хоть на секунду до сбоя задержался грязный блок в кэшэ в то время как пользователь увидел Transaction commited и все, система уже ненадежна, важные данные ей не доверишь.
Если система записи Oracle гарантированно надёжна, то почему мы получали битые блоки после холодной перезагрузки сервера СУБД при том, что табличные пространства лежали на хранилище, у которого никаких проблем не было?
27 сен 14, 14:45    [16629105]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Yo.!
Guest
dimitr
они "забесплатно" дают серьёзные бонусы (log shipping, PITR и т.п.) - это очевидно. Но вот с т.з. производительности, преимущества заканчиваются при переходе от шпинделей к SSD.

не правда. и на SSD записать один блок в транзакшен лог и отпустить транзакцию выходит заметно быстрее, чем запись 10 блоков в датафайлы ФБ, которые обязана дождаться транзакция.
27 сен 14, 16:50    [16629241]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Yo.!
записать один блок в транзакшен лог и отпустить транзакцию выходит заметно
быстрее, чем запись 10 блоков в датафайлы ФБ

Можешь более конкретно назвать какие именно 10 блоков придётся записать FB? Один блок -
страница данных, второй - Transaction Invention Page, третий - Database Header. Где ещё
семь? И, кстати, разве Оракулу не надо записать новый SCN куда-нибудь, откуда его могут
прочитать другие коннекты?..

Posted via ActualForum NNTP Server 1.5

27 сен 14, 17:25    [16629292]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Dimitry Sibiryakov
третий - Database Header

это при старте, а не при коммите
27 сен 14, 17:42    [16629321]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Yo.!
Guest
Dimitry Sibiryakov
Можешь более конкретно назвать

для тебя будет слишком сложно. помниться мне не удавалось донести до тебя и более простые вещи, чем индексы и несколько таблиц в транзакции.
27 сен 14, 18:07    [16629358]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Yo.!
помниться мне не удавалось донести до тебя и более простые вещи, чем индексы и
несколько таблиц в транзакции.

Ага. Но ты таки попробуй донести до меня как оракул запихивает индексы, несколько таблиц в
транзакции и ещё и redo лог в один-единственный блок undo лога.

Posted via ActualForum NNTP Server 1.5

27 сен 14, 18:52    [16629422]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Alexander Ryndin
от 5к за сокет. SEO и SE лицензируются по сокетам.

Воот. А теперь смотрим что можно купить на сэкономленные пять килобаксов. Я, как ни
считаю, получаю ещё один сокет и десяток SSD сверху. То есть сколько Оракула ни ужимай,
Firebird на его месте получит вдвое лучшее железо.

Posted via ActualForum NNTP Server 1.5

27 сен 14, 19:06    [16629454]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Yo.!
Guest
Dimitry Sibiryakov
Ага. Но ты таки попробуй донести до меня как оракул запихивает индексы, несколько таблиц в
транзакции и ещё и redo лог в один-единственный блок undo лога.

ну ты уел. а ведь действительно как в undo попадает изменения redo лога я не смогу пояснить
для тех кому интересно - в оракле все ровно наоборот, redo (транзакшен лог) защищает изменения в undo логе точно так же как в датафайлах. транзакция ждет записи только в redo, а вот запись в undo уже не принципиально. записалось - хорошо, не записалось - не беда, из redo все можно восстановить.
27 сен 14, 19:22    [16629506]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 11469
Yo.!
транзакция ждет записи только в redo, а вот запись в undo уже не принципиально. записалось - хорошо, не записалось - не беда, из redo все можно восстановить.
Вы постоянно забываете штатную эксплуатацию, когда всё записанное в redo обязано, таки, попасть в data, и, соответственно, сгенерировать undo. И, если пропускной способности носителя/хранилища не хватает, то никакая "размазанность" операций ввода-вывода не позволит избежать тормозов.

P.S. Понятно, что при крахе, с высокой степенью вероятности, СУБД донакатит данные из redo, но в нашем конкретном случае я не мог назвать процедуру восстановления ни мгновенной, ни даже быстрой.
27 сен 14, 19:33    [16629531]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

Yo.!
не записалось - не беда, из redo все можно восстановить.

Ага. Если нервов хватит дождаться этого момента и повезёт не получить ORA-600 в процессе.

Posted via ActualForum NNTP Server 1.5

27 сен 14, 19:48    [16629559]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
prog123
Guest
А вот меня больше всего в платных СУБД, да и не только СУБД, прикалывает лицензионное соглашение, смысл которого очень четкий и выделяется большими жирными буквами, дескать "мы-крутые-раскрутые" АБСОЛЮТНО НИЧЕГО И НИКОГДА И НИ ПРИ КАКИХ МЫСЛИМЫХ И НЕ МЫСЛИМЫХ ОБЧТОЯТЕЛЬСТВАХ, - МЫ ВАМ НИЧЕГО НЕ ГАРАНТИРУЕМ И НИ ЗА ЧТО НЕ ОТВЕЧАЕМ!!!

Это, на мой взгляд, - наиболее существенное, особенно в плане санкций. Юридически всё чики-чики.
27 сен 14, 21:06    [16629686]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
prog123
Guest
И это за мои то кровные и очень не маленькие денюшки!?

PS Вот он звериный оскал капитализьма.
27 сен 14, 21:08    [16629695]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить