Шаг вывода таблицы Pentaho не показывает правильную ошибку в журнале

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

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

Мой вопрос: есть ли в Pentaho способ определить, что при сбое вставки db, какие именно значения вызвали проблему и почему?

РЕДАКТИРОВАТЬ: ошибка «Превышена ширина столбца», и она показывает мне значения, которые предположительно вызывают проблему. Но я сделал оператор вставки с этими значениями, и он работает хорошо. Поэтому я думаю, что Pentaho не показывает мне правильное сообщение об ошибке, проблема связана с другим набором значений.


netezza pentaho
person Victor    schedule 24.01.2014    source источник
comment
Полагаю, я бы сказал, что у вас есть повторяющиеся значения в вашем входном наборе. Таким образом, вы загружаете значение ключа, а затем через несколько строк пытаетесь загрузить одно и то же значение и получаете ошибку повторяющегося ключа. Если это так, и вы не можете получить дубликаты из своего входного набора, вы можете отфильтровать их с помощью шага Unique Values. Если ваша проблема не связана с ошибкой дублирования ключа, напишите, что это такое.   -  person Brian.D.Myers    schedule 25.01.2014
comment
Спасибо, не могли бы вы посмотреть мой EDIT и посмотреть, поможет ли он отлаживать.   -  person Victor    schedule 25.01.2014
comment
Похоже, @carexcer в курсе. Также было бы полезно опубликовать DDL таблицы, которую вы пытаетесь загрузить. И когда вы «создали и вставили оператор с этими значениями», вы скопировали значения непосредственно из журнала ошибок?   -  person Brian.D.Myers    schedule 26.01.2014

Ответы (3)


arrow_upward
1
arrow_downward

Еще один способ, который я использовал для решения подобных проблем, — создать еще одну таблицу в БД с расширенными типами столбцов. Затем в своем преобразовании добавьте шаг Table output, связанный с новой таблицей. Затем подключите исходный Table output к новому шагу, но при появлении запроса выберите «Обработка ошибок» в качестве типа прыжка.

Когда вы запустите свое преобразование, оскорбительные строки окажутся в новой таблице. Затем вы можете точно выяснить, в чем проблема с этой конкретной строкой.

Например, вы можете сделать что-то вроде:

insert into [original table] select * from [error table];

Вы, вероятно, получите лучшее сообщение об ошибке от собственного интерфейса БД, чем от драйвера JDBC.

person Brian.D.Myers    schedule 26.01.2014
comment
отличная идея, попробую в понедельник первым делом - person Victor; 26.01.2014
comment
Еще одна вещь, которую вы можете сделать, если вам нужно, это поместить счетчик последовательности вверх по течению вашего преобразования и добавить столбец в вашу таблицу ошибок для его хранения. Затем, когда строка поступает в вашу таблицу ошибок, вы точно знаете, какая именно из вашего набора входных данных нарушается. - person Brian.D.Myers; 27.01.2014

arrow_upward
1
arrow_downward

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

Все кажется правильным, но проблема заключалась в том, что в некоторых преобразованиях, когда я преобразовывал числовое значение в строку, например, преобразование добавляло пробел в конце поля, а длина поля была n+1 вместо n, но это очень трудно увидеть.

Практическим примером может быть то, что если вы выполняете преобразование с помощью шага калькулятора, вы можете использовать функцию YEAR() для извлечения года из поля даты, и, возможно, к этому новому полю с годом были добавлены пробелы, поэтому, если год имел длину из 4, после этого шага он будет иметь длину 5, и когда вы собираетесь загрузить строку (с этим полем года, которое равно string(5)) в хранилище данных, а в вашем хранилище данных ожидается string(4), вы получите та же ошибка, что и сейчас.

You think is happening --> year = "2013"   --> length 4
Really is happening    --> year = "2013 "  --> length 5

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

Я надеюсь, что это может быть полезно для вас!

РЕДАКТИРОВАТЬ: я предполагаю, что вы работаете с PDI (Spoon, до Kettle), и ошибка возникает при загрузке хранилища данных, поэтому поправьте меня, если я ошибаюсь.

person carexcer    schedule 25.01.2014
comment
Спасибо, я проверил каждое поле, я думаю, что значения, которые отображаются в журнале как «проблемные значения», не являются проблемой. Фактические значения, которые вызывают проблему, не отображаются в журнале. - person Victor; 25.01.2014
comment
Можете ли вы предоставить полную ошибку, которая обеспечивает журнал? Вероятно, вы правы, но если я увижу полное сообщение об ошибке, я смогу помочь вам больше. Если вы можете предоставить шаги, которые вы используете, было бы лучше, потому что некоторые пошаговые преобразования имеют проблемы и иногда необходимы для использования альтернативных способов выполнения некоторых действий. - person carexcer; 25.01.2014
comment
Большое спасибо, я так и сделаю. Еще раз спасибо, чувак, ценю твою помощь. - person Victor; 26.01.2014

arrow_upward
0
arrow_downward

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

e.g. - 

nzload -u <username> -pw <password> -host <netezzahost> -db <database> -t <tablename> -df <datafile> -lf <logfile> -bf <badrecords file name> -delim <delimiter>
person Varun Bajaj    schedule 27.01.2014