Alexander Ryndin...расскажите как работает SDS...
А Yo.! расскажет как работает RAC.
Нам всем будет полезно узнать новое.
Ну и для завтравки вот такие вопросы:
1) Является ли решение active-active?
2) Что происходит, если данные изменились на одном узле и еще не были сброшены из кэша на диск и кто-то пытается изменить эти же данные на другом узле?
3) Потребуется ли от администратора какие-то действия при смерти одного узла?


Данный топик появился в результате обсуждения другой темы:
ASA vs MS SQL 2008R2 vs Oracle 11G

Alexander Ryndin...расскажите как работает SDS...
А Yo.! расскажет как работает RAC.
Нам всем будет полезно узнать новое.


Предложение звучит логично, согласится ли "Yo.!"? :)

Считаю, что "рассказывать" есть смысл в таких случаях:
1) если нет документации . Не наш случай, ссылки приводил, могу привести ещё раз.

2) если не знаю где искать или не нашёл в документации . Бывает. В таких случаях иногда человеку можно и помочь.

3) если непонятна документация . В таких случаях задают конкретные вопросы.

4) если есть знания помимо документации, которые документацию дополняют, либо опровергают . Тут уж, кто на что горазд :)

5) если делается аналитическое сравнение . А вот это оно.

Вот 5-ый вариант можно подготовить с участием специалистов с обеих сторон баррикады :).

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

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

Alexander RyndinНу и для завтравки вот такие вопросы:
1) Является ли решение active-active?

1) вопрос "Является ли решение active-active?" может иметь прозрачный смысл для ораклоида ( и то не всегда ), и я в данном случае прошу уточнить, что вы вкладываете в это понятие...

Alexander Ryndin2) Что происходит, если данные изменились на одном узле и еще не были сброшены из кэша на диск и кто-то пытается изменить эти же данные на другом узле?

Что Вас интересует: поведение системы с внешней точки зрения (пользователя) или подробное описание того, как сервер будет обрабатывать данную ситуацию с техническими подробностями?
Alexander Ryndin3) Потребуется ли от администратора какие-то действия при смерти одного узла?

Маркетолог мог бы ответить: "Нет, конечно" .
Я контрольно переспрошу: действия для чего? Сохранится ли без вмешательства админа работоспособность кластера и возможность работы с кластером для клиентов? Connection Manager позволяет настроить правила автоматического определения "смертей" и автоматического восстановления работоспособности кластера.

Вы про это хотели услышать? А что вы можете рассказать про Оракл?

Для примера прообраз того, что будет в блоге:

Сравниваемые характеристики/Кластер СУБД Informix SDS (IDS 11.70) Oracle RAC ( ? )1. Функциональность вторичных серверов1.1. Клиенты могут выполнять запросы на изменение данных на всех серверах Да с ограничениями ???...2. Автоматическое реагирование на сбои узла в системе2.1. Перенаправление клиентов на рабочий узел Да ???2.2. Восстановление (перезапуск узла) и включение его в кластер ??? ???
Термины:
Т1. Кластер - взаимодействующий набор серверов, созданный с целью повышения отказоустойчивости и масштабируемости решения.

Т2. primary = первичный
Один из узлов кластера, координирующий изменения данных в БД (единственный на момент времени)

Т3. secondary = вторичный
Дополнительные узлы кластера, за счёт ресурсов которых повышается отказоустойчивость и масштабируемость кластера.

Литература:
L1. Informix Dynamic Server 11: Extending Availability and Replication
L2. IBM Informix Flexible Grid: Extending Data Availability
L3. Informix 11.70 Admin's Guide. Shared Disks Secondary Servers

Yo.!АнатоЛой, имхо вам стоит сначала завести ветку в информикс разделе, что бы вам рассказали или так сказать пережували то, что говориться в документации по SDS.

Спасибо, "зубы" на месте, жевать умею, чуть-чуть осталось :).

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


Для меня это пока лишь ваши выводы - "верхний уровень".
На выходных дожую доку - отпишусь :)

И ещё, кто-то предлагает по всей "реальной жизни" и для "всех реальных" систем поменять Oracle на Informix? Dbf-ы живут до сих пор со своими "грехами", Access живёт со своими.
Ну просто непонятно, как реализовывали банковские системы времён dbf без уровня Serializable?! По-моему, вы просто размеры печалек преувеличиваете...

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

