Approver, certifier, fulfillment user set to oiminternal during role creation through scheduled job

Question

Hi all,
We are running 11gR2 PS1 (BP01). We have a scheduled job that creates role and then populates approver_user attribute (with user ID) in the catalog entry of this role. We only want the approver_user to be populated and not the certifier and fulfillment user on the catalog.
When i view the role in catalog, the approver user is correctly set with the user ID provided by the scheduled job however I see that certifier user and fulfillment user are automatically set to oiminternal.
We did not see this behavior in R2.
Are there any configurations that will prevent certifier user and fulfillment users to be auto populated with the identity of the user running the scheduled job (oiminternal)?
Thanks.

Answer 1

So while this certainly isn't the most elegant of solutions, and most assuredly isn't in the realm of supported by Oracle...
I've used the DBMS_IJOB.DROP_USER_JOBS('username'); package to remove the 194558 orphaned job entries from the job$ table. Don't ask, I've no clue how they all got there; but I've prepared some evil looks to unleash upon certain developers tomorrow morning.
Not being able to reorganize the JOB$ table to free the now wasted ~67MB of space I've opted to create a new index on the JOB$ table to sidestep the full table scan.
CREATE INDEX SYS.JOB_F1_THIS_NEXT ON SYS.JOB$ (FIELD1, THIS_DATE, NEXT_DATE) TABLESPACE SYSTEM;The next option would be to try to find a way to grant the select privilege to the role without using the aforementioned "after CREATE on schema" trigger and dbms_job call. This method was adopted to cover situations in which a developer manually added a table directly to the database rather than using the provided scripts to recreate their test environment.
I assume that the following quote from the 11gR2 documentation is mistaken, and there is no such beast as "create or replace table" in 11g:
http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_9003.htm#i2061306
"Dropping a table invalidates dependent objects and removes object privileges on the table. If you want to re-create the table, then you must regrant object privileges on the table, re-create the indexes, integrity constraints, and triggers for the table, and respecify its storage parameters. Truncating and replacing have none of these effects. Therefore, removing rows with the TRUNCATE statement or replacing the table with a *CREATE OR REPLACE TABLE* statement can be more efficient than dropping and re-creating a table."