但是回过头来仔细考虑一下，那是不是为了能够存储尽可能长时间的历史数据，就把分段尺寸设定得巨大，分段时长也设置个 10年8年来满足长期保留历史数据的要求呢。这种做法肯定是不可取的。原因有两点：1.当尺寸设置得非常大，那么意味着当WinCC运行激活时，S就需要去加载巨大尺寸的数据库片段文件，可想而知这是非常影响 WinCC的激活速度以及S的性能的。2.所有分段设置得越长，又意味着单个分段有可能越多。同样当WinCC运行激活时，S就需要加载越多的数据库片段文件。
说到这插播分享一个遇到过Zui多的问题给大家：一些用户的项目在运行初期都很正常，而当运行半年多之后，WinCC的激活速度就明显变慢。经过项目组态的检查就发现了问题所在，用户设置了所有分段时间为1年，而单个分段时间为 1天。那么就意味着Zui终将会有 365个数据库片段，所以也就会出现项目运行半年之后 WinCC激活变慢。
那单个片段的尺寸和片段的时长以什么为界呢？经过测试比较，SQL数据库所能连接的归档片断Zui大可行的数量为200个。归档片断个数不能过多地超过这个数量，否则会影响MicrosoftSQL server运行性能。这反过来会导致数据管理错误。上面讲的激活慢的例子就是因为365个片段已经超过了这个限制导致了性能受到影响。
同时WinCC V7.5 SP1中单个归档片断大小不应该超过2G。
详细信息可以参考：
那如果按照这个设置，历史数据的存储时长就会受限了。其实不然，这个时候就需要充分利用 WinCC归档的自动备份功能了。
可以在 WinCC归档组态中启用归档备份功能，如下图所示：
激活备份功能之后，所有归档文件在单个归档分段文件完成15分钟后或达到分段Zui大尺寸之后都会被自动复制到备份归档目标路径下。其中备份路径可以是本地路径，也可以是网络路径。如果勾选了“备份到两个路径”选项，那么会同时在两个路径下保存备份归档。
看到这应该就明白了，只要启用了备份功能。那么无论之前的归档片段如何设置，在Zui早的单个片段被覆盖之前，原始片段文件都已经被复制到指定的备份路径了。所以只要硬盘足够大，历史数据永远不会被覆盖丢失。
Zui后的问题就是，虽然保证了归档数据库片段可以一直存储下来。那WinCC运行系统中是不是就可以直接查询到所有的历史数据呢？答案是否定的，WinCC运行系统中，缺省情况下只能查询到归档组态中设置的所有分段时间范围内的历史数据。要想查询到更早的历史数据，就需要将所要查询时间范围内的备份数据库片段重新加载到S，WinCC中也就能查询到更早的历史数据了。如何重新加载已备份的数据库片段可以参考：