Building DBD::Oracle with one version but deploying with another

[John Wiersba]

[A previous version of this question was asked on dbi-users -- I haven't gotten any response there.  Not sure which list to post to.]

Hi, I'd like to find out how to build/install DBD::Oracle with one
version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location).  It seems like the Oracle
client libraries can be loaded dynamically at runtime, based on
ORACLE_HOME, so there doesn't need to be a dependency on those exact
client libraries that were used at build/install time. 

Another
way of asking:  How does ActiveState deploy DBD::Oracle without needing
to build it (maybe no C compiler is available), on servers with
different versions of the Oracle client libraries installed?

I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once.  If there's any reference material that I have overlooked, could you please point it out.  The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work?

Thanks!-- John

[Lyle]

On 18/04/2013 16:22, John Wiersba wrote:
> [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.]
>
> Hi, I'd like to find out how to build/install DBD::Oracle with one
> version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle
> client libraries can be loaded dynamically at runtime, based on
> ORACLE_HOME, so there doesn't need to be a dependency on those exact
> client libraries that were used at build/install time.
>
> Another
> way of asking: How does ActiveState deploy DBD::Oracle without needing
> to build it (maybe no C compiler is available), on servers with
> different versions of the Oracle client libraries installed?

I built DBD::Oracle on windows recently. I did need the Oracle client
libraries for the tests to pass, and ActiveState would have too. Once
built they package up the binaries for distribution, and expect the
target system to have the appropriate libraries. If I remember
correctly, I had to download the appropriate libraries from Oracle. I
spoke to the vanilla Perl people about this, as they currently don't
have a DBD::Oracle bundled in with their distro. They had been looking
at bundling the client libraries as well, but I think there is a
licensing issues surrounding doing that which is why ActiveState do not
do it. We agreed to take another look at it next month as I'm very busy
this month.

> I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work?

With ActiveState's ppm, it wont work on the target system unless the
correct client libraries are there. I think that's what led me to build
my own DBD::Oracle in the first place. I was building for 64 bit
Windows, and found this blog post:
http://www.pythian.com/blog/dbdoracle-and-windows-64bit/
I found errors in that post and commented with my findings, yet my
comment has yet to be accepted. I think Pythian is on this list? So
maybe they will comment.


Lyle

[John Wiersba]

Thanks, Lyle.  I'm trying to build DBD::Oracle on Linux/AIX/Solaris for distribution to another server (assume the OS and perl versions on both servers) which will have a different ORACLE_HOME, possibly a different version of the Oracle client and likely in a different location.  The target server may not have a C compiler.

That's the same situation that ActiveState must have encountered, building DBD::Oracle with whatever version of Oracle they had downloaded and installed in some random location, but deploying it on the user's server which likely has a different version of Oracle installed in a different location.

>________________________________
> From: Lyle <webm...@cosmicperl.com>
>To: dbi...@perl.org
>Sent: Thursday, April 18, 2013 11:43 AM
>Subject: Re: Building DBD::Oracle with one version but deploying with another

[Jan Dubois]

I think you also need to add the ORACLE_HOME directory to
LD_LIBRARY_PATH (on the deployment machine) to make it work.

Cheers,
-Jan

[John Wiersba]

Yes, I'm doing that.  Each server can have a different environment than the server the original DBD:Oracle was built on.  Or the question still applies if I want to use a different version of Oracle installed on the original build server, especially if I remove the version of Oracle that was used to build the original DBD::Oracle.

>________________________________
> From: Jan Dubois <ja...@activestate.com>
>To: John Wiersba <jrw3...@yahoo.com>
>Cc: Lyle <webm...@cosmicperl.com>; "dbi...@perl.org" <dbi...@perl.org>
>Sent: Thursday, April 18, 2013 1:09 PM

[Jan Dubois]

Sorry, I can't remember the details. I think you must use clients for
the same version of Oracle on the server, e.g. if you compiled
DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to
work with an Oracle 11 client. But my memories of that are foggy; I
don't know if this is just a limitation on Windows, or if it applies
everywhere.

