ITPUB论坛-中国最专业的IT技术社区

 
 注册
热搜:
查看: 1835|回复: 29

[SQL] 海量数据入库,关于临时段和Redo的问题

[复制链接]
论坛徽章:
0
跳转到指定楼层
1#
发表于 2017-12-20 16:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
现在的测试环境是Win7+ORA 11G, 每次事务写数据16000rows,每行200B左右,目前的情况是表需要索引,我现在建了唯一索引,一直在不停的串行入库,目标是同一个表;
为了速度,我把表设置为非记录式,因为需要UPSERT,所以中间加了临时表中转,然后合并入库,redo log根据实际测试,我调整为2G,一共3组,实例都是用的oracl的自动管理,其他的都没有调,log_buffer调大了;

现在有几个问题:
第一,我在写数据的过程中,先入临时表,然后转入主表,这里面,包括表本身,以及索引都是非记录,向上的表空间和数据库级别,都是都没有强制日志,不管是临时表还是主表,目前的情况应该都是产生比较少的redo,但是实际监控中,redo大小2g,还是6min左右切换一次,这有两点问题,redo量大导致io问题,以及切换频繁导致了检查点问题,很多检查点没有完成的日志,所以这里想问下大神,为什么会有这么多的redo产生,能否避免,还是说我现在的数据规模,这样的redo比较合理?

2. 还是前面的,我是经过临时表中转,为了临时表,我当前用户自己创建一个默认临时表空间,每次都是16000*200B的大小经过临时表,算下来才3M左右,这么小的数据,而且还是临时表,oracle应该是可以keep在内存里面,但是实际监控中,临时表空间数据文件的读和写IO,一直居高不下。后面我换了Oracle所谓的内存表,虽然没有了IO,但是实际入库速度不增反降,虽然降的不是非常明显。这里想问下大神,这个是什么原因呢?

3. 最后就是我现在的环境,临时表是裸表,但是入库速度还是卡在8W/S左右,这个速度有没有提升的空间呢,实际上我将临时表空间移到SSD上,速度基本上差不多,这个是什么原因?
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
2#
发表于 2017-12-21 01:46 | 只看该作者
你的临时表是GLOBAL TEMPORARY TABLE?
我记得索引的维护是没法跳过REDO的。
你的UPSERT是用MERGE做的?在UPDATE之前有没有检查数据是否不一致,如果一致就不UPDATE?

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
3#
发表于 2017-12-21 14:47 | 只看该作者
1、upsert是什么?update+insert?即使你把表和索引的logging都关了,也还是会产生一些redo的,因为,Oracle要维护起码的关系库特征;
2、那得看buffer大小,而且,这种操作也可能会发生direct path write;你这里所谓的内存表是什么?
3、8w/s对一般环境来说,也算不错,SSD的优势不是吞吐量;
4、关键你得看当前库的瓶颈在哪块。

使用道具 举报

回复
论坛徽章:
0
4#
 楼主| 发表于 2017-12-21 16:38 | 只看该作者
newkid 发表于 2017-12-21 01:46
你的临时表是GLOBAL TEMPORARY TABLE?
我记得索引的维护是没法跳过REDO的。
你的UPSERT是用MERGE做的? ...

1. 是GLOBAL TEMPORARY TABLE。
2. 索引这个没查到信息,暂时还没时间验证,不过索引既然是支持nologging的,那么应该可以跟表一样尽量少redo的吧?
3. 是的,肯定是要做检查的,不然用这个就意义了。不过暂时只做了不一致的处理,一致的暂时丢掉了。

使用道具 举报

回复
论坛徽章:
0
5#
 楼主| 发表于 2017-12-21 16:43 | 只看该作者
sqysl 发表于 2017-12-21 14:47
1、upsert是什么?update+insert?即使你把表和索引的logging都关了,也还是会产生一些redo的,因为,Oracl ...

1. 是存在即更新,不存在即插入;
2. buffer应该是足够的,开了将近100mb。内存表sqlserver里面有,oracle 显式的将表keep到内存,kepp_buffer同样开的足够大,测试中也证明了数据是存在内存里面的。
3. 。。。
4. 瓶颈的大头还是在IO上,因为现在的硬件不够好,但是就算数据库放到存储上,未来如果还是目前的逻辑通路,那么临时表和redo依然会是个瓶颈。
5. 因为目前的redo和我预期的严重不符,我觉得有可能是我那个部分理解的有问题,或者说是实际上配置错误导致了,就想找出这个点来

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
6#
发表于 2017-12-21 17:20 | 只看该作者
SQLSky 发表于 2017-12-21 16:43
1. 是存在即更新,不存在即插入;
2. buffer应该是足够的,开了将近100mb。内存表sqlserver里面有,orac ...

