物化视图刷新20亿个数据

时间:2012-12-11 06:26:22

标签: oracle olap

我拥有一个拥有200gb记录(22亿数据)和强大硬件(16 cpu 32 gb ram)Oracle的庞大数据库。我需要在这些方面查询这些庞大的数据。每小时将200.000条新记录添加到我的事实表中

时间 - >年,月,日,小时
business1 - > 4级
business2 - > 3级
订户 - > 100万左

business1和business2匹配名为ad_variation的相同最低级别 1份service_record表(20亿条数据)

service_record包括时间戳记,订阅者ID,ad_variation_id

为了查询这些庞大的系统,我使用了62个物化视图,但系统有时会出现12008: ORA-12008: error in materialized view refresh path等问题。

我的系统
service_record(20亿数据)
|
my_cube(service_record group by time,ad_variation_id,subscriber)(5亿数据)
|
business1_hour all level(my_cube group by trunc(time,hour),business1_levels,subscriber) (2亿 - 600万的数据)
|
business2_hour_all级别(my_cube group by trunc(time,hour),business2_levels,subscriber) (2亿 - 600万的数据)
|
business2_day所有级别(business1_hour group by trunc(time,day),business1_levels,subscriber) (3000万--50万的数据)
|
business2_day_all级别(business2_hour group by trunc(时间,日期),business2_levels,订阅者) (3000万--50万的数据)
|
time_levels

有谁能告诉我如何改善或解决刷新问题?

Oracle版:10g左

service_Record表:

创建表SERVICE_RECORD并行16存储(初始1M下10M)  按范围划分(服务时间)  ( 每日分区  )as  选择s.id,s.servicetime,s.advariationId,s.blindId,s.action  来自tap_prod.service_Record s,其中s.servicetime> TO_DATE('01 / 01 / 2012' , '日/月/年');  

我的主要群体数据:
创建物化VIEW tap_cube
 并行16存储(初始1M接下来10M)
 按范围划分(service_time)
 (每日分区)
 根据需要快速建立立即刷新 AS
SELECT TRUNC(sr.servicetime,'HH')as service_time,
            sr.advariationid AS ad_variation_id,
            sr.blindid AS blind_id,
            COUNT(sr.blindid)AS total_impr,
            SUM(sr.action)AS total_action,count(sr.action)as col1,
count(*)as col2
     来自service_record sr
    由TRUNC组成(sr.servicetime,'HH'),sr.advariationid,sr.blindid;

我的business1逻辑表:

业务级别1:

创建物化视图cube_ty_1_adv_1_time_4
 并行16存储(初始10M,下一个100M)
按范围划分(service_time)
 (daily_partition
)  根据需要快速建立立即刷新 作为
选择
        CAST(mycube.service_time AS TIMESTAMP)AS service_time,
    ADV.broker_id为entity_id,
    blind_id,
    SUM(total_impr)为total_impr,count(total_impr)col3,
    SUM(total_action)为total_action,count(total_action)为col1,count(*)为col2
     来自tap_cube mycube,dim_advertisement adv
    在哪里mycube.ad_variation_id = adv.ad_variation_id
按CAST分组(mycube.service_time AS TIMESTAMP),ADV.broker_id,blind_id;

业务1维度:

创建表
    dim_advertisement
 AS
 SELECT bro.id AS broker_id,
  adver.id AS advertiser_id,
  camp.id AS campaign_id,
  adv.id AS advertisement_id,
  ad.id AS ad_variation_id
 来自   tap_prod.advertisement adv,
  tap_prod.ad_variation ad,
  tap_prod.campaign camp,
  tap_prod.advertiser adver,
  tap_prod.broker兄弟   在哪里     bro.id = adver.brokerid
   和camp.advertiserid = adver.id
  AND camp.id = adv.campaignid
   和ad.advertisementid = adv.id;

1 个答案:

答案 0 :(得分:0)

一般建议:

  1. 密切关注您的PGA和缓冲区缓存建议,以获得平衡。
  2. 我见过的Oracle数据仓库性能不佳的最常见原因是i / o吞吐量不佳。你没有提到你的读/写带宽,但你应该知道并引用它。
  3. 至少有三种MV刷新机制 - MV日志,直接路径日志和分区更改跟踪。它们非常不同,使用中的一个取决于您的数据加载机制。让我们了解更多相关信息。
  4. 62 MV比我之前看到的要多。如果您的MV全部在一次交易中刷新,那么您将难以监控和诊断它,而无需启用10046样式的跟踪或使用AWR等工具。根据我的经验,MV刷新一直是最有效的过程,可能值得查看摘要表的手动维护以提高性能。