Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 commit = rollback!!! (SQL Server2000 и Oracle)  [new]
Vladsed
Member

Откуда: Moscow
Сообщений: 20
После миграции приложения с SQL Server2000 на Oracle (8i) в одном из триггеров остался вызов процедуры, в которой при определенных условиях вызывался commit. В общем случае в Oracle, как известно, операции с транзакциями в триггерах запрещены (не рассматривая специфические случаи типа автономных транзакций...), но компилирует при этом без всяких проблем. Ситуация усугублялась тем, что в блоке обработки исключиельных ситуаций на верхнем уровне именно это исключение перехватывалось "молча" (when others) и выполнялся rollback. Работало потрясающе, но иногда вместо ожидаемого commit в транзакции получался rollback!!! Докапаться было не очевидно, тем более эти случаи были очень редки...
Вывод:
написав commit в одной БД можете получить rollback в другой - и все в соответствии со стандартом ANSI...Песенка ослика-ораклиста
1 авг 03, 18:10    [285701]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
NewYear
Member

Откуда: Большой адронный коллайдер
Сообщений: 2203
а вот в дибите такой фигни нет! (про песенку)
1 авг 03, 18:17    [285707]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
Vladsed
Member

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

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 - гораздо больше:
- отсутствует перехват и обработка исключительных ситуаций (конечно, можно извратиться и сделать проверку на возможность, например, конвертнуть один тип данных в другой...);
- нет массивов и нет возможности хранить переменные для сессии иначе как во временных таблицах;
- нет возможности вернуть результаты динамического запроса в саму же вызывающую процедуру на сервере (только через временные таблицы)...


Возможно обсуждение этих вопросов поможет кому-то сделать осознанный выбор базы данных для приложений.
1 авг 03, 19:10    [285794]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>В Oracle чтение никогда не блокирует запись, хотя может блокировать некоторые ресурсы.

Это какие ресурсы? Что-то сходу не могу вспомнить...
2 авг 03, 00:49    [285946]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
DimaR
Member

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

Стоит, внимательней поизучать документацию, или спросить и почитать форум об Oracle, на этом же сайте и тогда не будет подобных проблем.
3 авг 03, 21:48    [286634]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
Одно из примечателных различий, на мой взгляд, в том, что выборка данных в SQL Server-е может блокировать DML-операции.

А может и не блокировать. Очень легко можно задать уровень блокировки от полного отсутствия до блоктрования всей таблицы.

Самый простой способ Select f1, f2.. from t1(nolock)

И нечего поклеп. А ежели нужна действительно сложная логика на MS SQL сервере, пиши XP - результат тебя удивит.
6 авг 03, 07:46    [289479]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
Vladsed
Member

Откуда: Moscow
Сообщений: 20
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..., решений много, но такого же простого - не знаю.
6 авг 03, 20:45    [291007]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
отсутствует перехват и обработка исключительных ситуаций (конечно, можно извратиться и сделать проверку на возможность, например, конвертнуть один тип данных в другой...);
Можно не извращаться, а использовать @@ERROR
6 авг 03, 22:11    [291059]     Ответить | Цитировать Сообщить модератору
 Re: commit = rollback!!! (SQL Server2000 и Oracle)  [new]
killed
Member

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

это все Internals...

ты думаешь в других СУБД все "бесплатно" дается ? ;-)
8 авг 03, 16:48    [293979]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить