Informix displaces Oracle at China Telcom / Сравнение СУБД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix displaces Oracle at China Telcom

203 сообщений из 203, показаны все 9 страниц

все

Informix displaces Oracle at China Telcom

#35727017

ifmxuser

Гость

Informix displaces Oracle at China Telcom

...

Рейтинг:

0 / 0

22.12.2008, 08:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727569

Yo.!

Гость

без версионности пытатся переманить пользователей оракла, да еще и на OLTP - утопия.

...

Рейтинг:

0 / 0

22.12.2008, 12:52

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727576

locky

Участник

Откуда: Харьков, Украина

Сообщения: 66 149

Рейтинг: 0 / 0

Yo.!,

так вроде уже переманили, или еще нет?

...

Рейтинг:

0 / 0

22.12.2008, 12:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727609

Yo.!

Гость

locky,

одного ? за это время с Informix на оракл сбежало десять (судя по репортам IDC/Gartner) ...

...

Рейтинг:

0 / 0

22.12.2008, 13:04

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727702

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

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

А в чем прелесть версиoнности на OLTP ?

в конкретный примерах, если не затруднит?

...

Рейтинг:

0 / 0

22.12.2008, 13:38

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727721

./fglgo

Гость

Yo.!locky,

одного ? за это время с Informix на оракл сбежало десять (судя по репортам IDC/Gartner) ...
брехня, ни одной ссылки не нагуглил

...

Рейтинг:

0 / 0

22.12.2008, 13:42

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727817

Yo.!

Гость

onstat-
А в чем прелесть версиoнности на OLTP ?

в конкретный примерах, если не затруднит?
прелесть - получение консистентных набора без блокирования половины субд и проблем с дедлогами, вам это уже несколько раз демонстрировалось. ;) за примером идите на TPC-E, там очень красиво видно как в первом тесте МС пыталась запустить без версионности (осталась закоментированая строка), но в итогде длинный читающий запрос был выполнен все же на уровне IL Snapshot. в последних тестах еще один длинный запрос начали выполнять на IL snapshot.

2./fglgo
http://www.gartner.com/it/page.jsp?id=492144

доля информикс сдулась до 1.4% к 2004 году и сильно меньше 1% (статистической погрешности) сегодня.

...

Рейтинг:

0 / 0

22.12.2008, 14:01

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727884

./fglgo

Гость

./fglgo
http://www.gartner.com/it/page.jsp?id=492144

доля информикс сдулась до 1.4% к 2004 году и сильно меньше 1% (статистической погрешности) сегодня.
данные 4-летней давности давности, смешно.. Посмотрим на эти данные по результатам этого года,
особенно с учетом китайского мнения:)
PS: А версионность все-таки в информиксе есть...

...

Рейтинг:

0 / 0

22.12.2008, 14:19

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35727991

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
А в чем прелесть версиoнности на OLTP ?

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

Буду премного благодарен если приведете ссылку, а то у меня что то с памятью, видимо не совсем убедительными были доводы.
С удовольствие перечитаю еще раз, может я чего то тогда недопонимал.

Можете мне показать как две сессии использующие select ... for update
будут пользоваться версионными механизмами и не будут блокировать друг друга на пересекающемся наборе данных?

Yo.!
за примером идите на TPC-E, там очень красиво видно как в первом тесте МС пыталась запустить без версионности (осталась закоментированая строка),

ИМХО Вы случаем не ошиблись веткой ?
МС тут не причем. Его обсуждают в других топиках.

Yo.!
но в итогде длинный читающий запрос был выполнен все же на уровне IL Snapshot. в последних тестах еще один длинный запрос начали выполнять на IL snapshot.

Откуда в OLTP длинные запросы?
Откуда у Вас информация, что в Informix Dynamic Server 11.5 нет версионности?

з.ы. Вы пофлудить или потролить в эту ветку заглянули?

...

Рейтинг:

0 / 0

22.12.2008, 14:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728148

Yo.!

Гость

я то веткой не ошибся, а у вас какая-то истерика ;)
расслабтесь и покажите где в документации информикса можно почитать о появившейся версионности. я не видел в планах IDS никаких намеков на версионность как минимум планах до 2012 года. видел лишь планы по переносу хинтов из дб2 позволяющие реализовать оптимистическу блокировку хоть в каком-то виде.
что касается вашей памяти, то вам, в том числе по select for update очень подробно разжували в этой ветке:
/topic/342527&pg=6

откуда в олтп берутся длинные читающие запросы читайте описание TPC-E у IBM, это OLTP тест нагрузки типичной брокерской компании.

...

Рейтинг:

0 / 0

22.12.2008, 15:45

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728162

Yo.!

Гость

./fglgo
данные 4-летней давности давности, смешно.. Посмотрим на эти данные по результатам этого года,
особенно с учетом китайского мнения:)

только в случае если доля поднимится выше статистической ошибки ....
./fglgo PS: А версионность все-таки в информиксе есть...
с нетерпением жду урл с подробностями.

...

Рейтинг:

0 / 0

22.12.2008, 15:49

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728185

Yo.!

Гость

onstat-
Откуда у Вас информация, что в Informix Dynamic Server 11.5 нет версионности?

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.perf.doc/ids_prf_424.htm

не вижу ни намека на версионность в IDS 11.5 ...

...

Рейтинг:

0 / 0

22.12.2008, 15:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728258

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!я то веткой не ошибся, а у вас какая-то истерика ;)
расслабтесь и покажите где в документации информикса можно почитать о появившейся версионности. я не видел в планах IDS никаких намеков на версионность как минимум планах до 2012

Такое определение версионности Вас устроит ?

IBM Informix Dynamic Server, Version 11.10
The LAST COMMITTED feature can reduce the risk of locking conflicts when an application attempts to read a row on which another session holds an exclusive lock while modifying data. When this feature is enabled, the database server returns the most recently committed version of the data, rather than wait for the lock to be released.

взято отсюда

В версии 11.50 эта возможность тоже присутствует.

Yo.!
что касается вашей памяти, то вам, в том числе по select for update очень подробно разжували в этой ветке:
/topic/342527&pg=6

Единственный вывод в котором я убедился по результатам того топика :

onstat-
Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

Все остальное было очень познавательно, но не убедительно.

...

Рейтинг:

0 / 0

22.12.2008, 16:22

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728276

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Откуда у Вас информация, что в Informix Dynamic Server 11.5 нет версионности?

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.perf.doc/ids_prf_424.htm

не вижу ни намека на версионность в IDS 11.5 ...

http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?topic=/com.ibm.sqls.doc/ids_sqs_1165.htm

Use the LAST COMMITTED keyword option of the Committed Read isolation level to reduce the risk of exclusive row-level locks held by other sessions either causing applications to fail with locking errors, or preventing applications from reading a locked row until after a concurrent transaction is committed or rolled back. In contexts where an application attempts to read a row on which another session holds an exclusive lock, these keywords instruct the database server to return the most recently committed version of the row, rather than wait for the lock to be released.

...

Рейтинг:

0 / 0

22.12.2008, 16:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728295

Yo.!

Гость

onstat-
Такое определение версионности Вас устроит ?
нет конечно
этот хинт позволяет запросу получать, что-то промежуточное между read commited и dirty read, ничего близкого к версионному механизму он не дает.

ЗЫ. ну хотя бы по select for update то освежили память ;)

...

Рейтинг:

0 / 0

22.12.2008, 16:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728363

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Такое определение версионности Вас устроит ?
нет конечно
этот хинт позволяет запросу получать, что-то промежуточное между read commited и dirty read, ничего близкого к версионному механизму он не дает.

Это Ваше право не соглашаться.
Я не буду Вам доказывать, что этот механизм такой же как псевдо-версионный механизм
oracle или что он лучше чем у Oracle, он другой, и он позволяет писателям не блокировать читателей,
А в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам
для получения более высокой производительности при паралельной обработке транзакций.

Yo.!
ЗЫ. ну хотя бы по select for update то освежили память ;)

Извините нет , в контексте данного вопроса ( преймещества версионного механизма в OLTP )
у меня ничего не освежилось.

...

Рейтинг:

0 / 0

22.12.2008, 17:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728377

./fglgo

Гость

Yo.!с нетерпением жду урл с подробностями.
Немного корявый перевод , но дает вполне конкретный ответ на Ваш вопрос.

...

Рейтинг:

0 / 0

22.12.2008, 17:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728711

Yo.!

Гость

onstat-
Я не буду Вам доказывать, что этот механизм такой же как псевдо-версионный механизм
oracle или что он лучше чем у Oracle, он другой, и он позволяет писателям не блокировать читателей,
А в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам
для получения более высокой производительности при паралельной обработке транзакций.
конечно не будете, потому, что даже ребенку видно "с другими доступными уровнями изолированности" ничерта не получить. попробую на пальцах, эта шняга сильно слабее READ COMMITED реализованого в блокировочниках, т.к. ко всем феноменам RC добавляет еще несколько своих. комбинирования с более строгими уровнями вообще бессмыслено, т.к. противоречит уже повторяемому чтению, не то что сериализабле. ну и в заключении - это конечно хорошо, что "он позволяет писателям не блокировать читателей", но собственно грязное чтение, которое гораздо ближе к этой фичи тоже не накладывает блокировки, но ближе к согласованому, неблокируемому чтению версионника не становится.

...

Рейтинг:

0 / 0

22.12.2008, 19:09

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728736

Yo.!

Гость

./fglgo
Немного корявый перевод , но дает вполне конкретный ответ на Ваш вопрос.
а это совсем из другой оперы вроде. кажется эти версии нужны были только для того, чтоб секондари нода, которая не имеет данных о последних закомиченых транзакциях могла бы хоть как-то ловить ошибки согласованности.

...

Рейтинг:

0 / 0

22.12.2008, 19:20

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728784

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!
конечно не будете, потому, что даже ребенку видно "с другими доступными уровнями изолированности" ничерта не получить. попробую на пальцах, эта шняга сильно слабее READ COMMITED реализованого в блокировочниках,

Ну слабее и что ?
Никто же не запрешает пользоваться стандартным infromix READ COMMITED
и другими более сильными уровнями.

Yo.!
т.к. ко всем феноменам RC добавляет еще несколько своих. комбинирования с более строгими уровнями вообще бессмыслено, т.к. противоречит уже повторяемому чтению, не то что сериализабле. ну и в заключении - это конечно хорошо, что "он позволяет писателям не блокировать читателей",

dirty read самый слабый
Sirialzable самый сильный
Dirty read слабее LC слабее RC слабее RR слабее Sirialzable.

Yo.!
но собственно грязное чтение, которое гораздо ближе к этой фичи тоже не накладывает блокировки, но ближе к согласованому, неблокируемому чтению версионника не становится.

Возможность вычитать значение из undo в oracle RC и воспользоваться
этим значением точно также же близка к dirty read.

Поэтому логично что oracle RC тоже слабее informix RC .

...

Рейтинг:

0 / 0

22.12.2008, 19:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728797

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

onstat-

Возможность вычитать значение из undo в oracle RC и воспользоваться
этим значением точно также же близка к dirty read.

Поэтому логично что oracle RC тоже слабее informix RC .

Также на пальцах , что видно и ребенку.

Значение в undo консистентно на какой то момент в прошлом,
но оно не всегда консистентно относительно SCN последенего коммита в базе
изменившего запись.

...

Рейтинг:

0 / 0

22.12.2008, 20:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728823

Yo.!

Гость

onstat-
Никто же не запрешает пользоваться стандартным infromix READ COMMITED
и другими более сильными уровнями.

не говорите ерунды, LAST COMMITTED запрещает , он каждый раз будет получать другое значение одной и той же записи т.е. даже неповторяемое чтение уже нарушает. к стате говоря формально LAST COMMITTED не нарушает RC, он слабее того RC, что сейчас используются в блокировочниках.

onstat-
Поэтому логично что oracle RC тоже слабее informix RC .
не смешите мои тапочки, оракловый RC получает согласованое чтение на момент запуска стейтмента, RC информикса (пофигу ест) получает кашу из записей которые были на момент старта, записи которые появились по ходу выполнения запрса, он не прочтет записи, что вроде как были в момент старта, но были удалены раньше и самое замечательное это НЕСКОЛЬКО РАЗ одни и той же записи (запись после чтения RC-читателя может быть другой перемещена после обновления конкурентным писателем). с опцией LAST COMMITTED каша лишь усугубляется и мне собственно совершенно не понятно чего в этой каше вы увидили больше похожего на версионник или вы уже не настаиваете на появлении версионности в IDS ?

...

Рейтинг:

0 / 0

22.12.2008, 20:32

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728849

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> этот хинт позволяет запросу получать, что-то промежуточное между read
> commited и dirty read, ничего близкого к версионному механизму он не дает.

Чего вы такое напридумывали-то ? Если он читает ЗАКОММИЧЕННЫЕ записи,
как же он может быть ближе к dirty read ? Ну сохраняет он там записи
где-то на время модификации и подсовывает читающим транзакциям.
Какие аномалии-то при этом могут возникнуть, которые запрещены RC ?
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

22.12.2008, 20:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728858

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> ко всем феноменам RC добавляет еще несколько своих. комбинирования с

Какие аномалии он добавляет ? И потом, даже если он их добавляет,
главное, чтобы соблюдались феномены RC. То есть он может быть и равнозначен RC,
и выше.

> более строгими уровнями вообще бессмыслено, т.к. противоречит уже
> повторяемому чтению, не то что сериализабле.

Чем ? Уж покажите.

> конечно хорошо, что "он позволяет писателям не блокировать читателей",
> но собственно грязное чтение, которое гораздо ближе к этой фичи тоже не
> накладывает блокировки, но ближе к согласованому, неблокируемому чтению
> версионника не становится.
Накладывает оно блокировки или нет - дело десятое. Главное - есть или
нет аномалии.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

22.12.2008, 20:50

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728866

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> не говорите ерунды, LAST COMMITTED *запрещает*, он каждый раз будет
> получать другое значение одной и той же записи т.е. даже неповторяемое
> чтение уже нарушает.

Ну, допустим, нарушает он Rep. read. Да и фиг с ним. RC тоже нарушает
Rep.read. Это только доказывает, что LAST COMMITTED ниже, чем Rep.read
и всё. Но для того, чтобы доказать, что LAST COMMITTED ниже read committed,
вам нужно показать, что в каких=то случаях LAST COMMITTED может прочитать
незакоммиченные данные.

к стате говоря формально LAST COMMITTED не нарушает
> RC, он слабее того RC, что сейчас используются в блокировочниках.
>

Что значит "RC, что сейчас используются в блокировочниках" ?
Уровни изоляции прописаны в стандарте ANSI.

> не смешите мои тапочки, оракловый RC получает согласованое чтение на
> момент запуска стейтмента, RC информикса (пофигу ест) получает кашу из
> записей которые были на момент старта, записи которые появились по ходу

А откуда вы знаете, может он тоже на время начала стейтмента или транзакции
берёт ? я вот не читал про это в топике или где-то ещё, это утверждение
ваше на каких-то более глубоких знаниях основано?

Ну, даже допустим это так. Но это ещё не говорит, что LAST COMMITTED
ниже READ COMMITTED. READ COMMITTED тоже читает неизвесно какой транзакцией
закоммиченые данные, и повторно может их не прочитать.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

22.12.2008, 20:59

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728873

kdv

Участник

Откуда: iBase.ru

Сообщения: 30 139

Рейтинг: 0 / 0

вот так возникают мифы о блокировочных версионниках...
стоило только "разблокировать" конфликты R-W в Read Committed - и уже сразу "версионник".

см. тут
http://informix-technology.blogspot.com/2007/02/cheetah-spot-by-spot-last-committed.html

Some of you with knowledge from other RDBMS like Oracle or Postgres may be wondering what's new about this... Well, historically there have been two types of RDBMS: The versioning (each transaction gets a "version" number that marks all the data it changes) and the non-versioning. The versioning RDBMSs have always this sort of isolation levels because each transaction sees the "current image" of the Database. But the non-versioning RDBMS usually didn't implement this. They have more light-weight reading primitives that read the data directly (not the before images marked with earlier versions stamps) and this causes the locking conflicts.
Also, some versioning RDBMS don't support the ANSI UNCOMMITTED READ, because the way they read doesn't allow it.

So, it's has been a kind of trade-off. But currently, most of the non-versioning databases implement this kind of COMMITTED isolation without blocking the readers.

...

Рейтинг:

0 / 0

22.12.2008, 21:06

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728876

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Никто же не запрешает пользоваться стандартным infromix READ COMMITED
и другими более сильными уровнями.

не говорите ерунды, LAST COMMITTED запрещает , он каждый раз будет получать другое значение одной и той же записи т.е. даже неповторяемое чтение уже нарушает. к стате говоря формально LAST COMMITTED не нарушает RC, он слабее того RC, что сейчас используются в блокировочниках.

Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?

Yo.!
onstat-
Поэтому логично что oracle RC тоже слабее informix RC .
не смешите мои тапочки, оракловый RC получает согласованое чтение на момент запуска стейтмента, RC информикса (пофигу ест) получает кашу из записей которые были на момент старта,

[/quot]
Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

Yo.!
записи которые появились по ходу выполнения запрса, он не прочтет записи, что вроде как были в момент старта, но были удалены раньше и самое замечательное это НЕСКОЛЬКО РАЗ одни и той же записи (запись после чтения RC-читателя может быть другой перемещена после обновления конкурентным писателем).

с опцией LAST COMMITTED каша лишь усугубляется и мне собственно совершенно не понятно чего в этой каше вы увидили больше похожего на версионник или

Если Вам нужен RR так и пользуйтесь RR зачем сюда притягивать за уши использование
RС , который вернет некий набор записей консистентный на момент запуска,
Меня лично и многи других консистентнось на момент запуска запроса мало интересует,
меня интересует
консистентность записи на момент fetch это должно быть текущее реальное значение,
а не какоето там реальное в прошлом и с неизвесным значением в момент доступа( fetch ).
Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.

Yo.!
вы уже не настаиваете на появлении версионности в IDS ?

В вашей понимании нет.

...

Рейтинг:

0 / 0

22.12.2008, 21:10

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728903

Yo.!

Гость

MasterZiv
Что значит "RC, что сейчас используются в блокировочниках" ?
Уровни изоляции прописаны в стандарте ANSI.
RC из стандарта требует лишь того, чтоб запись была закомиченой, закомиченое значение можно к примеру и из индекса брать, вместо того чтоб ждать освобождения блокировки таблицы. в реальных серверах все же брать из индекса пока запись экслюзивно залочена достаточно редкое явление

MasterZiv
А откуда вы знаете, может он тоже на время начала стейтмента или транзакции
берёт ? я вот не читал про это в топике или где-то ещё, это утверждение
ваше на каких-то более глубоких знаниях основано?
ну раздел концепты из доки по ораклу хоть и на вражеском языке, но я осилил :)

MasterZiv
Ну, даже допустим это так. Но это ещё не говорит, что LAST COMMITTED
ниже READ COMMITTED. READ COMMITTED тоже читает неизвесно какой транзакцией
закоммиченые данные, и повторно может их не прочитать.

ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED потому как выдает более несогласованое чтение, чем RC типичного блокировочника. если мы с такой опцией расчитываем какие-нибудь бонусы расчитываем у нас больше ерунды получится, чем при обычном RC. посути если грязное чтение при блокируемой записи берет грязное значение, то LAST COMMITTED в том же случае возьмет последнее, закомиченное, а версионник будет реконструировать то значение какое было на момент старта транзакции/стейтмента. и НИКОГДА не прочтет одну и ту же запись двадцать пять раз.

...

Рейтинг:

0 / 0

22.12.2008, 21:33

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35728927

Yo.!

Гость

onstat-
Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?
вы скзали, что опция LC "в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам". полная ерунда - эта опция может быть использована только с IL Read committed и только с ним. больше ни с каким уровнем. да и дает оно не больше свободы, а больше рассогласованости в наборе.

onstat-
Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

признаю, но блокировочные уровни дающие согласованный набор требуют залочить по бол базы и часто не применимы в реальных олтп. в результате приходится проэктировать БД так чтоб можно было получать согласованные данные на уровне RC, типа таких как сумма "закрытия рабочего дня" + "проводки текущего дня". мне

onstat-
Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.

не правада, ни стандарт ни RC в субд MSSQL такого не требуют/гарантируют. MSSQL на RC может прочесть залоченую эксклюзивно запись взяв значение из индекса (если конкурентная транзакция изменило значение строки на то же значение, что и было до этого)

...

Рейтинг:

0 / 0

22.12.2008, 21:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729007

Zhora

Участник

Откуда: USA New York

Сообщения: 371

Рейтинг: 0 / 0

kdv...Well, historically there have been two types of RDBMS...
Исторически было только 2 типа: Oracle, который сделал все правильно с саого начала и все остальные (IBM/Sybase=>ANSI), сделавшие это неправильно и десятилетиями отстаивавшие совершенно абсурдый механизм реализации уровней изоляции с помощью блокировок, пока не признали что были неправы (teоретически в 1995 -> Critique of ANSI isolation levels статья, а практически в MSSQL 2005 snapshot isolation).
Почитайте биографию Jim-a Gray (его печальный конец мне кажется связан с
этим, так как он и был осовным атором и исправителем ошибки IMHO)

...

Рейтинг:

0 / 0

22.12.2008, 23:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729405

Yo.!

Гость

MasterZiv

к стате LAST COMMITTED из феноменов банальный LOST UPDATE добавляет ко всем имеющимся в RC феноменам.

...

Рейтинг:

0 / 0

23.12.2008, 10:18

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729419

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Читаейте внимательно, LC слабее RR и недолжен гарантировать повторяемость.
Откуда вы взяли что он должен ее гарантировать?
вы скзали, что опция LC "в комплексе с другими доступными уровнями изолированности, дает больше свободы разработчикам". полная ерунда - эта опция может быть использована только с IL Read committed и только с ним. больше ни с каким уровнем. да и дает оно не больше свободы, а больше рассогласованости в наборе.

Имелось ввиду возможность изменять уровень изолированности на лету , по ходу транзакции через
set isolation

Одновременно использовать разные уровни внутри одного запроса конечно же нельзя.

Yo.!
onstat-
Вы что только репорты пишете ?
Только это может пояснить почему вы не хотите видеть никакой консистентности кроме оракловой.

признаю, но блокировочные уровни дающие согласованный набор требуют залочить по бол базы и часто не применимы в реальных олтп. в результате приходится проэктировать БД так чтоб можно было получать согласованные данные на уровне RC,

Мы же OLTP обсуждаем, для большенства OLTP задач консистентность на момент fetch гораздо
удобнее чем консистентность на начало запроса.

Потому как:
Yo.!
типа таких как сумма "закрытия рабочего дня" + "проводки текущего дня". мне

Еще раз повторяю:
onstat-
Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

+ Нужно учитывать, что Oracle RC работает( гарантирует консистентность) только в пределах запроса, а не транзакции.
И с подзапросами бывают ситуации, когда каждый подзапрос живет своей отдельной консистентной жизнью, а в сумме это может приводить к логическому нарушению данных.

Yo.!
onstat-
Уровень изоляции так и называется Read Commited, в момент доступа гарантиреутся, что реальное значение не удерживается( изменяется) никакой другой транзакцией.

не правада, ни стандарт ни RC в субд MSSQL такого не требуют/гарантируют. MSSQL на RC может прочесть залоченую эксклюзивно запись взяв значение из индекса (если конкурентная транзакция изменило значение строки на то же значение, что и было до этого)

