cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2346
Views
0
Helpful
4
Replies

Empty jobstat database table

Mark Twyman
Level 1
Level 1

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.

3 Accepted Solutions

Accepted Solutions

Tracy Donmoyer
Level 1
Level 1

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.

View solution in original post

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

View solution in original post

bluehouseinc
Level 1
Level 1

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.

View solution in original post

4 Replies 4

Tracy Donmoyer
Level 1
Level 1

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.

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

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.

bluehouseinc
Level 1
Level 1

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: