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!, наверное...