Chore best practices

[ravi]

Hi All,

We have chores about 400+ these chores run on daily basis against tm1 model ( 9 Prod tm1 instances).
These chores includes actually data load, hourly chores, dim update etc.......these chore run with time intervals - say daily dim update chore may run 4 times in day.

This practice is besically is to keep tm1 models updated and live for the users and reporting purpose.

I have noticed some time- thier may not may new dim available in source(DB) -hence dim update chore is not necessary to run 4 time in a day.
As this add-up work in monitoring chore and unnecessary chasing of chore of thier success and failure.

Are there any best practices you think- to avoid running chore-when particular chore no impact on reporting.

Regards,
Ravi

[qml]

400+ chores sounds like an awful lot, but maybe (just maybe) that's how it needs to be.

The main thing I would say to you that TI processes / chores should ideally never fail in an unhandled way. All the things that can reasonably go wrong you should test for and capture in the code and deal with them appropriately. In your example where you have a dim update running 4 times a day, but most of the time there will be nothing to update, I would make sure that your TI process first checks if there is anything to do, e.g. by checking if a source file exists or if a specific flag in a database is set to indicate change etc. Then, if your checks show no change required, you just execute ChoreQuit and that's that. That way you can still run your chore with the same frequency, but it will terminate immediately when it detects there's nothing to do. A similar principle should apply to data updates or any other type of process / chore.

As a side note, are your users not complaining about performance issues? I would expect a fair number of locking happening in an environment that is so frequently updated, unless it's really well designed.

[jim wood]

To back up QML's point about locking there are certain cases when a chore can lock a service for the whole duration of the chore. For example if you have a dim update at the start of the chore the chore will lock until completion even if the rest of the chore is set to load data. Have you looked at alternatives? On this forum you can download a batch file that will execute a process from the command line. Also TM1RunTI comes with 9.5.2? You can use this to either run individual processes or a process executing a group of processes,

Jim.

[lotsaram]

400 processes, well I can believe that. 400 chores, you must be kidding! Do you mean you have 400 individual chores? OR do you mean you have a lesser number of chores but you have an aggregated total of around 400 scheduled chore executions per day?

[rkaif]

First of all, like everyone I am shocked to see the 400+ which is way too many. I wish it was typo from you - if not then you must be facing some serious performance issues.

I have noticed some time- thier may not may new dim available in source(DB) -hence dim update chore is not necessary to run 4 time in a day.
As this add-up work in monitoring chore and unnecessary chasing of chore of thier success and failure.

Are there any best practices you think- to avoid running chore-when particular chore no impact on reporting.

1) Create a control cube measure.
2) Check the source DB and if there is any change in the metadata then set the value of this control measure as 'Y' otherwise 'N'.
3) Before updating your dimensions, you can check the value of Control measure. If the value is Y only then update the dimensions otherwise use the ChoreQuit() function to terminate the chore.