问题背景与现象安装OMS失败。原因分析查看gaussDB安装日志(/var/log/gaussdbinstall.log)，发现是初始化db失败，进而查看初始化db日志（/home/ommdba/gs_initdb-2016-06-13_162302.log）：日志中显示创建信号量失败，原因为超过了操作系统信号量资源的使用限制。【检查方法】：执行如下命令，查看操作系统信号量资源的限制参数：sysctl kernel.semkernel.sem = 2500 32000 1000 128其中第4个数据对应系统内核的SEMMNI参数，该参数用于控制整个Linux系统中信号集的最大数量。就GaussDB而言，这个参数至少应该为(max_connections / 16 + 1)。解决办法增大操作系统信号量资源的限制参数值（具体大小需要业务根据自己的资源使用来确定）：修改内核配置文件"/etc/sysctl.conf"，在此文件的任意位置增加如下参数：kernel.sem = 2500 32000 1000 1280Suse系统执行如下命令，使SUSE Linux启动时自动读取内核参数。（Red Hat系统可忽略）/sbin/chkconfig boot.sysctl on执行如下命令使内核参数生效。/sbin/sysctl -p修改后重新安装OMS即可。

问题背景与现象安装OMS失败，查看安装日志，提示could not translate host name "localhost" to address。原因分析查看安装日志“/var/log/Bigdata/controller/scriptlog/install.log”，报如下错误：从日志中可以看出是无法解析localhost的IP地址导致连接数据库失败，进而导致安装OMS失败。这是因为“/etc/hosts”中没有配置localhost 127.0.0.1。解决办法在“/etc/hosts”中增加一行localhost 127.0.0.1，卸载后重新安装。

问题背景与现象主OMS已安装成功，安装备OMS时启动ntp失败，提示Wait for ntp to startup timeout。===================================Welcome================================================== STEP 1 Preparing components...The ws_float_ip (10.103.100.106) already exists on the network.  Is it used on the active OMS HA? (y/n):yThe om_float_ip (10.103.100.104) already exists on the network. Is it used on the active OMS HA? (y/n):y=== STEP 2 Install packages. It may take several minutes. Please wait...    Waiting for ntp to satrtup.............................................................ERROR:Wait for ntp to startup timeout.ERROR:Installation failed.            Please run the following script to delete useless files:           /opt/huawei/Bigdata/om-0.0.1/inst/uninstall.sh原因分析分析NTP日志（/var/log/ntp.log），发现端口不同拒绝连接，提示connect refused。检查防火墙设置：chkconfig -lst | grep fire。解决办法先卸载已安装的备OMS。关闭防火墙设置。chkconfig SuSEfirewall2_setup offchkconfig SuSEfirewall2_init off重新安装备OMS，安装成功。

问题背景与现象安装OMS失败，报Failed to get omm db password。原因分析查看安装日志（/var/log/Bigdata/controller/scriptlog/install.log），报如下错误：java.security.InvalidKeyException: Illegal key size or default parameters        at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1011)        at javax.crypto.Cipher.implInit(Cipher.java:786)        at javax.crypto.Cipher.chooseProvider(Cipher.java:849)        at javax.crypto.Cipher.init(Cipher.java:1213)        at javax.crypto.Cipher.init(Cipher.java:1153)        at org.wcc.framework.util.encrypt.PasswordUtil.decryptByAes256(PasswordUtil.java:180)        at org.wcc.framework.util.encrypt.PasswordUtil.decryptByAes256(PasswordUtil.java:146)        at com.omm.encrypt.DecryptCommandMain.decryptCommandLine(DecryptCommandMain.java:71)        at com.omm.encrypt.DecryptCommandMain.main(DecryptCommandMain.java:130)[2014-12-09 10:58:47] ERROR Failed to get omm db password. [installcontroller.sh(main):788](12851)2.解密失败的原因最常见的就是JDK的版本不匹配，大数据FusionInsight系统会在omm用户下安装JDK。如果在安装以前root用户下已经有JDK或者JAVA_HOME环境变量，可能会导致安装FusionInsight失败。解决办法请卸载root用户下的JDK和JAVA_HOME。可以通过在root用户下执行env |grep JAVA_HOME查看。如果存在，请在“/root/.bash_profile”文件中去除JAVA相关环境变量，或者彻底删除安装的JDK，或者清除“/etc/profile”中的JAVA_HOME相关变量。

问题背景与现象OMS安装失败。原因分析查看日志，提示Failed to install ldap，具体内容如下：[2014-12-10 05:52:56] ERROR cleanUpCMD=/opt/huawei/Bigdata/om-0.0.1//ldapserver/ldapserver/ldapserver_wrap.sh [installLdap.sh(cleanup):173](31064)ERROR:cleanUpCMD=/opt/huawei/Bigdata/om-0.0.1//ldapserver/ldapserver/ldapserver_wrap.sh[2014-12-10 05:52:56] ERROR Failed to install ldap.scriptName=/ldapserver/ldapserver/ldapserver_wrap.sh,postinstallCMD=/opt/huawei/Bigdata/om-0.0.1//ldapserver/ldapserver/ldapserver_wrap.sh [installLdap.sh(postinstall):212](31064)ERROR:Failed to install ldap.scriptName=/ldapserver/ldapserver/ldapserver_wrap.sh,postinstallCMD=/opt/huawei/Bigdata/om-0.0.1//ldapserver/ldapserver/ldapserver_wrap.sh[2014-12-10 05:52:56] ERROR The input parameter is incorrect. [installLdap.sh(install):256](31064)ERROR:The input parameter is incorrect.[2014-12-10 05:52:56] ERROR install server failed [installLdap.sh(main):296](31064)ERROR:install server failed[2014-12-10 05:52:56] ERROR Failed to install the ldap [installLdap.sh(main):331](31064)2.查看“/var/log/Bigdata/oldapserver/ldapserver_install.log”，发现如下异常。2014-12-10 05:52:56 566 linux-126 SlapdServer ERROR ldap server rpm is not installed!2014-12-10 05:52:56 569 linux-126 SlapdServer ERROR ldap server rpm is not installed!解决办法缺少Ladp的相关rpm包，需要执行preinstall来进行包的添加。

