建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

Ivan_2020

发帖: 71粉丝: 9

发消息 + 关注

更新于2020年12月14日 15:54:41 1683 3
直达本楼层的链接
楼主
显示全部楼层
[博文鉴赏] GaussDB Kernel ODBC 问题定位指南

GaussDB Kernel ODBC 问题定位指南

1         基础知识

一个典型的用户应用程序如下:

image.png

 

用户的应用程序,调用的ODBCAPI,其实是由驱动管理器提供的,这个驱动管理器在微软上就是odbcad32(.exe/.dll),在Linux上就是UnixODBC。再由它们来调用ODBC的具体驱动(GaussOracleTD……)。

所以一般问题基本会出在以下几个方面:

·         应用加载驱动管理器

·         驱动管理器加载驱动

·         驱动连接数据库

2         问题处理

2.1        应用程序加载驱动管理器

2.1.1        Windows

Windows由于操作系统实现机制的问题,ODBC属于操作系统组件的一部分,除非操作系统损坏,一般不会出现应用程序加载驱动管理器失败;只会出现驱动管理器加载驱动失败。所以这里不再赘述。

2.1.2        Linux

Linux上应用程序加载驱动管理器,是指的应用程序依赖于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
解决此问题,只需要在UnixODBClib目录下,将不存在的版本建立成软链接,保证.1.2都存在,这样出问题的机率便会小很多。特别注意,这里强烈建议是建立软链接,而不要拷贝物理文件,不然可能出现一个应用程序进程中,加载了两个导出函数完全相同的.so,这样可能会引起一些比较难定位的启动错误,后文中会讲到。

2.2        驱动管理器加载驱动

 

2.2.1        Windows

最常见x86x64架构不同,导致的加载失败;此问题的典型报错为:

在指定的 DSN 中,驱动程序和应用程序之间的体系结构不匹配

此问题可能的原因:在64位程序中使用了32位驱动,或者相反。

64位系统上:

·         C:\Windows\SysWOW64\odbcad32.exe:这是32ODBC驱动管理器。

·         C:\Windows\System32\odbcad32.exe:这是64ODBC驱动管理器。

使用不同架构的应用程序时,请使用不同的驱动管理器;同时安装不同的驱动类型。

32位系统上只能跑32位程序,也无法安装64位驱动,所以基本不用区分。

如果是64位系统,那么它既支持32位程序,也支持64位程序;如果不能确定应用程序是32还是64,可以使用以下办法:

1.       ctrl + shift + esc 打开任务管理器

2.       查看进程列表中某进程后边有没有*32的字样(有就是32位,没有就是64位),如下图:

image.png

2.2.2        Linux

2.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 一下这个报错的文件,看看是不是真的缺少库,如果缺少库会出现如下问题:
image.png
要处理这个问题,需要将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/应用程序PID

cat environ

打印出来的结果可能比较乱,耐心看一下;如果内容有误,与应用程序开发人员对齐修改方法。

2.2.2.2       既有.2又有.1的库,导致重复加载

这种勤快的用户比较少见,但是一旦出现,很难定位,典型的报错信息是:

Driver's SQLAllocHandle on SQL_HANDLE_DBC failed

这种情况这时应用与驱动加载的是不同的物理文件,便会导致两套完全同名的函数列表,同时出现在同一个可见域里(UnixODBClibodbc.so.*的函数导出列表完全一致),产生冲突,无法加载数据库驱动。

解决此问题的办法也比较简单,查看LD_LIBRARY_PATH中的第一个unixodbclib目录。在其目录下,缺少.2.1,建立对应的.2.1的软链接便可。

2.3        连接问题

2.3.1        服务器不可达

典型报错:

connect to server failed: no such file or directory

此问题可能的原因:

·         配置了错误的/不可达的数据库地址,或者端口
请检查数据源配置中的ServernamePort配置项,确认网络是通达的。

·         服务器listen不正确
如果确认ServernamePort配置正确,请根据资料中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:这是32ODBC驱动管理器。C:\Windows\System32\odbcad32.exe:这是64ODBC驱动管理器。

3.       Linux下使用odbcinst -j 命令,查看当前环境中配置文件的正确路径,输出一般如下:

unixODBC 2.3.0
DRIVERS............: /usr/local/etc/odbcinst.ini/odbcinst.ini
SYSTEM DATA SOURCES: /usr/local/etc/odbcinst.ini/odbc.ini
FILE DATA SOURCES..: /usr/local/etc/odbcinst.ini/ODBCDataSources
USER DATA SOURCES..: /usr/local/etc/odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8

其中USER DATA SOURCES就是用户数据源,优先生效;SYSTEM DATA SOURCES是系统数据源,整个系统可用。请针对这些文件路径,

注意:有时用户数据源的配置文件可能是$(HOME)/.odbc.ini

2.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接口?

CopyPG的特有语法及通信协议;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其实只是UnixODBCconfigure配置的一部分,其函数导出,功能完全一致,不必纠结于此。

3.7        可以打印日志么?

可以。

一般建议打印驱动管理器的日志,此日志比较清晰,定位问题比较快。操作办法:

·         Windows上:

打开驱动管理器,调整到跟踪页面,确定日志文件路径后,点击开始跟踪便可,如图:

image.png

·         Linux上:

打开odbcinst.ini文件(可使用odbcinst -j 来确定文件路径),添加以下章节:

[ODBC]
Trace=Yes
TraceFIle=/tmp/odbc.log

         重启业务便可。

3.8        查询结果集过大,内存吃不消怎么办?

打开UseDclareFetch开关,它将会把查询包装成游标操作。对于不支持Cursor with hold的版本慎用。同时由于使用了服务器端的游标,游标的前后滚操作也会反馈给数据库,通信会有所增加,所以性能会有部分下降;可以通过调整Fetch参数来确定每次数据库向客户端反馈的数据量大小,来降低该性能影响。

·         Linux下打开UseDeclareFetch的方法:

在数据源配置项中添加:

UseDeclareFetch=1
Fetch=1000

·         Windows下打开UseDeclareFetch的方法:

image.png

         其中的Cache Size选项,就是Fetch的大小。

 

##如需完整附件,请留下您的邮箱,我们会及时发送给您

举报
分享

分享文章到朋友圈

分享文章到微博

角动量

发帖: 215粉丝: 8

发消息 + 关注

发表于2020年06月30日 14:31:44
直达本楼层的链接
沙发
显示全部楼层

感谢分享,满满干货

点赞 评论 引用 举报

GreatPeter

发帖: 7粉丝: 2

发消息 + 关注

发表于2020年11月16日 19:25:06
直达本楼层的链接
板凳
显示全部楼层

顶顶顶

点赞 评论 引用 举报

DWS殿阁大学士

发帖: 53粉丝: 15

发消息 + 关注

发表于2021年01月30日 14:06:14
直达本楼层的链接
地板
显示全部楼层

好文

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册