问题描述
嗨,汤姆
对于正在对表运行并行查询的用户报告,使用“交换分区”技术并发运行上载时,如何将出现ORA-12842错误的概率降至最低,请参考您的建议。
我们的业务要求禁止我们将上载限制在仅“维护窗口”内,并且希望用户在希望时运行他们的报告。最让我们困扰的是,即使对正在被查询的不同分区(当前分区与历史分区)进行分区交换,也会产生这样的错误。Oracle 11.2.0.4版。
任何技巧或技巧,包括对设计的重大修改,可以减少错误发生的机会?
谢谢你
斯坦
对于正在对表运行并行查询的用户报告,使用“交换分区”技术并发运行上载时,如何将出现ORA-12842错误的概率降至最低,请参考您的建议。
我们的业务要求禁止我们将上载限制在仅“维护窗口”内,并且希望用户在希望时运行他们的报告。最让我们困扰的是,即使对正在被查询的不同分区(当前分区与历史分区)进行分区交换,也会产生这样的错误。Oracle 11.2.0.4版。
任何技巧或技巧,包括对设计的重大修改,可以减少错误发生的机会?
谢谢你
斯坦
专家解答
MOS注释1322894.1描述了一种抑制错误的方法,但是在沿着这条路前进之前,我会非常仔细地思考。我敢肯定,在那篇文章中的解决方法是这样设计的:您*知道*数据的一致性没有随着对象定义的变化而改变(例如,添加一个空分区)
如果您正在交换分区,我假定您这样做是因为您已经更改了数据。但你看看那张纸条。
其他需要考虑的事项
1)动态最大限度地减少碰撞机会
当将要发生交换时,查询活动会话的v$sage ,使用SQL_ID将其驱动到V$SQLSTATS ,并探测活动查询中是否引用了相关表。如果是这样,暂停,然后在3秒等后重试...最后在(说) 60秒后决定是放弃交换还是继续进行。
2)最小化更换时间
在交换过程之外进行所有验证,这样您就可以使用“没有验证”等进行交换。与(1)结合使用,基本上是在试图尽可能地序列化操作,而不实际上阻止任何人。
3)分段视图
(我还没有测试这个,所以不能肯定它是否真的有用)
如果您知道大多数查询是针对(比如说)最近12个月的,并且您正在对比这更早的分区进行交换,那么创建一个视图,该视图是过去12个月所有这些分区的联合,并允许用户查询该视图。(我之所以说联合,是因为我的假设是,它比只在整个表上显示一个日期谓词的视图更能避免错误).
`
如果您正在交换分区,我假定您这样做是因为您已经更改了数据。但你看看那张纸条。
其他需要考虑的事项
1)动态最大限度地减少碰撞机会
当将要发生交换时,查询活动会话的v$sage ,使用SQL_ID将其驱动到V$SQLSTATS ,并探测活动查询中是否引用了相关表。如果是这样,暂停,然后在3秒等后重试...最后在(说) 60秒后决定是放弃交换还是继续进行。
2)最小化更换时间
在交换过程之外进行所有验证,这样您就可以使用“没有验证”等进行交换。与(1)结合使用,基本上是在试图尽可能地序列化操作,而不实际上阻止任何人。
3)分段视图
(我还没有测试这个,所以不能肯定它是否真的有用)
如果您知道大多数查询是针对(比如说)最近12个月的,并且您正在对比这更早的分区进行交换,那么创建一个视图,该视图是过去12个月所有这些分区的联合,并允许用户查询该视图。(我之所以说联合,是因为我的假设是,它比只在整个表上显示一个日期谓词的视图更能避免错误).
`
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




