[jira] [Created] (TRAFODION-2029) odb.exe crashed on windows when sevral files in src
zhangliang created TRAFODION-2029: - Summary: odb.exe crashed on windows when sevral files in src Key: TRAFODION-2029 URL: https://issues.apache.org/jira/browse/TRAFODION-2029 Project: Apache Trafodion Issue Type: Bug Components: db-utility-odb Environment: centos6.7 HBase 1.0.0-cdh5.4.8 odb.exe on windows 7-64 bits Reporter: zhangliang Priority: Critical When extact multiple data tables from trafodion to windows using the command below: odb.exe -u trafodion -p traf123 -d traf -e src=-conf/export_tbl_list.txt:tgt=output_data/ext_%t.csv:rows=m10:fs=,:trim:sq=^| If there is more than one file in conf/export_tbl_list.txt, odb.exe will crash in the end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-109) LP Blueprint: instrument-secure-hadoop - Instrument Trafodion to work with Secure Hadoop
[ https://issues.apache.org/jira/browse/TRAFODION-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-109 started by Roberta Marton. > LP Blueprint: instrument-secure-hadoop - Instrument Trafodion to work with > Secure Hadoop > > > Key: TRAFODION-109 > URL: https://issues.apache.org/jira/browse/TRAFODION-109 > Project: Apache Trafodion > Issue Type: New Feature > Components: sql-security >Reporter: Roberta Marton >Assignee: Roberta Marton >Priority: Critical > Fix For: 1.1 (pre-incubation) > > > The next step to enhance Trafodion security is to seamlessly integrate within > theSecure Hadoop eco-system. > > Trafodion is installed on top of the Hadoop and supports authentication > through OpenLDAP and authorization through Trafodion; however, Hadoop, by > itself runs in a non-secure mode. This blueprint defines a task to configure > Trafodion to run in with Secure Hadoop. When the secure mode is > instrumented, each user and service will be authenticated by Kerberos which > include all products Trafodion uses in its eco-system. The means that secure > versions of Hadoop, HBase, Zookeeper, and others will be integrated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1585) MDAM plan is not chosen unless NJ is turned off
[ https://issues.apache.org/jira/browse/TRAFODION-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316670#comment-15316670 ] ASF GitHub Bot commented on TRAFODION-1585: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/519 > MDAM plan is not chosen unless NJ is turned off > --- > > Key: TRAFODION-1585 > URL: https://issues.apache.org/jira/browse/TRAFODION-1585 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Qifan Chen >Assignee: David Wayne Birdsall > > MDAM is used in scan node #8 in the following plan. > >explain options 'f' xx; > LC RC OP OPERATOR OPT DESCRIPTION CARD > - > 15 .16 root 1.00E+000 > 14 715 hybrid_hash_join 1.00E+000 > 13 .14 hash_partial_groupby 1.00E+000 > 12 .13 esp_exchange1:21(hash2) 1.00E+000 > 11 .12 sort_partial_groupby 1.00E+000 > 10 .11 hash_groupby 6.60E+004 > 9.10 hash_groupby 1.35E+005 > 8.9esp_exchange21(hash2):16(hash2) 1.40E+006 > ..8trafodion_scan OP 1.40E+006 > 6.7sort_groupby 1.00E+000 > 5.6hash_partial_groupby 3.09E+001 > 4.5esp_exchange1:21(hash2) 3.09E+001 > 3.4hash_partial_groupby 3.09E+001 > 2.3hash_groupby 1.35E+005 > 1.2esp_exchange21(hash2):16(hash2) 1.40E+006 > ..1trafodion_scan OP 1.40E+006 > The same MDAM scan is absent if CQD NESTED_JOINS 'off' is not used. > TRAFODION_SCAN SEQ_NO 8NO CHILDREN > TABLE_NAME ... P > REQUESTS_IN .. 1 > ROWS_OUT . 1,401,802 > EST_OPER_COST 0.21 > EST_TOTAL_COST ... 0.21 > DESCRIPTION > max_card_est ... 1.4018e+06 > fragment_id 5 > parent_frag 4 > fragment_type .. esp > scan_type .. subset scan limited by mdam of table > OP > object_type Trafodion > cache_size 10,000 > probes . 1 > rows_accessed .. 1.4018e+06 > key_columns _SALT_, SITE_ID, PANEL, DWD_ID > executor_predicates (PANEL = '1') and (SITE_ID = 450) > mdam_disjunct .. (PANEL = '1') and (SITE_ID = 450) and (_SALT_ > >= (\:_sys_HostVarLoHashPart Hash2Distrib 64)) > and > (_SALT_ <= (\:_sys_HostVarHiHashPart Hash2Distrib > 64)) > part_key_predicates (PANEL = '1' = PANEL) and (SITE_ID = 450 > = SITE_ID) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-1585) MDAM plan is not chosen unless NJ is turned off
[ https://issues.apache.org/jira/browse/TRAFODION-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wayne Birdsall resolved TRAFODION-1585. - Resolution: Fixed Fix Version/s: 2.1-incubating > MDAM plan is not chosen unless NJ is turned off > --- > > Key: TRAFODION-1585 > URL: https://issues.apache.org/jira/browse/TRAFODION-1585 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Qifan Chen >Assignee: David Wayne Birdsall > Fix For: 2.1-incubating > > > MDAM is used in scan node #8 in the following plan. > >explain options 'f' xx; > LC RC OP OPERATOR OPT DESCRIPTION CARD > - > 15 .16 root 1.00E+000 > 14 715 hybrid_hash_join 1.00E+000 > 13 .14 hash_partial_groupby 1.00E+000 > 12 .13 esp_exchange1:21(hash2) 1.00E+000 > 11 .12 sort_partial_groupby 1.00E+000 > 10 .11 hash_groupby 6.60E+004 > 9.10 hash_groupby 1.35E+005 > 8.9esp_exchange21(hash2):16(hash2) 1.40E+006 > ..8trafodion_scan OP 1.40E+006 > 6.7sort_groupby 1.00E+000 > 5.6hash_partial_groupby 3.09E+001 > 4.5esp_exchange1:21(hash2) 3.09E+001 > 3.4hash_partial_groupby 3.09E+001 > 2.3hash_groupby 1.35E+005 > 1.2esp_exchange21(hash2):16(hash2) 1.40E+006 > ..1trafodion_scan OP 1.40E+006 > The same MDAM scan is absent if CQD NESTED_JOINS 'off' is not used. > TRAFODION_SCAN SEQ_NO 8NO CHILDREN > TABLE_NAME ... P > REQUESTS_IN .. 1 > ROWS_OUT . 1,401,802 > EST_OPER_COST 0.21 > EST_TOTAL_COST ... 0.21 > DESCRIPTION > max_card_est ... 1.4018e+06 > fragment_id 5 > parent_frag 4 > fragment_type .. esp > scan_type .. subset scan limited by mdam of table > OP > object_type Trafodion > cache_size 10,000 > probes . 1 > rows_accessed .. 1.4018e+06 > key_columns _SALT_, SITE_ID, PANEL, DWD_ID > executor_predicates (PANEL = '1') and (SITE_ID = 450) > mdam_disjunct .. (PANEL = '1') and (SITE_ID = 450) and (_SALT_ > >= (\:_sys_HostVarLoHashPart Hash2Distrib 64)) > and > (_SALT_ <= (\:_sys_HostVarHiHashPart Hash2Distrib > 64)) > part_key_predicates (PANEL = '1' = PANEL) and (SITE_ID = 450 > = SITE_ID) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-1664) Trafci install wizard legal disclaimer needs updating
[ https://issues.apache.org/jira/browse/TRAFODION-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde resolved TRAFODION-1664. --- Resolution: Fixed Fix Version/s: 2.1-incubating > Trafci install wizard legal disclaimer needs updating > - > > Key: TRAFODION-1664 > URL: https://issues.apache.org/jira/browse/TRAFODION-1664 > Project: Apache Trafodion > Issue Type: Bug > Components: client-ci >Affects Versions: 1.3-incubating >Reporter: David Wayne Birdsall >Assignee: Anuradha Hegde >Priority: Minor > Fix For: 2.1-incubating > > > I'm using the Trafodion Command Interface Installer Wizard on a Windows 8 > laptop. One of the screens, "Welcome to the Trafodion Command Interface > Installer Wizard", contains the following Open Source Legal Disclaimer: > "The ability to download open source extensions is provided for your > convenience only. HP neither recommends nor requires you to download this > software. The decision to download or use any non-HP branded software is at > your sole risk and discretion. Software provided under any open source > licensing model is governed solely by such open source licensing terms." > This is no longer appropriate once downloads come from an Apache site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-1664) Trafci install wizard legal disclaimer needs updating
[ https://issues.apache.org/jira/browse/TRAFODION-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde closed TRAFODION-1664. - > Trafci install wizard legal disclaimer needs updating > - > > Key: TRAFODION-1664 > URL: https://issues.apache.org/jira/browse/TRAFODION-1664 > Project: Apache Trafodion > Issue Type: Bug > Components: client-ci >Affects Versions: 1.3-incubating >Reporter: David Wayne Birdsall >Assignee: Anuradha Hegde >Priority: Minor > Fix For: 2.1-incubating > > > I'm using the Trafodion Command Interface Installer Wizard on a Windows 8 > laptop. One of the screens, "Welcome to the Trafodion Command Interface > Installer Wizard", contains the following Open Source Legal Disclaimer: > "The ability to download open source extensions is provided for your > convenience only. HP neither recommends nor requires you to download this > software. The decision to download or use any non-HP branded software is at > your sole risk and discretion. Software provided under any open source > licensing model is governed solely by such open source licensing terms." > This is no longer appropriate once downloads come from an Apache site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work stopped] (TRAFODION-1143) LP Bug: 1441712 - sqcheck shows negative value for mxosrvr count when there are stale mxosrvrs
[ https://issues.apache.org/jira/browse/TRAFODION-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-1143 stopped by Anuradha Hegde. - > LP Bug: 1441712 - sqcheck shows negative value for mxosrvr count when there > are stale mxosrvrs > -- > > Key: TRAFODION-1143 > URL: https://issues.apache.org/jira/browse/TRAFODION-1143 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-dcs >Reporter: Aruna Sadashiva >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > We have seen this several times. It seems to happen when there are leftover > mxosrvrs that did not get stopped by dcsstop. > [trafodion@n007 bin]$ sqcheck > Checking if processes are up. > Checking attempt: 1; user specified max: 2. Execution time in seconds: 0. > The SQ environment is up! > Process Configured Actual Down > --- -- -- > DTM 6 6 > RMS 12 12 > MXOSRVR 60 62 -2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-1143) LP Bug: 1441712 - sqcheck shows negative value for mxosrvr count when there are stale mxosrvrs
[ https://issues.apache.org/jira/browse/TRAFODION-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde closed TRAFODION-1143. - Resolution: Not A Problem Closing this JIRA. When all of trafodion is stopped and when dcscheck is run the -ve value indicates there is obsolete process which did not get terminated normally > LP Bug: 1441712 - sqcheck shows negative value for mxosrvr count when there > are stale mxosrvrs > -- > > Key: TRAFODION-1143 > URL: https://issues.apache.org/jira/browse/TRAFODION-1143 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-dcs >Reporter: Aruna Sadashiva >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > We have seen this several times. It seems to happen when there are leftover > mxosrvrs that did not get stopped by dcsstop. > [trafodion@n007 bin]$ sqcheck > Checking if processes are up. > Checking attempt: 1; user specified max: 2. Execution time in seconds: 0. > The SQ environment is up! > Process Configured Actual Down > --- -- -- > DTM 6 6 > RMS 12 12 > MXOSRVR 60 62 -2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-1479) sqcheck should display the status of the rest server
[ https://issues.apache.org/jira/browse/TRAFODION-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde resolved TRAFODION-1479. --- Resolution: Fixed Fix Version/s: 2.1-incubating > sqcheck should display the status of the rest server > > > Key: TRAFODION-1479 > URL: https://issues.apache.org/jira/browse/TRAFODION-1479 > Project: Apache Trafodion > Issue Type: Improvement > Components: foundation >Reporter: Venkat Muthuswamy >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > The sqcheck script displays the status for DTM, RMS and MXOSRVR. It should > also include the status of the Trafodion REST server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-1479) sqcheck should display the status of the rest server
[ https://issues.apache.org/jira/browse/TRAFODION-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde closed TRAFODION-1479. - fixed in r2.1 > sqcheck should display the status of the rest server > > > Key: TRAFODION-1479 > URL: https://issues.apache.org/jira/browse/TRAFODION-1479 > Project: Apache Trafodion > Issue Type: Improvement > Components: foundation >Reporter: Venkat Muthuswamy >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > The sqcheck script displays the status for DTM, RMS and MXOSRVR. It should > also include the status of the Trafodion REST server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1117) LP Bug: 1438961 - ODB doesn't terminate connections with DB when execution is interrupted
[ https://issues.apache.org/jira/browse/TRAFODION-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1117: -- Reporter: Weiqing Xu (was: Chirag Bhalgami) > LP Bug: 1438961 - ODB doesn't terminate connections with DB when execution is > interrupted > - > > Key: TRAFODION-1117 > URL: https://issues.apache.org/jira/browse/TRAFODION-1117 > Project: Apache Trafodion > Issue Type: Bug > Components: db-utility-odb >Reporter: Weiqing Xu >Assignee: Anuradha Hegde >Priority: Blocker > Fix For: 2.1-incubating > > > If execution of ODB is interrupted then it does not terminate connections > with DB (Trafodion) . > Restarting DCS does not help. It shows odb app is still occupying MXOSRVRs. > Also, re-executing odb throws following error message: > - > odb [2015-03-31 21:19:11]: starting ODBC connection(s)... (1) 1 2 3 4 > Connected to HP Database > [3] 5,000 records inserted [commit] > [2] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [2] 0 records inserted [commit] > [3] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [3] 5,000 records inserted [commit] > [4] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [4] 0 records inserted [commit] > [1] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [1] 0 records inserted [commit] > odb [sigcatch(4125)] - Received SIGINT. Exiting > - > ODB version: odb64luo > Trafodion Build: Release [1.0.0-304-ga977ee7_Bld14], branch a977ee7-master, > date 20150329_083001) > Hadoop Distro: HDP 2.2 > HBase Version: 0.98.4.2.2.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2024) Openssl libraries (ssl & crypto) should be dynamically linked not static
[ https://issues.apache.org/jira/browse/TRAFODION-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316695#comment-15316695 ] ASF GitHub Bot commented on TRAFODION-2024: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/522 > Openssl libraries (ssl & crypto) should be dynamically linked not static > > > Key: TRAFODION-2024 > URL: https://issues.apache.org/jira/browse/TRAFODION-2024 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-linux >Affects Versions: 2.0-incubating >Reporter: Steve Varnau >Assignee: Anuradha Hegde > > Due to licensing constraint, we should not bundle openssl software (at least > until they move to ASL2.0, which is in process) with our binary packages. > Therefore, we should not link libssl and libcrypto statically, but > dynamically. > That change is in core/conn/unixodbc/odbc/odbcclient/unixcli/makefile.lnx > This change will also add dependeny on having the shared libraries installed > on runtime system. That should be reflected in wiki (Creating Build > Environment), which currently says openssl-static package. > The new dependency is "openssl" package on centos6, and "openssl-libs" on > centos7. > The dependency should also be reflected in the client install guide. > docs/client_install/src/asciidoc/_chapters/odbc_linux.adoc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-887) LP Bug: 1410504 - Lots of mxosrvrs kicked off for proper number to stay up.
[ https://issues.apache.org/jira/browse/TRAFODION-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-887 started by Anuradha Hegde. > LP Bug: 1410504 - Lots of mxosrvrs kicked off for proper number to stay up. > --- > > Key: TRAFODION-887 > URL: https://issues.apache.org/jira/browse/TRAFODION-887 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-dcs >Reporter: Guy Groulx >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > We’ve noticed this before but never make anything out of it since we did not > have proof. But now that master_exec files are created in the logs > directory, I believe we have proof that on dcsstart, we need to start many > mxosrvrs before we get to the number of mxosrvrs we actually want. This > concerns us a bit as it means that we are creating processes that die right > away. > The last start time on zircon4 was around at 15:48. > /opt/hp/squser4/git150112dcs/logs> ps -C mxosrvr | wc –l > 129 > So this is showing that we have 128 mxosrvrs running on this node + 1 header > line from the PS command. > /opt/hp/squser4/git150112dcs/logs> ls master_exec* | wc –l > 598 > This is telling that we have 598 master_exec* file under the directory. > And yes, these are all from this start as the mod date is all 15:48. > /opt/hp/squser4/git150112dcs/logs> ls -lt master* > -rw-r- 1 squser4 seaquest 42037 Jan 13 15:48 master_exec_0_21145.log > -rw-r- 1 squser4 seaquest 42543 Jan 13 15:48 master_exec_0_21018.log > -rw-r- 1 squser4 seaquest 41706 Jan 13 15:48 master_exec_0_21012.log > -rw-r- 1 squser4 seaquest 41375 Jan 13 15:48 master_exec_0_20991.log > … > -rw-r- 1 squser4 seaquest 1499 Jan 13 15:48 master_exec_0_63779.log > -rw-r- 1 squser4 seaquest 1168 Jan 13 15:48 master_exec_0_63462.log > -rw-r- 1 squser4 seaquest 1499 Jan 13 15:48 master_exec_0_63652.log > -rw-r- 1 squser4 seaquest 662 Jan 13 15:48 master_exec_0_63673.log > -rw-r- 1 squser4 seaquest 331 Jan 13 15:48 master_exec_0_63598.log > -rw-r- 1 squser4 seaquest 837 Jan 13 15:48 master_exec_0_63667.log > -rw-r- 1 squser4 seaquest 0 Jan 13 15:48 master_exec_0_63594.log > -rw-r- 1 squser4 seaquest 0 Jan 13 15:47 master_exec > Looking at some of those: > /opt/hp/squser4/git150112dcs/logs> ps 63667 > PID TTY STAT TIME COMMAND > /opt/hp/squser4/git150112dcs/logs> cat master_exec_0_63667.log > 2015-01-13 15:48:27,292, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error Platform: NSK, > Transport: TCPIP, Api: UNKNOWN_API, Error type: LISTENER, Process: > ListenToPort, Operation: INIT_PROCESS, function: ACCEPT, error: 98, > error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > 2015-01-13 15:48:27,293, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: bailout ListenToPort[21002][-2], Operation: INIT_PROCESS, function: > SOCKET, error: 0, error_detail: 0. has occurred. > CEE Error Text: . > 2015-01-13 15:48:27,293, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error 5012 has occurred. > CEE Error Text: <5>. > The above is showing that 63667 did not survive as an mxosrvr. > /opt/hp/squser4/git150112dcs/logs> ps 65102 > PID TTY STAT TIME COMMAND > 65102 ?Sl 0:07 mxosrvr -ZKHOST > n014.cm.cluster:2181,n015.cm.cluster:2181,n016.cm.cluster:2181 -RZ > zircon-n011.usa.hp.com > /opt/hp/squser4/git150112dcs/logs> cat master_exec_0_65102.log > 2015-01-13 15:48:27,832, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:65102, > Process Name:$Z001I52 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: verifyPortAvailable:[21002], Operation: INIT_PROCESS, function: > BIND, error: 98, error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > 2015-01-13 15:48:27,832, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:65102, > Process Name:$Z001I52 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: verifyPortAvailable:[21003], Operation: INIT_PROCESS, function: > BIND, error: 98, error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > The above msg is giving 13 more times. (Exact same date time). > But finally it worked as the process is running. > If I was to look at all the master_exec above I would find all of them have > at least one error and (598 - 128) ~> 470 of them did not start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-887) LP Bug: 1410504 - Lots of mxosrvrs kicked off for proper number to stay up.
[ https://issues.apache.org/jira/browse/TRAFODION-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde closed TRAFODION-887. Resolution: Not A Problem All these messages are categorized as WARNING messages and the change has been delivered to 2.0 incubating release > LP Bug: 1410504 - Lots of mxosrvrs kicked off for proper number to stay up. > --- > > Key: TRAFODION-887 > URL: https://issues.apache.org/jira/browse/TRAFODION-887 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-dcs >Reporter: Guy Groulx >Assignee: Anuradha Hegde > Fix For: 2.1-incubating > > > We’ve noticed this before but never make anything out of it since we did not > have proof. But now that master_exec files are created in the logs > directory, I believe we have proof that on dcsstart, we need to start many > mxosrvrs before we get to the number of mxosrvrs we actually want. This > concerns us a bit as it means that we are creating processes that die right > away. > The last start time on zircon4 was around at 15:48. > /opt/hp/squser4/git150112dcs/logs> ps -C mxosrvr | wc –l > 129 > So this is showing that we have 128 mxosrvrs running on this node + 1 header > line from the PS command. > /opt/hp/squser4/git150112dcs/logs> ls master_exec* | wc –l > 598 > This is telling that we have 598 master_exec* file under the directory. > And yes, these are all from this start as the mod date is all 15:48. > /opt/hp/squser4/git150112dcs/logs> ls -lt master* > -rw-r- 1 squser4 seaquest 42037 Jan 13 15:48 master_exec_0_21145.log > -rw-r- 1 squser4 seaquest 42543 Jan 13 15:48 master_exec_0_21018.log > -rw-r- 1 squser4 seaquest 41706 Jan 13 15:48 master_exec_0_21012.log > -rw-r- 1 squser4 seaquest 41375 Jan 13 15:48 master_exec_0_20991.log > … > -rw-r- 1 squser4 seaquest 1499 Jan 13 15:48 master_exec_0_63779.log > -rw-r- 1 squser4 seaquest 1168 Jan 13 15:48 master_exec_0_63462.log > -rw-r- 1 squser4 seaquest 1499 Jan 13 15:48 master_exec_0_63652.log > -rw-r- 1 squser4 seaquest 662 Jan 13 15:48 master_exec_0_63673.log > -rw-r- 1 squser4 seaquest 331 Jan 13 15:48 master_exec_0_63598.log > -rw-r- 1 squser4 seaquest 837 Jan 13 15:48 master_exec_0_63667.log > -rw-r- 1 squser4 seaquest 0 Jan 13 15:48 master_exec_0_63594.log > -rw-r- 1 squser4 seaquest 0 Jan 13 15:47 master_exec > Looking at some of those: > /opt/hp/squser4/git150112dcs/logs> ps 63667 > PID TTY STAT TIME COMMAND > /opt/hp/squser4/git150112dcs/logs> cat master_exec_0_63667.log > 2015-01-13 15:48:27,292, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error Platform: NSK, > Transport: TCPIP, Api: UNKNOWN_API, Error type: LISTENER, Process: > ListenToPort, Operation: INIT_PROCESS, function: ACCEPT, error: 98, > error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > 2015-01-13 15:48:27,293, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: bailout ListenToPort[21002][-2], Operation: INIT_PROCESS, function: > SOCKET, error: 0, error_detail: 0. has occurred. > CEE Error Text: . > 2015-01-13 15:48:27,293, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:63667, > Process Name:$Z001GZ2 , , ,A network component error 5012 has occurred. > CEE Error Text: <5>. > The above is showing that 63667 did not survive as an mxosrvr. > /opt/hp/squser4/git150112dcs/logs> ps 65102 > PID TTY STAT TIME COMMAND > 65102 ?Sl 0:07 mxosrvr -ZKHOST > n014.cm.cluster:2181,n015.cm.cluster:2181,n016.cm.cluster:2181 -RZ > zircon-n011.usa.hp.com > /opt/hp/squser4/git150112dcs/logs> cat master_exec_0_65102.log > 2015-01-13 15:48:27,832, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:65102, > Process Name:$Z001I52 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: verifyPortAvailable:[21002], Operation: INIT_PROCESS, function: > BIND, error: 98, error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > 2015-01-13 15:48:27,832, ERROR, MXOSRVR, Node Number: 0, CPU: 0, PIN:65102, > Process Name:$Z001I52 , , ,A network component error UNKNOWN_ERROR_TYPE 0, > Process: verifyPortAvailable:[21003], Operation: INIT_PROCESS, function: > BIND, error: 98, error_detail: 0. has occurred. > CEE Error Text: The specified address is already in use. > The above msg is giving 13 more times. (Exact same date time). > But finally it worked as the process is running. > If I was to look at all the master_exec above I would find all of them have > at least one error and (598 - 128) ~> 470 of them did not start. -- This mess
[jira] [Updated] (TRAFODION-1628) Implement T2 Driver's Rowsets ability to enhance the batch insert performance
[ https://issues.apache.org/jira/browse/TRAFODION-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1628: -- Fix Version/s: 2.1-incubating > Implement T2 Driver's Rowsets ability to enhance the batch insert performance > - > > Key: TRAFODION-1628 > URL: https://issues.apache.org/jira/browse/TRAFODION-1628 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: RuoYu Zuo >Assignee: RuoYu Zuo >Priority: Critical > Labels: features, performance > Fix For: 2.1-incubating > > > JDBC T2 Driver now has very poor performance of batch insert, because it does > not have rowsets ability. Implement rowsets functionality will allow T2 > Driver performs batch insert operation much faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1241) LP Bug: 1456304 - mtserver - spjs with resultsets failing - no results returned
[
https://issues.apache.org/jira/browse/TRAFODION-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anuradha Hegde updated TRAFODION-1241:
--
Assignee: Anuradha Hegde (was: Suresh Subbiah)
> LP Bug: 1456304 - mtserver - spjs with resultsets failing - no results
> returned
> ---
>
> Key: TRAFODION-1241
> URL: https://issues.apache.org/jira/browse/TRAFODION-1241
> Project: Apache Trafodion
> Issue Type: Bug
> Components: client-jdbc-t2
>Reporter: Aruna Sadashiva
>Assignee: Anuradha Hegde
>Priority: Critical
> Fix For: 2.1-incubating
>
>
> SPJ tests with result sets failed because there are no result sets returned
> from the procedure. the same SPJ works from sqlci, but fails from trafci.
> Steps:
> -
> SQL>create table t1 (a int not null primary key, b varchar(20));
> SQL>insert into t1 values(111, 'a');
> SQL>insert into t1 values(222, 'b');
> SQL>create library testrs file '/opt/home/trafodion/SPJ/testrs.jar';
> SQL>create procedure RS200()
>language java
>parameter style java
>external name 'Testrs.RS200'
>dynamic result sets 1
>library testrs;
> SQL>call rs200();
> --- SQL operation complete.
> -
> The expected result is:
> SQL >call rs200();
> AB
> ---
> 111 a
> 222 b
> --- 2 row(s) selected.
> --- SQL operation complete.
> The jar file, testrs.jar, is on amber7 under /opt/home/trafodion/SPJ. It has
> the SPJ procedure:
>public static void RS200(ResultSet[] paramArrayOfResultSet)
>throws Exception
>{
> String str1 = "jdbc:default:connection";
>
> String str2 = "select * from t1";
> Connection localConnection = DriverManager.getConnection(str1);
> Statement localStatement = localConnection.createStatement();
> paramArrayOfResultSet[0] = localStatement.executeQuery(str2);
>}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TRAFODION-1260) LP Bug: 1461629 - T2 driver not returning proper error msg for several unsupported catalog apis
[ https://issues.apache.org/jira/browse/TRAFODION-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1260: -- Assignee: Kevin Xu (was: Rao Kakarlamudi) > LP Bug: 1461629 - T2 driver not returning proper error msg for several > unsupported catalog apis > --- > > Key: TRAFODION-1260 > URL: https://issues.apache.org/jira/browse/TRAFODION-1260 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t2 >Reporter: Aruna Sadashiva >Assignee: Kevin Xu >Priority: Critical > Fix For: 2.1-incubating > > > For the following unsupported JDBC catalog apis, T4 driver returns proper > error msg, but T2 returns syntax error with some junk characters (or crashes > with mtserver): > TestCat23(TestCatNew): Exception in test JDBC TestCat23 - Get Table > Privileges..*** ERROR[15001] A syntax error occurred at or before: > èÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat24(TestCatNew): Exception in test JDBC TestCat24 - Get Column > Privileges..*** ERROR[15001] A syntax error occurred at or before: > èÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat25(TestCatNew): Exception in test JDBC TestCat25 - Get Best Row > Identifier..*** ERROR[15001] A syntax error occurred at or before: > øÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat26(TestCatNew): Exception in test JDBC TestCat26 - Get Version > Columns..*** ERROR[15001] A syntax error occurred at or before: > øÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat27(TestCatNew): Exception in test JDBC TestCat27 - Get Procedures..*** > ERROR[15001] A syntax error occurred at or before: > Ö9÷ÿ; > ^ (1 characters from start of SQL stateme > TestCat28(TestCatNew): Exception in test JDBC TestCat28 - Get Procedure > Columns..*** ERROR[15001] A syntax error occurred at or before: > Ö9÷ÿ; > ^ (1 characters from start of SQL stateme > TestCat29(TestCatNew): Exception in test JDBC TestCat29 - Get Exported > Keys..*** ERROR[15001] A syntax error occurred at or before: > øÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat30(TestCatNew): Exception in test JDBC TestCat30 - Get Imported > Keys..*** ERROR[15001] A syntax error occurred at or before: > øÕ9÷ÿ; > ^ (3 characters from start of SQL statem > TestCat31(TestCatNew): Exception in test JDBC TestCat31 - Get Index Info..*** > ERROR[15001] A syntax error occurred at or before: > Ö9÷ÿ; > ^ (1 characters from start of SQL stateme > false > [trafodion@n007 basic]$ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2004) Statistics on volatile tables is not supported
[ https://issues.apache.org/jira/browse/TRAFODION-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316757#comment-15316757 ] ASF GitHub Bot commented on TRAFODION-2004: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/509 > Statistics on volatile tables is not supported > -- > > Key: TRAFODION-2004 > URL: https://issues.apache.org/jira/browse/TRAFODION-2004 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 2.0-incubating, 1.3-incubating > Environment: All >Reporter: David Wayne Birdsall >Assignee: David Wayne Birdsall > > The Trafodion SQL Reference Manual on wiki: > http://trafodion.apache.org/docs/sql_reference/Trafodion_SQL_Reference_Manual.pdf, > Page 119, 'Considerations for CREATE VOLATILE TABLE' explicitly says the > following: > "Statistics are not automatically updated for volatile tables. If you need > statistics, you must explicitly run UPDATE STATISTICS." > However, as shown in the following example, update statistics does not work > for volatile tables. > >>create schema mytest; > --- SQL operation complete. > >>set schema mytest; > --- SQL operation complete. > >> > >>create volatile table mytable (a int); > --- SQL operation complete. > >>insert into mytable values (1); > --- 1 row(s) inserted. > >>select * from mytable; > A > --- > 1 > --- 1 row(s) selected. > >>update statistics for table mytable on every column; > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > --- SQL operation failed with errors. > >> > >>drop volatile table mytable cascade; > --- SQL operation complete. > >>drop schema mytest cascade; > --- SQL operation complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1718) Add Batch test cases to dcs/src/test/jdbc_test folder
[ https://issues.apache.org/jira/browse/TRAFODION-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316758#comment-15316758 ] Anuradha Hegde commented on TRAFODION-1718: --- Can this be closed if it is already addressed? Thanks > Add Batch test cases to dcs/src/test/jdbc_test folder > - > > Key: TRAFODION-1718 > URL: https://issues.apache.org/jira/browse/TRAFODION-1718 > Project: Apache Trafodion > Issue Type: Test > Components: client-jdbc-t2, client-jdbc-t4, sql-exe >Reporter: RuoYu Zuo >Assignee: RuoYu Zuo > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1659) Need Batch test cases in JDBC Phoenix tests
[ https://issues.apache.org/jira/browse/TRAFODION-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1659: -- Assignee: RuoYu Zuo > Need Batch test cases in JDBC Phoenix tests > --- > > Key: TRAFODION-1659 > URL: https://issues.apache.org/jira/browse/TRAFODION-1659 > Project: Apache Trafodion > Issue Type: Test > Components: client-jdbc-t2, client-jdbc-t4 >Reporter: RuoYu Zuo >Assignee: RuoYu Zuo > Labels: test > > There's no batch insert/update test case now in Phoenix to test Rowsets > functionality of JDBC drivers, and also not able to evaluate the performance. > We need to create test cases for this area. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1957) Have jdbc drivers available on Maven Repository
[ https://issues.apache.org/jira/browse/TRAFODION-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1957: -- Assignee: Steve Varnau > Have jdbc drivers available on Maven Repository > --- > > Key: TRAFODION-1957 > URL: https://issues.apache.org/jira/browse/TRAFODION-1957 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2, client-jdbc-t4 >Reporter: Pierre Smits >Assignee: Steve Varnau > Fix For: 2.1-incubating > > > In order to increase visibility and thus adoption the (built) drivers must be > made available on 3rd party repositories as Maven Repository > (http://mvnrepository.com/). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-2004) Statistics on volatile tables is not supported
[ https://issues.apache.org/jira/browse/TRAFODION-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Wayne Birdsall resolved TRAFODION-2004. - Resolution: Fixed Fix Version/s: 2.1-incubating > Statistics on volatile tables is not supported > -- > > Key: TRAFODION-2004 > URL: https://issues.apache.org/jira/browse/TRAFODION-2004 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 2.0-incubating, 1.3-incubating > Environment: All >Reporter: David Wayne Birdsall >Assignee: David Wayne Birdsall > Fix For: 2.1-incubating > > > The Trafodion SQL Reference Manual on wiki: > http://trafodion.apache.org/docs/sql_reference/Trafodion_SQL_Reference_Manual.pdf, > Page 119, 'Considerations for CREATE VOLATILE TABLE' explicitly says the > following: > "Statistics are not automatically updated for volatile tables. If you need > statistics, you must explicitly run UPDATE STATISTICS." > However, as shown in the following example, update statistics does not work > for volatile tables. > >>create schema mytest; > --- SQL operation complete. > >>set schema mytest; > --- SQL operation complete. > >> > >>create volatile table mytable (a int); > --- SQL operation complete. > >>insert into mytable values (1); > --- 1 row(s) inserted. > >>select * from mytable; > A > --- > 1 > --- 1 row(s) selected. > >>update statistics for table mytable on every column; > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > *** ERROR[4082] Object TRAFODION.MYTEST.MYTABLE does not exist or is > inaccessible. > --- SQL operation failed with errors. > >> > >>drop volatile table mytable cascade; > --- SQL operation complete. > >>drop schema mytest cascade; > --- SQL operation complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1998) JDBC Type2 column information improve
[ https://issues.apache.org/jira/browse/TRAFODION-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1998: -- Fix Version/s: 2.1-incubating > JDBC Type2 column information improve > - > > Key: TRAFODION-1998 > URL: https://issues.apache.org/jira/browse/TRAFODION-1998 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: Weiqing Xu >Priority: Trivial > Fix For: 2.1-incubating > > > JDBC type2 use query to get the columns information from SQL. > 1. For Nullable, use the origin value from SQL > 2. For remark, return empty string since not support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1998) JDBC Type2 column information improve
[ https://issues.apache.org/jira/browse/TRAFODION-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-1998: -- Assignee: Weiqing Xu > JDBC Type2 column information improve > - > > Key: TRAFODION-1998 > URL: https://issues.apache.org/jira/browse/TRAFODION-1998 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: Weiqing Xu >Assignee: Weiqing Xu >Priority: Trivial > Fix For: 2.1-incubating > > > JDBC type2 use query to get the columns information from SQL. > 1. For Nullable, use the origin value from SQL > 2. For remark, return empty string since not support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2003) Some classes named with the prefix HP instead of Traf
[ https://issues.apache.org/jira/browse/TRAFODION-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-2003: -- Assignee: Kevin Xu > Some classes named with the prefix HP instead of Traf > - > > Key: TRAFODION-2003 > URL: https://issues.apache.org/jira/browse/TRAFODION-2003 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Reporter: Kevin Xu >Assignee: Kevin Xu > Fix For: 2.1-incubating > > > Some classes named with the prefix HP instead of Traf. It's not consistent > while the others start Traf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2003) Some classes named with the prefix HP instead of Traf
[ https://issues.apache.org/jira/browse/TRAFODION-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuradha Hegde updated TRAFODION-2003: -- Fix Version/s: 2.1-incubating > Some classes named with the prefix HP instead of Traf > - > > Key: TRAFODION-2003 > URL: https://issues.apache.org/jira/browse/TRAFODION-2003 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Reporter: Kevin Xu > Fix For: 2.1-incubating > > > Some classes named with the prefix HP instead of Traf. It's not consistent > while the others start Traf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-762) LP Bug: 1392452 - Support new Hive data types such as CHAR
[
https://issues.apache.org/jira/browse/TRAFODION-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316940#comment-15316940
]
ASF GitHub Bot commented on TRAFODION-762:
--
Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/496#discussion_r65943210
--- Diff: core/sql/optimizer/NATable.cpp ---
@@ -3553,6 +3560,60 @@ NAType* getSQColTypeForHive(const char* hiveType,
NAMemory* heap)
if ( !strcmp(hiveType, "timestamp"))
return new (heap) SQLTimestamp(TRUE /* allow NULL */ , 6, heap);
+ if ( !strcmp(hiveType, "date"))
+return new (heap) SQLDate(TRUE /* allow NULL */ , heap);
+
+ if ( !strncmp(hiveType, "varchar", 7) )
+ {
+char maxLen[32];
+memset(maxLen, 0, 32);
+int i=0,j=0;
+int copyit = 0;
+
+//get length
+for(i = 0; i < strlen(hiveType) ; i++)
+{
--- End diff --
@traflm you have missed out the change to optimize strlen. I am ok if you
can take care of it the next time It is not necessary to do another push commit
just for this.
> LP Bug: 1392452 - Support new Hive data types such as CHAR
> --
>
> Key: TRAFODION-762
> URL: https://issues.apache.org/jira/browse/TRAFODION-762
> Project: Apache Trafodion
> Issue Type: Wish
> Components: sql-cmp
>Reporter: Hans Zeller
>Assignee: liu ming
>Priority: Minor
>
> Hive now seems to support data types that match Trafodion types very well.
> According to
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Create/Drop/TruncateTable
> Hive 0.11 supports DECIMAL
> Hive 0.12 supports VARCHAR
> Hive 0.13 supports CHAR, DECIMAL(precision, scale)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-2031) At times T2 applications dump core at the time of logging error
Selvaganesan Govindarajan created TRAFODION-2031: Summary: At times T2 applications dump core at the time of logging error Key: TRAFODION-2031 URL: https://issues.apache.org/jira/browse/TRAFODION-2031 Project: Apache Trafodion Issue Type: Bug Components: client-jdbc-t2 Affects Versions: 2.0-incubating Reporter: Selvaganesan Govindarajan Fix For: 2.1-incubating The stack trace of the core is shown below gdb /usr/java/jdk1.7.0_67-cloudera/bin/java ./core.8230 --batch -n -x /tmp/tmp.nQQi6Jy1vZ 2>&1 [New Thread 8231] [New Thread 8598] [New Thread 8329] [New Thread 8328] [New Thread 8515] [Thread debugging using libthread_db enabled] Core was generated by `/usr/java/jdk1.7.0_67-cloudera/bin/java -Xmx512m -Xss1024k -classpath /opt/traf'. Program terminated with signal 6, Aborted. #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 001 0x7fe6d0394d8d in abort () from /lib64/libc.so.6 002 0x7fe6cfeaafe4 in __gnu_cxx::__verbose_terminate_handler() () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 003 0x7fe6cfea5e56 in __cxxabiv1::__terminate(void (*)()) () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 004 0x7fe6cfea5e83 in std::terminate() () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 005 0x7fe6cfea62ef in __cxa_pure_virtual () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 006 0x7fe6cfd15d7b in outputStream::print(char const*, ...) () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 007 0x7fe6cfa0a07d in frame::print_on_error(outputStream*, char*, int, bool) const () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 008 0x7fe6cfe8a64a in VMError::report(outputStream*) () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 009 0x7fe6cfe8bb8a in VMError::report_and_die() () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 010 0x7fe6cfd1096f in JVM_handle_linux_signal () from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so 011 012 0x7fe6bd1c05ea in log4cxx::LogManager::getLoggerRepository () at logmanager.cpp:92 013 0x7fe6bd1c0ba9 in log4cxx::LogManager::getLoggerLS (name="SQL") at logmanager.cpp:106 014 0x7fe6bd1c0cac in log4cxx::LogManager::getLogger (name=) at logmanager.cpp:121 015 0x7fe6bd1b9c49 in log4cxx::Logger::getLogger (name=) at logger.cpp:490 016 0x7fe6ba22e86c in QRLogger::log (cat="SQL", level=LL_ERROR, sqlCode=2034, queryId=0x14cf310 "MXID11082302123304816821555610206U300_263_S\ TMT2", logMsgTemplate=0x7fe6c0936f85 "%s") at ../qmscommon/QRLogger.cpp:570 017 0x7fe6c0936aae in SQLMXLoggingArea::logSQLMXEventForError (sqlcode=2034, msgTxt=0x7fe6d0f42aa0 "*** ERROR[2034] Err160: Operating system error 16 while \ communicating with server process Err160.", sqlId=0x14cf310 "MXID11082302123304816821555610206U300_263_STMT2", isWarning=) \ at ../sqlmxevents/logmxevent_traf.cpp:135 018 0x7fe6c1742c3b in logAnMXEventForError (condition=..., emsEventEL=) at ../cli/CliExtern.cpp:770 019 0x7fe6c174f843 in SQL_EXEC_GetDiagnosticsCondInfo (cond_info_items=0x7fe6d0f44230, cond_num_descriptor=0x7fe6d0f44108, output_descriptor=0x7fe6d0f441a0)\ at ../cli/CliExtern.cpp:3616 020 0x7fe6c174fcbe in SQL_EXEC_GetDiagnosticsCondInfo2 (what_to_get=15, conditionNum=, numeric_value=0x0, string_value=0x2889790 "8\017\ o\320\346\177", max_string_len=97, len_of_item=0x7fe6d0f442c8) at ../cli/CliExtern.cpp:3881 021 0x7fe6c38a3370 in GETSQLERROR (pSrvrStmt=, SQLError=0x25a5aa8) at native/SqlInterface.cpp:1825 022 0x7fe6c38a6201 in EXECUTE (pSrvrStmt=0x25a51e0) at native/SqlInterface.cpp:1219 023 0x7fe6c38a0b89 in SRVR_STMT_HDL::Execute (this=0x25a51e0, inCursorName=0x0, totalRowCount=, inSqlStmtType=0, inValueList=0x7fe6d0f4\ 4540, inSqlAsyncEnable=, inQueryTimeout=0, outValueList=0x7fe6d0f44530) at native/CSrvrStmt.cpp:260 024 0x7fe6c38a10df in SRVR_STMT_HDL::ExecDirect (this=0x25a51e0, inCursorName=0x0, inSqlString=, inStmtType=, inSq\ lStmtType=0, inHoldability=, inQueryTimeout=0) at native/CSrvrStmt.cpp:418 025 0x7fe6c38b744d in odbc_SQLSvc_ExecDirect_sme_ (objtag_=, call_id_=, exception_=0x7fe6d0f44720, dialogueId=, stmtLabel=, cursorName=0x0, stmtExplainLabel=0x7fe6c38c3c1d "", stmtType=0, sqlStmtType=0, sqlString=0x7fe6d0f446f0, hol\ dability=2, queryTimeout=0, resultSet=140629324875976, estimatedCost=0x7fe6d0f44778, outputDesc=0x7fe6d0f44740, rowsAffected=0x7fe6d0f44770, sqlWarning=0x7fe6d0\ f44750, stmtId=0x7fe6d0f44768, currentStmtId=0) at native/SrvrOthers.cpp:677 026
[jira] [Assigned] (TRAFODION-2031) At times T2 applications dump core at the time of logging error
[ https://issues.apache.org/jira/browse/TRAFODION-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2031: Assignee: Selvaganesan Govindarajan > At times T2 applications dump core at the time of logging error > --- > > Key: TRAFODION-2031 > URL: https://issues.apache.org/jira/browse/TRAFODION-2031 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t2 >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > The stack trace of the core is shown below > gdb /usr/java/jdk1.7.0_67-cloudera/bin/java ./core.8230 --batch -n -x > /tmp/tmp.nQQi6Jy1vZ 2>&1 > [New Thread 8231] > [New Thread 8598] > [New Thread 8329] > [New Thread 8328] > [New Thread 8515] > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/java/jdk1.7.0_67-cloudera/bin/java -Xmx512m > -Xss1024k -classpath /opt/traf'. > Program terminated with signal 6, Aborted. > #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 > #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 > 001 0x7fe6d0394d8d in abort () from /lib64/libc.so.6 > 002 0x7fe6cfeaafe4 in __gnu_cxx::__verbose_terminate_handler() () > from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 003 0x7fe6cfea5e56 in __cxxabiv1::__terminate(void (*)()) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 004 0x7fe6cfea5e83 in std::terminate() () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 005 0x7fe6cfea62ef in __cxa_pure_virtual () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 006 0x7fe6cfd15d7b in outputStream::print(char const*, ...) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 007 0x7fe6cfa0a07d in frame::print_on_error(outputStream*, char*, > int, bool) const () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 008 0x7fe6cfe8a64a in VMError::report(outputStream*) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 009 0x7fe6cfe8bb8a in VMError::report_and_die() () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 010 0x7fe6cfd1096f in JVM_handle_linux_signal () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 011 > 012 0x7fe6bd1c05ea in log4cxx::LogManager::getLoggerRepository () at > logmanager.cpp:92 > 013 0x7fe6bd1c0ba9 in log4cxx::LogManager::getLoggerLS (name="SQL") > at logmanager.cpp:106 > 014 0x7fe6bd1c0cac in log4cxx::LogManager::getLogger (name= optimized out>) at logmanager.cpp:121 > 015 0x7fe6bd1b9c49 in log4cxx::Logger::getLogger (name= optimized out>) at logger.cpp:490 > 016 0x7fe6ba22e86c in QRLogger::log (cat="SQL", level=LL_ERROR, > sqlCode=2034, queryId=0x14cf310 > "MXID11082302123304816821555610206U300_263_S\ > TMT2", logMsgTemplate=0x7fe6c0936f85 "%s") at ../qmscommon/QRLogger.cpp:570 > 017 0x7fe6c0936aae in SQLMXLoggingArea::logSQLMXEventForError > (sqlcode=2034, msgTxt=0x7fe6d0f42aa0 "*** ERROR[2034] Err160: Operating > system error 16 while \ > communicating with server process Err160.", sqlId=0x14cf310 > "MXID11082302123304816821555610206U300_263_STMT2", > isWarning=) \ > at ../sqlmxevents/logmxevent_traf.cpp:135 > 018 0x7fe6c1742c3b in logAnMXEventForError (condition=..., > emsEventEL=) at ../cli/CliExtern.cpp:770 > 019 0x7fe6c174f843 in SQL_EXEC_GetDiagnosticsCondInfo > (cond_info_items=0x7fe6d0f44230, cond_num_descriptor=0x7fe6d0f44108, > output_descriptor=0x7fe6d0f441a0)\ > at ../cli/CliExtern.cpp:3616 > 020 0x7fe6c174fcbe in SQL_EXEC_GetDiagnosticsCondInfo2 > (what_to_get=15, conditionNum=, numeric_value=0x0, > string_value=0x2889790 "8\017\ > o\320\346\177", max_string_len=97, len_of_item=0x7fe6d0f442c8) at > ../cli/CliExtern.cpp:3881 > 021 0x7fe6c38a3370 in GETSQLERROR (pSrvrStmt=, > SQLError=0x25a5aa8) at native/SqlInterface.cpp:1825 > 022 0x7fe6c38a6201 in EXECUTE (pSrvrStmt=0x25a51e0) at > native/SqlInterface.cpp:1219 > 023 0x7fe6c38a0b89 in SRVR_STMT_HDL::Execute (this=0x25a51e0, > inCursorName=0x0, totalRowCount=, inSqlStmtType=0, > inValueList=0x7fe6d0f4\ > 4540, inSqlAsyncEnable=, inQueryTimeout=0, > outValueList=0x7fe6d0f44530) at native/CSrvrStmt.cpp:260 > 024 0x7fe6c38a10df in SRVR_STMT_HDL::ExecDirect (this=0x25a51e0, > inCursorName=0x0, inSqlString=, inStmtType= optimized out>, inSq\ > lStmtType=0, inHoldability=, inQueryTimeout=0) at > native/CSrvrStmt.cpp:418 > 025 0x7
[jira] [Commented] (TRAFODION-823) LP Bug: 1402031 - Update stats gets wrong row counts with the first run after loading data
[ https://issues.apache.org/jira/browse/TRAFODION-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316980#comment-15316980 ] ASF GitHub Bot commented on TRAFODION-823: -- GitHub user DaveBirdsall opened a pull request: https://github.com/apache/incubator-trafodion/pull/525 [TRAFODION-823] Refine USTATS row count estimate for HBase tables You can merge this pull request into a Git repository by running: $ git pull https://github.com/DaveBirdsall/incubator-trafodion Trafodion823 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/525.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #525 commit 51ecfa623d206a60a0416cc146936345ea3e50ee Author: Dave Birdsall Date: 2016-06-06T18:48:42Z [TRAFODION-823] Refine USTATS row count estimate for HBase tables > LP Bug: 1402031 - Update stats gets wrong row counts with the first run after > loading data > -- > > Key: TRAFODION-823 > URL: https://issues.apache.org/jira/browse/TRAFODION-823 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Weishiun Tsai >Assignee: David Wayne Birdsall >Priority: Critical > > This problem has been seen several times in the past few builds, the latest > one being the v1209_0830 build. When QA populates the g_tpch2x tables on QA > clusters, the scripts load the data, do select count(*) on each table, and > then run update stats on each table. The select count(*) prior to the update > stats show the correct row counts. But showstats after update stats show > that the row count in the stats for each table is way off. Some tables get > more row counts than the actual row counts and some less. > Rerunning the same set of update stats statements often correct this > situation. But this is causing a huge problem for testing. When the stats > are this bad, some of the larger queries using these tables would lapse back > to nested join and would then hang for 20 hours without finishing. > This problem can’t be reliably reproduced on all clusters, but it does show > up frequently enough to cause problems. This case is created to document > this problem. Investigation needs to be done in the implementation of update > stats to see why select count(*) gets the correct counts while update stats > afterwards does not. > === > Here is the execution output of the select count(*) statements and the update > stats statements, in that order, after the data loading. > SQL>select count(*) from region; > (EXPR) > >5 > --- 1 row(s) selected. > SQL>select count(*) from nation; > (EXPR) > > 25 > --- 1 row(s) selected. > SQL>select count(*) from supplier; > (EXPR) > >2 > --- 1 row(s) selected. > SQL>select count(*) from customer; > (EXPR) > > 30 > --- 1 row(s) selected. > SQL>select count(*) from part; > (EXPR) > > 40 > --- 1 row(s) selected. > SQL>select count(*) from partsupp; > (EXPR) > > 160 > --- 1 row(s) selected. > SQL>select count(*) from orders; > (EXPR) > > 300 > --- 1 row(s) selected. > SQL>select count(*) from lineitem; > (EXPR) > > 11997996 > --- 1 row(s) selected. > --- > == TEST: tcase.test003 > --- > SQL>update statistics for table region on every column; > --- SQL operation complete. > SQL>update statistics for table nation on every column; > --- SQL operation complete. > SQL>update statistics for table supplier on every column; > --- SQL operation complete. > SQL>update statistics for table customer on every column; > --- SQL operation complete. > SQL>update statistics for table part on every column; > --- SQL operation complete. > SQL>update statistics for table partsupp on every column; > --- SQL operation complete. > SQL>update statistics for table orders on every column sample random 10 > percent; > --- SQL operation complete. > SQL>update statistics for table lineitem on every column sample random 10 > percent; > --- SQL operation complete. > === > Here is the showstats output for each table after update stats statements > were first run. The r
[jira] [Commented] (TRAFODION-2031) At times T2 applications dump core at the time of logging error
[ https://issues.apache.org/jira/browse/TRAFODION-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15317010#comment-15317010 ] ASF GitHub Bot commented on TRAFODION-2031: --- GitHub user selvaganesang opened a pull request: https://github.com/apache/incubator-trafodion/pull/526 [TRAFODION-2031] At times T2 JDBC applications dump core at the time of lo… …gging error Cores were dumped when SQL tries to log the error message via log4cxx. Log4cxx instance was not initialized in case of T2 driver [TRAFODION-1956] session defaults was getting corrupted in mxosrvr. COMPILER_IDLE_TIMEOUT wasn't added in alphabetical order. Also fixed the possible buffer overrun issue with some of the set commands in SessionDefaults You can merge this pull request into a Git repository by running: $ git pull https://github.com/selvaganesang/incubator-trafodion trafodion-2031 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/526.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #526 commit 73a981341c2606a09c6fbb3fc7fc330114b9c992 Author: selvaganesang Date: 2016-06-06T18:40:26Z [TRAFODION-2031] At times T2 applications dump core at the time of logging error Cores were dumped when SQL tries to log the error message via log4cxx. Log4cxx instance was not initialized in case of T2 driver [TRAFODION-1956] session defaults was getting corrupted in mxosrvr. COMPILER_IDLE_TIMEOUT wasn't added in alphabetical order. Also fixed the possible buffer overrun issue with some of the set commands in SessionDefaults > At times T2 applications dump core at the time of logging error > --- > > Key: TRAFODION-2031 > URL: https://issues.apache.org/jira/browse/TRAFODION-2031 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t2 >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > The stack trace of the core is shown below > gdb /usr/java/jdk1.7.0_67-cloudera/bin/java ./core.8230 --batch -n -x > /tmp/tmp.nQQi6Jy1vZ 2>&1 > [New Thread 8231] > [New Thread 8598] > [New Thread 8329] > [New Thread 8328] > [New Thread 8515] > [Thread debugging using libthread_db enabled] > Core was generated by `/usr/java/jdk1.7.0_67-cloudera/bin/java -Xmx512m > -Xss1024k -classpath /opt/traf'. > Program terminated with signal 6, Aborted. > #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 > #0 0x7fe6d0393625 in raise () from /lib64/libc.so.6 > 001 0x7fe6d0394d8d in abort () from /lib64/libc.so.6 > 002 0x7fe6cfeaafe4 in __gnu_cxx::__verbose_terminate_handler() () > from /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 003 0x7fe6cfea5e56 in __cxxabiv1::__terminate(void (*)()) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 004 0x7fe6cfea5e83 in std::terminate() () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 005 0x7fe6cfea62ef in __cxa_pure_virtual () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 006 0x7fe6cfd15d7b in outputStream::print(char const*, ...) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 007 0x7fe6cfa0a07d in frame::print_on_error(outputStream*, char*, > int, bool) const () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 008 0x7fe6cfe8a64a in VMError::report(outputStream*) () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 009 0x7fe6cfe8bb8a in VMError::report_and_die() () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 010 0x7fe6cfd1096f in JVM_handle_linux_signal () from > /usr/java/jdk1.7.0_67-cloudera/jre/lib/amd64/server/libjvm.so > 011 > 012 0x7fe6bd1c05ea in log4cxx::LogManager::getLoggerRepository () at > logmanager.cpp:92 > 013 0x7fe6bd1c0ba9 in log4cxx::LogManager::getLoggerLS (name="SQL") > at logmanager.cpp:106 > 014 0x7fe6bd1c0cac in log4cxx::LogManager::getLogger (name= optimized out>) at logmanager.cpp:121 > 015 0x7fe6bd1b9c49 in log4cxx::Logger::getLogger (name= optimized out>) at logger.cpp:490 > 016 0x7fe6ba22e86c in QRLogger::log (cat="SQL", level=LL_ERROR, > sqlCode=2034, queryId=0x14cf310 > "MXID11082302123304816821555610206U300_263_S\ > TMT2", logMsgTemplate=0x7fe6c0936f85 "%s") at ../qmscommon/QRLogger.cpp:570 > 017 0x7fe6c0936aae in SQLMXLoggingArea
[jira] [Commented] (TRAFODION-762) LP Bug: 1392452 - Support new Hive data types such as CHAR
[
https://issues.apache.org/jira/browse/TRAFODION-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15317513#comment-15317513
]
ASF GitHub Bot commented on TRAFODION-762:
--
Github user traflm commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/496#discussion_r65990271
--- Diff: core/sql/optimizer/NATable.cpp ---
@@ -3553,6 +3560,60 @@ NAType* getSQColTypeForHive(const char* hiveType,
NAMemory* heap)
if ( !strcmp(hiveType, "timestamp"))
return new (heap) SQLTimestamp(TRUE /* allow NULL */ , 6, heap);
+ if ( !strcmp(hiveType, "date"))
+return new (heap) SQLDate(TRUE /* allow NULL */ , heap);
+
+ if ( !strncmp(hiveType, "varchar", 7) )
+ {
+char maxLen[32];
+memset(maxLen, 0, 32);
+int i=0,j=0;
+int copyit = 0;
+
+//get length
+for(i = 0; i < strlen(hiveType) ; i++)
+{
--- End diff --
@selvaganesang thanks Selva for patient review. Yes, I must pay more
attention to these, and improve the coding quality next time.
> LP Bug: 1392452 - Support new Hive data types such as CHAR
> --
>
> Key: TRAFODION-762
> URL: https://issues.apache.org/jira/browse/TRAFODION-762
> Project: Apache Trafodion
> Issue Type: Wish
> Components: sql-cmp
>Reporter: Hans Zeller
>Assignee: liu ming
>Priority: Minor
>
> Hive now seems to support data types that match Trafodion types very well.
> According to
> https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Create/Drop/TruncateTable
> Hive 0.11 supports DECIMAL
> Hive 0.12 supports VARCHAR
> Hive 0.13 supports CHAR, DECIMAL(precision, scale)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-2032) Copy data from Oracle to Trafodion no data copied and no error occuer
zhangliang created TRAFODION-2032: - Summary: Copy data from Oracle to Trafodion no data copied and no error occuer Key: TRAFODION-2032 URL: https://issues.apache.org/jira/browse/TRAFODION-2032 Project: Apache Trafodion Issue Type: Bug Components: db-utility-odb Environment: centos 6.7 HBase 1.0.0-cdh5.4.8 odb.exe on windows 7-64 bits Reporter: zhangliang Copy data from Oracle to Trafodion by odb.exe on windows using the command below: odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v The oracle table test and trafodion table trafodion.ODB_TEST.MYTEST both exist and their formats are same. Also the table test has been inserted some data. But no data copied and no error occuer. Log: C:\odb_test>odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v Connected to Oracle odb [2016-05-30 17:34:05]: starting ODBC connection(s)... 0 >1 >2 3 >4 >5 Connected to Trafodion odb: Now truncating target table (DELETE FROM trafodion.ODB_TEST.MYTEST) NO data copyed , and no error occuer. [1.0.0]--- 0 row(s) deleted in 0.161s (prep 0.071s, exec 0.090s, fetch 0.000s/0.000s) [0] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE MOD(ORA_HASH(ROWID), 2) = 0 [3] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE MOD(ORA_HASH(ROWID), 2) = 1 [3] odb [Ocopy(10897)] - TARGET statement: INSERT INTO trafodion.ODB_TEST.MYTEST VALUES (?,?) [0] odb [Ocopy(10897)] - TARGET statement: INSERT INTO trafodion.ODB_TEST.MYTEST VALUES (?,?) odb: thread 4 closing connection... odb: thread 5 closing connection... odb: thread 3 closing connection... odb: thread 3 is ending... odb: thread 4 is ending... odb: thread 5 is ending... odb: thread 2 closing connection... [0] odb version 1.1.0 Copy statistics: [0] Source: TEST [0] Target: trafodion.ODB_TEST.MYTEST odb: thread 1 closing connection... [0] Total number of columns: 2 [0] ODBC row size: 297 B (data) + 16 B (len ind) [0] Rowset size: 6,700 [0] Rowset buffer size: 2,047.95 KiB [0] Pre-copy time: 3.285 s (00:00:03.285) [0] Copy time: 0.001 s (00:00:00.001) [0] Total records copied: 0 (0.000 krec/s) [0] Copy throughput (ODBC): 0.000 MiB/s (0.000 GiB/h) [0] Total/Wait cycles: 0/0 [0>1] 0 records copied in 0.001 (00:00:00.001 s) [0>2] 0 records copied in 0.001 (00:00:00.001 s) [3] Total/Wait cycles: 0/0 [3>4] 0 records copied in 0.001 (00:00:00.001 s) [3>5] 0 records copied in 0.001 (00:00:00.001 s) odb: thread 0 closing connection... odb: thread 0 is ending... odb: thread 1 is ending... odb: thread 2 is ending... odb [2016-05-30 17:34:09]: exiting. Session Elapsed time 3.365 seconds (00:00:03.365) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-2032) Copy data from Oracle to Trafodion no data copied and no error occuer
[ https://issues.apache.org/jira/browse/TRAFODION-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangliang closed TRAFODION-2032. - Resolution: Duplicate > Copy data from Oracle to Trafodion no data copied and no error occuer > - > > Key: TRAFODION-2032 > URL: https://issues.apache.org/jira/browse/TRAFODION-2032 > Project: Apache Trafodion > Issue Type: Bug > Components: db-utility-odb > Environment: centos 6.7 HBase 1.0.0-cdh5.4.8 > odb.exe on windows 7-64 bits >Reporter: zhangliang > > Copy data from Oracle to Trafodion by odb.exe on windows using the command > below: > odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp > src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v > The oracle table test and trafodion table trafodion.ODB_TEST.MYTEST both > exist and their formats are same. Also the table test has been inserted some > data. > But no data copied and no error occuer. > Log: > C:\odb_test>odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp > src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v > Connected to Oracle > odb [2016-05-30 17:34:05]: starting ODBC connection(s)... 0 >1 >2 3 >4 >5 > Connected to Trafodion > odb: Now truncating target table (DELETE FROM trafodion.ODB_TEST.MYTEST) > NO data copyed , and no error occuer. > [1.0.0]--- 0 row(s) deleted in 0.161s (prep 0.071s, exec 0.090s, fetch > 0.000s/0.000s) > [0] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE > MOD(ORA_HASH(ROWID), 2) = 0 > [3] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE > MOD(ORA_HASH(ROWID), 2) = 1 > [3] odb [Ocopy(10897)] - TARGET statement: INSERT INTO > trafodion.ODB_TEST.MYTEST VALUES (?,?) > [0] odb [Ocopy(10897)] - TARGET statement: INSERT INTO > trafodion.ODB_TEST.MYTEST VALUES (?,?) > odb: thread 4 closing connection... > odb: thread 5 closing connection... > odb: thread 3 closing connection... > odb: thread 3 is ending... > odb: thread 4 is ending... > odb: thread 5 is ending... > odb: thread 2 closing connection... > [0] odb version 1.1.0 Copy statistics: > [0] Source: TEST > [0] Target: trafodion.ODB_TEST.MYTEST > odb: thread 1 closing connection... > [0] Total number of columns: 2 > [0] ODBC row size: 297 B (data) + 16 B (len ind) > [0] Rowset size: 6,700 > [0] Rowset buffer size: 2,047.95 KiB > [0] Pre-copy time: 3.285 s (00:00:03.285) > [0] Copy time: 0.001 s (00:00:00.001) > [0] Total records copied: 0 (0.000 krec/s) > [0] Copy throughput (ODBC): 0.000 MiB/s (0.000 GiB/h) > [0] Total/Wait cycles: 0/0 > [0>1] 0 records copied in 0.001 (00:00:00.001 s) > [0>2] 0 records copied in 0.001 (00:00:00.001 s) > [3] Total/Wait cycles: 0/0 > [3>4] 0 records copied in 0.001 (00:00:00.001 s) > [3>5] 0 records copied in 0.001 (00:00:00.001 s) > odb: thread 0 closing connection... > odb: thread 0 is ending... > odb: thread 1 is ending... > odb: thread 2 is ending... > odb [2016-05-30 17:34:09]: exiting. Session Elapsed time 3.365 seconds > (00:00:03.365) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2033) Can't use symbol " as separator in windows
zhangliang created TRAFODION-2033: - Summary: Can't use symbol " as separator in windows Key: TRAFODION-2033 URL: https://issues.apache.org/jira/browse/TRAFODION-2033 Project: Apache Trafodion Issue Type: Bug Components: db-utility-odb Environment: centos 6.7 HBase 1.0.0-cdh5.4.8 odb.exe on windows 7-64 bits Reporter: zhangliang Priority: Minor Most of us are used to use " as the separator of strings, while " or ^" is not available for odb.exe parameter fs and sq on windows. Besides, it's better to update some information about what kinds of symbles can be used as fs and sq(or other separators) on linux and windows or other platform to Trafodion odb User Guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2034) Cannot output bad records in the loaded file even if specified file for storing bad records
zhangliang created TRAFODION-2034: - Summary: Cannot output bad records in the loaded file even if specified file for storing bad records Key: TRAFODION-2034 URL: https://issues.apache.org/jira/browse/TRAFODION-2034 Project: Apache Trafodion Issue Type: Bug Components: db-utility-odb Environment: centos6.7 HBase 1.0.0-cdh5.4.8 Reporter: zhangliang Priority: Minor This issue is from mantis 330. Load file where is bad record in it, with option bad=output_data/bad_records to hold the bad records, but the result is the file output_data/bad_records generated but it is empty lines. [root@suse-1 odb_test]# ./odb64luo -u trafodion -p traf123 -d traf -l src=output_data/ext_person3.csv:pre=@scripts/ddl_person3.sql:tgt=trafodion.odb_test.person3:max=1000:rows=5000:parallel=5:loadcmd=UL:fs=\|:sq=\":bad=output_data/bad_records odb [2016-04-25 19:17:05]: starting ODBC connection(s)... 0 1 2 3 4 5 [0.0.0]Executing: 'drop table TRAFODION.odb_test.person3;' [0.0.0]--- command executed in 7.279s (prep 0.001s, exec 7.278s, fetch 0.000s/0.000s) [0.0.1]Executing: 'CREATE TABLE TRAFODION.odb_test."PERSON3" ( PID BIGINT SIGNED NOT NULL ,FNAME CHAR(20) NOT NULL ,LNAME CHAR(20) NOT NULL ,COUNTRY VARCHAR(40) NOT NULL ,CITY VARCHAR(40) NOT NULL ,BDATE DATE NOT NULL ,SEX CHAR(1) NOT NULL ,EMAIL VARCHAR(40) NOT NULL ,SALARY NUMERIC(9,2) NOT NULL ,EMPL VARCHAR(40) NOT NULL ,NOTES VARCHAR(80) ,LOADTS TIMESTAMP(0) ,PRIMARY KEY (PID) );' [0.0.1]--- command executed in 1.388s (prep 0.002s, exec 1.386s, fetch 0.000s/0.000s) Connected to Trafodion [1] odb [Oloadbuff(9438)] - Error loading row 5 (State: 23000, Native 0) [Trafodion ODBC Driver] GENERAL ERROR. Null Value in a non nullable column. Row: 5 Column: 1 [1] 999 records inserted [commit] [0] odb version 1.1.0 Load statistics: [0] Target table: TRAFODION.ODB_TEST.PERSON3 [0] Source: output_data/ext_person3.csv [0] Pre-loading time: 10.920 s (00:00:10.920) [0] Loading time: 0.127 s(00:00:00.127) [0] Total records read: 1,000 [0] Total records inserted: 999 [0] Total number of columns: 12 [0] Total bytes read: 180,517 [0] Average input row size: 180.5 B [0] ODBC row size: 341 B (data) + 96 B (len ind) [0] Rowset size: 1,000 [0] Rowset buffer size: 426.76 KiB [0] Load throughput (real data): 1,388.080 KiB/s [0] Load throughput (ODBC): 2,619.487 KiB/s [0] Reader Total/Wait Cycles: 1/0 odb [2016-04-25 19:17:16]: exiting. Session Elapsed time 11.060 seconds (00:00:11.060) SQL>showddl person3; CREATE TABLE TRAFODION.ODB_TEST.PERSON3 ( PID LARGEINT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , FNAME CHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , LNAME CHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , COUNTRY VARCHAR(40) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , CITY VARCHAR(40) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , BDATE DATE NO DEFAULT NOT NULL NOT DROPPABLE NOT SERIALIZED , SEX CHAR(1) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , EMAIL VARCHAR(40) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , SALARY NUMERIC(9, 2) NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , EMPL VARCHAR(40) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED , NOTES VARCHAR(80) CHARACTER SET ISO88591 COLLATE DEFAULT DEFAULT NULL SERIALIZED , LOADTS TIMESTAMP(0) DEFAULT NULL NOT SERIALIZED , PRIMARY KEY (PID ASC) ) ; --- SQL operation complete. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2035) Not able to copy table where there is column with type timestamp(0), error out with ERROR[8102]
zhangliang created TRAFODION-2035: - Summary: Not able to copy table where there is column with type timestamp(0), error out with ERROR[8102] Key: TRAFODION-2035 URL: https://issues.apache.org/jira/browse/TRAFODION-2035 Project: Apache Trafodion Issue Type: Bug Components: db-utility-odb Environment: centos6.7 HBase 1.0.0-cdh5.4.8 Reporter: zhangliang This issue is from mantis 72. -> Create table as following in both oracle and trafodion: CREATE TABLE t_timestamp_0 ( PID int NOT NULL ,LOADTS TIMESTAMP(0) ,PRIMARY KEY (PID) ); -> insert data into oracle table begin for i in 1 .. 1000 loop insert into t_timestamp_0 values (i,systimestamp); end loop; commit; end; / -> using odb command as below to copy data to trafodion table, it is expected to success, but failed with 8102 error @dev1 odb_test]$ odb64luo -u jason:trafodion -p jason:traf123 -d OracleODBC-11g:traf -cp src=T_TIMESTAMP_0:tgt=trafodion.ODB_TEST.T_TIMESTAMP_0:rows=m2:truncate:parallel=2:splitby=pid -T 6 -v Connected to Oracle odb [2015-10-24 00:19:45]: starting ODBC connection(s)... 0 >1 >2 3 >4 >5 Connected to Trafodion odb: Now truncating target table (DELETE FROM trafodion.ODB_TEST.T_TIMESTAMP_0) [4.0.0]--- 0 row(s) deleted in 19.491s (prep 19.442s, exec 0.049s, fetch 0.000s/0.000s) [3] odb [Ocopy(10206)] - SOURCE statement: SELECT * FROM T_TIMESTAMP_0 WHERE pid >= 500 AND pid < 1001 [0] odb [Ocopy(10206)] - SOURCE statement: SELECT * FROM T_TIMESTAMP_0 WHERE pid >= 1 AND pid < 500 [0] odb [Ocopy(10548)] - TARGET statement: INSERT INTO trafodion.ODB_TEST.T_TIMESTAMP_0 VALUES (?,?) [3] odb [Ocopy(10548)] - TARGET statement: INSERT INTO trafodion.ODB_TEST.T_TIMESTAMP_0 VALUES (?,?) [1] odb [Oloadbuff(9437)] - Error loading row 3 (State: 23000, Native -8102) [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8102] The operation is prevented by a unique constraint. [2015-10-24 00:20:21] Row: 3 [1] 0 records copied [commit] [4] odb [Oloadbuff(9437)] - Error loading row 3 (State: 23000, Native -8102) [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8102] The operation is prevented by a unique constraint. [2015-10-24 00:20:22] Row: 3 [4] odb [Oloadbuff(9464)] - Unable to get row counts from driver [4] odb(9465) [2015-10-24 00:20:23] - [unixODBC][Driver Manager]Function sequence error (State: HY010 Native Err: 0) [4] odb(9465) [2015-10-24 00:20:23] - [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8102] The operation is prevented by a unique constraint. [2015-10-24 00:20:22] Row: 3 (State: 23000 Native Err: -8102) [4] 0 records copied [commit] odb: thread 2 closing connection... odb: thread 2 is ending... odb: thread 1 closing connection... odb: thread 5 closing connection... odb: thread 5 is ending... odb: thread 0 closing connection... odb: thread 0 is ending... odb: thread 1 is ending... odb: thread 4 closing connection... [3] odb version 1.1.0 Copy statistics: [0] Source: T_TIMESTAMP_0 [0] Target: trafodion.ODB_TEST.T_TIMESTAMP_0 [0] Total number of columns: 2 [0] ODBC row size: 62 B (data) + 16 B (len ind) [0] Rowset size: 26,886 [0] Rowset buffer size: 2,047.96 KiB [0] Pre-copy time: 28.434 s (00:00:28.434) [0] Copy time: 8.812 s (00:00:08.812) [0] Total records copied: 0 (0.000 krec/s) [0] Copy throughput (ODBC): 0.000 MiB/s (0.000 GiB/h) [0] Total/Wait cycles: 1/0 [0>1] 0 records copied in 9.297 (00:00:09.297 s) [0>2] 0 records copied in 9.257 (00:00:09.257 s) [3] Total/Wait cycles: 1/0 [3>4] 0 records copied in 8.811 (00:00:08.811 s) [3>5] 0 records copied in 8.769 (00:00:08.769 s) odb: thread 4 is ending... odb: thread 3 closing connection... odb: thread 3 is ending... odb [2015-10-24 00:20:23]: exiting. Session Elapsed time 37.287 seconds (00:00:37.287) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2029) odb.exe crashed on windows when several files in src
[ https://issues.apache.org/jira/browse/TRAFODION-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangliang updated TRAFODION-2029: -- Summary: odb.exe crashed on windows when several files in src (was: odb.exe crashed on windows when sevral files in src) > odb.exe crashed on windows when several files in src > > > Key: TRAFODION-2029 > URL: https://issues.apache.org/jira/browse/TRAFODION-2029 > Project: Apache Trafodion > Issue Type: Bug > Components: db-utility-odb > Environment: centos6.7 HBase 1.0.0-cdh5.4.8 > odb.exe on windows 7-64 bits >Reporter: zhangliang >Priority: Critical > > When extact multiple data tables from trafodion to windows using the command > below: > odb.exe -u trafodion -p traf123 -d traf -e > src=-conf/export_tbl_list.txt:tgt=output_data/ext_%t.csv:rows=m10:fs=,:trim:sq=^| > If there is more than one file in conf/export_tbl_list.txt, odb.exe will > crash in the end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2030) Copy data from Oracle to Trafodion no data copied and no error occur
[ https://issues.apache.org/jira/browse/TRAFODION-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhangliang updated TRAFODION-2030: -- Summary: Copy data from Oracle to Trafodion no data copied and no error occur (was: Copy data from Oracle to Trafodion no data copied and no error occuer ) > Copy data from Oracle to Trafodion no data copied and no error occur > - > > Key: TRAFODION-2030 > URL: https://issues.apache.org/jira/browse/TRAFODION-2030 > Project: Apache Trafodion > Issue Type: Bug > Components: db-utility-odb > Environment: centos 6.7 HBase 1.0.0-cdh5.4.8 > odb.exe on windows 7-64 bits >Reporter: zhangliang > > Copy data from Oracle to Trafodion by odb.exe on windows using the command > below: > odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp > src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v > The oracle table test and trafodion table trafodion.ODB_TEST.MYTEST both > exist and there formats are same. Also the table test has been inserted some > data. > But no data copied and no error occuer. > Log: > C:\odb_test>odb.exe -u zale:trafodion -p 123456:traf123 -d orac:traf -cp > src=test:tgt=trafodion.ODB_TEST.MYTEST:rows=m2:truncate:parallel=2 -T 6 -v > Connected to Oracle > odb [2016-05-30 17:34:05]: starting ODBC connection(s)... 0 >1 >2 3 >4 >5 > Connected to Trafodion > odb: Now truncating target table (DELETE FROM trafodion.ODB_TEST.MYTEST) > NO data copyed , and no error occuer. > [1.0.0]--- 0 row(s) deleted in 0.161s (prep 0.071s, exec 0.090s, fetch > 0.000s/0.000s) > [0] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE > MOD(ORA_HASH(ROWID), 2) = 0 > [3] odb [Ocopy(10552)] - SOURCE statement: SELECT * FROM TEST WHERE > MOD(ORA_HASH(ROWID), 2) = 1 > [3] odb [Ocopy(10897)] - TARGET statement: INSERT INTO > trafodion.ODB_TEST.MYTEST VALUES (?,?) > [0] odb [Ocopy(10897)] - TARGET statement: INSERT INTO > trafodion.ODB_TEST.MYTEST VALUES (?,?) > odb: thread 4 closing connection... > odb: thread 5 closing connection... > odb: thread 3 closing connection... > odb: thread 3 is ending... > odb: thread 4 is ending... > odb: thread 5 is ending... > odb: thread 2 closing connection... > [0] odb version 1.1.0 Copy statistics: > [0] Source: TEST > [0] Target: trafodion.ODB_TEST.MYTEST > odb: thread 1 closing connection... > [0] Total number of columns: 2 > [0] ODBC row size: 297 B (data) + 16 B (len ind) > [0] Rowset size: 6,700 > [0] Rowset buffer size: 2,047.95 KiB > [0] Pre-copy time: 3.285 s (00:00:03.285) > [0] Copy time: 0.001 s (00:00:00.001) > [0] Total records copied: 0 (0.000 krec/s) > [0] Copy throughput (ODBC): 0.000 MiB/s (0.000 GiB/h) > [0] Total/Wait cycles: 0/0 > [0>1] 0 records copied in 0.001 (00:00:00.001 s) > [0>2] 0 records copied in 0.001 (00:00:00.001 s) > [3] Total/Wait cycles: 0/0 > [3>4] 0 records copied in 0.001 (00:00:00.001 s) > [3>5] 0 records copied in 0.001 (00:00:00.001 s) > odb: thread 0 closing connection... > odb: thread 0 is ending... > odb: thread 1 is ending... > odb: thread 2 is ending... > odb [2016-05-30 17:34:09]: exiting. Session Elapsed time 3.365 seconds > (00:00:03.365) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
