合理规划数据库大小提高Forefront性能。

 

　　Forefront跟大部分的应用系统一样，后台也需要数据库的支持。如对于Forefront Client Security 来说，其就需要用到收集数据库、报表数据库和Tempdb数据库。在部署这个产品的之前，需要合理规划数据库的大小。因为这直接跟Forefront产品的性能相关。而且如果数据库规划不恰当，如过小，则后续可能还会面临扩容的风险。所以规划数据库大小这项作业，是在Forefront部署中不可或缺的一项工作。

　　一、在Forefront数据库规划中主要要考虑的事项

　　在规划数据库大小的时候，我们需要抓住主要矛盾。也就是说，影响Forefront数据库大小的因素有很多，大概有数十项。如果我们在规划的时候，将每个事项都考虑进去，显然工作量会很大。为此笔者的建议是，我们在规划的时候，只考虑影响数据库的大小的注意因素。抓大放小的策略，在这里很有作用。

　　根据经验，笔者认为影响Forefront数据库大小的主要因素为“事件的个数”和“警报的数量”。当每天事件的个数比较多(如客户端数量很庞大)又或者用户的行为老是触犯警报(可能是规则设置的不够严密)，此时就需要比较大的数据库。相反，数据库的容量就可以规划的小一点。在实际应用中，由于企业组织架构、规模都是不同的，为此需要根据不同的情况来确定，没有一个统一的标准值。

　　不过在实际工作中，笔者发现很多系统管理员会走两个极端。这两个极端都会导致数据库大小的增加。一是服务器没有及时的更新，从而会遇到比较多的恶意软件或者攻击威胁，此时由于警报与事件的数量成几何级别上升，就会导致数据库容量的增加。二是规则设置的太过于严密，甚至影响到了用户的正常访问。此时也会因为用户频频触犯高压线，而使得警报和事件的数量增加，从而影响数据库的大小。为此笔者建议，系统管理员在实际维护中，需要避免这两个极端。然后根据企业的实际情况，评估一下警报和事件的数量，来规划数据库的大小。

　　二、收集数据库与报表数据库的关系

　　Forefront产品的后台数据库主要包括三部分：收集数据库、报表数据库和Tempdb临时数据库。其中前两者最重要。每天托管计算机(客户端)会将数据发送到收集服务器，然后收集服务器会见数据发送到报表数据库进行长期的保存。一般来说，收集服务器只保存最近的数据，而收集服务器则需要保存一年甚至更长时间的数据。具体保存时间的长短，需要看用户的需求而定。这也就是说，报表数据库的大小要比收集数据库大的多。在规划数据库大小的时候，若能够关注到这层关系，那么后续的工作会简单的多。

　　那么影响这两个数据库的大小又有哪些因素的?在这里笔者做了一些简单的总结。各位读者可以参考一下。一般来说，以下行为都会影响到这两个数据库的大小。一是恶意软件的发生频率(其会频繁触发警报，导致警报数量增加);二是执行的扫描次数和扫描类型(扫描的结果都会发送给收集数据库并存档，扫描的频率越高，其需要的数据库空间也就越大);三是托管计算机(客户端)的数量。在规划这两个数据库的大小的时候，需要综合考虑这几个方面的因素。

　　三、数据记录的保持与安全等级也会影响到数据库的大小

　　在上面的分析中，笔者谈到，每天客户端会将数据发送到收集服务器，然后收集服务器再将数据发送到报表服务器进行归档保存。现在的问题是，报表服务器的数据要保存多久呢?因为在同样的情况下，如果保存得纪录越久，这所需要的数据库空间也就越大。而这个保存的时间又跟企业的安全等级有关。通常情况下，如果企业的安全等级比较高，这数据需要保存的时间就比较长。

　　默认情况下，Forefront系统报表数据库保留的数据是395天，也就是一年又一个月。注意，这里Forefront系统为什么不把时间设置为一年，而需要多出一个月呢?其中蕴含着比较深的含义。各位读者可以在实际工作中慢慢体会。当了解他们这么设计的用意后，用户的水平能够提高一个档次。如果管理员需要延长这个期限，如需要记录保存两年零一个月的话，则可以在MOM中通过存储过程来更改这个保持期。对于普通的企业来说(如果对于安全没有特别高的企业)，这采用这个默认的期限就可以了。毕竟，如果要保存比较久的数据，就需要增加数据库的空间。而这不仅会浪费存储空间，而且对于后续数据的查询、检索、分析也会造成负面影响。故适度就好。

　　四、数据库空间增大或者减少的影响

　　对于大部分管理员来说，数据库大小的设置不可能一蹴而就。在以后的维护中，还需要根据实际的情况来调整数据库的大小。如压缩数据库或者增加数据库的空间等等。那么在执行这些维护操作的时候，该注意些什么内容呢?一个简单的原则是，不能够随意或者频繁的调整Forefront后台数据库的大小。因为这会造成比较大的负面影响。

　　如需要压缩数据库(如因为缩短数据保持期而减少报表数据库的大小)的时候，需要慢慢的减，而不能够一下子减到位。这是什么意思呢?如要将报表数据库的容量压缩50%。此时千万注意，不能够一下子将数据库的容量调整到位，而应该慢慢的压缩。如每次压缩10%，经过五次压缩后才调整到位。这是什么原因呢?因为数据需要在下一个整理周期才会从数据库中删除。如果一下子压缩到50%，这就需要删除大量的数据。而这个操作就有可能导致整理作业超时，从而影响系统其他服务的运行。

　　如果要增强数据库的容量也是如此。如增加数据的保持时间，很明显就需要增加数据库的空间。而此时手机服务器将数据发送到报表服务器的时间就会延长。为此如果真的有必要要延长记录的保持时间，增加数据库空间的话，笔者有一个建议：调整过后，要利用工具监视这个传输作业的持续时间。如果持续时间过长，就需要考虑采取额外的措施，将其控制在可以接受的范围之内。

　　五、Tempdb数据库

　　这个数据库比较特别，因为其大小跟上面所谈到的因素，如数据的保持时间等等基本无关。这个数据库主要用来在数据库维护任务和查询期间存储临时数据。每次重新启动SQLServer服务的时候，这个数据库就会被动态重新创建。

　　一般情况下，在规划数据库大小的时候，不用考虑这个数据库的大小。我们只需要将其配制为自动增长即可。虽然如此，笔者针对这个数据库还是有两个建议。一是有必要给其设置一个最大的可用空间。二是对于日志文件，需要给与特殊的关注。因为这是后续分析问题、解决文件的关键。