После миграции приложения с SQL Server2000 на Oracle (8i) в одном из триггеров остался вызов процедуры, в которой при определенных условиях вызывался commit. В общем случае в Oracle, как известно, операции с транзакциями в триггерах запрещены (не рассматривая специфические случаи типа автономных транзакций...), но компилирует при этом без всяких проблем. Ситуация усугублялась тем, что в блоке обработки исключиельных ситуаций на верхнем уровне именно это исключение перехватывалось "молча" (when others) и выполнялся rollback. Работало потрясающе, но иногда вместо ожидаемого commit в транзакции получался rollback!!! Докапаться было не очевидно, тем более эти случаи были очень редки...
Вывод:
написав commit в одной БД можете получить rollback в другой - и все в соответствии со стандартом ANSI... Песенка ослика-ораклиста

После миграции приложения с SQL Server2000 на Oracle (8i) в одном из триггеров остался вызов процедуры, в которой при определенных условиях вызывался commit. В общем случае в Oracle, как известно, операции с транзакциями в триггерах запрещены (не рассматривая специфические случаи типа автономных транзакций...), но компилирует при этом без всяких проблем. Ситуация усугублялась тем, что в блоке обработки исключиельных ситуаций на верхнем уровне именно это исключение перехватывалось "молча" (when others) и выполнялся rollback. Работало потрясающе, но иногда вместо ожидаемого commit в транзакции получался rollback!!! Докапаться было не очевидно, тем более эти случаи были очень редки...
Вывод:
написав commit в одной БД можете получить rollback в другой - и все в соответствии со стандартом ANSI... Песенка ослика-ораклиста

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

1) Одно из примечателных различий, на мой взгляд, в том, что выборка данных в SQL Server-е может блокировать DML-операции. В Oracle чтение никогда не блокирует запись, хотя может блокировать некоторые ресурсы. Это серьезно влияет на разработку, требуя разных подходов.

2) Радикально различаются подходы к транзакциям. В SQL Server не рекомендуются длительные транзакции, т.к. потребляют значительные ресурсы, в Oracle, наоборот, излишние commit могут серьезно снизить производительность.

3) На серверной части SQL Server не желательно использовать сложную бизнес-логику, вызываю большую загрузку сервера БД. Разумнее переложить часть бизнес-логики на среднее звено. Т.е. лучше много отосительно коротких и простых операций, чем меньше В Oracle всю возможную работу с данными лучше предоставить БД, для сопуствующих операций - среднее звено и java процедуры.

4) Для клиентской части, наверное, немаловажно, что API для SQL Server проще в использовании. Чтобы в Oracle вернуть результаты запросов из процедур, придется использовать курсоры, и не всегда поддерживаются все его возможности (например вложенные таблицы или объектные типы).

5) В SQL Server: до сих пор нет триггеров на уровне строки, ограничения по рекурсионным вызовам, суммарному размеру индексов (в Oracle типов индексов больше) и стобцов, что зачастую невозможно создавать единую таблицу и приходится искусственно ее расщеплять, и т.д. Oracle - чтобы сказать, что у него чего-то нет, надо найти это в других базах, и не найти соответствующего аналога.

5) Сравнение Transact SQL и PL/SQL - вообще отдельная тема. В плюс Transact SQL - его относительная простота и удобство работы с документацией. Минусов по сравнению с Oracle - гораздо больше:
- отсутствует перехват и обработка исключительных ситуаций (конечно, можно извратиться и сделать проверку на возможность, например, конвертнуть один тип данных в другой...);
- нет массивов и нет возможности хранить переменные для сессии иначе как во временных таблицах;
- нет возможности вернуть результаты динамического запроса в саму же вызывающую процедуру на сервере (только через временные таблицы)...


Возможно обсуждение этих вопросов поможет кому-то сделать осознанный выбор базы данных для приложений.

2 killed:
Подразумевались внутренние блокировки и защелки, а также влияние на буферный кеш у сложных запросов с возвратом большого результирующего набора... Подробней об этом, наверное уместно на форуме по Oracle...

2 DimaR:
Разумеется проблемы решаются, но все же удобнее это в SQL Server-е.

2 vdimas:
READ UNCOMMITTED
Implements dirty read, or isolation level 0 locking, which means that no shared locks are issued and no exclusive locks are honored. When this option is set, it is possible to read uncommitted or dirty data; values in the data can be changed and rows can appear or disappear in the data set before the end of the transaction. This option has the same effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the least restrictive of the four isolation levels.

Т.е. без блокировки доступен только этот уровень, у Oracle без блокирования достигается уровень READ COMITTED и SERIALIZABLE.

А вот еще одна фича - отсутствие нумерации строк в результирующем наборе у SQL Server, вроде мелочь, но из-за этого по-разному реализуется, например, постраничный вывод на браузер записей от 190 до 200 с заданой сортировкой:
В Oracle:
select t.*
from ( select rownum rw , t.* from (select * from mytable t order by param1 desc, param2) t where rownum <= 200) t
where t.rw >= 190;
В SQL Server: нужно использовать либо временные таблицы, либо джойнить еще на что-нибудь, либо дополнительный подзапрос in..., решений много, но такого же простого - не знаю.