在Exadata数据库上，一个`insert...select...`语句执行缓慢，等待事件为`cell smart table scan`。该事件通常发生在存储单元处理全表扫描时，但可能因过滤和列投影导致效率问题。尽管有时全表扫描比索引查找更快，但针对小结果集，索引可能更优。通过调整查询和使用并行执行，可以避免该等待事件。新版本可能存在未知问题，建议通过改写查询或使用其他方法规避。
情况描述：
在exadata上跑了12.1.0.2版本的数据库，昨晚有个跑批sql语句，执行了十几个小时依然没有执行完。
SQL语句就是一条insert...select...语句，单独执行select部分发现几秒钟可以出结果，数量也不大，但是当带上insert执行的时候，就一种遥遥无期的感觉。
在观察insert执行过程中，发现这条sql语句的等待事件一直是cell smart table scan，按照我个人理解，应该是单块读或者多块读方面的等待事件。
由于是在exadata上，很多技术我现在也不熟悉，有点一知半解。
在网上找了下关于cell smart table scan的解释：
This is an Exadata wait event typically seen during full table scans that have been offloaded to the storage cells. This event replaces waits on “direct path read” in many cases. As with direct path reads, data is returned directly to the PGA rather than going through the buffer cache. When the storage cells process full table scans they can apply columns filters an
最低0.47元/天 解锁文章
扫一扫
1829
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
