-1

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

时间-->年、月、日、小时
业务1--> 4级
业务2--> 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 所有级别(my_cube group by trunc(time,hour) , business1_levels ,subscriber)(2 亿 - 6 亿数据)
|
business2_hour_all level(my_cube group by trunc(time,hour) , business2_levels ,subscriber) (200million - 600 百万数据)
|
business2_day 所有级别(business1_hour group by trunc(time,day),business1_levels,subscriber)(3000万-5000万数据)
|
business2_day_all level(business2_hour group by trunc(time,day), business2_levels,subscriber) (3000万-5000万数据)
|
time_levels

有谁可以向我提供如何改进或解决刷新问题?

甲骨文版本:10g

服务记录表:

创建表 SERVICE_RECORD 并行 16 存储(初始 1M 下一个 10M)按范围分区(服务时间)(每日分区)作为 select s.id, s.servicetime, s.advariationId, s.blindId, s.action from tap_prod.service_Record s where s .servicetime > to_date('01/01/2012','dd/MM/yyyy');

我的主要数据组:
CREATE materialized VIEW tap_cube
parallel 16 storage (initial 1M next 10M)
partition by range( service_time )
(daily partition )
按需快速构建即时刷新
AS
SELECT TRUNC (sr.servicetime,'HH') as service_time,
sr.advariationid AS ad_variation_id,
sr.blindid ASblind_id,
COUNT (sr.blindid) AS total_impr,
SUM (sr.action) AS total_action , count(sr.action) as col1 ,
count(*) as col2
FROM service_record sr
group by TRUNC (sr.servicetime,'HH'), sr.advariationid, sr.blindid;

我的business1逻辑表:

业务一级:

创建物化视图 cube_ty_1_adv_1_time_4
并行 16 存储(初始 10M 下一个 100M)
按范围分区(service_time)
(daily_partition

按需快速构建即时刷新
SELECT
CAST
(mycube.service_time AS TIMESTAMP) AS service_time,
ADV.broker_id as entity_id,
blind_id,
SUM (total_impr) as total_impr,count(total_impr) col3 ,
SUM (total_action) as total_action , count(total_action) as col1 , count(*) as col2
FROM tap_cube mycube, dim_advertisement adv
WHERE mycube.ad_variation_id = adv.ad_variation_id
group by CAST ( mycube.service_time AS TIMESTAMP),ADV.broker_id,blind_id;

业务1维级别:

CREATE table
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
FROM
tap_prod.advertisement adv,
tap_prod.ad_variation ad,
tap_prod.campaign camp,
tap_prod.advertiser adver,
tap_prod.broker bro
WHERE
bro.id = adver.brokerid
and camp.advertiserid = adver.id
AND camp.id = adv.campaignid
and ad.advertisementid = adv.id;

4

1 回答 1

0

一般建议:

  1. 密切关注您的 PGA 和缓冲区缓存建议,以获得正确的平衡。
  2. 我见过的 Oracle 数据仓库性能不佳的最常见原因是 I/O 吞吐量不佳。你没有提到你的读/写带宽,但你应该知道并引用它。
  3. 至少有 3 种 MV 刷新机制——MV 日志、直接路径日志和分区更改跟踪。它们非常不同,使用的那些取决于您的数据加载机制。让我们了解更多有关这方面的信息。
  4. 62 MV 比我以前看过的还要多。如果您的 MV 在一个事务中全部刷新,那么如果不打开 10046 式跟踪或使用 AWR 等工具,您将难以监控和诊断它。根据我的经验,MV 刷新并非一直是最有效的过程,值得关注汇总表的手动维护以提高性能。
于 2012-12-11T08:28:32.490 回答