Drop a Jobserver

[raphael...@conrad.de]

Dear schedulix Group,

I have the following problem.

I am using schedulix 2.8 on Server and Jobserver.

I wanted to remove a jobserver from schedulix but get the following error message:

SDMS Command failed
COMMAND    
drop JOB SERVER GLOBAL.'SERVER'.'cdc-schedulix-jobserver-03' CASCADE

ERRORCODE     03202231053
ERRORMESSAGE    

Scope GLOBAL.SERVER.cdc-schedulix-jobserver-03 contains Jobs

Have already tried the SQL statements from https://groups.google.com/forum/?fromgroups#!searchin/schedulix/drop$20Jobserver|sort:date/schedulix/3R2WvAC5C1E/oRe86dOZtgkJ run.

During the execution I get this error message:
column "sme_id" does not exist

Best regards

Raphael Lorenz

[Ronald Jeninga]

Hi Raphael,

the reason you can't drop Jobservers immediately is simply Referential Integrity.

The Scope hierarchy isn't versioned (you can't execute jobs on systems that were there yesterday, only on currently present hardware; hence no need to keep the history)..

This means that if you drop a scope, it'll be gone forever.

But if the list of jobs reference a Jobserver (== a Scope), you want to know which one that was (because you want to see that Job in the first place).

Thus we can't drop a Jobserver if there are Jobs in memory that reference it.

We're not perfect at this point. As soon as the last referencing Job is older that the History parameter in the server.conf file indicates, the referenced Jobserver can be dropped.

And if you then restart your server with a larger History setting, there'll be dangling references.

We think this is acceptable, since the History parameter is rarely changed.

The post you reference is almost 5 years old. And in the meantime we've improved the system significantly.

One of those improvements is the automated cleanup of the database, which is configurable by the administrator.

This eliminates the need to use of SQL to cleanup the database manually.

And this is EXCELLENT, because using SQL without knowing exactly what you do is about the fastest way to break your system!

In fact, we don't use SQL if we aren't forced to do so.

Anyway, to configure your database cleanup have a look at the following server.conf parameters:

#

# DbHistory: Number of minutes to keep in BICsuite repository database

#            If the Archive option is disabled, data of older job executions will get lost !!!

#            Set to 0 if you do not want to remove data of older job executions from the BICsuite repository

#            Set to 1 to remove all data which isn't any longer in server memory

#            Set to 45000 to keep the data for approximately 1 month

#            Set to 540000 to keep data for approximately 1 year

#

DbHistory=45000

#

# History: In Core Job History in minutes. Finished masters are kept in memory

#          at least this long

#

History=2880

#

# HistoryLimit: since the number of jobs to load can be specified, the previously 

#               defined History can be exceeded.

#               The HistoryLimit defines a hard limit. Final jobs elder than this

#               limit won't be loaded, disregarding any counts

#

HistoryLimit=5760

#

#

# MinHistoryCount: Minimum number of masters loaded (if present), disregarding the

#                  History. 0 means no minimum

#

MinHistoryCount=1

#

# MaxHistoryCount: Maximum number of masters loaded, even if History is larger

#                  0 means ignore

#

MaxHistoryCount=3

Basically it is the DbHistory that triggers the cleanup.

But of course, if you've configured a DbHistory = 1 (remove as fast as possible) but use a History = 28800 (== keep Jobs 20 days in memory), the effective DbHistory will be 20 days because we are not allowed to remove data from the database that is still in memory.

The other parameters that are used to configure the behaviour of the server regarding the Jobs to keep in memory play a role as well.

Generally it'll be a good idea to set the DbHistory to a value that is significantly larger than the HistoryLimit.

I am aware that this was a pretty interesting story (at least I hope), but that it doesn't really solve your problem.

My suggestion is to create a scope e.g. GLOBAL.TRASHBIN and move all jobservers that you'd like to drop thereto.

Then you deregister the jobserver (burning computer button) and remove all resources from the jobserver (or set them to be Offline):

Once per week (or perhaps even once per month) you can now try to empty the trash bin and the superfluous Jobservers will be dropped little by little.

HTH

Best regards,

Ronald