Возникла необходимость ознакомиться с Oracle

← →
pavel_guzhanov © (2006-06-06 13:34) [0]

Посему имею несколько вопросов:
1. Можно ли установить Oracle на свой рабочий комп, или только на сервер?
2. Есть ли в Delphi компоненты для работы с Oracle (например можно ли использовать dbExpress и насколько он удобен)?
3. Насколько Oracle отличается от других СУБД? (я работал с MSSQL, InterBase)
4. насколько отличается PL/SQL от SQL92 и от T-SQL?
Спасибо за ответы :0))

← →
Игорь Шевченко © (2006-06-06 13:36) [1]

> Можно ли установить Oracle на свой рабочий комп, или только
> на сервер?

Можно

> Есть ли в Delphi компоненты для работы с Oracle (например
> можно ли использовать dbExpress и насколько он удобен)?

Можно через BDE (просьба ногами не пинать)

> 3. Насколько Oracle отличается от других СУБД? (я работал
> с MSSQL, InterBase)

Толще

> 4. насколько отличается PL/SQL от SQL92 и от T-SQL?

Ширше

← →
pavel_guzhanov © (2006-06-06 13:37) [2]

> Толще

Это всмысле книги толще? :0))

← →
Игорь Шевченко © (2006-06-06 13:39) [3]

pavel_guzhanov © (06.06.06 13:37) [2]

> Это всмысле книги толще? :0))

Да нет, сама СУБД и ее потребности в ресурсах.

Книги всяко толще

← →
Sergey13 © (2006-06-06 13:39) [4]

2 pavel_guzhanov © (06.06.06 13:34)
2. Практически любые "стандартные" наверное можно настроить. Лучшие из платных DOA и ODAC.

← →
Petr V. Abramov © (2006-06-06 13:43) [5]

>1.
на компе фломастером необходимо написать "СЕРВЕР" :)
если есть свободных ~256М опреативки - можно.

>2. лучше через Direct Oracle Access (от Allroundautomations) или ODAC

>3. вот настолько

>4. см п.3

← →
Sergey13 © (2006-06-06 13:44) [6]

2 [3] Игорь Шевченко © (06.06.06 13:39)
> Да нет, сама СУБД и ее потребности в ресурсах.
ИМХО это расхожий штамп, не очень соответствующий дейстаительности. У меня на П2 ~300Мгц + 192М памяти крутилась 8-ка на одновременно 30-50 сессий. Плюс это был файловый и почтовый сервер. Плюс его "убивали" еще и разработчики. И каких то особых тормозов я не помню.

← →
Курдль © (2006-06-06 13:45) [7]

На один комп установить можно и серверную версию и персональную. Процесс типа "нажмите "Да".
Качается и та и другая с сайта оракла бесплатно, но по паре гигов трафика наберется.
Из Делфей лучше всего доступаться через компоненты сторонних производителей (DAO, ODAC и т.п.). Нормально работает через любые ODBC-совместимые.
От других СУБД отличается надежностью и быстродействием.
PL/SQL ничего вопиющего по сравнению с другими языками СУБД не несет.
Большой плюс - возможность организовывать логику пакетами.

← →
data © (2006-06-06 13:49) [8]

> Игорь Шевченко © (06.06.06 13:36) [1]
>
> Можно через BDE (просьба ногами не пинать)

только не через BDE

← →
Игорь Шевченко © (2006-06-06 13:50) [9]

Sergey13 © (06.06.06 13:44) [6]

> ИМХО это расхожий штамп, не очень соответствующий дейстаительности.
>

Сравни с Interbase, удивись. Про MSSQL ничего сказать не могу, не знаю я его.

← →
Danilka © (2006-06-06 13:50) [10]

2. Можно через АДО, dbExpress не пробовал, но вроде тоже без проблем.

По 3,4, в принципе, Том Кайт может дать ответ в книге "Оракле для профессионалов", мне книга нравицца.
Есть в pdf - 10МБ.

[7] Курдль © (06.06.06 13:45)
> PL/SQL ничего вопиющего по сравнению с другими языками СУБД
> не несет.

Вообще-то есть дофига вкусностей, которых в MSSQL, например, не хватает.
А работа с деревьями и аналитические функции вообще пестня. Именно их мне сейчас под MSSQL ой как не хватает, приходится корячица над тем, что раньше давалось легко и просто.

← →
Sergey13 © (2006-06-06 13:54) [11]

2[9] Игорь Шевченко © (06.06.06 13:50)
> Сравни с Interbase, удивись.
Не буду. Это разный класс продуктов.

← →
Андрей Пазик (2006-06-06 13:55) [12]

> А работа с деревьями и аналитические функции вообще пестня.
> Именно их мне сейчас под MSSQL ой как не хватает, приходится
> корячица над тем, что раньше давалось легко и просто.

В MSSQL2005 вроде появилось with, с помощью которого можно строить любые иерархии. В Firebird 3.0 такое тоже будет, но 3,0 выйдет наверно через год.

← →
Игорь Шевченко © (2006-06-06 13:55) [13]

Sergey13 © (06.06.06 13:54) [11]

> Это разный класс продуктов.

Смотря для каких задач автор планирует использовать сабж

← →
pavel_guzhanov © (2006-06-06 13:57) [14]

> Смотря для каких задач автор планирует использовать сабж

Это пока неясно... просто в перспективе может быть оччень хорошая вакансия.... Для этого надо хотя бы азы представлять....