согласен , что никто этого не гарантирует, но IMHO так было бы логичней.

...

Рейтинг:

0 / 0

23.12.2008, 10:22

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729430

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Zhorakdv...Well, historically there have been two types of RDBMS...
Исторически было только 2 типа: Oracle, который сделал все правильно с саого начала и все остальные (IBM/Sybase=>ANSI), сделавшие это неправильно и десятилетиями отстаивавшие совершенно абсурдый механизм реализации уровней изоляции с помощью блокировок, пока не признали что были неправы (teоретически в 1995 -> Critique of ANSI isolation levels статья, а практически в MSSQL 2005 snapshot isolation).
Почитайте биографию Jim-a Gray (его печальный конец мне кажется связан с
этим, так как он и был осовным атором и исправителем ошибки IMHO)

Я не вижу логики в Ваших словах,
Все было правильно сделано изначально, а затем туда был добавлен неправильный DBMS_LOCK,
Может рассказать зачем испортили правильную систему?

...

Рейтинг:

0 / 0

23.12.2008, 10:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729488

Yo.!

Гость

onstat-
Мы же OLTP обсуждаем, для большенства OLTP задач консистентность на момент fetch гораздо
удобнее чем консистентность на начало запроса.
категорически не согласен. у блокировочника по сути 2 варианта: нафетчить на уровне RC невиданные чудеса или использовать уровень выше RC который удерживает блокировки до конца транзакции и гарантирует смерть OLTP. вот и приходится в реальной жизни жить OLTP с чудесами на RC пытаясь спроэктировать субд так, чтоб нафетченые чудеса хоть как-то уживались с бизнес логикой.

onstat-
Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

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

onstat-
И с подзапросами бывают ситуации, когда каждый подзапрос живет своей отдельной консистентной жизнью, а в сумме это может приводить к логическому нарушению данных.

не правда, максимум что есть у оракла - оптимизация с рестартом пишуших транзакций в случае изменения предикатов, но к подзапросам никакого отношения она не имеет, тем более логику не нарушается ни при каких условиях ни на одном из уровней.

...

Рейтинг:

0 / 0

23.12.2008, 10:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729549

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Мы же OLTP обсуждаем, для большенства OLTP задач консистентность на момент fetch гораздо
удобнее чем консистентность на начало запроса.
категорически не согласен. у блокировочника по сути 2 варианта: нафетчить на уровне RC невиданные чудеса или использовать уровень выше RC который удерживает блокировки до конца транзакции и гарантирует смерть OLTP. вот и приходится в реальной жизни жить OLTP с чудесами на RC пытаясь спроэктировать субд так, чтоб нафетченые чудеса хоть как-то уживались с бизнес логикой.

[/quote]

Вы хотите сказать что нафетчить из undo было бы правильнее?
Да будет быстрее, но логическою целостность я предсказывать боюсь.
А что обчно делают разаработчики oracle что бы не фетчить из undo? :)

Если конкуренция есть то она везде есть хоть это блокировочник, хоть версионник.

Yo.!
onstat-
Ихмо, чем дольше отягивается контроль логической целостности,
тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
А ресурсы сейчас дешевые :)

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

Ваша позиция понятна.

Yo.!
onstat-
И с подзапросами бывают ситуации, когда каждый подзапрос живет своей отдельной консистентной жизнью, а в сумме это может приводить к логическому нарушению данных.

не правда, максимум что есть у оракла - оптимизация с рестартом пишуших транзакций в случае изменения предикатов, но к подзапросам никакого отношения она не имеет, тем более логику не нарушается ни при каких условиях ни на одном из уровней.

Я не силен в рестартах,
К вопросу о ресурсах.
И если кроме упомянутого предиката , есть еще и подзапрос,
то он тоже должен быть перевыполнен с учетом сдвинутой точки консистентности ?

ИМХО лучше ничего не делать на блокировке чем делать работу зря.

...

Рейтинг:

0 / 0

23.12.2008, 11:21

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729600

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED
> потому как выдает более несогласованое чтение, чем RC типичного
> блокировочника.

Где ? Пример давайте.

Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 11:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729618

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> к стате LAST COMMITTED из феноменов банальный LOST UPDATE добавляет ко
> всем имеющимся в RC феноменам.

LOST UPDATE как с READ COMMITED связан, а ?
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 11:38

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35729635

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> Что значит "RC, что сейчас используются в блокировочниках" ?
> Уровни изоляции прописаны в стандарте ANSI.

> RC из стандарта требует лишь того, чтоб запись была закомиченой,
> закомиченое значение можно к примеру и из индекса брать, вместо того

Да. Но я имел в виду не это, а то, что никакого другого
RC не существует. То, что вы пишите "RC, что сейчас используются в
блокировочниках" - его не существует.

> ну в стандарте далеко не все феномены описаны, а ниже LAST COMMITTED

Да, но там описаны уровни изоляции. Если вводите новые -- опишите, как
Грей с товарищами. Тогда будет разговор.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 11:43

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730022

Yo.!

Гость

onstat-
Я не силен в рестартах,
К вопросу о ресурсах.
И если кроме упомянутого предиката , есть еще и подзапрос,
то он тоже должен быть перевыполнен с учетом сдвинутой точки консистентности ?
есть подзапрос, нет подзапроса собственно разницы оракл думаю не сделает, а скорее всего перепишет запрос на анологичный через джоины. при рестарте сдвигается момент старта запроса, относительного нового момента результат полностью согласован будет.

onstat-ИМХО лучше ничего не делать на блокировке чем делать работу зря.
если бы МС не начал ковырять свою версионность, думаю ораклойды до сих пор не догадывались, что существует такая оптимизация. оракл предпочитает оптимистичную стратегию, МС вот предпочитает висеть на блокировке предикатов, будет нужно думаю оракл добавит блокировки предикатов и третий уровень изолированости, но я для себя не нашел бизнес задачу где могут сталкиватся такие транзакции чаще чем раз в год.

2MasterZiv

стандарт RC лишь требует чтоб выданая запись была закомиченой и все, больше стандарт ничего не требует. все известные блокировочники берут на себя повышенные обязательства, хотя в полне действительно могли бы в соответствии со стандартом выдавать значения к примеру из вчерашнего бэкапа. поэтому стандарт и реализация в субд все же отличаются.
почитайте уже упомянутую тут критику уровней, там не менее уважаемые товарищи дали определения недостающих феноменов, я свои выдумывать ленюсь ...
их терминами RC иногда возможен лост апдейт, а RC c last_committed его гарантирует к стате не заслужено забыт skip_committed, опция из той же серии.

...

Рейтинг:

0 / 0

23.12.2008, 13:28

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730092

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Я не силен в рестартах,
К вопросу о ресурсах.
И если кроме упомянутого предиката , есть еще и подзапрос,
то он тоже должен быть перевыполнен с учетом сдвинутой точки консистентности ?
есть подзапрос, нет подзапроса собственно разницы оракл думаю не сделает, а скорее всего перепишет запрос на анологичный через джоины. при рестарте сдвигается момент старта запроса, относительного нового момента результат полностью согласован будет.

Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.

Может кто то из Oracle Гуру прояснит сообществу, что же происходит на самом деле?

Yo.!
onstat-ИМХО лучше ничего не делать на блокировке чем делать работу зря.
если бы МС не начал ковырять свою версионность, думаю ораклойды до сих пор не догадывались, что существует такая оптимизация. оракл предпочитает оптимистичную стратегию, МС вот предпочитает висеть на блокировке предикатов,

Еще раз напоминаю МС обсуждается в других темах.

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

Я немного поковырялся в логике работы oracle и думаю (ИМХО) пока коренным образом
не будет изменена работа с SCN & UNDO добавить новые уровни изолированности не представляется возможным. Основная проблема в том что он всю свою консистентность
счинает на начало запроса.
Другими словами его нужно блокировочником сделать ( считать консистентность по fetch).

...

Рейтинг:

0 / 0

23.12.2008, 13:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730191

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

onstat-меня интересует консистентность записи на момент fetch
Это понятие представляется мне бессмысленным. Оно означает одно из двух: либо неконсистентные результаты запроса (нарушаются взаимоотношения между строками), либо тормозить всех заради искусственной консистентности.

onstat-Полной уверенности у Вас нет, у меня тоже нет. Я все еще думаю, что консистентность разъедестя.
Признаться, не очень понял, о чем вы спорите.

В Оракле результат любого одного запроса (целиком, со всем подзапросами) консистентен на некий момент времени. Собственно, это характерная черта версионного подхода. Неконсистентны могут быть результаты других запросов, если те выполняются в функциях, вызываемых из запроса.

Пример:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.

Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 5 . 0  
Connected as test

SQL> create table consistency (id integer);

Table created

SQL> create sequence consistency_seq;

Sequence created

SQL> insert into consistency select consistency_seq.nextval from dual connect by level <=  5 ;

 5  rows inserted

SQL> create function consistency_cnt return integer as
   2     cnt integer;
   3   begin
   4     select count(*) into cnt from consistency;
   5     return cnt;
   6   end;
   7   /

Function created

SQL> create function consistency_add return integer as
   2     new_id integer;
   3     pragma autonomous_transaction;
   4   begin
   5     select consistency_seq.nextval into new_id from dual;
   6     insert into consistency (id) values (new_id);
   7     commit;
   8     return new_id;
   9   end;
  10   /

Function created

SQL> select
   2     c.id,
   3     (select count(*) from consistency where dbms_random.value >=  0 ) select_cnt,
   4     consistency_cnt func_cnt,
   5     consistency_add new_id
   6   from
   7     consistency c;

                                     ID SELECT_CNT   FUNC_CNT     NEW_ID
--------------------------------------- ---------- ---------- ----------
                                       1            5            5            6 
                                       2            5            6            7 
                                       3            5            7            8 
                                       4            5            8            9 
                                       5            5            9           10 

SQL>

onstat-ИМХО лучше ничего не делать на блокировке чем делать работу зря.
ИМХО критерием истины здесь является практика. А именно - производительность реальных систем.

onstat-Основная проблема в том что он всю свою консистентность счинает на начало запроса.
Основное преимущество.

...

Рейтинг:

0 / 0

23.12.2008, 14:23

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730198

Yo.!

Гость

onstat-
Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.
с консистентностью у меня сомнений нет, я не знаю это оптимизатор одинаоковый план генерит для подзапроса и джоина или сначала переписывает запрос на джоины, а потом уже получает тот же план. а вам следует наконец прочесть хотя бы концепты из оракловой доки, а то ваши представления о явно навеяны постороннем звоном. например проблема консистентности у запроса с подзапросом есть у фаирберд, очень похоже что вы услышали "звон" от туда ...

onstat-
Я немного поковырялся в логике работы oracle и думаю (ИМХО) пока коренным образом
не будет изменена работа с SCN & UNDO добавить новые уровни изолированности не представляется возможным. Основная проблема в том что он всю свою консистентность
счинает на начало запроса.
если вы обнаружили сходство RC+last_committed с версионностью и ищите рассогласованость в подзапросах то позволю себе усомнится, что вы в чем-то версионном копались.

onstat-Другими словами его нужно блокировочником сделать ( считать консистентность по fetch).
нет, не нужно.

...

Рейтинг:

0 / 0

23.12.2008, 14:25

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730399

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> стандарт RC лишь требует чтоб выданая запись была закомиченой и все,
> больше стандарт ничего не требует. все известные блокировочники берут на
> себя повышенные обязательства, хотя в полне действительно могли бы в

Имеют право.

> почитайте уже упомянутую тут критику уровней, там не менее уважаемые
> товарищи дали определения недостающих феноменов, я свои выдумывать
> ленюсь ...

Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?

> их терминами RC иногда возможен лост апдейт, а RC c last_committed его
> гарантирует к стате не заслужено забыт skip_committed, опция из той же
> серии.

Вы так и не привели пример. ТАк что будем считать, что вы ничего не сказали.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 15:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35730409

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

softwarer пишет:

>
> Признаться, не очень понял, о чем вы спорите.

Да собственно ни о чём. Yo тут гонит что-то, а мы пытаемся его
утихомирить.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

23.12.2008, 15:29

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731324

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

onstat-Yo.!onstat-
Я не силен в рестартах,
К вопросу о ресурсах.
И если кроме упомянутого предиката , есть еще и подзапрос,
то он тоже должен быть перевыполнен с учетом сдвинутой точки консистентности ?
есть подзапрос, нет подзапроса собственно разницы оракл думаю не сделает, а скорее всего перепишет запрос на анологичный через джоины. при рестарте сдвигается момент старта запроса, относительного нового момента результат полностью согласован будет.

Полной уверенности у Вас нет, у меня тоже нет.
Я все еще думаю, что консистентность разъедестя.

Может кто то из Oracle Гуру прояснит сообществу, что же происходит на самом деле?

Я не гуру, но попробую ответить:

Если не вдаваяться в подробности реализации, то Оракл гарантирует согласованность данных как минимум для данного запроса. Эта гарантия не зависит от наличия или отсутствия в нем подзапросов. Она так же не зависит от того какой план был выбран оптимизатором для выполнения данного запроса. Read consistency работает на уровень ниже, в "storage engine" выражаясь языком open-source СУБД. Этот уровень и отвечает за всякие table scans и index scans. Упрощенно говоря, в блок пишется когда его крайний раз модифицировали (на самом деле все несколько сложнее и туда еще много чего пишется). Когда выполняется сканирование некого сегмента (т.е. таблицы или индекса) то поблочно проверяется когда данный блок изменялся. Если обнаруживается что блок был изменен после того как был запущен запрос, то Оракл лезет в undo с целью восстановить как же записи в этом блоке выглядели на момент запуска запроса.

В Оракле вы либо получите согласованные данные либо широко известное среди критиков данной СУБД сообщение об ошибке "ORA-1555: Snapshot too old". Ошибка происходит когда при попытке восстановления картины на момент запуска запроса обнаруживается что нужных данных в undo уже нет. Их там может не быть, потому что если транзакция которая изменила блок была прибита commit'ом то старая версия данных лежащая в undo при этом была помечена как свободное место, доступное для записи в него новых данных. На этом месте критики оракла обычно начинают говорить что-то в духе "Оракл аццтой" и "блокировщики форева". Они упускают один немаловажный нюанс. Писать в undo данные поверх того что там лежит оракл будет не сразу а через некоторое время. Этой задержкой по времени управляет DBA через undo retention period. Например в одной из OLTP баз у меня на работе он установлен в 3 часа. Поскольку запросы выполняющиеся по 3 часа в OLTP базах как правило не встречаются, то вероятность получить ошибку вместо данных мизерная.

...

Рейтинг:

0 / 0

24.12.2008, 04:56

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731800

Yo.!

Гость

MasterZiv
Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?
Утопший Джимми, Берштейн и Co, а чо критику не стали читать ? :- D

MasterZiv
Вы так и не привели пример. ТАк что будем считать, что вы ничего не сказали.

Пример: select * from table

...

Рейтинг:

0 / 0

24.12.2008, 11:34

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35731972

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:
> Ну а кто "RC, что сейчас используются в блокировочниках" придумал ?
>
>
> Утопший Джимми, Берштейн и Co,

Да вы, вы придумали, только что в топике. Ну да ладно.

а чо критику не стали читать ? :- D

Да читал, как же ...

> Пример: select * from table

Блин, вы видимо критику-то читали. Ну так вот так, как там сделано,
и надо пример пивести. А ДО этого дать определение нового
уровня изоляции LAST COMMITTED. Тоже так, как там.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

24.12.2008, 12:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35732365

Yo.!

Гость

MasterZiv
Да читал, как же ...

гы-гы, чукча писатель. это ж как нужно прочесть, чтоб не вьехать в основную мысль документика в котором рассказывается об разнице ANSI уровнях и блокировочных.

"We believe the isolation levels called Locking READ UNCOMMITTED, Locking READ COMMITTED , Locking REPEATABLE READ, and Locking SERIALIZABLE are the locking definitions intended by ANSI SQL Isolation levels — but as shown next they are quite different from those of Table 1. "

MasterZiv
А ДО этого дать определение нового
уровня изоляции LAST COMMITTED. Тоже так, как там.

немогу, я собствено и не считаю LAST COMMITTED уровнем изолированности, просто опция (хинт) к грязному чтению (оказывается к нему тоже) и RC. ну а то, что ерунда которую вычитает обычный RC лишь усугубится при отказе дожидаться снятия блокировок мне представляется очевидной. а что-то доказывать если и должен, так ИБМ.

...

Рейтинг:

0 / 0

24.12.2008, 14:11

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35732822

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Yo.! пишет:

> гы-гы, чукча писатель. это ж как нужно прочесть, чтоб не вьехать в
> основную мысль документика в котором рассказывается об разнице ANSI
> уровнях и блокировочных.

А с чего вы взяли, что я "невъехал" ? Наоборот даже.
Вы ссылались на термины оттуда ? Надо было так и сказать (сразу).
По умолчанию есть только ANSI.

> немогу, я собствено и не считаю LAST COMMITTED уровнем изолированности,

Ну тогда что ж говорить-то о его "хуже"/"лучше" ?
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

24.12.2008, 16:09

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35733493

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Yo.!
Утопший Джимми,

Зря вы так о покойнике. Джим Грей был замечательным человеком. Несмотря на его многочисленные заслуги у него не было ни капли зазнайства, ни малейших следов "звездной болезни". Он не любил когда его называли Джеймс, всегда просил "зовите меня просто Джим". Общаться с ним было одно удовольствие.

...

Рейтинг:

0 / 0

24.12.2008, 19:35

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35733519

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Итого, сухой остаток

На сегодня ни одна СУБД не поддерживает уровни изоляции транзакций в полном соответствии со стандартом ANSI. Более того, стандарт ANSI далеко не полностью оговаривает все возможные варианты поведения СУБД применительно к изоляции транзакций. Блокировщики отлконяются от стандарта в одну сторону а версионники - в другую.

С моей точки зрения не принципиально считать ли новую фичу Информикса неким новым "промежуточным" нестандартным уровнем изоляции транзакций или нет. Сути дела это не меняет. Я бы не стал называть это неким новым уровнем чтобы не вносить путаницу в устоявшуюся терминологию. При желании таких уровней изоляции транзакций можно еще напридумывать.

Я оцениваю эти фишки исключительно с точки зрения из практической полезности для разработки информационных систем. На взгляд новая фича Информикса "last committed" это очередной способ чтения определенного класса "грязных" т.е. потенциально проблематичных данных. Несложно найти ряд задач для решения которых она может быть полезной. Точно так же несложно найти ряд задач для которых она не только бесполезна, но даже вредна. Сути дела это не меняет. Информикс как был блокировщиком так и остался, никакие новые механизмы для обеспечения согласованности данных в нем не появились. Как были блокировки, так и остались. По большому счету тут не о чем спорить и нечего обсуждать. Вот когда (и если) Информикс сможет без блокировки обеспечить чтение набора данных согласованного по состоянию на некий момент времени, тогда и будет повод для обсуждения.

То есть Информикс с новой фичей несколько лучше старого но да Оракла ему по прежнему далеко. Существует целый класс задач (см пост Yo! выше) которые ни Информикс ни любая другая СУБД-блокировщик по нормальному решать не умеет. И такое положение вещей не изменится пока не будет переписано ядро СУБД, что в случае конкретно Информикса скорее всего не будет сделано никогда.

...

Рейтинг:

0 / 0

24.12.2008, 20:00

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35733537

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Зл0й пишет:

> На сегодня ни одна СУБД не поддерживает уровни изоляции транзакций в
> полном соответствии со стандартом ANSI. Более того, стандарт ANSI далеко
> не полностью оговаривает все возможные варианты поведения СУБД
> применительно к изоляции транзакций. Блокировщики отлконяются от
> стандарта в одну сторону а версионники - в другую.

Но я хочу подчеркнуть: отклонение в "верхнюю" сторону конкретной реализации
уровня в данной СУБД допустимо по стандарту.
Posted via ActualForum NNTP Server 1.4

...

Рейтинг:

0 / 0

24.12.2008, 20:18

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35737993

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!onstat-
А в чем прелесть версиoнности на OLTP ?

в конкретный примерах, если не затруднит?
прелесть - получение консистентных набора без блокирования половины субд и проблем с дедлогами, вам это уже несколько раз демонстрировалось. ;) за примером идите на TPC-E, там очень красиво видно как в первом тесте МС пыталась запустить без версионности (осталась закоментированая строка), но в итогде длинный читающий запрос был выполнен все же на уровне IL Snapshot. в последних тестах еще один длинный запрос начали выполнять на IL snapshot.

Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.

...

Рейтинг:

0 / 0

26.12.2008, 23:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35738178

Yo.!

Гость

Выбегалло
Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.
в олтп почти наверника все версии будут в кеше, а длинные запросы в том tpc-e не так уж редко вылазят.

...

Рейтинг:

0 / 0

27.12.2008, 13:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35738258

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!Выбегалло
Почему вы думаете, что постоянно тащить все версии данных дешевле, чем подождать освобождения блокировки ? "Длинные читающие запросы" в OLTP системах случаются once in a while, а ресурсов ваша версионность жрет от души.
в олтп почти наверника все версии будут в кеше,

Если пытаться анализировать технические причины сабжа ( почему Informix displaces Oracle at China Telcom )
Есть 2 варианта работы системы.
1. Очень много горячих блоков в кеше.
По этому пунткту informix имеет 2 очень важных перймущества
а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.
Все что выделяет ОС она выделяет ядру Informix, а оно само решает какую пользовательскую сессию в этом контексте выполнения крутить.
Насколько я знаю , проблема горячих блоков в Oracle решается через параметр _spin_count то есть простым опросом мутексов сессиями. Если Вы знаете другие возможности Oracle по борьбе с ожиданиями на горячих блоках в буферном кеше приведите ссылки. ( Про реверсивные индексы я знаю).

б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

2. Изменений много, но они равномерно распределены между блоками таблиц.
В этом случае Ваше наверняка абсолютно не очевидно.

Yo.!
а длинные запросы в том tpc-e не так уж редко вылазят.

Давайте поделим систему 2 части, регистрационная часть, это та которая выполняет всю OLTP
работу, и отчетная часть в которой как раз и могут вылазить длинные запросы.

С точки зрения регистрационной части, консистентность на какой то момент в прошлом
( будь то даже начало текущего запроса), не имеет никаких преймушеств, так как
необходимо оперировать с реальными значениями на момент их изменения.
Поэтому програмисты Oracle используют явное блокирование записей
через select for update или DBMS_LOCK , версионные механизмы здесь не работают.

Что касается отчетной части, соглаcен, что версионные механизмы Oracle удобнее.

При выборе СУБД оценивается соотношение регистрационной и отчетных
операций в системе, какие из них важнее, и чем дешевле пожертвовать.

Думаю и надеюсь , что китайцы сделали свой выбор на базе всесторонней оценки возможностей
сабжевых СУБД, а не откатов и прочей политической лабуды.

...

Рейтинг:

0 / 0

27.12.2008, 16:07

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35738308

Yo.!

Гость

onstat-
а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.

чтоб объявить это преимуществом, нужно хоть какое-то обоснование. мне история с этим вопросом представляется так: оракл столкнувшись с проблемой производительности переключения контекста процессов в винде принял решение на этой платформе использовать тхредовую модель, но при этом не переводить на тхреды отсальные платформы (по понятным причинам). информикс столкнувшись с той же проблемой решил вообще продублировать функции ОС, я к примеру не уверен, что ему удалось это лучше, чем это делает ОСь на своей родной платформе. тем более, что шедулеры в том же линуксе сейчас очень динамично развивающаяся часть ядра, есть ли смысл не использовать те грамадные ресурсы, что сейчас в эти иследования вбухиваются.
onstat-
б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