问题背景与现象使用omm用户进行扩容，在执行preinstall的时候出现如下错误，报Permission denied。Connection to 182.218.146.10/ closed.Error: Execute failed on 182.218.146.107 (1)[Mon May 14 15:23:13 CST 2018] Error: Gen workspace failede on 182.218.146.107mkdir: cannot create directory '/opt/fi-preinstall': Permission denied原因分析分析preinstall日志（/tmp/fi-preinstall.log），日志中的打印和截图反馈中的相同，没有权限。查看 /opt/FusionInsight_SetupTool文件属组，发现是root:root执行preinstall的节点是oms节点，查看该节点omm用户并没有执行提权脚本preset.sh。解决办法修改属组在opt目录下执行chown omm:wheel FusionInsight_SetupTool -R在oms节点上也执行sh /opt/preset/preset.sh提权命令。如果存在root属组的/tmp/fi-preinstall.log文件先mv掉，避免omm用户没有权限写入日志。重新执行preinstall，问题解决。

问题背景与现象执行Preinstall，发现Add Package Failed导致PreInstall失败。原因分析分析preinstall日志（/tmp/fi-preinstall.log）。Preparing...                ###Preparing...                ############xorg-x11-libICE             ##################################################xorg-x11-libSM              ##################################################xorg-x11-libxcb             #####################################################xorg-x11-libX11             ##############################################################################installing package xorg-x11-libXau-7.4-1.15.x86_64 needs 20KB on the / filesysteminstalling package xorg-x11-libICE-7.4-1.15.x86_64 needs 132KB on the / filesysteminstalling package xorg-x11-libSM-7.4-1.18.x86_64 needs 176KB on the / filesystemError: Execute failed on 192.168.29.32 (17) ###[Mon Jun  8 15:51:38 CST 2015] Info: Run ./script//function/remote.sh -i 192.168.29.32 -P 22 -u root -a /tmp/fi-preinstall-ctrl/preinstall-p.bin -t 300 -m ssh-cmd -c rpm -ivh /tmp/fi-preinstall/192.168.29.32_rpms_dir/*.rpm failed, ret code:17[Mon Jun  8 15:51:38 CST 2015] Error: Install [ xorg-x11-libICE xorg-x11-libSM xorg-x11-libX11 xorg-x11-libXau xorg-x11-libXext xorg-x11-libXfixes xorg-x11-libXmu xorg-x11-libXp xorg-x11-libXpm xorg-x11-libXprintUtil xorg-x11-libXrender xorg-x11-libXt xorg-x11-libXv xorg-x11-libfontenc xorg-x11-libs xorg-x11-libxcb xorg-x11-libxkbfile ] on 192.168.29.32 failed. Please check rpm packages version.[Mon Jun  8 15:51:38 CST 2015] Info: Add packages failed on 192.168.29.322.根目录磁盘空间不足，导致安装失败。解决办法清理根目录磁盘空间或者扩容。执行preinstall。

问题背景与现象执行Preinstall，Add Package Failed导致PreInstall失败。原因分析分析Preinstall日志（/tmp/fi-preinstall.log）。[Thu Apr  9 18:16:17 CST 2015] Info: Run ./script//function/remote.sh -i 192.168.17.33 -P 22 -u root -a /tmp/fi-preinstall-ctrl/preinstall-p.bin -k /tmp/fi-preinstall-ctrl/known_hosts -t 300 -m ssh-cmd -c rpm -ivh /tmp/fi-preinstall/192.168.17.33_rpms_dir/*.rpm failed, ret code:16[Thu Apr  9 18:16:17 CST 2015] Debug: [/opt/patch/packages/squid-3.1.10-19.el6_4.x86_64.rpm] Leave [get_rpm_file:77][Thu Apr  9 18:16:17 CST 2015] Error: rpm -ivh /tmp/fi-preinstall/192.168.17.33_rpms_dir/*.rpm failed on 192.168.17.33[Thu Apr  9 18:16:17 CST 2015] Error: Add packages failed on 192.168.17.33 [Thu Apr  9 18:16:16 CST 2015] Debug: Leave [exec_cmd_r:60][Thu Apr  9 18:16:16 CST 2015] Debug: Leave [check_rpms_dir:86][Thu Apr  9 18:16:16 CST 2015] Error: [192.168.17.39] Setup os failed2.OS在安装完成后，又安装了OS补丁，有些RPM被升级到高版本了，导致有些有依赖关系的RPM包安装失败。解决办法            方法一：卸载OS补丁后，再重新执行preinstall。 方法二：下载高版本的RPM包，手动安装RPM包。

问题背景与现象执行Preinstall，发现OS优化失败导致PreInstall失败，提示Operation not permitted。原因分析分析Preinstall日志（“/tmp/fi-preinstall.log”）。Modify /etc/sysctl.conf failed for kernel.sysrq.sed: cannot rename /etc/sedEVdcVQ: Operation not permitted[192.168.17.39]Error: run /tmp/fi-preinstall/modules/050.setup/centos-6.x/setup.sh failed[192.168.17.39]Error: run setup_main 050.setup in [/tmp/fi-preinstall/modules/050.setup] failed[Thu Apr  9 18:16:16 CST 2015] Debug: [/opt/patch/packages:m2crypto.x86_64:0] Enter [get_rpm_file:23]Debug: Missing:bind.x86_64[192.168.17.39]Error: install failedError: Execute failed on 192.168.17.39 (50) [Thu Apr  9 18:16:16 CST 2015] Debug: [/opt/patch/packages:python-simplejson.x86_64:0] Enter [get_rpm_file:23][Thu Apr  9 18:16:16 CST 2015] Info: Run ./script//function/remote.sh -i 192.168.17.39 -P 22 -u root -a /tmp/fi-preinstall-ctrl/preinstall-p.bin -k /tmp/fi-preinstall-ctrl/known_hosts -t 18000 -m ssh-cmd -c bash /tmp/fi-preinstall/modules/install.sh -i "192.168.17.39" -p "0"        -c "" -s "1" -d "1" -k "1" -o "redhat-6.3;redhat-6.4;redhat-6.5;suse-11.1;suse-11.2;centos-6.4;centos-6.5" failed, ret code:50[Thu Apr  9 18:16:16 CST 2015] Debug: Leave [exec_cmd_r:60][Thu Apr  9 18:16:16 CST 2015] Debug: Leave [check_rpms_dir:86][Thu Apr  9 18:16:16 CST 2015] Error: [192.168.17.39] Setup os failed“/etc/sysctl.conf”这个文件添加了隐藏权限（i权限），导致文件修改失败。解决办法执行lsattr -a /etc/sysctl.conf查看文件隐藏权限。执行chattr -i /etc/sysctl.conf删除文件隐藏权限（i权限）。

