vadiminfoУ Оракла существуют, (если не обращать внимания на streams, который появился в 9 и позволяет реплицировать не только данные, но и DDL, однако, есть нюансы)
Я тоже ничего в статье не нашел, чтоб бы не умели делать сервера от SYBASE. DDL таже замечательно реплицируется RS-ом, как и truncate table и прочие извращения. Есть одна РЕАЛЬНАЯ ЗАСАДА, это то, что для RS имя definition у процедуры должно совпадать с именем самой процедуры, но в принципе, это обходится.

Ладно, раз пошла такая пьянка...

Чего меня ЖУТКО огорчает в MSSQL (КАК ПРОЕКТИРОВЩИКА/РАЗРАБОЧИКА/...):
1) Невозможность непосредственного использования агрегатной функции либо подзапроса внутри агрегатной (select sum (x + select sum())). Обходится, не всегда красиво, но все же.
2) Отсутствие THRESHOLD-ов. Читал и дико смеялся насчет своевременных backup-ов, агента, счетчиков производительности и автоувеличения размера устройств в документе, описывающем миграцию с SYBASE на MSSQL.
3) Отсутствие partitions - обещают аналог в Yukon-е, но тоже через то самое место.
4) Отсутствие возможности управлять ресурсами сервера, доступными пользователю (процессу/логину/...).
5) Необходимость указывать владельца у скалярной функции (вообще убил бы того, кто это придумал).
6) Если надо select distinct и order by, то приходится указывать все поля из order by в select distinct. На кой?
7) Исполнение rollback не из транзакции приводит к ошибке (обходится if @@trancount > 0, но все равно неприятно).
8) Для получения текущего уровня изоляции транзакций надо такое вытворять с dbcc useroptions, что даже описывать не хочется.
9) Если надо просто поменять default на поле (который просто при создании таблицы как default указывался) либо изменить обязательность поля, надо выполнять/указывать кучу никому не нужных операций.
10) некорректность проверки if object_id(‘#tmpobject’) is not null
11) эвристический алгоритм эскалации уровня блокировки (обуздать его аппетит можно, но тоже только полудокументировано).

Чего не менее жутко напрягает в ASE:
1) отсутствие фукнций (обходится исключенительно изменением логики)
2) отсутствие возможности сжать БД (в смысле, выкинуть девайс либо уменьшить его размер), обходится, но либо переносом данных, либо недокументирвоаными update-ами.
3) dump/load на зачаточном уровне (у MSSQL там своя задница, но менее серьезная).
4) отсутствие поддержки табличек вида ##xxx.
5) отсутствует возможность получения списка доступных серверов (то есть, сканирование сети, а не только тех, что в sql.ini)
6) пользователь (sysusers) может входить только в одну группу (опять же sysusers).

В RS:
1) необходимость совпадения имени procedure и function replication definition (обходится иногда только размножением процедур).
2) отсутствие НАЛГЯДНОГО инструмента для исправления транзакции, которая пытается пропихнуться в принимающую БД, но отвергается по каким-либо причинам.

В oracle/db2:
1) совершенно издевательский синтасис конкатенации строк (палками).

С oracle/db2/informix/asa последние 2-4 года не работал вообще, что то могло и поменяться, так что все в некоторой степени ИМХО.

vadiminfoКуда более важно выяснить, например, про равноправную репликацию. Когда юзера работают локально с копиями данных распределенной БД. Или хотя бы не про равноправную, но, которая обеспечивается только средствами СУБД.
"Мир кожи и меха" у нас на полной двунаправленной репликации (RS+ASE) работает (за очень небольшим исключением, оно не технического плана). Есть клиенты, где одна центральная БД и куча филиалов, кое что во все строны, кое что не полностью, не все поля и только куда надо.

Сергей Васкецовна полной двунаправленной репликации
естественно, там во все стороны, "двунаправленной" - это просто жаргон, "дву" не при чем.

vadiminfoПриходится отключать триггера на втором сервере или их модифицировать так, чтобы они не выполняли ничего, если изменения вносит отложенная транзакция. А у нас много проектов и править это море триггеров не здорово. Если бы можно было как-то задать для всех триггеров было бы проще.
На RS, кстати, можно указать, что триггеры на ASE вообще для RS (DSI) не будут работать.