标签：span content parameter targe 详细 UI 导致 update tuple
原文链接：Vertica “ERROR: Too many ROS containers exist”
近期在用Vertica的时候碰到一个问题，Vertica在执行了一段时间后总是出现相似以下的错误
java.sql.SQLException: [Vertica][VJDBC](5065) ERROR: Too many ROS containers exist for the following projections: <projection> (limit = 18078, ROS files = 12088, DV files = 5992, new files = 10)
碰到找个问题就不得不说说Vertica的存储机制了。Vertica在默认情况下会把新写入的数据写入到WOS（写优化）中，然后依据一定的条件（比方说一定的时间周期）再把WOS中的数据写入到ROS（读优化）中，这时ROS有可能非常多都是非常小数据块的碎片。这是Vertica会在一定的时间周期后把这些ROS数据块合并成大的ROS文件。
这里把数据从WOS写入到ROS的过程Vertica管它叫MoveOut操作，而把零散的ROS合并成大的ROS的过程Vertica管它叫MergeOut操作。
错误里报的是ROS太多，那可能的原因是
1. WOS写ROS太多，这个原因的原因非常大的可能是每次insert/update的数据集太小，导致生成的碎片太多。
2. ROS太多，而配置的MoveOut和MergeOut的时间间隔太长。导致来不及做MoveOut和MergeOut。
2. 对于第二个可能的原因，我们查了一下Vertica的资料。在Vertica中默认的MergeOutInterval是600，MoveOutInterval是300。
这两个參数能够通过以下的命令来查看
SELECT GET_CONFIG_PARAMETER(‘MoveOutInterval‘); SELECT GET_CONFIG_PARAMETER(‘MergeOutInterval‘);
因为我们的应用本身会产生非常多的ROS碎片。所以我们想到了是不是能够通过减小MoveOut和MergeOut的Interval来让Vertica尽快的做MoveOut和MergeOut。因此我们改动了Vertica的參数
SELECT SET_CONFIG_PARAMETER(‘MoveOutInterval‘, 60); SELECT SET_CONFIG_PARAMETER(‘MergeOutInterval‘, 30);
在改动了这两个參数以后。我们的应用确实在执行了非常长时间后都没有再出现上面的问题了。
Vertica “ERROR: Too many ROS containers exist”
标签：span content parameter targe 详细 UI 导致 update tuple
原文地址：http://www.cnblogs.com/ljbguanli/p/7118173.html