问题背景与现象执行Preinstall，发现磁盘格式化失败导致PreInstall失败，提示Disk format failed。原因分析分析PreInstall日志（“/tmp/fi-preinstall.log”）。[Fri Jun  5 11:04:04 CST 2015] [ERROR] [check_swap:1058] sys swap and fstab swap are different.^M[Fri Jun  5 11:04:04 CST 2015] [ERROR] [check_system:622] check swap failed.^M[Fri Jun  5 11:04:04 CST 2015] [ERROR] [main:3216] check system failed.^M[Fri Jun  5 11:04:04 CST 2015] [INFO] [rollback_mount:2943] rollback no mount any yet.^M[Fri Jun  5 11:04:04 CST 2015] [ERROR] [none:3527] execute autopart.sh failed.^M[192.10.10.10]Error: run /tmp/fi-preinstall/modules/070.autopart/autopart/autopart.sh failed^M[192.10.10.10]Error: run autopart_main 070.autopart in [/tmp/fi-preinstall/modules/070.autopart] failed^M/tmp/fi-preinstall/modules/install.sh: line 249:  6036 Terminated              bash ${gc_mian_path}/${path}/schedule.sh "${gc_p_sched_file}" "${gc_sched_file}"^M[192.10.10.10]Error: install failed^MError: Execute failed on 192.10.10.10 (70)2.系统中的swap分区和“/etc/fstab”中的swap分区不一致。解决办法            1.执行swapon -s查看系统是否存在中swap分区。如果存在，请关闭（swapoff -a）。 2.检查“/etc/fstab”文件中是否包含swap分区记录信息，如果存在，请删除。

问题背景与现象执行Preinstall，发现磁盘格式化失败导致PreInstall失败，提示Disk format failed。原因分析1、析PreInstall日志（/var/log/fi-preinstall.log）[Fri Jun  5 10:15:30 CST 2015] [INFO] [get_blank_disk:1733] dev(sda) exists in mount.^M[Fri Jun  5 10:15:30 CST 2015] [INFO] [get_blank_disk:1733] dev(sdb) exists in mount.^M[Fri Jun  5 10:15:30 CST 2015] [INFO] [match_dev_size:1892] dev(sdc) size(99G) can match min required size(1G).^M[Fri Jun  5 10:15:30 CST 2015] [INFO] [disk_line_ready:2016] ready line conf(datanode1.conf) match dev(sdc) without condition.^M[Fri Jun  5 10:15:30 CST 2015] [ERROR] [disk_line_ready:2053] ready line conf(datanode2.conf) can not match dev.^M[Fri Jun  5 10:15:30 CST 2015] [ERROR] [disk_ready:2093] disk ready line(datanode2.conf  y  y  n ) invalid.^M[Fri Jun  5 10:15:30 CST 2015] [ERROR] [main:3300] disk ready failed.^M[Fri Jun  5 10:15:30 CST 2015] [INFO] [rollback_mount:2943] rollback no mount any yet.^M[Fri Jun  5 10:15:30 CST 2015] [ERROR] [none:3527] execute autopart.sh failed.^M2、服务器的空闲磁盘不足，导致datanode2挂载失败。解决办法如果是规划磁盘已经被挂载到系统中，请先卸载磁盘，再重新执行preinstall。如果是服务器磁盘不足，请添加磁盘，或调整集群规划减少挂载磁盘。

 1、适用版本FusionInsight V100R002C70*FusionInsight V100R002C80*GaussDB 200GaussDB 300FusionInsight Elk 6.5.1GaussDB A 8.0.02、问题背景与现象安装GaussDB 200GaussDB 300时报set os parameters failed、set os tcp failed；报找不到hung_task_timeout_secs、hung_task_panic或其它某个名称的参数，示例如下：3、原因分析/etc/sysctl.conf配置文件中存在无效参数，导致FI适配层在配置os参数，执行sysctl -p使参数生效时报错。4、解决办法登录执行报错的节点。切换用户到root打开/etc/sysctl.conf文件，找到报错的参数行，在行首添加#将其注释掉。

