|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 26 Aug 2002 18:54:04
To : Edward Shevtsov
Subject : Re: ответственная БД
--------------------------------------------------------------------------------
x.com> <ak5o3v$eh6$1@gavrilo.mtu.ru>
x.com> <vdsemu0rs0tr4k97cuadr1qcp7t1vq8lqd@4ax.com>
x.com> <aka178$goq$1@gavrilo.mtu.ru>
x.com> <q8phmu02s5clnebdinvfo5jtnietf0dmrb@4ax.com>
x.com> <akbdkn$179o$1@gavrilo.mtu.ru>
From: Tolik Tentser <tolik@katren.ru>
Hi, Edward Shevtsov!
В чреве акулы, пойманной Sun, 25 Aug 2002 20:13:01 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: ответственная БД':
>> Который конкретно пример ?
>> С разбиением таблицы по серверам и автоматической генерацией главным
>> сервером запросов только к нужным? Точно умел?
>
>Разбиение по серверам однозначно. Будет послан запрос на каждую удаленную
>таблицу
А MS посылает только тем серверам, на которых могут оказаться данные.
>и это правильно, поскольку узлы кластера должны
>быть равноправны.
Hет, неправильно, ибо глупо спрашивать данные там, где их заведомо
нету. Это принципиальное различие и Оракл этого до сих пор не умеет.
>> А Ораклу при этом надо обеспечить когерентность кэшей на всех
>> компьютерах, что нетривиально (если вообще реализуемо)
>
>так уже реализовано
При общем диске.
А не при shared nothing
>http://www.oracle.com/ip/deploy/database/oracle9i/db_sql_rac_askms.html
>Зря, там вполне конкретные вопросы, я просто хотел сверить ваши ответы с
>ответами от оракла, чтобы как раз и отделить пиар
Hу давай.
Can SQL Server2000's federated database architecture run any
application unchanged?
Answer: No.
SQL Server 2000 runs real applications on single server systems only.
Any transaction processing application that runs on Microsoft SQL
Server2000's federated architecture must be modified to support
sharing of data across the servers in the federated cluster. This
means you cannot take full advantage of the performance, scalability
and reliability that clustered servers provide to run your business
critical applications.
Hе совсем правда.
БД придется переделать, приложение - не обязятельно, поскольку внешне
распределенная таблица вкак обычная.
Can SQL Server2000's federated database 'scale out' with zero
downtime?
Answer: No.
Hе совсем. в принципе - может, хотя придется напрягать голову.
Hапример - добавляем сервер для нового диапазона данных - и начинаем
вставлять новые данные на него.
Is SQL Server2000 faster than Oracle9i Database on the TPC-C 32
processor clustered benchmark?
Answer: No.
В некластерной конфиурации - правда, в кластерной - враньё.
How many SAP parallel benchmarks have SQL Server2000 delivered?
Answer: None.
Hе в курсе.
How many enterprise applications are supported on SQL Server2000's
federated architecture?
Answer: None.
Hе в курсе.
Is SQL Server2000's federated architecture available on multiple
platforms?
Answer: No.
Само собой.
Hо, аналогичная архитектура от ИБМ - доступна где угодно
If a server fails in SQL Server2000's federated architecture,does the
application continue to run successfully?
Answer: No.
Остается спросить, что будет с Оракловским кластером, если загнется
общий диск :-)
In SQL Server2000's federated architecture, can user processing
continue without interruption if a server fails?
Answer: No.
SQL Server2000 applications have no concept of seamless application
reconnection. Therefore, in the event of a server failure and restart
on another server, users must manually reconnect to their database
applications.
Only Oracle9i Database supports the concept of transparent application
failover--automatically and transparently reconnecting users to their
database in the event of a system failure.
Бред.
Автореконнект - несколько строчек кода.
Can I manage my SQL Server2000 federated database(s) as a single
database?
Answer: No.
The management overhead of SQL Server2000 federated database is
proportional to the number of servers in your federated cluster.
Therefore, the more servers in your cluster, the greater your
management overhead becomes. In a federated configuration, every
database will require separate backup and recovery, tuning, security,
user management, space management, etc. The thousands of tables and
indexes typical of real-world complex OLTP applications will also have
to be split across the participating federated server. And managing
each object will require tremendous extra work per server.
Hе совсем. "security, user management" - пользователи видят только
главный сервер и менеджить их на остальных - не обязательно, точнее -
не нужно.
Пиар - он и есть пиар
>> А мы тут говорим только о рекордах :-)
>> Для реальных проектов в 99% случаев за глаза хватит интеловского
>> сервера
>
>И что мы увидим в разделе tpc.org для nonclustered-платформ. ;)
... в разделе Price-Performance, например ;-)
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
