Suddenly Long GTP and Reconcile

[ashishberry]

My contributor application would (in the past) take roughly 10-15 minutes to run a complete GTP and reconcile. Recently, it's starting to take hours to accomplish both tasks. The model itself has not gotten larger or more complex. Is there a reason that a GTP would jump from taking 15 minutes in the past to over 2 hours now? Do I have to restart any services? I restarted the server and the Cognos itself which has not helped the situation at all. Does anyone have any other ideas? Thank you!

[ykud]

Cyclic dlinks\calculations or Access-Tables change are first suspects.
Did you add new links? New elements?

[blackadder]

Doesn't happen often in these days of large capacity but Planningerrorlog and Database log files can grow large. Are you ok for disk space?

Another thing to consider is how much more data there is in the app than when you started.

[aaday]

what database are you using?

[jv_oz]

Check that you don't have any circular references (or near circular references) in your d-links or d-links that now break back.  Short of those, check what has changed in Analyst since the reconciliation process started taking so long. 

[Gunes]

Good Afternoon,

My first & foremost question would be:

(1) Have you experienced this change for ALL of your applications, or is it application specific - from this you can pretty quickly identify whether the problem is model related or architecture/envrionment specific.

(2) -What has changed?

What I would do from an adminitrative purpose is to ask everyone who is involved what has changed irrespective of whether it's a model/architecture/IT related change.
In most occasions this is the part which is extremely hard to answer, but with anything, something has to have changed for you to experience this sudden decrease in performance.

Some options/avenues to consider as mentioned above:

(A) Mass data load/density within the model - don't forget the reconcile and the engine which sits behind is essentially crunching the numbers, therefore with more data you will see the reconcile job take longer.

(B) Destructive changes: when there is a model change - In this scenario the chances are that the reconcile will happen for ALL elist items, hence why you are seeing an increase in times, because the actual number of elist items you are reconciling is great where as in the past, you've only done GTP/Reconciles for data loads (Imports/Admin link to dev to name a few)The data loads can happen for certain child nodes thus only needing to do a reconcile on the child nodes and it's parent & grandparent nodes.

(C) Introduction of cylical links - you can determine by switching on verbose logging on the client and going from one cube to another, and checking the planningtracelog.

(D) Transactional logging - what are these set to for the application databases/schemas

(E) Any amendments to the number of maximum concurrent threads dedicated to a job server? - This value is the number of Jhost7.exe processors spawned by a job server. Are all the job servers active? When the reconcile job is running you can check within the admin console, in the monitoring section, all the job threads executing elist items, alternatively you can check by running a job doctor within the macro section, which will give you an informative html doc, on average times it took to reconcile an item, which job servers took the longest to reconcile items, etc etc etc.

I've also realised there is so too many variables to list, so I will stop for now, hope some of the above leads you down the right path in diagnosing the problem.

best regards,

Gunes