How to Handle Transparent Application Failover TAF with DBD-Oracle
Har...@gmail.com
tnsnames.ora entry and a couple others that look similar.
stagging.rac =
(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =
host.name.com)(PORT = 15)) (ADDRESS = (PROTOCOL = TCP)(HOST =
host.name.too.com)(PORT = 15)) (LOAD_BALANCE = yes) (FAILOVER = true))
(CONNECT_DATA = (SERVICE_NAME = stagging) ) )
I went poking around in the oracle.com site and found that this appears
to be Transparent Application Failover" (TAF).
http://www.oracle.com/ecostructure/blueprint_res/implement_database_configuration_availability.htm
Since I have been asked to setup a tool to do some work on this
database I went to try and find out how the DBD-Oracle handles this. So
far my google searches have come up with very little. Is there some
info or examples on how this is handled and/or how to format the
connect string?
I am particularly interested in the connect string format that does not
require the use of the tnsnames.ora file but allows the host, port and
sid to be specified in the connect string.
Example: DBI:Oracle:host=$host;sid=$sid;port=$port
If this is not currently supported has anyone tried to handle this
programmatically and know of any hidden fun in the way Oracle kicks the
failure out during failover?
I did mistakenly post this question in
http://www.cpanforum.com/posts/1197
Bart the bear
You can't do it. DBD::Oracle doesn't support TAF, direct loads or array
interface.
DBI is not database neutral. DBI is geared toward MySQL and PostgreSQL.
DBD::Oracle is not being fixed because Tim Bunce is pushin open source
databases,
and Oracle driver isn't getting fixed and/or enriched with the new
features. If you want
a decent database driver, try with Python.
tim....@gmail.com
> Har...@gmail.com wrote:
> > The Database Admins in the place where I work gave me the following the
> > tnsnames.ora entry and a couple others that look similar.
> >
> > stagging.rac =
> > (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST =
> > host.name.com)(PORT = 15)) (ADDRESS = (PROTOCOL = TCP)(HOST =
> > host.name.too.com)(PORT = 15)) (LOAD_BALANCE = yes) (FAILOVER = true))
> > (CONNECT_DATA = (SERVICE_NAME = stagging) ) )
> > I went poking around in the oracle.com site and found that this appears
> > to be Transparent Application Failover" (TAF).
> > http://www.oracle.com/ecostructure/blueprint_res/implement_database_configuration_availability.htm
> >
> >
> > Since I have been asked to setup a tool to do some work on this
> > database I went to try and find out how the DBD-Oracle handles this. So
> > far my google searches have come up with very little. Is there some
> > info or examples on how this is handled and/or how to format the
> > connect string?
> >
> > I am particularly interested in the connect string format that does not
> > require the use of the tnsnames.ora file but allows the host, port and
> > sid to be specified in the connect string.
> >
> > Example: DBI:Oracle:host=$host;sid=$sid;port=$port
> > If this is not currently supported has anyone tried to handle this
> > programmatically and know of any hidden fun in the way Oracle kicks the
> > failure out during failover?
Did you try it? That kind of connection string has been supported since
DBD::Oracle 1.03 (12th July 1999) and is documented
http://search.cpan.org/~timb/DBD-Oracle/Oracle.pm#Connecting_without_environment_variables_or_tnsname.ora_file
> > I did mistakenly post this question in
> > http://www.cpanforum.com/posts/1197
Very few people read cpanforum for DBI/DBD::Oracle related posts. Also,
messages posted on google groups rarely get through to the
dbi-...@perl.org mailing list.
It's only because someone posted a note about this thread on
dbi-...@perl.org (where several thousand people are subscribed,
including myself) that I'm replying here.
> You can't do it. DBD::Oracle doesn't support TAF, direct loads or array interface.
DBD::Oracle supports using Oracle connection descriptions directly:
$dbh = DBI->connect('dbi:Oracle:', q{scott/tiger@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST= foobar)(PORT=1521))
(CONNECT_DATA=(SID=ORCL)))}, "");
I don't know if any deeper support is required for TAF, but if it is
I'd be very happy to add it if someone sends me a patch.
> DBI is not database neutral. DBI is geared toward MySQL and PostgreSQL.
I don't know where you got that idea from, but it's wrong. DBD::Oracle
was actually the very first DBI driver.
> DBD::Oracle is not being fixed because Tim Bunce is pushin open source databases,
Also baseless and just plain wrong.
> and Oracle driver isn't getting fixed and/or enriched with the new features.
Also wrong. Real life has certainly delayed progress (most recently
with the birth of my second daughter a few weeks ago) but the Oracle
driver IS getting fixed and/or enriched with the new features. In fact
1.17 is about ready - a release candidate should be available within a
week or two.
> If you want a decent database driver, try with Python.
Ah. Perhaps you're right, from your perspective, but I'd be grateful if
you didn't promote other software by spreading misinformation about
DBD::Oracle.
Tim.
Bart the bear
tim....@gmail.com wrote:
>
> $dbh = DBI->connect('dbi:Oracle:', q{scott/tiger@(DESCRIPTION=
> (ADDRESS=(PROTOCOL=TCP)(HOST= foobar)(PORT=1521))
> (CONNECT_DATA=(SID=ORCL)))}, "");
>
> I don't know if any deeper support is required for TAF, but if it is
> I'd be very happy to add it if someone sends me a patch.
TAF support is added within OCI and supports re-establishing connection
with one
of the surviving nodes if a node to which the session was connected
died. It also
includes continuing the curent transaction.
>
> > DBI is not database neutral. DBI is geared toward MySQL and PostgreSQL.
>
> I don't know where you got that idea from, but it's wrong. DBD::Oracle
> was actually the very first DBI driver.
And Oracle was the very first database to have an array interface.
DBD::Oracle still
doesn't have it.
>
> > DBD::Oracle is not being fixed because Tim Bunce is pushin open source databases,
>
> Also baseless and just plain wrong.
>
> > and Oracle driver isn't getting fixed and/or enriched with the new features.
>
> Also wrong. Real life has certainly delayed progress (most recently
> with the birth of my second daughter a few weeks ago) but the Oracle
> driver IS getting fixed and/or enriched with the new features. In fact
> 1.17 is about ready - a release candidate should be available within a
> week or two.
So, will finally have proper array interface or will it still be
internally breaking
queries, thus making PostgreSQL appear faster then Oracle, when used
from
Perl? The holy grail are direct inserts and proper implementation of
the array
interface. You may say that you don't prefer Pg, but by not
implementing array
interface, you're saying something completely different.