Re: Startup via SQL Embedded

IMO, this setup is a recipe for disaster. An application should never have the dba role, either internally or externally granted. Otherwise, an application error could corrupt the database.

Using the script run at boot time should suffice. If the database does not come up at that point, the odds are quite high that it will not come up when the application tries to start it.

                                  Rick

renatofabiano_at_hotmail.com (Renato Fabiano) writes:

> > > Hi guys,
> > >
> > > I want to know if it is possible to start an Oracle db instance
> > > via an C application (Pro*C), without using a "system()" call
> > > to "svrmgrl".
> > <snip>
> >
> ...
>
> > Your application will need a dba right?
>
> In order to startup an Oracle instance an user must have
> the Oracle DBA role; or to be part of O.S. group named "dba",
> to perform an 'connect internal'.
> My application can have this permissions.
>
> > That person will be able to startup both your app and the database?
>
> Yes, if it was possible to start the database instance from the
> application, the application would start the Oracle instance too.
>
> > Indeed they will be able to script that using cron or whatever.
>
> I've configured my Oracle db instance to start automatically during
> Solaris boot using script "/etc/init.d/dbora".
>
> Moreover, I want to ensure that when the application is started,
> it looks for an active Oracle instance and, if there isn't,
> it attempts to startup a new instance.
>
> > Why on earth is that not acceptable?
>
> Actually, It's acceptable.
>
> I just want to know if there is another way to start db instance,
> mainly via a Pro*C program, without using sqlplus or svrmgrl. Is there?
>
> Thanks,
>
> Renato Fabiano

-- 
                                Rick Wessman
                                Security Assurance Group
                                Oracle Corporation
                                Rick.Wessman_at_oracle.com

     The opinions expressed above are mine and do not necessarily reflect
                         those of Oracle Corporation.