oracle越界访问,Oracle字符乱码、数据越界访问典型Bug分析

Oracle字符乱码、数据越界访问典型Bug分析

前言：

作为乙方，在甲方客户那里验收阶段发现两个诡异Bug。以下就问题来源、问题根因、解决方案、如何避免做详细描述。

一、Bug1：Oracle读写字符乱码。

1、问题来源

Oracle数据库监听http://blog.csdn.net/laoyang360/article/details/46524519 需要获取最新插入的中文类别字符，以判定分类。单步调试发现每次接收到的都是乱码。

2、问题根因

编码格式不一致导致。

3、解决方案

第一步：查看oracle自身的编码格式，可以通过命令select userenv(‘language‘) from dual;查看。

查看后得知，目前多家公用的oracle采用SIMPLIFIED CHINESE_CHINA.ZHS16GBK编码格式。

第二步：查看后台程序使用的编码格式，后台程序通过OTL读取、写入orcle数据库。采用了设置环境变量putenv(),写入的是

NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8，也就是UTF-8编码格式。

第三步：由于oracle编码格式已经固定，只能修改后台程序写入环境变量的格式为IMPLIFIED CHINESE_CHINA.ZHS16GBK编码格式。

第四步：查看编译工具VS2010使用的编码格式，我们知道：VC6.0默认ANSI编码，而VS2010默认UNICODE编码。UNICODE编码和GBK编码格式不一致，需要进行转换。

第五步：查了很久，最终通过转换接口utf82gbk()以及gbk2utf8()完成格式转换。

也就是说：从数据库读出数据，需要调用gbk2utf8()进行格式转换才能在VS2010下正常显示。

同样的，向数据库写入数据，需要调用utf82gbk()接口进行转换，才能确保写入oracle不会显示乱码。

并且，前台程序统一为utf8编码，统一转化才能确保没有乱码。

至于Utf8和Unicode的关系(一句话，utf8是对unicode字符集进行编码的一种编码方式。)详见知乎讨论：

4、如何避免

1)最早设计的时候，定下数据库的编码格式，各个模块负责人按照统一格式进行处理。

二、Bug2：溢出，数据越界。

1、问题来源

程序频繁执行500个任务后，页面不能显示返回数据。从界面显示的数据看，序号为67138，67139，63140的都不能显示。

但是小的序号69，70都能正常显示对应的返回数据。

2、问题根因

数据越界访问，可能在程序的某个地方采取了2个字节unsigned short存储(最大范围：0-2的16次幂-1，即：0-65535)。

问题是如何发现的：

第一步：通过数字67138等猜测数据越界，原因：67138>65535。而69，70小于65535的都显示正常。

第二步：数据库入库编号和程序日志编号一一对比。查看得知：oracle对应的数据库表最早入库序号为67138等大于65535的值，但在程序第二次返回插入的结果表里变成了1618的序号值，而该序号非pointId，而是taskId或者systemId，也就是初步断定发生了越界访问。

第三步：研究为什么这个编号需要在数据库中唯一呢？和相关设计人员电话确认。因为后期的程序需求偏离了最早期的设计，此处在我看来完全不需要使用唯一值。只要保证每次任务下发唯一即可。因为我们的程序中由taskId索引唯一任务号，pointId的节点号为二级索引。程序使用查询表中也是，先一级索引后二级索引。

数据库中采用序列sequence进行唯一值递增判定，最大值设置的非常大999999999999999999999999999。且两个表的触发器Trigger都调用这个序列，也就说，程序的频繁任务下发任务中，频繁执行后，几周或者几个月很容易就超过65535的序号值。

综上，基本判定程序中出现越界访问导致显示异常。

3、解决方案

1)情况着急：采取简单规避方案：更新序列Sequence当前值，当前值已经查过67000，需要回归到1重新开始。

但有个知识点是，在sqldevelop以及所有的查看工具下，该值都不能手动修改。

需要删除后重建。用户必须具有ALTER ANY SEQUENCE 才能修改修改sequence，可以alter除start之外的所有sequence，如果想修改start值，必须drop sequence再re-create。

2)未来需要定位到哪里越界访问的，把类型至少改为unsigned int存储。

4、如何避免定义序号类型的变量，要考虑它的源头，如何产生的，最小值、最大值是多少，再确定定义哪种类型的变量。

总结：

1.两个Bug都不难，但都需要理清思路，避免走弯路。第一个Bug梳理到改完耗时3.5h，第二个Bug耗时5h。

2.第二个Bug很诡异，在我执行完500个任务就突然不显示返回数据。程序基本没有改动任何逻辑。想了很久，排除了非传输设备的影响，非搜索程序的影响，最终定位和65535有关。

2015-12-13 pm13:55 思于家中床前

作者：铭毅天下

如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！

原文：http://blog.csdn.net/laoyang360/article/details/50282569