| 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 19:33:31 GMT, Daniel Morgan
<dmorgan_at_exesolutions.com> wrote:
>Dale Edgar wrote:
>
>> 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.
>> >
>> >[Stuff Snipped]
>>
>>[Stuff Snipped]
>> 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.
>>
>>[Stuff Snipped]
>
>Please correct me if I misunderstand what you are doing but it seems to me
>you are making this far more complex than need be.
>
>Why can't you take a single database and just mirror the schemas being used
>for testing into other schemas right inside the same database? Restoration
>would require nothing more than a simple PL/SQL package that could be run
>by anyone with the EXECUTE privilege.
Hi Daniel
We did actually consider the mechanism you mention. It turns out that it becomes increasingly unfeasable (for reasons of speed and reproduceability) as the complexity of the schema increases.
The end result is to make sure the starting point is _exactly_ the same for the start of each test. If it isn't then the users are not testing the same thing each time and the test could be invalidated.
One of the major issue with the schema copy approach is figuring out what the current setup is and then figuring out how to put it all back. Lots of times the testing involves changes to multiple schemas in the same DB - so those would each have to be put back exactly identically. Also sometimes there is "state" information associated with a schema (pending jobs, refresh state of snapshots/adv queuing) which are not re-createable via a simple copy. Essentially the schema copy technique means rewriting (or providing a wrapper around) EXP and IMP. The schema copy is slower too. It just turns out to be a lot more efficient to simply stop the database, splat the database files back and start it up than it is to recreate everything. The databases we are talking about here are small referentially correct test/development databases (5-10 Gig) not huge terabyte production instances. Plus when the database has been restored - it is _absolutely_ the same as it was at the start of the previous test - no hidden funnies, every new feature in every minor version supported. All in all the restore method is just a lot cleaner and simpler.
Cheers
Dale Edgar
Net 2000 Ltd.
Dale_at_DataBee.com
 |
 |