Re: Oracle Apex Question

  • From: Stefan Knecht <knecht.stefan@xxxxxxxxx>
  • To: srcdco@xxxxxxx
  • Date: Wed, 6 Jun 2018 07:03:12 +0700

Another approach is of course to just stand up a new box temporarily,
export / import the APEX workspace and Apps on over, and ask a user to
test, and see what breaks. If you're doing this ahead of time, that can be
a feasible approach to learn more about the environment prior to actually
migrating on over.




On Wed, Jun 6, 2018 at 6:49 AM, Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:

There are a few things here that need to be looked at if you want to cover
all the possibilities and ensure a smooth migration.

1) How is APEX used by the clients

Currently there's EPG (not likely in production), Oracle HTTP Server (OHS)
with mod_plsql, Oracle REST data services (ORDS - formerly known as APEX
Listener), or even if someone has been very adventurous, mod_owa over
Apache.

To help determine what can be and can't be in use, a good starting point
is to look at the database users you have in that database.

APEX_PUBLIC_USER, if it's unlocked (and particularly if you see
connections) indicates OHS is used.
ORDS_PUBLIC_USER, if it's unlocked indicates ORDS is used.
ANONYMOUS if it's unlocked indicates EPG is used.

It's also worth noting that these aren't mutually exclusive - you can run
them all at the same time. You can run a standard APEX app via OHS and at
the same time offer REST services via ORDS.

A good way to find out is to just connect to the APEX web interface with a
browser and see what pops up on the database end (e.g. which users become
active). Another indicator is the URL that's used to connect to APEX:

http://hostname/ords/apex indicates ORDS is used ;(but again, the file can
be renamed and this would change the URL - the path used in the URL would
have to correspond to the name of the war file you'd see running).
http://hostname/* ;(on port 80) is more likely to be a real web server
(OHS or Apache)
http://hostname:8080/apex is most likely EPG.

You can also look for the processes - for OHS or Apache, you'd see httpd
processes, and for ORDS you'd see a .war file being run by java; usually
it's called ords.war but it can be renamed. Also keep in mind that they can
be offloaded - e.g. you can run OHS or ORDS on a different machine than the
database, they don't need to be local.

For EPG, what MUST be the case if it's being used is that the XDB HTTP
port is open. You can see that by either querying:

SQL> select dbms_xdb.gethttpport from dual;

GETHTTPPORT
-----------
          0

.. here, zero means it's closed; or by checking your listener with lsnrctl
status where you'd see an XDB endpoint (usually on port 8080).


2) Depending on 1) what else you need to move

Generally, exporting the workspace and application will work (see here for
example https://ruepprich.wordpress.com/2011/07/15/
exporting-an-apex-application-via-command-line/ )

If you're using EPG, it's likely that all the components the APEX app
needs are inside the database (and stored in XDB).

However, if you're using OHS or ORDS, there may also be files referenced
outside the database.

If you have access to the APEX environment,  you can also take a look at
SQL Workshop -> RESTful Services to see if any are configured.



Let us know what you find and if you need  more information

Stefan



On Wed, Jun 6, 2018 at 1:25 AM, Scott Canaan <srcdco@xxxxxxx> wrote:

I will be running the install for Apex 5.4, which is the version I
ultimately need to end up with.  I am trying to figure out how to get the
Apex 4.1 data migrated over so it isn’t lost when the upgrade to Apex 5.4
is done.



*Scott Canaan ‘88*

*Sr Database Administrator *Information & Technology Services
Finance & Administration


*Rochester Institute of Technology *o: (585) 475-7886 | f: (585) 475-7520

srcdco@xxxxxxx | c: (585) 339-8659

*CONFIDENTIALITY NOTE*: The information transmitted, including
attachments, is intended only for the person(s) or entity to which it is
addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon this information by persons or entities other than
the intended recipient is prohibited. If you received this in error, please
contact the sender and destroy any copies of this information.



*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@freeli
sts.org] *On Behalf Of *Jeffrey Beckstrom
*Sent:* Tuesday, June 05, 2018 2:02 PM
*To:* oracle-l-freelist; rjoralist3@xxxxxxxxxxxxxxxxxxxxx
*Subject:* Re: Oracle Apex Question



I would think you would have to run the install since at least in 11G,
APEX appears in dba_registry.

Rich J <rjoralist3@xxxxxxxxxxxxxxxxxxxxx> 6/5/18 1:54 PM >>>

On 2018/06/05 07:19, Scott Canaan wrote:

I have an application that uses Oracle Apex.  We are just starting an
application, Oracle, and O/S upgrade.  I have to copy the Apex “install”
from Oracle 11.2.0.3 on Red Hat 6 to Oracle 12.1.0.2 on Red Hat 7.
Normally, I do a data pump import across the network to migrate the Oracle
schemas, but I’ve been told that doesn’t work for Apex.  I need to preserve
the Apex version at 4.01 until the application upgrade, then it will be
upgraded to the current version.

Is it true that I can’t use Oracle data pump to copy Apex from one server
to another?



The correct answer is "it depends", of course.  I suspect that if the
webserver is the builtin EPG and there are no external files (custom
images, CSS, etc), it *may* work.  I'm not sure if APEX 4.x will work in an
Oracle 12.1 DB either.  If possible, I would upgrade the APEX version
first, then migrate to another DB/server.

I've only attempted migrations by using the APEX export/import
application, but I'm using ORDS on Tomcat for the web and also external
files.   As always, test, and YMMV.

GL!

Rich




--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/




-- 
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | @zztat_oracle | fb.me/zztat | zztat.net/blog/

Other related posts: