OBIEE 12c RCU Error - "The specified user may not have sufficient privileges to perform this operati

chillychin

Im attempting to install OBIEE 12c on our teams sand box and am hitting an error when trying to install the repository schemas.

The DBA's are being a bit of a pain and not allowing my user account to have DBA privileges - I understand why but its just a pain.

Anyways, I start the RCU tool and I click on [Prepare scripts for System Load - Create scripts for DBA to run later]

It then takes me to another screen asking me to enter in connection details which I do then I hit the following error

"The version  of the database that you are using is not a supported version or

The specified user may not have sufficient privileges to perform this operation. User should have sysdba or dba privileges."

The version of my database is 12.1.0.2.0 which meets the requirements, so it should be a privilege issue.

My question now is why on earth do I need to have DBA or SYSDBA privileges when I am generating scripts for a DBA to run later??

If I have DBA/SYSDBA privileges I would just do a full System and Product load.

I hit this error on all 3 options, even on [Perform Product Load]

Im very confused why Oracle/OBIEE12c would give you "options" to install the new schemas, yet for all the options you need DBA/SYSDBA privileges????

Is anyone else having this problem??

Gbenga Ajakaye

You don't need sysdba or dba. You just need to make sure your user id has the privileges below for you to perform the system load:. See the details here https://docs.oracle.com/middleware/1212/core/RCUUG/overview.htm#RCUUG347

• grant select_catalog_role to user;
• grant select any dictionary to user;
• grant create session to user;
• grant select on schema_version_registry to user;

I understand why your DBA isn't giving you either DBA or SYSDBA privileges. Those are powerful privileges that should only reside with the dba. You haven't given them any reason to grant you those privileges. Just tell them that you only need the listed privileges.

Gianni Ceresa

Do not forget the RCU implemented an alternatives for these cases.

You can run the RCU to generate the scripts instead of execute them and you send the SQL to your DBA so he can review what is inside and execute it as sys on his side without problem. In this way the DBA keep sys on his side and is also totally aware of what the RCU does on his server.

Just tell him he must not edit the script ...

chillychin

Much thanks for this!

I totally understand as well why they are hesitant as well - But that Oracle error message really doesnt help when it says specifically I need SYSDBA/DBA privileges EVEN on a product load

Let me check with them about granting my user these privileges

chillychin

Gianni - Thanks for the feedback

When running the RCU I actually tried ALL of the alternatives (System load, product load etc) and ALL of them gave me the same error message saying that I need SYSDBA/DBA privileges.

Which was why I was complaining in the first place, I tried to generate the scripts for the DBA to run but it still gave me an error that I need SYSDBA/DBA privileges.

And even a simple PRODUCT LOAD the error it gave was that I need to have SYSDBA/DBA privileges which made no sense!

Gianni Ceresa

Actually you are right

It's just the dumbest thing ever to run the RCU to generate the scripts for the DBA and being asked for a DBA connection. If you have the DBA connection why would you like to generate the code instead of running it?

Smell like a smart developer forgot a piece of logic here ...

Actually it must be a bug !

The "help" inside the RCU says:

Select Prepare Scripts for System Load if you are unable to provide login credentials for a user with DBA privileges.

chillychin

Either this is a bug - or the error message in this really needs to be updated with more details that you need to have privileges granted BEFORE you can run ANY option in the RCU

Thanks to @Gbenga Ajakaye for his notes to add these grants

• grant select_catalog_role to user;
• grant select any dictionary to user;
• grant create session to user;
• grant select on schema_version_registry to user;
• grant REGISTRYACCESS to user;

I asked our DBA to grant these privileges and they said that only 3 out of 5 of the above grants actually worked.

These 3 worked, and FINALLY let my user account get into the option for [PREPARE SCRIPTS]

• grant select_catalog_role to user;
• grant select any dictionary to user;
• grant create session to user;

Reading the provided documentation, at this point my DBA gets the following error for these two privileges

• grant select on schema_version_registry to user;
• grant REGISTRYACCESS to user;

ORA-01919: role 'REGISTRYACCESS' does not exist

ORA-00942: table or view does not exist

Im guessing that these two probably need to be granted AFTER my DBA runs the scripts I prepare for them.

Will continue to update this thread as I go through the steps.

But for anyone reading so far

Once you get to the step in the RCU to prepare scripts you must grant at least the 3 privileges I noted above in order to even be able to prepare scripts for my DBA to run.

Gbenga Ajakaye

Yes. After performing the system load, your dba can grant the REGISTRYACCESS in order for you to perform data load

chillychin

So I discovered something else with the RCU tool.....

After my DBA granted me the required privileges to even be able to "Prepare the scripts" the scripts have their own issues.

There were two scripts generated

1) script_systemLoad.sql

2) script_postDataLoad.sql

A few of the issues my DBA and I were able to resolve but the biggest issue was that there seems to be a whole chunk of script missing.

I had selected to have all the components in the RCU tool to be installed, to be on the safe side.

When my DBA tried to run the second script_postDataLoad.sql, they got errors noting that the tables did not exist.

It looks like the schemas for IAU Audit Services are completely empty.

I know that there are SUPPOSED to be things in the schemas, but the script is NOT generating what needs to be in these schemas.

Im going to ask my DBA to now try and run the RCU tool while I am there now, and am also going to try and create a ticket to Oracle about this.

This option they provided is creating a lot more pain then good