← →
Курдль © (2006-06-06 13:59) [15]

> Danilka © (06.06.06 13:50) [10]
> Вообще-то есть дофига вкусностей, которых в MSSQL, например, не хватает.

А я про MS SQL и не заикался - я PL/SQL с TSQL сравнивал - а ведь это не только MS SQL :)

rowid - это уже достижение!

← →
Игорь Шевченко © (2006-06-06 13:59) [16]

> оччень хорошая вакансия.... Для этого надо хотя бы азы представлять.
> ...

Оччень хорошую вакансию за азы вроде не дают...Дают просто хорошую или не оччень хорошую

← →
pavel_guzhanov © (2006-06-06 14:03) [17]

> Оччень хорошую вакансию за азы вроде не дают...Дают просто
> хорошую или не оччень хорошую

Дело в том, что вакансия оччень хорошая именно с моей точки зрения, для моих знаний и умений. Для Вас, судя по Вашим ответам (не только на мои вопросы, а вообще в форуме) эта вакансия может показаться и не оччень... А мне до мастера еще далековато :0))

← →
Курдль © (2006-06-06 14:15) [18]

> pavel_guzhanov © (06.06.06 14:03) [17]

Только что в Библио-глобусе листал толстую книжку PL/SQL для профессионалов. Рекомендую ее приобрести и не пытаться извлечь зерна знаний из форумов.

← →
pavel_guzhanov © (2006-06-06 14:22) [19]

> Рекомендую ее приобрести и не пытаться извлечь зерна знаний
> из форумов.

Обязательно приобрету... И еще есть в электронном виде книга Тома Кайта, просто я прежде чем углубляться в книгу, решил получить стартовое представление :0)) А из форума я не пытаюсь извлечь зерна знаний, а просто пытаюсь получить самую первую и самую общую информацию....

← →
Petr V. Abramov © (2006-06-06 14:24) [20]

Все-таки книга Concepts из документации - рулезней

← →
pavel_guzhanov © (2006-06-06 14:34) [21]

и еще один вопрос: А сколько он места на диске скушает?

← →
J_f_S (2006-06-06 14:39) [22]

> и еще один вопрос: А сколько он места на диске скушает?

Немерянно. У меня девятка трешку съела. Но там много очень всякого намешанно, свой сервер ставит (на основе апача), доков куча, есть и своя система Java разработки JDeveloper (круче, чем JBuilder).

← →
Sergey13 © (2006-06-06 14:42) [23]

2[21] pavel_guzhanov © (06.06.06 14:34)
>и еще один вопрос: А сколько он места на диске скушает?
Каое это имеет значение, если "перспективе может быть оччень хорошая вакансия"
"Торг тут не уместен"
(с) Киса Воробьянинов в роли отца русской демократии
8-)

← →
pavel_guzhanov © (2006-06-06 14:49) [24]

> Каое это имеет значение,

Значение только такое, что возможно, придется диск в комп доставлять... Но, вроде бы, обойдусь и тем что есть:0)))

← →
Sergey13 © (2006-06-06 15:05) [25]

2[24] pavel_guzhanov © (06.06.06 14:49)
Не все что можно поставить ставить нужно. 8-)

← →
Desdechado © (2006-06-06 21:52) [26]

> 1. Можно ли установить Oracle на свой рабочий комп, или только на сервер?
Можно. Если грамотно отконфигурировать и повыкидывать неиспользуемые запчасти. Или просто иметь комп с многими мегабайтами ОЗУ (один экземпляр Оракла с настройками по умолчанию отъедает ~500 М).

> 2. Есть ли в Delphi компоненты для работы с Oracle (например можно ли использовать dbExpress и насколько он удобен)?
Есть. Я пользую dbExpress. Драйвера в D7 для Оракла косые (хотя для пробы пойдет). Мы покупали.
Удобство - понятие суъективное. Мне хватает (на всякие выкрутасы в т.ч.).

> 3. Насколько Oracle отличается от других СУБД? (я работал с MSSQL, InterBase)
Элементарные вещи - одинаковы. Серьезные - совсем другие. Оракл гораздо ближе по концепциям к IB, чем к MS. Но следует помнить, что IB - версионник, а Оракл и MS - блокировочники.

> 4. насколько отличается PL/SQL от SQL92 и от T-SQL?
SQL-92 - это стандарт SQL. А PL-SQL и T-SQL - это процедурные расширения, присущие серверу и стандартом не покрываемые. Поэтому там все разное.
В Оракле есть даже понятие контекста выполнения (в SQL или PL/SQL) и переключения между контекстами. Да и ограничения у них (SQL и PL/SQL) при схожем синтаксисе разные.

← →
Sergey Masloff (2006-06-06 22:16) [27]

Desdechado © (06.06.06 21:52) [26]
>Или просто иметь комп с многими мегабайтами ОЗУ (один экземпляр Оракла >с настройками по умолчанию отъедает ~500 М).
120 мег десятка

>Оракл гораздо ближе по концепциям к IB
:-))))))) кто к кому
>Но следует помнить, что IB - версионник, а Оракл и MS - блокировочники.
Оракл не блокировочник как таковой. Просто у него версии не в сегменте данных лежат ;-)

По остальному претензий нет ;-)

← →
Petr V. Abramov © (2006-06-06 22:21) [28]

