table2 t2, table3 t3 - таблицы с уникальными id
table4 t4 - подзапрос, возвращающий единственную запись для table3 t3

t1.t2_id - уникальный в таблице t1, t1.t3_id - не уникальный (рояли не играет, данные просто для красоты)

--этот запрос - кривой
update table1  t1
set field1 =
(select
t2.field2
from table2 t2, table3 t3, table4 t4
where t2.id = t1.t2_id
   and t3.id = t1.t3_id
   and t4.id = t1.t3_id
)

--этот отрабатывает нормально
update table1  t1
set field1 =
(select
t2.field2
from table2 t2, table3 t3, table4 t4
where t2.id = t1.t2_id
   and t3.id = t1.t3_id
   and t4.id = t3.id
)

наблюдение показало, что роль играет связка t3.id = t1.t3_id  and t4.id = t1.t3_id - эта вот связка глючит, и, я так понимаю, глючит соединение с t4.id.

почему, не пойму.

планы в студию

> --этот запрос - кривой
> update table1  t1
> set field1 =
> (select
> t2.field2
> from table2 t2, table3 t3, table4 t4
> where t2.id = t1.t2_id
>    and t3.id = t1.t3_id
>    and t4.id = t1.t3_id
> )
>
> --этот отрабатывает нормально
> update table1  t1
> set field1 =
> (select
> t2.field2
> from table2 t2, table3 t3, table4 t4
> where t2.id = t1.t2_id
>    and t3.id = t1.t3_id
>    and t4.id = t3.id
> )


> t1.t3_id - не уникальный (рояли не играет, данные просто
> для красоты)

как раз-таки играет, в первом случае запрос вернет столько записей, сколько t3_id в t1(т.е. сколько угодно от нуля до бесконечности), во втором - не больше одной (при условии, что остальные связки возвращают по одной, конечно)

> Игорь Шевченко ©   (11.12.10 12:41) [1]

планы, увы... одинаковы. да не в планах дело. но я попробую, не сей час, и с работы не могу


> Petr V. Abramov ©   (11.12.10 17:23) [2]

всего одну. это подзапрос с историей на дату по ID. все жестко связано. второй раз  на такую забавную штучку натыкаюсь, хорошо, хоть полнял, где оно происходит.

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

>Паша   (11.12.10 02:29)  
что значит "кривой"? в подробностях.
про одинаковые планы верится с трудом - в студию уже попросили.
желательно вместе с desc t1, desc t2, desc t3, desc t4 и ключами.
в общем случае, это разные запросы и ничего удивительного в том, что они возвращают разный результат, нет.

PS для оформления кода лучше-таки пользоваться спец. тегами.

> Кщд   (12.12.10 08:51) [4]


увы, плана сейчас нет, и будет, ну разве шо во вторник%). а хочется прям счаз!

я тут подозреваю, что шо-то в логике глючит у оракла. или у меня.

но! таблица, на которой глючит (а именно table4) имеет уникальную связку как с ведущей table1, так и с table3, через которую (в случае правильной отработки запроса я ее и прицепил). т.е. логика запроса тут не страдает. а получается, по-факту - рвет этот запрос на куски, как Тузик грелку.

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

а, да! шо такое - кривой? так он работает криво. для наглядности, беру конкретную живую айдишку

update table1  t1
set field1
*****
where t1.id = 1
return field1

и в первом случае null, а во втором - то, что нужно. хэх, я народу на работе показывал - народ чешит рэпу...

зы. три строчки еще и тэгами - а оно нужно?

>Паша   (12.12.10 17:01) [5]
1. desc t1, t2, t3, t4;
2. PK, UQ, FK ключи, not null constraint на поля, участвующие в запросе;
3. планы.
после этого можно начать разбираться в проблеме.

читать эту галиматью с самовыдуманной терминологией и "кривой" диагностикой проблемы не интересно

PS а коли Вам лень дернуть мышкой, чтобы Ваш код был читаем, а не как в "Паша   (11.12.10 02:29)", то лично мне в этом случае незачем и пытаться Вам помочь. "чешите репу" друг другу с коллегами и дальше.

> Кщд   (12.12.10 19:20) [6]


> то лично мне в этом случае незачем