I also never tried to run DBD::Oracle compiled against the instant
client with a server that has the regular client installed. I kind of
expect it to work, if they are the same versions, but haven't verified
it.

Cheers,
-Jan

[John Wiersba]

Yep, that's exactly what I'm getting at.  Apparently ActiveState makes this work with their DBD::Oracle package.  So, I'm wondering how I can make it work, too.  What are the limitations?  Why does ORACLE_HOME and LD_LIBRARY_PATH need to be set during build/installation rather than just during runtime?

>________________________________
> From: Jan Dubois <ja...@activestate.com>
>To: John Wiersba <jrw3...@yahoo.com>
>Cc: Lyle <webm...@cosmicperl.com>; "dbi...@perl.org" <dbi...@perl.org>

>Sent: Thursday, April 18, 2013 1:41 PM

[Martin J. Evans]

On 18/04/13 18:41, Jan Dubois wrote:
> Sorry, I can't remember the details. I think you must use clients for
> the same version of Oracle on the server, e.g. if you compiled
> DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to
> work with an Oracle 11 client. But my memories of that are foggy; I
> don't know if this is just a limitation on Windows, or if it applies
> everywhere.
>
> I also never tried to run DBD::Oracle compiled against the instant
> client with a server that has the regular client installed. I kind of
> expect it to work, if they are the same versions, but haven't verified
> it.
>
> Cheers,
> -Jan

DBD::Oracle attempts to find the version of your client using sqlplus etc. Once it knows the version it sets macros which affect what support is built into DBD::Oracle.

e.g.,

Installing on a linux, Ver#2.6
Using Oracle in /home/martin/instantclient_11_2/
DEFINE _SQLPLUS_RELEASE = "1102000200" (CHAR)
Oracle version 11.2.0.2 (11.2)
Looks like an Instant Client installation, okay
Your LD_LIBRARY_PATH env var is set to '/home/martin/instantclient_11_2/'

DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.2\" -DORA_OCI_102 -DORA_OCI_112

Notice the ORA_OCI_102 and ORA_OCI_112 macros are defined in this case since this was Oracle 11.2. If you search the source for those macros you'll see loads of places where code is only included if they are defined and hence it affects what you can do with DBD::Oracle.

So if you built against a 10.2 client and then attempted to run against a 11.2 client there are a) things you would not be able to do and b) possibly DBD::Oracle would make a different set of OCI calls (you'd need to read the code to see what).

If you did it the other way around it is quite likely some things won't work.

The instant client files required to run DBD::Oracle (as opposed to build it) are quite small. What cannot you distribute those with the DBD::Oracle you build.

Martin

[Jan Dubois]

On Fri, Apr 19, 2013 at 12:35 AM, Martin J. Evans <boh...@ntlworld.com> wrote:
> The instant client files required to run DBD::Oracle (as opposed to build
> it) are quite small. What cannot you distribute those with the DBD::Oracle
> you build.

It is my understanding that you have to present the OIC license to the
user before installation and have them *actively* accept it (click on
an "I accept" button, or answering "yes" to a prompt, with "yes" not
being the default etc). The last time I checked, you couldn't even
download the OIC without accepting the license first via JavaScript;
there were no direct download link. And somewhere in their
redistribution license was a clause that says they expect you to do
the same thing when you redistribute.

So it is possible, but requires non-trivial extra effort in your
installer to do this.

Cheers,
-Jan

[John Scoles]

Should Allways work for 1 DB version forward and one back.

So a 10 instantshould should work a 9,10 and 11 at least that is the theory.

Oracle is a little unclear on what a Version is.

What I usually do is complie with the instant client and depoly it with the compiled code. This is how activestae gets awaywith it
as they install the IC along with the dll so they need only compile it once/\.

One can freely ditribute the IC with no gruff from Oracle.

Cheers





> Date: Fri, 19 Apr 2013 08:35:39 +0100
> From: boh...@ntlworld.com
> To: dbi...@perl.org