Empty jobstat database table

Answered Question
Apr 25th, 2012

Hello Tidal community,

My company currently uses TES 5.3.1.297 in conjunction with MS SQL Server 2000 and according to the scheduler 5.3.1 data model, the jobstat table should contain information depicting job status changes for historical reporting, which I think is the log data in the Operations/Logs. Please correct if my understanding is incorrect. In addition, my company is posturing to upgrade to MS SQL 2008 and TES 6.02, so I my main concern is not having the log data on the database when we migrate. Please help with the following questions:

  • Is the log data in the Operations/Logs the data the jobstat table should reflect?
  • If the log data in the Operations/Logs is supposed to reside in the jobstat table, what needs to happen to get the data there?
  • If not, where does the log data in the Operations/Logs reside? (I checked and queried my database as best I can for now and I do not see the corresponding data)

Thanks in advance for any and all assistance.

I have this problem too.
0 votes
Correct Answer by bluehouseinc about 3 years 2 hours ago

Mark, Sorry for my late reply; Tracy and Marc are correct and I can tell you that in 6.0.x nothing changes for you. However, I would consider 6.0.3 over 6.0.2. 6.0.3 allows the client cache to exists in MSSQL or Oracle vs. the internal Db that comes prepackaged. It will improve performance and give you insite as to what the client manager is doing.

Correct Answer by Marc Clasby about 3 years 7 hours ago

I agree that it appears the data you ar elooking for (states of a job) resides in the msglog table... our jobstat table is empty as well.

I believe the amount of data variers and is controlled by your Activities.. Configure Scheduler... Logging Tab settings

(we keep 7 days of audit and 30 days of errors) ~ 140 MB for the msglog table in the database... Your audit needs may vary. we only care about operator actions and alert closure for our own internal purposes.

I wouldn't worry too much about losing history if you back your TES databases up prior to upgrade.

(you'd be rolling back if you can't see the logs form the client side.)

We haven't gone through an upgrade yet but may by year end or Q1 next year.

We are running Master 5.3.1.318

(we wiill be going to .366 in a month or so as requires a matched client deploy as well)

Marc

Correct Answer by Tracy Donmoyer about 3 years 9 hours ago

Your description of the jobstat table matches the Schedule Data Model documentation.  Our table is empty as well, so I'm not sure what this table is used for or how to turn on logging.

The entries from the Operations/Log are found in the msglog table.  Caution: this table can be large.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (3 ratings)
Correct Answer
Tracy Donmoyer Wed, 04/25/2012 - 09:13

Your description of the jobstat table matches the Schedule Data Model documentation.  Our table is empty as well, so I'm not sure what this table is used for or how to turn on logging.

The entries from the Operations/Log are found in the msglog table.  Caution: this table can be large.

Correct Answer
Marc Clasby Wed, 04/25/2012 - 11:03

I agree that it appears the data you ar elooking for (states of a job) resides in the msglog table... our jobstat table is empty as well.

I believe the amount of data variers and is controlled by your Activities.. Configure Scheduler... Logging Tab settings

(we keep 7 days of audit and 30 days of errors) ~ 140 MB for the msglog table in the database... Your audit needs may vary. we only care about operator actions and alert closure for our own internal purposes.

I wouldn't worry too much about losing history if you back your TES databases up prior to upgrade.

(you'd be rolling back if you can't see the logs form the client side.)

We haven't gone through an upgrade yet but may by year end or Q1 next year.

We are running Master 5.3.1.318

(we wiill be going to .366 in a month or so as requires a matched client deploy as well)

Marc

Mark Twyman Wed, 04/25/2012 - 12:18

Thanks a million Tracy and Marc. I followed the bread crumbs and realized, the msglog_text column in the msglog tables is exactly what I needed to see.

Correct Answer
bluehouseinc Wed, 04/25/2012 - 16:27

Mark, Sorry for my late reply; Tracy and Marc are correct and I can tell you that in 6.0.x nothing changes for you. However, I would consider 6.0.3 over 6.0.2. 6.0.3 allows the client cache to exists in MSSQL or Oracle vs. the internal Db that comes prepackaged. It will improve performance and give you insite as to what the client manager is doing.

Actions

Login or Register to take actions

This Discussion

Posted April 25, 2012 at 8:35 AM
Stats:
Replies:4 Overall Rating:
Views:463 Votes:0
Shares:0

Related Content