| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: How does OEM remotely start DB's?
On Fri, 03 May 2002 18:59:27 +0200, Sybrand Bakker
<postbus_at_sybrandb.demon.nl> wrote:
>>How can an Oracle DB be remotely started/stopped (programmatically -
>>rather than with clever rsh,rexec or telnet scripts)?
>
>Likely it uses the Oracle Agent and a database can be restarted only
>through OEM or directly on the server
>There is no API for Oracle Agent, and as I can guess what you are up
>to, I can only say: and that is GOOD. No DBA will want to have
>everyone to be capable to shutdown the database and restart it.
>Inevitably there will be an idiot or a hacker (please cross all that
>apply) that is going to try it.
>
>Oracle is not a toy like Microsoft Access which simply crashes many
>times a day when the database has reached a certain size. The
>procedure you seem to advocate is IMO highly unprofessional. If you
>allow this, do you think the person initiating the restart is going to
>recover the database if the restart doesn't work? Please reconsider.
>
Actually you are being a bit unfair here. We have no particular desire to produce a tool which can allow anybody to stop any database at whim. What would be the point? Any DBA can shut them down if need be. Besides the Oracle password or SYS ID is still likely to be required through any programmatic method - otherwise it is just "security by obscurity".
So why do we want a programmatic method of starting and stopping databases? Well we are in the business of producing software which creates referentially correct subset databases for testing and development. One issue that we get frequently asked about is that testers often trash these databases as part of their ongoing operations. They really need a tool with can save and restore databases at whim without involving the DBA's or sysadmins.
This is the software we are developing. Essentially the DBA's create the initial DB then copy and save it into what we call a slot on a client PC. This slot is write protected. The testers can, at the push of a button on their console, replace the database with the saved slot contents (shutting down the DB first). If they get the test database to a state to which they would like to return there are other unwrite protected slots into which the testers can save the database themselves. If they need to get back to a particular state they just restore it.
We have prototyped this in a working environment using a combination of scripts and SUID'd binarys (the working version will be pure client server - no scripts/serverside binarys involved). It has been very very sucessful. The testers love it - they are empowered - they do not need to involve the DBA's once the database has been created and saved in the write protected slot. They can replace and retest the same sequence of events several times an hour if need be. The DBA's and sysadmins like it too since they are overworked already and don't want to run around restoring databases all the time. Note: the testers never have the Oracle or Root password and cannot do anything really DBA'ish. It is purely a push button solution "make this copy of the database reappear" or pull the "fixed target database into this slot for later restoration".
So you can see there are legitimate reasons why one might want to work out a programmatic method of shutting down and starting Oracle databases.
Although the software is not yet ready, I do have a key features sheet for this software - if anybody wants a copy just send me an email.
Thanks
Dale Edgar
Net 2000 Ltd.
Dale_at_DataBee.com
 |
 |