Unix fix pack uninstall question (newbie)

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

william.david.anderson@gmail.com - 01 Apr 2008 22:23 GMT

Hi there,

I'm trying to develop some procedures to enable me to back out of a
fix pack if I
encounter a problem after several days of running with a DB2 fix
pack on my
Solaris system.

Some operating systems have ways to "uninstall" a patch to revert
the state of the
system back to what it was prior to the patch install. Is there a
way to do that
with DB2?

Since it appears that the installation process may update some
system database
tables, it doesn't seem like I can simply roll back the DB2
software itself since
it seems like system DB tables might need to be rolled back as
well. Maybe I'm
misunderstanding the process though.

Thanks for any help,

Bill Anderson

Reply to this Message

Mark A - 01 Apr 2008 23:08 GMT

> Hi there,
>
[quoted text clipped - 21 lines]
>
> Bill Anderson

If you are using DB2 Enterprise with alternate fixpacks, you can revert to
the prior fixpack (see the fixpack readme file).

Reply to this Message

Ian - 02 Apr 2008 01:16 GMT

> Hi there,
>
> I'm trying to develop some procedures to enable me to back out of a
> fix pack if I encounter a problem after several days of running with
> a DB2 fix pack on my Solaris system.

This depends on what Operating System and DB2 version you're running.
In V8 and before, DB2 used the native package management tools for each
OS. So, AIX used LPP, Solaris used pkgadd, Linux used RPM, etc.
Your ability to roll back a fixpack depended on whether your OS provided
the means to "reject a fix". AFAIK, only AIX offered this.

In V9, DB2 does not use the native package management tools. With this
you gain the ability to install multiple versions of the product into
different directories. So, you could have V9 FP1 in /opt/IBM/db2/v9fp1,
V9 FP2 in /opt/IBM/db2/v9fp2, etc. You tell a particular instance which
code to use when you run the db2iupdt command. (i.e., run:
"/opt/IBM/db2/v9fp2/instance/db2iupdt inst1" to use v9fp2 code, or run:
"/opt/IBM/db2/v9fp1/instance/db2iupdt inst1" to go back to v9fp1 code.

(Of course, you need to shut down DB2 to run the db2iupdt command...)

>Since it appears that the installation process may update some
> system database tables, it doesn't seem like I can simply roll back
> the DB2 software itself since it seems like system DB tables might
> need to be rolled back as well. Maybe I'm misunderstanding the
> process though.

Taking an offline backup prior to the upgrade is generally a good idea,
in case you need to revert.

Reply to this Message

Mark A - 02 Apr 2008 03:59 GMT

> This depends on what Operating System and DB2 version you're running.
> In V8 and before, DB2 used the native package management tools for each
> OS. So, AIX used LPP, Solaris used pkgadd, Linux used RPM, etc.
> Your ability to roll back a fixpack depended on whether your OS provided
> the means to "reject a fix". AFAIK, only AIX offered this.

If you use alternate fixpacks, you can do this same thing in V8 on all OS
except for Windows (assuming you have Enterprise Edition). Not coincidently,
alternate fixpacks in V8 allows one have multiple versions on the same
machine (except Windows), and you run the db2iupdt command to bring the
instance up to whatever fixpack you have installed on that machine. You can
upgrade an instance, and you can depreciate an instance to any alternate
fixpack where the code is laid down on that server.

> In V9, DB2 does not use the native package management tools. With this
> you gain the ability to install multiple versions of the product into
[quoted text clipped - 3 lines]
> "/opt/IBM/db2/v9fp2/instance/db2iupdt inst1" to use v9fp2 code, or run:
> "/opt/IBM/db2/v9fp1/instance/db2iupdt inst1" to go back to v9fp1 code.

It appears that with V9 (which allows multiple versions of DB2 on the same
machine) you can do the same thing as is accomplished with alternate
fixpacks in V8 (but I am not an expert in this V9 feature).

Reply to this Message

Mark A - 02 Apr 2008 04:03 GMT

> If you use alternate fixpacks, you can do this same thing in V8 on all OS
> except for Windows (assuming you have Enterprise Edition). Not
[quoted text clipped - 3 lines]
> machine. You can upgrade an instance, and you can depreciate an instance
> to any alternate fixpack where the code is laid down on that server.

BTW, if you need to depreciate an instance to lower fixpack (if installed as
an alternate fixpack), you use the -D option with db2iupdt (see Command
Reference manual):

-D Moves an instance from a higher code level on one path to a lower code
level installed on another path.

Reply to this Message

william.david.anderson@gmail.com - 02 Apr 2008 14:39 GMT

Thanks for the responses to my post. That helps a lot.

Bill

Reply to this Message

Darin McBride - 02 Apr 2008 14:46 GMT

> Hi there,
>
[quoted text clipped - 3 lines]
> pack on my
> Solaris system.

What version of DB2?

If it's v8 or earlier, there are backout patch scripts in /var/sadm/patch,
IIRC.

If it's v9 or later, you simply install the old fix level over top of the
new one. Or, better yet, install the new fix pack to a new location (using
db2iupdt to switch the copy associated with the instance), and leave the
old copy around until you're satisfied with the new copy.

Reply to this Message