Tag Archives: upgrade

Upgrade Oracle APEX from 4.2.4 to 4.2.5

Introduction

Oracle recently released version 4.2.5 of its Application Express (APEX) software.  This post is to document how to upgrade Oracle APEX from 4.2.4 to 4.2.5.

The Oracle APEX installation to be upgraded has the following specification:

  1. The operating system of the server is CentOS 6.5.
  2. The Oracle Database version is Oracle XE 11gR2.
  3. Oracle APEX is served using the APEX Listener, via GlassFish 4.

Download and read the Patch Set Notes

First things first, read up on the patch set notes here.

Download and unzip the Patch Set

Next, the patch set is downloaded via Oracle Support.

The downloaded patch set is then extracted.

[oracle@server ~]$ unzip p17966818_425_Generic.zip

Backup database

The database is backed up as a precaution if the patch is unsuccessful.

I prefer a cold and consistent backup to ease the recovery process.

[oracle@server ~]$ rman target / nocatalog

Recovery Manager: Release 11.2.0.2.0 - Production on Fri Apr 25 09:38:09 2014

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: XE (DBID=2709648321)
using target database control file instead of recovery catalog

RMAN> shutdown immediate

database closed
database dismounted
Oracle instance shut down

RMAN> startup mount

connected to target database (not started)
Oracle instance started
database mounted

RMAN> backup database plus archivelog;

RMAN> alter database open;

database opened
RMAN> exit

Recovery Manager complete.

Prevent access to the APEX instance

No users should be using the APEX installation while it is being upgraded.  Access to the instance should be limited.  In this particular case, since APEX is served by the APEX Listener which is hosted by a GlassFish instance, user access is prevented by shutting down the GlassFish instance.

[oracle@server ~]$ sudo service glassfish4 stop
Shutting down glassfish4: Waiting for the domain to stop ...
Command stop-domain executed successfully.
                                                           [  OK  ]

The above command is used to control the GlassFish installation only if the corresponding service init script has already been correctly created.  An example on how this is done can be found here.

Apply the patch set

Now, set the current directory to the patch directory, and apply the patch.

[oracle@server ~]$ cd patch
[oracle@server patch]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Fri Apr 25 09:38:45 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

SQL> @apxpatch.sql

The patch will now be applied, and the process will take a few minutes.

Copy patch directory contents into APEX directory

After the patch process is completed, it is time to copy the contents of the patch directory into the original APEX installation directory.

[oracle@server patch]$ cp -R * /path/to/apex/

This will include the images directory as well, and if the path to the APEX directory is the same one used to originally create the images WAR file, the WAR file need not be recreated.

Restart GlassFish

The final step is to restart the GlassFish instance.

[oracle@server ~]$ sudo service glassfish4 start
Starting glassfish4: Waiting for domain1 to start .....................................................
Successfully started the domain : domain1
domain  Location: /home/gfish/glassfish4/glassfish/domains/domain1
Log File: /home/gfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
                                                           [  OK  ]

Now the APEX installation is successfully updated to version 4.2.5, and is ready to be accessed.

Upgrade Oracle APEX from 4.2.3 to 4.2.4

Introduction

Oracle recently released version 4.2.4 of its Application Express (APEX) software.  This post is to document how to upgrade Oracle APEX from 4.2.3 to 4.2.4.

The Oracle APEX installation to be upgraded has the following specification:

  1. The operating system of the server is CentOS 6.5.
  2. The Oracle Database version is Oracle XE 11gR2.
  3. Oracle APEX is served using the APEX Listener, via GlassFish 4.

Download and read the Patch Set Notes

First things first, read up on the patch set notes here.

Download and unzip the Patch Set

Next, the patch set is downloaded via Oracle Support.

The downloaded patch set is then extracted.

[oracle@server ~]$ unzip p17607802_424_Generic.zip

Backup database

The database is backed up as a precaution if the patch is unsuccessful.

I prefer a cold and consistent backup to ease the recovery process.

[oracle@server ~]$ rman target / nocatalog

Recovery Manager: Release 11.2.0.2.0 - Production on Tue Jan 7 12:33:41 2014

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: XE (DBID=2709648321)
using target database control file instead of recovery catalog

RMAN> shutdown immediate

database closed
database dismounted
Oracle instance shut down

RMAN> startup mount

connected to target database (not started)
Oracle instance started
database mounted

RMAN> backup database plus archivelog;

RMAN> alter database open;

database opened
RMAN> exit

Recovery Manager complete.

Prevent access to the APEX instance

No users should be using the APEX installation while it is being upgraded.  Access to the instance should be limited.  In this particular case, since APEX is served by the APEX Listener which is hosted by a GlassFish instance, user access is prevented by shutting down the GlassFish instance.

[oracle@server ~]$ sudo service glassfish4 stop
Shutting down glassfish4: Waiting for the domain to stop ...
Command stop-domain executed successfully.
                                                           [  OK  ]

