Wine@Etersoft SQL и Selta (технология перехода вопрос)

[kerya33]

Есть 1С 7.7 SQL версия, 25 Windows и Linux терминальных клиентов, сервер Kraftway двухпроцессорный Xeon, 8 Гб RAM, сказевая дисковая подсистема (зеркало). На сервере установлены Microsoft Windows Server 2003 Enterprise Edition, Microsoft SQL Server 2000. Объем БД ~ 30 Гб. Рассматривается вариант перехода на WINE@Etersoft 1.0 SQL, SELTA@Etersoft под Debian'ом. Заказал тестовые версии, начну тестить (правда не на таком железе).
Перечитал много постов на форуме, страничку внедрений на etersoft.ru, но так и не уяснил для себя реально-ли работать в такой конфигурации и на таких объемах БД стабильно и без существенной потери производительности ? И еще очень слабо представляю себе технологию переползания конторы на новую платформу при отсутствии второго сопоставимого по железу сервера. Буду благодарен за любые отзывы - рекомендации. Особенно интересуют реально работающие проекты с аналогичной структурой и объемами БД.

[arahorn]

Есть 1С 7.7 SQL версия, 25 Windows и Linux терминальных клиентов, сервер Kraftway двухпроцессорный Xeon, 8 Гб RAM, сказевая дисковая подсистема (зеркало). На сервере установлены Microsoft Windows Server 2003 Enterprise Edition, Microsoft SQL Server 2000. Объем БД ~ 30 Гб. Рассматривается вариант перехода на WINE@Etersoft 1.0 SQL, SELTA@Etersoft под Debian'ом. Заказал тестовые версии, начну тестить (правда не на таком железе).
Перечитал много постов на форуме, страничку внедрений на etersoft.ru, но так и не уяснил для себя реально-ли работать в такой конфигурации и на таких объемах БД стабильно и без существенной потери производительности ? И еще очень слабо представляю себе технологию переползания конторы на новую платформу при отсутствии второго сопоставимого по железу сервера. Буду благодарен за любые отзывы - рекомендации. Особенно интересуют реально работающие проекты с аналогичной структурой и объемами БД.

В принципе все реально, у меня работает, объем основной БД 15 Гб, число пользователей на офисе, на котором перехожу 5. "без существенной потери производительности" тут есть нюансы, в чем то Postgre будет быстрее, в чем то медленнее, в том где он быстрее пользователи не замечают ...

Я произвожу перевод первого офиса развернув базы на слабой машине и предварительно преупредив пользователей что станет плохо. Как переходить в вашей ситуации не знаю. Но всегда можно что нибудь придумать для плавного перехода.

Для начала рекомендовал бы вам развернуть периферийную базу (или копию базы) на слабом сервере и имитируя работу нескольких пользователей отточить под себя конфигурацию Postgre

[kerya33]

Для начала рекомендовал бы вам развернуть периферийную базу (или копию базы) на слабом сервере и имитируя работу нескольких пользователей отточить под себя конфигурацию Postgre

В принципе так и планировал сделать на стареньком сервере, отловлю по возможности глюки, вот только потом все равно на боевую базу переключаться единомоментно придется, а страшновато, ну на тесты месяц есть, а там посмотрю...

[arahorn]

В принципе так и планировал сделать на стареньком сервере, отловлю по возможности глюки, вот только потом все равно на боевую базу переключаться единомоментно придется, а страшновато, ну на тесты месяц есть, а там посмотрю...

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

[kerya33]

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

Спасибо за дельный совет.