Может ли AOS работать одновременно с двумя серверами SQL?

[Atani]

собственно, сабж.

С уважением, Атани.

[raz]

Конечно может, и даже с большим числом, но не одновременно :-)

[Vadik]

Quote:

Конечно может, и даже с большим числом, но не одновременно :-)

А пуркуа бы, собственно, и не па? Что мешает на одной физической машине иметь несколько настроенных AOS-ов (Object servers в Navision Axapta Server Manager), в каждом из которых настраивается подключение к разным БД или разным серверам? Что может им помешать работать одновременно?

Именно это, я полагаю, имел в виду raz?

[raz]

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

[mazzy]

согласен, может.

можно я ссылочку добавлю?
http://technet.navision.com/usered/A...01.00-ENUS.doc

[Atani]

Здравствуйте!

Вообще-то я имел ввиду несколько иное.
Может ли один AOS настраиваться и работать с задачей, расположенной в двух базах или даже на двух SQL-серверах?
Или может ли, скажем, работать два AOS'а, каждый со своей частью задачи, и между ними будут постоянные связи: всякая синхронизация справочников, возможность пользователям из клиента обращаться к обеим базам и т.п.

Наверное, через ODBC или OLE DB можно всё, но на свой страх и риск и не используя "интеллектуальности" самой Аксапты, а это не очень интересно.
Моя идея перенести часть серверной функциональности, соответствующей более-менее обособленному классу задач, на отдельный сервер. Но при этом обеспечение тесного взаимодействия задач как части единой системы.

С уважением, Атани

[mazzy]

Ага. Тогда в вопросе используется неправильная терминология.

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

Два приложения могут работать с одной базой. Но это противоречит лицензионной политике. И к тому же надо быть чертовски осторожным в таком режиме.

[Dron AKA andy]

To Mazzy: позволю себе не согласиться. Лично настраивал АОС таким образом, что ОДНО приожение использовалось ДВУМЯ АОС для доступа к ДВУМ разным базам (находящимся правда, на одном SQL-сервере, но это, по-моему, несущественно). Все упирается при этом только в лицензию на количество АОС (их должно быть столько же, сколько подключается баз к одному приложению). Все стабильно работало, очень удобно было осуществлять обновление приложения, главное - не забывать синхронизировать каждую БД при изменении приложения.

[mazzy]

А ведь правильно. И так можно.

Т.е. вопрос звучит так -
Можно ли в одной сессии Аксапты работать с двумя серверами SQL?
Atani, так?

[Atani]

Спасибо вам.

Я начинающий в Аксапте, поэтому возможно использую неправильную терминологию и что-то недопонимаю.

Да, именно так. Мне важно, чтобы клиент мог работать в одной сессии с двумя серверами, ну и это для него было не сложнее, как если бы он обращался к одной БД.

To Dron AKA andy:
Расскажите, пожалуйста, какакие настройки нужны, чтобы приложение работало с двумя БД, пусть это будет посредством двух АОС.

С уважением, Атани.

[Михаил Андреев]

Quote:

Изначально опубликовано Atani
Здравствуйте!

Вообще-то я имел ввиду несколько иное.
Может ли один AOS настраиваться и работать с задачей, расположенной в двух базах или даже на двух SQL-серверах?
Или может ли, скажем, работать два AOS'а, каждый со своей частью задачи, и между ними будут постоянные связи: всякая синхронизация справочников, возможность пользователям из клиента обращаться к обеим базам и т.п.

Наверное, через ODBC или OLE DB можно всё, но на свой страх и риск и не используя "интеллектуальности" самой Аксапты, а это не очень интересно.
Моя идея перенести часть серверной функциональности, соответствующей более-менее обособленному классу задач, на отдельный сервер. Но при этом обеспечение тесного взаимодействия задач как части единой системы.

С уважением, Атани

Требования противоречивы, то два АОСа, то два SQL сервера...

Два AOS на одной базе и даже с одним приложением запустить можно (убрав флажок монопольного доступа к файлам приложения). Это позволит разгрузить один сервер за счет другого (один - для оперативной работы, другой - для аналитики и расчетов, например). Но: 1) в 2.5. криво работает, приходится регулярно перезапускать, если одновременно что-то еще дорабатывается. Понятно, что решается запретом разработки, а импорт модификаций производить только в двухуровневой схеме. 2) Часть данных все равно может быть заблокировано, поэтому не всегда это однозначно ускоряет процесс расчетов. Но это редкость, я думаю. 3) Связь АОсов с серверами БД и файл сервером с файлами приложений нужна хорошая, иначе все насмарку...

Теперь, допустим, приложение одно, базы две. Работать будет, но криво: таблицы перекрестных ссылок, пользовательских настроек, вообще говоря, у разных баз могут быть разными, а приложение одно. Не пробовал использовать в штатном режиме, но кривости вылезут точно.

Теперь, допустим, приложения два, в база одна. Вообще не понял, зачем это может понадобиться. Но тоже будет криво по тем же причинам.