это древняя фича в оракле, к стате, а в информиксе можно назначить буфер с отличным от других размером блоков ?

onstat-
В этом случае Ваше наверняка абсолютно не очевидно.

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

onstat-
С точки зрения регистрационной части, консистентность на какой то момент в прошлом
( будь то даже начало текущего запроса), не имеет никаких преймушеств, так как
необходимо оперировать с реальными значениями на момент их изменения.

не факт, мне кажется в полне логичным отказать в доступе т.к. на момент запроса на счету не было достаточно средств. версионник проиграет только в случае совершенной необходимости пессимистичной блокировки т.к. не имеет всего того зоопарка блокировок который есть у типичного блокировочника ... хотя озвученая доля 90% в телекомах Китая и явно больше 50% в России наверно наверно говорит о том, что оптимистичная блокировка в задачах телекома привалирует (на наших широтах).

...

Рейтинг:

0 / 0

27.12.2008, 18:29

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35738495

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

Tons of Fun @ informix

...

Рейтинг:

0 / 0

28.12.2008, 03:20

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35738605

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

Yo
к стате, а в информиксе можно назначить буфер с отличным от других размером блоков ?

Да:
[quote IDS ]

IBM Informix Dynamic Server, Version 11.50
--------------------------------------------------------------------------------

BUFFERPOOL
onconfig.std values
Operating systems with 2K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=2k,buffers=50000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60
Operating systems with 4K default page size:
BUFFERPOOL default,buffers=10000,lrus=8,lru_min_dirty=50.00,
lru_max_dirty=60.50
BUFFERPOOL size=4k,buffers=10000,lrus=8,lru_min_dirty=50,
lru_max_dirty=60

[/quote]

...

Рейтинг:

0 / 0

28.12.2008, 13:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35739422

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
а. Ядро СУБД контролирует контексты выполнения пользовательских сессий, то есть пользовательской сессии не будет выделен процессор, если сессия не может получить доступ к ресурсу ( он защищен мутексом) по причине особенностей внутренней многозадочности ядра.

чтоб объявить это преимуществом, нужно хоть какое-то обоснование. мне история с этим вопросом представляется так: оракл столкнувшись с проблемой производительности переключения контекста процессов в винде принял решение на этой платформе использовать тхредовую модель,
но при этом не переводить на тхреды отсальные платформы (по понятным причинам).

Я не знаю, по каким ?

Yo.!
информикс столкнувшись с той же проблемой решил вообще продублировать функции ОС, я к примеру не уверен, что ему удалось это лучше, чем это делает ОСь на своей родной платформе. тем более, что шедулеры в том же линуксе сейчас очень динамично развивающаяся часть ядра, есть ли смысл не использовать те грамадные ресурсы, что сейчас в эти иследования вбухиваются.

Этот API Informix написал еще в 1993 году.

Понять теоретическое обоснование, почему именно так поступили разработчики можно отсюда

http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

Нет разницы нитевая это модель или процессная, суть проблемы заключается в том что ОС
при переключении контекстов не всегда в состоянии точно предсказать, что будет делаться в
контексте выполнения.
Сейчас мяч у матемтиков, пока они что то не придумают кардинально ничего не поменяется.

Yo.!
onstat-
б. Informix имеет возможность( через параметр) поделить буферный кеш на несколько независимых LRU.

это древняя фича в оракле, к стате,

Ссылочку приведите пожалуйста, как я могу поделить конкретный буфферный пулл на несколько LRU
И как этим управлять?

Yo.!
а в информиксе можно назначить буфер с отличным от других размером блоков ?

Уже ответили.

Yo.!
onstat-
С точки зрения регистрационной части, консистентность на какой то момент в прошлом
( будь то даже начало текущего запроса), не имеет никаких преймушеств, так как
необходимо оперировать с реальными значениями на момент их изменения.

не факт, мне кажется в полне логичным отказать в доступе т.к. на момент запроса на счету не было достаточно средств.

На счете уже небыло, а в undo на момент начала запроса было значение
которого хватало, ИМХО без пессиместичной блокировки тут не обойтись.

...

Рейтинг:

0 / 0

29.12.2008, 11:59

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35739785

Yo.!

Гость

onstat-

юнихов с тхредами по прежнему не все гладко, в линуксе так просто сыро. в винде с точностью до наоборот, потому и пришлось обоим в 1993 выкатывать тхредовые версии. в плане шедулеров математики тут не причем, мячь сейчас у линуксойдов, которые сию секунду обкатывают на линуксовом ядре кажется три стратегии шедулеров.
по буферным кешам в оракле есть три дефолтных пула, один стандартный, на другой ЛРУ не распростроняется и используется, чтоб напрочь закешировать объект, третий ровно наоборот, предотвратить кеширование. кроме этого можно насоздавать свои пулы и задать объектам (таблицы, индексы, партиции) имя дефалтного пула через опцию BUFFER_POOL, эта фича была уже в семерке.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14249/adlob_design.htm
с информиксом прочел доку и ничего не понял. "Operating systems with 2K default page size" - что такое дефаулт применительно к ОС ? речь о файловой системе или где ? и как то не понял, если нужно отлично от дефаулта, то что ? к стате в догонку, можно ли в информикесе в одной базе часть таблиц иметь с 8К страницей, другую с 16К ?

по поводу писсемистичной блокировки - ну если совсем необходимо оно есть в оракле в виде for update и dbms_lock. но судя по популярности оракла в телекомах они больше оптимистичную применяют.

...

Рейтинг:

0 / 0

29.12.2008, 14:03

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35739964

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!
onstat-

с информиксом прочел доку и ничего не понял. "Operating systems with 2K default page size" - что такое дефаулт применительно к ОС ? речь о файловой системе или где ? и как то не понял, если нужно отлично от дефаулта, то что ? к стате в догонку,

Informix page это почти тоже самое что в Oracle block.

автор
The basic unit of database server I/O is a page. Page size might vary among computers.

Yo.!
можно ли в информикесе в одной базе часть таблиц иметь с 8К страницей, другую с 16К ?

конечно, создаете дбпространство
http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.adref.doc/adref426.htm

Потом создаете таблицу в этом дбпространстве
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls301.htm

Yo.!
по поводу писсемистичной блокировки - ну если совсем необходимо оно есть в оракле в виде for update и dbms_lock. но судя по популярности оракла в телекомах они больше оптимистичную применяют.

Вовсе не факт, они применяют, то что не нарушает логической целостности данных.

...

Рейтинг:

0 / 0

29.12.2008, 15:14

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35740240

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-

юнихов с тхредами по прежнему не все гладко, в линуксе так просто сыро. в винде с точностью до наоборот, потому и пришлось обоим в 1993 выкатывать тхредовые версии. в плане шедулеров математики тут не причем, мячь сейчас у линуксойдов, которые сию секунду обкатывают на линуксовом ядре кажется три стратегии шедулеров.

Скажите , Вы может гарантировать что в СУБД, не важно какой, за одним мутексом( семафором ОС)
не прячется несколько обьектов защищенных латчами( мутексами, и прочими мехнизмами сериализации доступа пользовательских сессий СУБД)?

Если прячутся то ядро не сможет дать никакой гарантии, что незапустит контекст, который тут же
отдаст управление обратно ядру потому как делать ему абсолютно нечего.
Или не снимет контекст с выполнения недождавшись пока сессия не освободит внутрениий латч СУБД.
Если на каждый объект который нужно защищать в СУБД взводить мутекс или семафор ОС,
то никаких семафоров на это не хватит.
Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).

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

...

Рейтинг:

0 / 0

29.12.2008, 17:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35740701

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

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

Yo.!
MasterZiv
Вы так и не привели пример. ТАк что будем считать, что вы ничего не сказали.

Пример: select * from table
можно еще select * from calls или select * from cdr и идти пить чай с бубликами ;) (все же пройдет и будет результ)

Зл0й Например в одной из OLTP баз у меня на работе он установлен в 3 часа. Поскольку запросы выполняющиеся по 3 часа в OLTP базах как правило не встречаются, то вероятность получить ошибку вместо данных мизерная.
Попросите Yo.! выполнить парочку десятков вышеприведенных запросов на Вашей базе ;)

А вообще рад что Oracle обладает такими замечательними способностями как версионность...и делает на этом акцент.
Особенно видя, как народ форматирует какой-то SQLище на десять тысяч строк в Toadе и при этом утверждая что он (SQL) аж не делает deadlockов! Так ведь и не делает! Работает!

Так что работы хватит для всех в ближайщем будущем

Yo.!
хотя озвученая доля 90% в телекомах Китая и явно больше 50% в России наверно наверно говорит о том, что оптимистичная блокировка в задачах телекома привалирует (на наших широтах).
Тут надо отдать должное Oracle в том что они сделали доступность своих продуктов без всяких там триалов и т.д.

---

В телекомах, особенно сейчас, когда маржа все падает, а кол-во транзакций (звонков) выросло-и-растет с каждым днем, все чаще-и-чаще присматриваются к альтернативам...

...

Рейтинг:

0 / 0

29.12.2008, 23:15

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35740716

SergSuper

Участник

Откуда: SPb

Сообщения: 5 995

Рейтинг: 0 / 0

herr, учитесь писать менее эмоционально и более информативно

...

Рейтинг:

0 / 0

29.12.2008, 23:43

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35740722

Yo.!

Гость

onstat-
Скажите , Вы может гарантировать что в СУБД, не важно какой, за одним мутексом( семафором ОС)
не прячется несколько обьектов защищенных латчами( мутексами, и прочими мехнизмами сериализации доступа пользовательских сессий СУБД)?

честно - не знаю, а вы знаете ? наверно в каких-то шедулерах можно, в других наверное нельзя. но если можно у меня ломается мозг, что это может дать ? информикс проводит какую-то оптимизацию основаную на знании о кол-ве латчей ? можно чуть развернутей, что там за оптимизация ?

И вообще, как информикс работает. из курса по осям смутно помню, что процесс это понятие на уровне процессора, соответсвенно при переключении просессов CPU производит аппаратно огромную работу в том числе востанавливая значения регистров, если для ОСи информикс один процесс (наверно однин на процессор) значит никто информиксу аппаратно не вычисляет адреса, не востанавливает значения регистров ...

...

Рейтинг:

0 / 0

29.12.2008, 23:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35740995

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat-
Скажите , Вы может гарантировать что в СУБД, не важно какой, за одним мутексом( семафором ОС)
не прячется несколько обьектов защищенных латчами( мутексами, и прочими мехнизмами сериализации доступа пользовательских сессий СУБД)?

честно - не знаю, а вы знаете ? наверно в каких-то шедулерах можно, в других наверное нельзя. но если можно у меня ломается мозг, что это может дать ?

Это может дать представление, что ОС не с состоянии
знать ( угадать ) когда процесс ( нить) пользовательской сессии заснет на латче, и вообще нужно ли ее будить в настоящий момент, хотя ее время( по шадулеру) уже наступило,
в соответсвии с
http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

Yo.!
информикс проводит какую-то оптимизацию основаную на знании о кол-ве латчей ? можно чуть развернутей, что там за оптимизация ?

Так Вам это уже рассказывали

/topic/271249&pg=4&hl=%e2%e5%f0%f1%e8%ee%ed%ed%ee%f1%f2%fc#2649266

...

Рейтинг:

0 / 0

30.12.2008, 10:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35741103

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

Yo!на другой ЛРУ не распростроняется и используется, чтоб напрочь закешировать объект
Это неверно. Все там распространяется, и все там вытесняется по LRU, просто детали этого механизма несколько отличаются.

...

Рейтинг:

0 / 0

30.12.2008, 11:15

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35741156

Yo.!

Гость

onstat-
Это может дать представление, что ОС не с состоянии
знать ( угадать ) когда процесс ( нить) пользовательской сессии заснет на латче,
url с подробностями наконец можно увидеть ? ну ждет к примеру сессия25 латча на блок38 в кеше и что это знание дает ? перед переключением на сессию25 проверять латч - глупо, будем войную работу часто и густо делать.

onstat-
и вообще нужно ли ее будить в настоящий момент, хотя ее время( по шадулеру) уже наступило,
в соответсвии с
http://en.wikipedia.org/wiki/Branch_predication
http://en.wikipedia.org/wiki/Branch_prediction
http://en.wikipedia.org/wiki/Branch_misprediction

мне не понятно какое отношение это имеет к информикс ? мне не понятно откуда могут возникнуть ветви в ожиданиях. и совершенно не понятно почему вы выбрали латчи, а не блокировки, почему не погадать по блокировках, их больше
короче очень хочется документик от ИБМ рассказывающий о своем шедулере, прирно такой какие есть по шедулерам современных осей.

Yo.!
/topic/271249&pg=4&hl=%e2%e5%f0%f1%e8%ee%ed%ed%ee%f1%f2%fc#2649266
не вижу описания оптимизации. там описана софтварная эмуляция базовых возможностей процессора. ядро субд состоит из множества подсистем очень далеких друг от друга. движек SQL как ни крути будет иметь переключение контекста на исполнение интерпритатора PL/SQL и я не вижу преимуществ в софтварной эмуляции такого переключения.

2Apex
ОК, там я сильно не вникал.

...

Рейтинг:

0 / 0

30.12.2008, 11:42

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743357

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!
мне не понятно какое отношение это имеет к информикс ? мне не понятно откуда могут возникнуть ветви в ожиданиях. и совершенно не понятно почему вы выбрали латчи, а не блокировки, почему не погадать по блокировках, их больше
короче очень хочется документик от ИБМ рассказывающий о своем шедулере, прирно такой какие есть по шедулерам современных осей.

Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.

...

Рейтинг:

0 / 0

02.01.2009, 20:11

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743510

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

С версионностью разобрались, закономерным образом не нашли у СУБД-блокировщиков (на примере Информикса) никаких существенных преимуществ. Теперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной. Оракловый инстанс на юниксе, если его рассматривать "с высоты птичьего полета" представляет собой немеряных размеров кусок shared memory к которому прицеплена дюжина системных процессов самой СУБД. А в информиксе - один большой и толстый процесс у которого внутри куча нитей (трэдов, потоков). Синхронизация доступа к памяти в обоих случаях осуществляется "ручками" потому как память в обоих случаях разделяемая. Более того, Оракл в виндовой версии тоже представляет собой один большой процесс с кучей трэдов внутри. Сделано это потому что винды в отличие от Юникса и особенно Линукса не умеют переключать процессы с приемлемой производительностью. В Оракле написан API который позволяет в значительной степени абстрагироваться от нюансов реализации ОС.

Вообще, раз зашла речь про такие вещи как latch contention, то при грамотно спроектированном приложении в них обычно упираются при попытках выжать последние 2% производительности из системы из которой 98% уже выжато. Причина очевидна - все те явления которые происходят в оперативной памяти случаются примерно на 1-2 порядка быстрее чем те которые затрагивают подсистему ввода-вывода.

Я предполагаю что в причина по которой в China Telecom поменяли одну СУБД на другую не имеет ровным счетом никакого отношения к производительности самой СУБД. Была некая команда криворуких разработчиков, сделавших систему которая работала через пень-колоду. Хреново работало не потому что СУБД "кривая" а от неумения проектировать и разрабатывать, то есть от банальной кривизны рук. Систему-то можно даже и на IMS с коболом и CICS сделать, если уметь. Это правда это будет гораздо дороже чем реляционная СУБД, но работать будет. Когда криворуких выгнали взашей, то на смену им пришла другая команда с другим инструментом (Информикс). Могла бы прийти команда с DB2 в качестве инструмента, ничего бы не поменялось.

Я видел немало проектов по переходу с одной СУБД на другую, как правило кривизна рук разработичков списывается на кривизну СУБД. Ищется некая магическая серебряная пуля в виде другой СУБД. И не находится.

...

Рейтинг:

0 / 0

03.01.2009, 01:41

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743521

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

У информиха и по сей день много толстых телекомуникационных клиентов, типа AT&T, Verizon, Sprint Nextel. Так чта выбор CT не удивителен. Также можно вспомнить Walmart, Mastercard, и Home Depot. Видимо, где требуется процессинг огромного количества OLTP там требуется информикс. А там, где это не требуется (во множестве случае, ИМХО), можно обойтись и "другими системами" :)

...

Рейтинг:

0 / 0

03.01.2009, 02:37

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743587

Ggg_old

Участник

Откуда: Одесса

Сообщения: 1 474

Рейтинг: 0 / 0

Интересно, почему IBM им продал informix а не свой любимый DB2. Думаю, что о тредах, латчах и блокировках китайцы думали меньше всего, вернее те кто принимал решение руководствовались другими критериями - ценой вопроса в деньгах и времени. Скорее всего оракл проявил жадность невиданных даже для китайцев масштабов и пролетел.
А блокировки, изоляции, латчи - это всё грустный удел гиков.

...

Рейтинг:

0 / 0

03.01.2009, 12:45

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743776

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

Ggg_oldСкорее всего оракл проявил жадность невиданных даже для китайцев масштабов и пролетел.
А блокировки, изоляции, латчи - это всё грустный удел гиков.Почему? Оракел у них и так уже был куплен... Сами подумайте - зачем им покупать лицензии информикса при оплаченных оракловых?

...

Рейтинг:

0 / 0

03.01.2009, 17:31

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743783

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

Ggg_oldте кто принимал решение руководствовались другими критериями - ценой вопроса в деньгах и времени.Руководство не принимает решения, а выбирает из того, что ему предложат :)

...

Рейтинг:

0 / 0

03.01.2009, 17:40

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35743811

Ggg_old

Участник

Откуда: Одесса

Сообщения: 1 474

Рейтинг: 0 / 0

Значит предложение оракла оказалось неконкурентноспособным. Все просто.
Нам остается только гадать о подробностях их тендера. Но мораль сей басни такова, что последний информикс выиграл очень большой тендер в неравных стартовых условиях.

...

Рейтинг:

0 / 0

03.01.2009, 18:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745100

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Зл0йС версионностью разобрались, закономерным образом не нашли у СУБД-блокировщиков (на примере Информикса) никаких существенных преимуществ.

Если бы одна из архитектур обладала существенными преимуществами, то вторая бы не выжила.

Зл0йТеперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной.

А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2

...

Рейтинг:

0 / 0

05.01.2009, 20:10

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745134

Yo.!

Гость

Выбегалло
Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.
а есть нормальный документ описывающий, что там есть и чего нет ? а то onstat- нам рассказывал ровно противоположное.

ВыбегаллоА вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи. а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).

...

Рейтинг:

0 / 0

05.01.2009, 20:58

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745306

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Выбегалло

Зл0йТеперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной.

А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами.

На порядок только в MS Windows. В Линуксе на x86 и x86-64 примерно в полтора-два раза. Зависит от реализации ОС.

Выбегалло
Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU.

Зато ОС (например Юникс) о том что происходит у процесса внутрях не ведает ни сном ни духом, и выделяет ему ресурсов исходя из неких заложенных в нее создателями предположений. Так что один здоровенный тяжеленный процесс с кучей тредов внутри не обязательно работает лучше. Чисто умозрительно можно придумать сценарий при котором произойдет некий "затык" по производительности из-за процессов а не трэдов. Можно придумать и сценарий при котором произойдет "затык" по производительности из-за того что ОС не даст ресурсов большому-толстому процессу. Как показывает практика, если руки не кривые то такой "затык" в природе не встречается, потому что в СУБД есть миллион других мест где таковой "затык" происходит по совершенно другим не зависящим от архитектуры сервера причинам.

Выбегалло
Недаром IBM решила перейти на нитевую архитектуру в DB2

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.

Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.

...

Рейтинг:

0 / 0

06.01.2009, 01:44

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745313

info-win-3-1

Гость

То, что "придумал" информикс - называется "Cooperative Mutitasking". Штука известная по временам Windows 3.1, появившаяся, кстате, на два года раньше Informix 6 с переписанным ядром под использование нитей. Тогда это было модно. Я сам помню по институту )))

Cooperative multitasking/time-sharingWhen computer usage evolved from batch mode to interactive mode, multiprogramming was no longer a suitable approach. Each user wanted to see his program running as if it was the only program in the computer. The use of time sharing made this possible, with the qualification that the computer would not seem as fast to any one user as it really would be if it were running only that user's program.

Early multitasking systems consisted of suites of related applications that voluntarily ceded time to each other. This approach, which was eventually supported by many computer operating systems, is today known as cooperative multitasking. Although it is rarely used in larger systems, Microsoft Windows prior to Windows 95 and Windows NT, and Mac OS prior to Mac OS X both used cooperative multitasking to enable the running of multiple applications simultaneously. Windows 9x also used cooperative multitasking, but only for 16-bit legacy applications, much the same way as pre-Leopard PowerPC versions of Mac OS X used it for Classic applications. Cooperative multitasking is still used today on RISC OS systems.

Because a cooperatively multitasked system relies on each process to regularly give time to other processes on the system, one poorly designed program can cause the whole system to hang.

...

Рейтинг:

0 / 0

06.01.2009, 01:58

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745507

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!Выбегалло
Нет там никакого scheduler-а в понимании ОС. Потому что невытесняемая многозадачность. Каждая нить сама ставит себя в очередь к латчу и передает управление планировщику, который пробегает очередя, проверяет какие нити перешли в состояние готовности и переставляет их в очередь на выполнение, и запускает первую нить из очереди.
а есть нормальный документ описывающий, что там есть и чего нет ?

http://docs.rinet.ru/InforSmes/ch07/ch07.htm#Heading7
автор

The VP holds the same responsibilities that the UNIX operating system has, managing time slices and the priority levels of the jobs allowed to run on the CPU. The VP manages the priority and scheduling of the threads connected to it. VPs are also responsible for switching threads when needed. Figure 7.6 shows a VP switching the context of two threads.

Figure 7.6.
Context switching performed on two threads by a virtual processor.

Threads are not restricted to work under a specific time slice as CPU processes are. A thread continues processing in the VP until it completes its task or until it must wait for something else to occur before it can continue. These waits are built into the thread's instructions, usually to take care of reads or writes or to free up locks. The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

Three types of queues hold the threads not running for each VP class. The ready queue is where all threads that are ready to run reside; that is, they have all the data needed to perform their task. The sleep queue is where threads that have no work to perform reside until there is work for them to do. The wait queue is where threads are placed when they need something else to complete before they can continue. Threads in sleep and wait queues are placed in the ready queue when they are needed to run again.

When there is more than one VP of the same class running, there is still only one set of queues. A thread waiting in the class queue is run on the first VP available. This provides a balance in the workload of each VP and provides faster work throughput of ready threads.

Multiprocessor systems also provide the capability to perform some tasks in parallel. Usually a client process has one session thread associated with it at one time. Tasks that require index building, sorting, sequential scanning, and joining can have more than one session thread. Figure 7.7 shows a client process with more than one session thread attached to various VPs. An example is when a client process reads through table data sequentially. If this table is fragmented over different disk partitions, a thread to read each partition's data can run at the same time. After all the partition reads are complete, the data is placed together by one thread and returned to the client. This process is also known as fan-out, where the single starting point of the fan is at the client. The fan becomes wider as multiple threads are created and connect to multiple VPs. Each of these VPs then connects to multiple CPUs.

Yo.!
а то onstat- нам рассказывал ровно противоположное.

