|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Edward Shevtsov 2:5020/400 27 Aug 2002 01:52:58
To : Tolik Tentser
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>
x.com> <6dfkmu89488m4btcb75dpf0upgvt46987p@4ax.com>
From: "Edward Shevtsov" <edward.shevtsov@mtu-net.ru>
> >Разбиение по серверам однозначно. Будет послан запрос на каждую удаленную
> >таблицу
>
> А MS посылает только тем серверам, на которых могут оказаться данные.
И что будет с таким кластером, когда перестанет справляться главный сервер? Ведь
изначально все запросы идут на него. Так? Это
значит, что все пользователи должны держать соединение на этот главный сервер? Я
правильно понимаю? А остальные узлы держат части
одной логической таблицы и курят, поскольку невозможно эффективно распараллелить
нагрузку простым делением большой таблицы на N
частей. И большая таблица еще не есть большая нагрузка.
>
> >и это правильно, поскольку узлы кластера должны
> >быть равноправны.
>
> Hет, неправильно, ибо глупо спрашивать данные там, где их заведомо
> нету. Это принципиальное различие и Оракл этого до сих пор не умеет.
Ему это как я понимаю просто не нужно.
Если бы этот путь был эффективен, его бы реализовали. Там делов то получается -
добавить метаданные об удаленных частях таблицы, все
остальное было сделано очень давно. Принципиальное различие в том, что даже при
такой конфигурации у оракла все узлы остаются
равноправными. Берите данные этой таблицы с любого узла - они остаются
равноправными в отношении этой таблицы. Здесь нет ничего
искусственного
[skip]
> >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.
>
> В некластерной конфиурации - правда, в кластерной - враньё.
Пункты 7 и 9 для кластерных конфигураций с 32 х Intel Pentium III Xeon 900 MHz
>
> 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.
>
> Остается спросить, что будет с Оракловским кластером, если загнется
> общий диск :-)
Hадежность и защищенность этой штуки будет на порядок выше того, что сможет
позволить себе MS на каждом узле своего кластера, чтобы
сохранить конкурентно-способность по ценам с учетом стоимости железа. Кроме
того, если умрет хотя бы один нод MS-кластера, то
придется останавливать всю систему.
>
> 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" - пользователи видят только
> главный сервер и менеджить их на остальных - не обязательно, точнее -
> не нужно.
а остальное в предложении?
>
> Пиар - он и есть пиар
>
Спасибо.
Regards,
Ed
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
