|
|
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
hi all LI-T3.0.0.30967 DDL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. DML-1 ("просто update"): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. DML-2 (merge, который должен привести вроде бы к тому же самому результату): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Сравниваю с Ora 11.2.g : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Any comments ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2014, 23:25:00 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
ТаблоидAny comments ? Оракул закэщировал результат подзапроса как инвариант, иначе результат был бы тем же. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2014, 23:38:24 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Таблоид, я попробовал без таблицы t2 Код: sql 1. 2. 3. 4. 5. 6. 7. Код: sql 1. Код: plaintext 1. 2. 3. 4. 5. Dimitry Sibiryakov, инвариант инвариантом, но для запроса Код: sql 1. даёт результат правильный и не факт что там инвариант был закэширован ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2014, 23:49:27 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Симонов Денисне факт что там инвариант был закэширован План посмотри, там должно быть это видно. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2014, 23:55:04 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, не там не там не кэшируется для MERGE Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. для UPDATE Код: plaintext 1. 2. 3. 4. 5. 6. стабильность курсора Влад решал не через материализацию, а зачсёт раскрутки undo лога. Ну если это не так путь он меня поправит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 00:04:01 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Код: sql 1. 2. 3. 4. 5. 6. 7. я приводил план для вот такого запроса (слегка изменённого). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 00:11:55 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Симонов Денисдля запроса Код: sql 1. даёт результат правильныйв датском королевстве у "просто" апдейта, кажись, тоже трудности имеются. Код: sql 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Код: sql 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 01:28:05 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
пардон, первый вариант апдейта такой: Код: sql 1. (РАВЕНСТВО вместо неравенства). Занятно, что ФБ 2.5 выполняет его правильно : Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 01:32:41 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Вот попроще пример: FB: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Oracle: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 01:50:12 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
"Хьюстон, у нас проблемы". В следующем DML поле ` y ` меняется на значение скалярного запроса select count(*), в котором это поле ВООБЩЕ НЕ УПОМИНАЕТСЯ. Ну, и смотрим результат: FB 3.0: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Oracle 11.2g: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. FB 2.5 выдаёт результат, как Oracle. Чё-то в трёшке снова поломалось, КМК... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 01:59:16 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
И на десерт еще немного. FB: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Oracle: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Пойду вздремну слегонца. Всем приятных сновидений. "I'llbe back!" (C) :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 02:30:06 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
ТаблоидЧё-то в трёшке снова поломалось, КМК... Это не в трёшке поломалось, а у тебя в столбце Х две четвёрки, так что результат вполне правильный. Поспать - правильное решение для этой проблемы. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 02:42:39 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovПлан посмотри, там должно быть это видно. не отображается это в плане ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 09:25:53 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovТаблоидЧё-то в трёшке снова поломалось, КМК... Это не в трёшке поломалось, а у тебя в столбце Х две четвёрки, так что результат вполне правильный. Поспать - правильное решение для этой проблемы.Да,перегрелся я вчера :( 2 IP / WS : потрите, плз, к ЧМ мои посты, начиная от 15731769 и до этого. Выглядят бестолковым шумом, всё там ОК с апдейтами. :-[ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 10:52:28 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
dimitrне отображается это в плане Мне почему-то показалось, что Денис запускал запрос на Оракуле... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 12:18:59 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Результат merge как-то связан с физической раскладкой записей Вот скрипт, который пересоздаёт эти две таблицы с пятью строками, укладывая их каждый раз в random_порядке, и делающий этот самый merge. "Результат превосходит ожидания": он такой же случайный, как и порядок записей в таблицах t & t2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. run Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 13:40:16 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Блин, оберни уже своё (select count(*) from t where x<>y) в детерминированную функцию... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:10:55 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
и чё, на каждый такой мёрдж свою детерм. ф-цию ваять ? ;-) Странное дело: если мёрдж реализован как что-то типа этого: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. - то каким образом в нём вообще возникает вышепоказанная хрень ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:28:25 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, тут битва ведь не за результат конкретного запроса, а за правильность выполнения любого запроса как бы он не был записан и что бы там не думал оптимизатор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:37:10 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Таблоиди чё, на каждый такой мёрдж свою детерм. ф-цию ваять ? ;-) Не на каждый. Достаточно на один, чтобы до тебя дошёл смысл первого ответа в этой теме. Таблоидесли мёрдж реализован как что-то типа этого С какого перепугу он так должен быть реализован? Он делается так: Код: sql 1. 2. 3. 4. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:40:11 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Симонов Денистут битва ведь не за результат конкретного запроса Угу, тут битва за право мучить хреново спроектированную базу дерьмозапросами и чтобы было всё так как хочется левой пятке. В морг. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:45:17 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov битва за право мучить хреново спроектированную базу дерьмозапросами и чтобы было всё так как хочется левой пятке. В морг.Не, погодь! Тут битва за стабильность курсора как бэ... Вековая мечта почти сбылась, осталось поднажать еще чуток... ЗЫ. И какие бы дерьмозапросы не сыпались в базу, если они синтаксически корректны, то результат их должен быть ПРАВИЛЬНЫМ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:49:32 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
ТаблоидНе, погодь! Тут битва за стабильность курсора как бэ... Стабильность курсора это в пределах одного запроса. На подзапросы она не распространяется ни в птице, ни в оракуле. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 14:59:47 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, да ну? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 15:06:14 |
|
||
|
merge: не совпадают результаты FB и Oracle (again cursor stability ?)
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovСтабильность курсора это в пределах одного запроса . На подзапросы она не распространяется ни в птице, ни в оракуле.Может, всё же в пределах одного стейтмента , а не запроса ? http://tracker.firebirdsql.org/browse/CORE-3362 SQL Standard <...> requires that set of records which will be affected by UPDATE\DELETE statements should be evaluated first and real action (UPDATE or DELETE) should use this stable recordset. I.e. action implementation should not affect updating recordset in any way. PS. В орацле ты не добьёшься случайных результатов вышепоказанного мёрджа, если будешь заталкивать в таблицу строки в random-порядке: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2014, 15:19:05 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38587483&tid=1563795]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 403ms |

| 0 / 0 |