> Sergey Masloff (06.06.06 22:16) [27]
> 120 мег десятка
ну ты мастер обрезания. никогда б не заподозрил :)
автору топика этим делом заняться, конечно, необходимо, но после прочтения Concepts

← →
Desdechado © (2006-06-06 22:23) [29]

Sergey Masloff (06.06.06 22:16) [27]
> 120 мег десятка
Я про девятку R2 говорил, хотя забыл указать.
А вообще не удивительно. Инсталляха 10R2 почти втрое меньше 9R2 (одинаковых редакций).

← →
Sergey Masloff (2006-06-06 22:24) [30]

Petr V. Abramov © (06.06.06 22:21) [28]
Да я сам удивился - но сейчас в таск манагере посмотрел 120. Правда он без юзеров. Я вроде и не делал ничего почти

← →
Sergey Masloff (2006-06-06 22:26) [31]

Desdechado © (06.06.06 22:23) [29]
>Я про девятку R2 говорил, хотя забыл указать.
А ну это известное дело. Она у меня вообще просто не заработала на 500 мегах оперативки.

← →
Petr V. Abramov © (2006-06-06 22:27) [32]

сейчас стоит 10-ка EE Basic Installation (приговоренная к завтрашнему снесению в таком виде, но таковая была нужна) - ~2+G

← →
Petr V. Abramov © (2006-06-06 22:29) [33]

Sergey Masloff (06.06.06 22:24) [30]
> но сейчас в таск манагере посмотрел 120
так мы ж про диск...
а в оперативке - это нормально, главное - не меньше 44М :)

← →
Desdechado © (2006-06-06 22:32) [34]

> Она у меня вообще просто не заработала на 500 мегах оперативки
а я как-то умудрился запустить на 128
не работа - своп сплошной ....

← →
Petr V. Abramov © (2006-06-06 22:40) [35]

я с 10-кой EE нервов потратил... не стартует база запуском сервиса, и все! уж и trace`ы на уровне support изучал, и афигевал...
обратился к знающим матчасть по долгу службы и узнал, что

это баг 4991595. Нужно поставить патч 10.2.0.2 и выше. Или самому создать
службу, которая будет запускать bat файл с командой запуска.

хорошие люди - Oracle, но казлы иногда...

← →
Sergey13 © (2006-06-07 09:55) [36]

Запустил 8.1.7 - посмотрел - 50 метров отъела. Посмотрел в параметры - все правильно - сколько отвел ей, столько и съела. 8-)

← →
Курдль © (2006-06-07 10:12) [37]

> Desdechado © (06.06.06 21:52) [26]
> IB - версионник, а Оракл и MS - блокировочники.

Тебе здесь до меня еще ноги не повырывали за такое высказывание? :)
Оракл - единственный полноценный версионник. MS SQL - полный блокировщик. IB пыжится побороть блокировки.

← →
Игорь Шевченко © (2006-06-07 11:19) [38]

Курдль © (07.06.06 10:12) [37]

> Оракл - единственный полноценный версионник

А IB, стало быть неполноценный ? :)

← →
Курдль © (2006-06-07 11:28) [39]

> Игорь Шевченко © (07.06.06 11:19) [38]
> А IB, стало быть неполноценный ? :)

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

← →
evvcom © (2006-06-07 11:33) [40]

> Игорь Шевченко © (06.06.06 13:36) [1]
> Ширше

"Ширше" не правильно, правильно "ширее" :-)

> Petr V. Abramov © (06.06.06 13:43) [5]
> >1.
> на компе фломастером необходимо написать "СЕРВЕР" :)
> если есть свободных ~256М опреативки - можно.

У меня дома всего 256, не шустро, но крутится. Службу стартую только по необходимости естественно. :-)

← →
Desdechado © (2006-06-07 11:49) [41]

Курдль © (07.06.06 10:12) [37]
> Оракл - единственный полноценный версионник.
Был бы он версионником, не болел бы этой странной, тщательно культивируемой и всеми "любимой" болезнью по имени "ORA-04091 Table is mutating, trigger/function may not see it".

PS холивара не будет

← →
evvcom © (2006-06-07 11:54) [42]

> Desdechado © (06.06.06 21:52) [26]
> Но следует помнить, что IB - версионник, а Оракл и MS - блокировочники.

Oracle блокировщик? Оп. Это что-то новое. Блокируются только изменяемые в данный момент (до коммита или ролбэка) записи, но это и правильно.

> Sergey Masloff (06.06.06 22:26) [31]
> Desdechado © (06.06.06 22:23) [29]
> >Я про девятку R2 говорил, хотя забыл указать.
> А ну это известное дело. Она у меня вообще просто не заработала
> на 500 мегах оперативки.

А что такое R2? Я чего-то не знаю, видимо. У меня 9i дома на 256М нормально запускается. Из служб стартую только Listener и базу. Память надо смотреть, так не знаю. А на винте, что поставишь. Можно и скрипты не ставить, и тестовые (учебные) базы, тогда может и на 9i много не съестся?

← →
evvcom © (2006-06-07 11:59) [43]

> Desdechado © (07.06.06 11:49) [41]
> Курдль © (07.06.06 10:12) [37]
> > Оракл - единственный полноценный версионник.
> Был бы он версионником, не болел бы этой странной, тщательно
> культивируемой и всеми "любимой" болезнью по имени "ORA-
> 04091 Table is mutating, trigger/function may not see it".

Эта ошибка не из-за блокировок. Ты путаешь. Не используй селектов (DML) в триггерах on each row, которых в MSSQL нет (или может уже появились?, не знаю про IB), применительно к изменяемым таблицам, и не получишь такой ошибки.

← →
Курдль © (2006-06-07 12:13) [44]

> Desdechado © (07.06.06 11:49) [41]
> "ORA-04091 Table is mutating, trigger/function may not see it".

Это не болезнь и не ошибка. Даже не фитча. Это предупреждение нерадивому программисту, прямо вытекающая из версионности, что "нефиг рубить сук, на котором сидишь".
Если среда разработки предупреждает тебя о зацикливании программы, бесконечной рекурсии, или переполнении стека, это ошибка? :)

← →
evvcom © (2006-06-07 12:22) [45]

> Это не болезнь и не ошибка.

Нет, это все-таки и болезнь, и ошибка. Только не Оракла. :-)

← →
evvcom © (2006-06-07 12:25) [46]

> прямо вытекающая из версионности

Кстати, с версионностью, по-моему, совсем никак не вяжется, хотя бы потому, что возникает в той же самой сессии. А из другой сессии будет совсем другая ошибка (опять же не разработчика)

← →
Petr V. Abramov © (2006-06-07 12:53) [47]

> evvcom © (07.06.06 11:33) [40]
можно и в меньше запихать. только у автора ветки с первого раза может не получиться.

← →
Desdechado © (2006-06-07 12:59) [48]

evvcom © (07.06.06 11:54) [42]
> Oracle блокировщик? Оп. Это что-то новое. Блокируются только изменяемые
> в данный момент (до коммита или ролбэка) записи, но это и правильно.
Блокируются? Значит, блокировочник.
Версионник IB просто создает копию записи для тебя, и терзай ее как хочешь независимо от других. Помни также, что при использовании некоторых видов индексов (например, BITMAP) блокируются и другие записи, которые ты не трогаешь (если изменяется индексное поле).

> А что такое R2?
Это Release 2 (9.2 или 10.2)

> Эта ошибка не из-за блокировок. триггерах on each row (не знаю про IB)
в IB все триггеры одинаковые, для каждой записи.
И у него нет проблем с чтением изменяемой таблицы, т.к. он читает версии записей, относящиеся к текущей транзакции. А у Оракла проблема есть, т.к. нет понятия версии. Он не понимает, какие данные взять.

← →
Petr V. Abramov © (2006-06-07 13:03) [49]

> Это предупреждение нерадивому программисту, прямо вытекающая из версионности
из версионности это никак не вытекает. Вытекает из того, что если DML затрагивает несколько записей, и при этом в row-триггере делать селект, он вернет полную белиберду - половина записей в виде ДО DML-statement`а, половина - после. Еще противоречит принципу, что на конкретный SCN мы всегда увидим одни и те же данные.