1      问题背景GaussDB 200分布式数据库，通常由于各种网络问题，导致查询异常、丢包、数据发送失败、并发作业hang等问题。网络问题产生的原因有很多种，例如网关ping不通、路由错误、子网掩码配置有误、IP冲突、节点间连接被关闭，MTU值不一致等。掌握网络问题定位方法对于大集群环境下快速解决网络故障至关重要。2      定位策略2.1      常用视图目前，GaussDB 200对外提供两类视图来辅助网络问题的分析定位，两类视图说明如下表所示，具体用法详见第三章的3.3节。pgxc_thread_wait_status    ☆☆☆☆☆查询集群全局所有线程的层次调用关系及查询在整个集群节点上的等待状态，确定查询阻塞状态。630版本对等待视图进行增强，丰富wait status列的显示信息，且将更多存在耗时等待可能的场景纳入wait status中，扩展之前none中间过渡状态为明确的状态，尽可能地辅助用户一键式查询等待视图获知更多系统实时等待信息。pg_comm_send_stream   ☆☆☆☆展示单个DN上所有的通信库发送流状态。登录到单个DN节点，查询此视图，如果视图中某个state的值持续为CTRL_HOLD，说明发送数据阻塞。pg_comm_recv_stream   ☆☆☆☆与pg_comm_send_stream视图对应，展示单个DN上所有的通信库接收流状态。 2.2      定位方法及处理措施通信问题分类如下图2.1，如集群部署在新的环境上通信就没成功过，首先怀疑是系统环境问题，此时需要检查系统环境问题以及集群配置；否则可能是节点故障导致执行报错。图2.1 通信问题分类针对这些问题具体的诊断措施及处理方法如下表2.1：表2.1 通信问题诊断措施及处理方法问题分类问题名称检查方式解决方案系统环境问题防火墙问题查看连接两端防火墙状态，检查是否有特殊规则iptables -L关闭防火墙或清理防火墙规则  service iptables stop网卡的MTU值是否一致查看连接两端网卡MTU（ethX指业务网卡）  ifconfig ethX|grep -i mtu设置MTU，如设置为1500  ifconfig ethX mtu 1500Redhat+bond+sctp造成的通信问题检查SctpChecksumErrors，不等于0则有问题  cat /proc/net/sctp/snmp|grep SctpChecksumErrors升级内核sctp模块或关闭checksums规避  echo 1 > /sys/module/sctp/parameters/no_checksums集群配置问题listen端口不存在CN日志出现如下报错  Error message: could not connect to server: Connection refused检查DN listen端口是否存在，listen端口协议是否正确  ssh 10.185.240.51 "netstat -anop|grep 31350|grep LISTEN"  需正确配置listen端口，保持与pgxc_node中的配置一致local_bind_address配置错误CN日志出现如下报错  Error message: sctp could not translate host name "192.168.1.215,192.168.1.155", errno: 111postgresql.conf中的local_bind_address字段只能设置一个IPIP不在受信任列表DN日志出现如下报错  FATAL: no pg_hba.conf entry for host "100.144.192.22"将100.144.192.22加入pg_hba.conf受信任列表节点偶发故障进程Core、OOM、DN主备切换ps ux检查被连接进程启动时间  查看被连接进程是否有重启日志非通信问题，进一步分析宕机、网卡故障查看被连接进程所在单板系统日志  vi /var/log/messages非通信问题，进一步分析内存不足导致发送失败CN日志报错  LOG:  Connection error datanode6  到报错DN日志上找到连接的对端  Poll has already closed by remote node[4]: datanode3  到连接对端DN上根据debug_query_id，找到断开连接的报错原因  Cannot allocate memory检查是否运行drop cache脚本  检查min_free_kbytes是否为系统总内存的5%以上  /sbin/sysctl -a|grep min_free_kbytes 节点持续故障节点状态问题cm_ctl查看节点状态非通信问题，进一步分析DN线程死锁gstack查看DN进程堆栈，发现死锁  如堆栈出现类似__lll_lock_wait非通信问题，进一步分析DN连接数满DN日志出现如下报错  FATAL: sorry, too many clients already, active/non-active: 15/185.增大postgresql.conf文件中的max_connections或减小并发随机端口用尽CN日志出现如下报错  Error message: sctp bind of localaddr 192.168.1.116 is not successfull and   errno 98查看随机端口配置是否合理  sysctl -a|grep ip_local_port_range  查看连接数，如连接数过大，需减小并发  netstat -anop|wc -l注：关闭防火墙或清理防火墙规则service iptables stop如果遇到如下报错：Redirecting to /bin/systemctl stop iptables.serviceFailed to stop iptables.service: Unit iptables.service not loaded.可以执行，来关闭防火墙：systemctl stop firewalldsystemctl disable firewalld原因：在CentOS 7或RHEL 7或Fedora中防火墙由firewalld来管理，不是iptables.service。2.3      基本步骤连接失败报错后可按照以下步骤进行定位：Step1. 检查是否是环境问题（防火墙，MTU，参数）·         若在连接报错之前集群已经不正常，优先考虑是环境问题导致，需检查防火墙、MTU、参数等；若系统环境配置均正确，继续检查系统集群配置；·         若在连接报错之前集群正常，则考虑可能是节点故障导致，继续定位；Step2. 检查集群个节点状态，检查是否有DN重启，网卡故障，宕机等若存在此类情况，说明是节点故障导致连接报错，继续定位；Step3. 通过报错的详细信息，查找日志·         若是gsql客户端查询报错，直接查看CN节点日志，通过报错日志查找debug_query_id，若未分配，通过线程id往上继续查看详细信息；若已分配，根据debug_query_id继续查看日志信息；·         根据上述线程id或debug_query_id，查找当前日志信息中的关键信息，若存在与对端节点相关的记录，则到对端节点上继续根据线程id或debug_query_id查找关键信息；以此类推，直到找到连接报错最终原因；Step4. 若上述方法仍然无法定位，查看不接受连接节点的堆栈信息。2.4      常用命令在进行网络问题定位过程中，经常会用到例如网络测速、网络参数调整等与网络相关的一系列操作，本节主要介绍在定位过程如何通过命令行配置网卡速度、测试网络实际带宽、查询网卡缓存队列长度、查看丢包信息、调整网络相关参数等。2.4.1        测试网络速度通过网络测速命令speed_test，可以测试网络的速度，并能验证网络可连接，万兆网络速度应该在700MB以上。# cd $GAUSSHOME../.././huawei/wisequery/script/inspection/lib/checknetspeed/# ./speed_test send 10.185.180.119 10001 tcp# ./speed_test recv 10.185.180.119 10001 tcp查看网络设备状态的统计信息，可看到eth8每秒接收和发送的数据包以及接收和发送的字节数。# sar -n DEX 12.4.2        测试节点间网络是否可连通过网络连接命令speed_test connect，可以测试两个DN或者CN到DN之间的网络是否可连接。# cd $GAUSSHOME../.././huawei/wisequery/script/inspection/lib/checknetspeed/# ./speed_test connect 10.185.180.119 10001 tcp2.4.3        查询网卡缓存队列长度大集群大负荷环境值设计要大，比如这个设置的4096，否则容易丢包。# ethtool -g eth0Ring   parameters for eth0:Pre-set   maximums:  --最大配置RX:             4096RX   Mini:        0RX   Jumbo:       0TX:             4096Current   hardware settings: --当前配置RX:             4096RX   Mini:        0RX   Jumbo:       0TX:             40962.4.4        查看丢包信息通过以下两种方式查看丢包信息：1、执行gsar.sh脚本，观察drop和resend，比例不高于0.01%，说明无丢包。# sh gsar.sh eth82、命令行方式查询RX表示接收的包，dropped表示丢包的数量，一般只有RX会有丢包，TX发送队列没有丢包，本网卡MTU的值是1500。# ifconfig -abond0     Link encap:Ethernet  HWaddr C0:BF:C0:20:29:49          inet addr:84.*. *. *  Bcast:84. *. *. *  Mask:255.255.255.0          inet6 addr:   fe80::c2bf:c0ff:fe20:2949/64 Scope:Link          UP BROADCAST RUNNING MASTER   MULTICAST  MTU:1500  Metric:1          RX packets:8834946013 errors:0 dropped:12379671 overruns:0 frame:0          TX packets:1295482128 errors:0   dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:13235953570465 (12622788.9   Mb)  TX bytes:83375946600 (79513.4 Mb)2.4.5        检查通信协议参数GAUSSDB对OS通信协议参数有严格约束，集群安装前置脚本会配置这些参数，gs_checkos也可以检查配置是否正确，如需人工排查，可使用net_para_check.sh脚本检查通信相关参数，要求修改为“must be”后的值。# sh net_para_check.sh通信依赖的系统内核、通信协议参数如下，定位过程中，无需关注所有参数，使用以上net_para_check.sh脚本直接检查即可。net.sctp.sctp_mem=94500000       915000000       927000000net.sctp.sctp_rmem=8192 250000 16777216 net.sctp.sctp_wmem = 8192 250000 16777216 net.ipv4.tcp_wmem=8192 250000 16777216 net.ipv4.tcp_rmem=8192 250000 16777216net.core.netdev_max_backlog=65535net.ipv4.tcp_max_syn_backlog=65535net.core.somaxconn=65535net.ipv4.tcp_syncookies=1net.ipv4.tcp_retries2=80net.ipv4.tcp_keepalive_time=30net.ipv4.tcp_keepalive_intvl=30net.ipv4.tcp_keepalive_probes=9net.ipv4.tcp_max_tw_buckets=10000net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1不使用drop cache脚本的环境需将vm.min_free_kbytes设置为系统内存的5%，最大15Gb，网卡收发队列设置为4096。 2.4.6        查看TCP协议栈缓存状态如遇到集群hang，怀疑是网络收发问题时，可通过观察TCP协议栈缓存状态确认。·         TCP协议栈接收缓存排序netstat -ant|awk '{print $2,$4,$5}'|sort -rn|head·         TCP协议发送栈缓存排序netstat -ant|awk '{print $3,$4,$5}'|sort -rn|head排查步骤：Step1. 集群产生hang，怀疑数据发送阻塞，首先查看发送缓存排序，如下图：Step2. 切换到接收端机器，根据发送端端口56614查看接收协议栈缓存状态，如下图：       有图中可看出，接收端接收了123120KB的数据。Step3. 分析导致发送协议栈缓存堆积的有以下几种原因：1)      观察对端接收协议栈，如接收协议栈空闲，则网络本身不通畅或达到网络性能上限，排查带宽瓶颈，排查单个CPU核是否满载。2)      持续观察接收端进程堆栈，接收线程是否存在hang或阻塞。Step4. 本例中，Step2步查询结果表明接收协议栈空闲，此时继续查看带宽使用情况，由下图可知，此场景是由于带宽达到上限导致。##常见案例，见附件，请留下邮箱，我们会将文件发送到您邮箱

