一般来说，为了保障每日信息收集，每个企业都会配置/SDF/SMON的监控。这样在出现性能问题时，可以通过收集到的snapshot进行分析检查。如果/SDF/SMON在配置时选取了过多的记录项，或者选择了过低的时间间隔[Interval in seconds],那显而易见的是会收集更多的数据，很可能会导致内存以及磁盘size大量增长的问题。
从细节来讲，当我们使用Tcode /N/SDF/SMON开始记录数据，从HANA层面，监控快照会保存在表/SDF/SMON内。当完成1天的快照累计后，SAP会自动将已经收集好的快照们打包压缩到/SDF/SMON_CLUST表内。
当我们来看表定义，可以发现/SDF/SMON这个表，关键快照数据会存放在CLUSTD列中，数据类型为VARBINARY
而压缩后的快照数据会存在/SDF/SMON_CLUST表中，快照同样会存放在CLUSRD列内，但是这里的数据类型为BLOB。
很显然压缩后的数据会存放在HANA磁盘上，以减少对内存的占用。
当我们在Tcode /N/SDF/SMON中双击某一行来查看具体监控内容时，/SDF/SMON_CLUST中的压缩数据会抽取到内存并且解压到/SDF/SMON中。
此时从Tcode /N/SDF/SMON界面，可以看到这一列已经是Extract状态。
如果想把已经解压的数据放回压缩状态，可以在Edit里或者屏幕工具栏找到按钮来重新压缩。
【结论】
1.不要设置过小的颗粒度，这可能导致每日收集的数目过多。
2.只有在收集后解压数据或者进行查看时，才会对HANA性能造成真正风险。
3.定时清理监控内容可以有效的预防/SDF/SMON过大带来的性能风险。
