[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Oracle DBD and 9i on Redhat



On Wed, Mar 31, 2004 at 05:23:56AM +0000, mike808@users.sourceforge.net wrote:
> > setting up Oracle 9i and the Perl DBD module for oracle.
> > setup oracle 9i on a Fedora/Redhat box as well as set up the DBD module.
> 
> For the DBD part, all you need is the SQL*Net client libs installed.
> 

hehe do you happen to have a tar file with those so i can just bypass most
of the migrain of getting oracle setup.

> For the Oracle 9i part, a lot depends on your disk configuration.

don't laugh (although I would if I weren't the one doing it)

> Oracle likes to have dedicated disk devices if possible. What's your disk
> footprint look like? NAS? SAN? Dedicated RAID array? Transaction and rollback
> log volumes? Are you able to allocate across multiple spindles? multi-channel
> SCSI controllers?

1 IDE disk, 40 gig, on an athlon 2800+ single proc <-- i know sick and twisted right
 
> Are you running any fancy stuff like the engines for native XML, natural query,
> full text indexing, Java-DB-appserver, distributed transactions, data
> warehousing, etc.?

nope just a standard db with a few dozen schema and about two gigs of data, but there
is no other db i can use for this application unfortunately :(

> Are you running heavy transaction apps like Oracle Financials?

nope 
 
> You may want to find someone with the Oracle setup experience that best fits
> your server and application environment. Then separately get someone with Perl
> module-building expertise to come in and build your DBD client modules. That
> part is definitely the easier of the two. 

last night I did end up running into some posts on google that talked about the
Oracle DBD not building from within the CPAN interface but if you pulled it down
and compiled manually it worked, i guess thats a new route for me to try

> Sizing and tuning your Oracle is the part where experience and skill can make
> big performance differences in the same configurations/environments.

It's a "backup/test" server so we can try things with the data and "see what happens"
without harming our current install.  Also I currently am doing alot of manual
operations with text files (output from Oracle) into perl scripts then back out
to sql files run back into Oracle.  All of these operations could be streamlined
and simplified if I could just connect directly and work with the data from within
one script.  

> The fact that it's on RH/Fedora shouldn't make a whole lot of difference to the
> actual oracle installation, since Oracle will readily consume whatever resources
> you feed it.

The problems i've been seeing seem (keeping in mind up till last month I knew nothing
about Oracle) to stem from the changes in GCC and some libraries from RH 8 to the
modern versions.  I've found a dozen or so install guides specifically for RH/Fedora
that have me change enviromental variables and rename standard executables because
Oracle hard codes the names and paths of the executables it needs.  
 
> Mike/

Bob T. Kat

-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.