Не надо придумывать.

Yo.!
ВыбегаллоА вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
как мы выяснили в информиксе нет нитей, есть их эмуляция в рамках процесса, не факт что эта эмуляция быстрей апаратного переключения целого процесса ОСи.

Суть вопроса не сколько в скорости переключения в сумме времени потраченной на все переключения. (см. выделенный фрагмент цитаты)
Нет смысла выделять некоторому коду CPU, если через несколько тактов снова нужно будет делать переключение. Ссылки для понимание этого вопроса я уже здесь приводил.

Yo.!
а дб2 могла перейти на процессы например из бедности - не возможность поддерживать две ветки db2 luw (нитевую для виндовс и поцессорную для Unix/Linux).

Это ваши фантазии, ссылки на документы давайте.

...

Рейтинг:

0 / 0

06.01.2009, 12:03

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745541

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Зл0й

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.

в качестве изучения истории, кто это был ?
ссылки можно ?

Зл0й
Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.

ИМХО если бы все было написано по одной спецификации, то IBM не составило бы труда
взять из Informix все лучшее и перенести в DB2 как изначально планировалось,
но этого не произошло.
Развитие было притормозилось( с 2000 до 2004) , но потом ( после 2005 года) продукт
(технология Informix DSA ) продолжала не просто жить,
а и интенсивно развиваться. Настоящий топик тому доказательство.

...

Рейтинг:

0 / 0

06.01.2009, 12:32

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745614

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!
а есть нормальный документ описывающий, что там есть и чего нет ?

вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex

...

Рейтинг:

0 / 0

06.01.2009, 13:17

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745673

Yo.!

Гость

onstat- The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

ну это рекламный слоган, типа шелковистых волос, никакой информации не несет :(
onstat-
вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex
это уже лучше, но скуповато, описания каких-либо оптимизаций не нашел. зато нашел:
onstat-
Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).

One of the more common ways to use a semaphore is to put a process to sleep on the semaphore waiting for a particular event to wake it up. Informix uses semaphores in this way for a VP process that does not have any further work to do.

почему вы думаете что взвыедение семофоров ОС для оракла дороже чем та же операция в информикс ?

ну и дальше:
This spinning is a tight loop in the code that does nothing. Every so many loops it would try for the latch again. This is more CPU intensive, but requires less operating system overhead than swapping the process in and out as it goes to sleep on the semaphore.

ничего не напоминает ? ну и чем это лучше ораклового _spin_count ? к стате сразу вопрос - как завется аналог _spin_count в IDS ?

...

Рейтинг:

0 / 0

06.01.2009, 13:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745754

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!onstat- The VP sometimes learns from the running thread which thread should run next. This learning occurs when the thread realizes that it needs more information; it allows itself to be switched out so that another thread can be started to satisfy the need of the original thread.

ну это рекламный слоган, типа шелковистых волос, никакой информации не несет :(

Какая вам еще нужна информация?
Поставьте Informix и поробуйте, почитайте матчасть и многие вопросы сами собой отпадут.

Yo.!
onstat-
вот еще одни документ который может пролить свет как все происходит ( при желании понять)

http://www.informix-zone.com/idswiki/doku.php/idsdev:misc:mutex
это уже лучше, но скуповато, описания каких-либо оптимизаций не нашел. зато нашел:
onstat-
Также системный вызов по взведению мутексов и семафоров
в ОС тоже операция не дешевая требует преключения контекста( выполнения кода на уровень ядра).

One of the more common ways to use a semaphore is to put a process to sleep on the semaphore waiting for a particular event to wake it up. Informix uses semaphores in this way for a VP process that does not have any further work to do.

почему вы думаете что взвыедение семофоров ОС для оракла дороже чем та же операция в информикс ?

Потому что количество CPU VP равно или меньше количеству физических процессоров или ядер
( так рекомендует performance guid).
при этом эти CPU VP обрабатывают десятки, сотни или тысячи пользовательских сессий.

В Oracle didicated процесс(нить) обслуживает только одну сессию, а их ( dedicated) также
десятки , сотни или тысячи, для соизмеримых систем.
Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.
Хотите доказать обратное, приведите ссылку как Oracle синхронизирует доступ к разделяемым ресурсам dedicated процессов без использования системных вызовов.

Yo.!

ну и дальше:
This spinning is a tight loop in the code that does nothing. Every so many loops it would try for the latch again. This is more CPU intensive, but requires less operating system overhead than swapping the process in and out as it goes to sleep on the semaphore.

ничего не напоминает ? ну и чем это лучше ораклового _spin_count ? к стате сразу вопрос - как завется аналог _spin_count в IDS ?

Такие ситуации бывают редко, но бывают.
Вы их на практике видели?

Вот ответ на ваш вопрос:
автор The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.

Вы _spin_count, вы ведернули из контекста, при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.
Увеличивайте количество LRU, тем самым уменьшите спины.
Если есть не нагруженные CPUVP - остановите их это тоже уменьшает спины.

...

Рейтинг:

0 / 0

06.01.2009, 14:50

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35745888

Yo.!

Гость

я хочу увидеть документ описывающий оптимизацию, чтоб убедится что она существует, а не вы как с scip_commited что-то напутали.
onstat-
Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.

прикидываю - разница на порядок, т.к. информикс вынужден софтварно эмулировать базовые вещи процессора, оракловый процесс же хардварно примерно на порядок быстрей переключит контекст.

автор The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.
тут или у меня плохо с англицким или криво построена фраза. единствено, что понял, так что это обязаность тхреда запустить следующего из очереди, сразу возникает вопрос, а если там бесконечный луп, кто будет переключать ? то же самое, что такое "ресурс", юлозить по десяткам МБ структуры локов при каждом преключении тоже сомнительная оптимизация. ну и конечно не понятно зачем тогда лупить в попытках получить латч. короче вопросов стало только больше.

onstat-Вы _spin_count, вы ведернули из контекста, при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.
уже вроде отвечал, повторяю:
авторConsidering Multiple Buffer Pools

A single default buffer pool is generally adequate for most systems. However, users with detailed knowledge of an application's buffer pool might benefit from configuring multiple buffer pools.

With segments that have atypical access patterns, store blocks from those segments in two different buffer pools: the KEEP pool and the RECYCLE pool. A segment's access pattern may be atypical if it is constantly accessed (that is, hot) or infrequently accessed (for example, a large segment accessed by a batch job only once a day).

Multiple buffer pools let you address these differences. You can use a KEEP buffer pool to maintain frequently accessed segments in the buffer cache, and a RECYCLE buffer pool to prevent objects from consuming unnecessary space in the cache. When an object is associated with a cache, all blocks from that object are placed in that cache. Oracle maintains a DEFAULT buffer pool for objects that have not been assigned to a specific buffer pool. The default buffer pool is of size DB_CACHE_SIZE. Each buffer pool uses the same LRU replacement policy (for example, if the KEEP pool is not large enough to store all of the segments allocated to it, then the oldest blocks age out of the cache).

By allocating objects to appropriate buffer pools, you can:

* Reduce or eliminate I/Os
* Isolate or limit an object to a separate cache

http://download.oracle.com/docs/cd/B10500_01/server.920/a96533/memory.htm#30936

...

Рейтинг:

0 / 0

06.01.2009, 16:25

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746164

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

onstat-Зл0й

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.

в качестве изучения истории, кто это был ?
ссылки можно ?

Сайбэйс. Впопыхах была выпущена новая версия которая при определенном стечении обстоятельств невосстановимо теряла данные - это был очень злобный баг. С этого начался закат Сайбэйса. Версию за давностью лет не помню, спросите Сайбэйсных DBA кто работал с этим продуктом году этак в 93-95 они вам расскажут.

onstat-
Зл0й
Оно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.

ИМХО если бы все было написано по одной спецификации, то IBM не составило бы труда
взять из Informix все лучшее и перенести в DB2 как изначально планировалось,
но этого не произошло.
Развитие было притормозилось( с 2000 до 2004) , но потом ( после 2005 года) продукт
(технология Informix DSA ) продолжала не просто жить,
а и интенсивно развиваться. Настоящий топик тому доказательство.

Просто один талантливый дядька который проходил производственную практику на IBM и писал там спецификацию для DB2 по окончании своей учебы пошел работать в Информикс, который тогда только создавался. С той поры довольно много воды утекло, Информикс купил стоунбрэйкеровскую Иллюстру пытался толкать объектно-реляционную лажу, купил красный кирпич и пытался лезть в хранилища данных. Оба продукта слегка разошлись, но сходство все равно порой просто поразительное. Информикс на порядок ближе к DB2 чем любые 2 других коммерческих СУБД от разных производителей (кроме старого сайбэйса и MS SQL server версии примерно 6).

...

Рейтинг:

0 / 0

06.01.2009, 20:28

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746167

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

onstat-
Суть вопроса не сколько в скорости переключения в сумме времени потраченной на все переключения.

В Оракле при грамотно написаном приложении эта сумма времени часто составляет менее 0.1% от времени выполнения запроса. Поэтому любая оптимизация в данной области неоправдана. "premature optimization is the root of all evil." (C) Дональд Кнут

...

Рейтинг:

0 / 0

06.01.2009, 20:33

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746259

Yo.!

Гость

Зл0й
Просто один талантливый дядька который проходил производственную практику на IBM и писал там спецификацию для DB2 по окончании своей учебы пошел работать в Информикс
а о которой db2 идет речь ? майнфреймовская db2 что-ли ? вроде на момент старта информикса у ibm ни каких намеков на unix, os/2 и даже as/400 не было ...

...

Рейтинг:

0 / 0

06.01.2009, 22:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746279

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

06.01.2009, 23:37

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746291

Yo.!

Гость

Выбегалло
Кто конкретно выяснил что в информиксе нет нитей ?
И как вы, собственно, понимаете разницу между нитью и процессом в юниксах?
понимаю, я не понимаю какое отношение имеют к "Информикс использует свою собственную библиотеку user threads".
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.admin.doc/admin237.htm
то что там нарисовано на картинке, на уровне ОС такое переключение процесса/нити процессор делает хардварно, как я понимаю библиотека информикс должна эмулировать такое переключение софтварно, т.к. с точки зрения процессора один процесс.

...

Рейтинг:

0 / 0

06.01.2009, 23:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746297

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Зл0й
Выбегалло
Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU.

Зато ОС (например Юникс) о том что происходит у процесса внутрях не ведает ни сном ни духом, и выделяет ему ресурсов исходя из неких заложенных в нее создателями предположений.

Каких-таких ресурсов юникс может недодать ? Приоритетов ? Ну пользуйтесь noage параметром, чтобы "перцем не стареть", и получать всегда один и тот же квант времени / приоритет.

Зл0йТак что один здоровенный тяжеленный процесс с кучей тредов внутри не обязательно работает лучше. Чисто умозрительно можно придумать сценарий при котором произойдет некий "затык" по производительности из-за процессов а не трэдов. Можно придумать и сценарий при котором произойдет "затык" по производительности из-за того что ОС не даст ресурсов большому-толстому процессу.

Пример ?

Зл0йВыбегалло
Недаром IBM решила перейти на нитевую архитектуру в DB2

Мы посмотрим что из этого выйдет, когда они на нее перейдут. Помнится лет этак пятнадцать тому назад один из лидеров рынка СУБД на тот момент решил перейти на блокировку уровня строки вместо блока (за 7м Ораклом погнались). Кончилось прискорбно, с большим скандалом.

Дык перешли уже, 9.5. C October 31, 2007 - особых скандалов что-то не слышно.

Зл0йОно конечно можно слабать информикс который будет выдавать себя за DB2. Обе СУБД были в свое время написаны практически по одной спецификации, потму что ее писал один и тот же человек. Но это к "переходу на нитевую архитектуру" не имеет отношения. Просто у IBM оказалось 2 софтины написанных по одной спецификации. Выбрали ту которая поблатнее, а другую решили убить. А под какой маркой продавать будут - это к маркетроидам. Пусть хоть IMS обзовут, техники дела это не поменяет.

О как ! Значит, Informix начнут продавать под маркой DB2...
Признайтесь честно - вы ведь ни DB2, ни Informix толком не знаете?

...

Рейтинг:

0 / 0

07.01.2009, 00:00

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746313

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!я хочу увидеть документ описывающий оптимизацию, чтоб убедится что она существует, а не вы как с scip_commited что-то напутали.
onstat-
Теперь прикиньте разницу в количестве системных вызовов для синхронизации доступа к разделяемым ресурсам в памяти.

прикидываю - разница на порядок, т.к. информикс вынужден софтварно эмулировать базовые вещи процессора, оракловый процесс же хардварно примерно на порядок быстрей переключит контекст.

И какая же OS из используемых Ораклом позволяет хардверно переключать контекст ?

Yo.!автор The threads are awakened and given the resource in the order that they have requested it. It is the responsibility of the thread releasing the resource to awake the first thread on the queue, change the head of the queue, and put the thread on the ready queue. The spinning mechanisms described under latches is still used, but only to get one of the latches in the mutex. The threads are never put to sleep on a semaphore to wait since there are now appropriate VP queues for them to wait in.
тут или у меня плохо с англицким или криво построена фраза. единствено, что понял, так что это обязаность тхреда запустить следующего из очереди, сразу возникает вопрос, а если там бесконечный луп, кто будет переключать ?

Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.

...

Рейтинг:

0 / 0

07.01.2009, 00:23

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746365

Yo.!

Гость

Выбегалло
И какая же OS из используемых Ораклом позволяет хардверно переключать контекст ?
не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:
Old versions of Linux took advantage of the hardware support offered by the 80x86 architecture and performed a process switch through a far jmp instruction[*] to the selector of the Task State Segment Descriptor of the next process. While executing the instruction, the CPU performs a hardware context switch by automatically saving the old hardware context and loading a new one. But Linux 2.6 uses software to perform a process switch ...

Выбегалло
Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.
хм ... а что у информикса нет аналога SPL из db2 ? сторед процедуры компилирую отдельно, кто их исполнение контролирует ?

...

Рейтинг:

0 / 0

07.01.2009, 01:31

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746367

Yo.!

Гость

фразу "не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:" читать как "не знаю, до сегоднешнего дня думал, что все, но гугл нашел такую фазу:"

...

Рейтинг:

0 / 0

07.01.2009, 01:32

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746490

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!фразу "не знаю, до сегоднешнего дня все, но гугл нашел такую фазу:" читать как "не знаю, до сегоднешнего дня думал, что все, но гугл нашел такую фазу:"

Context switching can be performed primarily by software or hardware. Some processors, like the Intel 80286 and higher CPUs, have hardware support for context switches, by making use of a special data segment designated the Task State Segment or TSS. When a task switch occurs (implicitly due to a CALL instruction, referring to a task gate, or explicitly due to an interrupt or exception) the CPU can automatically load the new state from the TSS. With other tasks performed in hardware, one would expect this to be rather fast; however, mainstream operating systems, including Windows, do not use this feature.

...

Рейтинг:

0 / 0

07.01.2009, 07:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746492

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!

Выбегалло
Никто. Но все бесконечные лупы уже выловлены за долгие годы эксплуатации.
хм ... а что у информикса нет аналога SPL из db2 ? сторед процедуры компилирую отдельно, кто их исполнение контролирует ?

SPL - есть, конечно. Как конкретно происходит отдача управления я не знаю, но скорей всего код процедуры парсится, нить, отвечающая за выполнение процедуры, берет псевдокод и интерпретирует его покомандно, время от времени (скажем, после каждой десятой команды) отдавая процессор следующей нити из очереди готовых на выполнение. Таким образом, бесконечный цикл внутри процедуры не вызовет бесконечного захвата процессора.
Более интересна ситуация, когда процедура написана на C. В свое время на интервью меня спросили "в чем преимущества и недостатки информиксовской реализации хранимых процедур на С ?". Я тогда в informixе был практически ни в зуб ногой, как сейчас понимаю :-) , но интервьюир ответил сам : преимуществом и недостатком является выполнение таких процедур в адресном пространстве сервера. С одной стороны, получается быстро, без системных вызовов, семафоров и тд, но с другой стороны можно уронить сервер, или устроить, действительно, бесконечный цикл.

...

Рейтинг:

0 / 0

07.01.2009, 07:49

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746708

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

07.01.2009, 15:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746821

Zhora

Участник

Откуда: USA New York

Сообщения: 371

Рейтинг: 0 / 0

Выбегалло
...
Дык перешли уже, 9.5. C October 31, 2007 - особых скандалов что-то не слышно.
...

Речь шла о Sybase ASE, в котором BTW до сих пор (at least 12.5) с row-level locking and index ignored dup_key возникают дурацкие deadlocks (оба stmt в errorlog показыает select !) при insert, так что я помню (у меня где-то тонны есть emails) нам пришлось клиенту советовать вернуть все обратно (на APL)...

...

Рейтинг:

0 / 0

07.01.2009, 18:14

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746871

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

ApexВыбегалло
Зл0йТеперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной.

А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
Да хоть на два порядка, сколько это в абсолютном значении? И сколько это в процентах от общего времени отклика? Покажите мне хоть одно, настолько хорошо написанное предложение, где перфоманс начинают выжимать уже из скоростей переключения контекста!

DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?

...

Рейтинг:

0 / 0

07.01.2009, 19:25

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746894

Yo.!

Гость

Выбегалло
DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?
ну например для того, чтоб не остатся единственной в мире субд работающей через процессы под виндой (где действительно переключения между процессами противоестественно и жутко тормозит).

...

Рейтинг:

0 / 0

07.01.2009, 19:49

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746972

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Yo.!Выбегалло
DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?
ну например для того, чтоб не остатся единственной в мире субд работающей через процессы под виндой (где действительно переключения между процессами противоестественно и жутко тормозит).
Yo.! дайте ссылку, вместе почитаем, когда-там у DB2 процессы были под Windows?

...

Рейтинг:

0 / 0

07.01.2009, 21:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746974

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

offtop:

например, зачем нужен thread-based, смотрите последний пост
http://www.sql.ru/forum/actualthread.aspx?tid=490648&hl=thread

...

Рейтинг:

0 / 0

07.01.2009, 21:56

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35746999

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Yo.!Выбегалло
DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?
ну например для того, чтоб не остатся единственной в мире субд работающей через процессы под виндой (где действительно переключения между процессами противоестественно и жутко тормозит).

О процессах в винде никто речи не ведет - там испокон веку все (O, DB2, Inf, Sybase, Ms) используют нити .

...

Рейтинг:

0 / 0

07.01.2009, 23:15

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747020

Я и ёжик

Участник

Откуда: СПб

Сообщения: 1 833

Рейтинг: 0 / 0

Справка 1.
onstat- при этом уклонились от ответа на вопрос как поделить
конкретный буферный пул на несколько LRU.

Он делится автоматически исходя из числа процессоров в системе (cpu_count) и числа буферов кэша.
До 9i существовал параметр db_block_lru_latches которым можно было подкрутить автоматически установленное значение, с 9i он стал скрытым и не рекомендован к изменению.

onstat-
Увеличивайте количество LRU, тем самым уменьшите спины.

Честно говоря никогда не наблюдал конкуренции на защелках LRU списков, в Oracle (да думаю и у других) они используются только когда надо найти место для вновь считанного с диска блока, т.е. для орперации которую буферный кеш и стремится сократить. Конкуренция обычно возникает при поиске нужного блока в кеше (т.е. при логической операции чтения, коих случается значительно больше), а этот поиск Oracle выполняет отнюдь не по LRU спискам (опять же думаю как и у других СУБД, поскольку LRU списки приспособлены для поиска давно не используемого блока, а не для поиска требуемого блока), а по специальной отдельной HASH-структуре, в Oracle её называют 'cache buffer chains', которая имеет свои латчи. Рулить размером этой таблицы тоже можно и так же за это отвечает скрытый параметр, т.е. в большинстве случаев рулить не рекомендуется.

References:
Database Writer and Buffer Management. Nitin Vengurlekar. Oracle corp.

Справка 2, (про Oracle механизмы доступа к latch и spin_count )
В оракле есть два механизма получения доступа к защелкам (latch), один из них
уже упоминавшийся здесь 'Willing-to-Wait', т.е. выполнение _spin_count попыток и потом при неудаче сон и после тайм аута новая попытка. Второй метод 'Latch Wait Posting', когда процесс не получивший доступ к защелке перед тем как заснуть ставит себя в очередь на доступ к защелке,
а процесс освобождающий защелку проверяет список ожидающих (latch wait list) и если он не пуст будет следующего.
По умолчанию 'wait posting' применяется только для двух видов защелок ('library cache','shared pool'), связанных со структурами для хранения планов запросов, кода процедур и пакетов и т.п.
Режим 'wait posting' можно отключить для всех защелок или наоборот включить для всех опять же скрытым параметром. Но даже при включении 'wait posting' для всех защелок он не используется для защелок 'cache buffer chains', т.е. как раз защелок используемых при поиске в буферном кеше
о котором здесь и идет основное обсуждение.
Это можно трактовать двояко или доступ к буферам настолько быстр, что засыпание с последующим бужением оказывается дороже небольшого цикла попыток доступа или Oracle реализация 'wait posting' не очень удачна.

References:
Oracle 8i Internal Services for Waits, Latches, Locks and Memory. Steve Adams. O'Rally ISBN:1-56592-598-x

...

Рейтинг:

0 / 0

07.01.2009, 23:57

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747028

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

ВыбегаллоApexВыбегалло
Зл0йТеперь полезли искать эти преимущества в архитектуре сервера. Их там тоже нет. Потому, что как показывает практика многопоточная архитектура сервера СУБД не дает никаких ощутимых преимуществ по сравнению с многопроцессной.

А вот это в принципе неверно.
Переключение контекста в нити происходит на порядок быстрее, чем переключение контекста между процессами. Кроме того, нить "знает" когда можно отдать выполнение другой нити, а процесс переключается принудительно и может бестолку занимать CPU. Недаром IBM решила перейти на нитевую архитектуру в DB2
Да хоть на два порядка, сколько это в абсолютном значении? И сколько это в процентах от общего времени отклика? Покажите мне хоть одно, настолько хорошо написанное предложение, где перфоманс начинают выжимать уже из скоростей переключения контекста!

DB2 ver 9.5 - пример приложения, в котором "перфоманс начинают выжимать уже из скоростей переключения контекста". Иначе с хрена ли бы им переходить на новую архитектуру ?

На виндах переключение контекста происходит через задницу, поэтому производительность приложения состоящего их множества процессов ниже плинтуса. Поэтому на виндах Оракл тоже представляет собой один процесс с трэдами. Оракл мог бы и на Юниксах так сделать, но это не имеет смысла. Нормально написанные приложения на оракле крайне редко упираются в wait events связанные с межпроцессным взаимодействием. Как правило время ожидания на них сопоставимо со статистической погрешностью измерения.

...

Рейтинг:

0 / 0

08.01.2009, 00:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747286

softwarer

Участник

Откуда: 127.0.0.1

Сообщения: 51 965

Рейтинг: 0 / 0

Оракл мог бы и на Юниксах так сделать, но это не имеет смысла
Имхо скорее "имеет смысл так не делать". С точки зрения, например, выживания приложения при падении одного из процессов..

...

Рейтинг:

0 / 0

08.01.2009, 11:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747362

Yo.!

Гость

Выбегалло
О процессах в винде никто речи не ведет - там испокон веку все (O, DB2, Inf, Sybase, Ms) используют нити .

хм ... действительно

