gardenman,

Да ну ?!

Каждый раздел DPF - имеет свой лог (если конечно у Вас не SMP-big server with SAN Disk Storage).
Я так понимаю, что InfoSphere Balanced, ведет себя по другому ... :)

Да, и вот еще,
в DB2 используется значительно меньший размер записи для регистрации транзакции, чем в Oracle !!!

С уважением,
Вадим.

gardenman,

Вообще-то странно. Что может записываться в логический журнал на узле (DB2 with DPF),
если транзакция не затрагивает данные на этом узле (кроме служебной информации) ?!

Решение DB2 with DPF, наиболее часто, используется для DWH.Заливка данных
в DWH, проводится планово (с использованием - ETL или DB2 IMPORT, DB2 LOAD и т.д.).
Использовать DB2 with DPF в транзакционных системах - что-то новенькое.
Уж лучше DB2 pureScale ... :) ... или OLTP-решение на Informix !!!

С уважением,
Вадим.

Mark Barinstein,

Все верно.

If a transaction failure occurs in a partitioned database environment, database recovery is usually necessary on both the failed database partition server and any other database partition server that was participating in the transaction .
....

In a partitioned database environment, the database partition server on which a transaction is submitted is the coordinator partition, and the first agent that processes the transaction is the coordinator agent.

Ключевая фраза ...

The coordinator agent is responsible for distributing work to other database partition servers, and it keeps track of which ones are involved in the transaction.

С уважением,
Вадим.

Mark Barinstein,

Распределенные транзакции, как правило,
применяют в гетерогенных и распределенных системах.

На мой взгляд,
наиболее целесообразно, использовать мониторы танзакций - CICS, Tuxedo and so on.
Порождать распределенные транзакции на уровне Engine сервера базы данных - создавать себе дополнительные проблемы (надежность, быстродействие, гибкость и логика взаимодействия подсистем и т.д.).

Думаю, что использовать DB2 with DPF в OLTP-окружении, не совсем коректно.
Решение DB2 with DPF скорее для OLCP=OLTP+DSS и DWH-систем.


Порождать для OLTP-транзакции, синхронизацию узлов кластера на базе протокола two-phase commit, слишком дорогое удовольствие. Какой же это OLTP-решение и главное зачем?!!!
Это все равно, что у Вас есть несколько отдельных систем на базе DB2, которые в рамках
распределенной трнзакции выполняет SQL-запросы в режиме работы OLTP-систем.

Уж лучше использовать DB2 9.8 pureScale или быстрый OLTP-движок IBM Informix !!!

То, что распределенные транзакции более ресурсоемкие и требует дополнительных,
накладных расходов - это понятно. Для OLTP-систем наиболее важно, чтобы время реакции
на SQL-запрос пользователя было детерменированное (не более 3-5 секунд).

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

С уважением,
Вадим Головский.

mitek,

Уважаемые коллеги.

Во-первых,
не всегда можно оптимальным образом размазать таблицы по узлам кластера DB2 with DPF
для OLTP-приложений (очень многое зависит от природы данных, гистограммы распределения и т.д). Опять же вопрос с обновлением или удалением записей по Primary Key (включая первичный ключ), выбор Partitionong Key, выполнение сложных JOIN (not collocation join) и т.д.

Во-вторых,
вопрос относительно тестов TPC-E и TPC-H носит больше политический подтекст.
Нужно просто посмотреть, кто выступил инициатором тестов TPC-E и для чего ... :)

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

С уважением,
Вадим Головский.

mitek,

Инициатор TPC-E, вроде бы Microsoft. И какова же цель, если не секрет ? :) Захватить мир ? :)
...


Все верно, инициатор TPC-E - Microsoft !!! Какова же цель - они лучше знают ... :)

...
И что мешает Oracle и IBM в нём успешно выступать ?


Думаю, что ничего ... есть же тесты TPC-H для DWH(DSS) ... :)

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

Но лучше спросить у IBM или Oracle !!!

С уважением,
Вадим.