"блокировки оракл хранит в блоках данных"
Oracle RAC "платит" за это снижением быстродействия при наложении блокировок по сравнению с вариантом "храним блокировки в оперативной памяти"? Или я неправильно понял выделенное жирным?

Yo.!SDS блокировки не умеет синхронизировать и соответственно SDS ноды понятия не имеют о том, что соседние ноды модифицируют данные. отсюда и растут ноги на ограничения по уровням изолированности и невозможность обеспечить да нормальный Read Committed (предлагая взамен "хер знает когда но когда-то Committed")


да, у него реализация другая:

The Updatable Secondary server provides an automatic transfer from the
Secondary to the Primary node when an update operation is to be performed.
This is done without taking a distributed lock on the row at the Secondary and the
Primary. Instead, the Primary server uses a form of optimistic concurrency . This
means that the Primary server will consider the update operation only if the
before image is identical between the Primary and the Secondary server. If it is
not, then the server will consider the operation as having encountered a
deadlock type of error and abort the operation.
Это что-ли, вселенская печаль?

londiniumавторЭтот момент просьба осветить в сравнительной характеристеке более подробно
И чего там освещать? Сказано - "валите на меня как на мертвого, я за все отвечаю", значит, так и есть, гарантирует.

И коллеги, пожалуйста, расскажите о задачах, где без RAC/SDS жить нельзя
Какие задачи ? Главное, что "RAC пригоден для транзакционных систем , не то что SDS"... .
Если серьёзно: жить без него можно - ибо жили же до того, как они появились. Вопрос в том, что может дать или уже кому-то даёт (пятничные мысли:) неоспоримые преимущества по сравнению с другими решениями. Я сейчас и пытаюсь добраться до сути, мешают ли мне наличие/отсутствие "шашечек" собственно ехать...
Кстати, есть очень интересная статья на эту тему.

londiniumИ коллеги, пожалуйста, расскажите о задачах, где без RAC/SDS жить нельзя

Если совсем серьёзно:

Пример задачи :
Есть готовая и работающая система на Oracle/Informix.
Бизнес достаточно резко вырос в охвате (удачные инвестиции и "перестаравшиеся" маркетологи).
Вопрос : как с наименьшими затратами выросшую нагрузку на сервера (тупо объём траффика/транзакций прыгнул за год в 3 раза) таки обработать.

Вот тут и появляются варианты , среди которых и RAC/SDS.
А так чтобы жить нельзя... Это к Yo!, наверное...

кракПо табличке в 11816843 по всем пунктам для рак - да.
Не принимается. Я не зря писал - "формируем корректные ответы (со ссылками на источник)"...

Alexander RyndinДохтаРYo!, тебе снова наступили на больную. мозоль ?
пропущено...

Этот момент просьба осветить в сравнительной характеристеке более подробно
Какие уровни изолированности транзакций где присутствуют и где отсутствуют и что в какой системе точнее гарантируются
)ДохтаР, вы повторяетесь.

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

Ключевым отличием Oracle RAC от остальных кластеров является то, что уровень сервиса для одноузловой конфигурации и многоузловой одинаков - одна и та же транзакционность, одни и те же уровни изолированности, одна и та же надежность (только выше).
Alexander Ryndin, пожалуйста, давайте обсуждать на техническом форуме технические детали. А особенно в этой ветке.
Отвечая маркетинговой пропагандой на вопрос техническому специалисту, готовьтесь к встречным вопросам :).
"Огромное количество банков", "вполне устраивают", а особенно то, что все они "официально считают наилучшей системой" - это просто сногсшибательные аргументы в нашем сравнении .
Вы действительно видите данные характеристики в затеянном мною сравнении?
Вы действительно готовы предоставить ссылки на статистику по озвученным показателям?
Если Вам неитересны "академические измышления" - никто не принуждает Вас их обсуждать...

Yo.!как видите оракл отмасштабировался практически ровно в 2 раза ...

Искреннее спасибо, цифры интересные.
Но в этих ссылках сравнивается DB2 на однопроцессорном Win и Oracle RAC на 2-х процессорном Nix.
С тем же успехом я могу утверждать, что Win съел все преимущества блокировочника DB2 :). Ах, если бы сапёры устраивали сравнение "при прочих равных"... Но им то ли такие сравнения настолько дорого проводить, то ли для бизнеса слишком дорого выкладывать результаты в общий доступ :).