Я и ёжик Второй метод 'Latch Wait Posting', когда процесс не получивший доступ к защелке перед тем как заснуть ставит себя в очередь на доступ к защелке, а процесс освобождающий защелку проверяет список ожидающих (latch wait list) и если он не пуст будет следующего.
ну вот нашелся аналог очереди и "responsibility of the thread releasing the resource to awake the first thread on the queue"

...

Рейтинг:

0 / 0

08.01.2009, 13:26

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747440

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

Yo.!
ну вот нашелся аналог очереди и "responsibility of the thread releasing the resource to awake the first thread on the queue"

Без информации о том, как операционака знает, что нужно переключать контекст именно на
first thread on the queue:

(C) Yo! это рекламный слоган, типа шелковистых волос, никакой информации не несет :(

...

Рейтинг:

0 / 0

08.01.2009, 14:28

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35747533

Я и ёжик

Участник

Откуда: СПб

Сообщения: 1 833

Рейтинг: 0 / 0

onstat-Без информации о том, как операционака знает, что нужно переключать контекст именно на
first thread on the queue
Операционка этого и не должна знать,очередь это внутренняя структура которую Oracle ведет для Latch. Тут идет совершенно стандартный механизм взаимодействия процессов в OS, процесс (1) записывает себя в очередь и засыпает на семофоре OS, процесс (2) заканчивает свою работу, видит, что есть очередь к ресурсу который он держал и сбрасывает соответствующий симофор OS (вероятно номер симофора это часть информации записываемой в очередь). Далее OS видит , что симофор на котором у нее спит процесс сброшен и ставит соответствующий процесс в очередь на выполнение.

...

Рейтинг:

0 / 0

08.01.2009, 15:40

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35749383

terrarium

Гость

to "Я и ёжик"

странно видеть тут вас двоих :)
А скажите реализация в windows какие имеет недостатки/достоинства окромя, что "все в одном процессе"?

...

Рейтинг:

0 / 0

10.01.2009, 00:45

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35749565

ёжик с финской границы

Гость

terrariumto "Я и ёжик"

странно видеть тут вас двоих :)
А скажите реализация в windows какие имеет недостатки/достоинства окромя, что "все в одном процессе"? я не сталкивался с промышленными инсталяциями oracle под windows, поэтому ничего сказать не могу.

...

Рейтинг:

0 / 0

10.01.2009, 11:02

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35749859

ёжик с финской границы

Гость

...

Рейтинг:

0 / 0

10.01.2009, 16:44

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35764023

чя321

Гость

Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.

...

Рейтинг:

0 / 0

19.01.2009, 10:23

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35765822

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

чя321Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.

А пацаны из оракла просто дописали к серверу приблуду под названием MTS (по новому shared server). Вместо того чтобы на каждую сессию создавать процесс (dedicated server process), создаются совместно используемые сессиями процессы. То есть архитектура собственно сервера осталась неизменной, поменяли только один кусок. Как показывает практика, эта фича используется крайне редко, потому что грамотные разработчики web-приложений обычно используют connection pool а доля приложений с тяжелым клиентом неуклонно падает каждый год.

Все эти дорогостоящие архитектурные оптимизации сервера под случаи которые происходят "раз в миллион лет" напоминают мне установку спойлера на автомобиль ВАЗ-2106. Чисто теоретически все логично - машина заднеприводная и создавать дополнительный момент прижимающий ведущие колеса к дороге полезно. На практике же, сколько-нибудь ощутимый эффект от использования спойлера появляется на скоростях от 180 до 200 километров в час. То есть на скоростях развить которые этот автомобиль конструктивно не способен.

...

Рейтинг:

0 / 0

19.01.2009, 20:41

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35765837

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Зл0йчя321Контекст кончечно контекстом и скорость его переключения важна, особенно в граничных случаях.

Насколько мне известно, IBM DB2 перешла на threads потому как у операционной системы типа AIX, Solaris, HP-UX крышу сносит от 2000-3000 активных процессов и OS при такой нагрузке не знает как оптимально управлять специфичной нагрузкой на БД. Потому как schedulers операционной системы тоже имеют недостатки, и в таких пограничных ситуациях они начинают проявляться.

А пацаны из оракла просто дописали к серверу приблуду под названием MTS (по новому shared server). Вместо того чтобы на каждую сессию создавать процесс (dedicated server process), создаются совместно используемые сессиями процессы. То есть архитектура собственно сервера осталась неизменной, поменяли только один кусок. Как показывает практика, эта фича используется крайне редко, потому что грамотные разработчики web-приложений обычно используют connection pool а доля приложений с тяжелым клиентом неуклонно падает каждый год.

Все эти дорогостоящие архитектурные оптимизации сервера под случаи которые происходят "раз в миллион лет" напоминают мне установку спойлера на автомобиль ВАЗ-2106. Чисто теоретически все логично - машина заднеприводная и создавать дополнительный момент прижимающий ведущие колеса к дороге полезно. На практике же, сколько-нибудь ощутимый эффект от использования спойлера появляется на скоростях от 180 до 200 километров в час. То есть на скоростях развить которые этот автомобиль конструктивно не способен.

Пацаны из Информикса написали такую приблуду под названием Connection Manager году, если мне не изменяет мой склероз, в 1999м. Несмотря на нитевую архитектуру.

Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.

...

Рейтинг:

0 / 0

19.01.2009, 20:54

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35765848

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

На самом деле дискуссия перешла в плоскость "Pre-emptive vs. Cooperative Multitasking". Преимущества и недостатки обоих давно известны. При "правильном" использовании ...

автор - Cooperative Multitasking: Mostly avoids the need to explicitly
control resource sharing. Allows you to violate "invariants"
to boost performance as long as things are restored to normal
before the next task switching point.

- Pre-emptive Multitasking: Doesn't lose control to buggy
applications.Что и сделал Informix. Азбучные истины, в общем-то...

...

Рейтинг:

0 / 0

19.01.2009, 21:01

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35766180

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Relic HunterНа самом деле дискуссия перешла в плоскость "Pre-emptive vs. Cooperative Multitasking". Преимущества и недостатки обоих давно известны. При "правильном" использовании ...

автор - Cooperative Multitasking: Mostly avoids the need to explicitly
control resource sharing. Allows you to violate "invariants"
to boost performance as long as things are restored to normal
before the next task switching point.

- Pre-emptive Multitasking: Doesn't lose control to buggy
applications.Что и сделал Informix. Азбучные истины, в общем-то...

И это тоже. Имея весь код на руках, глупо заниматься pre-emptive miltitasking. И наоборот, имея код от третьих фирм, глупо на него уповать (вспоминая винду-95ю).

...

Рейтинг:

0 / 0

20.01.2009, 08:21

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35768379

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Выбегалло
Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.

Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.

...

Рейтинг:

0 / 0

21.01.2009, 04:33

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35768439

Выбегалло

Участник

Откуда: Scottsdale, AZ, USA

Сообщения: 3 653

Рейтинг: 0 / 0

Зл0йВыбегалло
Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.

Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.

Рядом с таким сильным утверждением неплохо бы смотрелась ссылочка.

...

Рейтинг:

0 / 0

21.01.2009, 07:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35770300

чя321

Гость

2Злой:
Можно подумать СУБД состоит только и пользовательских процессов?
А как на счет системных процессов например DBWRITE/DBREAD или как они там в Oracle называются.
В системе с терабайтами данных их немало...

...

Рейтинг:

0 / 0

21.01.2009, 18:25

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35771317

Informix Guest

Гость

2008 VendorRate Annual Report

...

Рейтинг:

0 / 0

22.01.2009, 11:17

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35771433

Mark Barinstein

Гость

How multithreaded architecture works in DB2 9.5 .
Упор делается на:
---
Here are some of the advantages of the new memory model:

* The new memory model is simpler and more easily configured.
* This model saves resources:
Significantly fewer system file descriptors are used. The most obvious distinction between processes and threads is that all threads of a process share the same memory space and system-defined facilities. Facilities include open file handles (file descriptors), shared memory, process synchronization primitives, and current directory. All threads in a process can share the same file descriptors. There is no need to have each agent maintain its own file descriptor table.
* Performance is enhanced:
Operating systems can generally switch (context switching) faster between threads of the same process than between different process. There is no need to switch address space. Because global memory is shared and almost no new memory must be allocated, creating a thread is simpler and faster than creating a process. Process creation is expensive in terms of processor cycles and memory usage.
* There are more automatic and dynamic configurable parameters, so less is required from the DBA.
---

...

Рейтинг:

0 / 0

22.01.2009, 11:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35772882

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

ВыбегаллоЗл0йВыбегалло
Оптимизация сервера под нити - это отнюдь не "случай, который происходит раз в миллион лет". Выигрыш имеется изначально и растет с увеличением нагрузки.

Выигрыш если и имеется изначально, то в пределах погрешности измерения. Что-то между сотой и десятой частью процента и растет в лучшем случае где-то до четверти процента от времени затраченного на выполнение запроса. Это так, исходя из того сколько времени запрос в сумме тратит на все ожидания которых можно избежать с помощью нитевого сервера.

Рядом с таким сильным утверждением неплохо бы смотрелась ссылочка.

Ссылочка на что? Достать вам с production environment и выложить statspack/AWR report? Боюсь начальство не разрешит, т.к. в нем SQL. Может на слово поверите?

...

Рейтинг:

0 / 0

23.01.2009, 04:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35772887

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

чя3212Злой:
Можно подумать СУБД состоит только и пользовательских процессов?
А как на счет системных процессов например DBWRITE/DBREAD или как они там в Oracle называются.
В системе с терабайтами данных их немало...

Оракл с включенным сбором AWR для каждого запроса хранит сколько времени было потрачено на:
- исполнение на проце
- ввод-вывод (несколько разных видов)
- ожидание на блокировках
- ожидание на "защелках" (latch wait) т.е. примитивах синхронизации самой СУБД.

Сия информация доступна через каталог (Data Dictionary), можно посчитать сколько процентов от времени выполнения запроса уходит на ожидание на "защелках". Так вот, даже если архитектура сервера представляет недостижимый идеал, при котором этого ожидания не происходит совсем, то существенной экономии достигнуть не удастся. От силы выжмете процент-два, если очень повезет. Все это при условии что приложение разработано грамотно и учитывает специфику СУБД Оракл и что DBA грамотно настроил СУБД. В противном случае ожидание на "защелках" может представлять собой проблему. Но лечится эта проблема не переписыванием сервера СУБД а грамотной разработкой приложения и настройкой СУБД.

Если глянуть в архитектуру Информикса, то его трэды это модель которая у жабокодеров называецца green threads. От нее в жабе кажись ушли еще в версии 1.2-1.3 лет этак много тому назад. От кооперативной многозадачности в ОС тоже в общем-то ушли очень давно. И правильно сделали. Допустим донаписал я свой собственный DataBlade к информиксу, и лажанулся в процессе (с кем не бывает). Энтот блэйд уложит мне весь информикс к ядрене фене. В Оракле если я лажанулся аналогичным образом то отвалится пользовательский процесс и этим дело скорее всего законится. Я уж не говорю что архитектура из одного тяжелого процесса у которого все "внутрях" конфликтует с изначальной идеологией Юникса который по идее писался как time sharing system, которая по идее не должна давать одному процессу монополизировать всю железяку. Оно конечно Юникс - система гибкая, можно извратиться и заставить ее работать совсем не так как она должна работать. Только может лучше грамотную архитектуру сервера делать с самого начала, чтобы не пришлось извращаться и издеваться над ОС - основной платформой на которой абсолютное большинство production systems крутятся?

...

Рейтинг:

0 / 0

23.01.2009, 05:04

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35772890

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

чя3212Злой:
В системе с терабайтами данных их немало...

Хотите я про терабайты, телеком и СУБД вам правду-матку рубану, с плеча? Для типичных телекомовских задачек (сотни терабайт данных + нетривиальная аналитика), при желании можно вообще без СУБД обойтись. То есть и Оракл и Информикс и DB2 c Teradata - неэффективное решение данной задачи. Лет этак 10 тому назад просто не было другого выбора. "Мыши плакали и кололись, но ели кактус" (С). Сейчас выбор есть. Самую тяжелую часть работы связанную с обработкой терабайт данных выполняет не СУБД, а совсем другая хреновина. А реляционная СУБД сегодня предстваляет собой витрину/ларек данных (Data Mart). Если тупо и злобно по книжке строить реляционное хранилище, то при "взрослых" телекомовских объемах эта затея обойдется примерно в рыночную капитализацию всей телекомовской компании.

...

Рейтинг:

0 / 0

23.01.2009, 05:18

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35772973

Informix Guest

Гость

Зл0йДопустим донаписал я свой собственный DataBlade к информиксу, и лажанулся в процессе (с кем не бывает). Энтот блэйд уложит мне весь информикс к ядрене фене. В Оракле если я лажанулся аналогичным образом то отвалится пользовательский процесс и этим дело скорее всего законится. Я уж не говорю что архитектура из одного тяжелого процесса у которого все "внутрях" конфликтует с изначальной идеологией Юникса который по идее писался как time sharing system, которая по идее не должна давать одному процессу монополизировать всю железяку. Оно конечно Юникс - система гибкая, можно извратиться и заставить ее работать совсем не так как она должна работать. Только может лучше грамотную архитектуру сервера делать с самого начала, чтобы не пришлось извращаться и издеваться над ОС - основной платформой на которой абсолютное большинство production systems крутятся?

Многопоточная архитектура не означает наличия только одного процесса. Informix состоит не из одного процесса. Процессов может быть достаточно много, в зависимости от конфигурации конкретного сервера. "Энтот блэйд" ничего не уложит, т.к. выполняется на отдельном виртуальном процессоре (в отдельном процессе). Архитектура Informix не конфликтует с идеологией Unix, но её эффективно использует и органично дополняет. Informix Dynamic Server имеет грамотную архитектуру, возможно лучшую из всех существующих на данный момент.

...

Рейтинг:

0 / 0

23.01.2009, 08:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35773313

ScareCrow

Участник

Откуда: Белый город

Сообщения: 16 205

Рейтинг: 0 / 0

автор совсем другая хреновина
а что за хреновина?

...

Рейтинг:

0 / 0

23.01.2009, 11:26

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35774789

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

ScareCrowавтор совсем другая хреновина
а что за хреновина?

Смотря сколько у конторы денех. Суть задачи - пакетная обработка данных, которые надо почистить, отсортировать, аггрегировать итп. Если лавэ много а терабайт меньше ста то можно например Ab Initio, SAS, Informatica использовать. Если терабайт сотни то использовать коммерческие продукты становится накладно, и в ход идут mapreduce, sawzall и подобные технологии. Ларек/витрину для аггрегированных данных можно делать на реляционной СУБД а можно на многомерной OLAP, смотря что от нее требуется.

...

Рейтинг:

0 / 0

23.01.2009, 19:53

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35774814

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Informix Guest
"Энтот блэйд" ничего не уложит, т.к. выполняется на отдельном виртуальном процессоре (в отдельном процессе).

Виртуальном-шмиртуальном. Объясните мне простую вещь. С точки зрения ОС Юникс есть некий процесс. У него внутрях трэды-шмэды, это не существенно. Когда процессор выполняет некий код данного процесса происходит банальный segmentation fault. Что дальше происходит с процессом-то?

...

Рейтинг:

0 / 0

23.01.2009, 20:22

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35774913

Informix Guest

Гость

Зл0йВиртуальном-шмиртуальном. Объясните мне простую вещь. С точки зрения ОС Юникс есть некий процесс. У него внутрях трэды-шмэды, это не существенно. Когда процессор выполняет некий код данного процесса происходит банальный segmentation fault. Что дальше происходит с процессом-то?
Процесс-то естественно помрёт. Тот самый, в котором некий кривой код вызвал, как было метко подмечено банальный, sigsegv. Да и фиг с ним.

...

Рейтинг:

0 / 0

23.01.2009, 22:15

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35774957

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Хотите я про терабайты, телеком и СУБД вам правду-матку рубану, с плеча? Для типичных телекомовских задачек (сотни терабайт данных + нетривиальная аналитика), при желании можно вообще без СУБД обойтись. То есть и Оракл и Информикс и DB2 c Teradata - неэффективное решение данной задачи. Лет этак 10 тому назад просто не было другого выбора. "Мыши плакали и кололись, но ели кактус" (С). Сейчас выбор есть. Самую тяжелую часть работы связанную с обработкой терабайт данных выполняет не СУБД, а совсем другая хреновина..

ну зачем же так "долго" вспоминать ;)

вот например, года 3-4 назад, пару мобильных телекомов из топа 5 в Европе prepaid* клиентов считали hot-billing'ом**,
теряя каких-то "жалких" 15-20 лямонов EUR в год, тем что немогли это сделать на "лету"... Классический OLTP
Использовался продукт, который сейчас в Oracle Communications портфолио (т.е. изначально все было-и-есть Oracle)

Казалась бы, немогли что-ли напрявить весь "поток" сразу в Oracle-базульку? И наслажадаться "версионностью" и всякими другими прелестями...?!

п.с.
* prepaid - это когда вы сперва платите, а потом используете
** hot-billing - типа batch, который выполняется ,например, каждые 2 минуты

...

Рейтинг:

0 / 0

23.01.2009, 23:15

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35784374

Grrrr...

Гость

Зл0йНа виндах переключение контекста происходит через задницу, поэтому производительность приложения состоящего их множества процессов ниже плинтуса. Поэтому на виндах Оракл тоже представляет собой один процесс с трэдами.

Это не так. Нитевая модель была выбрана вовсе не из-за этого.

...

Рейтинг:

0 / 0

29.01.2009, 08:19

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35787789

Informix Over Oracle

Гость

ifmxuser Informix displaces Oracle at China Telcom
Europoean Postal service Chooses Informix Over Oracle

Key Facts:
- Decided to use Informix over Oracle Database for its newly designed core system.
- This country’s postal service currently has a network of more than 1,150 servers across more than 1,350 offices.

...

Рейтинг:

0 / 0

30.01.2009, 12:33

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35789984

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Informix Over Oracleifmxuser Informix displaces Oracle at China Telcom
Europoean Postal service Chooses Informix Over Oracle

Key Facts:
- Decided to use Informix over Oracle Database for its newly designed core system.
- This country’s postal service currently has a network of more than 1,150 servers across more than 1,350 offices.

2 Informix Over Oracle

Тогда уж бы добавили и

---
Investment Bank chooses Informix over Oracle RAC
Key Facts:
They twice failed to migrate to Oracle RAC
---

и т.д.

читать здесь:
ftp://ftp.software.ibm.com/software/data/informix/pubs/presentations/IDS-2009-Roadmap-012909.pdf

...

Рейтинг:

0 / 0

01.02.2009, 01:40

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35791711

sysmaster

Участник

Откуда: moscow_dbs.dat

Сообщения: 459

Рейтинг: 0 / 0

Оттуда же.

Telco Equipment Manufacturer chooses Informix
Key Facts:
Chose IDS upgrade over competing solution from Oracle.

Compelling Decision Factors:
Scalability and reliability
Ease of use
Small footprint
Benchmark testing against Oracle

...

Рейтинг:

0 / 0

02.02.2009, 14:40

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35791856

Yo.!

Гость

спасибо IBM, Informix на данный момент RIP с долей сильно меньше 1% рынка ...

...

Рейтинг:

0 / 0

02.02.2009, 15:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35792537

Informix over Oracle

Гость

Yo.!спасибо IBM, Informix на данный момент RIP с долей сильно меньше 1% рынка ...Снова пукнул, только чтоб не промолчать :)

...

Рейтинг:

0 / 0

02.02.2009, 21:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35792662

Пупукин

Гость

Informix over OracleСнова пукнул, только чтоб не промолчать :)

В мире существуют ниши.

Ниша корпоративная, высокоденежная. Крепко занята Oracle, а там где откатить быстрее
удалось, там DB2 и Sybase подвизаются (последний больше исторически, ЕМНИП повсеместно сносится).

Ниша средняя. Полунищеброды недокорпорации. Microsoft SQL Server. И Oracle чутка, где
полунищеброды мнят себя в элиты.

Ниша низшая. Нищеброды. MySQL, Firebird/Interbase, чутка PostgeSQL (там, где бомжи хотят быть чуть похожими на Oracle).

Ну еще ниша встраеваемых систем.

Перетекание из ниши в нишу в принципе не возможно,
во всяком случае легальными средствами (хотя в этих ваших СНГ распостранено
использование Oracle на всех уровнях, и ухахаха, даже попытки лепить MSSQL на
корпоративный уровень).

===

А на кой нужен ваш Informix? Ну хорошо, ну молодцы, не загнулись еще. И что с того?
На кой хер энтропию плодить? Все равно мыслей у вас умных нет, одно занудство.

...

Рейтинг:

0 / 0

02.02.2009, 23:39

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35792973

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

Пупукин
На кой хер энтропию плодить?

Зачем сам энтропию плодишь?! Был !Yo, остался б !Yo, так нет - то Пупукин, то ... :)

...

Рейтинг:

0 / 0

03.02.2009, 10:00

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35792983

побарабану кто круче

Гость

Пупукин
На кой хер энтропию плодить? Все равно мыслей у вас умных нет, одно занудство.

+1

Так прочли бы новость , кому интересно, и забыли бы, а если топик на 6 страниц,
и от технических деталей спор перешел о % рынка,
значит, кто то чувствует слабину, и пытается свою священную корову защищать.

Священная корова в защите нуждаться не нужна, на то она и священная.

...

Рейтинг:

0 / 0

03.02.2009, 10:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35793589

психотерапевт

Гость

ПупукинПеретекание из ниши в нишу в принципе не возможно
Ага, все генералы сразу стали полковниками после училища и все корпорации сразу стали ворочать миллиардами, а ты сразу родился с тайным знанием одной единственной субэдэшки.
Диагноз:
Юношеский максимализм и упрямство (тут еще шансы есть) или просто беспросветная глупость с завышенной самооценкой (тут шансов нет).

...

Рейтинг:

0 / 0

03.02.2009, 13:00

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35797764

Пупукин

Гость

психотерапевтЮношеский максимализм и упрямство (тут еще шансы есть) или просто беспросветная глупость с завышенной самооценкой (тут шансов нет).

Самокритичненько.

У кого что болит, тот о том и говорит, понимаю, да.

...

Рейтинг:

0 / 0

04.02.2009, 21:06

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35800665

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herr

Investment Bank chooses Informix over Oracle RAC
Key Facts:
They twice failed to migrate to Oracle RAC

Если руки кривые, то можно и пять раз неудачно пытаться мигрировать с single-instance Oracle на Oracle RAC. А если не кривые, то можно с одного раза мигрировать. Оракл и Информикс тут не при чем. Я могу привести вам команду и мигрировать на RAC. Буит стоить денех, и если приложение кривое то его придется переписать.

sysmaster
Telco Equipment Manufacturer chooses Informix
Key Facts:
Chose IDS upgrade over competing solution from Oracle.

Compelling Decision Factors:
Scalability and reliability
Ease of use
Small footprint
Benchmark testing against Oracle

Готов поспорить что еще и на ценник посмотрели. Больше всего прикололо "Ease of use" и "Small footprint". Сразу зародились подозрения о кривизне рук. Что такое "Ease of use" применительно к СУБД? Что, вы хотите сказать что средства администрирования у Оракла недоразвитые и неудобные а у Информикса офигительно удобные что существенно повышает производительность труда DBA? В реальности все с точностью до наоборот. А бенчмарк я могу нарисовать такой при котором простая файловая система сделает любую реляционную СУБД. Вопрос в том кто тестировал, как и главное - зачем.