а я лично Вас просил? и о чем, если не секрет? увы мне, увы... так что желаю Вам удачи!

зы. и, казалось бы, при чЁм тут PK, UQ, FK ключи, not null constraint на поля? слова, конечно мне знакомые, но как они могут в данном конкретном случае на что-то повлиять - не понимаю.

> Паша   (12.12.10 19:54) [7]
>
>

ты в студию давай, понимать потом будешь.
и вопрос сформулируй не "криво-не-криво", а "ожидалось то-то, вижу сё-то"

Безусловно, это глюк Оракла. А как же. Там 101 950 служащих (на 2010 год) насчитывается, как они могут нормальный продукт-то написать?
Вот Паша - другое дело.

>Ega23 ©   (13.12.10 12:01) [9]
тем не менее, баг оптимизатора вероятен.
их в 8-ке было прилично, в 9-ке поменьше, но таки имелись.
вспомнить хотя бы забавное поведение при outer join синтаксисе(не (+)).
можно вспомнить индусский код в системных(dbms, а не третьесторонних utl) с: if var=null then...
но, увы, автор вместо подробностей предпочитает "чесать репу", что - вероятно - приятно всем "коллегам", но к сожалению мало способствует решению проблемы))

> тем не менее, баг оптимизатора вероятен.


Вероятен. Но - маловероятен. Гораздо более вероятно другое.

>Ega23 ©   (13.12.10 12:55) [11]
подождем, когда(и если) автор обнажит детали

> Ega23 ©   (13.12.10 12:01) [9]
>
> Безусловно, это глюк Оракла. А как же. Там 101 950 служащих
> (на 2010 год) насчитывается

за этот глюк 1450 уволят

> Кщд   (13.12.10 12:34) [10]


> тем не менее, баг оптимизатора вероятен


ага... вот это уже ближе к телу. но планы обеих запросов выдают на удивление одинаковый результат. т.е. идентичны.

я еще буду думать в этом направлении, как время появится, счаз немного некогда. хочу попробовать свести эту песню к чему-то вполне очевидному.

уже второй раз нарываюсь на такую неприятность в девятке, переписывая цикл в update методом копи-пасте. для ускорения работы. да, время порадовало, но результаты - отнюдь.


> Ega23 ©   (13.12.10 12:55) [11]


> Гораздо более вероятно другое.

да ты шо? вероятно? удивил! гыгы

Паша, ака Старый Маразматик

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

>Паша   (15.12.10 00:20) [14]
>но планы обеих запросов выдают на удивление одинаковый результат
лог снятия плана из sqlplus, пожалуйста
и опять никаких данных по теме - слова, слова, слова
что ж, сваливайте всё на оптимизатор и продолжайте гадать на кофейной гуще

> лог снятия плана из sqlplus

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

однако, план обеих запросов - а его ж, таки, можно и без этого плюса сделать, та хоть и execute plan? показывает на удивление одинаковые результаты.

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

зы. на оптимизатор я как-то ничего не сваливал? это таки Ваше предположение? и я его всебоко принял к рассмотрению, однако - не в кассу...
а на кофейной-то - ну, не мой метод! мне всяко ближе метод научного тыка. гыгы

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

зы. анекдот:
поставили нам десятку. ну я не в курсе, шо там эти чудики натворили, но! есть таблица в три поля, два number, третье - varchar2. запрос типа select * ругается на невозможность преобразования в число, что естественно - там их и быть не может, с в третьем-то поле. т.е. можно было или нумберы выводить, или варчары, но по отдельности. во какие умельцы бывают! потом починили, но шо они сделали - сами не знают. абыдна, да?


> Кщд   (15.12.10 05:02) [15]

а насчет слов... года три-четыре назад тезка мой, Паша Голуб, от меня тут вопрос задал насчет математического округления (round криво работал в пятерке), и как его нормально в дельфях реализовать (у меня временно сюдой доступа не было). казалось бы, все просто? и шо тут было? начиная с того, как округляет интел, и кончая неописуемым количеством вариантов оного. буков на две страницы. и даже подрались. или нет? нет, ну не могли не подраццо, значит таки подрались. когда я сюда влез (уже порешав вопрос, там три строчки кода всего), улыбнуло.

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