问题描述
我试图更新我创建的母版视图的统计信息:
已经15个小时了,这个过程还在运行。
基表本身接近80gb,约有6亿行。物化视图是该数据的子集,因此可能在1/3左右。
主机具有40gb的ram和4个内核。我特别将估计百分比设置为自动,这样会更快,并且出于相同的原因,我将并行性/度设置为3。
我错过了什么,我应该看什么?
BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname => 'CSPRD', tabname => 'mv_llattrdata_shrinked', cascade => true, estimate_percent => dbms_stats.auto_sample_size, method_opt => 'for all columns size auto', degree => 3 ); END;复制
已经15个小时了,这个过程还在运行。
基表本身接近80gb,约有6亿行。物化视图是该数据的子集,因此可能在1/3左右。
主机具有40gb的ram和4个内核。我特别将估计百分比设置为自动,这样会更快,并且出于相同的原因,我将并行性/度设置为3。
我错过了什么,我应该看什么?
专家解答
我的猜测是直方图的昂贵排序。
但我们不要猜测-让我们得到证据。
试试这个:
exec dbms_monitor.session_trace_enable(waits=>true);
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(
ownname => 'CSPRD',
tabname => 'mv_llattrdata_shrinked',
cascade => true,
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all columns size auto'
);
END;
/
exec dbms_monitor.session_trace_enable(waits=>false);
请注意,我已经在这里串行获取单个跟踪文件中的所有数据。
让它运行一段时间,然后查看跟踪数据。
DBMS_STATS只是在幕后运行许多SQL,因此即使在运行时,您也可以监视V $ SESSION (以及v $ active_session_history,如果获得许可) 来获取导致问题的SQL_ID。
但是我的怀疑是直方图过多,因此减少直方图可能是最终的解决方案。
但我们不要猜测-让我们得到证据。
试试这个:
exec dbms_monitor.session_trace_enable(waits=>true);
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(
ownname => 'CSPRD',
tabname => 'mv_llattrdata_shrinked',
cascade => true,
estimate_percent => dbms_stats.auto_sample_size,
method_opt => 'for all columns size auto'
);
END;
/
exec dbms_monitor.session_trace_enable(waits=>false);
请注意,我已经在这里串行获取单个跟踪文件中的所有数据。
让它运行一段时间,然后查看跟踪数据。
DBMS_STATS只是在幕后运行许多SQL,因此即使在运行时,您也可以监视V $ SESSION (以及v $ active_session_history,如果获得许可) 来获取导致问题的SQL_ID。
但是我的怀疑是直方图过多,因此减少直方图可能是最终的解决方案。
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。