swlist ???

[MikeL_4]

We have two servers, one production and one development that suppose to have the same patch levels on them, except of course for development should we be testing new patches.

However, the production server contains patches never applied to the development, and now the development server has code that has superseeded these patches...

The problem is my boss wants me to remove the current patches on the development server, install the older patches, and then re-install the newer ones so that both server show the same code as being on them...

Needless to say this does make me nervous to do this. Is there any way to reflect on the development server that these patches were installed ?? i.e.: fake it out ?????

Thanks

[James R. Ferguson]

Hi:

Tell your boss this is needless work; may not be possible; and has the potential to cause problems!

If any of the development server's patches have been commited it will be impossible to remove them. For that matter, removing a patch may impact dependent patches. This is not to be taken lightly.

Patches on development servers should be later than on production ones.

Regards!

...JRF...

[Sridhar Bhaskarla]

fake it out?. No. You can try (die) hard to manipulate IPD to get swlist working. But swverify and swconfig sessions will fail later making the things messed up.

If the situation is out of control, take the image of your production using make_tape_recovery and reinstall your development server with it. Restore the configuration. Do it with the latest ignite software. It supports installation across different hardware. Save an additional copy of make_tape_recovery image for both production and development in case things don't work out well.

-Sri

[James R. Ferguson]

Hi (again) Michael:

If you are running 11.x, then generate a software listing with the patch_state attribute. This will show you superseded and committed patch (states):

# swlist -l patch -a patch_state

Now show this to your boss!

Regards!

...JRF...

[Steven E. Protter]

Want the systems to work right? Don't do it.

Unless the system is an exact hardware match, you might have trouble having exact patch match.

You are better off, getting the development machien current, running your tests and then putting the same patches in prod.

If you are a glutton for punishment, you could do a make_tape_recovery on development and boot prod and restore off that tape.

Leave a few days to deal with what Ignite doesn't handle.

Tell your boss that the experts at HP say, do nothing, and you will do a better job making sure patches get into development and then x number of weeks later they get installed into prod.

SEP

[Jairo Campana]

I did this and had problems , removing a patch the problem impact dependent patches.

solve the problem with:
make_tape_recovery -A
too backup before to do this mentioned previously mentioned

[A. Clay Stephenson]

If not commited then you can use swremove to roll back most patches but you have to pay special; attention to those which require "Special Installation Instructions".

A far better answer is to go to a 3-tier approach (and if done wisely will actually save money - and time).

You should get yourself a "Sandbox". An old D or K box (or an old C if these are workstations) will work just fine and are very inexpensive on the used-equipment market.

The Sandbox is where you apply the latest OS patches, OS Releases, new Oracle releases and/or patches, ... and test against your application. Only after sucessfully passing the Sandbox do the OS patches go to the Development Box. It's main purpose is just that - development. Often, loss of development time is nearly as costly as temporary loss of production - especially in cases where development costs are measured in K$/hr.

The development box is then maintained either at or very near the patch level of the production box at all times and everybody feels safer.

This is the method that I use and I'll put my unplanned production downtime against anybody's.

[Shannon Petry]

I never recommend faking, cheating, nor lieing to get a job done.

First, unless hardware is an exact match, then some patches will never match up. This is everything from the cpu to graphics card to network card to I/O cards. 1 Rev difference in same model cards may result different patches.

Now, if you installed QPK03.06 on the production machine, and only QPK03.03 on the test server, you have only 1 safe choice. Install QPK03.06 on test server too.

It's a safe bet that you can not safely back out patches most of the time. It is not possible if all the patches were committed.

If your boss needs a correlation, lets use food as an easy comparison. Tell your boss it's like making 2 nice 12oz steaks. You salt and pepper 1, and not the other. Do you wipe the good steak on the floor to remove the salt and pepper just to re-apply it to both? or do you just add salt and pepper to the other one to make them match?

Best bet is to keep the new parts.

In reality, most of the time removing patches leaves systems unstable and in many cases un-usable. Since I doubt your boss would eat steak that was smeared on the floor, he should not want a system treated that way either.


Regards,
Shannon