...

Рейтинг:

0 / 0

06.02.2009, 01:41

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35800685

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Если руки кривые, то можно и пять раз неудачно пытаться мигрировать с single-instance Oracle на Oracle RAC.
А если не кривые, то можно с одного раза мигрировать.

как правило, кол-во кривых рук > чем не-кривых :)

Зл0й
Я могу привести вам команду и мигрировать на RAC.
Буит стоить денех, и если приложение кривое то его придется переписать.

в том же аспекте, могу сделать любое приложение, которое будет не хуже работать с не-Oracle базой
(это про менеджерский бред по поводу блокировок, локов и всякой прочей лабуды)

по поводу что-то переписать, так база же тоже "перепишется", в итоге:
Зл0й
Оракл и Информикс тут не при чем.

...

Рейтинг:

0 / 0

06.02.2009, 02:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35800686

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0йБольше всего прикололо "Ease of use" и "Small footprint" .
вас за язык никто не тянул :)
какие мин требование нужны для Oracle и Informix, чтобы делать больше чем поднять сам инстанс?

...

Рейтинг:

0 / 0

06.02.2009, 02:45

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35800704

интересующийся РАК

Гость

Зл0йherr

Investment Bank chooses Informix over Oracle RAC
Key Facts:
They twice failed to migrate to Oracle RAC

Если руки кривые, то можно и пять раз неудачно пытаться мигрировать с single-instance Oracle на Oracle RAC. А если не кривые, то можно с одного раза мигрировать. Оракл и Информикс тут не при чем. Я могу привести вам команду и мигрировать на RAC. Буит стоить денех, и если приложение кривое то его придется переписать.

Сколько(приблизительно) может стоит и сколько занять времени опрделить
придется ли переписывать софт?

Если считать что в сиситеме около 400 таблиц около 1000 функций и процедур на PL/SQL и в шаред пуле
около 8000 планов запросов .

...

Рейтинг:

0 / 0

06.02.2009, 04:11

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35800881

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

herrЗл0йБольше всего прикололо "Ease of use" и "Small footprint" .
вас за язык никто не тянул :)
какие мин требование нужны для Oracle и Informix, чтобы делать больше чем поднять сам инстанс?
Можно я вмешаюсь? "чтобы делать больше чем поднять сам инстанс" нужно ровно столько чтобы поднять сам инстанс+столько, сколько нужно приложению.
Или сформулируйте вопрос инча, я его наверняка понял неправильно:)

...

Рейтинг:

0 / 0

06.02.2009, 09:28

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35802891

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herrЗл0йБольше всего прикололо "Ease of use" и "Small footprint" .
вас за язык никто не тянул :)
какие мин требование нужны для Oracle и Informix, чтобы делать больше чем поднять сам инстанс?

Мы СУБД на мобильный телефон пытаемся поставить или мы про базу для телекома говорим? Оракл можно поднять и на PDA c подключенным к нему внешним носителем, только это на фиг никому не нужное извращение. В случае реальной для субд задачи, типа биллинга для телекома, железяка будет серьезная. Поэтому вопрос "какова минимальная железяка на которой будет работать данная СУБД" представляет чисто умозрительный интерес.

...

Рейтинг:

0 / 0

06.02.2009, 20:51

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35802903

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

интересующийся РАКЗл0йherr

Investment Bank chooses Informix over Oracle RAC
Key Facts:
They twice failed to migrate to Oracle RAC

Если руки кривые, то можно и пять раз неудачно пытаться мигрировать с single-instance Oracle на Oracle RAC. А если не кривые, то можно с одного раза мигрировать. Оракл и Информикс тут не при чем. Я могу привести вам команду и мигрировать на RAC. Буит стоить денех, и если приложение кривое то его придется переписать.

Сколько(приблизительно) может стоит и сколько занять времени опрделить
придется ли переписывать софт?

Если считать что в сиситеме около 400 таблиц около 1000 функций и процедур на PL/SQL и в шаред пуле
около 8000 планов запросов .

Делаецца так: сначала feasibility study, нужно разобраться что происходит в СУБД, какие процессы и приложения в ней живут и как часто они "наступают друг другу на пятки" на диске. На основе детального анализа готовится proposal в котором указывается сколько времени уйдет, сколько народу будет пахать и сколько это будет стоить.

На feasibility study уйдет как минимум неделя, час моей работы стоит $250 в случае если работа в Северной Калифорнии. Если за ее пределами - дороже. В настоящий момент я дэцл занят но могу порекомендовать товарища который умеет такие штуки не хуже меня.

...

Рейтинг:

0 / 0

06.02.2009, 21:00

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35802960

интересующийся РАК

Гость

Зл0й
какие процессы и приложения в ней живут и как часто они "наступают друг другу на пятки" на диске.

Спасибо за ответ.

Большое количество инсертов связанная с ним актуализация индексов
считается насупанием на пятки?

Если да, то можно ли обойтись малой кровью поделив партиции на субпартиции своя для каждой
ноды.

Как быть если ПК глобальный, (не соответсвует условию партиционирования)?
При изменении партиционирования нужно будет много переделывать,
условия партиционирования есть частью логики не только хранения но и обработки.

зы Прошу прощения за офтопик, это был последний вопрос(ы).

...

Рейтинг:

0 / 0

06.02.2009, 22:04

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803127

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Мы СУБД на мобильный телефон пытаемся поставить или мы про базу для телекома говорим? Оракл можно поднять и на PDA c подключенным к нему внешним носителем, только это на фиг никому не нужное извращение. В случае реальной для субд задачи, типа биллинга для телекома, железяка будет серьезная. Поэтому вопрос "какова минимальная железяка на которой будет работать данная СУБД" представляет чисто умозрительный интерес.

видемо иногда железяк и не хватает (а может и рук тоже, но как-то повсеместно получается)
"стандартный вариант" с Оракл типа продалбать в стене дыру, чтоб влез какой-то там очередной Enterprise Mххх - можно. только зачем, если это невсегда нужно?

кстати, упоминалось здесь же
http://www.sql.ru/forum/actualthread.aspx?tid=625326&pg=6#6730059

"Small footprint" ссылка шла с Telco Equipment Manufacturer, и них там каждый байт на чеку :)

...

Рейтинг:

0 / 0

07.02.2009, 02:22

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803129

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Apex
Можно я вмешаюсь?

всегда пожалуйста

Apex
"чтобы делать больше чем поднять сам инстанс" нужно ровно столько чтобы поднять сам инстанс+столько, сколько нужно приложению.
Или сформулируйте вопрос инча, я его наверняка понял неправильно:)

хорошо, упростим задачу :)
информикс идс отсчет начинается с 256 мб рама для линукс, у оракл - с 1 гб

...

Рейтинг:

0 / 0

07.02.2009, 02:29

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803136

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

интересующийся РАКЗл0й
какие процессы и приложения в ней живут и как часто они "наступают друг другу на пятки" на диске.

Спасибо за ответ.

Большое количество инсертов связанная с ним актуализация индексов
считается насупанием на пятки?

Чисто умозрительно, не глядя на ваш конкретный расклад, скорее всего да. Под "Наступанием на пятки" понимают locking contention и как ни странно latch contention. Некоторые наивно полагают что поскольку в RAC инстансов много то конкуренция за внутриинстансные защелки станет меньше. На самом деле она вместо локальной (внутри одного инстанса) станет глобальной. Поэтому до попыток миграции на RAC нужно затюнить приложения и процессы крутящиеся в БД - минимизировать locking и latching. А уже потом ставить на RAC и тестировать как оно на нем работает.

интересующийся РАК
Если да, то можно ли обойтись малой кровью поделив партиции на субпартиции своя для каждой
ноды.

Как быть если ПК глобальный, (не соответсвует условию партиционирования)?
При изменении партиционирования нужно будет много переделывать,
условия партиционирования есть частью логики не только хранения но и обработки.

зы Прошу прощения за офтопик, это был последний вопрос(ы).
Oracle - не Teradata, он по архитектуре shared-disk а не shared-nothing. У каждой из этих архитектур есть свой комплект достоинств и недостатков. Нужно пользоваться достоинствами и обходить недостатки данной архитектуры, а не пытаться эмулировать другую архитектуру.

...

Рейтинг:

0 / 0

07.02.2009, 02:49

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803138

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herrApex
Можно я вмешаюсь?

всегда пожалуйста

Apex
"чтобы делать больше чем поднять сам инстанс" нужно ровно столько чтобы поднять сам инстанс+столько, сколько нужно приложению.
Или сформулируйте вопрос инча, я его наверняка понял неправильно:)

хорошо, упростим задачу :)
информикс идс отсчет начинается с 256 мб рама для линукс, у оракл - с 1 гб

Не зря говорят что правильно поставленный вопрос содержит больше половины ответа ;)

Если серьезно, то для встроенных примений есть Oracle Lite. На мобильные девайсы не ставят Oracle Enterprise Edition. Для разных применений у оракла есть разные продукты с разными требованиями к железу.

Oracle Lite на спор можно поднять на PDA с подключенным через USB внешним диском. Мой приятель поднимал на спор, выиграл ящик пива.

...

Рейтинг:

0 / 0

07.02.2009, 02:58

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803153

интересующийся РАК

Гость

Зл0йинтересующийся РАКЗл0й
какие процессы и приложения в ней живут и как часто они "наступают друг другу на пятки" на диске.

Спасибо за ответ.

Большое количество инсертов связанная с ним актуализация индексов
считается насупанием на пятки?

Чисто умозрительно, не глядя на ваш конкретный расклад, скорее всего да. Под "Наступанием на пятки" понимают locking contention и как ни странно latch contention. Некоторые наивно полагают что поскольку в RAC инстансов много то конкуренция за внутриинстансные защелки станет меньше. На самом деле она вместо локальной (внутри одного инстанса) станет глобальной. Поэтому до попыток миграции на RAC нужно затюнить приложения и процессы крутящиеся в БД - минимизировать locking и latching. А уже потом ставить на RAC и тестировать как оно на нем работает.

интересующийся РАК
Если да, то можно ли обойтись малой кровью поделив партиции на субпартиции своя для каждой
ноды.

Как быть если ПК глобальный, (не соответсвует условию партиционирования)?
При изменении партиционирования нужно будет много переделывать,
условия партиционирования есть частью логики не только хранения но и обработки.

зы Прошу прощения за офтопик, это был последний вопрос(ы).
Oracle - не Teradata, он по архитектуре shared-disk а не shared-nothing. У каждой из этих архитектур есть свой комплект достоинств и недостатков. Нужно пользоваться достоинствами и обходить недостатки данной архитектуры, а не пытаться эмулировать другую архитектуру.

Насколько я понял из ответов, в общем случае, чем больше количество конкурентных изменений данных в приложении, тем тяжелее оно мигрируется на РАК?

...

Рейтинг:

0 / 0

07.02.2009, 03:37

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35803154

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Не зря говорят что правильно поставленный вопрос содержит больше половины ответа ;)

Если серьезно, то для встроенных примений есть Oracle Lite. На мобильные девайсы не ставят Oracle Enterprise Edition. Для разных применений у оракла есть разные продукты с разными требованиями к железу.
Oracle Lite на спор можно поднять на PDA с подключенным через USB внешним диском. Мой приятель поднимал на спор, выиграл ящик пива.
Речь же идет о двух продуктах: Informix и Oracle, также речь шла о Informix и small footprint, как одна из причин перехода с Оракл.

Другими словами, если клиенту надо "нарезать" слаицы под виртуализацией или поставить в суперсторе железяку алл-ин-оне (а не PDA),
для этого ненадо покупать high-end, иметь электростанцию и держать в каждом бранче по ДБА ;)

О том что у Oracle есть что предложить "другое", никто и не совневается...
Но мы же не будем сравнивать тут идс с лите :)

еще раз,
Зл0й
Больше всего прикололо "Ease of use" и "Small footprint".

что вас там прикололо с "Small footprint"?

п.с.
пиво дело хорошее, и мало его не бывает... :)
в свое время, поставив Оракл 7 на Вин 3.11 с 4мб рам и 386сх проц, надолго обеспечил поставки пива

...

Рейтинг:

0 / 0

07.02.2009, 03:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35804399

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

herr
хорошо, упростим задачу :)
информикс идс отсчет начинается с 256 мб рама для линукс, у оракл - с 1 гб
Да ну, ерунда все это. Два года назад ставил Оракл 10.2 на виртуальную машину с Gentoo, виртуалке отдал 196Мб памяти. Работало. Чтоб подняться Ораклу надо 32М на разделяемый пул + 4Мб на кэш буферов+ 10% оверхэд под служебные структуры.
Ну да, начальные аппетиты у Оракла больше, в силу более сложной архитектуры, полагаю. Но кому есть дело, до начальных требований, если для реальной работы памяти потребуется на пару порядков больше? Или вы хотите сказать, что если Ораклу требовалось для биллинга, скажем, 12Гб кэша, то Информикс справится с той же нагрузкой при той же функциональности с 3Гб кэша(ну типа раз начальные требования в 4 раза больше, то тут в 4 раза можно сократить)?

...

Рейтинг:

0 / 0

08.02.2009, 17:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35804749

шубин_ду

Участник

Откуда: Питер->Кобург

Сообщения: 245

Рейтинг: 0 / 0

Зл0йherrApex
Можно я вмешаюсь?

всегда пожалуйста

Apex
"чтобы делать больше чем поднять сам инстанс" нужно ровно столько чтобы поднять сам инстанс+столько, сколько нужно приложению.
Или сформулируйте вопрос инча, я его наверняка понял неправильно:)

хорошо, упростим задачу :)
информикс идс отсчет начинается с 256 мб рама для линукс, у оракл - с 1 гб

Не зря говорят что правильно поставленный вопрос содержит больше половины ответа ;)

Если серьезно, то для встроенных примений есть Oracle Lite. На мобильные девайсы не ставят Oracle Enterprise Edition. Для разных применений у оракла есть разные продукты с разными требованиями к железу.

Oracle Lite на спор можно поднять на PDA с подключенным через USB внешним диском. Мой приятель поднимал на спор, выиграл ящик пива.

Какой там спор. Это уже вовсю используется. В последнем Oracle Magazine за февраль 2009 есть статья об использовании Oracle Lite во встроенных устройствах (Oracle Embedded Database).

...

Рейтинг:

0 / 0

09.02.2009, 01:53

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35807058

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

интересующийся РАК[quot Зл0й][quot интересующийся РАК]
Насколько я понял из ответов, в общем случае, чем больше количество конкурентных изменений данных в приложении, тем тяжелее оно мигрируется на РАК?

Тяжесть миграции сильнее всего зависит от квалификации разработчика (или команды разработчиков) оргинального приложения. Если приложение было грамотно спроектировано, написано и настроено с самого начала то оно переносится на RAC без внесения каких бы то ни было изменений. Причем грамотно написанное и отлаженное приложение в RAC конфигурации позволит больше конкурентных изменений чем то же приложение в сопоставимой single-instance конфигурации.

Чем больше ошибок и упущений допустили разработчики, тем больше мороки с миграцией на RAC. Если криво написанное приложение в single-instance конфигурации работать через пень-колоду еще будет, а в RAC конфигурации оно заткнется очень быстро.

Предлагаю аналогию:

Этот как мотоцикл, начинающим советуют 250 или 400 кубов. Потому что если по неумению ездить начинающий его уронит у него больше шансов выжить. В случае спортивного мотоцикла объемом в тысячу кубов шансы выжить у начинающего резко уменьшаются. Он существенно быстрее и им сложнее управлять. Значит ли это что литровый спортивный мотоцикл - ацтой? Нет, это значит что начинающим ездокам на нем делать нечего.

Oracle RAC - штука для тех кто "хорошо умеет ездить".

...

Рейтинг:

0 / 0

10.02.2009, 00:53

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35807063

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herr
Речь же идет о двух продуктах: Informix и Oracle, также речь шла о Informix и small footprint, как одна из причин перехода с Оракл.

Другими словами, если клиенту надо "нарезать" слаицы под виртуализацией
или поставить в суперсторе железяку алл-ин-оне (а не PDA),
для этого ненадо покупать high-end, иметь электростанцию и держать в каждом бранче по ДБА ;)

О том что у Oracle есть что предложить "другое", никто и не совневается...
Но мы же не будем сравнивать тут идс с лите :)

"Поставить" и "нарезать" - это решения задачи а не ее поставновка. Вы скажите какая задача решается, а я вам скажу как ее на Оракле эффективнее решить чем на Информиксе. Oracle lite - крайний случай демонстрирующий что Оракл можно заставить работать даже на "вообще никакой" железяке. Если уметь конфигурировать Оракл и знать линейку оракловых продуктов, то данную субд можно заставить работать на самых разных железяках, от мобильного телефона до Sun Fire E25K и HP SuperDome. Можно заставить работать и на дешевых линуксовых серверах по мощности сопоставимых со средней руки персоналкой.

herr

еще раз,
Зл0й
Больше всего прикололо "Ease of use" и "Small footprint".

что вас там прикололо с "Small footprint"?

То что выбирать и конфигурировать Оракл надо уметь. Оракл по сути единственная гибкая СУБД где один и тот же код работает в самых разных конфигурациях, от самой маленькой до самой большой. Например у DB2 и Sybase под мелкие задачи по сути одна СУБД, а под крупные - совсем другая. Инфромикс тоже не исключение с IDS и XPS.

Прикололо то, что нерюхи, толком неразобравшиеся с Ораклом, выдают одно из его премуществ за недостаток.

...

Рейтинг:

0 / 0

10.02.2009, 01:09

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35807092

интересующийся РАК

Гость

Зл0й
Тяжесть миграции сильнее всего зависит от квалификации разработчика (или команды разработчиков) оргинального приложения. Если приложение было грамотно спроектировано,
............
Oracle RAC - штука для тех кто "хорошо умеет ездить".

Приведите пожалуйста критерии правильного проектирования, можно даже лучше ссылку на мастер класс ,
а то я что то понять не могу, с одной стороны массовая вставка записей с разных нод
есть наступанием на пятки( как вы предположили) , когда я попытлся предположить,
что разнесение оперций по нодам
( каждая работает со своей субпартицией) может помочь, вы увидели в этом копироване
вражеской технологии shared-nothing .
Как правильно работать с RAC с точки зрения вставки записей?
Как писать приложения, что бы минимизировать наступание на пятки( блокировки , латчи, etc),
Логичным для меня, есть подход когда с каким либо набором данных работают(вставляют и изменяют) сесси только одной ноды с другим набором только другой.

В чем я не прав в своих предположениях?

Если я хочу стать архитектором приложений для РАК, этому где то учат, или только методом проб и ошибок?

...

Рейтинг:

0 / 0

10.02.2009, 02:17

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35807118

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Apex
Да ну, ерунда все это. Два года назад ставил Оракл 10.2 на виртуальную машину с Gentoo, виртуалке отдал 196Мб памяти. Работало. Чтоб подняться Ораклу надо 32М на разделяемый пул + 4Мб на кэш буферов+ 10% оверхэд под служебные структуры.

Дело ваше, где, на что и как устанавливать. Тут что производитель скажет...
Оракл 11гы, если не ошибаюсь, at least 1GB нужно, в десятке было 512мб

Apex
Ну да, начальные аппетиты у Оракла больше, в силу более сложной архитектуры, полагаю. Но кому есть дело, до начальных требований, если для реальной работы памяти потребуется на пару порядков больше?

мне есть дело :)
т.е. "взлететь" ему нужно как минимум тонна, то каков будет "расход"?! :)

Apex
Или вы хотите сказать, что если Ораклу требовалось для биллинга, скажем, 12Гб кэша, то Информикс справится с той же нагрузкой при той же функциональности с 3Гб кэша(ну типа раз начальные требования в 4 раза больше, то тут в 4 раза можно сократить)?
честно говоря незнаю, сколько кому потребуется в данном случае. 3 гига или 2, а может и все 8.

никогда не удовалось видеть (может не везло?), что идеть миграция с базы Х на Оракл, и при этом вся инфраструктура остается той же (как правило меняется в большую сторону по затратам $$$ и т.д.), но участвовал в проектах, где все делалось с точностью наооборот и при этом все хватало надолго для растущего бизнеса (в контексте биллинга, вендор и "OCP консультанты" советовали все выбросить и перебраться на high-end как решение проблем производительности)

...

Рейтинг:

0 / 0

10.02.2009, 03:57

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35807123

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
"Поставить" и "нарезать" - это решения задачи а не ее поставновка. Вы скажите какая задача решается, а я вам скажу как ее на Оракле эффективнее решить чем на Информиксе.

Клиент ушел на Informix, приведя свои аргументы, один из них small footprint.
Эффективнее решение это или нет - знают только они и только для них оно может быть эффективным в том контексте.

Зл0й
Oracle lite - крайний случай демонстрирующий что Оракл можно заставить работать даже на "вообще никакой" железяке.

"Оракл" слово оверюсед, многие употребляют его, но имеют совсем разное значение...

Зл0й
Если уметь конфигурировать Оракл и знать линейку оракловых продуктов, то данную субд можно заставить работать на самых разных железяках, от мобильного телефона до Sun Fire E25K и HP SuperDome. Можно заставить работать и на дешевых линуксовых серверах по мощности сопоставимых со средней руки персоналкой.

Вместо "Оракл" можно поставить например "IBM" и ваше утверждение останется верным.

Зл0й
То что выбирать и конфигурировать Оракл надо уметь. Оракл по сути единственная гибкая СУБД где один и тот же код работает в самых разных конфигурациях, от самой маленькой до самой большой.

немного перефразирую: "кому-то нравится алл-ин-он на все случаи жизни шампунь с кондиционером для волос и тела; кто-то покупает отдельно шампунь, кондиционер для специального типа волос"

Зл0й
Например у DB2 и Sybase под мелкие задачи по сути одна СУБД, а под крупные - совсем другая. Инфромикс тоже не исключение с IDS и XPS.

если уж использовать названия компаний везде - тогда вместо DB2 имеем IBM :)

Зл0й
Прикололо то, что нерюхи, толком неразобравшиеся с Ораклом, выдают одно из его премуществ за недостаток.

думаю, таких неразобравшихся, будет появлятся все больше.

...

Рейтинг:

0 / 0

10.02.2009, 04:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35808309

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

herrДело ваше, где, на что и как устанавливать. Тут что производитель скажет...
Оракл 11гы, если не ошибаюсь, at least 1GB нужно, в десятке было 512мб

Что Ораклы 11гы, что 10-ке памяти чтобы взлететь надо было гораздо меньше. После кастрации (потушить все ненужное, оставить только нужное), база под 11-гы вполне себе живет в своих 256 Мб для тестовых целей - за глаза. Объясняю откуда такие требования: в страндартной поставке 11-ой версии, вместе с базой ставится Apex (мини-сервер приложений) и OWB (ETL, design), их метаданные хранятся в базе и исполняемой средой для них тоже является база. Отсюда и требования. Ну, разве что shared_pool потолстел в последней версии, но оно и понятно, там теперь гораздо больше статистической информации хранится.

herrмне есть дело :)

Да вы же даже не понимаете причину этих требований, какое вам до них можеть быть дело?

herrт.е. "взлететь" ему нужно как минимум тонна, то каков будет "расход"?! :)
Вовсе необязательно бОльшие начальные требования приведут к бОльшему потреблению в процессе работы. Я не понимаю, как это можно не понимать :)

...

Рейтинг:

0 / 0

