Get schemas does not return a schema being used in Trafci
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Trafodion |
Won't Fix
|
High
|
Suresh Subbiah |
Bug Description
This is a strange behavior that we sometimes saw in Trafci. As shown in the following execution output, the schema ‘TRAF_SYNTAX_MISC’ is being used. It contains the table MYTABLE and MYVIEW, but ‘get schemas’ does not return the schema name at all. This problem only seem to exist in Trafci. Running the same sequence of commands from sqlci returns the schema name just fine.
This problem is seen on the GIT 0606_0930 build installed on a cluster (centos-mapr1 in this case). There may be a caching issue somewhere. This problem may seem minor, but we have seen our Trafodion metadata falls into an inconsistent state and suspect that this strange behavior may be related. Therefore we want to document it.
-bash-4.1$ trafci.sh -h centos-
Welcome to Trafodion Command Interface
Copyright(C) 2013-2014 Hewlett-Packard Development Company, L.P.
Host Name/IP Address: centos-
User Name: dontcare
Connected to Trafodion
SQL>get schemas;
Schemas in Catalog TRAFODION
=======
G_ARKCASEDB
G_CMUREG
G_SQLDOPT
G_SQLDPOP
G_TPCDS1X
OPENCART
SCH2
SEABASE
T001A
T001B
VOLATILE_
_MD_
--- SQL operation complete.
SQL>set schema TRAF_SYNTAX_MISC;
--- SQL operation complete.
SQL>create table mytable (a int);
--- SQL operation complete.
SQL>get schemas;
Schemas in Catalog TRAFODION
=======
G_ARKCASEDB
G_CMUREG
G_SQLDOPT
G_SQLDPOP
G_TPCDS1X
OPENCART
SCH2
SEABASE
T001A
T001B
VOLATILE_
_MD_
--- SQL operation complete.
SQL>create view myview as select * from mytable;
--- SQL operation complete.
SQL>get schemas;
Schemas in Catalog TRAFODION
=======
G_ARKCASEDB
G_CMUREG
G_SQLDOPT
G_SQLDPOP
G_TPCDS1X
OPENCART
SCH2
SEABASE
T001A
T001B
VOLATILE_
_MD_
--- SQL operation complete.
SQL>
Changed in trafodion: | |
assignee: | nobody → Suresh Subbiah (suresh-subbiah) |
Changed in trafodion: | |
milestone: | none → r1.1 |
This problem was filed long time ago. There are many causes that would lead to metadata inconsistency. But nowadays, we tend to work on this area with narrower situations that have clear causes. When this case was filed, the purpose was to document that there is such a problem of metadata inconsistency. But the actual cause of this particular case has been lost in history. With so many improvement done in SQL and DTM between then and now, this problem has likely been fixed. This bug report will be closed for now. If a similar problem occurred in the future, either this one can be reopened with more info added, or a new bug report can be opened.