一、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字符集进行编码的一种编码方式。）详见知乎讨论：
http://www.zhihu.com/question/23374078
4、如何避免
1）最早设计的时候，定下数据库的编码格式，各个模块负责人按照统一格式进行处理。
2）编译器不同导致编码格式不同，需要大家统一接口进行转换。实现接口可参见如下： http://blog.csdn.net/p569354158/article/details/6567175
二、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有关。
