Operating System - HP-UX
1752273 Members
4626 Online
108786 Solutions
New Discussion юеВ

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

 
Ralph Grothe
Honored Contributor

Supressing error about unset ORACLE_HOME from DBD::Oracle

After finally successfully defeating the installation beast DBD::Oracle on HP-UX 11.00 (this was a long battle),
I'm now about to set up some monitoring scripts for our Oracle dbs.
For testing purposes I created an Oracle test instance FOO.
To use more "user-friendly" Oracle TNS names (I dislike the names our DBAs chose ;-) I provided myself with a copy of a tnsnames.ora file with wee short instance names of *all* our db instances where an Oracle listener is listening for connect requests.
I put my copy of tnsnames.ora in
/usr/local/etc/oracle
The original tnsnames.ora files provided by our DBAs reside somewhere in
$ORACLE_HOME/network/admin

Please have a look at the short sample scriplet in the attachment to see how I do the connection.

I found out that I have to take care for unsetting any ORACLE_HOME environment variable, because then the original tnsnames.ora file would take precedence over mine, which would result in a failed connection.
That's why I explicitly unset ORACLE_ENV should it be set, and only set TNS_ADMIN to point to the dir with my tnsnames.ora.
Of course I have to mention that I connect with my DBD::Oracle client remotely (i.e. DB instance runs on another host).

When I run this script I successfully get connected, which means that my client uses my tnsnames.ora since an instance FOO is officially unknown.
But what still annoys me is that I cannot supress a warning/error about an unset ORACLE_HOME, which my client really doesn't need.

Here's the output from the attached script:

ORACLE_HOME environment variable not set!
connected to FOO as system successfully

Of course, I could close or redirect STDERR to get rid of the warning/error.
I also tried to set the attribute hashref's keys RaiseError and PrintError to 0.
But this doesn't help, and I wouldn't want to do this because I'd like to catch errors.

Madness, thy name is system administration
16 REPLIES 16
H.Merijn Brand (procura
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

I know you are using a recent perl :)

Try if changing

#!/usr/bin/perl -w

use DBI;

to

#!/usr/bin/perl

use strict;
use warnings;
use DBI;

helps. use warnings is more localized (scoped) than -w, and might just be what you want.
Enjoy, Have FUN! H.Merijn
H.Merijn Brand (procura
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

BTW congratulations to your new hat!
Enjoy, Have FUN! H.Merijn
John Palmer
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Hi Ralph,

Are you sure that you have to unset ORACLE_HOME.

I thought that Oracle will look in the directory (if it's set), otherwise /etc and $ORACLE_HOME/network/admin.

I've tried it (Oracle 8.1.7) and it picks up my (private) tnsnames.ora OK.

Regards,
John
Ralph Grothe
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Thank you Merijn,

but I am much more happy about that I got DBD::Oracle installed finally than about the new hat ;-)

Of course, I always "use strict".
I only felt it'd be too exaggerated for just 5 lines of code.

And, I also will be using the warnings pragma.
"-w" was just left over as an old habit from my previous Perl installation.

But even with the warnings pragma the output is exactly the same.
So I guess this must be coming rather from some Oracle lib (or the inards of DBD::Oracle) than from Perl.

But never mind, this is just a cosmetic problem that I can circumvent somehow.

What upsets me more are some bugs (so it looks to me) with the debugger of Perl 5.8.0-RC3.

For instnace the command set changed a little bit.
E.g. lower case "w" now sets a watchpoint instead of the display window, but this will be regarded as a feature I suppose.
What I miss is that the => arrow which indicated your current position, doesn't seem to work.
Shell escapes also don't work in this debugger (used to work in earlier versions by "!!").
Then the pager (I exported PAGER in my environment) isn't invoked when you use "|" before a command.
I really miss this feature, which was nice when you were looking on large nested data structures.
With nested hashes, I always used
"|x \%some_hash"
in the debugger, which would give you a nice Data::Dumper like overview of the whole data structure.

Have you come accross those as well?

I haven't been playing long enough yet with Perl 5.8.0 to have stumbled over other obscurities.
So let's see what else doesn't work the way I expect it to.

But it clearly said in CPAN, from where I always download the sources, that this version is considered "development" ("if you want to be at the bleeding edge...")

stable.tar.gz still contains Perl 5.6.1 !!!

I only installed 5.8.0 because you said this would be the only version that allowed installation of DBD::Oracle on HP-UX.
Don't you think I can step back to 5.6.1?
This would make me feel more comfortable.
But right now I haven't the time to do a new Configure/make run.
I will try if DBD::Oracle cooperates with Perl 5.6.1 on HP-UX when I find time.


Madness, thy name is system administration
Ralph Grothe
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

I thought this would be enough, to clear some uncalled for ORACLE_HOME setting:

delete $ENV{ORACLE_HOME} if exists $ENV{ORACLE_HOME};
Madness, thy name is system administration
Jean-Luc Oudart
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

use the TNS_ADMIN variable.
If not set the config files are found in $ORACLE_HOME/network/admin or /etc.

Of course there is a rule of priority.

Jean-Luc
fiat lux
Ralph Grothe
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Just double checked with the POD of delete.
Here is what it says with regard to %ENV:

Deleting from $ENV{} modifies the
environment.
Madness, thy name is system administration
H.Merijn Brand (procura
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

> But it clearly said in CPAN, from where I
> always download the sources, that this
> version is considered "development" ("if
> you want to be at the bleeding edge...")
> stable.tar.gz still contains Perl 5.6.1 !!!

What is your favourite CPAN? On ftp://ftp.funet.fi/pub/languages/perl/CPAN/src/ all looks fine. What mirror is wrong? Then I can ask the responsible persons to fix it!

> I only installed 5.8.0 because you said
> this would be the only version that allowed
> installation of DBD::Oracle on HP-UX.

No, not true. Only if you depend on Unicode 5.8.0 is *needed*. And the -A trick for Oracle is not supported in 5.6.1 Configure, but you can always alter config.sh or enter it manually if you need it.

> Don't you think I can step back to 5.6.1?

No.

> This would make me feel more comfortable.

Why?


For the debugger issues, I don't use it :)
I use ptkdb (you will need Tk) from ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module/Devel/Devel-ptkdb-1.108.tar.gz so I don't have to think about debugger options and commands
Enjoy, Have FUN! H.Merijn
Ralph Grothe
Honored Contributor

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Jean Luc,

please have a look at the attachment.
I explicitly set $ENV{TNS_ADMIN}.
And as I said this works, because in the
$ORACLE_HOME/network/admin/tnsnames.ora
there is no "net service name" (cited from an Oracle training booklet a DBA lent me) such as FOO.
This means I wouldn't have got a connection at all if my client resorted to the "official" tnsnames.ora
Madness, thy name is system administration