← →
Petr V. Abramov © (2006-06-07 13:04) [50]

> Desdechado © (07.06.06 12:59) [48]
> А у Оракла проблема есть, т.к. нет понятия версии. Он не понимает, какие данные взять.
Как это нету??? А SCN?

← →
evvcom © (2006-06-07 13:11) [51]

> Версионник IB просто создает копию записи для тебя, и терзай
> ее как хочешь независимо от других.

IB не знаю, спорить не буду, только спрошу. Хорошо. Одна сессия изменила запись без коммита, другая аналогично. Потом 2 коммита. Что получим? И это правильно?

> в IB все триггеры одинаковые, для каждой записи.
> И у него нет проблем с чтением изменяемой таблицы

Я делаю вывод, что в IB нет понятия изменяемой таблицы. Есть понятие измененной таблицы. В Оракле присутствуют оба эти понятия, и они различны. Ты просто не разобрался с этим.

> > А что такое R2?
> Это Release 2 (9.2 или 10.2)

А... Ну тогда у меня R2 с 6 патчем.

← →
Petr V. Abramov © (2006-06-07 13:16) [52]

> evvcom © (07.06.06 13:11) [51]
> IB не знаю, спорить не буду, только спрошу. Хорошо. Одна сессия изменила запись без коммита, другая аналогично.
Ну IB тоже не дураки писали. Вторая транзакция подождет коммита первой. "Кто первый встал, того и тапки"

← →
evvcom © (2006-06-07 13:25) [53]

> Ну IB тоже не дураки писали

Ну я и не говорил, что дураки. Мне просто было интересно, как они разрулили тогда такую ситуацию?

> Вторая транзакция подождет коммита первой. "Кто первый встал,
> того и тапки"

Ну, если одна из них делает ролбэк, вопросов нет, а если коммит, вторая тогда что, ошибку выплюнет? В [41] помнится списали ошибку, возникающую из недопонимания программиста, на отсутствие версионности. Здесь аналогичная ситуация.

← →
pavel_guzhanov © (2006-06-07 13:34) [54]

Спасибо за ответы и за советы. Завтра поеду на Горбушку, надеюсь, что там найду дистрибутив... и начну дома изгаляться... над собой больше всего :0)))

← →
kaif © (2006-06-07 13:50) [55]

В ORACLE есть одно хорошее примущество. Возможность делать SELECT над SELECT. Это очень удобно даже просто при разработке. Например, хочешь узнать, сколько записей тебе вернет некий запрос. Можно вполне написать такую вещь:
SELECT COUNT(*) FROM (SELECT ... FROM ... WHERE ...).
Любопытно, что возможны не просто SELECT анд SELECT-ом, но и объединение результатов нескольких запросов в запросе более высокого уровня через алиасы запросов.

