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

From: Andy Sayer <andysayer_at_gmail.com>
Date: Wed, 8 May 2019 23:30:27 +0100
Message-ID: <CACj1VR4=8pL0cTc8dDw_E3c-g7ck=TRLeKAqGqv663-fYjY2Ag_at_mail.gmail.com>



That’s probably the case, but there’s always wishful thinking.

On Wed, 8 May 2019 at 22:28, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:

> he is now, not 'he is not'. Typing faster than thinking...
>
> On Wed, May 8, 2019 at 4:27 PM Andrew Kerber <andrew.kerber_at_gmail.com>
> wrote:
>
>> It sounds to me like its simply a matter of his boss overriding his
>> recommendation, and he is not at the point where he needs to do what his
>> boss is instructing, regardless of his best judgment. Been there, done
>> that, got the t-shirt. It goes with the job sometimes. Backed when I
>> worked in health care as an oracle dba, doctors always knew more about the
>> database than I did. Even when they didnt.
>>
>> On Wed, May 8, 2019 at 4:21 PM Andy Sayer <andysayer_at_gmail.com> wrote:
>>
>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>> --
>> Andrew W. Kerber
>>
>> 'If at first you dont succeed, dont take up skydiving.'
>>
>
>
> --
> Andrew W. Kerber
>
> 'If at first you dont succeed, dont take up skydiving.'
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 09 2019 - 00:30:27 CEST

Original text of this message