|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Тут нам руководство НАСТОЯТЕЛЬНО рекомендует начинать (после известных событий) сабж... "переделывать" конечно не так много, но имхо если уж переходить , то лучше переходить, на чтонть более рульное...типа Oracle 9.2 (поставил тут, вроде приятная штука) Как народ решает такие проблемы?! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2003, 19:56 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
С песнями ! Ну и не на DB2, разумеется... А что за "известные события" имеются ввиду? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2003, 20:54 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
IBM скушал Informix ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2003, 22:46 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Я бы не стал так торопиться. Согласно заявлению IBM, DB2 и все различные версии серверов Informix постепенно движутся к единому продукту, вбирая в себя недостающие друг у друга прелести. Так что в перспективе, где-нибудь в 2009 году проапгрейдив очередной раз сервер ты получишь DB2 и Informix в одном флаконе :-). ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2003, 10:14 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
А зачем переходить, межделмаш в полный рост продолжает развивать INFORMIX мы например перешли на 64 битный INFORMIX от IBM и не жужжим ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2003, 16:22 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
> Ну и не на DB2, разумеется... Такое впечатление, что ты хорошо знаком с этой СУБД и много на ней поработал.... > но имхо если уж переходить , то лучше переходить, на чтонть более > рульное...типа Oracle 9.2 (поставил тут, вроде приятная штука) Ну да, вот именно "рульное" :)) - синоним модное. Заодно и свою квалификацию придется повысить... И на рынке такие спецы ценятся дороже... Они ведь "рульный" продукт юзают. А "приятная штучка" она только на первый взгляд, если хочешь не очень приятных штучек - почитай конфу типа fido7.ru.rdbms.oracle, а то мне ведь не поверишь. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2003, 21:55 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Бог спас от необходимости работать с DB2, хотя не спас от Информикса. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2003, 10:37 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Интересно - а что, повышение квалификации теперь уже воспринимается как нечто негативное? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2003, 10:42 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
> повышение квалификации теперь уже воспринимается как нечто негативное? Scott Tiger, Вами судя по всему да. Или повышать квалификацию можно только изучая Oracle? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2003, 11:53 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Нет, разумеется. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2003, 12:15 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Еще есть такое "ужасное" понятие, как overqualification... ;) > levon А переход Informix -> DB2, на мой взгляд, смысла не имеет. Преимущества DB2 перед Informix несколько надуманы (имхо), а вот гемморою огребете, но если начальнику хочется устроить своим работникам побольше работы - то кто ж ему скажет, что он дурак... ;) IBM отнюдь не станет Informix хоронить, ну сделает для самых "веселых" (кому не терпится) какой-нибудь Migration Toolkit, а вот чтоб уж совсем забить на Informix - на западе с корпоративными клиентами так стараются не поступать, себе дороже выйдет. Да и не затем IBM его купила... ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2003, 13:24 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Имея опыт переноса разработок на различные версии INFORMIX на различные платформы, могу сказать что переход на следующие версии ODS не вызывает никаких проблем. В то же время от счастливцев работающих на Оракле не раз приходилось слышать что их софтина работающая скажем на семерке на восьмерке не работает и тд. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2003, 15:18 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Ну это решаемая проблема при наличии исходников тел пакетов и отсутствии deprecated-синтаксиса и проч. в изначальной версии софта. Часто встречается такой момент, что некое использованное разработчиком в 7-й версии для имени таблицы (например) слово стало в 8-й зарезервированным, но при грамотном кодировании это, опять же, проблема вполне решаемая малой кровью. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2003, 16:27 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
То то и оно что слышу то я это как раз не от пионеров а от серьезных поставщиков ПО. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2003, 13:34 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Пример, пожалуйста, в студию. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2003, 14:39 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Лично я это слышал от представителей Форса. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2003, 20:25 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Ты прав, "Форс" - солидная контора. Но, наверное, у них слишклм большой проект, и адаптировать его долго и лень :) Ну не бывает такого софта, который никакими способами и переписываниями нельзя запустить на другой СУБД (даже). Долго, гнусно, дорого, не хочется - ну тут уж ничего не поделаешь, где-то лажанулись, теперь расхлёбывать придётся. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2003, 22:27 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
To: Scott Tiger Я знаю еще одну крупную контору, которая поленилась подправить свои исходники одного продукта (порядка 4 систем и дохрена интерфейсов), чтобы можно было без проблем перейти с 8 на 9. Уверения Оракла о совместимости этих версий на 100% не оправдались :) To: All DB2, Informix, SyBase, DBase и т.д. по сравнению с MS-SQL, Oracle слабые системы раз они сейчас не особо популярны. Всегда выбирают по возможности выбирают лучшее своего времени, а не старые, отсталые продукты. С другой стороны можно поговорить еще о производительности, надежности, безопасности, целостности, ориентированности на задачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2003, 16:26 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Тогда Виндоуз лучшая операционная система Ж8-(Ё) в мире! Я только скажу, что если бы у меня стоял Оракл, то затраты на аппаратуру в моей конторе были бы выше на много как на сервер , так и на клиентов. Ну и эротики с масдаем тоже гораздо больше. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2003, 17:04 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Вы не любите хомячков? Вы просто не умеете их готовить! Особенно когда Вы говорите о затратах на оборудование, особенно на клиентов. Это смешно. Прайс-лист на память (единственное "место", где Oracle нужно много) давно видели? Давно... А эротики с маздаем - это Вы тоже путаете, лучший трах - это когда всё работает медленно/плохо, а покрутить негде. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2003, 18:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
По поводу популярности - мой любимый тест - www.job.ru, вакансии за последние 20 дней в Москве, поиск по ключевому слову в IT-рубрике: Oracle - 377 Informix - 18 DB2 - 14 Резюме: Oracle - 149 Informix - 14 DB2 - 10 Any comments? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2003, 18:26 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Это говорит только о том, что слово Oracle в Москве более рекламируемое. Кстати, аналогичный поиск на http://www.job.kiev.ua дает несколько другие результаты. Соотношение примерно 1/4 в пользу Oracle. Ну и уж если пошел разговор про интернет-информацию, то зачем далеко ходить? Почти 30% посетителей этого сайта выбирают Informix ;-). ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 11:51 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Это говорит о том, что со знанием Oracle найти работу проще, чем со знанием Informix, а также о том, что людей, в какой-то мере знающих первый продукт, больше, чем людей, знающих продукт второй. А по поводу т.н. "голосования" - ну все уже поняли, что оно ни в коей мере не отражает реальное положение дел. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 12:58 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Странная логика - качество (надежность, производительность, стоимость) подменяется популярностью (дя еще и на ограниченной территории). Тогда надо, используя эту логику, объявить Жигули лучшей машиной всех времен и народов. Что интересно, как я понял, человек только поставил себе Оракл поиграться, не сделал на нем еще ни одной серьезной системы и даже не поддерживал работу серьезного промышленного Оракловского сервера, а хвалит его выше крыши только потому, что он моден и много вакансий :)) А DB2, который в глаза не видел, "отстой и фуфел" потому что за свои 30 лет уже успел всем надоесть, "отстал в развитии" и вакансий на него мало. Скромнее надо бы в оценках, ув. Скотт Тайгер. А Оракл - такой же как и все остальные СУБД, а агрессивный маркетинг (действующий на уровне рекламы "лучшего порошка"), он ведь имеет и отрицательные стороны - обещания нужно выполнять, а ожидания подтверждать, что удается далеко не всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 13:17 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
1. Не подменяется, а дополняется. Поверьте мне, непредсказуемые ошибки/сбои ODS 7.23 встречаются в этой жизни примерно с той же интенсивностью, что и Oracle 8.1.7. Производительность Informix ниже, функциональность на уровне бесплатных продуктов, а стоимость выше. На всех территориях, и на Украине в том числе :) 2. Вы ошибаетесь, ~2,5 года разработки и промышленной эксплуатации Oracle на разных платформах, конечно, не очень много, есть масса более опытных, знатных и грамотных людей, в том числе и здесь, более того, кое-кто из них меня когда-то учил, но скрывать свои заслуги мне кажется некорректным. 3. Про DB2 я говорю со слов т.н. "народа". Учтите, что я сказал про DB2 мало, почти ничего. "Отстой и фуфел" - это не мои слова. С Informix работаю чуть более полугода (почти критически важная для предприятия система, правда, не 24*7, скорее, 21*6 :) ), но для составления вполне определённого мнения об этом продукте этого достаточно. 4. Ещё я люблю кушать, и не люблю сидеть без работы. Думаю, я не одинок в своих слабостях. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 14:55 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
1 если анализ качества системы проводить по предлжению работы, то самая лучшая система - 1С предприятие, торговля и тд и тп. По моему комментарии излишни. 2 Функциональность INFORMIX - это функциональность SQL СЕРВЕРА, не путайте технологические уровни. Серверы ОРАКЛа и ИНФОРМИХ функционально примерно равнозначны. К тому же INFORMIX всегда технологически был лидером и все его догоняли а не наоборот. Популярность Оракла - это популярнось Оракл файнэншнл, sql-сервер Оракла без билдеров оасов и прочего ПО промежуточного уровня вообще фуфло, для начала возьмите ембедед sql c например и сделайте скроллируемый список и сделайте это на INFORMIX esqlc. Оракл для тех кому нужны готовые приложения или их заготовки. INFORMIX для тех кому нужен мощный и гибкий инструмент. Сравните нетепичные проекты и Оракла там будет немного. Оракл доминирует в области финансовых приложений где типовые решения возможны и лучше продаются. 3 INFORMIX на одном и том же оборудовании БОЛЕЕ ПРОИЗВОДИТЕЛЬНАЯ система, имеющая БОЛЬШЕ механизмов для настроийки профиля энджайна под конкретную задачу. Если INFORMIX тормозит конкретно у Вас, это проблема кривых ручек либо ДБА либо разработчика ПО. 4 стоимость это вообще отдельный вопрос. И прежде чем говорить на эту тему советую изучить схему лицензирования Оракла. Стоимость оракла во-первых составляется из стоимости его составляющих, а INFORMIX поставляет ВСЕ возможности промышленного сервера в одном модуле, во вторых стоимость Оракла очень сильно зависит от платформы. Стоимость для ПК под виндоуз одна, а для ULTRASPARC другая, к тому же еще зависит и от количества процессоров. Для масштабных систем думаю разница если и будет, то небольшая. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 15:41 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
1. Не подменяется, а дополняется. Поверьте мне, непредсказуемые ошибки/сбои ODS 7.23 встречаются в этой жизни примерно с той же интенсивностью, что и Oracle 8.1.7. А никто об этом и не спорит, вот только уже в который раз сравниваются версии с, как минимум, 4-х летней разницей. Почему бы не сравнить с 7-м Ораклом ? Производительность Informix ниже, функциональность на уровне бесплатных продуктов, а стоимость выше. На всех территориях, и на Украине в том числе :) Насчет производительности даже спороть неохота - просто есть масса прямо противоположных примеров (на одном и том же железе и одинаковых по функциональности системах) - на мой взгляд тут столько зависит от кривизны рук разработчика, админа и специфики системы, что ... А по стоимости - просто ложь. Вы хоть знаете, сколько стоил Оракл а сравнимой конфигурации в то время, когда продавался 7.23 ? Уж можете мне поверить на слово - продавал и считал для заказчика. Сейчас - точно не скажу, только еще одно - не надо путать цены О. на Винде (где Оракл и др. просто вынуждены снижать цены, чтобы конкурировать с МС) с ценами на Оракл в общем, для серьезных серверных платформ 2. Вы ошибаетесь, ~2,5 года разработки и промышленной эксплуатации Oracle на разных платформах, конечно, не очень много, есть масса более опытных, знатных и грамотных людей, в том числе и здесь, более того, кое-кто из них меня когда-то учил, но скрывать свои заслуги мне кажется некорректным. тут прошу прощения, меня сбила с толку фраза "типа Oracle 9.2 (поставил тут, вроде приятная штука)" сказанная другим участником и ошибочно приписанная Вам 3. Про DB2 я говорю со слов т.н. "народа". Учтите, что я сказал про DB2 мало, почти ничего. "Отстой и фуфел" - это не мои слова. С Informix работаю чуть более полугода (почти критически важная для предприятия система, правда, не 24*7, скорее, 21*6 :) ), но для составления вполне определённого мнения об этом продукте этого достаточно. А где этот "народ" ? Прошу в конфу о DB2 прямо на этом сайте, там как раз на эту тему разговор... А по поводу наследства. Представим, вы купили подержанный авто (например, Ауди :) Так что, на базе своего опыта его эксплуатации (а он старый, использовался своим старым хозяином "абы-как", без плановых ТО и пр.) вы сделаете вывод, что все Ауди плохие ? Ну-ну... 4. Ещё я люблю кушать, и не люблю сидеть без работы. Думаю, я не одинок в своих слабостях. А никто и не отбирает права работы и покушать. Это все любят. Вот только все не любят, когда приходят "в чужой монастырь со своим уставом" и начинают поливать грязью любимое детище (пусть оно и с грешками :)) Я же не иду в форум Оракла и не кричу, что Оракл плохой, а Информикс "рулез". Это даже не этично. А если есть проблемы с Информикс, то значительно полезней и конструктивней будет поделиться своими проблемами - смотришь, может кто то и поможет. А не изливать свое раздражение, что пришлось поддерживать старую, но "жизненно важную" систему на незнакомом сервере. Кстати, а чего бы не сменить работу - благо предложений для Ораклоидов намного больше ? (это просто злая шутка, без обид). ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 16:30 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Я сразу двоим отвечу, ладно? :) 2cpr: 1. Я сказал про популярность, а не про качество. Насколько бы абстрактным понятием "качество" ни было, но определённая связь между популярностью и качеством имеется, при том есть зависимость как первого от второго, так и наоборот. Возвращаясь к Вашему предыдущему посту - Windows суть лучшая домашняя ОС для x86. MacOS лучше, но он не для x86. Linux и иже с ним не для дома. Не будем спорить, ладно, я маздая тоже не люблю, но дома частично использую :) Аналогично и 1С при всех её недостатках (сужу об этом со слов "народа", сам не работал) штука удобная, популярная и безальтернативная. "Так сложилось исторически", и на текущий момент никто ситуацию исправить не сможет. 2. Я говорю только про то, что сейчас, по-видимому, называется Oracle Server (если верить инсталлеру 9.2.0.1.0), т.е. ORDBMS. В России (СНГ?) Oracle Applications и иже с ними малопопулярны, разве что несколько инсталляций. Впрочем, как и SAP. Это уже совсем оффтопик, не будем развивать тему. И давайте, в целом, говорить про эту страну, или, точнее, наши братские страны. "sql-сервер Оракла без билдеров оасов и прочего ПО промежуточного уровня вообще фуфло" - ловлю на слове. На C не пишу, эпизодически пишу на Java, к слову :). Но это особо ничего не значит, давайте тогда уже сравнивать SQL обоих серверов и PL/SQL с SPL. Не встречался особо с заготовками, не в курсе, что такое "нетипичные проекты". Если я правильно понял, тогда у меня все приложения нетипичные, хотя не так уж и редко кусок кода и какие-то общие принципы, оправдавшие себя в одном проекте, переносятся в другой. Что угодно можно на чём угодно написать, вопрос тут в том, каким боком это выйдет писателю и/или эксплуататору. 3. Руки сложная вещь :) Я не считаю себя хорошим администратором Informix, и, к сожалению, хороших специалистов крайне мало, хотя бы уровня меня в Oracle (не считая себя крутым ораклоидом). Это - минус продукту, и очень большой. Моего железа на текущий момент достаточно для комфортной работы пользователей. Oracle у меня работает быстрее. Возможностей настройки наблюдаю больше. 4. Ваши сведения устарели. Разные цены на разные платформы были года 2 назад. Сейчас лицензируются либо количество голов пользователей :), либо количество процессоров. Отдельные цены на Standard Edition и Enterprise Edition. Сходите, например, на http://oraclestore.oracle.com/ Даже у Standard Edition огромный набор возможностей, хотя, вполне могу предположить, что кому-то их может не хватить. 2vasilis: 1. С 7-й версией не работал, однако, как говорят знающие люди, последние релизы 7-й версии работают понадёжней 8i-й. В целом, думается, надёжность в продуктах такого класса не должна быть функцией от времени на достаточном временном отрезке. Так оно, по большей части, и есть. Про цену - не скажу за всю Одессу, но мы сейчас платим за 1 пользователя Informix заметно больше, чем за 1 пользователя Oracle. Тж. см. выше про политику ценообразования сейчас. 2. Ну с кем не бывает :) 3. Интернет большой, мнений много, не имея собственного, стараюсь вывести что-то среднее. Опять же, смотрите на результаты поисков на job.ru. Со знаниями DB2 найти работу сложно. Продукт малопопулярный, здесь, во всяком случае. Про Audi, боюсь, не совсем понял аналогию. Наверное, потому что сам не вожу Шутка. 4. Я вообще личность аморальная и неэтичная. Но не склонен к любви к тому или иному программному продукту. Мне есть кого любить в этой жизни. Вы не бойтесь, заходите и в оракловый форум, поливайте грязью, если есть за что. Критика за дело лучше, чем восхищённое молчание. А работу менять я пока не собираюсь. Всему своё время. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2003, 19:47 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
>Производительность Informix ниже Не устраивает производительность информикс? Примеры в студию. Покажи запросы, планы, конфиги, описание системы, статистику. С вероятностью 60% тебе помогут исправить твои ошибки влегкую, в остальных 40% придется переделывать схему что не всегда возможно. > функциональность на уровне бесплатных продуктов Функциональность СУБД описывается 9-ю пунктами, она присутствует, чего еще надо? Бесплатные продукты дают меньше гарантий, поэтому используются в недорогих системах, где не требуется высокая доступность. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2003, 11:39 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
С цифрами придётся подождать, ибо я сейчас на больничном... Будет чуть позже. Про функциональность - что за 9 пунктов Вы имеете в виду? Давайте, подробнее и с разблюдовкой. Только, пожалуйста, не говорите слово "стандарт ANSI SQL" ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2003, 18:12 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
К слову вспомнился один документ, который кстати не понравился и Informix-у (сравнивалась 7-ка, а не 9-ка) и Oracle (кто ж правду любит :-). Документ достаточно объектинвый, + и - хватает в обоих продуктах. "Использование СУБД Informix Dynamic Server 7.31 и Oracle 8.1.7 для разработки и эксплуатации бизнес-приложений" http://www.profix.com.ua/service/news/I7O8C_.doc ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2003, 19:08 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
2Daugava Прочитал этот опус... Из всех резюмирующих отрицательных качеств Oracle - принимаю только первый - сложность....остальные приведены явно для количества.... 1. В 9.2 ОЧЕНЬ много сделано против СЛОЖНОСТИ 2. а что вы хотели, чтоб системы ТАКОГО уровня были так просты в управлении, как и Access? Любая корпоративная РСУБД требует некоего опыта и неопытным админам туда надо соваться крайне осторожно... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2003, 18:40 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
2Non Опус писался когда 9.2 еще не было. Кто тут говорил об Access-e ? Хотя на мой взгляд, администрирование многопользовательской базы, реализованной на DBF,Paradox,Access требует пусть и меньшего опыта, но значительно .большИх. усилий :-). Кроме того, речь шла все таки о простоте администрирования Informix, в сравнение с Oracle. Я согласен, что некоторые "минусы" в статье притянуты за уши, т.е. с ними можно спокойно смириться, но не забываейте еще и о больших прожорливости Oracle по памяти, что снижает возможности масштабирования, в особенности на распространенной на наших просторах 32-разрядной архитектуре. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2003, 11:30 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
НАСЧЕТ ПРОЖОРЛИВОСТИ - ЭТО ТОЖЕ ВСЕ ОТ ЛУКАВОГО....) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2003, 12:52 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Ну не знаю, от лукавого или нет, но мне известны системы под Informix - 400 пользовательских сессий (реальных пользователей на порядок больше), при этом именно под пользователей использовалось менее 70Мб ОЗУ. Примеры на Oracle, со сравнимыми характеристиками, мне неизвестны. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2003, 14:14 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Почитал все что тут писали, но думаю спорить не будут: 1) Если кривые руки у разработчика, то СУБД не виновата. 2) Каждая СУБД хороша в своих задачах. 3) Не все можно сделать средствами СУБД, и не всегда оправдано. Я на информиксе работа уже 5 лет, начинали на еще 5 версии, и довелось поработать на SE сейчас IDS 7.31. Правда в своих продуктах не пользуеся ODBС написаны свои сетевые сервера по SCO которые работаю с БД. Так вот делаю я претензионную службу УЗЛА ( учет всех исходящих разговоров). Каждый день в БД ложится ~1.500.000 записей. На текуший момент в ней разговоры с 2001 года. Размер чанков 60Г + 10Гиндыхсы. Поиск информации за месяц проводится за 30 секунд (машина PII-400) подсчет всех звонков по каждому абоненту 10 минут (~250.000 абонентов). Просили пример, я его привел. Стандартные средства для стандартных задач, а для нестандартных приходится изголятся. PS. У меня 4 сервера под Informix и он переодически падал, помогает: update statistics low -- для БД c статикой (пишем и только читаем) update statistics high -- для БД в которой иду постоянный изменения данных Рекомендую выполнять каждый день, и пусть ваш IDS живет долго ! ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2003, 14:35 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
хехе ... опять подняли тему за бугром билинг практически весь или на дибиту или на информиксе. Это у нас его на оркле пишут. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2003, 12:37 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Если все же вернуться к первоначальному вопросу, то сейчас торопиться с переходом на DB2 не советовал бы по следующим причинам: - Сам IBM не рекомендует переходить с Informix на DB2 если только заказчик не хочет использовать те возможности DB2, которых нет в Informix - В новых версиях Connectivity Informix планируется ввести поддержку DRDA. Это сильно упростит портацию приложения на DB2, если таковая понадобится. - В новых версиях DB2 (8.2) в SQL постараются ввести конструкции из диалекта SQL Informix. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.04.2003, 13:52 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
кгхм... а мы и не торопимся ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2003, 18:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Не читал всех диалогов, просто хочу сказать. Пришлось однажды переводить большой проект с Informix на DB2. Не по причине закупки IBM, мы сделали это чуть раньше и используем DB2 по сей день. Причина - очень низкая производительность Informix`a. При переходе тестировали и оценивали DB2 и Oracle. Второй на наших задачах проиграл. Перешли довольно быстро. Основные трудности - хранимые процедуры. Informix БЫЛ на много слабее !!!!!!! раз в 8 на наших задачах. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.05.2003, 18:56 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2.
Ну и зачем ты это сказал? Ты всем предлагаешь перейти с информикса на ДБ2? У всех в 8 раз "лучше" станет? ЗЫ: Если проблема не в руках админа Информикса, то проблема в аналитике который выбрал НЕ ТУ СУБД для вашей НЕСТАНДАРТНОЙ задачи изначально. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2003, 09:33 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
С последним я полностью согласен, изначально выбрали не ту СУБД. Но когда выбирали, выбор был не большой и Информикс был одним из лучших. С админами все впорядке ... поверь. Да и лично пришлось попыхтеть над конфигом, каждый параметр в свое время пришлось прозондировать. Обижаться не надо - если нравится и устраивает Информикс то смысла съезжать нету. По поводу задач - если задачу можно решить путем SELECT A FROM B WHERE A=1, это стандартная задача и под силу многим СУБД остальные- не стандартные. По поводу наших хочу отметить, что БД очень динамическая, постоянно обновляется (если не ежесекундно то ежеминутно точно) и SQL-запросы достигают нескольких килобайт по десяткам таблиц каждый. Поверь здесь правильный выбор очень важен ... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2003, 22:44 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Да... Не пробывал контекстный поиск? Я использовал Excalibur DataBlade module. В одинаковых условиях Excalibur - 2 часа и неправильный результат Text Extender под DB2 3 минуты и правильный результат. Для пользователя это важно Ж:-) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2003, 22:52 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
И еще. При большой нагрузке валился чуть ли не каждый день. Админы за голову брались. (Использовали 9.20 под Виндой, незнаю может по Юникс он понадежнее) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2003, 22:57 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
У нас 7.23 на RS/6000 валился только от глюков железа, хотя и был жестоко изнасилован чудовищным приложением и "странной" конфигурацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 10:20 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
А подробнее про хранимые процедуры можно? И вообще по специфике задачи интересно что нибудь услышать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 12:23 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Код: plaintext 1.
Да, вот что-то не верится. Код: plaintext 1.
Если бы я был волен выбирать, я бы выбрал FireBird. Код: plaintext 1. 2.
Согласен. Но хочу заметить что часто задачи становятся нестандартными по причине ошибок при анализе и проектировании. Код: plaintext 1.
Хотелось бы знать, что за предметная область такая? И сколько пользователей изменяют данные. Код: plaintext 1.
В этом случае перед запросом SET OPTIMIZATION LOW, после назад HIGH. Код: plaintext
Верю. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 14:52 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2.
Excalibur известен своей кривостью, но при чем тут Informix и СУБД вообще? А другие датаблейды полнотекстового поиска не пробовал? Родные? Поддерживающие морфологию русского языка? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 14:58 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Код: plaintext 1. 2.
А админы они с техсупортом умеют общаться? Я натыкаюсь на баги в информиксе постоянно, и чем сложнее система, тем на большее количество багов она налетает. С Бааном сразу на 3 мемори лика в Информиксе наступили, причем на разные (под Виндой больше чем под AIX), и ничего все решаемо, нахожу воркараунды, все баги исправляют. Однажды налетел на баг при роллбек апдейта таблицы с несколькими версиями из-за IPAT, тоже валилось каждый день, думал застрелится или в окно выйти, через пару дней разобрался, один апдейт, и все проблема решена. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 15:07 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
А датаблэйд вообще интересная штука, в том смысле что свалить сервак может на раз. Насколько я знаю в 9.3 есть фича позволяющая запускать код расширений в отдельных виртуальных процессорах дабы не подвергать сбою весь сервер. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 15:13 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
А подробнее про хранимые процедуры можно? И вообще по специфике задачи интересно что нибудь услышать Единственный приемлимый вариант - писать хранимые процедуры на С . Создается ДЛЛ потом цепляется как внешняя хранимая процедура. SQL процедуры и функции слабоватые, имеют неприятные ограничения. Можно еще на Яве писать ... Специфику задач предпочитаю не обсуждать :-( В этом случае перед запросом SET OPTIMIZATION LOW, после назад HIGH. Уже больше года не работаю с Информиксом - советы бесполезны. Помню пытался улучшить за счет параллелизма и PDQ. ... И сколько пользователей изменяют данные. Корректируют пару десятков короткими транцакциями. Ввод централизированный - через одно средство в порядке очереди (накапливается единая очередь заданий на загрузку, которая постоянно обрабатывается) Объемы данных не приведу. А другие датаблейды полнотекстового поиска не пробовал? Родные? Не знаю родных. Пробывал какой-то Verity ... который ужасно тормозил. По-поводу техсупорта ... облом ... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2003, 23:20 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
CNN сделало на INFORMIX хранилище медиаданных, в котором хранятся все их видео и аудиозаписи с возможностью поисков и тд и тп. Британцы на нем же сделали хранилище дактилоскопических отпечатков. Примеров полно. Сам я с объектными расширениями не работал, но в стандартных реляционных моделях INFORMIX использую с 97 года (на трех юниксах на интле и санах). К ресурсам требования существенно меньше нежели у Оракла. С производительностью тоже проблем нет. В частности самый тяжелый пример - ИС банка - с 98 года более 10 млн записей в таблице документов в которую ввод осуществляетс непосредственоо без всякого промежуточного накопления. Общий объем БД >20 гиг. Причем вся бизнес логика на ХП. Особенно радует простота копирования и восстановления. Вот недавно на филиале взорвался бесперебойник с которого был запитан внешний скази оба зеркальных винта в полной ж... , >8гиг даннных поднялись за 15 мин с ленты(отдельное спасибо конечно солярису с его метаустройствами). А db2 наверное вещь хорошая, но плохо наблюдаемая ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2003, 11:59 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
интересно, кто-то поддался "паники" и перевел informix на ... ? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2008, 23:59 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
DaugavaЯ бы не стал так торопиться. Согласно заявлению IBM, DB2 и все различные версии серверов Informix постепенно движутся к единому продукту, вбирая в себя недостающие друг у друга прелести. Так что в перспективе, где-нибудь в 2009 году проапгрейдив очередной раз сервер ты получишь DB2 и Informix в одном флаконе :-).И все таки какая СУБД лучше, Informix или DB2? У Informix ведь нет бесплатной Express-C версии? А лицензия на Informix стоит многоденег ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2009, 21:26 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
интересовавшийсяИ все таки какая СУБД лучше, Informix или DB2? У Informix ведь нет бесплатной Express-C версии? а что делать то хотите с базой то? интересовавшийся А лицензия на Informix стоит многоденег неправда! давайте ссылки, вместе почитаем про деньги ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2009, 00:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
herrинтересовавшийсяИ все таки какая СУБД лучше, Informix или DB2? У Informix ведь нет бесплатной Express-C версии? а что делать то хотите с базой то? интересовавшийся А лицензия на Informix стоит многоденег неправда! давайте ссылки, вместе почитаем про деньгиhttp://www-01.ibm.com/software/data/db2/express/ Free to develop, deploy, distribute А где бесплатный Interbase? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2009, 21:46 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Scott TigerБог спас от необходимости работать с DB2, хотя не спас от Информикса. Вы право, удивляете все больше и больше .. :) Informix rated #1 by VendorRate in survey: beats Oracle! Read the press release!! http://www.businesswire.com/portal/site/google/?ndmViewId=news_view&newsId=20081016005336&newsLang=en Я бы мог предоставить достаточно обширный список, кто работает и использует технологии Informix. For example: - Every VISA transaction authorization in US goes through IDS - 8 of the top 10 U.S. Retailers - 20 of the top 25 U.S. Supermarkets - United States “911” Emergency System - and so on. В настоящий момент, у Informix - самый мощный OLTP движок в мире. Если сравнивать СУБД ORACLE 11g , DB2 9.5 и Informix 11.50 для OLTP - то решение на DB2 требует в два раза меньше аппаратных ресурсов чем ORACLE, а Informix - в два раза меньше чем при использовании DB2 - при одинаковой производительности (транзакционной нагрузки). Вот и считай ваши денежки. Есть желание купить больше железа для достижения той же производительности, покупай ORACLE ... :) .... хочешь иметь дополнительный запас прочности ... Informix !!! Продавцы железа ... ой как любят впаривать свои железяки для ORACLE - язва, язву кормит ... Если нужно решить задачу и грамотно использовать имеющиеся ресурсы ... выбор за Вами. SAP - DB2 has significant advantages running under SAP compared to Oracle that will not only give customers better performance, but will also lower their operating costs. Сегодня, крайне редко встречаются задачи где требуется только использование режима OLTP. Для смешанных сред - лучше использовать DB2 чем Informix. Версия DB2 9.5, предлагает уникальные технологии - MDC, MQT, Deep Compression, LEO-оптимизатор, WLM на уровне СУБД (или WLM - интегрированную с OS, например AIX), встроенный тип данных XML, SQL-репликацию, HADR-репликацию, Q-репликацию, поддержку хранимых процедур на PL/SQL, C/С++, Java, thread-based process model и т.д. В следующей версии DB2 Cobra, планируется поддержка хранимых процедур, написанных в диалекте ORACLE (PL/SQL) .... :) Так что, DB2 - очень даже хорошая СУБД ... просто, инструменты нужно ипользовать по назначению ... :) С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2009, 22:28 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVFScott TigerБог спас от необходимости работать с DB2, хотя не спас от Информикса. Вы право, удивляете все больше и больше .. :) Браво! Ответ через 5 лет почти в тотже день (оригинал Scott Tiger запостил аж 25 янв 03, 10:37), немного нужно было подождать ;) Незря уж говорят - лучше поже, чем никогда Уже интересно, автор использует все еще Informix? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2009, 02:28 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF, Приходилось общаться с одним камрадом, который работал с САП под DB2 и под Oracle. Его мнение - DB2 менее надежен. При падении сервера шансов подняться нормально у DB2 меньше. Так что что Informix надежнее будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 11:41 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
cprПриходилось общаться с одним камрадом, который работал с САП под DB2 и под Oracle. Его мнение - DB2 менее надежен. При падении сервера шансов подняться нормально у DB2 меньше. Так что что Informix надежнее будет.Приложения которые пытаются поддерживать несколько субд -- это супергеморой для пользователей. То 2-2<>0 (потому что в оракле number, а в информиксе float), то отчеты выполняющиеся в dirty reads, показывают не пойми что. Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 11:59 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Есть много разных мнений .... и хороших и плохих. Если администратор не может поднять базу - это говорит о том, что он не тестировал процедуру восстановления для данного архитектурного решения (action plan, configuration, bug fix, and so on.). Видел Я такие конфигурации. Как правило, успех мероприятия во многом зависит от уровня профессионализма бизнес-партнеров, которые настраивают и устанавливают подобные системы. Не совсем понятно, причем здесь база данных ? Например, Я знаю другой вариант, когда у одного заказчика на площадке работают DB2 for SAP и ORACLE RAC. С DB2 никаких проблем, а вот у ORACLE RAC - ноды между собой не могут договориться ... вылетает то одно то другая ... :) С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 13:25 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Незря уж говорят - лучше поже, чем никогда Уже интересно, автор использует все еще Informix? Да - это так ... лучше позже, чем никогда .... :) В данный момент ... разбираюсь с новой версией IDS 11.50 - технологией MACH11. Собираюсь покопаться в новой версии DB2 Cobra - если времени будет достаточно ... :) C уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 13:29 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Приложения которые пытаются поддерживать несколько субд -- это супергеморой для пользователей. Причем здесь пользователи ? Пользователь должен получить комфорт от работы с приложением и нужный перечень сервисов. Архитектурные особенности решения его не должны волновать ... :) ... это дело IT-архитектора и т.д. Опять же, каждый инструмент хорош для определенных задач. То 2-2<>0 (потому что в оракле number, а в информиксе float), то отчеты выполняющиеся в dirty reads, показывают не пойми что. Ну батенька, используйте другой вид изоляции транзакций. Никто не заставляет Вас использовать для отчетов - dirty reads. Интересно, как в ORACLE можно прочитать данные, когда в базу BI они только загружаются (в процессе загрузки) ... :) ... ? И DB2 и Inromix - поддерживают все уровни изоляции, которые определены в стандарте. Использование особенностей оптимистических или пессимистических блокировок - больше всего, оказывает влияние на дизайн и разработку приложений. С точки зрения базы данных - это оказывает влияние на эффективность распределение ресурсов. Работал же Informix c оптимистическими блокировками много лет ... думаю, что ни у кого не вызывало сомнений, что это самый быстрый OLTP-движок ... :) Хотите еще быстрее - используйте новой возможности ... :) Есть много разных мнений ... What strategies are available to organizations for executing mixed OLTP and DSS workloads using current DBMS technology? The most straightforward approach is simply to execute all DSS queries/reports using an isolation level of uncommitted read (UR) so that it does not cause any locks, or wait for any locks held by other applications. In this manner OLTP transactions continue to execute (with the locks they need to ensure the data integrity) and are not impacted by the DSS queries since they do not acquire any locks and therefore do not block any other queries (OLTP or DSS). The reality is that 90%+ of all transactions in an OLTP system are committed, not rolled back, so the fact that the DSS queries see the uncommitted data is inconsequential. As well, the DSS queries are typically calculating monthly or yearly values, so the fact that they might see a query that is not yet committed does not affect the result ... Какую стратегию выбрать - решать Вам. В данном случае, Informix и DB2 не ограничивают Вас в выборе .... :) С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 13:53 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF Ну батенька, используйте другой вид изоляции транзакций. Никто не заставляет Вас использовать для отчетов - dirty reads. Интересно, как в ORACLE можно прочитать данные, когда в базу BI они только загружаются (в процессе загрузки) ... :) ... ? .Это не мне, у меня в консерватории все ок, это индусам которые сап и баан пишут посоветуйте. Вот свежий пример идиотизма: 1с работал с mssql и был там например такой код, обычное непересечение периодов (понятно что это нарушение НФ): create table test_den(a int, b int, e int); create unique index test_den_ix on test_den(a, b, e); сессия 1. сессия 2begin transaction;select 1 from test_den where a=1 and ((a between 0 and 10) or (b between 0 and 10));0 row(s) found.insert into test_den values (1; 0; 10); begin transaction select 1 from test_den where a=1 and ((a between 1 and 9) or (b between 1 and 9)); висим на блокировкеcommit; 1 row(s) found. rollback; Решили поддерживать postgre сессия 1. сессия 2begin TRANSACTION ISOLATION LEVEL SERIALIZABLE; select 1 from test_den where a=1 and ((a between 0 and 10) or (b between 0 and 10));(0 rows)insert into test_den values (1; 0; 10);begin TRANSACTION ISOLATION LEVEL SERIALIZABLE;select 1 from test_den where a=1 and ((a between 1 and 9) or (b between 1 and 9)); (0 rows) А блокировок-то нет. insert into test_den values (1; 1; 9);commit;commit;select 1 from test_den where a=1 and ((a between 0 and 10) or (b between 0 and 10));(2 rows) select 1 from test_den where a=1 and ((a between 1 and 9) or (b between 1 and 9));(2 rows) Угадайте как эту проблему решил 1С ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 14:15 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Тьфу. Запутался в буквах. И порядке коммитов. Решили поддерживать postgre сессия 1. сессия 2begin TRANSACTION ISOLATION LEVEL SERIALIZABLE; select 1 from test_den where a=1 and 0 <= e and 10>= b;(0 rows)insert into test_den values (1; 0; 10);begin TRANSACTION ISOLATION LEVEL SERIALIZABLE;select 1 from test_den where a=1 and 1 <= e and 9>= b; (0 rows) А блокировок-то нет. insert into test_den values (1; 1; 9);commit;commit;select 1 from test_den where a=1 and 0 <= e and 10>= b;(2 rows)select 1 from test_den where a=1 and 1 <= e and 9>= b;(2 rows) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 14:36 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Это не мне, у меня в консерватории все ок, это индусам которые сап и баан пишут посоветуйте. Это хорошо, что у Вас все - OK! Проблемы индейца - вождя не волнуют ... :) ... шутка. Примеры конечно - показательные ... :) ... но и рекомендации могут быть разные. Например, использовать уровень изоляции транзакций CS, установить для сессии2 TIMEWAIT и т.д. Вообще-то, рецептов может быть много ... в том числе и использование optimistic locking. Improve concurrency with DB2 9.5 optimistic locking http://www.ibm.com/developerworks/db2/library/techarticle/dm-0801schuetz/ Угадайте как эту проблему решил 1С? Думаю, что 1C - затачивает свою систему под DB2, а IBM, свою базу - под 1С ... :) С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 14:50 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF Это не мне, у меня в консерватории все ок, это индусам которые сап и баан пишут посоветуйте. Это хорошо, что у Вас все - OK! Проблемы индейца - вождя не волнуют ... :) ... шутка. Примеры конечно - показательные ... :) ... но и рекомендации могут быть разные. Дело в том что прикладной разработчик, не знает в какой субд будет работать код, он пишет на 4gl языке (baan-sql, abap, 1c) . На уровень изоляции тут повлиять нельзя. Залочить и то проблема. Эти запросы трансформируются в запросы к разным субд и надо написать так чтоб работало во всех. GVF112GVF Думаю, что 1C - затачивает свою систему под DB2, а IBM, свою базу - под 1С ... :) Залочили таблицу целиком. И написали патч к постгре добавляющий два новых уровня изоляции. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 15:35 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Журавлев Денис И написали патч к постгре добавляющий два новых уровня изоляции. А можно более подробно? и ( или ) ссылку. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 19:21 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
cpr Приходилось общаться с одним камрадом, который работал с САП под DB2 и под Oracle. Его мнение - DB2 менее надежен. При падении сервера шансов подняться нормально у DB2 меньше. Так что что Informix надежнее будет. Вы это .... поменьше общайтесь с такими комрадами ....плохому научат Мой коллега-сапбазисник, до этого работавший только со связкой SAP+Oracle, два дня прыгал от счастья, когда после криво вставшего саповского патча на продуктив все восстановление базы свелось к команде из одной строчки в пять слов (прислал ему sms-кой во втором часу ночи) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 22:37 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVFЕсли администратор не может поднять базу - это говорит о том, что он не тестировал процедуру восстановления для данного архитектурного решения (action plan, configuration, bug fix, and so on.). Видел Я такие конфигурации. А где можно ознакомиться с образцами документов администратора (action plan, configuration, bug fix, and so on.)? Может Вы выложите образцы? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 23:05 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Дело в том что прикладной разработчик, не знает в какой СУБД будет работать код, он пишет на 4gl языке (baan-sql, abap, 1c) .На уровень изоляции тут повлиять нельзя. Залочить и то проблема. Эти запросы трансформируются в запросы к разным СУБД и надо написать так чтобы работало у всех. Если прикладной разработчик заранее не знает в какой СУБД будет исполняться его код, тогда, тем более есть все основания для того чтобы придерживаться стандарта ANSI. Насколько мне известно DB2 и Informix, предоставляют такую возможность. Далее, если SQL-запросы трансформируются к разным СУБД, тогда необходимо понимать методологию и логику такой трансформации. Как минимум, должны быть определенные рекомендации со стороны - SAP, 1C и т.д. Например, SAP все больше поддерживает технологию Java. Соответственно Java, поддерживает J2EE Isolation Level - который хорошо совместим с ANSI Isolation Level. Если разработчик поддерживает ANSI-стандарт, тогда и проблем меньше. Если нет ... ну тогда больше лишней работы - за все нужно платить Залочили таблицу целиком. И написали патчь к постгресе добавляющий два новых уровня изоляции. Насколько мне известно, в 1C, используется не так много хранимых процедур (может с десяток и то менее). В основном, используется чистый SQL. Наверное, разработчики 1С не хотели привязываться к конкретной СУБД. Эффективность выполнения запросов 1С, во многом зависит от реализации внутренних механизмов в самой СУБД. Здесь разработчик прикладного решения повлиять не может, а вот на параметры пользовательской сессии, уровни изоляции транзакций и SQL-запросы - изменить может. Если для решение проблемы Lost updates или Old Data Reads будут введены новые уровни изоляции в стандарт ANSI, тогда по всей логике онидолжны будут поддерживаться и всеми промышленными производителями СУБД. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2009, 23:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat-Журавлев Денис И написали патч к постгре добавляющий два новых уровня изоляции. А можно более подробно? и ( или ) ссылку. Наврал я, 1св патче PostgreSQL для 1С:Предприятия 8 реализован особый вид табличных блокировок, называемах APPLICATION SHARED и APPLICATION EXCLUSIVE http://v8.1c.ru/overview/postgres_patches_notes.htm applock-1c-8.3.1.patch ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2009, 08:44 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
mitekcpr Приходилось общаться с одним камрадом, который работал с САП под DB2 и под Oracle. Его мнение - DB2 менее надежен. При падении сервера шансов подняться нормально у DB2 меньше. Так что что Informix надежнее будет. Вы это .... поменьше общайтесь с такими комрадами ....плохому научат Мой коллега-сапбазисник, до этого работавший только со связкой SAP+Oracle, два дня прыгал от счастья, когда после криво вставшего саповского патча на продуктив все восстановление базы свелось к команде из одной строчки в пять сов (прислал ему sms-кой во втором часу ночи) Мы говорим о разном. Удобство администрирования<>вероятность выживания базы после краха системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2009, 14:30 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
cpr[ Мы говорим о разном. Удобство администрирования<>вероятность выживания базы после краха системы. Что Вы понимаете под крахом системы ? Halt по питанию ? Умирание ноды HA-кластера ? Полный disaster ЦОДа ? Я не знаток Oracle, но, если не ошибаюсь (да поправят коллеги), halt по питанию там аналогичен shutdown abort, как я понимаю штука часто приводящая к не очень хорошим последствиям. DB2 в этом случае автоматически сделает crash recovery и поедет дальше. DB2 нормально работает с MSCS, TSA, HACMP, etc для случаев failover-кластеров. В плане защиты от дизастеров DB2 HADR (спасибо информиксу) ничуть не хуже Oracle DataGuard Средств куча, надо только "уметь готовить" ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2009, 16:47 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
mitek Я не знаток Oracle, но, если не ошибаюсь (да поправят коллеги), halt по питанию там аналогичен shutdown abort, как я понимаю штука часто приводящая к не очень хорошим последствиям. DB2 в этом случае автоматически сделает crash recovery и поедет дальше. оракл не менее автоматически сделает crash recovery откроет бд, запустит юзеров и в фоне будет вычищать датафайлы откатывая незавершенные транзакции. т.е. быстрей чем дб2 востановит работоспособность. mitekВ плане защиты от дизастеров DB2 HADR (спасибо информиксу) ничуть не хуже Oracle DataGuard а хадр разве умеет более одной стенбай машины иметь и пускать на них отчеты ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 03:20 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Все хорошо, вот только почему то люди на соседнем форуме, частенько поднимают тему типа "не поднимается Oracle после отключения питания" Почему интересно, если все так шоколадно. Больше одного стендбая DB2 не умеет (а так уж ли надо ?) Чтение со стендбая это хорошо, но я специально подчеркнул, что в плане защиты от дизастеров ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 10:23 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash оракл не менее автоматически сделает crash recovery откроет бд, запустит юзеров и в фоне будет вычищать датафайлы откатывая незавершенные транзакции. т.е. быстрей чем дб2 востановит работоспособность. Не всегда, мне не один раз приходилось поднимать oracle датафайлы из offline накатывая логи вручную. про ДБ2 не скажу, а Informix не откроет базу для юзеров пока полностью не выполнит crash recovery. Оракл выполняет crash recovery быстрее, но иногда лажается. Informix делает это дольше, но надежнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 11:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat-Оракл выполняет crash recovery быстрее, но иногда лажается. Informix делает это дольше, но надежнее. Информикс тоже лажается (я сторонник объективности :) Конечно же, сильно зависит от условий, версии, уровня администрирования и платформы. Я несколько раз уже описывал свои наблюдения за несколькими сотнями инстансов с одной и той же прикладной системой, но в тяжелых условиях эксплуатации (интел платформа и винда, отсутствие стабильного энергопитания в регионах, частое отсутствие упсов, слабое или отсутствующее администрирование и т.п.). Да, в 99-и случаях из 100 (а может и в 999 из 1000) Информикс корректно обработает аварийное выключение компа, тем не менее, обычно несколько раз в год приходилось разбирать ситуации, когда сервер не мог накатить транзакции из лога и fast recovery не мог выполниться. Руками самому воспроизвести это никогда не получалось :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 12:20 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
vasilisonstat-Оракл выполняет crash recovery быстрее, но иногда лажается. Informix делает это дольше, но надежнее. Информикс тоже лажается (я сторонник объективности :) Конечно же, сильно зависит от условий, версии, уровня администрирования и платформы. Я несколько раз уже описывал свои наблюдения за несколькими сотнями инстансов с одной и той же прикладной системой, но в тяжелых условиях эксплуатации (интел платформа и винда, отсутствие стабильного энергопитания в регионах, частое отсутствие упсов, слабое или отсутствующее администрирование и т.п.). Да, в 99-и случаях из 100 (а может и в 999 из 1000) Информикс корректно обработает аварийное выключение компа, тем не менее, обычно несколько раз в год приходилось разбирать ситуации, когда сервер не мог накатить транзакции из лога и fast recovery не мог выполниться. Руками самому воспроизвести это никогда не получалось :) Это и понятно, база наверное была в bufferеd log, и документация об этом кажись( насколько я помню) предупреждает, что могут быть неприятные моменты с crash recovery. Если база в unbeffered log, то таких ситуаций я не видел, и вероятность их возникновения ниже, по понятным ( архитектурным) причинам. Если быть объективным то недостаток информикса в том, что только логическими журналами ситуацию не исправишь, нужно ресторить и даже не чанк , а дбспейс польностью + журналы или вообще всю базу. p.s. За надежность всегда нужно платить, как правило производительностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 12:47 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
mitekВсе хорошо, вот только почему то люди на соседнем форуме, частенько поднимают тему типа "не поднимается Oracle после отключения питания" Почему интересно, если все так шоколадно. а чего удивительного ? раз crash recovery не смогло поднять значит у них после отключении питания поврежденные блоки в самом датафайле появились. тут накатом лога не обойтись, блоки из бэкапа придется восстанавливать, что опять же в оракле лучше сделано. onstat- Не всегда, мне не один раз приходилось поднимать oracle датафайлы из offline накатывая логи вручную. вы утверждаете что у оракла при целых датафайлах есть баг при котором он забывает "recover database" запустить или у вас все таки посложней ситуации были ;) ? у все этих субд есть лог транзакций, так что у всех принцип одинаков, просто у оракла еще фича с запуском базы и ролбека транзакций в фоне за счет версионности. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 15:17 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash onstat- Не всегда, мне не один раз приходилось поднимать oracle датафайлы из offline накатывая логи вручную. вы утверждаете что у оракла при целых датафайлах есть баг при котором он забывает "recover database" запустить или у вас все таки посложней ситуации были ;) ? Аж на расссс, одна из причин( самая простая и даже не баг) oracle не знает как достать журналы которые уже сбекаплены и удалены rman-ом. db2crash у все этих субд есть лог транзакций, так что у всех принцип одинаков, просто у оракла еще фича с запуском базы и ролбека транзакций в фоне за счет версионности. Лучше или хуже, это вопрос субъктивный, у вас есть опыт работы с 2 разными СУБД , что бы сравнивать? ИМХО версионность тут не причем. Informix в режиме unbuffered log мне не приходилось восстанавливать ниразу. А в Oracle у меня падали и датафайлы и контролфайлы. По каким причинам я не знаю ( это баг версии или фича в логике крешрековери), но поупражняться в востановлении либо логами либо с бэкапа мне приходилось. Контролфайлы ( на 9.2.06) падали даже без аварийного выключения питания, в ОС что то непонятное произошло. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 16:12 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat- Аж на расссс, одна из причин( самая простая и даже не баг) oracle не знает как достать журналы которые уже сбекаплены и удалены rman-ом. а что информикс в таком случае сам перематывает ленту и с нее достает лог ? onstat- Лучше или хуже, это вопрос субъктивный, у вас есть опыт работы с 2 разными СУБД , что бы сравнивать? ИМХО версионность тут не причем. oracle может пускать пользователей за счет того, что закомиченные версии строк затертые в датафайле вырублеными транзакциями можно читать из UNDO. имхо много опыта не нужно, чтоб что в информикс UNDO нет. onstat-Informix в режиме unbuffered log мне не приходилось восстанавливать ниразу. а у меня краш рековери всегда срабатывал ... onstat- Контролфайлы ( на 9.2.06) падали даже без аварийного выключения питания, в ОС что то непонятное произошло. а у информикса при повреждении файлов бд по вине ОС они сами выпрыгивают из бэкапа ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 17:26 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashonstat- Аж на расссс, одна из причин( самая простая и даже не баг) oracle не знает как достать журналы которые уже сбекаплены и удалены rman-ом. а что информикс в таком случае сам перематывает ленту и с нее достает лог ? Informix не нуждается в заархивированных журналах для крешрековери. db2crash onstat- Лучше или хуже, это вопрос субъктивный, у вас есть опыт работы с 2 разными СУБД , что бы сравнивать? ИМХО версионность тут не причем. oracle может пускать пользователей за счет того, что закомиченные версии строк затертые в датафайле вырублеными транзакциями можно читать из UNDO. имхо много опыта не нужно, чтоб что в информикс UNDO нет. Informix имеет совсем другой механизм получения таких страниц. физический журнал называется. UNDO ему не нужен. db2crash onstat-Informix в режиме unbuffered log мне не приходилось восстанавливать ниразу. а у меня краш рековери всегда срабатывал ... Значит нам повезло, мне с informix, Вас с oracle на этом основании невозможно обоснованно доказать того что кто то из них нажедней. Учитывая отсутствие у Вас элементарных знаний об архитектуре Infomix, спорить с Вами на эту тему - зря тратить время. Что касается oracle, будучи объективным :), то основаная его солома, которую он себе подкладывает в том, что дбврайтер практически никогда не делает мультиблочную запись, потому что вынужден писать на диск в порядке SCN, а не в порядке физического расположения блоков в файле. Это его плата производительностью за крешрековери. У каждой СУБД она своя. db2crash onstat- Контролфайлы ( на 9.2.06) падали даже без аварийного выключения питания, в ОС что то непонятное произошло. а у информикса при повреждении файлов бд по вине ОС они сами выпрыгивают из бэкапа ? Нет конечно, в информикс нет контролфайлов, и соотвественно выпрыгивать они отуда не могут и пересоздавать их не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 18:43 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat- Informix не нуждается в заархивированных журналах для крешрековери. а в заархивированых logical logs он нуждается ? в чем принципиальное отличие от оракловых арклогов от logical-log backups ? onstat-Informix имеет совсем другой механизм получения таких страниц. физический журнал называется. UNDO ему не нужен. нет никакого другого механизма есть банальный Write ahead log, с помощью этого лога на последней стадии рекавери откатывает незавершенные транзакции, пользователи информикса в это время курят. в оракле на этой стадии уже работают, а незавершенные транзакции откатываются в фоне, пока идет этот процесс пользователи видят последние закомиченые данные из UNDO, аналога которому в информиксе нет. onstat- Нет конечно, в информикс нет контролфайлов, и соотвественно выпрыгивать они отуда не могут и пересоздавать их не нужно. ну тады с нетерпением ждем пояснений, чем oncfg_servername.servernum принципиально отличается от ораклового контрол-файла и почему вы решили, что oncfg_servername.servernum не нужен при рековери ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 20:17 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashonstat- Informix не нуждается в заархивированных журналах для крешрековери. а в заархивированых logical logs он нуждается ? в чем принципиальное отличие от оракловых арклогов от logical-log backups ? Принипиальных отличий в логах нет, есть отличия в архитектуре сервера, одной из которых есть отсутствие UNDO. db2crash onstat-Informix имеет совсем другой механизм получения таких страниц. физический журнал называется. UNDO ему не нужен. нет никакого другого механизма есть банальный Write ahead log, с помощью этого лога на последней стадии рекавери откатывает незавершенные транзакции, Почитайте, что происходит на первой. Это очень важно с точки зрения понимания как происходит fast recovery, и почему вероятность появления битых страниц после падения OS + informix снижается в режиме unbufferd log. Очень хорошо что вы начали читать документацию informix :). db2crash пользователи информикса в это время курят. Я этого не скрывал. db2crash в оракле на этой стадии уже работают, а незавершенные транзакции откатываются в фоне, пока идет этот процесс пользователи видят последние закомиченые данные из UNDO, аналога которому в информиксе нет. Даже те кто делают select for update ? Если это действительно так, я не знаю, то это не крешрековери , а реклама шелковистых волос, как любит говорить Yo! Если select for update выполнить нельзя, то не нужно говорить о востановлении полнофункциональной работы во время фонового наката логов. Давайте будем объективными. db2crash onstat- Нет конечно, в информикс нет контролфайлов, и соотвественно выпрыгивать они отуда не могут и пересоздавать их не нужно. ну тады с нетерпением ждем пояснений, чем servername.servernum принципиально отличается от ораклового контрол-файла и почему вы решили, что oncfg_servername.servernum не нужен при рековери ? Давайте не будем путать крешрековери и рековер после рестора. [quote автор] database server uses the oncfg_servername.servernum file when it salvages logical-log files during a whole-system restore[ /quote] 1.Для крешрековери этот файл не нужен, он нужен только для утилиты onbar при полном востановлении. другая утилита бекапирования (ontape ) в нем не нуждается ( во всяком случае не нуждалась когда я последний раз ею пользовался). 2. В этом файле нет SCN или какого либо другого значения отражающего порядок следования транзакций в разрезе файлов. Он великолепно правится руками в отличие от controlfile. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 21:16 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat- Принипиальных отличий в логах нет, есть отличия в архитектуре сервера, одной из которых есть отсутствие UNDO. давайте конкретно, в отличие от ораклового рековери, который не находит арклоги удаленные рманом, информикс рековери найдет удаленный ontape logical-log, вы это утверждаете ? onstat- Почитайте, что происходит на первой. Это очень важно с точки зрения понимания как происходит fast recovery, и почему вероятность появления битых страниц после падения OS + informix снижается в режиме unbufferd log. прочел, в данном тексте вижу описание совершенно стандартного Write-ahead log, не вижу ни одного принципиального отличия от накатывания ораклового REDO. можно более развернутые пояснения. onstat- Если select for update выполнить нельзя, то не нужно говорить о востановлении полнофункциональной работы во время фонового наката логов. Давайте будем объективными. на не затронутые упавшими транзакциями данные select for update пройдет, на затронутые конечно rw транзакции не пройдут, зато прочесть можно. onstat- Давайте не будем путать крешрековери и рековер после рестора. хорошо, что произойдет если в процессе работы oncfg_servername по вине ОС будет запорот мусором ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 22:02 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashonstat- Принипиальных отличий в логах нет, есть отличия в архитектуре сервера, одной из которых есть отсутствие UNDO. давайте конкретно, в отличие от ораклового рековери, который не находит арклоги удаленные рманом, информикс рековери найдет удаленный ontape logical-log, вы это утверждаете ? я утверждаю что заархивированные логи , которые находятся на ленте либо в каком либо другом месте недоступном серверу , но доступном утилите востановления ( onbar, ontape ) не нужны серверу при fast - recovery. Сервер следит за тем что бы у него вся информация необходимая для fast recovery была в доступных ему логических журналах. То что журнал уже заархивирован и перенесен в архив не значит что он уже недоступен серверу. Полная аналогия с редо. db2crash прочел, в данном тексте вижу описание совершенно стандартного Write-ahead log, не вижу ни одного принципиального отличия от накатывания ораклового REDO. можно более развернутые пояснения. Что хранится в физическом журнале вы прочитали ( поняли ) ? Насколько я понял вы пока не видите разницы между физическим и логическим журналами. Пока не поймете, что либо рассказывать бессмысленно, а когда прочитаете( поймете) может и обьяснять ничего не нужно будет. db2crash onstat- Давайте не будем путать крешрековери и рековер после рестора. хорошо, что произойдет если в процессе работы oncfg_servername по вине ОС будет запорот мусором ? Вы его востановите . Этот файл может быть запорчен только в случае, когда глюк произошел во время переключения журналов или добавления чанков. В другое время он не изменяется. Если этот файл запорчен вне проведения этих операций то это может говорить только о том что железу на котором работает база срочно нужно отправлять на пенсию. Кстате вспомнил, этот файл нужен при востановлении базы на новом сервере, или если rootdbs, логические и физические журналы доступны, то onbar может взять всю информацию из базы sysutils, это аналогия recovery catalog. Скажу чесно и объективно, до настройки sysutils для для onbar на другом сервере у меня руки не дошли . Что касается востановления файловой системы средствами ОС после падения для минимизации битых страниц в СУБД , то порядок действий на этом форуме описывался, воспользуйтесь поиском. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 23:11 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
В плане защиты от дизастеров DB2 HADR (спасибо информиксу) ничуть не хуже Oracle DataGuard Здесь не совсем корректное сравнение!!! Думаю, что более правильнее сравнивать решение ORACLE RAC+ DataGuard и IBM DB2 with xkoto GRIDSCALE !!! GRIDSCALE is a database load balancer that uses patent-pending technology to dramatically improves transaction performance and data availability through horizontal scaling. Identical replicas of the database are placed in an active/active (n-way) cluster. GRIDSCALE sends DML requests to each node concurrently so that they’re always in sync. However, the Application does not need to wait for all the nodes to complete processing – this results in significant speed-up. а хадр разве умеет более одной стенбай машины иметь и пускать на них отчеты ? Насколько мне известно, IBM работает над этим ... думаю, что в DB2 Cobra, stanby база будет доступна для чтения ... С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 23:19 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Уважаемый коллега, специально для Вас, небольшой экскурс в DB2. В DB2 используется метод восстановления ARIES(1) (считается наиболее из продвинутых в индустрии). Агент обновляющий запись в БД изменяет соответствующую страницу, и создает запись в журнале, содержащую необходимую информацию для выполнения или отката (redo или undo) изменения. Различные техники и алгоритмы, такие включая XOR журналирование (XOR logging) , используются для минимизации количества данных для журналирования. Ни страницы с данными, ни буфер журнала не сбрасываются на диск немедленно (для оптимизации производительности). Процесс журналирования (logger) и менеджер буферного пула работают вместе для того, что бы соответствовать WAL протоколу (Write Ahead Logging – запись вперед) который гарантирует что ни одна измененная страница не попадет на диск раньше соответствующей этому изменению записи журнала. Только одна операция I/O всегда требуется транзакцией это форсированный сброс буфера журнала когда осуществляется COMMIT. Далее, в отличие от ORACLE, размер записи в логическом журнале DB2, требует гораздо меньше места для транзакции,что существенно сказывается на производительности, особенно в OLTP-окружении. --------------------------------------------------- DB2 9 = 2.4KB of log per transaction Oracle 10gR2 = 4.9KB of log per transaction Oracle 10g RAC = 43.0KB of log per transaction --------------------------------------------------- Reduced logging = increased performance !!! Логические журналы в DB2 - могут иметь зеркальные копии и т.д. Время восстановление DB2 и прикладной системы, зависит от архитектурного решения и реализации методологии - Disaster Recovery. Другими словами, стоимость решения будет зависеть от стоимости простоя прикладной задачи. В данном случае, более важно, что бы производитель СУБД предлагал достаточно гибкие возможности для выбора наиболее оптимального варианта решения. Я не люблю, когда у меня нет права выбора. В этом отношении, достаточно гибкий Informix c его технологией MACH11, да и DB2 имеет достаточно мощный арсенал - DB2 HADR, DB2 SQL-Applay Replication, Q-Replication и т.д. Нужно правильно применять те возможности, которые Вам предлагают. И еще, все что хорошо для ORACLE - это хорошо только для ORACLE!!! Нельзя проецировать свой устав в чужом монастыре ... :) Я за корректное сравнение или за плодотворное общение - это обогащает и сближает людей. С уважением, Вадимю ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2009, 23:51 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat- я утверждаю что заархивированные логи , которые находятся на ленте либо в каком либо другом месте недоступном серверу , но доступном утилите востановления ( onbar, ontape ) не нужны серверу при fast - recovery. это из серии "в трудные военные годы синус достигал значения 2 и даже 3". legical-log точно такая же цикличиская структура, что и REDO. если в эту структуру не влезли все активные транзакции, то что, информикс создает искривление пространства и в это трудное время в структуру logical-log влазит больше ? если нет то ему прийдется переключатся на следующий logical-log файл, этот в точности как и ораклу архивировать. onstat- То что журнал уже заархивирован и перенесен в архив не значит что он уже недоступен серверу. Полная аналогия с редо. нифига, редо это logical-log, если он заархивирован то это уже аналог арклога. onstat- Что хранится в физическом журнале вы прочитали ( поняли ) ? Насколько я понял вы пока не видите разницы между физическим и логическим журналами. да все там понятно, в следствии не сильно удачной архитектуры информиксу информиксу мало востановить датафайлы, нужно востановить картинку памяти, например, чтоб вернуть структуру блокировок, для этого и нужен еще и физический лог. ораклу достаточно проиграть REDO ... onstat- Вы его востановите . Этот файл может быть запорчен только в случае, когда глюк произошел во время переключения журналов или добавления чанков. В другое время он не изменяется. и что, если информикс чуть реже пишет в один из файлов, то теперь он гораздо надежен ? вы с oncfg_servername.servernum получите те же проблемы, что оракл с контролфайлом. те же яйца только в профиль. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 01:10 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
2 db2crash с вами вcе ясно. Тролей в Informix форуме не кормят. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 07:27 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat-2 db2crash с вами вcе ясно. Тролей в Informix форуме не кормят. Ну, вы покормили достаточно :) Потратили кучу времени, хотя, обычно, с анонимами трудно что-либо спокойно и внятно обсуждать - менталитет уже соответствующий. Так что, если уже в самом начале разговора не удается договориться "о понятиях" и предмете спора, то лучше не поддаваться на провокации :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 11:42 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
onstat-Это и понятно, база наверное была в bufferеd log, и документация об этом кажись (насколько я помню) предупреждает, что могут быть неприятные моменты с crash recovery. Да, базы были в bufferеd log из-за проблем производительности и слабых компов в начале внедрения системы. Вот только ссылки в официальной док-ии, которая предупреждает о возможности неподнятия сервера при bufferеd log, я не помню ни на версиях 7.31 ни на 9.30. Будет любопытно глянуть на такие ссылки. Да и неверное это в принципе - сервер может потерять несколько транзакций из-за bufferеd log, на это были согласны. Но НЕ подняться в онлайн после броска питания и последующего fast recovery ? Это уже явные баги алгоритма обеспечения целостности, которые , кстати, вылезли явно при введении, мною проклятого, фаззи чекпойнта. К счастью, потом (в 10-е) этот режим все таки отменили, чем еще раз подтвердили его ущербность. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 11:56 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashда все там понятно, в следствии не сильно удачной архитектуры информиксу информиксу мало востановить датафайлы, нужно востановить картинку памяти, например, чтоб вернуть структуру блокировок, для этого и нужен еще и физический лог. ораклу достаточно проиграть REDO ... Бред и досужий вымысел. В физическом логе фактически лежат теневые копии, неизменённые версии страниц данных из буферного пула. Очень близко к REDO. Никаких данных о блокировках и т.п. там нет. Задача физ. лога обеспечить максимально быстрое восстановление после падения - не нужно проигрывать длиииинный при активной работе журнал - встал, быстро восстановил картинку в памяти на момент незадолго до падения, быстро пробежался по логам, готово. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 13:22 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
informix/informixБред и досужий вымысел. В физическом логе фактически лежат теневые копии, неизменённые версии страниц данных из буферного пула. Очень близко к REDO. Никаких данных о блокировках и т.п. там нет. Задача физ. лога обеспечить максимально быстрое восстановление после падения - не нужно проигрывать длиииинный при активной работе журнал - встал, быстро восстановил картинку в памяти на момент незадолго до падения, быстро пробежался по логам, готово. а в чем смысл восстанавливать структуры памяти ? в оракле не успевшие записаться блоки из REDO расскладываются по датафайлам, почему информиксу приходится кроме этого еще и востанавливать еще и некие буфера памяти ? но больше интересует, что за магия происходит когда длинная транзакция переполнит все файлики logical-log, откуда возьмется спейс для продолжения работы транзакции кроме как архивирования (бэкапирования) одного из logical-log ? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 14:30 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF Далее, в отличие от ORACLE, размер записи в логическом журнале DB2, требует гораздо меньше места для транзакции,что существенно сказывается на производительности, особенно в OLTP-окружении. --------------------------------------------------- DB2 9 = 2.4KB of log per transaction Oracle 10gR2 = 4.9KB of log per transaction Oracle 10g RAC = 43.0KB of log per transaction --------------------------------------------------- Reduced logging = increased performance !!! не факт. в оракловом блоке хранится инфо о блокировках, потому не вижу ничего удивительного в том, что запись в REDO слегка больше. зато имея блокировки как атрибут блока ораклу отличии от дб2 не приходится заниматься эскалацией, что вредит конкурентному доступу, особенно в OLTP. что касается RAC, мне представляется более выгодной стратегией записать чуть больше, чем ждать отклика через HADR стендбай ноды, который понадобится для сравнимой с RAC доступностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 14:42 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashне факт. в оракловом блоке хранится инфо о блокировках, потому не вижу ничего удивительного в том, что запись в REDO слегка больше.Тут самое главное что писать, некотрые пишут делты строк, а некоторые целиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 15:13 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
Журавлев Денисdb2crashне факт. в оракловом блоке хранится инфо о блокировках, потому не вижу ничего удивительного в том, что запись в REDO слегка больше.Тут самое главное что писать, некотрые пишут делты строк, а некоторые целиком. да, в оракловом REDO дельта, но всего блока, вместе с блокировкой, а не отдельной записи. Oracle docsRedo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 15:36 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash, ЭТО ФАКТ !!! АРГУМЕНТ ДОСТАТОЧНО ВЕСОМЫЙ - Я оперирую не голыми словами, а конкретными результатами (цифрами). Вы можете соглашаться или не соглашаться (если Вы Oracle evangelist), но у Вас ничего нет кроме слов. Вам приводят реальные цифры и объективные доводы, а что в ответ - не зрелые рассуждения. Как-то, даже обидно за Вас. не факт. в оракловом блоке хранится инфо о блокировках, потому не вижу ничего удивительного в том, что запись в REDO слегка больше. зато имея блокировки как атрибут блока ораклу отличии от дб2 не приходится заниматься эскалацией, что вредит конкурентному доступу, особенно в OLTP. Вопрос экскаляции блокировок, это вопрос правильного выбора уровня изоляции транзакций, и архитектурного дизайна приложения. Если у разработчика криво стоят руки, то и оптимистический уровень его не спасет ... так как он еще более требовательнее и накладывает дополнительные проверки при выполнении последних изменений. что касается RAC, мне представляется более выгодной стратегией записать чуть больше, чем ждать отклика через HADR стендбай ноды, который понадобится для сравнимой с RAC доступностью. Это уже обсуждали. По всей видимости, у Вас плохо было с математикой. Время переключения между узлами HADR на порядок меньше чем у ORACLE (менее 15 секунд). Стоимость решения ниже, запас по процессорным ресурсам выше чем у ORACLE !!! Если у Вас упадет одна нода в ORACLE RAC, эффективность процессорного пула упадет существенно (для двух узлов на 50%) а это значить, что эффективность обработки массива данных упадет, время отклика на запрос увеличиться почти в двое .... вот к чему Вы клоните. Далее, DB2 на 20% эффективнее в OLTP задачах чем ORACLE при использовании на одной и той же аппаратной платформе. Эффективность OLTP-запросов, зависит и от дисковых операций I/O ввода/вывода. Чем больше ORACLE пишет в LOG тем хуже для ORACLE !!! Дисковые операции самые медленные... запись больших блоков, требует дополнительных буферов и т.д. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 22:52 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF ЭТО ФАКТ !!! АРГУМЕНТ ДОСТАТОЧНО ВЕСОМЫЙ - Я оперирую не голыми словами, а конкретными результатами (цифрами). факт ? где ? я не вижу. вижу цифирю записи дельты оракла + блокировки и дельты дб2, причем цифири без источника ... ну дельта с блокировкой больше, меня это не удивляет. хотите конкретные цифры - пожалуйте: http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105080802 http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105101702 GVF112GVF Вопрос экскаляции блокировок, это вопрос правильного выбора уровня изоляции транзакций, и архитектурного дизайна приложения. Если у разработчика криво стоят руки, то и оптимистический уровень его не спасет ... так как он еще более требовательнее и накладывает дополнительные проверки при выполнении последних изменений. For many tablespaces, it’s also probably advisable to turn off lock escalation. SAP’s cluster table interface can read cluster tables without causing a problem with lock escalation; however, with other ERPs, lock escalation is one of the biggest contributors to poor performance. http://www.db2mag.com/db_area/archives/1999/q2/99sp_yevich.shtml GVF112GVF Это уже обсуждали. По всей видимости, у Вас плохо было с математикой. Время переключения между узлами HADR на порядок меньше чем у ORACLE (менее 15 секунд). Стоимость решения ниже, запас по процессорным ресурсам выше чем у ORACLE !!! Если у Вас упадет одна нода в ORACLE RAC, эффективность процессорного пула упадет существенно (для двух узлов на 50%) а это значить, что эффективность обработки массива данных упадет, время отклика на запрос увеличиться почти в двое .... вот к чему Вы клоните. не думаю, что проблемы с математикой у меня. при 6 нодах RAC падение одной из них даст просадку всего на 16%, это при том что ресурсы HADR-ского стендбая тупо простаивают. учитывая, что стендбай нода может быть одна, простаивать будет 50% ресурсов. по записи лога в RAC, не вижу связи с временем переключения. попробую повторить: для того чтоб обеспечить сравнимую с RAC доступность дб2 придется писать не только в собственный лог, но и доставлять в синхронном режиме на стенбай ноду и записывать еще и там. на этом фоне 43кб выглядят гораздо привлекательней. GVF112GVF Далее, DB2 на 20% эффективнее в OLTP задачах чем ORACLE при использовании на одной и той же аппаратной платформе. разве, что в мечтах ... на сию секунду 6 нод RAC в тестах SAP-SD самая крупная конфигурация которая есть у IBM. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.01.2009, 23:38 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
vasilisonstat-Это и понятно, база наверное была в bufferеd log, и документация об этом кажись (насколько я помню) предупреждает, что могут быть неприятные моменты с crash recovery. Да, базы были в bufferеd log из-за проблем производительности и слабых компов в начале внедрения системы. Вот только ссылки в официальной док-ии, которая предупреждает о возможности неподнятия сервера при bufferеd log, я не помню ни на версиях 7.31 ни на 9.30. Будет любопытно глянуть на такие ссылки. Да и неверное это в принципе - сервер может потерять несколько транзакций из-за bufferеd log, на это были согласны. Но НЕ подняться в онлайн после броска питания и последующего fast recovery ? Это уже явные баги алгоритма обеспечения целостности, которые , кстати, вылезли явно при введении, мною проклятого, фаззи чекпойнта. К счастью, потом (в 10-е) этот режим все таки отменили, чем еще раз подтвердили его ущербность. В документации я тоже этого не нашел, мое кажись оказалось не верным, прошу прощения, если кого то ввел в заблуждение. Но помню , что когда то, где то это читал. Возможно это касалось какой то конкретной версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 10:01 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF ЭТО ФАКТ !!! АРГУМЕНТ ДОСТАТОЧНО ВЕСОМЫЙ - Я оперирую не голыми словами, а конкретными результатами (цифрами). Вадим, от размера шрифта и его цвета весомость аргументов не увеличивается :) Так что лучше не злоупотреблять этим, тем более в обычной сваре, которая уже давно вышла за пределы конструктивизма и желания услышать друг друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 11:39 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crashа в чем смысл восстанавливать структуры памяти ? в оракле не успевшие записаться блоки из REDO расскладываются по датафайлам, почему информиксу приходится кроме этого еще и востанавливать еще и некие буфера памяти ? Не нужно понимать каждое слово буквально. Как уже говорилось, физический лог очень близок к REDO. но больше интересует, что за магия происходит когда длинная транзакция переполнит все файлики logical-log, откуда возьмется спейс для продолжения работы транзакции кроме как архивирования (бэкапирования) одного из logical-log ? Чудес не бывает. Да и вопрос задан не по адресу. Я только хотел развеять заблуждения по поводу механизма быстрого восстановления Informix. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 13:48 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
informix/informix но больше интересует, что за магия происходит когда длинная транзакция переполнит все файлики logical-log, откуда возьмется спейс для продолжения работы транзакции кроме как архивирования (бэкапирования) одного из logical-log ? Чудес не бывает. Это точно. Разве ЭТО чудо? 1. Админ - держит свободное место в dbspace 2. Informix - автоматически создаёт ещё logical-log'и 3. К следующей версии Informix ( IBM Informix Dynamic Server (IDS) Roadmap and Business Update January 2009 ) обещают автоматическое создание dbspace (Нерадивому одмину прийдётся думать больше о месте на диске, а не в dbspace) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 14:42 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
АнатоЛой3. К следующей версии Informix ( IBM Informix Dynamic Server (IDS) Roadmap and Business Update January 2009 ) обещают автоматическое создание dbspace Прошу прощения - напутал чего-то. В этой ссылке подобного нет. Проясню - напишу дополнительно.... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 14:46 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
АнатоЛойЭто точно. Разве ЭТО чудо? Чудес не бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 14:54 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash, факт ? где ? я не вижу. вижу цифирю записи дельты оракла + блокировки и дельты дб2, причем цифири без источника ... ну дельта с блокировкой больше, меня это не удивляет. хотите конкретные цифры - пожалуйте: http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105080802 http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105101702 Немного о блокировках: 1. If the DB2 Lock List memory structure (which keeps track of locks within the database) is sized correctly, NO lock escalation occurs !!! The Self Tuning Memory Manager (STMM) will AUTOMATICALLY adjust this memory parameter to ensure lock escalation does NOT occur !!! 2. The Oracle UNDO table space and its UNDO segments require additional database storage and each reader of a data block must have its own copy of the data block: - High overhead due to the fact that Oracle does not keep track of locks in memory, but tracks write locks on disk 3. Data Blocks within the UNDO table space are marked for reuse when a write transaction using the data block completes: - Read transactions are NOT considered, this can result in the “read version” of the data block being overwritten before a read transaction completes, resulting in a roll back of the read transaction Факты были чуть Выше ... :) .. теперь, отностительно TPC-C тестов. Такие ссылки Я могу целый огород набросать. Подумать только, IBM System p 570-я ... почему не System p595 с Power 6 ??? IBM Power 595 Server Model 9119-FHA - http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=108061001 Можно посмотреть здесь - http://www.tpc.org/tpcc/results/tpcc_results.asp?orderby=dbms или здесь - http://www.tpc.org/tpcc/results/tpcc_perf_results.asp Вот вам еще один факт - DB2 9.5 delivered a world record breaking result of record breaking 6,085,166 tpmC on the TPC-C benchmark running on a single system 64-core IBM Power 595 server. This result is 49% higher than the Oracle 10gR2 result which was run on a single system 128-core HP Integrity Superdome server. Теперь о реальных фактах (а не в общем) ... можете поупражняться в сравнении: http://www.sap.com/solutions/benchmark/sd2tier.epx http://www.sap.com/solutions/benchmark/sd3tier.epx DB2 recently released a new SD 2-tier benchmark using the Power6-based processor that is superior to Oracle (8000 vs. 7300 SD users) and has held the SD 3-tier benchmark leadership position for over the last 4 years. Value proposition for IBM DB2 9: Cost/Benefit Case for SAP Enterprise Migrations [b]http://www-03.ibm.com/solutions/sap/us/detail/resource/L734039B13530T12.html http://www-03.ibm.com/solutions/sap/us/detail/landing/J233701A22235G06.html http://www.redbooks.ibm.com/abstracts/sg247385.html[/b] Думаю, что заказчики SAP - знают истинное положение вещей !!! For many tablespaces, it’s also probably advisable to turn off lock escalation. SAP’s cluster table interface can read cluster tables without causing a problem with lock escalation; however, with other ERPs, lock escalation is one of the biggest contributors to poor performance. http://www.db2mag.com/db_area/archives/1999/q2/99sp_yevich.shtml Да это же старая статья - 1999 года .... :) ...Вы бы еще за 1899 год привели статью ... ха-ха-ха Вам не следует вводит людей в заблуждение .. или это такой стиль прививает Ларик и вся его команда.... Насколько мне известно - SAP будет поддерживать только для Oracle 11gR2 (дальше - кирдык). Для общего развития: ----------------------- Oracle RAC was first made available in 2001. At the time, Larry Ellison made a lot of statements about how it would run Real Application (hence the name) like SAP and others. However, after 7 years, Oracle has yet to make RAC generally available for use with SAP. Why is that? Does it not live up to the promise of scalability and high availability under real world SAP workloads? In 2004 Oracle began to pilot SAP on RAC with 1 customer on Tru64 (a now dead OS) and 1 customer on AIX. One year later they had moved up to 2 pilot customers on each platform. We are now in 2008 and RAC is still under “Controlled availability on all these platforms”. Do you want to run on a platform that could not be GAed even after 7 years of work? This is increased risk to your project s. SAP does not support ASM (Automatic Storage Management with RAC) – But Oracle recommends ASM for all RAC installations. What do you do? Use an unsupported option or go with a suboptimal storage management system that Oracle does not recommend? Oracle RAC does not fully support rolling upgrades - Only 5% of patches are rolling upgradeable - No patchsets or Critical Patch Updates are rolling upgradeable - SAP requires shared Oracle home directory negating rolling upgrades Это меня позабавило ... да здравствует ORACLE RAC ... :) Теперь о производитеьности: ------------------------------ Oracle results on Power 6 show a dramatic performance drop per core when running with RAC You would need 76 cores of Oracle to equal DB2 on just 64 cores SAP SD 2-tier results for databases running on the IBM Power6 processor. There are 2 results for DB2 and several results for Oracle. The Oracle results are both with non-RAC (the 8 core result) as well as with RAC (the 32, 48, 64, and 80 core results). DB2 64-core result significantly exceeds the Oracle RAC 64-core result (by almost 20%). In fact DB2 on 64-cores delivers the same performance as Oracle on 76 cores. DB2 performance per core increases from 16-cores to 64-cores. In contrast the Oracle RAC results lose performance from the non RAC 8-core result down to the RAC clusters of 32, 48, 64, and 80 cores. ------------------------------------------------------------ SAP Performa nce - сравнение DB2 с Oracle: Performance measurement before and after migration from Oracle to DB2 on same System p hardware: DB2 40% faster Dialog DB2 40% faster Batch processing -------------------------------- и т.д. не думаю, что проблемы с математикой у меня. при 6 нодах RAC падение одной из них даст просадку всего на 16%, это при том что ресурсы HADR-ского стендбая тупо простаивают. учитывая, что стендбай нода может быть одна, простаивать будет 50% ресурсов. по записи лога в RAC, не вижу связи с временем переключения. попробую повторить: для того чтоб обеспечить сравнимую с RAC доступность дб2 придется писать не только в собственный лог, но и доставлять в синхронном режиме на стенбай ноду и записывать еще и там. на этом фоне 43кб выглядят гораздо привлекательней. Не отрицайте очевидное. Для начала посчитайте стоимость решения ORACLE RAC на 6-ти нодах для заказчика. Дальше, сравните линейную масштабируемость ORACLE RAC (к слову - DB2 работает с 1024 узлами в кластере) , какой прирост призводительности получает заказчик и за какие деньги. Дальше, приведите хоть один пример, работы ORACLE RAC c 6-нодами хотя бы на местном рынке и за одно расскажите почему при увеличении узлов в класте в ORACLE RAC, падает производительность ... :) ... если не сможет ... тогда спросите у Technical Director at Oracle at Kirk McGowan ... или например у другого светила ORACLE ... Don Burleson и Mike Ault ... Подсказка - Parallelism in RAC requires a lot of data movement between nodes !!! , сказываются архитектурные проблемы ... Don Burleson is likely the most prolific author on Oracle technology having written over 30 books on Oracle. He speaks at most Oracle conferences. On his website is an article entitled “Beware of using RAC with a data warehouse” http://www.dba-oracle.com/oracle_tips_rac_clusters_warehouse.htm At that same site is the quote from Mike Ault who literally wrote the book on RAC (author of “Oracle 10g Grid and Real Application Clusters”) who concurs with Burleson saying RAC is sub-optimal for data warehousing. The source for Mike Ault’s comments is at the same link above within the Burleson article. OARCLE Вам расскажет ... ха-ха-ха ... :) Теперь о математике ... Я Вам немного помогу ... :) Для начала, оценим стоимость ORACLE RAC (4-узла) - Oracle RAC on 4 4way AMD Servers running Linux, 4x4way AMD, 16 cpu Oracle/RAC,1st year maintenace, Total Oracle Price ~ $1.3M (внимание: Linux !!! Не AIX !!! ). Теперь оценим стоимость для INFORMIX (даже не DB2!!!) - IDS on 8way p5 570 add in a passive Standby: 2x8way p5 570 (AIX), 9 cpu IDS Ent, 1st year maintenace, HDR, Total Informix Price ~ 664k Обратите внимание - IDS has 100% Performance after failure Думаю, для начала будет достаточно. Про не линейность масштабирования ORACLE RAC - поговорим чуть позже. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 16:33 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVF, прощу прощения, но на весть ваш поток ответить не смогу, попробую парировать основные тезисы: 1. по блокировкам, эскалации и и/о, много фантазий, но не вижу фактов. факт состоит в том, что в конкретном тесте TPC на идентичном железе большее оракловое и/о тем не менее перевесило блокировки db2. я склонен думать, что именно на счет конкурентного доступа. 2. сравнивать производитеьность субд по тестам на разных желязяках, с разным кол-вом процессоров, да еще и на разных платформах по меньшей мере глупо. p5 570 мной был выбран именно потому, что этот tpc-c тест был выполнен на идентичном железе. в тестах SAP-SD на идеентичном железе не проводилось. 3. что касается RAC, в отличие от shared-nothing кластеров IBM реально обслуживает OLTP нагрузку. оракловый кластер реально работает у десятков тысячь клиентов, в том числе и на SAP инсталяциях. кластера IBM для OLTP нагрузки не годятся никак, 1024 нод в клатере db2 из разряда "Джо умеет печатать на машинке со скоростью 1024 знаков в минуту, но така фигня получается ..." 4. что касается масштабирования RAC - смотрим тесты SAP-SD Parallel: http://www.sap.com/solutions/benchmark/sd1_results.htm а конкретно IBM System p 570 на 2х,3х,4х и пяти нодах RAC 10g. четыре ноды RAC это 32 процессора = 151800 SAPS теперь смотрим не кластерные результаты IBM Power 595, 32 Processors на db2 9.5 = 177950 saps т.е. в реальности некластерный db2 9.5 всего на 15% производительней четырех нод RAC 5. математика: теперь возьмите калькулятор и посчитайте к четырем нодам RAC понадобится всего одна небольшая нода p570 для обеспечения доступности при выходе из строя одного из компов и сколько будет стоить дублирование такого монстра как p595. 6. а вот тут смеялсо GVF112GVF Теперь оценим стоимость для INFORMIX (даже не DB2!!!) - IDS on 8way p5 570 add in a passive Standby: 2x8way p5 570 (AIX), 9 cpu IDS Ent, 1st year maintenace, HDR, Total Informix Price ~ 664k вы в курсе что только один 8-way p570 это более $2M (без СХД) ? две такие махины с информиксом это более $5M, только на половину такой суммы можно сотню "4x4way AMD" 7. байки агенства ОБС о супорте крыть нечем. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 18:32 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
меня тут поправили: IBM Power 595, 32 Processors на db2 9.5 = 177950 saps, это на 5Ghz прцессорах, четыре ноды RAC были на 4.7ghz, значит разница с четырьмя нодами RAC гораздо меньше 15%. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2009, 19:46 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash, Отвечаю по порядку ... :) 1. На счет фантазий ... по блокировкам, эскалации и и/о, много фантазий, но не вижу фактов. факт состоит в том, что в конкретном тесте TPC на идентичном железе большее оракловое и/о тем не менее перевесило блокировки db2. я склонен думать, что именно на счет конкурентного доступа. При чем сдесь операции I/O к блокировкам ???? Если у Вас есть сомнения по поводу достоверной информации, обращайтесь в SAP или в IBM. И нечего народу лапшу вешать на уши. Те кто понимают, поймут о чем идет речь. 2. Читайте внимательно, Вы же мастер своего дела. сравнивать производитеьность субд по тестам на разных желязяках, с разным кол-вом процессоров, да еще и на разных платформах по меньшей мере глупо. p5 570 мной был выбран именно потому, что этот tpc-c тест был выполнен на идентичном железе. в тестах SAP-SD на идеентичном железе не проводилось. Я могу сравнивать производительность на разных аппартных платвормах и на одной и той же аппаратной платформе, в отличие от Вас. Производительность DB2 yf 15-20% выше на одной и той же аппаратной платформе !!! Это есть факт !!!! Если Вы хотите продать заказчику экстенсивную технологию, то есть затратную и аргументировать ему, что делаете ему великое благо - это тоже позиция .... все хотят заработать ... :) ... только не надо нам вешать лапшу !!! Дураков хватает .... Ваш контингент - казнокрады !!! Любой трезвомыслящий руководитель не будет выбрасывать день на ветер ... если он конечно не идиот или засланный казачок ... :) 3. Вы не только не владеете информацией, но и несете бред сивой кобылы !!! что касается RAC, в отличие от shared-nothing кластеров IBM реально обслуживает OLTP нагрузку. оракловый кластер реально работает у десятков тысячь клиентов, в том числе и на SAP инсталяциях. кластера IBM для OLTP нагрузки не годятся никак, 1024 нод в клатере db2 из разряда "Джо умеет печатать на машинке со скоростью 1024 знаков в минуту, но така фигня получается ..." Фигня получатся, если человек не понимает о чем говорит. Вы можете спросить у SAP И IBM сколько у кого инсталляций. Отмечу сразу, что больше всего SAP было установленно на HP !!! Что касается 1024-узлов, это реально работающая система, которую устанавливали в jодной из лаборатории IBM !!! Теперь на счет OLTP - Вы наверное не знаете, что самый быстрый OLTP-движок, это INFORMIX, после него идет DB2 (DSA-архитектура Infromix, обеспечивает мультипоточность в контксте процесса). Последние версии DB2, используют облегченные процессы на уровне операционной системы. Это упрощает управление и распределение памяти на уровне операционной системы в контексте виртуализации аппартных ресурсов - ведь это так модно сейчас. Например, оптимизатор DB2 может запросить у менеджера операционной системы информацию, для эффективного планирования и управления выполнения SQL-запросов. Думаю ,что ORACLE - это и не снилось в кошмарном сне .... ха-ха-ха ... 4. Каждый хочет увидеть то, что хочет ... :) что касается масштабирования RAC - смотрим тесты SAP-SD Parallel: http://www.sap.com/solutions/benchmark/sd1_results.htm а конкретно IBM System p 570 на 2х,3х,4х и пяти нодах RAC 10g. четыре ноды RAC это 32 процессора = 151800 SAPS теперь смотрим не кластерные результаты IBM Power 595, 32 Processors на db2 9.5 = 177950 saps Мой милый друг, смотрите между строй ... как SAP-считает сапсы, Я знаю, в отличи от Вас. Поверьте, у меня для этого есть полное описание методологии такого расчета ... :) Мне не нужно рассказывать чем отличется System p 570 от System p 595. И вот еще что, стоимость HW в проэкте - это всего лишь - 30-40% от общей стоимости. Делайте выводы ... кому и сколько Вы платите !!! т.е. в реальности некластерный db2 9.5 всего на 15% производительней четырех нод RAC Это не мало ... Попробуйте сравнить кластерный DB2 c ORACLE RAC или кишка тонка ... 5. Вас наверное плохо учили по математике .... Сканави ... :) математика: теперь возьмите калькулятор и посчитайте к четырем нодам RAC понадобится всего одна небольшая нода p570 для обеспечения доступности при выходе из строя одного из компов и сколько будет стоить дублирование такого монстра как p595. Попробуйте задачку из Моденова ... :) .. Почему Вас тянет сравнивать самолет с пароходом ??? Уж если сравнивать, то только 570-е конфигурации или 595-е .... Вычислительный кластер DB2 можно построить и на 570-серии и на 595-й! И все равно это будет дешевле !!! Не за счет железа ... за счет стоимости лицензий ORACLE+RAC. И дело сдесь не в IBM железках ... какую бы Вы платформу не выбрали .. стоимость решения ORACLE RAC всегда выше ... :) 6. Был у нас такой юморист .... Вы в курсе что только один 8-way p570 это более $2M (без СХД) ? две такие махины с информиксом это более $5M, только на половину такой суммы можно сотню "4x4way AMD" Пример из жизни ... в одном из Телекомов, жил себе INFORMIX на Intel железяке (32-bit, 4GB RAM), обслуживал биллинговую систему (~ 300 пользовалей) и не очем не тужил. Пришли верующий дяди из ORACLE ... отстой .. давайте повысим капатализацию вашего бизнеса ... :) Установили ORACLE на старую железку ... заказчику чуть кондрат не хватил ... максимум 60-пользователей ... вот и весь сказ ... :) Теперь о цифрах: DB2 на 25% требует меньше ресурсов чем ORACLE, INFORMIX на 75% чем ORACLE. В OLTP-задачах, ORACLE боится INFORMIX как огня. При меньших ресурсах - эффективность выше. Байки про великие OLTP результаты ORACLE нужны тем, кому нужно обоснование расходной части бюджетный средств - другими словами аферистам, тем которые лезут Вам в карманы !!! Сказка ложь да в ней намек ... добрый молодцам урок !!! С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2009, 01:48 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
GVF112GVFПроизводительность DB2 yf 15-20% выше на одной и той же аппаратной платформе !!! разве, что в ваших эротических фантазиях, а вот в телекоме, тестах tpc и sap ситуация ровно противоположная. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2009, 14:25 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
разве, что в ваших эротических фантазиях, а вот в телекоме, тестах tpc и sap ситуация ровно противоположная. Когда человеку нечего сказать - он начинает пошлить .. стыдно за Вас. Ваши амбиции, превышают чувство объективной реальности, поэтому, чем быстрее Вы избавитесь от всяких галлюцинаций, тем более зрелыми будут Ваши суждения и восприятие окружающего мира - дерзайте ... у Вас еще шанс. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2009, 14:45 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
2 db2crash db2crashGVF112GVFПроизводительность DB2 yf 15-20% выше на одной и той же аппаратной платформе !!! разве, что в ваших эротических фантазиях, а вот в телекоме, тестах tpc и sap ситуация ровно противоположная. назовите то хоть телеком у которых так, как вы сказали :) 2 all а где Informix разрабатывают? например, все вокруг-да-около DB2 активно в Индии "пишут", InfoSphere - Германия... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2009, 15:43 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
IBM это матрица. В Индии для подразделения InfoSphere (DB2, Informix, DataStage, Cognos...) Пишут только GUI средства, поэтому они такие кривые у IBM долго были и думаю будут Informix - 80% разрабатывается в Канзасе. DB2 UDB - 90% разрабатывается в Торонто DB2 zOS - 90% в Санта-Терезе (Калифорния) немного в Москве DB2/400 - 100% где-то в штате New-York Они кстати и друг для друга много пишут. Например .Net провайдер для Informix в Torolab разрабатывается, HADR в Канзасе писали и так далее. Unicode для Informix из DB2 взяли. В следующих релизах DB2 like tablespace для Informix обещают.... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2009, 17:20 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
nkulikov, Коля, привет! Очень рад, что ты нашел время посетить этот форум. Как у тебя дела, какие планы на будущее? В IBM не тянет ? ... :) Напиши мне на домашний e-mail. С уважением, Вадим. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2009, 11:45 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash вы в курсе что только один 8-way p570 это более $2M (без СХД) ? это Вы сами такое придумали или "подсказал" кто ? POWER 570 (Model 9117-MMA3) по US price list чуть больше полумиллиона USD, ну и стандартная 40%-ая скидка (для тех, кто "в теме") ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2009, 20:48 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
2mitek цена взята из TPC репорта, для тех кто в теме там не похульничаешь и Discounts are based on US list prices for similar quantities & configurations including pre-payment for maintenance. The discount of 43% applies to the totality of all items with price source of "1". http://www.tpc.org/results/FDR/TPCC/IBM_570_20070522_FDR.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2009, 23:41 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
db2crash2mitek http://www.tpc.org/results/FDR/TPCC/IBM_570_20070522_FDR.pdf Тогда понятно. TPC-C (с его гипертрофированными монстрами) это для тех, кому "шашечки" Те, кому "ехать", смотрят в другие места (тот же SAP SD) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2009, 12:59 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
SAP мало того, что не публикует цены, но еще и на прямую запрещает использовать его тесты для сравнения по ценам. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2009, 14:14 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
nkulikovIBM это матрица. В Индии для подразделения InfoSphere (DB2, Informix, DataStage, Cognos...) Пишут только GUI средства, поэтому они такие кривые у IBM долго были и думаю будут Informix - 80% разрабатывается в Канзасе. DB2 UDB - 90% разрабатывается в Торонто DB2 zOS - 90% в Санта-Терезе (Калифорния) немного в Москве DB2/400 - 100% где-то в штате New-York Они кстати и друг для друга много пишут. Например .Net провайдер для Informix в Torolab разрабатывается, HADR в Канзасе писали и так далее. Unicode для Informix из DB2 взяли. В следующих релизах DB2 like tablespace для Informix обещают.... 2 nkulikov спасибо за инфо. по GUI да уж, были подозрения, чего только один IBM Data Studio "стOит" при гигабайтном размере... Informix 12? когда? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2009, 03:05 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
herrInformix 12? когда? Так ведь совсем недавно публиковали в теме Ресурсы по Informix IDS 2009 Roadmap and Future Direction ftp://ftp.software.ibm.com/software/data/informix/pubs/presentations/IDS-2009-Roadmap-012909.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2009, 16:09 |
|
Informix -> DB2 (не хочу!)
|
|||
---|---|---|---|
#18+
vasilisherrInformix 12? когда? Так ведь совсем недавно публиковали в теме Ресурсы по Informix IDS 2009 Roadmap and Future Direction ftp://ftp.software.ibm.com/software/data/informix/pubs/presentations/IDS-2009-Roadmap-012909.pdf Что-то я не нашел ничего про IDS12 в этой презентации. Может просто смотрел плохо. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2009, 16:53 |
|
|
start [/forum/topic.php?all=1&fid=44&tid=1607893]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
126ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 236ms |
0 / 0 |