Well there's a hint in the name of that Windows permission.
Can you guess how oracle implements certain functions in OEM?
Yes that's right, it apparently does them as batch jobs submitted to
the OS,
and then the user whose credentials are used to login to do that must
have this permission. That sounds very simple and straightforward but
in real life, the customer doesn't know how OEM does stuff under the
hood,
that it is using batch jobs. They just
know that they were logged into OEM, selected some task, and OEM
came back and asked them for an id and password to do that task, and
then the task fails with OEM saying the id and password are wrong. This
is
very confusing to have oracle come back and tell you you don't know the
administrator password when you obviously do. What would be a good
thing
for oracle to do here is evaluate the permissions of the user id
supplied
for the task at the time it asks for that information. Then it could
tell
the interactive user using OEM that the id supplied lacked whatever
permissions, rather than result in a misleading error message at
execution time. Simple, effective, happy customer, no hours of sifting
through
messages on metalink to find this out.
DA Morgan wrote:
> fluff wrote:
>
> > There's a lot of little gotchas and each one
> > takes time. For example, you have to
> > have the "login as a batch job" privilege for
> > a lot of oracle activities. By default even administrator doesn't have
> > that in 2003 server.
> > There's just a lot of issues like that.
>
> What does being an administrator on a Micrsoft operating system have to
> do with an Oracle privilege?
>
> The only gotcha I see here is the one about reading the manual before
> engaging the keyboard.
> --
> Daniel A. Morgan
> http://www.psoug.org
> damorgan_at_x.washington.edu
> (replace x with u to respond)
Received on Sat Jul 09 2005 - 17:28:53 CDT
