Re: AW: How to Install Oracle 12 Client in Existing Oracle Home

From: Andy Sayer <andysayer_at_gmail.com>
Date: Wed, 8 May 2019 22:19:56 +0100
Message-ID: <CACj1VR4pVFL5RoyFOAh+KN9wcTrczHKyC7gfHtUMjW5=QsSKUw_at_mail.gmail.com>



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_at_gmail.com> 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_at_gmail.com>:
>
> 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_at_strychnine.co.uk> 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_at_rit.edu>:
>>
>> 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_at_rit.edu <srcdco_at_rit.edu>* | 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_at_gmail.com>
>> *Sent:* Wednesday, May 8, 2019 10:19 AM
>> *To:* Scott Canaan <srcdco_at_rit.edu>
>> *Cc:* oracle-l_at_freelists.org
>> *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_at_gmail.com
>>
>>
>>
>> On May 8, 2019, at 9:59 AM, Scott Canaan <srcdco_at_rit.edu> 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_at_rit.edu <srcdco_at_rit.edu>* | 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.
>>
>>
>>
>>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed May 08 2019 - 23:19:56 CEST

Original text of this message