|
|
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan Rabashchenko...Просто в начале пакета сделать фейковую функцию вида... IMHO жесть какая Не проще пакет на несколько пакетов разделить? Ну и самый интересный вопрос: а что говорит Oracle Support на эту багу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 19:38 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
А эти неправильные значения в коде не встречаются случайно? Может тупо переполнение индекса идет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 20:41 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Леонид, нет не проще. Для этого нужно изменить не только код генератора пакетов, но и всю парадигму системы, а это тьма кода, который работает поверх этих нелепых, неповоротливых, гигантских пакетов. К этому добавлю, что нарвались мы на этот bug только лишь у одного клиента (а их сонм), у которого и OS и БД знакомые (связка такая много у кого Solaris + 11.2.0.4) и затевать глобальный рефакторинг это очень смелый и дорогой шаг. Возможно, обойдемся малой кровью. Сначала решил сам поколупаться - не получилось (не хватает знания матчасти) , затем решил спросить умных людей (спасибо всем кто откликается), если решения не найдем, зарегим официальную ноту на Oracle Support. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 20:48 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
xtenderА эти неправильные значения в коде не встречаются случайно? Может тупо переполнение индекса идет Вполне возможно, на сегодня забрали доступ, завтра с утра предоставлю такую информацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 20:54 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan Rabashchenko, А можете попробовать с числом 268435455 и написать полученный результат? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 20:54 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
MaximaXXLIvan Rabashchenko, А можете попробовать с числом 268435455 и написать полученный результат? Мне наверное стоило в моем первом комментарии уточнить вот такой факт: Если оперировать не большими числами, например: Код: plsql 1. 2. 3. 4. 5. 6. то все работает корректно независимо от положения в пакете. А если 268435456, например, то натыкаемся на некорректное поведение. Чтобы было понятнее, структура пакета такая: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. и получается, что fIr$Tmp_110 и fIr$Tmp_112 возвращают ересь, а fIr$Tmp_111 - норм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 21:16 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Расплющенная принцессаIvan RabashchenkoStarting with release 7.3.4, the DIANA for package bodies is thrown away, not used, and not stored in the databaseЭто откуда? Смотри в доке plsql лимиты, там есть что посчитать. По объему parsed_code грозятся ошибкой pls-123. И она даже возникает. Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 21:35 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan Rabashchenko, А если включить Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 21:35 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
К сожалению, только завтра смогу все проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 21:48 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan Rabashchenko, еще можно попробовать дропнуть полностью пакет и заново создать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 22:44 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan RabashchenkoДля этого нужно изменить не только код генератора пакетов, но и всю парадигму системы, а это тьма кода, который работает поверх этих нелепых, неповоротливых, гигантских пакетов. Как программист - не понимаю. Если с размером specification проблем нет, а только с размером body, то никто не мешает точку входа в API оставить в одном пакете. Сделать пакет-прокси со старым именем, который просто будет вызывать функции из других пакетов. Код приложения, кроме генератора, менять не нужно Единственная проблема чисто технического разделения - возможные связи между private (не вынесенные в спецификацию) функциями и глобальные переменные в пакете. Лично я бы, первым делом, все глобальные переменные из пакета вынес в отдельный пакет (что бы на них всегда можно было ссылаться из всех генерированных пакетов), дальше бы разбирался, какие блоки функций можно отделить друг от друга. Сомневаюсь, что все 100 000 строк сгенерированного кода настолько сильно связаны друг с другом, что их не разделить. Второе возможное решение, запрос в Oracle и фиксенье бага. Поиск мелодии для бубна, который заставит обратно заработать систему у одного неудачливого заказчика.... это конечно хорошо, но как-то вызывает опасение. Если один раз свалилось на 100 000 строк кода, то кто может гарантировать, что в следующий раз не свалится на пакете в 101 000 строк кода и прошлогодняя мелодия и бубен поможет и в следующий раз? IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2017, 23:06 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
xtender А эти неправильные значения в коде не встречаются случайно? Может тупо переполнение индекса идет Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Есть такое. Чем мне (нам) этот факт может помочь? MaximaXXLIvan Rabashchenko, А можете попробовать с числом 268435455 и написать полученный результат? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ожидаемо, некорректный результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 09:40 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
andreymxIvan Rabashchenko, еще можно попробовать дропнуть полностью пакет и заново создать Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 09:48 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Ivan Rabashchenko, а так? :) Код: plsql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 10:07 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
andreymxIvan Rabashchenko, а так? :) Код: plsql 1. 2. 3. 4. 5. 6. Намекаете, что drop не отрабатывает? Код: plsql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 10:25 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Предполагаю, что проблема в количестве констант (нод). Возможно малая константа имеет в пкоде "непосредственную адресацию". Более 16 бит заносится в некую хеш-таблицу. При превышении количества 32767/65535 констант результат парса теряется. На выполнении из хеш-таблицы выбирается по индексу младших 15/16 бит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 10:31 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Код: plsql 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. 30. 31. 32. 33. 34. 35. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 10:43 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopIvan Rabashchenko, А если включить Код: plaintext Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 10:49 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopРасплющенная принцессапропущено... Это откуда? Смотри в доке plsql лимиты, там есть что посчитать. По объему parsed_code грозятся ошибкой pls-123. И она даже возникает. Код: plsql 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. Указанный вам пример порождает PLS-00123 и у меня на разных платформах (Win\Linus\Solaris + 11.2.0.4\12.1.0.2) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:03 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:06 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
-2-Предполагаю, что проблема в количестве констант (нод). Возможно малая константа имеет в пкоде "непосредственную адресацию". Более 16 бит заносится в некую хеш-таблицу. При превышении количества 32767/65535 констант результат парса теряется. На выполнении из хеш-таблицы выбирается по индексу младших 15/16 бит. О, это уже горячо. Уважаемый, -2-, подскажите пжл документ, в котором указано такое ограничение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:15 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
StaxIvan Rabashchenko, на правах версии переполняется "таблица констант" если в конец пакета добавить еще одну ф-цию fIr$Tmp2 с константой (напр 268435457), они будут правильно работать? ps перемещая по телу пакета ф-цию, возможно можно определить когда перестает работать ..... stax Мне сразу дали намек, а его не понял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:21 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
-2-, Имхо не хэш а переполнение индекса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:36 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
Читаем доки PL/SQL Program Limits ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 11:48 |
|
||
|
Странное поведение переменных в пакетах, с большим количеством строк
|
|||
|---|---|---|---|
|
#18+
-2-Предполагаю, что проблема в количестве констант (нод). Возможно малая константа имеет в пкоде "непосредственную адресацию". Более 16 бит заносится в некую хеш-таблицу. При превышении количества 32767/65535 констант результат парса теряется. На выполнении из хеш-таблицы выбирается по индексу младших 15/16 бит. Имхо как-то так должно быть:-2-Предполагаю, что проблема в количестве констант (нод). Возможно малая константа имеет в пкоде "непосредственную адресацию". Для оптимизации, константы Более 16 бит заносятся в некий массив, а вместо константы указывается ее индекс в этой таблице. На выполнении из-за переполнения из массива выбирается по индексу младших 15/16 бит. PL/SQL Program LimitsЧитаем доки PL/SQL Program Limits лимита на количество литералов там нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2017, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39566197&tid=1884763]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 356ms |

| 0 / 0 |
