 | | | Checking if remote database is up | Checking if remote database is up 2005-04-26 - By Niall Litchfield
Would a quick hack to code the procedure as a version of=20
declare
l_alive number;
begin=20
select 1 into l_alive from dual@(protected);
if l_alive =3D 1 then
proc_name;
end if
end;
/=20
make sense?=20
This might avoid ocella upgrades breaking your check, or dealing with
the politics :).
Alternatively you might wish to add error handling for what ever
errors you get when the ocella db is down and add that to your
functions and procedures...
On 4/26/05, stephen booth <stephenbooth.uk@(protected)> wrote:
> One of our new systems (Documentum from EMC) uses a database link to a
> remote database (Ocella from Ocella) for some processes. Due to
> organisation politics the people managing the Ocella database don't
> tell the people managing Documentum when they're taking their system
> down (the joys of working in the public sector). Documentum can do
> most of it's functions when Ocella is down, it just can't do certain
> transactions, unfortunately it's currently not very good at dealing
> with situations where the Ocella database is down.
>=20
> We're looking at some way of checking if the Ocella database is up
> before trying a transaction that needs it then reporting back to the
> user if it's down. What we're currently thinking of is putting an
> empty table in the Ocella database then querying that from a PL/SQL
> function over the link and trapping the error. If we get data or 'No
> Rows Returned' then we know that the database is up and the link is
> working. If we get an ORA-03113 (See ORA-03113.ora-code.com) then we know that the database is
> down or the link isn't working for some other reason (e.g. Network
> broken again). the function returns either TRUE or FALSE depending on
> whether the remote dtabase is up or not.
>=20
> Does anyone have experience of a similar situation? Is there a more
> elegant/reliable method? Anything I've failed to consider that will
> make this all blow up?
>=20
> Thanks
>=20
> Stephen
>=20
> --=3D20
> It's better to ask a silly question than to make a silly assumption.
> --
> http://www.freelists.org/webpage/oracle-l
>=20
--=20
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
--
http://www.freelists.org/webpage/oracle-l
|
|
|