[Dron AKA andy]

Все тривиально: в параметрах конфигурации для каждого из АОСов (расположенных в окне сервер менеджера) прописываем один и тот же Application, но разные БД (и даже разные SQL серверы). Но не забудьте про лицензию на количество АОС, должно быть >1 АОС.

[Михаил Андреев]

Quote:

Изначально опубликовано Dron AKA andy
To Mazzy: позволю себе не согласиться. Лично настраивал АОС таким образом, что ОДНО приожение использовалось ДВУМЯ АОС для доступа к ДВУМ разным базам (находящимся правда, на одном SQL-сервере, но это, по-моему, несущественно). Все упирается при этом только в лицензию на количество АОС (их должно быть столько же, сколько подключается баз к одному приложению). Все стабильно работало, очень удобно было осуществлять обновление приложения, главное - не забывать синхронизировать каждую БД при изменении приложения.

Согласен с ремаркой. Про кривости выше написано. Но сам в штатном режиме сие не использую. Думаю, в приведенном случае, лучше использовать два приложения с двумя базами, сначала на первой базе обновлять в двухуровневой и синхронизировать, а затем первое приложение копировать на второе приложение, опять синхронизировать, затем перезапускать АОСы. Но, хозяин барин, это только мое мнение...

[Vadik]

Quote:

Теперь, допустим, приложение одно, базы две. Работать будет, но криво: таблицы перекрестных ссылок, пользовательских настроек, вообще говоря, у разных баз могут быть разными, а приложение одно. Не пробовал использовать в штатном режиме, но кривости вылезут точно.

Проблемы будут, но не смертельные

Quote:

Теперь, допустим, приложения два, в база одна. Вообще не понял, зачем это может понадобиться. Но тоже будет криво по тем же причинам

А вот это - полная ж.., если какая-то разработка ведется, при экспорте-импорте проекта такое начинается... ID у объектов в AOT разъезжаются, при синхронизации заполненные таблицы пересоздаются, ужас.. И это в принципе обходится, но чтобы при каждом неаккуратном чихе в системе разворачивать резервную копию.. Спасибо, нет. Экономия копеечная - размер БД на диске, а нервные клетки не восстанавливаются

Quote:

Да, именно так. Мне важно, чтобы клиент мог работать в одной сессии с двумя серверами, ну и это для него было не сложнее, как если бы он обращался к одной БД.

2Atani: этого Вам стандартная функциональность не даст. Вы лучше скажите, зачем Вам это надо? AOS-ы в разных местах стоят - офис и DMZ? Хотите данные разделять на актуальные и архив? Еще что-то?

Есть ощущение, что Вашу задачу надо с другого бока решать, например через разграничение прав.

[Михаил Андреев]

Quote:

Изначально опубликовано Vadik
... ID у объектов в AOT разъезжаются, при синхронизации заполненные таблицы пересоздаются, ужас.. И это в принципе обходится, но чтобы при каждом неаккуратном чихе в системе разворачивать резервную копию..

Там хуже: восстановление ничего не дает, придется делать экспорт-импорт данной таблицы

[Vadik]

Quote:

Там хуже: восстановление ничего не дает, придется делать экспорт-импорт данной таблицы

Всегда остается восстановление рядом копии БД и insert into Table1(..) select (..) from oldDB..Table1. Главная проблема - найти пересоздавшиеся таблицы

Я имел в виду возможность поиграться с "Экспортировать / Импортировать со значениями идентификаторов" еще до того, как что-то разъехалось, то есть на этапе экспорта-импорта проекта

[Михаил Андреев]

Quote:

Изначально опубликовано Vadik
Всегда остается восстановление рядом копии БД и insert into Table1(..) select (..) from oldDB..Table1. Главная проблема - найти пересоздавшиеся таблицы

Я имел в виду возможность поиграться с "Экспортировать / Импортировать со значениями идентификаторов" еще до того, как что-то разъехалось, то есть на этапе экспорта-импорта проекта

Понял. Забыл, что наряду с версией 2.5 есть еще 3.0

[komar]

Прочитал, понял, что все поняли по-своему. Можно я тоже встряну, а ?
Может, имелась в виду кластеризация SQL-серверов? Но это проблема не Акзапты, а личное дело СУБД....

[Atani]

Quote:

2Atani: этого Вам стандартная функциональность не даст. Вы лучше скажите, зачем Вам это надо? AOS-ы в разных местах стоят - офис и DMZ? Хотите данные разделять на актуальные и архив? Еще что-то?

Есть ощущение, что Вашу задачу надо с другого бока решать, например через разграничение прав.

Офис и удалённый офис. Какие-то задачи свои, какие-то - общие, плюс ненадёжный канал, при котором каждый офис должен остаться в рабочем режиме, если связь пропадёт.

[mazzy]

понятно. опять репликация.
лучше бросьте эту затею, ИМХО.