Persistent Feeders

jsyyrs

Persistent Feeders have problems with multiple DB folders defined in cfg. That's a known issue starting with 9.5.x through 10.1.1, the same is valid for a bunch of other TM1 functions (TI's, audit logs etc. either don't work or come back with weird errors in message log).
I have seen at least a couple of them on the fix list of 10.2, but not retestet yet.

wlx123

Gabor wrote:Persistent Feeders have problems with multiple DB folders defined in cfg. That's a known issue starting with 9.5.x through 10.1.1, the same is valid for a bunch of other TM1 functions (TI's, audit logs etc. either don't work or come back with weird errors in message log).
I have seen at least a couple of them on the fix list of 10.2, but not retestet yet.

And that too      

碧·染

Thanks ET & Gabor. For my environment, in CX9.0 it is taking 5hours to start up the environment (some of the cube is very heavy, it took 2hrs to fully loaded the feeder). and we only have 1 DB directory, hence, I think for our case, it might be good to use the PersistentFeeder?
Anyway, I had not really tried out using PersistentFeeder to load the environment yet, hence can't say how much it help in this. I will try out later in the evening, and update the new startup time here.

socaca

1st startup will take longer, subsequent starts are much faster then. I saw 50 min to go up to 75 min first and then down to 3 min.
Another idea, feeding is not equal to feeding. Apart from the feeder volume in source cube, it also depends on the destination cube and how far dim order is optimized there.
You may try to use the manual dim order optimization feature to try minimizing the amount of RAM after feeding. If you can get it down by lets say 80%, your feeder time will go down by a similar percentage.

孤云清云

Yes, you are right. Only the subsequent startup will be faster. For my case, from 5hours, it cut down to 30mins, and the data directory, the size increased by 3~4 times of the original size.