Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
Привет, коллеги.

Если у кого-то есть 11g на AIX, убедительная просьба развернуть у себя прикрепленный дамп таблицы TEST (выполнен простой EXP из схемы SAV) в свою версию и выполнить незатейливый стейтмент

select to_char(val_num) from test;

Еще просьба посмотреть чему равно значение в строках где, например, ATTR=48. Смотреть в графической тулзе (Navigator или Developer) - это ВАЖНО(!).

О результате сообщите, если не трудно.

Теперь объясню в чем дело. Переехали с девятки, там проблем не было. На 11g (11.2.0.1.2, удалось воспроизвести ТОЛЬКО путем exp/imp и на 11.2.0.2) сервер клиенту возвращает несколько строк, далее клинч и в результате ORA-12152 или ORA-03113. Что интересно, гуя показывают, что в поле NUMBER есть строки со значением, например, 16.60000000000000142108547152020037174225, что уже странно.

Поддержка (вендор, не Metalink) воспроизвести не смогла. Я же воспроизвожу легко двумя методами; exp/imp и create as select.

В общем жду результатов с указаниями версии от вас.

К сообщению приложен файл (test.dmp - 8Kb) cкачать
29 окт 10, 13:04    [9699698]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Зелебоба,

ваша миграция не включала ли изменение кодировки (основной или национальной)?
29 окт 10, 13:24    [9699948]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Зелебоба
..Еще просьба посмотреть чему равно значение в строках где, например, ATTR=48. Смотреть в графической тулзе (Navigator или Developer) - это ВАЖНО(!).
..

смотреть лучше (всё равно в какой среде) на
dump(колонка)
29 окт 10, 13:29    [9700014]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Elic
Member

Откуда:
Сообщений: 29976
Зелебоба
16.60000000000000142108547152020037174225, что уже странно.
Вполне допустимое число. Именно оно там и "лежит". И что в нём странного?
29 окт 10, 13:33    [9700064]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
orawish
Зелебоба,

ваша миграция не включала ли изменение кодировки (основной или национальной)?


нет, ничего не менялось...
29 окт 10, 13:57    [9700350]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
Elic
Зелебоба
16.60000000000000142108547152020037174225, что уже странно.
Вполне допустимое число. Именно оно там и "лежит". И что в нём странного?


Oracle guarantees the portability of numbers with precision of up to 20 base-100 digits, which is equivalent to 39 or 40 decimal digits depending on the position of the decimal point.

Разве в этом случае decimal digits не должно быть 39?
29 окт 10, 14:14    [9700526]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
Еще один момент. Что может значить такое для NUMBER?

SQL> select min(length(val_num)) from test;

MIN(LENGTH(VAL_NUM))
--------------------
                  -1
29 окт 10, 14:16    [9700563]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3778
Зелебоба,

$ oslevel -r
6100-04

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select attr,to_char(val_num) from test;

      ATTR TO_CHAR(VAL_NUM)
---------- ----------------------------------------
         1 1
         2 1
         3 0
         4 1
         5 1
         6 4
         7 1
         8 9
         9 1
        10 1
        11 1

      ATTR TO_CHAR(VAL_NUM)
---------- ----------------------------------------
        12 1
        13 1
        14 1
        15 2
        16 2
        17 94
        18 0
        18 1973
        20 2
        21 6190
        22 4

      ATTR TO_CHAR(VAL_NUM)
---------- ----------------------------------------
        23 3
        24 82
        26
        27 5
        27 1
        42 6941
        47 11,88
        47 15,6
        47 16,6000000000000014210854715202003717423
        47 16,9200000000000017053025658242404460907
        47 21,0199999999999995736743585439398884773

      ATTR TO_CHAR(VAL_NUM)
---------- ----------------------------------------
        47 22,92
        48 11,78
        48 15,6
        48 16,6000000000000014210854715202003717423
        48 16,9200000000000017053025658242404460907
        48 21,0199999999999995736743585439398884773
        48 22,92
        67 0
        70 138
        71 18
        72

      ATTR TO_CHAR(VAL_NUM)
---------- ----------------------------------------
        72
тут залипло все нафиг
29 окт 10, 14:36    [9700777]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
Андрей Панфилов,

отлично! значит меня поддержка водит за нос.
29 окт 10, 14:50    [9700941]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Elic
Member

Откуда:
Сообщений: 29976
Зелебоба
MIN(LENGTH(VAL_NUM))
--------------------
                  -1
Круто.
Elic@elic11> select attr,val_num,length(val_num),to_char(val_num), dump(val_num) from test where length(val_num)<=0;

         ATTR       VAL_NUM LENGTH(VAL_NUM) TO_CHAR(VAL_NUM)
------------- ------------- --------------- ----------------------------------------
DUMP(VAL_NUM)
---------------------------------------------------------------------------------------------------------------------
           97          2.93              -1         ЂІв
 Їв
cэХ        ёоѕШтѕ
Typ=2 Len=21: 193,3,94,1,1,1,1,1,1,2,60,88,22,16,55,61,23,55,19,22,1


Elic@elic11> select attr,val_num,length(val_num),to_char(val_num), dump(val_num) from test where attr in (97,95);

         ATTR       VAL_NUM LENGTH(VAL_NUM) TO_CHAR(VAL_NUM)