Что-то вроде этого:

SELECT
A.ID, A.NAME, B.S_AMOUNT
FROM
T1 A,
(SELECT ID, SUM(AMOUNT) S_AMOUNT
FOM T2 WHERE ... GROUP BY ID ORDER BY ID) B
WHERE
A.ID = B.ID

причем конструкцию ORDER BY можно применять и во вложенном запросе. Это позволяет как бы проиндексировать внутренний набор перед объединением (я такое делал) и значительно ускорить результат.

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

← →
Sergey13 © (2006-06-07 13:53) [56]

2[55] kaif © (07.06.06 13:50)
> Вообще оптимизатор ORACLE меня несколько раз смутил непредсказуемостью своих решений.

Который из оптимизаторов?

← →
Desdechado © (2006-06-07 13:53) [57]

Petr V. Abramov ©
evvcom ©
я, возможно, чего-то еще не понимаю или не знаю
но даже при наличии версионности (сколько, кстати, возможно таких версий у записи?) она явно какая-то не такая, как в IB
может, просто под одним словом понимаются разные вещи?

← →
evvcom © (2006-06-07 13:59) [58]

> SELECT COUNT(*) FROM (SELECT ... FROM ... WHERE ...).

Ну вообще такое умеет, наверное, любой современный сервер.

> SELECT
> A.ID, A.NAME, B.S_AMOUNT
> FROM
> T1 A,
> (SELECT ID, SUM(AMOUNT) S_AMOUNT
> FOM T2 WHERE ... GROUP BY ID ORDER BY ID) B
> WHERE
> A.ID = B.ID

А это разновидность записи join, тоже, наверное, есть в любом сервере. Даже в Local SQL есть (я не говорю про вложенный select)

> Вообще оптимизатор ORACLE меня несколько раз смутил непредсказуемостью
> своих решений.

Это от непонимания или от недопонимания. Но иногда у Оракла действительно крышу сносит. Но переделав немного запрос, заставляешь его проглотить и такое.

← →
Desdechado © (2006-06-07 14:01) [59]

> оптимизатор ORACLE меня несколько раз смутил непредсказуемостью своих решений
там у него настроек - вагон и маленькая тележка
все предсказуемо, только вот способ предсказания является нетривиальной формулой от настроек + загрузки + порядка соединения таблиц + количества и разнообразия данных в таблицах + актуальности статистики индексов + ...

← →
ораклоид (2006-06-07 14:03) [60]

>>kaif © (07.06.06 13:50) [55]
>>В ORACLE есть одно хорошее примущество. Возможность делать SELECT над SELECT.

Я тебе страшную вещь скажу: такое умеет делать даже тупой Access.

← →
kaif © (2006-06-07 14:04) [61]

Sergey13 © (07.06.06 13:53) [56]
2[55] kaif © (07.06.06 13:50)
> Вообще оптимизатор ORACLE меня несколько раз смутил непредсказуемостью своих решений.

Который из оптимизаторов?

На знаю. Их много? Я работал с ORACLE 9i.
Не настолько долго, чтобы серьезно разбираться с оптимизаторами. Но запросы у меня были многоэтажные (с генерируемым текстом). По умолчанию что используется? Насколько я понял тогда: "экономический принцип оптимизации" (или что-то в этом роде, не помню - по английски читал в описании).

Но у меня была ситуация, над которой мы с товарищем ломали весь день голову. Именно та, о которой я сказал: безобидный некоррелированный запрос ORACLE исполнял как коррелированный. То есть многократно вызывал подзапрос, хотя результат при каждом вызове должен был быть заведомо одинаков (в условиях подзапроса никак не использовались поля из внешнего запроса). Только когда мы приблизительно поняли, как ORACLE пытается рассуждать, мы выбросили одно лишнее (тривиальное) условие из подзапроса и все заработало верно. Лишнее условие возникало из-за того, что тексты генерировались автоматически и в определенной ситуации два разных условия могли друг друга логически дублировать - поначалу я не видел в этом криминала.

← →
Danilka © (2006-06-07 14:06) [62]

[55] kaif © (07.06.06 13:50)
OracleXE бесплатный. Но с некоторыми ограничениями, несущественными для малых БД.
А там, где базы большие, обльше ограничений, уже стоимость сервера будет несущественной.
:)

← →
kaif © (2006-06-07 14:09) [63]

ораклоид (07.06.06 14:03) [60]
>>kaif © (07.06.06 13:50) [55]
>>В ORACLE есть одно хорошее примущество. Возможность делать SELECT над SELECT.

Я тебе страшную вещь скажу: такое умеет делать даже тупой Access.

Очень сомневаюсь, что Access в своем синтаксисе поддерживает алиасы для подзапросов. Если даже это так, то сколько уровней вложенности подзапросов позволяет следать Access ?
И какова при этом скорость?
А может ли Access принять конструкцию ORDER BY в подзапросе?

Я сравниваю с IB. В нем, к сожалению, запрос над запросом сделать невозможно, хотя можно выкрутиться через хранимую процедуру с SUSPEND. Я знаю, что MS SQL может тоже делать запрос над запросом, нот я лично такие вещи в MS SQL не делал.

Просто в ORACLE это сделано великолепно.
Я лишь это хотел сказать.

← →
Petr V. Abramov © (2006-06-07 14:10) [64]

логику оптимайзера можно понять, сказав