10.02.2009, 14:44

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35808850

Favn

Гость

Зл0йЕсли уметь конфигурировать Оракл и знать линейку оракловых продуктов, то данную субд можно заставить работать на самых разных железяках, от мобильного телефона до Sun Fire E25K и HP SuperDome. Можно заставить работать и на дешевых линуксовых серверах по мощности сопоставимых со средней руки персоналкой.Назовите, пожалуйста, причину, по которой DB2 LUW откажется работать на Sun Fire и HP SuperDome, равно как и на pSystem - ну очень интересно!
А для мобильных телефонов есть DB2 Everyplace.
Зл0йОракл по сути единственная гибкая СУБД где один и тот же код работает в самых разных конфигурациях, от самой маленькой до самой большой. Например у DB2 и Sybase под мелкие задачи по сути одна СУБД, а под крупные - совсем другая.IBM pSystem, Sun Fire и HP SuperDome - это для каких задач? DB2 LUW там живет, с "одним и тем же кодом", как и на персоналках. И в чем же "единственная гибкость" Oracle
А вот на zSystem (мейнфрейм), там где сидит "отдельная" DB2 for z/OS, Oracle в нативном виде не живет вообще. Если и есть, то только в виртуальных Linux-разделах. Или я что-то путаю, и на сайте Oracle z/OS версию тщательно скрывают? ;)

...

Рейтинг:

0 / 0

10.02.2009, 17:13

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35808905

Yo.!

Гость

Favn Или я что-то путаю, и на сайте Oracle z/OS версию тщательно скрывают? ;)
как обычно
http://www.oracle.com/technology/software/products/database/oracle10g/htdocs/10202zos.html

ЗЫ. но справедливости ради Oracle Lite это другая субд.
ЗЗЫ. db2 это три разных субд, че-то DB2 AS/400 у вас забылась.

...

Рейтинг:

0 / 0

10.02.2009, 17:32

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35811915

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

FavnOracle в нативном виде не живет вообще.
Неправда ваша. Oracle на мэйнфреймах живет еще с 80х годов прошлого века.

Favn
Если и есть, то только в виртуальных Linux-разделах. Или я что-то путаю, и на сайте Oracle z/OS версию тщательно скрывают? ;)
Оракл для z/OS есть, это раз. К тому же z/OS не единственная операционная система для мэйнфреймов, это два.

...

Рейтинг:

0 / 0

11.02.2009, 19:17

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35811985

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

интересующийся РАКЗл0й
Тяжесть миграции сильнее всего зависит от квалификации разработчика (или команды разработчиков) оргинального приложения. Если приложение было грамотно спроектировано,
............
Oracle RAC - штука для тех кто "хорошо умеет ездить".

Приведите пожалуйста критерии правильного проектирования, можно даже лучше ссылку на мастер класс ,

Что касается методологии проектирования - у Мартина очень дотошно расписано, книжка хоть и старая, но добрая. Что касается конкретно Оракла, начинать надо с книжек Кайта, а потом тюнить приложения пользуясь изложенной у него методологией. Со временем и опытом придет понимание как делать надо, и как не надо. Написать сборник рецептов "на все случаи жизни" не сможет никто.

интересующийся РАК
а то я что то понять не могу, с одной стороны массовая вставка записей с разных нод
есть наступанием на пятки( как вы предположили) , когда я попытлся предположить,
что разнесение оперций по нодам
( каждая работает со своей субпартицией) может помочь, вы увидели в этом копироване
вражеской технологии shared-nothing .

Тут нюансов много, кто вставляет, когда вставляет и как? Что в это же самое время происходит в базе данных? Данные читаются (если да - то как), изменяются (если да - то как)?

Если делать то что вы предлагаете (1 секция на узел), то делать нужно слегка не так. Нужно создать по одной таблице на узел, структура каждой таблицы должна полностью соответствовать основной (секционированной) таблице. Потом каждый узел заливает данные в свою таблицу. Потом все эти таблицы вставляются в основную с помощью Exchange partition.

Это решение совершенно не обязательно самое эффективное. Раз на то пошло, можно на ту же кластеризованную файловую систему посадить еще один (или много) оракл который будет "готовить" таблицы через transportable tablespace.

А еще можно сделать hash-partitioning основной таблицы. А еще можно сделать комбинированный partitioning. Можно много чего сделать. Если посидеть и подумать я могу еще десяток разных вариантов придумать. Не зная что конкретно происходит в вашей системе, как и когда данные читаются и пишутся и какие требования предъявляются к их актуальности, согласованности итп. я лично не могу сказать какое решение вам подойдет.

интересующийся РАК
Как правильно работать с RAC с точки зрения вставки записей?

Не зная вашей конкретной задачи я затрудняюсь ответить на поставленный вопрос. В зависимости от требований решения могут быть самые различные.

интересующийся РАК
Как писать приложения, что бы минимизировать наступание на пятки( блокировки , латчи, etc),
Логичным для меня, есть подход когда с каким либо набором данных работают(вставляют и изменяют) сесси только одной ноды с другим набором только другой.

В чем я не прав в своих предположениях?

Если я хочу стать архитектором приложений для РАК, этому где то учат, или только методом проб и ошибок?

Предположения - это хорошо, только я лично не раз жестоко ошибался. Шишек набил немало. Хотите в архитекторы? О вас требуется вот что:
- опыт тюнинга оракловых приложений
- детальное понимание архитектуры RAC, как она работает

Дальше делаете прототип (proof of concept), зная где основные contention points вашего конкретного приложения на single-instance строите RAC с тем чтобы их обойти. Потом используя уже наработанную методологию тюнинга и прототип вы проверяете что ваши предположения (и сведения написанные в оракловой документации) верны. Если ошиблись - находите где "затык" и пытаетесь переделать архитектуру чтобы его не было. Есть книжки по тюнингу приложений и про то как работает РАК. Сборников готовых рецептов пока нет, и скорее всего не будет.

...

Рейтинг:

0 / 0

11.02.2009, 20:20

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35820695

Favn

Гость

Yo.!Favn Или я что-то путаю, и на сайте Oracle z/OS версию тщательно скрывают? ;)
как обычно
http://www.oracle.com/technology/software/products/database/oracle10g/htdocs/10202zos.html
Да, как обычно - Федот, да не тот :)
Спасибо за ссылку - на сайте ее найти не просто. И ссылка эта - на версию 4-летней давности (10gR2 вышла в мае 2005, если не ошибаюсь).
Вывод - в данный момент z/OS от Оракл поддерживается только сильно устаревшей версией - 11g вышла в июле 2007, как я понял.
Вывод из вывода - не сделали 11g for z/OS за 2 года, никакой информации о планах выпуска нет (в поиске по сайту не нашел) - значит, уже вряд ли появится.
Yo.!ЗЗЫ. db2 это три разных субд, че-то DB2 AS/400 у вас забылась.Спасибо, я в курсе :) Не забылась, просто платформа OS/400 - случай отдельный, к разговору о "свермощных" решениях и "уникальности" Оракл не относящийся - IBM iSeries в смысле СУБД не мощнее Unix-серверов.

...

Рейтинг:

0 / 0

16.02.2009, 19:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35820756

Favn

Гость

Зл0йНеправда ваша. Oracle на мэйнфреймах живет еще с 80х годов прошлого века.Прошу прощения, переформулирую - да, устаревшая версия Oracle живет там и сейчас.
Зл0йОракл для z/OS есть, это раз. К тому же z/OS не единственная операционная система для мэйнфреймов, это два.Думаю, что сейчас реально имеет смысл говорить только о мейнфреймах от IBM. На них 2 ОС - z/OS и z/Linux. На обеих, как меня справедливо поправили, живет 10gR2 (как и на Fujitsu Siemens BS2000/OSD). На большинстве остальных систем - 11g. Вспоминаем Ваше утверждение:
Зл0йОракл по сути единственная гибкая СУБД где один и тот же код работает в самых разных конфигурациях, от самой маленькой до самой большой. Например у DB2 и Sybase под мелкие задачи по сути одна СУБД, а под крупные - совсем другая.1. Вы будете утверждать, что 10g и 11g - это один и тот же код? :) А DB2 for z/OS то же не сильно отличается от DB2 LUW, по крайней мере с точки зрения SQL.
2. Получается, что практически все поддерживаемые Oracle 11g платформы поддерживаются и DB2 LUW, "с одним и тем же кодом". Делаю вывод, что под "самой большой" платформой понимался все-таки мейнфрейм. Да, на z/OS DB2 другая, но живая, а Oracle - устаревшая версия. Вторая OS для zSeries - z/Linux, но там тоже Oracle 10gR2. А DB2 LUW там как раз неплохо себя чувствует, с тем же самым кодом (в отличие от Оракл). :)
Итого - не утверждаю, что DB2, например, лучше, но с нетерпением жду аргументации "единственности" для "маленьких и больших конфигураций". ;)

...

Рейтинг:

0 / 0

16.02.2009, 19:37

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35820827

.Yo!

Гость

пока не выйдет второй релиз 11g эта версия не привысит 1% продакшен инсталяций оракала, говорить что 10g занимающий 99% продакшен инсталяций мягко говоря глупо ...

ЗЫ. поинтересуйтесь на досуге каких готов дб2 и zOS на большинстве МФ ;)

...

Рейтинг:

0 / 0

16.02.2009, 20:41

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35823173

Favn

Гость

.Yo!пока не выйдет второй релиз 11g эта версия не привысит 1% продакшен инсталяций оракала, говорить что 10g занимающий 99% продакшен инсталяций мягко говоря глупо ...Ну хорошо, не считаете устаревшей - не надо, я говорил об уровне поддержки платформы и отсутствии "общего кода", т.к. нет упоминаний о планах выхода 11g под ОСы zSeries, а 2 года - срок большой. На самом деле, все мои посты тут вызваны только искренним удивлением по поводу "гибкой уникальности" Оракла. Против него самого ничего не имею - кой-чего имею именно против фанатизма :)

.Yo!ЗЫ. поинтересуйтесь на досуге каких готов дб2 и zOS на большинстве МФ ;)Дело в выходе свежих версий, которые показывают жизненность платформы, а не в установках - мало ли древностей в мире работает. Интересоваться не буду - не интересно, т.к. эти платформы я не использую.
ЗЫ. "Готы db2 и zOS" очень понравились, на наших глазах родилась новая субкультура :)

...

Рейтинг:

0 / 0

17.02.2009, 18:12

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35823305

.Yo!

Гость

гибкость и уникальность оракла в том, что АДБ имея опыт с 11g на своем лаптопе может пройти небольшой курс по особностям оракла на МФ и рулить ораклом 10g под МФ. у db2 же опыт администрирования не на МФ не поможет т.к. администрирование db2 под z/OS совершенно отличается от UDB. два года для субд - совсем ничего, 11g и на трети поддерживаемых ораклом платформ еще не выпущен, но вы можете расслабится, по секрету сообщу 11g уже никогда не появится на МФ. Оракл считает, что МФ умерло ...

...

Рейтинг:

0 / 0

17.02.2009, 19:11

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35825449

Favn

Гость

.Yo!гибкость и уникальность оракла в том, что АДБ имея опыт с 11g на своем лаптопе может пройти небольшой курс по особностям оракла на МФ и рулить ораклом 10g под МФ. у db2 же опыт администрирования не на МФ не поможет т.к. администрирование db2 под z/OS совершенно отличается от UDB.Стоимость обучения админа на фоне цены МФ + СУБД, мягко говоря, незначительна. Ну да речь не об этом.
.Yo!два года для субд - совсем ничего, 11g и на трети поддерживаемых ораклом платформ еще не выпущен, но вы можете расслабится, по секрету сообщу 11g уже никогда не появится на МФ. Оракл считает, что МФ умерло ...Да я, собственно, и не напрягался. Тем более, что наши выводы полностью совпали - как я и говорил, Оракл скорее всего не выпустит 11g под МФ. :)
Итог - по состоянию последних версий, DB2 LUW 9.5 живет на всех платформах, где есть 11g. Более того, LUW есть на Linux для IBM System p, System i и System z, где 11g нет. Теперь вспоминаем, с чего все началось:
Зл0йОракл по сути единственная гибкая СУБД где один и тот же код работает в самых разных конфигурациях, от самой маленькой до самой большой.Учитывая отсутствие Oracle 11g на System z, одна только DB2 LUW поддерживает даже чуть больше платформ с "одним и тем же кодом". Предлагаю излечиться от фанатизма :)
ЗЫ. И к чему тогда Ваше традиционное негодование по поводу "3-х разных" DB2, раз ареал 11g как раз совпадает с 9.5 LUW?

...

Рейтинг:

0 / 0

18.02.2009, 17:36

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35825733

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Favn1. Вы будете утверждать, что 10g и 11g - это один и тот же код? :) А DB2 for z/OS то же не сильно отличается от DB2 LUW, по крайней мере с точки зрения SQL.

10g и 11g это две версии одного и того же кода. Одна постарше, другая помоложе DB2 for z/OS и DB2 LUW это две разных СУБД, хотя и очень похожих друг на друга. Если посмотреть на DB2 для AS/400 то
это - третья СУБД.

Favn
2. Получается, что практически все поддерживаемые Oracle 11g платформы поддерживаются и DB2 LUW, "с одним и тем же кодом".

Не получается. У Оракла примерно 90-95% кода СУБД платформенно-независима. А 5-10% платформенно зависимый код, причем часть написана на ассемблере конкретного процессора. У DB2 на всех трех платформах совершенно разный код.

...

Рейтинг:

0 / 0

18.02.2009, 20:07

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35825856

побарабану кто круче

Гость

Офтопик конечно , но прикольно, относится
к любым сравнениям платных СУБД.

http://vid.org.ua/news.php?news=12215&razdel=5

Особенно подорвало:
автор
8. Не тушуйтесь. Если потребителю не нравится ваше говно, то он сам говно. Клиент всегда говно. Если вы уверенно назовете кучку говна инсталляцией (калькулятором, книжкой, чем угодно), два человека из сотни вам поверят. Ориентируйтесь на них, на остальных говна тоже хватит, но его продадите не вы.

А на бесплатное и пенять нечего, просто радуйтесь, что ничего не платите.

...

Рейтинг:

0 / 0

18.02.2009, 21:42

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35827010

Favn

Гость

Зл0й10g и 11g это две версии одного и того же кода. Одна постарше, другая помоложе DB2 for z/OS и DB2 LUW это две разных СУБД, хотя и очень похожих друг на друга. Если посмотреть на DB2 для AS/400 то это - третья СУБД.Не лечите разработчика, две версии одного кода - это багфикс. Если изменилась функциональность, а она изменилась - код похожий, но не тот же. Впочем, т.к. Оракл с z System похоже уходит - и говорить не о чем.

Зл0йFavn
2. Получается, что практически все поддерживаемые Oracle 11g платформы поддерживаются и DB2 LUW, "с одним и тем же кодом".Не получается. У Оракла примерно 90-95% кода СУБД платформенно-независима. А 5-10% платформенно зависимый код, причем часть написана на ассемблере конкретного процессора. У DB2 на всех трех платформах совершенно разный код.Еще раз, медленно - я писал о 11g , а она работает ровно там же , где и DB2 LUW , у которой тоже "90-95% кода СУБД платформенно-независима". Более того, LUW работает и под Linux на p Sytem, i System и z System, где 11g нет . Это не недостаток Оракл, но и никак не достоинство :)

ЗЫ. Оставьте, наконец, в покое DB2 for i (OS/400) - там Оракла нет и в помине. Кроме того, это уникальный случай интеграции полноценной Enterpise-level СУБД внутрь самой ОС - DB2 for i отдельно не покупается, идет "бесплатным приложением", как и куча другого софта. Естественно, что она немного отличается от DB2 LUW. И естественно, что других СУБД (кроме MySQL в том же комплекте для извращенцев :) ) там нет - ибо зачем? ;)

...

Рейтинг:

0 / 0

19.02.2009, 12:59

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35827117

Yo.!

Гость

FavnLUW есть на Linux для IBM System p, System i и System z, где 11g нет.
1. для начала db2 нужно хотя бы догнать 10g, потом уже посмотрим в сравнении 11g
2. в чем смысл запускать db2 на zLinux ? хотя я знаю ответ - db2 zOS сильно отстает от db2 LUW, но перформенс LUW в посуте эмуляторе Linux (zLinux) будет ниже плинтуса
3. тут уже пережевывали как оракл на дешевых писюках просто порвал system i + db2 с тем же кол-вом процев в тестах типа tpc-c
4. под AIX (system p) 11g уже выпустили.

...

Рейтинг:

0 / 0

19.02.2009, 13:23

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35828290

Favn

Гость

Yo.!1. для начала db2 нужно хотя бы догнать 10g, потом уже посмотрим в сравнении 11g
2. в чем смысл запускать db2 на zLinux ? хотя я знаю ответ - db2 zOS сильно отстает от db2 LUW, но перформенс LUW в посуте эмуляторе Linux (zLinux) будет ниже плинтуса
3. тут уже пережевывали как оракл на дешевых писюках просто порвал system i + db2 с тем же кол-вом процев в тестах типа tpc-c
4. под AIX (system p) 11g уже выпустили.1. В чем именно догонять-то? Впрочем, ладно, уже пережевывали, сейчас все равно речь идет об "ореале обитания".
2. Ответ неправильный - один из вариантов применения z System по IBM - конгломерат виртуальтных Linux-серверов, и это не эмуляция (хотя для x86 программ есть и она), а аппаратная виртуализация. Опять-таки, речь не об этом. Речь о том, что Oracle 10gR2 для z/Linux есть, а 11g - нет.
3. Я ему про Фому, он опять про Ерему - причем тут "порвал"? Я про "отдельную" DB2 под i System - нечего на нее ссылаться, раз никакого Оракл там нет.
4. Я в курсе. А Вы не в курсе, что p System может работать под Linux (дешевле выходит), а не под AIX (Linux on Power). И для этого варианта 10gR2 есть, а 11g нет, о чем я и писал.

Еще раз - я не говорил, что кто-то лучше или хуже. Я говорил, что "единый код под все платформы" - фича совсем не уникальная, вот и все.

...

Рейтинг:

0 / 0

19.02.2009, 19:05

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35832893

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Favn
2. Ответ неправильный - один из вариантов применения z System по IBM - конгломерат виртуальтных Linux-серверов, и это не эмуляция (хотя для x86 программ есть и она), а аппаратная виртуализация.

Программно-аппаратная если на то пошло, а не программная. Английский термин - Paravirtualization. Ближайший аналог на х86 платформе - VmWare.

Favn
Опять-таки, речь не об этом. Речь о том, что Oracle 10gR2 для z/Linux есть, а 11g - нет.
...
(Linux on Power). И для этого варианта 10gR2 есть, а 11g нет, о чем я и писал.

Вы в курсе как Оракл решает когда для какой платформы выйдет какая версия? По количеству лицензий на Оракл под данную платформу. Поэтому первыми выходят версии для более популярных платформ, а для менее популярных - последними. Просто команда тестировщиков Оракла не резиновая, а проверять на наличие платформенно-зависимых багов надо. 10g и 11g это тот же код и та же СУБД, только одна версия постарше а другая помоложе. Для экзотичных платформ 11g выйдет попозже, когда у Оракла дойдут руки его протестировать.

Favn
Еще раз - я не говорил, что кто-то лучше или хуже. Я говорил, что "единый код под все платформы" - фича совсем не уникальная, вот и все.
Назовите другую коммерческую СУБД у которой один и тот же codebase работает на мэйнфрейме и на LUW. Заодно назовите другую коммерческую СУБД которая при том же коде может поддерживать хранилище данных терабайт этак на 400 и high-end OLTP систему. Тогда поговорим.

...

Рейтинг:

0 / 0

23.02.2009, 19:52

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35834922

Favn

Гость

Зл0йПрограммно-аппаратная если на то пошло, а не программная. Английский термин - Paravirtualization. Ближайший аналог на х86 платформе - VmWare.Большое спасибо за ценную информацию :) Позвольте напомнить, что сначала Вы говорили об эмуляции, а это совсем не то же самое. Кстати, Вы можете привести пример чисто аппаратной виртуализации, без поддержки ОС? ;) Если нет - поправка выглядит странно.
Кстати, x86 виртуализация на z/Linux похожа не очень, т.к. там аппаратная поддержка куда шире поддержки на уровне процессора в x86.

Зл0йПросто команда тестировщиков Оракла не резиновая, а проверять на наличие платформенно-зависимых багов надо. 10g и 11g это тот же код и та же СУБД, только одна версия постарше а другая помоложе. Для экзотичных платформ 11g выйдет попозже, когда у Оракла дойдут руки его протестировать.Мы с Yo! тут пришли к выводу, что такими темпами похоже не дойдут - уже почти 3 года прошло, воз и ныне там, а тестировщикам пора браться за 11gR2. :)

Зл0й1. Назовите другую коммерческую СУБД у которой один и тот же codebase работает на мэйнфрейме и на LUW.
2. Заодно назовите другую коммерческую СУБД которая при том же коде может поддерживать хранилище данных терабайт этак на 400 и high-end OLTP систему.
3. Тогда поговорим.1. Формально - пожалуйста, DB2 LUW работает на z/Linux на мейнфрейме. Насколько я помню, есть вариант лицензирования z Series без z/OS, только с z/Linux. Не формально - нового Oracle там тоже нет. В любом случае, выставлять работу предыдущей версии на "экзотической" платформе как мощное преимущество - с Ваших позиций странно.
2. Тестов на 400Tb нет, но на "жалкие" 10Tb - пожалуйста, вот тут . Или Вы можете назвать причину, по которой DB2 LUW Warehouse не сможет работать с 400Tb, а Oracle - сможет? Если да - назовите. Кроме той очевидной, что DB2 - не Oracle :) Кстати, в какой задаче может понадобится OLAP по БД в 400Tb реляционных данных?
По OLTP - тоже пожалуйста. Результат выглядит неплохо ;)
Я понимаю, что tpc - не показатель лидерства, но уж точно - показатель работоспособности.
3. Если Вы будете продолжать говорить об "уникальной многоплатформенности" Oracle без серьезной аргументации - то уже поговорили. Еще раз - я не говорю, что Oracle плох. Хорош. Но не уникален, имхо есть не хуже.

...

Рейтинг:

0 / 0

24.02.2009, 18:06

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35834993

Yo.!

Гость

говорить, что LUW работает под zLinux это примерно то же самое, что радоватся ораклу под вмваре. что толку от такой субд если они и десятой части фич zOS (в том числе ключевых) не может использовать ? для разработки или тестирования разве что.
фича оракла в том, что он практически весь написан на С (ядро субд, не путать с обвязкой вокруг), поэтому собрать его на том же редхате для МФ не проблема, проблема в платформе МФ, она померла в 80х и поддерживать софт под эту платформу теперь интересно только ибм.
а вообще почитайте, что было сделано ораклом для интеграции с zOS и задумайтесь как блекло в этом плане выглядит LUW. может тогда поймете почему ибм под zOS приходится тянуть отдельную субд.

...

Рейтинг:

0 / 0

24.02.2009, 18:27

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35835232

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

FavnЗл0йПрограммно-аппаратная если на то пошло, а не программная. Английский термин - Paravirtualization. Ближайший аналог на х86 платформе - VmWare.Большое спасибо за ценную информацию :) Позвольте напомнить, что сначала Вы говорили об эмуляции, а это совсем не то же самое. Кстати, Вы можете привести пример чисто аппаратной виртуализации, без поддержки ОС? ;) Если нет - поправка выглядит странно.
Кстати, x86 виртуализация на z/Linux похожа не очень, т.к. там аппаратная поддержка куда шире поддержки на уровне процессора в x86.