------------- ------------- --------------- ----------------------------------------
DUMP(VAL_NUM)
---------------------------------------------------------------------------------------------------------------------
           95         66914               5 66914
Typ=2 Len=4: 195,7,70,15

           97          2.93              -1                                    66914
Typ=2 Len=21: 193,3,94,1,1,1,1,1,1,2,60,88,22,16,55,61,23,55,19,22,1
Видно, что лажает на стороне сервера и по-разному в зависимости от контекста.
Скорее всего, причиной является ненормализованная мантисса (наличие в мантисе незначащего нуля).
Elic@elic11> select val_num*1, dump(val_num*1) from test where attr in (97);

    VAL_NUM*1
-------------
DUMP(VAL_NUM*1)
------------------------------------------------------------------------------
         2.93
Typ=2 Len=20: 193,3,94,1,1,1,1,1,1,2,60,88,22,16,55,61,23,55,19,22
В любом случая, не стоит хранить кривые данные.

К сообщению приложен файл. Размер - 0Kb
29 окт 10, 14:54    [9700987]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
Elic

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


Дело в том, что create table ... as select воспроизводит запросто. Экспорт/импорт тоже. select round(val_num,38) тож зависает.

И как в таких случаях лечить прикажете? Ну ладно там записей с гулькин хрен, можно пролечить нагенерив инсертов. А если б там терабайты?
29 окт 10, 14:59    [9701057]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Elic
Зелебоба
MIN(LENGTH(VAL_NUM))
--------------------
                  -1
Круто.
..
В любом случая, не стоит хранить кривые данные.

+1

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

затычки:
1) не использовать экспорт
2) перед экспортом чиселки укоротить
29 окт 10, 15:21    [9701265]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Зелебоба
Member

Откуда:
Сообщений: 1121
orawish
Elic
Зелебоба
MIN(LENGTH(VAL_NUM))
--------------------
                  -1
Круто.
..
В любом случая, не стоит хранить кривые данные.

+1

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

затычки:
1) не использовать экспорт
2) перед экспортом чиселки укоротить


В исходной базенке 9.2.0.8 та же картина, но результат другой. :) Там нет затыков.
29 окт 10, 15:28    [9701345]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
Зелебоба

..
В исходной базенке 9.2.0.8 та же картина, но результат другой. :) Там нет затыков.

пока эффект не ликвидировали - вытряхните в бинарном формате пару таких (кривых) блоков.
народ оценит. например, помнится, DBA хотела на них посмотреть
29 окт 10, 15:33    [9701377]     Ответить | Цитировать Сообщить модератору
 Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
Elic
Member

Откуда:
Сообщений: 29976
Зелебоба
Дело в том, что create table ... as select воспроизводит запросто. Экспорт/импорт тоже.
orawish
вообще, экспорт иногда круто зажигает..
Вообще-то, CTAS, exp, imp не преобразуют внутренний формат числа. А тупо передают это нечисло по цепочке.
Скорее:
  • данные попортились на исходном сервере из-за какого-нибудь бага
  • (более вероятно) были так предоставлены кривым клиентом. (Кто помнит, например, проблему 100n).


    Зелебоба
    И как в таких случаях лечить прикажете?
    Я ж показал, как (*1).
  • 29 окт 10, 16:00    [9701601]     Ответить | Цитировать Сообщить модератору
     Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
    orawish
    Member

    Откуда: Гадюкино-2 (City)
    Сообщений: 15487
    Elic
    orawish
    вообще, экспорт иногда круто зажигает..
    Вообще-то, CTAS, exp, imp не преобразуют внутренний формат числа. А тупо передают это нечисло по цепочке..

    я тут вспомнил грабли, на которые в свое время на 9i.2.0.4(или_5 склероз )
    налетел. смысл - из однобайтовой базы в уникодную переносились данные. спецификация столбцов и на источнике и на мишени была одинаковая ~varchar2(10 byte).
    так данные, у которых новая длина в байтах превышала ту спецификацию колонки.. влезли. ну а после этого любой дмл над такими строками заканчивался (вернее, видать, начинался ) с ошибки про превышение длины данных.
    29 окт 10, 17:08    [9702228]     Ответить | Цитировать Сообщить модератору
     Re: ORA-12152 При конкатенации полей с неявным преобразованием.  [new]
    Elic
    Member

    Откуда:
    Сообщений: 29976
    orawish
    я тут вспомнил грабли - из однобайтовой базы в уникодную переносились данные. спецификация столбцов и на источнике и на мишени была одинаковая ~varchar2(10 byte).
    так данные, у которых новая длина в байтах превышала ту спецификацию колонки.. влезли. ну а после этого любой дмл над такими строками заканчивался (вернее, видать, начинался ) с ошибки про превышение длины данных.
    Из той же оперы: ctas из линка же на mssql (или т.п.) - и в not null столбце спокойно (до первого exp/imp, например) живут null-ы.

    Oracle не проверяет там, где вроде () как и не надо :)
    29 окт 10, 17:29    [9702408]     Ответить | Цитировать Сообщить модератору
    Все форумы / Oracle Ответить