alter session set events "10053 trace name context forever, level 1"

и зимним вечером почитав trace-файл.

> но даже при наличии версионности (сколько, кстати, возможно
> таких версий у записи?) она явно какая-то не такая, как
> в IB
> может, просто под одним словом понимаются разные вещи?

Вообще в оракле блокировка наступает только (я сейчас не говорю про пользовательские блокировки) при попытке во второй сессии изменить уже изменяемую запись. Но если запись селектится, никаких блокировок не наступает. Даже если за время (точно не помню правильное название) неизменности данных во время транзакции (первая сессия) происходит изменение этих данных в другой сессии, первая продолжает работать со своей старой версией. Оракл эту инфу добывает из журнала изменений что ли. Но это уже из темы "Уровни изолированности транзакций".
За некоторые "термины" прошу не пинать, не админ я. :)

2[61] kaif © (07.06.06 14:04)
> Их много?
Их 2. По стоимости и по правилам. По умолчанию работает первый. Но для его работы должна регулярно собираться статистика. При отсутствии статистики работает второй. При нерегулярно собираемой статистике результаты могут быть непредсказуемы. Плюс параметры настройки конечно.

> evvcom © (07.06.06 14:11) [65]
> Оракл эту инфу добывает из журнала изменений что ли.
из undo tablespace, до 9-ки - сегмента отката.
а журнализирутся все - и данные, и undo

> Их 2. По стоимости и по правилам.
по деньгам и по понятиям :)

2 Sergey13 ©
Логика той ошибки была именно в применении оптимизации по стоимости (вспомнил термин :). Однако стоимость он оценивал достаточно по-идиотски. Таблицы подзапроса были маленькие, а внешнего - большие. Вот он и прикинул, что ему лучше выполнить подзапрос много раз. Хотя поздапрос возвращал заведомо всегда один и тот же результат и ORACLE имел достаточно информации, чтобы до этого додуматься.
Я бы тогда не возмутился, если бы в документации не было черным по белому написано, что такие запросы всегда рассматриваются как некоррелированные (если в подзапросе не используются значения полей из таблиц внешнего запроса). В результате у нас запрос работал 20 минут вместо 1 секунды. Пока мы не выбросили лишнее условие.

2[69] kaif © (07.06.06 14:20)
>Однако стоимость он оценивал достаточно по-идиотски.
Какая статистика, такая и оценка. 8-)
Вполне вероятно, что, когда-то в прошлом году однажды собранная, статистика говорила СВО, что выгоднее делать именно так.

← →
ораклоид (2006-06-07 14:47) [71]

>>kaif © (07.06.06 14:09) [63]
>>Очень сомневаюсь, что Access в своем синтаксисе поддерживает алиасы >>для подзапросов.

А не надо сомневаться, можно проверить. Ответ - поддерживает.

>>Если даже это так, то сколько уровней вложенности подзапросов >>позволяет следать Access ?

Проверил 10, дальше надоело.

>>А может ли Access принять конструкцию ORDER BY в подзапросе?

Может. А зачем? А в Oracle зачем?

>>Просто в ORACLE это сделано великолепно.

Да и многое другое сделано с умом, лично мне приятно иметь дело с этим (9.2) продуктом :-)

> >>А может ли Access принять конструкцию ORDER BY в подзапросе?
> Может. А зачем? А в Oracle зачем?

Я с этим столкнулся пока только однажды. Написал древовидный select с order by siblings, потом добавил rownum, потом всё это надо было просеять и отсортировать обрезанное дерево by siblings. Ну а самый внешний select был естественно уже не древовидный, вот и сортировал во второй раз по выбранному ранее rownum.

evvcom © (07.06.06 13:11) [51]
> Я делаю вывод, что в IB нет понятия изменяемой таблицы.
> Есть понятие измененной таблицы. В Оракле присутствуют оба эти понятия,
> и они различны. Ты просто не разобрался с этим.
Я не понимаю, что значит "изменяемая таблица". Для данных, имхо, достаточно двух состояний - до изменения и после. Зачем нужно состояние "в процессе", если все равно к ним в это время не обратиться (мутации, етить!)? Толк какой от него? Примерчик приведешь?
Я делаю вывод, что "в процессе" - это и есть та самая блокировка.

> Я сравниваю с IB. В нем, к сожалению, запрос над запросом
> сделать невозможно

в двойке можно

evvcom © (07.06.06 13:11) [51]
Что получим?
зависит от параметров транзакций. Либо исключение еще при запросе получим, либо при коммите второй транзакции..

> Я не понимаю, что значит "изменяемая таблица".

В оракле существуют 2 вида триггеров: триггеры уровня оператора и уровня строки (on each row), каждый из них соответственно делится еще на 2 вида (подвида, кому как угодно): до изменения и после изменения. Естественно каждый из них может действовать при insert, update, delete и в комбинации. Допустим требуется выполнить update таблицы с условием where <условие>, под которое попадает несколько строк. Алгоритм:
1. Выполняется before уровня оператора.
2. Начинается скан таблицы (индекса), находится первая строка, удовлетворяющая условию.
3. Выполняется before уровня строки.
4. Вносятся изменения.
5. Устанавливается флаг изменяемой таблицы.
6. Выполняется after уровня строки.
7. Ищется следующая строка, удовлетворяющая условию.
8. Если нашлась, то переход к шагу 3.
9. Иначе сбрасывается флаг изменяемой таблицы.
10. Выполняется after уровня оператора.

