So - we are using MM5.2 and recently started getting errors pulling the data. The tracing file had to be rebuilt - too large I think. From what I understand, it takes a while before data is available again and also have heard a 3rd party option to capturing data would be better. Anyone out there have thoughts on that? If you are using the reports, any issues?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Usage Reports
- Thread starter demanding
- Start date
if it is setup correctly there wouldn't be any issues. If your operation history or your transaction databases had to be rebuilt because they reached the 2GB limit then either your Tracing configuration is not setup properly or your scheduled tasks are not running correctly to clean up those databases. (going from memory) OpHist is the DB where you can keep your operational history data but you can only see the past 3 days worth using the operational history viewer tool from MM (even if you chose to keep more than 3 days worth of operation history). Trxdb is where the transactions are stored. Transactions are generated (by default) everyday and are what the reports you run are based on. So you can run reports on today's data, just the data upto the time when the last transactions were generated. The default keep period for transactions is 30 days but if you want to run reports for periods of time longer than that you will need to modify that in the Tracing portion of the VMSC.
kepetersen
Technical User
Along with this... if you have more than one MAS the database for Tracing is installed on only one MAS in an MM domain. You can point the database to other MAS and this procedure is in the Messaging Application Administration guide.
- Thread starter
- #4
If the tracing service is simply stopped/started you should not have lost any operation history as each MAS has a buffer (default 4 MB but I usually set that to 99 MB) to keep before purging operation history. So depending on how busy each MAS is, will factor into whether or not the MAS would fill up the buffer before the tracing service could reconnect to the MAS to capture the data.
If the operation history DB was rebuilt, that would only affect the data from the point in which it reached the 2GB limit and when the DB was rebuilt. That portion of your data would be lost and would not show up in transactions that were generated from it.
Keep in mind that all your reporting is based on the data in the transaction DB, not the tracing/operation history DB. The transactions should be generated daily from the data contained in the operation history DB.
If the operation history DB was rebuilt, that would only affect the data from the point in which it reached the 2GB limit and when the DB was rebuilt. That portion of your data would be lost and would not show up in transactions that were generated from it.
Keep in mind that all your reporting is based on the data in the transaction DB, not the tracing/operation history DB. The transactions should be generated daily from the data contained in the operation history DB.
kepetersen
Technical User
Also, if you are looking for data on the reports for the last hour, you won't find it in the usage reports on the MAS. The pull of data is done nightly from the settings in the VMSC, Tracing times. These are usually set for staggered times (1, 2, & 3am). By design, these staggered times should never run at one time or it can also create issues with the Tracing system.
- Thread starter
- #7
- Status