про эмуляцию говорил не я, а участник конференции под ником Yo1; что касается виртуализации, то x86 архитектура бывает разная. С virtualization extensions (Intel VT, AMD-V) она позволяет аппаратную виртуализацию. Пример hardware-assisted виртуализации без поддержки ОС - Windows XP работающий из-под Xen 3.0 и ни сном ни духом не подозревающий что он виртуализирован.

Favn
Зл0йПросто команда тестировщиков Оракла не резиновая, а проверять на наличие платформенно-зависимых багов надо. 10g и 11g это тот же код и та же СУБД, только одна версия постарше а другая помоложе. Для экзотичных платформ 11g выйдет попозже, когда у Оракла дойдут руки его протестировать.Мы с Yo! тут пришли к выводу, что такими темпами похоже не дойдут - уже почти 3 года прошло, воз и ныне там, а тестировщикам пора браться за 11gR2. :)

Значит нет достаточного количества клиентов на данной платформе. Вопрос тут не технического свойства а "про бабки".

Favn
Зл0й1. Назовите другую коммерческую СУБД у которой один и тот же codebase работает на мэйнфрейме и на LUW.
2. Заодно назовите другую коммерческую СУБД которая при том же коде может поддерживать хранилище данных терабайт этак на 400 и high-end OLTP систему.
3. Тогда поговорим.1. Формально - пожалуйста, DB2 LUW работает на z/Linux на мейнфрейме. Насколько я помню, есть вариант лицензирования z Series без z/OS, только с z/Linux. Не формально - нового Oracle там тоже нет. В любом случае, выставлять работу предыдущей версии на "экзотической" платформе как мощное преимущество - с Ваших позиций странно.
2. Тестов на 400Tb нет, но на "жалкие" 10Tb - пожалуйста, вот тут .

Не смешите мои тапки, 10 терабайт в наше время это не хранилище данных а Data Mart.

Favn
Или Вы можете назвать причину, по которой DB2 LUW Warehouse не сможет работать с 400Tb, а Oracle - сможет? Если да - назовите. Кроме той очевидной, что DB2 - не Oracle :) Кстати, в какой задаче может понадобится OLAP по БД в 400Tb реляционных данных?
По OLTP - тоже пожалуйста. Результат выглядит неплохо ;)
Я понимаю, что tpc - не показатель лидерства, но уж точно - показатель работоспособности.
3. Если Вы будете продолжать говорить об "уникальной многоплатформенности" Oracle без серьезной аргументации - то уже поговорили. Еще раз - я не говорю, что Oracle плох. Хорош. Но не уникален, имхо есть не хуже.
Причин почему - вагон. Задач на пол-петабайта тоже. Правда делаются они вручную через map-reduce и ему подобные штуки, потому что лицензия на СУБД получается очень кусачая. Я лично на Оракле строил хранилище на четверть петабайта несколько лет тому назад. Сейчас с Exadata построить пол-петабайта или даже петабайт - чисто вопрос бюждета. Неразрешимых технических проблем нет.

...

Рейтинг:

0 / 0

24.02.2009, 21:01

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35835358

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

прибавлю немного оффтопа :)

пару строчек из истории:

http://en.wikipedia.org/wiki/Informix

1996 and 1997: Internal Problems

Although Informix took a technological lead in the database software market, product releases began to fall behind schedule by late 1996. Plagued with technical and marketing problems, a new application development product, Informix-NewEra, was soon overshadowed by the emerging Java programming language. Michael Stonebraker had promised that the Illustra technology would be integrated within a year after the late 1995 acquisition, but as Gartner Group had predicted, the integration required more than 2 years. Unhappy with the new direction of the company, XPS lead architect Gary Kelley suddenly resigned and joined arch-rival Oracle Corporation in early 1997, taking 11 of his developers with him. [1] Informix ultimately sued Oracle to prevent loss of trade secrets.

Так что, то что раньше называлось Oracle Parallel Server оказывается пришло из Informix гуру

хотя вроде читал про все это вот здесь The Real Story of Informix Software and Phil White: Lessons in Business and Leadership for the Executive Team (Hardcover)
(достаточно интересная книга показалась)

...

Рейтинг:

0 / 0

24.02.2009, 22:57

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35835425

Yo.!

Гость

herr
Так что, то что раньше называлось Oracle Parallel Server оказывается пришло из Informix гуру

с учетом того где сейчас XPS и уже во всю работающему OPS на 1997 год, то выглядит что XPS был настолько безнадежная технология, что даже его лид архитек признал крутизну конкурента.

...

Рейтинг:

0 / 0

24.02.2009, 23:55

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35835517

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herrприбавлю немного оффтопа :)
Так что, то что раньше называлось Oracle Parallel Server оказывается пришло из Informix гуру

Не надо сказки рассказывать, Oracle Parallel Server был в 6.2 версии Оракла которая вышла аж в 1989 году. Упомянутый гуру сбежал из Информикса в Оракл восемь лет спустя.

...

Рейтинг:

0 / 0

25.02.2009, 01:42

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35837603

Relic Hunter

Участник

Откуда: AB

Сообщения: 7 268

Рейтинг: 0 / 0

Зл0й,

А через 4-ре года, в 2001, Оракл выпускает RAC на замену OPS. Удивительное совпадение?

...

Рейтинг:

0 / 0

25.02.2009, 18:51

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35837624

Зайцев Фёдор

Участник

Откуда: Лужки

Сообщения: 5 437

Рейтинг: 0 / 0

Relic Hunterчерез 4-ре
1-дин
2-ва
3-ри
4-ре
5-ть
6-сть
...
11-адцать
...

...

Рейтинг:

0 / 0

25.02.2009, 18:58

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35837642

Yo.!

Гость

Relic Hunter
А через 4-ре года, в 2001, Оракл выпускает RAC на замену OPS. Удивительное совпадение?
а чего удивительного вы там обнаружили ? сменилось лишь название, теперь между прочим это не RAC, a Grid. или вы обнаружили, что-то хоть немного схожее между shared-nothing XPS и OPS/RAC/Grid ?? по мне так отрисовка спрайтов doom2 с двигателем внутреннего сгорания имеют больше схожего, чем эти две технологии ...

...

Рейтинг:

0 / 0

25.02.2009, 19:06

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35837889

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Не надо сказки рассказывать, Oracle Parallel Server был в 6.2 версии Оракла которая вышла аж в 1989 году. Упомянутый гуру сбежал из Информикса в Оракл восемь лет спустя.
Кстати, а где это работало (если работало)? под каким-то VAXом?
А упомянутый товарищь действительно гуру, он вроде до Informix в Tanden трудился.
Недумаю, что в Oracle штаны протирал, как минимум поведал о всех "болячках" XPS... :)

Yo.!
сменилось лишь название, теперь между прочим это не RAC, a Grid.
Вы запутались в маркетинговых словосочетаниях!

...

Рейтинг:

0 / 0

25.02.2009, 21:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35838049

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

herrЗл0й
Не надо сказки рассказывать, Oracle Parallel Server был в 6.2 версии Оракла которая вышла аж в 1989 году. Упомянутый гуру сбежал из Информикса в Оракл восемь лет спустя.
Кстати, а где это работало (если работало)? под каким-то VAXом?

Началось на DEC Vax cluster. Причем работал он абсолютно реально. Бюрлесоновские писания можете смело игнорировать, если он не использовал 6.2 OPS это не значит что его не использовал никто. По мере появления других подходящих платформ OPS переползал на них. В семерке он на чем только не работал.

herr
А упомянутый товарищь действительно гуру, он вроде до Informix в Tanden трудился.
Недумаю, что в Oracle штаны протирал, как минимум поведал о всех "болячках" XPS... :)

Tandem а не Tanden. Никто не умаляет заслуг г-на Келли, но OPS у оракла появился задолго до его побега из Информикса. Архитектурно XPS и OPS/RAC - разные системы.

herr
Yo.!
сменилось лишь название, теперь между прочим это не RAC, a Grid.
Вы запутались в маркетинговых словосочетаниях!

На самом деле, в 6.2 и 7 был OPS в "чистом виде" с block pinging. В 8i была некая промежуточная реализация, которая использовала и block pinging и cache fusion. А начиная с 9i уже один cache fusion безо всякого block pinging. А какую терминологию и когда к этому прикрутили маркетроиды несущественно.

...

Рейтинг:

0 / 0

26.02.2009, 00:13

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843357

Favn

Гость

Зл0йпро эмуляцию говорил не я, а участник конференции под ником Yo1; что касается виртуализации, то x86 архитектура бывает разная. С virtualization extensions (Intel VT, AMD-V) она позволяет аппаратную виртуализацию. Пример hardware-assisted виртуализации без поддержки ОС - Windows XP работающий из-под Xen 3.0 и ни сном ни духом не подозревающий что он виртуализирован.Про эмуляцию - прошу прощения, перепутал. Про hardware-assisted - Xen и т.д. все равно работают на базовой ОС (или на своей внутренней), x86 проц выполняет только небольшую часть работы. А для hardware-assisted виртуализации в более широком смысле у x86 hardware не заточен.

Зл0йЗначит нет достаточного количества клиентов на данной платформе. Вопрос тут не технического свойства а "про бабки".Какая разница? Тут или есть, или нет и похоже не будет, почему - вопрос вторичный.

Зл0й10 терабайт в наше время это не хранилище данных а Data Mart.Как не назови, это показатель того, что может не хуже Оракл. Просто на бОльшие объемы сравнительных тестов нет.

Зл0йFavnИли Вы можете назвать причину, по которой DB2 LUW Warehouse не сможет работать с 400Tb, а Oracle - сможет? Причин почему - вагон. Задач на пол-петабайта тоже. Неразрешимых технических проблем нет.Вагон - аргумент конечно большой, но слабый. По поводу технических проблем - полностью согласен, и справедливо это для любой enterprise level СУБД.

Позволю себе резюме "содержательной" беседы - список поддерживаемых текущими версиями DB2 и Oracle платформ фактически совпадает, безотносительно причин этого.

...

Рейтинг:

0 / 0

27.02.2009, 19:47

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843370

Favn

Гость

Yo.!говорить, что LUW работает под zLinux это примерно то же самое, что радоватся ораклу под вмваре. что толку от такой субд если они и десятой части фич zOS (в том числе ключевых) не может использовать?Повторю - z Series может работать просто как куча Linux серверов. Или Oracle зря делала 10gR2 для z/Linux?
Yo.!фича оракла в том, что он практически весь написан на С (ядро субд, не путать с обвязкой вокруг), поэтому собрать его на том же редхате для МФ не проблема, проблема в платформе МФ, она померла в 80х и поддерживать софт под эту платформу теперь интересно только ибм.Вот уж, действительно, уникальная фича! А DB2, значит, написана на Cobol с PL/1 пополам! :) Или - вся на ассемблере, так, в порядке мазохизма.
Yo.!а вообще почитайте, что было сделано ораклом для интеграции с zOS и задумайтесь как блекло в этом плане выглядит LUW. может тогда поймете почему ибм под zOS приходится тянуть отдельную субд.Вы, пожалуйста, таки определитесь - пациент скорее мертв или пациент скорее жив. Если МФ мертв - наличие на нем предыдущего Оракл роли не играет. А если присутствие на z/OS - ключевое преимущество, то куды дели 11g на нем? ;)
Еще раз - в любом случае, без исторических экскурсов, на данный момент Oracle и DB2 LUW живут практически на одних и тех же платформах

...

Рейтинг:

0 / 0

27.02.2009, 19:57

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843501

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

FavnЗл0йпро эмуляцию говорил не я, а участник конференции под ником Yo1; что касается виртуализации, то x86 архитектура бывает разная. С virtualization extensions (Intel VT, AMD-V) она позволяет аппаратную виртуализацию. Пример hardware-assisted виртуализации без поддержки ОС - Windows XP работающий из-под Xen 3.0 и ни сном ни духом не подозревающий что он виртуализирован.Про эмуляцию - прошу прощения, перепутал. Про hardware-assisted - Xen и т.д. все равно работают на базовой ОС (или на своей внутренней), x86 проц выполняет только небольшую часть работы. А для hardware-assisted виртуализации в более широком смысле у x86 hardware не заточен.

C Intel VT, AMD-V заточен. Принципиальный момент в том, что ОС и остальной софт исполняемый на виртуальной машине даже не подозревает об этом.

Favn
Зл0й10 терабайт в наше время это не хранилище данных а Data Mart.Как не назови, это показатель того, что может не хуже Оракл. Просто на бОльшие объемы сравнительных тестов нет.

Может, но хуже и дороже. Расписывать почему мне некогда, да и лень. Огромных хранилищ на DB2 LUW не строят. На Oracle есть, на Teradata есть, на DB2 EEE есть, а на DB2 LUW - нет.

Favn
Зл0йFavnИли Вы можете назвать причину, по которой DB2 LUW Warehouse не сможет работать с 400Tb, а Oracle - сможет? Причин почему - вагон. Задач на пол-петабайта тоже. Неразрешимых технических проблем нет.Вагон - аргумент конечно большой, но слабый. По поводу технических проблем - полностью согласен, и справедливо это для любой enterprise level СУБД.

Я могу назвать навалом таких причин. Начну с того что заткнется и начнеть тормозить Data Dictionary который никто и никогда не оптимизировал под такие объемы информации. Оракл эту болячку тоже проходил, лет 5 тому назад.

Favn
Позволю себе резюме "содержательной" беседы - список поддерживаемых текущими версиями DB2 и Oracle платформ фактически совпадает, безотносительно причин этого.
Позвлю вам не позволить. Текущая версия берется для данной конкретной платформы, "список поддерживаемых текущими версиями ... платформ" - терминологический нонсенс.

...

Рейтинг:

0 / 0

27.02.2009, 22:03

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843621

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

offtop:

Зл0й
Огромных хранилищ на DB2 LUW не строят. На Oracle есть, на Teradata есть, на DB2 EEE есть, а на DB2 LUW - нет.

дайте ссылку, почитаем вместе что есть DB2 EEE и когда оно было...

p.s.
по поводу z/OS - зачем Oracle поддерживать, если есть exadata :)

...

Рейтинг:

0 / 0

28.02.2009, 01:40

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843622

herr

Участник

Сообщения: 174

Рейтинг: 0 / 0

Зл0й
Архитектурно XPS и OPS/RAC - разные системы.

никто вроде и не утверждал что это одно и тоже.
но ифлуенц на OPS/RAC, несомненно был сделан от вышеупомянутого товарища ;)

...

Рейтинг:

0 / 0

28.02.2009, 01:43

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843939

db2man

Гость

Зл0й
Огромных хранилищ на DB2 LUW не строят.

Еще как строят
Зл0й
На Oracle есть, на Teradata есть, на DB2 EEE есть, а на DB2 LUW - нет.

Вас послушать, так DB2/LUW и DB2/LUW+DPF(EEE) есть какие-то разные СУБД, хотя второе всего лишь фича для первого. Кому надо - юзают, кому не надо - нет.

Никому нормальному не придет в голову парится с масштабированием многотеррабайтного варехауза на single partition database, когда есть эффективный механизм распареллеливания оного "из коробки" хоть и за дополнительные деньги.
Oracle такого механизма не имел (и помнится на этом же форуме несколько лет назад некоторые утверждали, что и не надо вообще), потому развивал (и весьма удачно) свой table partitioning, что позволяло неплохо масштабировать DWH на SMP (до определенного предела), однако время все рассудило и показало, что единственная реально масштабируемая архитектура для таких задач - это shared nothing. В результате, чтоб угнаться за "отстающими иноверцами" придумали свою database machine + exadata, но, видимо, поздно, ибо в этой нише уже вовсю начинают "править бал" всевозможные гринплумы, парацелли и прочие вертики.

...

Рейтинг:

0 / 0

28.02.2009, 15:57

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843953

Favn

Гость

Зл0йC Intel VT, AMD-V заточен. Принципиальный момент в том, что ОС и остальной софт исполняемый на виртуальной машине даже не подозревает об этом.Нда, спасибо за "самое сокровенное знание". Еще раз - аппаратная поддержка виртуализации в "больших" серверах IBM куда шире, чем несколько команд процессора. Но речь сейчас не об этом, оставим ее в покое.
Зл0йМожет, но хуже и дороже. Расписывать почему мне некогда, да и лень. Огромных хранилищ на DB2 LUW не строят. На Oracle есть, на Teradata есть, на DB2 EEE есть, а на DB2 LUW - нет.сравнительных тестов нет.Очаровательно! А DB2 EEE - это не LUW по-вашему? Посмотрите вот тут , строка Database Partitioning. На минуточку, EEE (extended enterprise edition) раньше называлась Database Partitioning Feature, платное дополнение к DB2 LUW EE (enterprise edition). С версии 9.5 этот функционал включили в InfoSphere Warehouse, варианты которой докупаются к DB2 LUW EE, так же как Data Warehousing Options докупаются к Oracle Enetrprise.
Итого - мы пришли к согласию, что на DB2 EEE, являющейся топ-версией DB2 LUW, таки "строят огромные хранилища". По поводу хуже-дороже / лучше-дешевле - говорить не будем, ибо бездоказательно. А вот факт - зафиксируем.
Зл0йЯ могу назвать навалом таких причин. Начну с того что заткнется и начнет тормозить Data Dictionary который никто и никогда не оптимизировал под такие объемы информации. Оракл эту болячку тоже проходил, лет 5 тому назад.А можно ссылочку - с чего Вы решили, что DB2 Warehouse, он же EEE, не оптимизирован "под такие объемы"? Где описан подобный негативный опыт? Или опять-таки DB2 не смог "пройти эту болячку" только потому, что он - не Oracle? :)

Вспомним еще раз:
Зл0йЗаодно назовите другую коммерческую СУБД которая при том же коде может поддерживать хранилище данных терабайт этак на 400 и high-end OLTP систему. Тогда поговорим.Назвали - DB2 LUW. И даже Вы уже согласны, что может.

...

Рейтинг:

0 / 0

28.02.2009, 16:08

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35843971

Favn

Гость

Зл0йПозвлю вам не позволить. Текущая версия берется для данной конкретной платформы, "список поддерживаемых текущими версиями ... платформ" - терминологический нонсенс.Позволю, конечно - не позволяйте, сколько Вам угодно. Правда, разработчики программ, использующие новые фичи 11g, с Вами не согласятся - им-то пофиг платформа, им аналогичный функционал на всех платформах подавай. Ну да ладно, будем считать и 10g.
Простое сравнение покажет, что DB2 LUW нет только на z/OS, Fujitsu Siemens BS2000/OSD и старых платформах от HP типа Alpha и PA-RISC (на Itanium - есть). Причем все они, кроме z Series, мертвы даже по мнению их производителей . Остается только z/OS. Оставим даже в стороне тот факт, что если не по администрированию, то по разработке программ DB2 z/OS очень близка к DB2 LUW - думаю, не многим дальше, чем от 10g до 11g ;)
По Вашим с Yo! словам получается, что единственное, основное преимущество Oracle перед DB2 LUW по платформам - поддержка "экзотической, старой, мертвой, экономически не выгодной" z/OS. Исходя из этих Ваших же эпитетов делаю логичный вывод - поддержкой такой "гадости", с Вашей точки зрения, можно и должно пренебречь (что Oracle в 11g и сделала).
Итог - DB2 LUW работает на тех же платформах, что и Oracle, и здесь никакого преимущества нет.

...

Рейтинг:

0 / 0

28.02.2009, 16:24

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35847307

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

Елки-моталки, неужели нужно простые вещи растолковывать про DB2? DB2 EEE - это СУБД shared-nothing архитектуры работающая на кластерах массивно-параллельных железяк, а DB2 LUV - это обычный UDB. Взрослые хранилища строят только на EEE потому что в другой конфигурации DB2 их не тянет.

...

Рейтинг:

0 / 0

03.03.2009, 02:51

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35847655

db2man

Гость

Зл0йЕлки-моталки, неужели нужно простые вещи растолковывать про DB2?
Ну если только самому себе, чтобы разобраться наконец-таки в терминологии.

Зл0й
DB2 EEE - это СУБД shared-nothing архитектуры работающая на кластерах массивно-параллельных железяк, а DB2 LUV - это обычный UDB. Взрослые хранилища строят только на EEE потому что в другой конфигурации DB2 их не тянет.

Еще раз (и последний раз) повторяю : DB2/LUW это ОДНА СУБД, из коробки умеющая делать как single partition database так и multiple partition database (хоть physical partitions на shared nothing кластере, хоть logical partitions на SMP)

И по аналогии (не для холивара) :

"Oracle RAC - это СУБД shared disk архитектуры, работающая на кластерах, а Oracle Database - это .....обычная Oracle Database. Взрослые OLTP-системы строят только на Oracle RAC, потому что в другой конфигурации Oracle Database их не тянет"

...

Рейтинг:

0 / 0

03.03.2009, 10:43

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35849647

Зл0й

Участник

Откуда: Северная Калифорния

Сообщения: 632

Рейтинг: 0 / 0

db2man
И по аналогии (не для холивара) :

"Oracle RAC - это СУБД shared disk архитектуры, работающая на кластерах, а Oracle Database - это .....обычная Oracle Database. Взрослые OLTP-системы строят только на Oracle RAC, потому что в другой конфигурации Oracle Database их не тянет"

Вот тут как раз вы и не правы, потому что Oracle масштабируется вверх на SMP безо всякого RAC пока позволяет железяка. Есть большие хранилища на single-instance Oracle database. Аналогичных размеров хранилища на DB2 LUW встречаются только на EEE. Доступно излагаю?

...

Рейтинг:

0 / 0

04.03.2009, 02:48

| Ответить | Цитировать | Написать

Informix displaces Oracle at China Telcom

#35851120

db2man

Гость

Зл0й
Вот тут как раз вы и не правы, потому что Oracle масштабируется вверх на SMP безо всякого RAC пока позволяет железяка.

Это была всего лишь ирония по поводу некорректных сравнений. О том, что Oracle хорошо масштабируется в OLTP на SMP я прекрасно знаю.

Зл0й
Есть большие хранилища на single-instance Oracle database. Аналогичных размеров хранилища на DB2 LUW встречаются только на EEE. Доступно излагаю?

Излагаете доступно, сравниваете некорректно.
Скажите, много ли тех самых многотеррабайтных single-instance Oracle DWH НЕ используют фичу партишонинга ? Если такие найдутся (что сомнительно), то вот только ИХ и корректно сравнивать с DB2/LUW БЕЗ опции DPF/EEE.

Резюмируя :

Обе СУБД имеют опцию для партицирования

Oracle - вертикальное партицирование, с ограничением масштабирования на SMP.
DB2 - горизонтальное партицирование на SMP или MPP c практически неограниченным масштабированием (особенно в миксе с фичами MDC и table range partitioning)

Без этих фич партицирования ни в той, ни в другой СУБД хранилища не делают

...

Рейтинг:

0 / 0

04.03.2009, 15:31

| Ответить | Цитировать | Написать

203 сообщений из 203, показаны все 9 страниц

все

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix displaces Oracle at China Telcom

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=35&tid=1552984]:	0ms
get settings:	10ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	47ms
get topic data:	11ms
get forum data:	2ms
get page messages:	176ms
get tp. blocked users:	2ms
others:	12ms

total:	282ms