转载

今天处理的三个小问题——20160120

今天处理了几件事情，有几件还比较有意思，我拿出三件来说说。
首先是早上有一个同学打电话求助一个问题，给我的反馈是他们目前有一个表，数据量越来越大，目前数据插入变得很慢。想问问我该怎么分析。对于这个问题，听起来还是有些模糊，稍后想他明确了数据库是10gR2的版本。至于他说的数据量是很大，目前是百万数据量，其实还可以了，不算很大，那么他说的速度很慢，到底有多慢，是1秒钟变为2秒钟还是更大，他说大概有30秒。
通过这个问题，可以简单猜想能让insert很慢的场景其实还是比较少的，至少对于增量数据的插入这一点上很难和锁联系起来了。简答和他确认了问题表的数据频率，他说主要就是insert。
然后简单了解了情况之后，我让他发了一个awr报告，然后给他打电话指导他完成了awr报告的生成。当然报告因为网络原因是没法发给我的。我简单贴出来几个后续的截图。
今天处理的三个小问题——20160120

通过这个可以看出来,数据库还是初始版本，DB time可以大体看出来负载其实也不高。其实整个系统的负载也不高，从TPS，redo这些可以看出来。不过其中的一个亮点就是物理读比较高，还有一个是硬解析比较高。如果放下看，buffer hit实在是很低，当然这个和本身的配置有一定的关系，就给了500M的sga，还是有一定的压力的。
当然这些是一个概要，我又要了一个等待事件的截图。可以看到排在首位的是scattered read，这个和大量的物理读还是可以印证出似乎有全表扫描。
今天处理的三个小问题——20160120

当然关于全表扫描和索引扫描，我也给同学简单解释了一下。接着就是从sql入手了，我提供了关键字，sql order by elapsed让他把截图发给我。
得到的报告内容如下：
今天处理的三个小问题——20160120

通过这个可以看到其实他这个服务器还是默认安装了OEM，估计他也没意识到这个工具的存在，当然主要的就是关心他所说的Insert相关的语句，但是没有相符的，但是找到了两条update。和他确认了一下，就是目前反馈插入慢的表，所以通过这个我可以简单得出结论，这个表没有索引，后续的结果想必大家也可以猜到了，加上索引这类的语句可能会飞起来。这也就见解说明了，得到的反馈不一定准确，还是需要一些简单的分析。当然这也算帮了同学一个小忙。后续可以继续跟进。

然后是公司处理问题的时候碰到了一个问题，目前存在两个数据库环境A和B,目前根据需求需要把A库中的一张表数据同步到数据库B中，表的数据其实还是非常少的，不到100条。看起来是一个非常简单的需求了，当然两个数据库环境还是大大不同的，数据库A是solaris环境10gR2,数据库B是linux环境11gR2.
一种很简单的思路就是使用db link来同步了，但是目前的情况是应用账户的密码都是加密，在属主账号中使用db link还是受限的。
那么我就尝试exp/imp这种文件级的同步方式，但是这个时候exp却报错了。看起来是哪里不一致了。
$ exp XXX/XXX@XXXX file=XXXX_new.dmp tables=XXX.XXXX
Export: Release 11.2.0.3.0 - Production on Wed Jan 20 18:26:49 2016
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
Export done in ZHS16GBK character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path ...
Current user changed to XXXX
EXP-00008: ORACLE error 904 encountered
ORA-00904: "POLTYP": invalid identifier
EXP-00000: Export terminated unsuccessfully
看错误应该是缺少了一个字段。至于这个字段从哪里而来，发现是属于sys.exu9rls的。
sh findcols.sh POLTYP
#################################
OWNER TABLE_NAME COLUMN_ID COLUMN_NAME DATA_TYPE DATA_LENGTH NULLABLE
-------------------- ------------------------- ---------- ------------------------------ --------------- ----------- ---------- --------------------
SYS EXU9RLS 12 POLTYP VARCHAR2(33) 33 Y
对于这个问题事后查找原因，发现是一个相关的小bug.
The Fix For Bug 7568350 Generates ORA-00904: "POLTYP" Error At Export Client (Doc ID 784038.1)
当然对这个问题我们打补丁还是不显示的，那么怎么办呢，还是得靠db link了，不过这个时候我们可以创建一个临时的public db link来做。
create public database link xxxxx 指向数据库A
然后使用insert xxxx select * from xxxx@link 的方式插入数据
然后删除public daabase link即可。

然后第三个问题比较有意思，目前的情况是运营的同学反馈有一个统计应用在某些天没有数据。然后开发同学就找到了我，然后想让我帮忙看看，按理说我应该直接推回去。不过还是为了配合工作，我从我的角度进行了检查，首先他提供的这个表test_storage中的数据来源对于DBA来说也是黑盒的。开发同学反馈说缺少12月半个月的数据，之后这部分数据又不上了，这个时候就让我有些意外，这都过去了一个月了，之前怎么没有发现，当然也是牢骚之言，得到答复和没有答复是一样的效果，还是需要查明原因。至于这部分数据的插入逻辑，看来还得靠自己了来摸清楚了，首先这是一个统计业务，那么这部分的数据应该来源于线上业务，所以说数据源是线上系统，数据需要同步到这个表中，目前是有一定的频率，主要是设置频度来完成同步，可能每天会定时来同步等，通过这些简单的信息就可以从系统级，数据库级进行排查，当然这个过程也是很顺利的，几分钟就去会出结果，发现一个存储过程会在每天的指定时间去同步数据到test_storage这个表里。
同步的逻辑是从线上的一个数据库去取得数据，然后使用游标的方式过滤得到，然后直接insert插入数据。看起来逻辑还是比较简单的。
那么问题来了，如果每天定时去同步数据，怎么会丢失了近半个月的数据，这个还得从一个小故障说起，在线的那个业务在12月初有了宕机的情况，然后切换到了备库，这个时候把防火墙的一个设置给弄丢了。导致这个统计库的数据同步被阻塞。当然也是耽误了好些天，也是在业务的推动下，问题反馈到了我这里，当时对其中的部分表的数据进行了追加。这张表当时没有提供，所以也没有进行处理，这不拖了些日子，最终还是浮出水面了。
当然解决的思路就很简单了，就是从指定的存储过程中找到相应的逻辑部分，然后改装一下，拼装成一个insert xxxx select xxx from xx where 的形式的语句来搞定。其实整个过程也就不到10分钟，但是还是需要对很多的背景情况进行了解，要不还是很难定位的。

正文到此结束