Re: Oracle ping
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I rather strongly disagree. It is possible to do useful work over a > connection in situations when a 'simple select' is not possible. > My production Oracle database is protected by a physical standby database. Ah, well in that case I withdraw my previous statement. > However it is not possible to select from any table. > SELECT 1 FROM DUAL will fail. Ah, so Oracle still requires an actual table? Thought they might have joined the rest of us by now in allowing things like 'SELECT 2+2;' :) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201211051157 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlCX7+kACgkQvJuQZxSWSsiw9gCg7ue5/9c+qvKhw/uTpTx/4cWq 8HQAnjBdWDySKjPiwTOlOnoaTwvvdvFQ =V+96 -END PGP SIGNATURE-
Re: Oracle ping
I would tend to think that such a ping would be a special case, but I agree with you to keep it as is: Simply because overloading ping() with a complete eval'ed select statement would be trivial. And the opposite isn't. --- Henri Asseily henri.tel On Nov 5, 2012, at 4:35 PM, Charles Jardine wrote: > On 05/11/12 02:47, Greg Sabino Mullane wrote: > > >>> Also by the time an application does execute some SQL, the the >>> connection/node/server/network could have dropped and so the application >>> 'will have to check & recover from write failures at that point anyway." >> >> This is a bit of a red herring. You could say that about any database action, >> anytime ever. I personally think a simple select is better than relying >> on a low-level library call, as it does a more complete end-to-end check >> that is almost certainly closer to what the caller is going to use the >> connection for. > > I rather strongly disagree. It is possible to do useful work over a connection > in situations when a 'simple select' is not possible. My production > Oracle database is protected by a physical standby database. This > database is, in Oracle terms, mounted but not open. A user with the SYSADMIN > privilege can connect to the database. It is possible use virtual views to > monitor the database and ALTER SYSTEM commands to change its state. However > it is not possible to select from any table. SELECT 1 FROM DUAL will fail. > > I would like to see $dbh->ping to continue to return a true values in cases > like this. > > -- > Charles Jardine - Computing Service, University of Cambridge > c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
Re: Oracle ping
On 05/11/12 15:35, Charles Jardine wrote: On 05/11/12 02:47, Greg Sabino Mullane wrote: Also by the time an application does execute some SQL, the the connection/node/server/network could have dropped and so the application 'will have to check & recover from write failures at that point anyway." This is a bit of a red herring. You could say that about any database action, anytime ever. I personally think a simple select is better than relying on a low-level library call, as it does a more complete end-to-end check that is almost certainly closer to what the caller is going to use the connection for. I rather strongly disagree. It is possible to do useful work over a connection in situations when a 'simple select' is not possible. My production Oracle database is protected by a physical standby database. This database is, in Oracle terms, mounted but not open. A user with the SYSADMIN privilege can connect to the database. It is possible use virtual views to monitor the database and ALTER SYSTEM commands to change its state. However it is not possible to select from any table. SELECT 1 FROM DUAL will fail. I would like to see $dbh->ping to continue to return a true values in cases like this. Just to reiterate what I eventually said. I don't want ping changed in DBD::Oracle. All I was saying is you should only read anything useful into ping returning false and not true unless your only purpose is like Oracle's OCIPing which checks your connection is still there (although not usable for some things). I believe the connection caching only does anything when ping returns false. Like Charles, I also have database systems where the users who log in have no select access at all - in fact all you can do is call some procedures in a few packages (no select, no insert, update, delete, you cannot even seen any schema). A ping implemented as "select xx" is useless to me (not that I rely on it any way). Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
Re: Oracle ping
On 05/11/12 02:47, Greg Sabino Mullane wrote: Also by the time an application does execute some SQL, the the connection/node/server/network could have dropped and so the application 'will have to check & recover from write failures at that point anyway." This is a bit of a red herring. You could say that about any database action, anytime ever. I personally think a simple select is better than relying on a low-level library call, as it does a more complete end-to-end check that is almost certainly closer to what the caller is going to use the connection for. I rather strongly disagree. It is possible to do useful work over a connection in situations when a 'simple select' is not possible. My production Oracle database is protected by a physical standby database. This database is, in Oracle terms, mounted but not open. A user with the SYSADMIN privilege can connect to the database. It is possible use virtual views to monitor the database and ALTER SYSTEM commands to change its state. However it is not possible to select from any table. SELECT 1 FROM DUAL will fail. I would like to see $dbh->ping to continue to return a true values in cases like this. -- Charles Jardine - Computing Service, University of Cambridge c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
RE: Oracle ping
> From: g...@turnstep.com > To: dbi-dev@perl.org > Subject: Re: Oracle ping > Date: Mon, 5 Nov 2012 02:47:06 + > > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > >> Also by the time an application does execute some SQL, the the >> connection/node/server/network could have dropped and so the application >> 'will have to check & recover from write failures at that point anyway." > > This is a bit of a red herring. You could say that about any database action, > anytime ever. I personally think a simple select is better than relying > on a low-level library call, as it does a more complete end-to-end check > that is almost certainly closer to what the caller is going to use the > connection for. > Yes I am comming over to that way of thinking. Might just need some clarification in the DBD::Oracle doc then. i.e. May be able to ping but you cannot run querries or alike >> Mysql has 'mysql_ping' the same sort of thing as OCIPing except it can >> reconnect. > > Does it automatically reconnect? That certainly seems like the wrong thing > to do, especially in light of the docs for connect_cached. got that from the MySql doc it can be set up to reconnect if ping fails http://dev.mysql.com/doc/connector-python/en/myconnpy_MySQLConnection_ping.html> not didn't check the DBD driver to see if it does this though. Perhaps just some clarification on the DBI spec would be better to get all the DBD that impliment it in line and doing the same thing?? Cheers > - -- > Greg Sabino Mullane g...@turnstep.com > End Point Corporation http://www.endpoint.com/ > PGP Key: 0x14964AC8 201211042146 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > > -BEGIN PGP SIGNATURE- > > iEYEAREDAAYFAlCXKI0ACgkQvJuQZxSWSsgMAACg4VdWNpWYgyrENkXKhO9G5Mez > /fkAoM6hBowTxDCAvKOD6G7yQBgItiO1 > =85sU > -END PGP SIGNATURE- > >
