Update Package Deploy to Multiple Servers

[gerd_renz3]

Hi All,

I am working at a client with multiple servers for each environment. For example, for PY we have 2 batch and another 2 logic (BSFN) servers. So I need to build update packages for all 4 servers each time. I frequently run into problems while deploying packages, mostly due to "unable to create server lock".

To go around this I was thinking to deploy packages with specs only (no BSFN) only to one of these servers. Since we have "shared specs", once I deploy specs to one server, all will see these changes.

Is this correct thinking or am I missing something here? Has anybody done this before as a regular practice ?

E9.1, 9.1.5 tools, all Linux servers, Weblogic, Oracle BIP 11.1.1.7

Thanks in advance, Gerd

 

[Soumen]

In theory that sounds like it would work but I believe you will run into issues after you deploy the packages. The servers where the package were not deployed will not be able to sync with the new the package deployed. You can make it work though with some manual steps for ex,

- Update the spec.ini file on each server with the new package name.
- Update the SKSERSHP column in table f96511 with the new package name.
- Restart the JDE services to pick the change.

But then again that does not solve your purpose I believe because you are recycling the JDE services anyway.

This is my thought let's see what others have to say.

 

[altquark]

Gerd - are you deploying these packages outside of regular hours ?

I make sure that I put all the Batch Queues on hold (about 15 minutes prior to a package deployment) and ensure that no batch jobs are processing - a running batch job will stop the package build kernel from achieving a lock.

Then disable access to the weblogic servers (this was done at the time the package deployment "time" occurred)

Then check running UBE's. Notify users if there was a UBE still running - this would determine whether the deployment would go ahead or not. Certain UBE's in a list could be killed if running (ie, if they were just long read-only reports that could be resubmitted).

Once no running UBE's were in the system - then I would stop and start services on all Enterprise Servers - that ensures that there are no interactive sessions "locking" a callobject kernel (inlcuding "phantom" sessions) - and I used the opportunity to remove logs at this point.

Then immediately deploy a package - the package deployment should go through quickly

Then re-enable logons via weblogic - I never ever had to bounce weblogic services btw.

Then start the jobqueues

This was the process I went through for my 15,000 user customer who was at the time running TR 9.1.4.7 - and we reliably pushed out packages to multiple Enterprise Servers (including multiple types) without ever receiving the "unable to create a server lock" message.

Obviously for Production pathcode purposes, you want to build packages for all servers in the enterprise - and you probably want to limit package deployments to something like once per week at the MOST !

 

[gerd_renz3]

Thanks for your suggestions, John.

We are about to go Live, so I expect the need for emergency quick deploys, even in daytime.
Sure, taking everything down, even stopping queues and scheduler is teh proper way to do it, if I only could limit update packages to once a week!

 

[gerd_renz3]

Hi Soumen,

looks like you are talking about full packages. I had actually asked about SPECS ONLY, small update packages.

But thanks for your answer.

 

[altquark]

Well - update packages with specs only should be built in the "traditional" way - ie, all servers selected - but it shouldn't try and perform a lock when you go to deploy. That would be your best, and fastest, solution.

As for packages with DLL's - well, I would suggest performing the steps I previously stated to guarantee safety. But hopefully you won't need to 'emergency deploy' a business function !