This is all very questionable.
"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. "
This seems quite suspicious. Why did restarting the app server and bouncing
the database help reduce the frequency the app was sending the same SQL? Or
help the problem at all? Are you sure that wasn't just some red herring
that looked terrible but was't the real problem? Was it executing the same
SQL with the same bind values, or was it likely that it was trying to join
data in the application? Or some other classic slow-by-slow process?
If this is something that happens several times a year and the whole app
slows down then something is different at those times - perhaps another
process is running to tip the workload from manageable to unmanageable,
perhaps a critical but quick SQL changes plan which increases it's duration
by a tiny fraction but because it's so important everything gets effected,
perhaps the result of some important SQL is usually cached somewhere but
something invalidated the cache.
How much slower are we really talking about here? Is this all over the
application or just a few processes?
"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."
You mean add load to the DB server? :) Any network elimination you get from
using the same Oracle home is also achieved by using a different Oracle
home on the same server, so long as the connections point to the same
machine you're in. You can also achieve bequeath connections but that would
likely require an application change - and if you're going to change the
application, you might as well fix the slow-by-slow behavior.
How it could help the situation you described isn't terribly clear - you
didn't do anything to speed up the network when you "fixed" the issues
before, you just restarted either end.
"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."
What exactly were you benchmarking? Did you run the application for long
enough with enough load that you would have hit whatever problem you were
seeing before? Were you using the same network? Did you do exactly the same
benchmark on older servers to show that it would have hit the problem you
were seeing?
"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."
Have you explained to the decision makers why you don't need to use the
same Oracle home to achieve what they think they want? (and why you
shouldn't)?
Thanks,
Andy
On Wed, 8 May 2019 at 22:00, Tim Gorman <tim.evdbt@xxxxxxxxx> wrote:
A few years ago, I had the pleasure of helping a vendor move their
Fortran-based ERP package for the building construction industry from
mainframe VSAM files to Oracle. It was easy, and it wasn't pretty, but
they needed the data in an RDBMS so that they could feed BI/DW environments.
The application itself still hums along on Fortran. Today. In 2019. And
the vendor itself is comfortably profitable in their niche in the
construction industry.
Before anyone thinks themselves superior, remember that we have all seen
highways and bridges rebuilt in a few months while in use, but none of us
have ever seen that happen in software, ever, anywhere. The project
managers, trained in construction and repurposed into IT, were awesome and
performed their jobs flawlessly, keeping the development and testing teams
progressing smoothly with full transparency and no hiccups.
It is no joke that if buildings and roads were built the way software is
developed, then the first gopher to come along would destroy civilization.
On 5/8/19 15:20, Michael D O'Shea/Woodward Informatics Ltd wrote:
All I can say is that I am gobsmacked. Having written that, I saw a
green-field VB6 contract role advertised the other day. They're going to
get who they deserve, that’s for sure.
Thanks for your replies all.
Mike
Am 08.05.2019 um 19:34 schrieb Jeff Chirco <backseatdba@xxxxxxxxx>:
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> 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>:
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 <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>
*Sent:* Wednesday, May 8, 2019 10:19 AM
*To:* Scott Canaan <srcdco@xxxxxxx>
*Cc:* 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
On May 8, 2019, at 9:59 AM, Scott Canaan <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 <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.
