Размещение БД на физически разных SQL серверах.

[Alexandr A. Osipkin]

Добрый день

Подскажите пожалуйста, как реализовать размещение базы данных Axapta 3.0 SP3 на физически разных SQL серверах (т.е. одни таблицы на одном сервере, другие на другом). Возможно ли это?
Кто сталкивался с этим? И каких проблем можно ожидать?
В данный момент используется Axapta 3.0 SP3 (Kernell Rollup не установлены)
MS SQL 2000, Windows 2003 Server.

С уважением, Александр А. Осипкин.

[fomenka]

В таком ключе решения под 2000 sql нет. Возможные варианты увеличения производительности системы в целом с помошью количества серверов начинаются с ключевых слов Database Mirroring, Log Shipping, replication и т.д. Это если вы абсолютно уверены, что дело в железе, а не в руках и головах.

Можно еще прочитать про federated database servers и distributed partitioned views. Скорее всего, последний термин - самый близкий к вашему случаю.

Ну и конечно же http://www.sql.ru

[Alexandr A. Osipkin]

Цитата:

Сообщение от fomenka

В таком ключе решения под 2000 sql нет. Возможные варианты увеличения производительности системы в целом с помошью количества серверов начинаются с ключевых слов Database Mirroring, Log Shipping, replication и т.д. Это если вы абсолютно уверены, что дело в железе, а не в руках и головах.

Можно еще прочитать про federated database servers и distributed partitioned views. Скорее всего, последний термин - самый близкий к вашему случаю.

Ну и конечно же http://www.sql.ru

Я абсолютно уверен, что дело в руках и головах. Но никто не хочет править код. А я не имею возможности. А можно как нибудь на пальцах объяснить про эти термины, а то с англицким проблемы
Заранее спасибо

[Alexandr A. Osipkin]

Всем спасибо. уже разобрался.. ))

[Андре]

Цитата:

(т.е. одни таблицы на одном сервере, другие на другом).

По-моему, очень не удачное решение. Особенно с точки зрения надежности.
В случае останова(в том числе незапланированного) одного из серверов все приложение становится неработоспособным. Вероятность выхода из строя системы становится произведением вероятностей поломки каждого из серверов.

Также я бы подумал, как Вы планируете делать backup базы данных. В случае работы пользователей ни о какой согласованности данных на момент backup речи не идет.

Кроме всего прочего, я очень сомневаюсь, что Аксапта сможе работать одновременно с двумя серверами (часть таблиц там - часть там). Каждый сервер имеет свой менеджер блокировок и в случае, если изменения транзакции касатся таблиц на нескольких серверах, мне вообще непонятно как это может работать. Даже теоритически. Нужен какой-то внешний менеджер распределенных транзакций.

[Андре]

Цитата:

Возможные варианты увеличения производительности системы в целом с помошью количества серверов начинаются с ключевых слов Database Mirroring, Log Shipping, replication и т.д.

В общем то, все это позволит создать более-менее актуальную БД для сбора по ней отчетов. В случае Log Shipping - надо будет еще view настроить. C Database Mirroring - надо экспериментировать. Сама база постоянно находится в сатусе recovery - значит надо делать снапшоты. Снапшоты надо обновлять с какой-то периодичностью, а что будет с Аксаптой в момент обновления снапшота - тоже большой вопрос.

[mono]

Цитата:

Сообщение от Андре

Вероятность выхода из строя системы становится произведением вероятностей поломки каждого из серверов.

Интересная логика. Если вероятность поломки сервера A составляет 0.3 и сервера B 0.3, то вероятность выхода из строя системы из двух серверов (A и B) будет 0.3*0.3 = 0.09?

[oip]

Думаю имелось в виду, что перемножать надо вероятности безотказной работы (0.7*0.7=0.49).
Обычная опечатка.

[Torin]

Народ, а какой смысл во всем этом ? ;-)
Или, типо, теоретический спор ?

[fomenka]

Человек начал тему с того, как с помощью нескольких железок поднять производительность SQL. Почему теоретический вопрос? Очень даже практический. Отрицательный результат - тоже результат.

[Андре]

Цитата:

Думаю имелось в виду, что перемножать надо вероятности безотказной работы (0.7*0.7=0.49).
Обычная опечатка.

Да, спасибо.