Alexander RyndinМоя фраза относилась к флейму ДохтаРа о том, что Oracle не поддерживает различные уровни изоляции.

1. Перечитайте пост ДохтарА ещё раз.
Имхо, в его фразе нет утверждения "о том, что Oracle не поддерживает различные уровни изоляции".
Имхо, он честно попросил подробностей :).
2. "Мой аргумент состоит именно в том, что большинство клиентов Oracle он устраивает."
Именно в этом мои претензии и состояли: как ваш аргумент логично связан с техническим вопросом от ДохторА?
Что именно "клиентов устраивает"? Степень поддержки уровней изоляции? Вы серьёзно? Этот технический вопрос всплывал хоть при одном принятии решения клиентами Oracle? Вы можете это подтвердить ссылками?


Alexander Ryndin
АнатоЛойВы действительно готовы предоставить ссылки на статистику по озвученным показателям?
Статистика у меня есть. 10 из 10 крупнейших банков мира используют Oracle.
Опять печалька. 1) Где ссылка? 2) "Используют Oracle" <> "Эти же банки не используют Informix, DB2, PostgreSQL, ...".

Alexande Ryndinя сошлюсь на независимых авторов ...
Спасибо, ссылки мне уже попадались.

Yo.!блокировочник дб2 на винде быстрее чем на линуксе
Спасибо, а то у меня терпения не хватает в этом объёме шарится.
Жалко что не нашлось Oracle без RAC на тех же условиях, что и DB2.
Итого, вывод зафиксирован: тесты на SAP приложениях показали, что версионник Oracle RAC отлично масштабируется и несколько уделывает блокировочник DB2. Жалко, что некуда этот вывод в нашу таблицу вставить...

Alexander RyndinАнатоЛойпропущено...
Опять печалька. 1) Где ссылка? 2) "Используют Oracle" <> "Эти же банки не используют Informix, DB2, PostgreSQL, ...". Ссылка вот , например. 3 слайд с конца. Ну а насчет Informix, DB2 и т.д. - это уж вы приведите
Alexander Ryndin, скажите, Вы маркетолог/сейл/пресейл?
Ещё раз повторяю: мы говорим о технических вопросах. Да, вы приводите отличный пример:
сам Томас Куриан, исполнительный продюсер вице-президент Оракл, говорит о том, что лучшие-из-лучших во всём мире используют комплексные решения от Oracle.
Если Вы мне скажете, как этот (судя по всему, с Вашей точки зрения, убийственнейший) аргумент должен меня убедить что:
1. "Комплексное решение" подразумевает обязательноt и исключительное использование Oracle Database, нет, даже Oracle RAC, в каждом из этих случаев. Ну или хотя бы в большинстве.
2. Все остальные, которым не повезло войти в top-10-20-50-100 (по соответствующим категориям) не используют Оракл, потому что они просто тупы и не увидели единственность истинного и достойнейшего Бога нашего...
Извините, но просто срываюсь на стёб - нет сил пояснять причины неприемлемости мною Ваших аргументов.

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

АнатоЛойСоответственно, ссылки аналогичные Вашим приводить не могу :).

Нет, таки привести что-то надо, а то подумаете бог-весть что :)
Пусть будет эта

АнатоЛойПусть будет эта
Или даже вот эта .

Alexander RyndinАнатоЛойпропущено...
Ещё раз повторяю: мы говорим о технических вопросах. Да, вы приводите отличный пример:
сам Томас Куриан, исполнительный продюсер вице-президент Оракл, говорит о том, что лучшие-из-лучших во всём мире используют комплексные решения от Oracle.
Просто этот факт гарантирует, что на СУБД Oracle (в т.ч. RAC) можно строить надежные, отказоустойчивые системы.

Дорогая редакция, я х... Как ссылка на "комплексные решения" соотносится с использованием "Oracle RAC".
Может у TOP-10 поголовно Exadata с Oracle Database, НО без всяких РАКов, откуда мне знать?

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

Alexander RyndinА разве не вы меня просили привести статистику? Я привел - для вас это стало не аргументом. Чудно :)
Я просил не просто статистику. Я просил статистику по сути обсуждаемого вопроса. Всё, устал. Дальше в этом топике на подобные "аргументы" буду стараться не тратить много времени: прочитаю и отвечу с цитированием "OFF-TOP"...