1 内存基础知识1.1 操作系统内存内存是操作系统中程序使用的重要资源，一般使用以下命令查看系统内存使用情况free -gfree命令可以查看当前系统内存整体情况。如free列的值>min_free_kbytes，则系统中有可用内存，不会出现OOM。top命令可查看系统当前各个进程的内存使用情况。主要查看RES、SHR和%MEM列，RES为进程(实例)当前使用的物理内存量，SHR为进程(实例)当前使用的共享内存量，RES包含SHR。%MEM为进程（实例）当前占系统总内存的百分比。OOM(out of memory)：操作系统OOM指的是操作系统的一种保护机制，在系统无法分配内存时，会让oom-killer程序选择一个占用内存最高的进程，将其kill掉，以保证系统中其他进程能正常执行。在触发OOM后，OS会在/var/log/messages中打印相关信息，一般搜索oom-killer即可，日志中当时的系统中所有进程的内存使用情况，可以用于判断是不是数据库进程导致OOM.如果为数据库进程导致OOM，需分析数据库max_process_memory是否设置合理，适当调小max_process_memory来避免OOM。1.2 数据库进程内存数据库进程中使用内存层次如下：进程级内存：max_process_memory： 单进程所能占用的最大内存语句级内存：query_max_mem: 单语句在单DN上能占用的最大内存算子级内存：work_mem: 单个算子在单DN上能占用的最大内存。 公用内存：1.                   存储引擎使用的缓存（参数shared_buffers（行存）和cstore_buffers（列存））2.                   通信库使用的缓冲区（参数comm_usable_memory）3.                   其他（动态库申请的内存，一般很少，如果模块使用较多，请自行控制）其他内存：DDL语句，优化器、系统表cache等内存上下文管理的内存。 重要概念：内存上下文内存上下文可以简单理解为一个语句在一个实例中执行时，对所使用的动态内存按类型的一个树状结构。例如。Hashjoin语句在访问系统表时，要使用cache context,在创建哈希表时，要创建Hash context。所有动态申请的内存都由内存上下文管理。包括work_mem占用的内存，DDL语句、优化器、系统表cache等。  内存问题常用定位视图：目前，GaussDB 200对外提供诸多系统视图，可以用来辅助内存问题的分析定位，常用视图及用法说明如下表所示。（☆代表常用程度）pv_total_memory_detail ☆☆☆☆☆查询当前实例上整体内存使用状态和信息，可以看到各类型内存使用情况，来对当前实例上内存使用情况做一个概要的判断。select * from pv_total_memory_detail;Memorytype中各类型含义如下： 名称含义max_process_memory   实例可用最大内存阈值。由guc参数max_process_memory控制。process_used_memory  实例当前已使用的内存值，从OS top命令RES列取得。如process_used_memory已经或马上要超过max_process_memory，说明当前内存使用已经超限，或马上就要超限。max_dynamic_memory   实例可使用的最大动态内存dynamic_used_memory  实例当前已使用的动态内存dynamic_peak_memory  实例从启动后到目前为止的动态内存峰值dynamic_used_shrctx  当前已使用的共享内存上下文内存量，也记录在dynamic_used_memory内dynamic_peak_shrctx  共享内存上下文峰值。如减去sctpcomm_peak_memory后超过1G，说明共享内存没有释放，存在泄漏。max_shared_memory    最大共享内存，主要为shared_bubffers。shared_used_memory   实例当前已使用的共享内存，从OS top命令SHR列取得max_cstore_memory    列存buffer可使用的最大内存，由guc参数cstore_buffers控制。cstore_used_memory  实例当前已使用的列存buffer.max_sctpcomm_memory  通信模块可使用的最大内存。sctpcomm_used_memory 通信模块已使用的最大内存sctpcomm_peak_memory 通信模块峰值内存other_used_memory    其他内存占用，为OS  RES-     dynamic_used_memory- shared_used_memory- cstore_used_memory后的值。一般为系统中不受memory context管理的的第三方组件所占用的内存。如果过大，也有可能是内存泄漏。 pv_session_memory_detail ☆☆☆☆☆查看内存上下文级别的内存占用详细信息select * from pv_session_memory_detail order by totalsize desc   limit 100;视图中各字段含义如下：名称类型描述sessidtext线程标识+线程启动时间。使用substr可以将线程号过滤出来，方便和上述其他视图进行关联。sesstypetext线程名称。contextnametext内存上下文名称。levelsmallint当前内存上下文的层级。parenttext父内存上下文名称。totalsizebigint当前内存上下文的内存总数，单位字节。指的是分配给当前内存上下文的内存总数，为freesize+usedsize之和。freesizebigint当前内存上下文中已释放的内存总数，单位字节。是指当前你内存上下文中预留的内存，只有这个内存上下文可以使用，其他线程及其他内存上下文都不能使用，实际还是当前内存上下文中占用的。usedsizebigint当前内存上下文中已使用的内存总数，单位字节。       2 内存问题分类问题原因大类问题原因小类集群参数配置集群参数配置不合理OS配置OS参数配置不合理，主要为min_free_kbytes业务层面业务并发度增加业务SQL计划变化（含有hash、sort、agg等）是否新增业务CN报错SQL是否下推参数优化集群内存相关参数并发控制参数业务优化增加内存集群扩容内存泄漏软件BUG 3 内存问题定位方法及解决措施3.1 基本步骤1 Memory is temporary unavailable问题Step1. 当出现memory is temporary unavailable报错后，首先确认是哪个实例报错，是CN还是DN。Step2. 使用gsql登陆到报错的实例上，查询pv_total_memory_detail, 重点查看一下信息：1.       当前是否还存在内存不足问题。方法为查看process_used_memory和max_process_memory的关系，如已经大于或比较接近，则说明当前内存使用已经或即将超限。如明显小于，则说明占用内存大的语句已经跑完或者被杀掉。当前系统已经恢复。这时可查看对应的peak_memory值，如peak_memory值过高，说明确实曾经出现过内存使用过大。2.       当前是哪个类型的内存过大。最常见的是dynamic_used_memory过大，说明动态申请的内存过大，这类问题可能和客户正在运行的SQL强相关。Step3.如通过step2发现当前内存占用仍过高，则进一步使用pv_session_memory_detail继续分析，看内存占用过高是哪个内存上下文引起的。视图中有线程号信息及内存上下文信息，通过这些信息可以判定是什么语句的什么操作占用了过多内存，进而可以cancel此语句，并给客户提出语句优化建议。常见语句问题为：1.       SQL不下推。如内存问题在CN上出现，很大程度上是因为某个SQL的不下推导致。通过explain确认语句不下推后，将语句进行修改使其下推。2.       中间结果集倾斜。GaussDB 200在进行表关联时，优先使用hash join, 需要对一张表创建哈希表，当哈希表大小超过work_mem限制时，会进行下盘避免内存占用过多，但如果原始表里或中间结果集中在join列上存在大量重复数据，是无法下盘的，必须全部载入内存中进行计算，会造成内存大量占用。如pv_session_memory_detail中占用内存最大的内存上下文为hash context,则大概率是此问题。这时应对客户的表和SQL进行分析，对重复值进行处理后，再进行关联。Step4.如通过上一步没有发现内存占用过高的单个语句，但系统整体内存占用仍过高，则问题原因为参数配置不合理或用户语句并发设置不合理。1.       参数配置不合理。需评估系统关键内存参数是否设置合理。如用户将Poc环境直接转为生产。Poc环境为了追求极致性能，一般内存参数设置比较激进。而生产系统 需要长期稳定运行，内存参数设置应相对保守。此时应调整相关参数。a)         max_process_memory设置过小，导致内存不能充分利用而提前报错。b)        shared_buffer/cstore_buffer设置过大：shared_buffer设大可以增大缓存空间，提高数据读取效率，但如设置过大，会导致语句运行时无法申请到足够的动态内存，导致报错。c)         work_mem/maintainence_work_mem设置过大：在高并发场景下，work_mem设置过大可能导致所有语句的work_mem加起来超过可用动态内存的最大值，从而导致报错。 2.       语句并发设置不合理。此问题与参数配置不合理问题相关。语句并发高，则内存参数配置应较小；反过来说，如内存参数配置较大，则可支撑的语句并发也就相应的要变低。a)         局点上线后，或局点业务量增大后频繁报内存不足，很可能是因为max_active_statements设置过高，高并发的语句加起来后超出了系统可用内存上线，此时如检查第一点中参数都合理后，应将max_active_statements调小，让语句排序进行，避免一起运行时报错。b)        局点新上业务后报内存不足，很可能是因为新业务较为复杂，有多个表join、sort或group by。此时如分析不存在中间结果集倾斜，则需要将并发调小，或将work_mem调小。以上操作都可能导致业务响应时间变长，需要和客户确认。Step5. 如分析时已没有现场，则有3个方法来确认什么语句导致了问题1.       到报错的节点日志中搜索全部memory is temporary unavailable报错，分析可能是哪个语句导致的。2.       重新让客户运行业务，或等下次业务高峰期时进行分析。3.       打开active sql。打开后会将内存相关信息记到系统表中。 附：查看集群配置情况和关键参数（1）集群每个物理节点内存、每个节点dn个数；select sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;（2）监控session total memory size占用最多的TOP20 session 。select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  order by sum_total desc limit 20 ) a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid;（3）监控session中占用内存最多的context TOP20 session.select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;（4）监控当前实例总totalsize memroy大小select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;（5）监控当前实例总usedsize memroy大小select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;（6）监控当前实例内存总体使用情况select * from pg_total_memory_detail;（7）监控共享内存实时使用情况select * from pg_shared_memory_detail; 4. 通过打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）打开方法：gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_track =on' ;gs_guc reload -Z coordinator -Z datanode -N all -I all -c 'enable_resource_record =on' ;Active sql分析使用方法（1）查询2018-11-9峰值内存使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,max_peak_memory desc limit 10; （2）查询2018-11-9CPU使用top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,total_cpu_time desc limit 10; （3）查询2018-11-9查询时间最长的top10的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' order by nodename,duration desc limit 10;（4）查询2018-11-9SQL执行失败，错误信息为” memory is temporarily unavailable”且最大峰值内存超过1G的SQLselect * from pgxc_wlm_session_info where start_time like '%2018-11-1%' and status='aborted' and abort_info like '%memory is temporarily unavailable%' and max_peak_memory >1000 order by max_peak_memory desc;               （5）查询不下推的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and query_plan like ‘%_REMOTE_TABLE_QUERY_ %’;（6）查询不下盘的SQLSELECT * FROM pgxc_wlm_session_info where start_time like '%2018-11-9%' and warning like ‘%spill%’;2 操作系统OOM问题Step1. 查看OS日志：/var/log/messages,搜索oom-killer,确认额是否为gaussdb进程触发的OOMStep2. 分析数据库内存参数，确认设置是否合理，特别是max_process_memory;##常见案例，见附件，请留下邮箱，我们会将文件发送到您邮箱

