Thanks for the proxy idea, forgot about that. This could work to clean up
our existing jobs but it doesn't help with our somewhat automated rollouts.
Currently the developers give us a script we run in production which points
to multiple scripts for each object that compiles multiple packages and
creates jobs. So everything gets run under our accounts. It is not fully
automated yet but we plan to at some point.
On Thu, Mar 9, 2023 at 1:34 PM Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> wrote:
Use a proxy account:
ALTER USER <APP USER> grant connect through <DBA USER> ;
Then when you connect , you connect as:
DBA_USER[APP_USER]/DBA_USER_PASSWORD (where the account you're actually
logging into is the "APP_USER" inside the brackets.
Then any operation you run is run as the APP_USER and you don't need to
know the password for the APP_USER that should own the jobs.
HTH
Chris
On Thu, Mar 9, 2023 at 2:54 PM Jeff Chirco <backseatdba@xxxxxxxxx> wrote:
We have a lot of custom applications in our database all under locked
schema accounts. When we create scheduler jobs, the owner is the schema but
since the command gets run as a DBA account logged in the JOB_CREATOR is
the DBA that ran it. Which then when you look at active sessions while the
job is running it is that DBA user. Is there a way to have the JOB_CREATOR
be the schema instead? We dropped a DBA account then found out that all
the jobs he created for other schemas became disabled. Trying to avoid
this in the future.
Thanks,
Jeff
