Юрий Шакуда, ответ зависит от частоты репликации данных. Если итерация раз в сутки, обновление структур можно проводить "вручную".

Вариант 1 (изменение структуры в центре - упорядоченное)
Все изменения структур в центральной БД выполнять sql-скриптами.
Хранить порядок выполнения данных sql-скриптов (например, в названии файла записывать и дату/время ГГГГ-ММ-ДД-ЧЧ-ММ-СС).
Cкрипты отправлять в регионы вместе с данными для репликации. В регионах перед загрузкой данных должны запускать скрипты обновления структуры, если они есть.

Вариант 2 (истории изменения центральной БД нет)
При передаче данных в регион передаётся вся структура (во внутреннем формате или просто выгруженная dbschema).
В регионе должна быть утилита, сверяющая структуру полученную с структурой местной БД и генерирующая скрипт для устранения расхождений. Сверять можно как полученный файл, так и создать тестовую БД с этой структурой и сравнивать структуры этих БД.
Утилиту можно написать самому, либо искать на просторах инета (зависит от целей и ограничений).

Какими именно средствами работает ваша репликация?

"Из коробки" у Informix такая фича есть в 11.70.
Если выберете мой вариант 1 (т.е. добьётесь упорядоченного внесения изменений в DDL центрального сервера), то при наличии связи с региональными серверами, времени и чуть-чуть головы несложно организовать запуски скриптов удалённо по ssh на каждом сервере.

Написал с третьего раза, первые два варианта вытер :).
Юрий, кто вы? Программист? Системный администратор?

1. Администратору сети и администратору БД очень полезны знания и умение использовать скриптовые языки.
Linux/Unix - shell-скрипты.
Windows - VBScript, batch-файлы.

2. Вам нужно решить, что вы будете делать в ситуациях, если:
2.1) на каком-то региональном сервере часть DDL-команд в скрипте выполнится, а часть - нет;
2.2) на одном из региональных сервере весь скрипт выполнился, а на другом - нет.

3. А дальше научиться, как автоматически :
3.1) доставить sql-скрипт по обновлению БД на региональный сервер;
3.2) запустить shell-скриптом удалённо (ssh) уже доставленный sql-скрипт (dbaccess'ом) на региональном сервере;
3.3) отлавливать в shell-скрипте ошибки выполнения dbaccess и решить, что вы с ними будете делать;
3.4) если вас не устраивает последовательное обновление серверов:
а) как выполнить в скрипте без ожидания их завершения несколько команд ("параллельный" запуск задач на серверах).
б) что делать дополнительно, если произошла ситуация 2.1) или 2.2):
3.5) возможно, останавливать и запускать репликацию на центральном сервере.

4. Скриптовый язык позволит склеить это всё в одну программу.

5. Вопросы? :)

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

Вариант 1, организационный: есть админ БД, через которого пропускаются все изменения БД в центральной БД
1.1) Программисты проверяют работоспособность скриптов на тестовых БД, перед тем как "отдать" (положить в систему контроля версий - СКВ) для запуска на центральной БД.
1.2) Админ лично запускает DDL-скрипты, взяв их из СКВ.

Один админ уже более организуем , чем толпа программеров, а значит человеческий фактор не так критичен :).
Тем более если это вы, и проблема печёт вас :).

Вариант 2, технический: программисты "неуправляемы" и изменяют структуру как хотят и когда хотят и какими им только заблагорассудится инструментами (неужели это правда? ).
Если это правда, то у вас такие пути:
а) всё DDL-изменения в центральной БД отлавливать аудитом и переносить в регионы;
б) всё DDL-изменения в центральной БД отлавливать аудитом, анализировать (какие важны для репликации), переносить в регионы;
в) запускать "инструмент сравнения" схем БД периодически ;
г) запускать "инструмент сравнения" схем БД после возникновения ошибок репликации.

в) и г) - с инструментом возможны варианты:
1) Мы для себя писали утилиту, которая коннектилась к двум БД, через таблицы системного каталога сравнивала структуры и генерировала скрипт обновления для второй БД.
2) Можно воспользоваться кучей специализированных утилит для этой задачи, инет в руки. Возможно, вам для нужд репликации достаточно будет сравнивалки, которая работает через ODBC с любой БД, и проверяет только таблицы и поля с типами данных, игнорируя констрейнты, триггеры, взгляды и хранимые процедуры...

3) можно воспользоваться универсальными серьёзными инструментами типа PowerDesigner: реверс-инжиниринг структур обеих БД, генерация DDL-скрипта для устранения отличий. Но универсальность тоже может потребовать доработки напильником.

Теперь посмотрите на эти варианты, подумайте и скажите - вы точно за технический вариант решения задачи?

Юрий ШакудаВсе очень сложно и не очень красиво, ...это все равно человеческий фактор что не очень хорошо.
Мне тоже иногда проще утилитку найти, чем с людьми договориться.
Профессиональная деформация личности, так сказать. Но всегда ли утилитка лучше?
Вы точно хотите делать сами много тупой работы вместо того, чтобы один раз организовать процесс?

Юрий ШакудаПочему то у меня все проблемы связаны с синхронизацией то данных, то структуры:)
Лучше создайте отдельный топик с соотв. темой, а здесь отпишитесь, что со структурой-то решили? :)