Hi there,
I found the Cube }StatsByProcess in my TM1-Model (Planning Analytics 2.0, but I think, it's avalable since TM1 10.something)
but I cannot find any documentation regarding this cube.
Does anyone knows something about the different Values in the cube:
Current State
Completion Status
Client Name
Last Start Time - ok, should be clear
Last End Time - ok, should be clear
Last Duration - ok, should be clear, but why is this field only filled for }TimeIntervals <> "LATEST"?
Next Activation Time
Current Process
That would be great!
Regards
Mark
Cube }StatsByProcess - any documentation?
-
paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: Cube }StatsByProcess - any documentation?
Hi
The downside that most of us find with turning on the population of the }Stats cubes is that it does add quite a performance overhead to the system so I would do this on the Dev server but probably not Production and even then only to investigate a particular issue.
Unfortunately there is no way to turn on just the logging of processes, and some of the cubes such as }StatsByCubeByClient can get quite large very quickly.
You can start population of the }Stats cubes by right clicking on the server and selecting Start Performance Monitor, or by adding PerformanceMonitorOn=T to the TM1S.CFG but I would recommend the former since you generally don't want this on permanently.
The fact that your cubes are only sparsely populated might be because you are looking at a previous capture and performance monitoring has since been turned off, eg because the server has restarted.
When I started performance monitoring and ran a process then it did appear in the LATEST slot.
The Completion Status will tell you if there was an error. A successful run will show a 0, and anything else will show a non-zero.
I doubt you will ever see Current State unless you have a very long running process. As far as I can see Client Name does not get populated.
In practice we add some standard code into most of our processes to log results to a custom process information cube. This records things like the number of records processed, who ran the process, whether it completed, what the parameters were. As it can only record the last run, it is of limited value for frequently run processes. However, you can also use things like the TM1Server.log to see when a process was run and get the duration. We also log the last element that a user selected on a worksheet, in each dimension, to a cube so this tells us on a user by user basis the last selections that a user was likely to have used as parameters to a process. We could potentially extend our logging to log to a file or relational database, to get a full history, but there is the danger that the logging will add too much overhead.
Regards
Paul Simon
The downside that most of us find with turning on the population of the }Stats cubes is that it does add quite a performance overhead to the system so I would do this on the Dev server but probably not Production and even then only to investigate a particular issue.
Unfortunately there is no way to turn on just the logging of processes, and some of the cubes such as }StatsByCubeByClient can get quite large very quickly.
You can start population of the }Stats cubes by right clicking on the server and selecting Start Performance Monitor, or by adding PerformanceMonitorOn=T to the TM1S.CFG but I would recommend the former since you generally don't want this on permanently.
The fact that your cubes are only sparsely populated might be because you are looking at a previous capture and performance monitoring has since been turned off, eg because the server has restarted.
When I started performance monitoring and ran a process then it did appear in the LATEST slot.
The Completion Status will tell you if there was an error. A successful run will show a 0, and anything else will show a non-zero.
I doubt you will ever see Current State unless you have a very long running process. As far as I can see Client Name does not get populated.
In practice we add some standard code into most of our processes to log results to a custom process information cube. This records things like the number of records processed, who ran the process, whether it completed, what the parameters were. As it can only record the last run, it is of limited value for frequently run processes. However, you can also use things like the TM1Server.log to see when a process was run and get the duration. We also log the last element that a user selected on a worksheet, in each dimension, to a cube so this tells us on a user by user basis the last selections that a user was likely to have used as parameters to a process. We could potentially extend our logging to log to a file or relational database, to get a full history, but there is the danger that the logging will add too much overhead.
Regards
Paul Simon