Selvaganesan Govindarajan created TRAFODION-2854:
----------------------------------------------------
Summary: Load encounter Operating system error 201
Key: TRAFODION-2854
URL: https://issues.apache.org/jira/browse/TRAFODION-2854
Project: Apache Trafodion
Issue Type: Bug
Components: sql-exe
Reporter: Selvaganesan Govindarajan
Assignee: Selvaganesan Govindarajan
Fix For: 2.3-incubating
Load data from hive data encounter 201 error, but using uspert using load the
error is different
>>load with log error rows to '/bulkload/logs' into
>>TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from
>>hive.hive.DM_FUNCTION_LOCATION;
Task: LOAD Status: Started Object: TRAFODION.ODS_SC.DM_FUNCTION_LOCATION
Task: CLEANUP Status: Started Time: 2017-12-15 10:04:17.366
Task: CLEANUP Status: Ended Time: 2017-12-15 10:04:17.385
Task: CLEANUP Status: Ended Elapsed Time: 00:00:00.019
Logging Location:
/bulkload/logs/ERR_TRAFODION.ODS_SC.DM_FUNCTION_LOCATION_20171215_020417
Task: LOADING DATA Status: Started Time: 2017-12-15 10:04:17.385
*** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating
with server process $Z0211QE:526.
*** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating
with server process $Z0211QE:526.
*** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating
with server process $Z0211QE:526.
SQL>upsert using load into TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from
hive.hive.DM_FUNCTION_LOCATION;
*** ERROR[8411] A numeric overflow occurred during an arithmetic computation or
data conversion. Conversion of Source Type:CHAR(REC_BYTE_F_ASCII,15
BYTES,ISO88591) Source Value:214040391595900 to Target Type:DECIMAL
SIGNED(REC_DECIMAL_LSE). [2017-12-15 13:46:59]
Additional Information Core file and stack trace are under
10.10.22.152:/opt/GuangXi_20171218
Account: root/linux
Step to analyze core:
[root@esggy-del-n002 GuangXi_20171218]# gdb
(gdb) source zgdb-GuangXi_20171218-
(gdb) file /opt/esgynDB223/export/bin64/tdm_arkesp
(gdb) core core.44989
(gdb) bt
#0 0x00007f440e0ea1d7 in raise () from /opt/GuangXi_20171218/lib64/libc.so.6
#1 0x00007f440e0eb8c8 in abort () from /opt/GuangXi_20171218/lib64/libc.so.6
#2 0x00007f4410039f85 in os::abort(bool) () from
/opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
#3 0x00007f44101dc383 in VMError::report_and_die() () from
/opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000004 0x00007f441003f48f in JVM_handle_linux_signal () from
/opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000005 0x00007f44100359d3 in signalHandler(int, siginfo*, void*) ()
from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000006 <signal handler called>
0000007 0x00007f440e1ffde0 in __memcpy_ssse3_back () from
/opt/GuangXi_20171218/lib64/libc.so.6
0000008 0x00007f441308aeaf in str_cpy_all (length=-7167, src=<error reading
variable: Cannot access memory at address 0xbc>,
tgt=0x7fff64f1ed60 "\200") at ../common/str.h:265
0000009 getLength (data=<error reading variable: Cannot access memory at
address 0xbc>, this=0x80) at ../exp/exp_attrs.h:415
0000010 ExHbaseAccessBulkLoadPrepSQTcb::createLoggingRow (this=<optimized out>,
tuppIndex=<optimized out>, tuppRow=0x7f43fe67e3d0 "",
targetRow=0x7f43fe68e401 "", targetRowLen=@0x7fff64f1eea0: 0) at
../executor/ExHbaseIUD.cpp:1754
0000011 0x00007f441308ed1c in ExHbaseAccessBulkLoadPrepSQTcb::work
(this=0x7f43fe662f48) at ../executor/ExHbaseIUD.cpp:1591
0000012 0x00007f441309b46f in donotUpdateCounters (this=0x1343d9928) at
../executor/ExStats.h:3729
0000013 ExScheduler::work (this=0x7f44141a2008, prevWaitTime=<optimized out>)
at ../executor/ExScheduler.cpp:296
0000014 0x00007f4412fc69ed in ExEspFragInstanceDir::fixupEntry (this=0x0,
handle=320060680, numOfParentInstances=1693577552, da=...)
at ../executor/ex_esp_frag_dir.cpp:331
0000015 0x000000000040ca26 in runESP (argc=argc@entry=3,
argv=argv@entry=0x7fff64f1f878,
guaReceiveFastStart=guaReceiveFastStart@entry=0x0)
at ../bin/ex_esp_main.cpp:404
0000016 0x000000000040bd9b in main (argc=3, argv=0x7fff64f1f878) at
../bin/ex_esp_main.cpp:258
(gdb)
This issue was observed at a customer installation that deployed EsgynDB
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