GaussDB Kernel ODBC 问题定位指南1         基础知识一个典型的用户应用程序如下： 用户的应用程序，调用的ODBC的API，其实是由驱动管理器提供的，这个驱动管理器在微软上就是odbcad32(.exe/.dll)，在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动（Gauss、Oracle、TD……）。所以一般问题基本会出在以下几个方面：·         应用加载驱动管理器·         驱动管理器加载驱动·         驱动连接数据库2         问题处理2.1        应用程序加载驱动管理器2.1.1        WindowsWindows由于操作系统实现机制的问题，ODBC属于操作系统组件的一部分，除非操作系统损坏，一般不会出现应用程序加载驱动管理器失败；只会出现驱动管理器加载驱动失败。所以这里不再赘述。2.1.2        LinuxLinux上应用程序加载驱动管理器，是指的应用程序依赖于UnixODBC的相关动态库，启动时要将其加载到自己的进程空间中。加载出现问题多表现为在启动时找不到libodbc.so.x/libodbcinst.so.x等库。解决此问题：1.       首先确认环境中是否安装了UnixODBC。如果安装了，那么至少会有isql/odbcinst等工具可用。例如可使用which isql这样的命令来确定安装路径。相关的lib库一般会在which isql指定的bin目录的同级目录下，将其添加到LD_LIBRARY_PATH中重启应用程序便可。export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH特别注意，此语句只影响当前shell会话中的后续命令，其他会话不受影响，特别是后台启动的进程。如果是后台进程，请与应用程序的开发人员确认其运行环境如果修正。2.       如果确认LD_LIBRARY_PATH已经生效（可以打开/proc/应用程序pid/environ文件确认）,依然无法加载libodbc.so.x/libodbcinst.so.x，那么可能是.1或者.2的库的问题。历史原因，一般的开发环境中，UnixODBC提供的库既可能叫libodbc.so.1也可能叫libodbc.so.2。用户程序可能依赖了.2，但是环境中只有.1；也有可能是存在.2，但是依赖了.1。解决此问题，只需要在UnixODBC的lib目录下，将不存在的版本建立成软链接，保证.1与.2都存在，这样出问题的机率便会小很多。特别注意，这里强烈建议是建立软链接，而不要拷贝物理文件，不然可能出现一个应用程序进程中，加载了两个导出函数完全相同的.so，这样可能会引起一些比较难定位的启动错误，后文中会讲到。2.2        驱动管理器加载驱动 2.2.1        Windows最常见x86与x64架构不同，导致的加载失败；此问题的典型报错为：在指定的 DSN 中，驱动程序和应用程序之间的体系结构不匹配此问题可能的原因：在64位程序中使用了32位驱动，或者相反。在64位系统上：·         C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。·         C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。使用不同架构的应用程序时，请使用不同的驱动管理器；同时安装不同的驱动类型。32位系统上只能跑32位程序，也无法安装64位驱动，所以基本不用区分。如果是64位系统，那么它既支持32位程序，也支持64位程序；如果不能确定应用程序是32还是64，可以使用以下办法：1.       ctrl + shift + esc 打开任务管理器2.       查看进程列表中某进程后边有没有*32的字样（有就是32位，没有就是64位），如下图：2.2.2        Linux2.2.2.1       环境中缺少psqlodbcw.so的库一般这个问题的报错是[UnixODBC][Driver Manager]Can't open lib 'xxx/xxx/psqlodbcw.so' : file not found.可能的原因有：1.       odbcinst.ini中配置的路径不正确，最简单的办法是  ls -l 一下这个报错的文件，看看这个是不是真的存在，同时具有执行权限。2.       依赖的库不存在，此时最简单的办法是ldd 一下这个报错的文件，看看是不是真的缺少库，如果缺少库会出现如下问题：要处理这个问题，需要将unixodbc的安装目录下的lib，添加到LD_LIBRARY_PATH里，例如：export LD_LIBRARY_PATH=/where/unixodbc/installed/lib:$LD_LIBRARY_PATH同时，在UnixODBC的安装的lib目录下，看看libodbcinst.so.x后边的后缀是.1还是.2。如果是.2，那么请建立一个软链接，链接到.1，便可以解决此问题。如果该目录下只有.1的库，没有.2的库，也建议建立一个.2的软链接，防止应用程序依赖于.2，我们依赖于.1，引起冲突。特别注意，当前会话的LD_LIBRARY_PATH不代表应用程序运行时也是同样的LD_LIBRARY_PATH，必要的时候，与应用程序开发人员对齐。如果是常驻进程，可以通过如下方法获取到当前进程的环境变量：cd /proc/应用程序PIDcat environ打印出来的结果可能比较乱，耐心看一下；如果内容有误，与应用程序开发人员对齐修改方法。2.2.2.2       既有.2又有.1的库，导致重复加载这种勤快的用户比较少见，但是一旦出现，很难定位，典型的报错信息是：Driver's SQLAllocHandle on SQL_HANDLE_DBC failed这种情况这时应用与驱动加载的是不同的物理文件，便会导致两套完全同名的函数列表，同时出现在同一个可见域里（UnixODBC的libodbc.so.*的函数导出列表完全一致），产生冲突，无法加载数据库驱动。解决此问题的办法也比较简单，查看LD_LIBRARY_PATH中的第一个unixodbc的lib目录。在其目录下，缺少.2或.1，建立对应的.2或.1的软链接便可。2.3        连接问题2.3.1        服务器不可达典型报错：connect to server failed: no such file or directory此问题可能的原因：·         配置了错误的/不可达的数据库地址，或者端口请检查数据源配置中的Servername及Port配置项，确认网络是通达的。·         服务器listen不正确如果确认Servername及Port配置正确，请根据资料中listen_addresses参数的配置方法，确保数据库listen了合适的网卡及端口，特别是Servername中指定的网卡地址及LVS的虚拟IP地址。修改完记得重启数据库，使listen生效。·         防火墙及网闸、流控设备请确认防火墙设置，将数据库的通信端口添加到可信端口中。如果有网闸、流控设备，请确认一下相关的设置。此问题一般都是第三方商业产品导致，需要咨询服务/产品提供商相关的策略。2.3.2        SSL配置不正确典型报错1：The password-stored method is not supported.解决办法1：请将数据源配置中的的sslmode调整至allow及以上级别，允许使用SSL连接。典型报错2：Server common name "xxxx" does not match host name "xxxxx"  此问题是由于sslmode中使用了全校验(verify-full)，它不仅会校验证书，还会校验证书所在的域名/机器名是否与证书符合，不符合时将报出此问题。解决办法2：重新让CA机构以新的域名/机器名签发证书；或者将SSLMODE调整至verify-ca选项或其以下级别（具体级别见产品资料中的说明）。2.3.3        使用开源驱动连接问题我们的数据库是支持低版本及开源驱动的（V1R7C10及以后），所以可以放心使用。但是偶尔一些从V1R6C10升级上来的数据库，接受开源驱动连接时，会碰到用户认证算法不支持的问题，典型报错如下：authentication method 10 not supported.此问题机理比较复杂，下面详细展开，先说解决办法：·         请使用管理新账号新建一个数据库的用户，并给予其相关的访问权限，使用新用户连接数据库。·         更改当前业务用户的密码，使用新密码连接数据库。解释一下此问题发生的机理：我们的数据库在连接时，是会让客户端将认证信息发过来的。但是发过来的信息不会是明文密码，这是不安全的；客户端发到数据库的认证信息一般是经过加盐后的密码哈希(md5/sha256算法)，迭代次数也非常多。数据库本身也并不存储用户的明文密码，存储的是一个哈希值（所以密码要是丢了，就真的丢了，只能重置不能找回）。数据库在校验这个密码的时候，是比较哈希的，这就涉及到数据库中存储的哈希是使用的什么算法得到的哈希值，常见的是sha256（高斯自研）及MD5（开源）。V1R7C00及以前，数据库中只存储了SHA256的哈希，升级时我们也无法推导用户原有密码，所以升级后仍然只有SHA256的哈希；但是开源客户端只识别MD5的哈希，这就导致数据库无法认证；数据库也只会让客户端以SHA256的哈希来做认证，这时开源就不识别该认证请求，导致报出如上的错误。在创建用户和修改用户密码时，我们的新版本会同时记录两份哈希，所以后续将会同时支持开源及自研的各个版本。 2.3.4        因数据源配置不正确，导致的连接错误典型报错：Data source name not found, and no default driver specified可能原因：1.       数据源名称书写错误（或含有特殊符号）2.       不同的操作系统用户下，数据源可见性不一样；3.       Linux上的数据源配置文件(odbc.ini)位置不正确解决办法：1.       修正数据源名称2.       Windows下，请在当前用户下打开驱动管理器，查看数据源配置是否正确。请注意在64位系统上使用正确的数据源管理器：C:\Windows\SysWOW64\odbcad32.exe：这是32位ODBC驱动管理器。C:\Windows\System32\odbcad32.exe：这是64位ODBC驱动管理器。3.       Linux下使用odbcinst -j 命令，查看当前环境中配置文件的正确路径，输出一般如下：unixODBC 2.3.0DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.iniSYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.iniFILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSourcesUSER DATA SOURCES..: /usr/local/etc/odbc.iniSQLULEN Size.......: 8SQLLEN Size........: 8SQLSETPOSIROW Size.: 8其中USER DATA SOURCES就是用户数据源，优先生效；SYSTEM DATA SOURCES是系统数据源，整个系统可用。请针对这些文件路径，注意：有时用户数据源的配置文件可能是$(HOME)/.odbc.ini2.3.5        通信协议不匹配问题典型报错：unsupported frontend protocol 3.51: server supports 1.0 to 3.0可能原因：使用了新版本的数据库驱动连接老版本的数据库(V1R6C10)；或者使用了我们的驱动，连接到了开源的数据库上。解决办法：1.       请使用老版本的数据库驱动连接该数据库。我们的数据库中，默认低版本客户端可以连接高版本数据库；使用高版本驱动连接低版本客户端，不在规格约束范围内。这个规格也比较好理解：因为用户一般是对数据库集中管理，升级也是有计划的。但是客户端驱动可能嵌入到业务中的每一个角落，有时甚至是已经发布的装备中，升级相对比较困难。2.       如果是开源服务器：我们的数据库驱动不支持开源数据库，无法连接；请使用开源客户端连接。3         其他常见疑问3.1        与开源的区别？1.       增加了安全性，使用了SHA256算法做认证加密；同时调整密钥哈希加密次数2.       提升了批量性能（V1R7C10 2019-4-30及以后版本）3.        3.2        是否可以增加新API？不可以。还是基础知识里那张图，用户引用的API是由驱动管理器提供的，我们提供的API只可供驱动管理器使用；新增API无法穿过中间层为用户提供服务。3.3        是否支持COPY接口？Copy是PG的特有语法及通信协议;而ODBC是微软提出的通用调用接口，所以无此特殊接口。3.4        Linux上的驱动管理器有哪些？驱动管理器在Linux上并不是操作系统的一部分，它也是由其他开源组织开发的。所以并不是只有UnixODBC一种。但是目前使用最广泛的，其实只有UnixODBC，多数据操作系统安装时基本都已经自带了UnixODBC的某个特定版本；除此之外，还有iODBC等，现在已经慢慢退出市场了。3.5        UnixODBC的版本有限制么？有。我们支持2.3.0及以上版本。3.6        UnixODBC的.1与.2的库有什么区别？没有什么区别。这个与UnixODBC的历史有关，历史上有一段时间提供.1，后来做了一次大升级，动态库版本也跟着升级了，变成了.2。但是一大批存量业务受制无法运行，就又添加了.1的支持。.1与.2其实只是UnixODBC的configure配置的一部分，其函数导出，功能完全一致，不必纠结于此。3.7        可以打印日志么？可以。一般建议打印驱动管理器的日志，此日志比较清晰，定位问题比较快。操作办法：·         Windows上：打开驱动管理器，调整到跟踪页面，确定日志文件路径后，点击开始跟踪便可，如图：·         Linux上：打开odbcinst.ini文件（可使用odbcinst -j 来确定文件路径），添加以下章节：[ODBC]Trace=YesTraceFIle=/tmp/odbc.log         重启业务便可。3.8        查询结果集过大，内存吃不消怎么办？打开UseDclareFetch开关，它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标，游标的前后滚操作也会反馈给数据库，通信会有所增加，所以性能会有部分下降；可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小，来降低该性能影响。·         Linux下打开UseDeclareFetch的方法：在数据源配置项中添加：UseDeclareFetch=1Fetch=1000·         Windows下打开UseDeclareFetch的方法：         其中的Cache Size选项，就是Fetch的大小。 ##如需完整附件，请留下您的邮箱，我们会及时发送给您