Если на каком-то из шагов произошла ошибка, то весь update на фиг. Вроде ниче не забыл.

> Для данных, имхо, достаточно двух состояний - до изменения и после.
> Зачем нужно состояние "в процессе", если все равно к ним
> в это время не обратиться (мутации, етить!)? Толк какой
> от него? Примерчик приведешь?

Нужно не состояние в процессе, а нужно бывает обработать текущие значения строки. Например, в MSSQL формируются таблицы inserted и deleted. Если надо проанализировать правильность update-а записи, надо ее найти в обеих таблицах, и потом только сравнивать. Поскольку записей там может быть много и различных условий сравнения тоже, мы использовали курсоры. Если надо что-то поправить приходилось делать опять update (чего, уже не помню, то ли целевой таблицы, то ли таблицы inserted, давно уже не работал с MSSQL, кто знает, меня поправят).
В Oracle создаешь триггер уровня строки (before), выполняешь проверку и если надо что-то подправить, пишешь, например так:
:new.fld := :old.fld + 1
+ все это делается в одном и том же скане.

> Я делаю вывод, что "в процессе" - это и есть та самая блокировка.

Нет, это не блокировка. Просто после изменения первой строки группы выставляется флаг, а после того как вся группа строк изменена флаг сбрасывается. И если select происходит из таблицы с установленным флагом, то и получаешь ту самую ошибку про "мутацию".

Все побег домой, если что, остальное завтра...

evvcom © (07.06.06 18:03) [76]
Про триггеры и шаги выполнения - факты известные и простые.
Но смысл состояния "в процессе" они не раскрывают. Ибо шаги 2 и 7 не формализованы, следовательно, можно считать, что порядок изменения записей произвольный или (что то же самое) одновременный.
Таким образом, флаг этот нужен только самому Ораклу для разгребания своих проблем, а не для пользователя/разработчика программ.
Блокировка в этом случае получается даже не для других транзакций, а и для текущей тоже.
Т.е. приходим к заключению, что это блокировка, о которой я говорил.
И фраза "это не блокировка. Просто после изменения первой строки группы выставляется флаг" дает всего лишь определение блокировки другими словами, оставляя неизменным смысл.

← →
ораклоид (2006-06-07 20:15) [78]

Desdechado © (07.06.06 18:48) [77]
ОК. Допустим есть таблица TABLE_1 из 5-ти строк. Есть запрос типа update TABLE_1 set id = id + 1 Есть триггер before update on TABLE_1 for each row, срабатывающий, естесственно, для каждой изменяемой строки. В теле этого триггера есть запрос
select t.id bulk collect into AnyCollection from TABLE_1 t.
Триггер выполняется третий раз. Вопрос, какие зн-я должны попасть в AnyCollection?
После ответа на него уйдут все вопросы про «…разгребания Oracle своих проблем…».

ораклоид (07.06.06 20:15) [78]
Для такой ситуации важен порядок изменения записей, который можно явно определить в этом третьем срабатывании. А т.к. порядок неизвестный, то указанный в триггере запрос - бессмысленный.
Но если ответить более конкретно, то попасть должны значения из измененных записей новые, а из нетронутых - старые, поскольку для некоторых строк триггер уже сработал, а для некоторых - нет. Для текущей срабатываемой записи - старое, т.к. триггер BEFORE.

> После ответа на него уйдут все вопросы
Ответил. Не ушли....

Desdechado © (07.06.06 16:21) [73]
> Я делаю вывод, что "в процессе" - это и есть та самая блокировка.
" процессе" - это бред сивой кобылы, никому не нужный. т.к. порядок изменения произвольный. так что "блокирУй, не блокирУй, все равно получишь" ... ora-XXXX :)
и что за "флаг", который Вы обсуждаете???

а для анализа НАБОРА изменяемых записей ДО и ПОСЛЕ DML есть BEFORE и AFTER STATEMENT-LEVEL триггеры.

> Desdechado ©
о если ответить более конкретно, то попасть должны значения из измененных записей новые, а из нетронутых - старые, поскольку для некоторых строк триггер уже сработал, а для некоторых - нет.
А мне кажется, что именно такойнабор данных очень хорошо сойдет в качестве определения белиберды.
потому как какое ему есть применение?

> Desdechado © (07.06.06 20:52) [79]
> Для такой ситуации важен порядок изменения записей, который
> можно явно определить в этом третьем срабатывании. А т.к.
> порядок неизвестный, то указанный в триггере запрос - бессмысленный.

Здесь 2 фразы, противоречащие друг другу, или я чего-то не понял? Порядок именно важен, но определить его нельзя! Он именно неизвестный, а запрос бессмысленный! А теперь подумай чуть дальше, ты уже сказал ключевую фразу: "запрос - бессмысленный"! Именно в таких случаях оракл и выдает ошибку о "мутации", которую мы уже так долго разбираем.

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

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

> и что за "флаг", который Вы обсуждаете???

Это внутренний флаг, недоступный программисту. Я о нем у Кайта читал, и проведенные эксперименты подтверждают, что он устанавливается именно в момент, указанный в алгоритме [76]. Т.е. если сделать select из той же таблицы в триггере before for each row для случая, когда изменяется/добавляется всего одна запись, ошибки не будет. И это объяснимо. Ведь еще ничего не изменилось.

