Вот нарыл в документации:
Database Clustering Architectures: There are two primary database clustering architectures: shared-disk and shared-nothing. Shared-disk is used by Oracle RAC. DB2 for Linux employs shared-nothing.

In a shared-disk environment, each database node has its own processors but shares the disks with other nodes. Therefore all the processors can access all the disks in the cluster. This introduces additional overhead for coordinating resources and locks between nodes. For example if Node 1 wants to access data on a certain disk that has been locked for update by another node in the cluster, Node 1 must wait for other nodes to complete their operations. While this works well when there are few nodes in the cluster (e.g. mainframe environments), the overhead for distributed lock management and cache coherency issues can severely limit scalability and introduce performance degradation for 4 or more nodes, making it impractical to exploit economies of large clusters on Linux. Furthermore this approach involves specialized hardware and software for shared disk and cache management, making it a lot more expensive than shared-nothing.
Shared-nothing: As the name implies, partitions (nodes) in a shared-nothing environment do not share processors, memory or disks with partitions on other machines. Each partition acts on its own subset of data. Since each partition has its own private resources, this approach does not involve any resource contention with other servers, lending itself to virtually unlimited scalability. This is one reason DB2 for Linux can support up to 1000 partitions. And since there is no coordination overhead for accessing resources, additional machines can easily be added to the cluster with linearly scalable performance, which implies, if doubling of the data volume is matched by the doubling of the cluster resources, the high performance of the database will be maintained at the same level. If one partition in a cluster fails, its resources can dynamically be transferred to another machine, ensuring high availability. Another benefit of the shared nothing approach used by DB2 for Linux is that it does not require specialized hardware, making the solution a lot simpler, less expensive and suitable for Linux based "commodity" hardware.



Т.е. чтобы развернуть Оракловский кластер нужно специальное оборудование для реализации Shared Storage. А вроде для IBM кластера нужна куча персоналок + гигабитная связь между ними.


А от о чем говорил г-н Куликов


Т.е. в SMP машине при большом количестве процессоров производительность
растёт нелинейно. Типа из-за борьбы за разделяемые ресурсы. А в этом случае
каждому разделу базы данных отводятся свои память, диски, процессоры.
Дескать рост производительности должен быть более линейным.
По идее поэкспериментировать с кластером DB2 - подешевле нежели с Ораклом. Все дело упрется в лицензию PDF (Database Partition Feture)

2 Kulikov
>>Ты не говори про лицензию ты попробуй. За 90 дней обыгаться можно до потери сознания и пульса :)

Дадут шанс - обязательно попробую. Потому как очень интересно.:)
Во всяком случае поучиться настраиваить подобную систему очень хочу.

Кстати, для всех - DB2 самая легко настраиваемая система. *Это мой субъективный взгляд конешно*

2 Сергей Тихонов.
Просмотрел указанную Вами ссылочку.

With Microsoft SQL Server 2000, scale out is generally accomplished via clustered architectures. In a clustered database architecture, multiple autonomous systems, each containing a copy of the operating system and a copy of the database engine, share a single copy of the database. The multiple copies of the database and operating system coordinate with one another but are controlled separately. This arrangement is generally referred to as a "loose coupling" of the operating systems.

В статье все-же написано что Sharing Nothing - теоретически д.б. более линейно масштабируемой системой.
Из статьи я также понял, что механизмы кластеризации в Windows реализованы для общего случая, а не конкретно под SQL Server, и
и следовательно такое решение не будет столь же хорошо масштабирроваться как для MPP архитектуры, которую предлагают IBM,Sybase,Nonstop SQL.
может именно поэтому в конце статьи дается совет - scale up (нарастить один сервер) прежде чем scale out (делать кластер).

Наверно все дело в реализации.
Основной довод в пользу scale up - кластер работает со скоростью самого медленного узла. Ну что тут сказать?... Правильной балансировкой нагрузки должен заниматься администратор БД.


Искать нечто подобное этой статье и именно от IBM...не возьмусь...)))
Разве что предложу посмотреть эту ссылочку:
http://www-306.ibm.com/software/data/db2/udb/support/manualsNLVv8.html#ru_main
- руководство администратора