Какой кошмаааар!

- В общем, цепочка ASE11 -> ASA(9-12) -> MS SQL 2008 работать должна. Работать оно будет тяжко и медленно, но будет. Проблем с синтаксисом опасаться не стоит - запросы будут обрабатываться в основном на ASE. Источник и промежуточные сервера будут просто гнать полные таблицы (на каждый запрос) и все это будет очень даже жутковато смотреться. Но работать будет.

- Если вы делаете переход на новую технологию, то скорее всего, вам стоит подумать и о редизайне базы в соответствии с современными требованиями бизнеса. То есть вопрос об онлайн связке нескольких серверов просто отпадет.


Я пару раз участвовал в подобных играх и мы всегда делали просто:
1) В разработке новый клиент на новом сервере с новой структурой базы. Старый клиент продолжает жить со старой базой.
2) Когда определено как основные бизнес-объекты будут храниться в новой структуре делается односторонний конвертор-репликатор - из старой структуры в новую и запускается по ночам. Тогда разработчики новой системы могут работать с реальными данными. Когда решают подправить новую структуру - репликатор тоже обновляется.
3) Когда новая система готова к выпуску - она ставится в один-два филиала (отдела) и репликатор выключается для этих филиалов, но продолжает работать для остальных.
4) Когда все переходят на новую систему - старая вместе с репликатором уходят в архив.
Все.

KruНасколько реальна репликация между ASE 11.9 и MSSQL2008? Достаточно ли будет сайбезовского сервера репликации для этого? Если да, то должен ли он быть старой версии или любой подойдёт?Репликация реальна всегда.
Но Replication Server для этой задачи не подойдет. RS это полноценная система репликации с промежуточным хранением. Ее будет слишком много для этой задачи и настраивать ее не так просто. Да, если у тебя она уже есть, то можно до-настроить и использовать, но в данном случае целевая база будет постоянно меняться (структура базы которая в разработке это очень нестабильная штука).
Полноценную ETL в этой задаче использовать можно конечно, но мне сильно кажется что это будет неудобно. Да и не помню я никаких ETL кроме RS которые могут работать с ASE-11.


То что я имел в виду можно сделать либо кучкой вызовов bcp out - bcp in, либо написанием специального приложения ориентированного на бизнес-объекты. Там менять структуру выходного формата будет намного проще.
Собственно говоря у меня чаще всего это просто перловый скрипт который делает bcp out из несколько таблиц, пересортировывает данные из этих файлов в новые файлы, а потом bcp in в новую базу.
Пару раз, исходной базой были DBF'ки. Один раз Клипперские, в другой FoxPro'шные. Там я делал C приложения которые бегали по куче dbf'ов, собирали из них бизнес-объект в память, потом грузили (через ODBC) этот бизнес-объект в кучку таблиц. Потом брались за другой БО. Там в обоих случаях структура баз была полностью другой, так что двигаться от бизнес-объектов было намного проще и логичнее чем от таблиц.


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

KruКак в вашем случает рассматривался сценарий восстановления данных в случает отката неудачной миграции?Не было такого ни разу.
Мы просто назначали географически ближайший филиал "подопытными кроликами" и заставляли их вводить данные в две системы разом. За два-три месяца они вылавливали все баги которые IT-testers не могли поймать по причине своей опытности в IT.
Ну а остальные филиалы сами делали себе период двух-системной работы пока обучались работе в новой системе. Мы (центральный офис) им это советовали, но не заставляли. И уже местное начальство решало когда окончательно переходить на жизнь по новому. В среднем за пару месяцев - полгода переход на новую систему проходил окончательно.
Реплицировать данные в старую систему не было нужды ни разу.

KruТоже такой вопрос. Если исходить из того, что структура базы будет идентична, то может быть имеет смысл обновить клиента чтобы он одновременно писал и в новую и в старую базы?Никогда такого не было чтобы структура баз была идентична. Теоретически это конечно возможно, но в моей практике такого не встречалось.
Если начинают задумываться о смене клиента-базы, и главное выделяют на это деньги. То это значит что старая клиент-база уже реально не удовлетворяет бизнес.