Petr V. Abramov © (08.06.06 00:03) [81]
evvcom © (08.06.06 08:27) [82]
Это определение белиберды я просто логически вывел, как ответ на вопрос ораклоида. Понятно, что такой запрос бессмысленен, о чем я и сказал. Но бессмысленен он не сам по себе, а в силу невозможности определить порядок изменения записей.
Но тем не менее, при срабатывании триггера на конкретной записи ведь есть уже записи измененные, а есть - неизмененные. О чем я и сказал. Понятно, что в этом случае логическая непротиворечивость и целостность данных не гарантируется, потому и запрос к ней блокируется. Но ведь запрос в триггере можно к этой таблице сделать такой, чтоб явно не затронуть изменяемые записи (уже измененные или еще не измененные, но направленные на изменение). Но Оракл и это блокирует. Что противно.

← →
ораклоид (2006-06-08 13:29) [84]

Desdechado © (08.06.06 12:08) [83]
Бессмысленных запросов не бывает, важно то, с какой целью делается тот или иной запрос. В данном случае цель была просто познавательная. Запрос синтаксису не противоречит, а значит он допустим и должен возвращать однозначный НД.
create or replace trigger TABLE_1_BUER before update on TABLE_1 for each row declare AnyCollection /*некая коллекция*/ begin delete from TABLE_1 t where t.id = :old.id; :new.id := 100; select t.id bulk collect into AnyCollection from TABLE_1 t; end;
И что д.б. в AnyCollection следуя Вашей логике? Хотя бы кол-во эл-тов? :-) А последовательность триггеров? Напишите? :-)

Цитирую Desdechado © (08.06.06 12:08) [83]
Но бессмысленен он не сам по себе, а в силу невозможности определить порядок изменения записей.

А приведенный тобой триггер бессмысленен точно сам по себе. Даже с познавательной точки зрения. На что я процитирую себя еще раз запрос в триггере можно к этой таблице сделать такой, чтоб явно не затронуть изменяемые записи (уже измененные или еще не измененные, но направленные на изменение). Но Оракл и это блокирует. Что противно.

И прошу объяснить причину этого, а не уводить в сторону.

> потому и запрос к ней блокируется.

Не блокируется.

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

Не блокирует. Если ты вдруг (кстати можно это сэмулировать) из 2-ой сессии попытаешься обновить записи изменяемой в 1-ой сессии таблицы, отличные опять же от записей из 1-ой сессии, Оракл тебе отлуп не даст. Для 2-ой сессии таблица неизменяемая. Отлуп даст только если попытаешься обновить уже измененную из 1-ой сессии запись.
Такое объяснение доказывает тебе, что "мутация" - это не блокировка?

← →
ораклоид (2006-06-08 15:23) [87]

> Desdechado © (08.06.06 13:39) [85]
> запрос в триггере можно к этой таблице сделать такой, чтоб
> явно не затронуть изменяемые записи (уже измененные или
> еще не измененные, но направленные на изменение). Но Оракл
> и это блокирует. Что противно.

А как по Вашему Oracle может узнать о том, какие записи изменятся при выполнении запроса? Например, можете ли Вы утверждать, что при выполнении запроса update AnyTable set FieldName = AnyValue where ID = 1 запись с ID = 5 останется неизменной? Я - нет. Oracle - тоже. Например:
create or replace trigger TriggerName before update on TableName for each row begin execute immediate "update TableName set FieldName = null where ID = 5"; end;
В этом случае Oracle узнает об изменении записи с ID = 5 только в момент синтаксического разбора строкового выражения, которое произойдёт только в момент выполнения триггера на уже произошее событие before update. Так что всё далеко не так просто, как кажется изначально.

evvcom © (08.06.06 15:19) [86]
Я говорил о той же самой транзакции, а не о какой-то другой сессии.

ораклоид (08.06.06 15:23) [87]
> всё далеко не так просто
Я и не утверждал, что просто. Имхо, лучше дать возможность изменений на усмотрение разработчика (пусть сам разгребает свои косые запросы с тройной модификацией тех же записей из каскадно срабатывающих триггеров), чем препятствовать ему выполнять нормальные запросы из соображений "как бы чего не вышло". Если оракл такой умный, зачем тогда в нем столько ошибок?

> Я говорил о той же самой транзакции, а не о какой-то другой
> сессии.

Просто ты утверждаешь, что это блокировка, а я доказываю, что нет, т.к. из другой сессии ошибку ты не получаешь.
Зря ты упираешься. Я так понимаю, что тебе уже просто не хочется признаваться, что фраза твоя об "оракле-блокировочнике" брошена то ли сгоряча, то ли в попыхах... Ты столкнулся с проблемой, толком в причинах не разобрался, это тебе не понравилось, вот и рубанул.
Продолжать этот спор в дальнейшем не вижу смысла. Если есть вопросы, могу ответить, объяснить, но спорить более не буду. Хочешь думать по-своему, твое дело...

Да я и не спорю вовсе. Просто хочется разобраться.

Ну и пожаловаться на эту хрень... :/

Методы обхода и способы обработки известны, норадости-то все равно не доставляют...

> Ну и пожаловаться на эту хрень... :/

Хуже было б, если Оракл не давал бы об этом знать, а тихо выполнял то, что от него просят, при этом результат был бы непредсказуемым.

> Методы обхода и способы обработки известны

Да не так уж и часто приходится ими пользоваться.

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

Возникла необходимость ознакомиться с Oracle Найти похожие ветки