Unwanted job server connections

dataservices administration
1

Hi, Can someone tell me how to get rid of redundant (un-associated) job server connections from the job execution drop down list?

My understanding is that you associate one or more repositories with a job server. However it appears that repositories hold onto connection details with job servers which are subsequently disconnected.

This situation creates confusion, with job logs popping up on unassociated designer repository connections, and the risk of selecting incorrect job servers during execution.

Thanks
Simon

simonkirk (BOB member since 2006-10-10)

2

Before you decommission a jobserver you should run the server manager and remove it from there to get rid of all repo associations. I know, sometimes this is not possible, e.g. the entire server just died and got replaced. Then you have to manually edit the AL_MACHINE_INFO table and delete the jobserver entries there.

Werner Daehn :de: (BOB member since 2004-12-17)

3

Thanks Werner.

I’m evaluating Data Services 3.1 prior to us upgrading. I “cloned” an 11.5 repository to another schema, and upgraded this using Repository Manager. It is this repository from which I want to remove connections to 11.5 job servers. However, when I look at the AL_MACHINE_INFO table for this upgraded repository, it is empty, as are most of the other tables!

This is very odd, as I can connect to the repository using Designer 12.1 and see the content.

Is there something I’m missing?

Thanks
Simon

simonkirk (BOB member since 2006-10-10)

4

Looking at the wrong tables? Different owners??

Werner Daehn :de: (BOB member since 2004-12-17)

5

Nope. I’ve just repeated the upgrade of another local repository from 11.5.1.5 to 12.1, and the AL_MACHINE_INFO table is now empty also, except for the SEQNUM column.

I think I’m going mad :slight_smile:

S

simonkirk (BOB member since 2006-10-10)

6

you mean all the other columns have value set to NULL and only SEQNUM is populated with values ?

was your repository upgrade successful ?

what is the database type of your repository ? you changed your DI repo schema to a different DB type of same db type ?

How did you clone the DI 11.5 repo to different schema ? was everything ok after moving repo from one schema to other

did you resync each repo from the server manager for each job server? you have to resync to get rid of unwanted job server entries from AL_MACHINE_INFO table

manoj_d (BOB member since 2009-01-02)

7

<<you mean all the other columns have value set to NULL and only SEQNUM is populated with values ?>>

Yes. All columns are NULL except SEQNUM. 6 rows with vales 1,2,3,4,5,6. I notice this is a new column which does not exist in 11.5 repositories.

<<was your repository upgrade successful ? >>

Yes. And it does not matter if I upgrade a repository with the DS3.1 unix (Solaris) repoman utility, or the windows version, the outcome feedback is “successful”

<<what is the database type of your repository ? you changed your DI repo schema to a different DB type of same db type ? >>

Repository database is Oracle 11g. Oracle client on both Solaris and Windows is 10.2.0.1.0. All database types specified as Oracle during upgrade)

<<How did you clone the DI 11.5 repo to different schema ? was everything ok after moving repo from one schema to other.>>

DBA copied 11.5 repository database with all associated repository schemas to a new database for upgrade testing. I personally examined the AL_MACHINE_INFO of one repository before upgrading to 3.1. The jobserver connections existed before, but not after.

<<did you resync each repo from the server manager for each job server? you have to resync to get rid of unwanted job server entries from AL_MACHINE_INFO table>>

No, because after the repository database was copied, no existing job servers had connections to the copy, so there was nothing to resync.

I will try removing the entries from AL_MACHINE_INFO from a 11.5 repository schema before upgrading it to 3.1, and then associate it with a 3.1 job server.

Thanks
Simon

simonkirk (BOB member since 2006-10-10)