1、MSSQL库的内存优化表,如果内存不足会报错;Oracle的keep表连报错也没有。
2、8w/s的数据量,产生楼主说的redo,不离谱。由此,如果有并发,或GTT为preserve rows,100m的keep buffer是否够也是个问题,GTT能否keep到buffer,我也不确定,没这么用过。
3、如果可能,楼主可取个数据处理峰值期间的awr,大家可以看看。

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
7#
发表于 2017-12-21 22:25 | 只看该作者
SQLSky 发表于 2017-12-21 16:38
1. 是GLOBAL TEMPORARY TABLE。
2. 索引这个没查到信息,暂时还没时间验证,不过索引既然是支持nologgin ...

插入的时候有没有用 /*+ APPEND */ ?
索引的NOLOGGING只是在创建的时候,还有REBUILD的时候起作用。你要么在插入之后才创建索引,要么将SKIP_INDEX_MAINTENANCE设置为TRUE, 然后过后再用NOLOGGING模式REBUILD索引。
我看到很多人写的MERGE都是用主键匹配,然后WHEN MATCHED UPDATE, 并没有判断数据是否真需要修改。你确定你做到了?代码大概是怎么写的?

使用道具 举报

回复
论坛徽章:
0
8#
 楼主| 发表于 2017-12-22 08:54 | 只看该作者
sqysl 发表于 2017-12-21 17:20
1、MSSQL库的内存优化表,如果内存不足会报错;Oracle的keep表连报错也没有。
2、8w/s的数据量,产生楼 ...

1. 理论上1.6W行的记录,肯定是可以保存在内存里面的,keep内存我设置的比较大,而且,根据系统试图,我们也能看到,内存表确实被keep到内存,而且写入之后数据正常;
2. 暂时还没有考虑高并发,GTT是delete的;
3. 我现在不在公司,没有环境,下周我跑一个AWR和ADDM,给你们看下~

使用道具 举报

回复
论坛徽章:
0
9#
 楼主| 发表于 2017-12-22 08:59 | 只看该作者
newkid 发表于 2017-12-21 22:25
插入的时候有没有用 /*+ APPEND */ ?
索引的NOLOGGING只是在创建的时候,还有REBUILD的时候起作用。你要 ...

1.入临时表用的批量绑定,用了Append,但是理论和实际上都没有什么效果;
2. 临时表UPSERT的时候,用了append hint, 不过貌似也没有什么作用。
3. 生产环境不允许插入之后重建索引,这个性能最严重的瓶颈部分,没办法优化;
4. 这个方法,根据实际测试和监控,主键也确实用到了,而且在转存的时候优点和缺点都非常明显;

:其实8W/S只是写临时表的速度,实际写到主表的话,因为索引和磁盘问题,越来越慢,另外由于生产环境问题,数据库老旧,没有分区,导致大批量的数据在一个表空间,虽然对应了多个数据文件了,但是依旧影响IO。现在表中已经有了将近30亿的数据,写主表速度已经降到1W/S了。。。

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
10#
发表于 2017-12-22 11:19 | 只看该作者
你如果是用INSERT ... VALUES ... 那是用不上APPEND, 可以修改成 INSERT /*+ APPEND */ ... SELECT ... FROM DUAL
MERGE没有APPEND的。
如果每天维护的数据都很有规律,尽快把主表进行分区,这样你可以用 CREATE TABLE AS SELECT来进行UPSERT,  维护之后的数据可以很方便地用分区交换进入主表。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

DTCC2018购票6.8折优惠进行时

中国数据库技术大会是国内数据库及大数据领域规模最大、最受欢迎的技术交流盛会。 2018年5月10-12日,第九届中国数据库技术大会将如约而至。本届大会以“数领先机•智赢未来”为主题,设定2大主会场及20个技术专场,邀请来自国内外互联网、金融、教育等行业百余位技术专家,共同探讨Oracle、MySQL、NoSQL、大数据等领域的前瞻性热点话题与技术。
----------------------------------------
优惠时间:2018年2月13日前

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 |
  | | |
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表
北京赛车pk10 申博官网 北京赛车pk10 六台宝典现场开奖 北京赛车pk10历史记录 北京赛车开奖 北京赛车预测 949494开奖结果今晚 威尼斯人线上娱乐 手机投注平台 幸运28投注技巧 pk10助赢软件 北京pk10百度鼎盛彩票网 北京赛车聚彩 北京pk10如何稳杀3码 pk10稳赢方法 pk10定位计划 pk10包赢计划群