Database maintenance
What are the methods and recommendations re maintenance of the database?
Mario
What are the methods and recommendations re maintenance of the database?
Mario
Since nobody answered I guess the question is too general.
What I'm looking for is
What are the methods provided to get rid of old tracking data in a production enviornment?
I think this is a very valid question, and one I'm wondering a bit about as well.
I think that most people will need to create a sensible policy taking into account how much time you want to leave data there, and possibly create an archive database as well. (I wonder if the sql persistence service database would need this, as well, or whether it is self-cleaning).
What worries me more is not that no sample policies have been brought forward by MS (I think that a decent policy would be easy to create on our own); but rather the fact that as far as I can see, no documentation on the tracking database schema has been provided (yet), and more importantly, the logic included in the database doesn't include such basic tools as clean up procedures for cleaning up stale data on top of which you could schedule clean up jobs.
At least I believe that the latter would be an important addition and would like to know if there are any plans for this.
Hi Tomas and MarioBR -
WF provides out of box (OOB) data maintenance functionality for the SqlTrackingService by partitioning the tracking data upon completion of workflow instances. When partitioning is enabled, a new set of tables is created periodically for tracking data and the tracked data of completed workflow instances will move to the new partitions without disrupting currently running applications. Check the post here for more information on how to enable the OOB support for SqlTrackingService partitioning and for some code snippets. Of course, you can still implement your own routines and policy to archive and purge your tracking database if you wish.
Thanks, --Moustafa
Thanks for answering; the partitioning stuff seems interesting. A few questions, though:
Tomas -
The partition is done on the completion of the workflow instance. That is your records will be in your regular tables until the instance completes and this is when the records are going to move to the added tables. This is designed for applications that have no downtime do not want to incur downtime. We do have an offline scheme as well, so if you have a downtime and want to do partitioning during that time or you want to avoid moving records around when the instances complete or for any other reason you can schedule a task that runs PartitionCompletedWorkflowInstances stored proc which will move all currently completed instances from the live tables to the partitions. Host applications don’t need special privileges to create those tables, the user should be part of the tracking_ roles that are defined in the SqlTrackingService database.
SqlTrackingQuery will look at the partitioned tables as well. You can look at the PartitionCompletedWorkflowInstances stored proc as a starting point if you want to have your own Archiving and Purging story other than the one we provide out of box. We are working on documenting the SqlTrackingService schema in WF’s help.
Thanks, --Moustafa
Thanks for the comprehensive answer, it is much appreciated. It is excellent that we can run the PartitionCompletedWorkflowInstances procedure on our own, that is definitely gonna help, as I'm sure some of our customers will definitely prefer it that way. It's also great that the SqlTrackingQuery stuff will look at the partition tables, that's what I was hoping for :)