杨建荣的学习笔记

每天坚持一点点,个人微信公众号 jianrong-notes

  • 博客访问: 11928964
  • 博文数量: 1202
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1100多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1202)

文章存档

2017年(135)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Oracle

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

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

当然关于全表扫描和索引扫描,我也给同学简单解释了一下。接着就是从sql入手了,我提供了关键字,sql order by elapsed让他把截图发给我。
得到的报告内容如下:

通过这个可以看到其实他这个服务器还是默认安装了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分钟,但是还是需要对很多的背景情况进行了解,要不还是很难定位的。

阅读(10324) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册