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

 
 注册
热搜:
楼主: SQLSky

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

[复制链接]
论坛徽章:
0
11#
 楼主| 发表于 2017-12-22 11:29 | 只看该作者
newkid 发表于 2017-12-22 11:19
你如果是用INSERT ... VALUES ... 那是用不上APPEND, 可以修改成 INSERT /*+ APPEND */ ... SELECT ... FR ...

1. 我之前也想过,Append只能针对select的数据,但是实际环境是,应用层直接写数据到数据库的, 这样没有办法用到你说的那种,select没有数据源啊~我也查了比较多的资料,没有这种方法~
2. 哎,现在问题很头疼,目前生产环境不允许更改库结构,服务器不是在我们这。。。

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期: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秀才
日期:2016-01-06 14:10:21
12#
发表于 2017-12-22 11:44 来自手机 | 只看该作者
都跟你说了 select 变量 from dual, 何不试试?

使用道具 举报

回复
论坛徽章:
0
13#
 楼主| 发表于 2017-12-22 12:14 | 只看该作者
newkid 发表于 2017-12-22 11:44
都跟你说了 select 变量 from dual, 何不试试?

好的!下周一我去试一试

使用道具 举报

回复
认证徽章
论坛徽章:
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
14#
发表于 2017-12-22 12:36 来自手机 | 只看该作者
SQLSky 发表于 2017-12-22 08:59
1.入临时表用的批量绑定,用了Append,但是理论和实际上都没有什么效果;
2. 临时表UPSERT的时候,用了a ...

嗯,我就说呢,磁盘表到了8w/s也算不错了。1w/s带索引的情况下,也不算很慢。估计问题在索引或IO上,考虑分区吧。
服务器不在你那里,能访问库就可以的。
我也很少到现场的,不也一样干活?

使用道具 举报

回复
认证徽章
论坛徽章:
22
ITPUB 11周年纪念徽章
日期:2012-10-09 18:16:00天枰座
日期:2016-01-18 10:58:39马上加薪
日期:2014-10-21 18:48:25马上加薪
日期:2014-10-21 18:48:312015年新春福章
日期:2015-03-04 14:53:162015年新春福章
日期:2015-03-06 11:58:39沸羊羊
日期:2015-06-11 17:08:14巨蟹座
日期:2015-07-10 09:11:44秀才
日期:2016-02-18 10:08:14秀才
日期:2016-06-23 14:15:06
15#
发表于 2017-12-22 15:41 | 只看该作者
在源库里面把数据库转换好后用数据泵最快

使用道具 举报

回复
论坛徽章:
0
16#
 楼主| 发表于 2017-12-24 17:20 | 只看该作者
stevendba 发表于 2017-12-22 15:41
在源库里面把数据库转换好后用数据泵最快

没有源数据库的,直接从生产环境入库。
来自苹果客户端来自客户端

使用道具 举报

回复
论坛徽章:
0
17#
 楼主| 发表于 2017-12-24 17:28 | 只看该作者
sqysl 发表于 2017-12-22 12:36
嗯,我就说呢,磁盘表到了8w/s也算不错了。1w/s带索引的情况下,也不算很慢。估计问题在索引或IO上,考虑 ...

光看速度其实还可以,如果改了分区和换了存储的话,基本上可以满足现在的数据规模。
但是我比较想搞清楚我主帖中的关于redo和临时段的问题,卡在喉咙比较难受~
来自苹果客户端来自客户端

使用道具 举报

回复
论坛徽章:
0
18#
 楼主| 发表于 2017-12-25 08:44 | 只看该作者
@sqysl   @newkid
两位老哥帮们分析一下,附件是AWR日志~~

CET_2017_12_19.rar

48.99 KB, 阅读权限: 20, 下载次数: 4

使用道具 举报

回复
论坛徽章:
20
迷宫蛋
日期:2011-11-25 14:00:472015年新春福章
日期:2015-03-06 11:57:31天枰座
日期:2015-07-18 17:23:54暖羊羊
日期:2015-06-15 10:03:48托尼托尼·乔巴
日期:2017-01-25 09:38:19秀才
日期:2017-03-02 10:30:14秀才
日期:2017-03-02 10:30:35秀才
日期:2017-06-29 10:16:48技术图书徽章
日期:2017-07-11 09:10:26喜羊羊
日期:2015-03-04 14:49:39
19#
发表于 2017-12-25 10:02 | 只看该作者
本帖最后由 dhhb 于 2017-12-25 10:05 编辑

按照你说的数据量,16万条,总量3M左右,redo不可能那么大. 你现在一次执行多久,16万条入库+比较update,应该不到几秒的时间,如果超长了,看看是不是程序逻辑问题.

还有入库后的update,注意看看一个update,对应目标表的记录数有多少,是不是update的行数比16万要多很多.

使用道具 举报

回复
论坛徽章:
0
20#
 楼主| 发表于 2017-12-25 11:25 | 只看该作者
dhhb 发表于 2017-12-25 10:02
按照你说的数据量,16万条,总量3M左右,redo不可能那么大. 你现在一次执行多久,16万条入库+比较update,应 ...

一次是1.6W条数据,大概3M左右,现在的环境暂时不考虑更新,重复数据直接丢掉,全部时插入操作。
现在的规模比较大了,30亿数据量,速度降到了1W/S~程序逻辑应该没问题,但是看AWR,sql命中率好像不太高,这块需要优化,其他的依照我目前的Oracle水平实在是找不出什么问题了~

使用道具 举报

回复

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

本版积分规则

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 |
  | | |
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表