如果DB2 HADR的standby端的log replay很慢，很容易导致standby端的HADR receive buffer, HADR TCP receive buffer满,从而导致Primary端发的
消息得不到回应，Primary端被堵，最终application完蛋。
在HADR的db cfg里面有一个参数 hadr_spool_limit，它能设置log spooling，这个log spooling是个什么东西那？在standby log replay慢的时候，它允许把接收到的log以文件的方式放在Standby端，等Standby端慢慢来做replay
这听起来是一个很好的主意，尤其是当Primary端处于transaction的高峰期，log源源不断的被扔到standby端，standby端如果性能并不是很好，那log replay这个很费IO的活就干的很慢，有了这个参数设置以后，primary就不用干等standby的log replay了
既然接收到的log是以文件保存的，保存在哪里那？答案是在活动日志目录下面，所以有了这个参数以后，对于活动日志文件系统，要考虑大小。
在我看来，此参数和DB2_HADR_BUF_SIZE有着异曲同工之妙，一个设置的是文件的大小，一个设置的接受缓存的大小，都是为了稀释Primary端的业务高峰，等高峰已过，Standby端再慢慢消化。
嗯，有点用空间来换取时间的概念。