The above command is used to control the GlassFish installation only if the corresponding service init script has already been correctly created.  An example on how this is done can be found here.

Apply the patch set

Now, set the current directory to the patch directory, and apply the patch.

[oracle@server ~]$ cd patch
[oracle@server patch]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Tue Jan 7 16:07:39 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

SQL> @apxpatch.sql

The patch will now be applied, and the process will take a few minutes.

Copy patch directory contents into APEX directory

After the patch process is completed, it is time to copy the contents of the patch directory into the original APEX installation directory.

[oracle@server patch]$ cp -R * /path/to/apex/

This will include the images directory as well, and if the path to the APEX directory is the same one used to originally create the images WAR file, the WAR file need not be recreated.

Restart GlassFish

The final step is to restart the GlassFish instance.

[oracle@server ~]$ sudo service glassfish4 start
Starting glassfish4: Waiting for domain1 to start .....................................................
Successfully started the domain : domain1
domain  Location: /home/gfish/glassfish4/glassfish/domains/domain1
Log File: /home/gfish/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
                                                           [  OK  ]

Now the APEX installation is successfully updated to version 4.2.4, and is ready to be accessed.

Upgrading Zenoss 4.2.3 to 4.2.4 on CentOS 6.4

The guides I am using for this procedure includes:

The resources above have somewhat conflicting information about upgrading to 4.2.4.  The installation guide lists a long set of instructions to perform but the blog, including the comments, suggest a much simpler course of action.

Some of the steps listed in the installation guide is not even required in my opinion.  For instance, the installation guide included the upgrade of MySQL server as part of the Zenoss upgrade.  However, as I found out after testing a fresh install of Zenoss 4.2.4, the MySQL version installed by the 4.2.4 auto-deploy script is the same as the one used by the 4.2.3 auto-deploy script.  Therefore, I would assume that not all the of the listed actions from the installation guide are totally necessary.

Let’s try the simplest upgrade as suggested by the blog.

Grab the 4.2.4 installer rpm.

# wget http://downloads.sourceforge.net/project/zenoss/zenoss-4.2/zenoss-4.2.4/zenoss_core-4.2.4.el6.x86_64.rpm

Stop Zenoss daemons.

# service zenoss stop
Daemon: zenwinperf stopping...
Daemon: zeneventlog stopping...
Daemon: zenwin stopping...
Daemon: zenjmx stopping...
Daemon: zenrrdcached stopping...
Daemon: zenprocess stopping...
Daemon: zencommand stopping...
Daemon: zenperfsnmp stopping...
Daemon: zenmodeler stopping...
Daemon: zentrap stopping...
Daemon: zenactiond stopping...
Daemon: zenstatus stopping...
Daemon: zensyslog stopping...
Daemon: zenping stopping...
Daemon: zeneventd stopping...
Daemon: zenjobs stopping...
Daemon: zenhub stopping...
Daemon: zopectl .
daemon process stopped
Daemon: zeneventserver stopping...

Install redis.

# yum --enablerepo=epel install redis

Install the installer rpm.

 # rpm -Uvh zenoss_core-4.2.4.el6.x86_64.rpm
Preparing...                ########################################### [100%]
Upgrading from zenoss 4.2.3 to zenoss 4.2.4
Stopping any down-level Zenoss daemons...
Stopped.
   1:zenoss                 ########################################### [100%]

At this point, as I understand it, there will be some problems with passwords not matching in configuration files, because the auto-deploy scripts (for both 4.2.3 and 4.2.4) would perform password synchronization, which is not done by the RPM.  Let’s check them.

# cat /opt/zenoss/etc/hubpasswd
admin:zenoss

# cat /opt/zenoss/etc/global.conf | grep password
zodb-password <some other password>
zodb-admin-password xxxxxxxxx
amqppassword <some other password>
zep-password <some other password>
zep-admin-password xxxxxxxxx
hubpassword <some other password>

The password in the hubpasswd file should match the <some other password> in global.conf.  So let’s change it.

# vi /opt/zenoss/etc/hubpasswd
# cat /opt/zenoss/etc/hubpasswd
admin:<some other password>

Finally, start the zenoss service.

# service zenoss start
Zenoss upgraded.  Running data migration scripts...
Upgrade pre step
Checking RRDtool version >= 1.4.7: [ OK ] 1.4.7
Creating database: zenoss_zep
Applying schema version: 6
Dropping database: zodb_session
Creating database: zodb_session
Applying schema version: 1
Applying schema version: 2
Upgrading to use persistent sessions...
Already using persistent sessions or using custom session storage. zope.conf will not be altered.
Starting zeneventserver...
Migrating data...

...
...

Upgrade install post step
Zenoss upgrade complete.

And the upgrade is done!

The ‘localhost’ device started to give out warnings in Zenoss that the zen processes are not running, but after a remodel of the device, the warnings stopped.