Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

0

好友

3

主题
1#
发表于 2013-4-28 10:55:47 | 查看: 9912| 回复: 10
请教各位:

之前生产碰到个问题,在ogg的源端采用impdp导入了2亿多的一张大表,机器配置是p750,16个cpu,因为源端短时间内导入大量的数据,oracle生成了大量的日志需要ogg的extract解析,导致ogg的extract进程占用内存过多把机器搞挂了。
想问一下,在ogg的环境下,如何处理大批量数据导入的问题?
现在ogg是安装在oracle用户下的,也可以将ogg安装在其他用户下,限制该用户使用服务器的资源限制。
2#
发表于 2013-4-28 11:03:12
我知道的方法有:
1.停机,导入的时候停止连接数据的所有应用,停止ogg的抽取进程,然后导入大量的数据,导入完成后,
alter extract xxx begin now,再起来ogg的进程,人为的跳过导入大量数据的日志的解析过程,在目标端手工再导入这批数据,以保持源端目标端的数据一致性

回复 只看该作者 道具 举报

3#
发表于 2013-4-28 11:04:51
2.将ogg安装在其他用户下,限制该用户的资源使用,以避免大量数据导入extract消耗过多内存的问题,
然后在该用户下慢慢解析日志,直到最后的追平数据,估计需要耗费大量的时间

回复 只看该作者 道具 举报

4#
发表于 2013-4-28 11:07:30
按照ogg的原理来说,impdp生成了大量的日志,extract肯定需要解析这些日志,所以性能肯定有问题,我也想不出来能有什么好方法能解决这个问题,想听听高手的意见,或许有新的思路,谢谢大家^_^

回复 只看该作者 道具 举报

5#
发表于 2013-4-28 11:39:29

一种思路 split large transaction

MAXTRANSOPS.

MAXTRANSOPS 1000
表示如果单个交易中的实际数据变化量超过了1千,replicat会每1千条进行一次提交。由于OGG的队列中全部是提交了的交易,使用此参数后只是交易被拆分为了多个依次提交,并不改变数据变化的顺序,所以对一致性并不影响。
需要注意的是使用MAXTRANSOPS时,如果出现了系统异常如目标数据库宕机,有可能出现Replicat的检查点还处在交易开始点,但实际已经投递到大交易的中间某个点了,这样再次重启会报告一些数据错误。此时可以通过使用reperror default,discard将这些冲突数据写入discard文件,等待追上后再去验证这部分数据在两端是否一致,一般情况下不需要重新初始化,如有问题可以联系技术支持予以协助。
(说明:OGG的GROUPTRANSOPS参数会将小交易合并为大一些的交易进行提交,也会改变交易边界,但一般不对资源要求产生较大影响)

回复 只看该作者 道具 举报

6#
发表于 2013-4-28 12:46:07
谢谢刘大回复^_^
MAXTRANSOPS是在目标端的参数已经设置过了。今天我在其他群里看到别人讨论这个问题,想起来自己几个月前也碰到过,当时由于磁盘空间不够,所以采用的是把ogg停掉了,然后后来重新初始化的。所以想问问如果下次碰到此种情况有什么解决的思路。^_^

回复 只看该作者 道具 举报

7#
发表于 2013-5-20 13:44:26
ellengan 发表于 2013-4-28 11:03
我知道的方法有:
1.停机,导入的时候停止连接数据的所有应用,停止ogg的抽取进程,然后导入大量的数据,导 ...

个人感觉这个方法靠谱

回复 只看该作者 道具 举报

8#
发表于 2013-5-23 23:08:50
to ghy1215:
艾,生产申请停机时间很不容易啊

回复 只看该作者 道具 举报

9#
发表于 2013-5-25 21:13:12
本人在 askmacleaan.com 的第一次发言,希望对你有帮助。Daniel 现在的生产环境大量使用了 OGG 同步,一个省一个省在上线,每上个省都会从以前的厂商迁移大量的数据,第一个省上线后,由于数据迁移的问题,有些数据有问题需要大批量修改数据,数据迁移人员几次偷偷修改数据读造成了OGG同步长达3、40 个小时的延迟,最后我们把权限全部收回。提出了一个解决方案。如果需要对数据做大批量操作(灌入、修改、删除),就在默认数据同步追平的情况下,同时在同步两端进行批量操作,与此同时 屏蔽 OGG extract 进对大批量操作的捕获。这一方案是通过在 extract 进程加入 TRANLOGOPTIONS  [EXCLUDEUSER <user name>] 实现的,也就是用一个单独的用户同时在两端执行大批量操作,让 Extract 进程不去捕获该用户的数据库行为。

回复 只看该作者 道具 举报

10#
发表于 2013-6-4 10:15:10
to xiangsir:
此方法在我们生产不可用,是因为我们生产的应用都是连接至同一个用户下的,不能导入至另一个数据库用户,应用不支持,而且我们是24小时不能停机的业务。
不过还是非常感谢您的回答,我想问一下: 让extract 进程使用excludeuser 不去捕获该用户的数据库行为,那此期间产生的数据库大量的归档,extract还要过一遍,此过程会有性能影响么?
按照此思路的话,extract进程加上过滤原用户的此张大表,extract同样需要过滤大量的归档,会不会有较大的性能问题?
以上两种方法在实现的本质上,不知道有何区别^_^

回复 只看该作者 道具 举报

11#
发表于 2014-8-25 13:58:00
ellengan 发表于 2013-6-4 10:15
to xiangsir:
此方法在我们生产不可用,是因为我们生产的应用都是连接至同一个用户下的,不能导入至另一个 ...

我在虚拟机上做过实验:重启所有ogg进程,然后查看进程使用的内存。
1.使用TRANLOGOPTIONS EXCLUDEUSER xxxx  使用xxxx这个账号对要同步的表大量插入数据,然后观察extract进程的内存使用情况,发现几乎没有增加。
2.使用不是EXCLUDEUSER账号进程同样操作,发现extract进程内存增加非常明显。

使用这种方法,应该不会出现ogg的extract吃内存过多的问题。你也可以测试一下。

环境:
os: CentOS5.9 X64
11.2.0.3.7 x64 源(ASM)
12.1.0.2    x64 目标(非ASM)
ogg
Version 12.1.2.0.0 17185003 OGGCORE_12.1.2.0.0_PLATFORMS_130924.1316_FBO
Linux, x64, 64bit (optimized), Oracle 11g on Sep 25 2013 00:31:13

回复 只看该作者 道具 举报

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

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-20 07:39 , Processed in 0.048617 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部