ITPub博客

现象近来有一个客户那个经常性的EsgynDB起不来。从CDHManager看起来Hadoop集群是正常的，但trafodion用户执行hbcheck确显示HBase状态异常。原因使用trafodion用户执行hbcheck显示Unavailable，但CDHManager中显示正常。于是执行hbas

OutOfOrderScannerNextException

EsgynDB数据库中使用DBManager可视化工具通过调用python脚本的方式来执行备份导出的任务。在数据库节点的cds目录下有相关备份恢复的执行脚本如edb_br_action.py。此脚本正常情况下均运行正常，但在个别运行很久的环境中，我们偶尔发现脚本会有执行卡住的问题。通过在脚本中关键位

2020年10月有31天，2020年11月有30天，当在2020年11月30日做减一个月的运算时，普通数据库，按照11月30日是改月最后一天，减去一个月的值为10月31日，EsgynDB减去一个月不同的写法有不同的结果，更能满足客户不同场景的需求；oracle:SQL>selectadd_mo

目前，易鲸捷数据库支持Authentication（认证）和Authorization（授权），Authentication通过额外的LDAP服务来管理账号密码，EsgynDB通过和LDAP交互把LDAP中的用户注册为数据库用户；Authorization允许通过GRANT/REVOKE方式实现不同

现象EsgynDB所在的集群，HBase有4台RegionServer，因某种原因有一个RegionServer下线。从CDHManager中手动启动此RegionServer无法启动，报错信息如下，2019-08-0310:40:48,501ERRORorg.apache.hadoop.hbase

现象在某些特殊情况下，我们已经清除了schema，但getschemas仍然存在，使用dropschema或cleanupschema均提示schema已经不存在，如下述步骤所示，SQL>getschemas;SchemasinCatalogTRAFODION=================

现象某环境突然发现连接不上数据库，使用JDBC或trafci连接数据库报错如下：***ERROR[8837]Internalerroroccurred.User:XXX分析报错ERROR[8837]Internalerroroccurred.一般是数据库与LDAP连接认证出现问题。所以遇到此报错后，

现象EsgynDB中创建带增量备份的表，出现长时间不结束的现象。DTM日志中有报错如下，分析表带增量备份属性，建表时有一个额外的snapshot动作，此动作执行时会在zookeeper中临时注释一个znode节点，其他建表动作若要完成需要等待此LOCK结束。解决从zookeeper-client中删

鉴于当前的EsgynDB版本(2.4及更早)的数据库用户/密码使用LDAP来存储管理，对于LDAP的安装肯定是安装过程中不可或缺的一部分。目前常用的开源的LDAP软件有OpenLDAP、FreeIPA。其中，FreeIPA包含的内容比较多，它集成了LDAP、kerberos、tomcat等多个组件，

在EsgynDB2.5版本及后续版本中，支持了对MySQL数据库中unix_timestamp及from_unixtime函数的兼容性实现。unix_timestamp用于得到一个固定timestamp对应的unixtimestamp值，类型为整形。from_unixtime用于从一个固定的unix

EsgynDB自2.4版本以后添加一个新的dump命令，可以用于导出模式、表或其他对象定义到文件中，具体语法为，DUMPobject_typeobject_nameTOFILE'location';object_type:SCHEMA|TABLE|VIEW|SEQUENCE|LIBRARY|FUNC

Ⅰ解压odb：解压odb后，在bin目录下有文件odb64luo，该文件就是odb的命令执行文件；例如：./odb64luo-h查看odb命令帮助信息odb64_linux-2.7.0.tar.gzⅡ验证odb配置：./odb64luo-lsdrvbin目录下执行III验证能否连接到指定数据源：./

在当前版本中，EsgynDB的SPSQL存储过程默认是不支持中文的，如果需要支持中文，需要在cds目录下添加对中文支持的配置文件，并同步到每个EsgynDB节点。中文配置文件命名为hplsql-site.xml，内容如下，<configuration><property>&l

EsgynDB的SPSQL存储过程的执行日志保存在每个节点的$TRAF_HOME/logs/trafodion.sql.java.log文件中，默认情况下数据库不会打印存储过程中的执行信息，如执行的每条命令。存储过程的日志级别的配置信息保存在$TRAF_CONF/log4j.sql.config文件

在已经发布的EsgynDB2.5版本中，对update的性能做了优化。从语法上，我们增加了新的语法updateusingupsert，详细语法如下，updateusingupsert<tablename>set<colname>=<colvalue>where..

I.建表A.主键/聚集键Trafodion表按主键排序，若查询经常按某个字段做WHERE过滤，适合将此字段放置于主键/聚集键注意事项：（1）主键字段长度应尽量短，如VARCHAR(100)字段就不适合放在主键（2）除非必须存储中文，否则对于字符类型，尽量用CHAR/VARCHAR(nBYTES)，而

clipVarchar假如数据库中一张表，定义宽度为100KB，实际存储宽度为1KB，默认情况下从SQL引擎->Mxosrvr->客户端，两个阶段传输均按最大定义宽度100KB来传输，在网络带宽不是特别好的情况下性能会下降较大。当有clipVarchar=1时，数据在Moxsrvr层会被

Trafodion通过DCS作为客户端和数据库服务端的连接桥梁。默认情况下，Trafodion安装完只有一个DCSMaster进程，每个Trafodion节点一个DCSServer进程。殊不知，DCS是可以配置HA来保证高可用和稳定性。Trafodion安装过程中可以配置DCSHA，配置DCSHA需

EsgynDB数据库的使用中有时候会碰到一些mxosrvr的core的情况，此时需要分析core产生的原因。常规的做法是执行gdbmxosrvrcoreName，然后执行t，看一下堆栈的情况。一些常规的手段可以收集一下client&server的基本信息，展示如下：(gdb)bt#00x00