I understand all that. We prefer to have them separate, but I lost that battle
years ago.
The (quick) history is this. Several times a year the app would start running
slowly. It would only be fixed by restarting the app server and bouncing the
database. At that point, it was running on old Solaris hardware and we were in
the process of upgrading the app and migrating to Red Hat 7 and much newer
servers. We did some analysis and found that the database was responding very
quickly, however the app was sending the same SQL almost a million times, so it
looked like the SQL was taking a long time to run. The decision was made to
co-locate the app and the database (something I don’t like to do) to “eliminate
the network” from the transaction. My belief was that the move from Solaris to
Red Hat would have been enough to solve the problem as benchmarking that I had
done showed that the Red Hat servers were 10 – 20 times faster than the Solaris
servers. I was overruled, so I had to create an Oracle Home that ran the
database and also contained all of the client software so the app could run.
That’s how we got to where we are now. Now we are trying to upgrade from
Oracle 12.1.0.2 to 12.2.0.1 and need a similar configuration. I’d love to go
back to the app server / database server configuration, but those that made the
original decision to co-locate them have said no.
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<mailto: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: Seth Miller <sethmiller.sm@xxxxxxxxx>
Sent: Wednesday, May 8, 2019 2:40 PM
To: Backseat DBA <backseatdba@xxxxxxxxx>
Cc: woodwardinformatics@xxxxxxxxxxxxxxxx; Scott Canaan <srcdco@xxxxxxx>;
oracle-l@xxxxxxxxxxxxx
Subject: Re: How to Install Oracle 12 Client in Existing Oracle Home
Installing a client in an existing home puts you in a precarious position at
best with Oracle Support.
On Wed, May 8, 2019 at 1:35 PM Jeff Chirco
<backseatdba@xxxxxxxxx<mailto:backseatdba@xxxxxxxxx>> wrote:
Our ERP system is done in COBOL. It was a package purchased many years ago but
we own the source code and have completely redone it over the years. It is a
totally custom ERP system. The COBOL developers range from 20-39 years old,
granted they were all hired from within and trained into that position.
However we have begun to work on moving this ERP system into APEX.
On Wed, May 8, 2019 at 7:42 AM Michael D O’Shea/Woodward Informatics Ltd
<woodwardinformatics@xxxxxxxxxxxxxxxx<mailto:woodwardinformatics@xxxxxxxxxxxxxxxx>>
wrote:
I just have to ask, sorry - COBOL? Is there much COBOL there or this is just
one of the remaining remnant applications? And is new COBOL development
ongoing? And the developers, what age range?
I do a lot of contract work in banks and although I’ve heard rumours there is
COBOL in the wild, I have never met one of these developers. Especially
Pro*COBOL.
Decades back I used to develop in Cics and RM/COBOL. As I write, that was
decades back. I have not seen COBOL on the (UK) contract job boards for years
either.
Mike
Von meinem iPhone gesendet
Am 08.05.2019 um 15:31 schrieb Scott Canaan
<srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>>:
I was wondering the same thing. In 12.1.0.2, the Oracle Homes are slightly
different, though. I have to make sure that the Pro*COBOL precompiler is
there, as the application is written in COBOL.
In looking at the inventory on the special Oracle Home that I built in 2016
that includes the client, the comps.xml file is different in that it includes
the client install in addition to the base install.
The problem is that I can’t just take a chance that it will work.
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<mailto: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: Shane Borden <sborden76@xxxxxxxxx<mailto:sborden76@xxxxxxxxx>>
Sent: Wednesday, May 8, 2019 10:19 AM
To: Scott Canaan <srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>>
Cc: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: How to Install Oracle 12 Client in Existing Oracle Home
Perhaps I am mistaken, but isn’t the client already a part of the database
software?
---
Thanks,
Shane Borden
sborden76@xxxxxxxxx<mailto:sborden76@xxxxxxxxx>
On May 8, 2019, at 9:59 AM, Scott Canaan
<srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>> wrote:
We have an application that needs to have the Oracle client installed in the
same Oracle Home as the database software. Somehow, I managed to do it with
Oracle 12.1.0.2, but the client installer for Oracle 12.2.0.1 won’t let me. It
says there’s already Oracle software in that home and won’t let me move on.
How do I do this?
This is Oracle 12.2.0.1 on Red Hat 7 Linux.
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<mailto: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.