Hyperion 11.2, WebLogic 12 & SYSDBA

Hyperion 11.2, WebLogic 12 & SYSDBA



With the use of WebLogic 12 in the Hyperion 11.2 environments we now have new database requirements that weren’t present in earlier versions. It’s necessary to be aware of these requirements and prepare for them, especially when making plans with your Oracle DBA.

WebLogic 12 uses multiple schemas for each server in the environment – NINE per server with WebLogic deployments to be exact. While the size of each is small, the number of them means you have to plan for them. Otherwise, it can be quite a surprise to the DBA.


Option 1 – SYSDBA Forever

The real problem for database security and management comes with the creation and management of these schemas. As with other tasks run by the RCU utility, an account with SYSDBA is required. However, per the Install & Configuration guide, this account with the SYDBA rights has be stored in a config file (it is encrypted) and keep the SYSDBA rights:


As you might expect, not many database administrators will be very happy with this requirement. The security and audit implications are a problem.


Option 2 – DBA Handoff

Fortunately, an alternative is made available in the Troubleshooting and Tips guide. The section is misleadingly titled “Creating the RCU schema on Oracle Database Without SYSDBA Rights”. SYSDBA rights are still required, but not by the user doing the configuration and not permanently.

The alternative process involves using DB user with lower rights and the RCU to generate the SQL scripts, then providing the scripts to the DBA to run with SYSDBA rights at specific times in the configuration process.

An account is still required permanently, but with lower rights. This resolves the long-term security issue, but as anybody who’s worked in a large organization knows, the handing off of scripts and then timing the execution at proper points during the configuration can cause hours, days and even sometimes weeks of delay in an implementation. This brings its own problems.


Option 3 – Temporary SYSDBA

An alternative to each of the above involves using an account with SYSDBA, then reducing the rights to that same account once the initial configuration steps are complete. This addresses the issue of a permanent SYSDBA without having to coordinate script executions with a DBA.

To accomplish this, the process is as follows:

1) Create a permanent account

a. Required permanent rights

i. select_catalog_role
ii. select any dictionary
iii. create session
iv. select on schema_version_registry


I created user WLNOTDBA and then granted SYSDBA rights:


2) Use this account to run the RCU per documentation for WL configuration:


3) Enter created account (currently with SYSDBA) and other required information into RCUSchema.properties:


4) Run initial configuration / deployment of Shared Services (this creates the PREFIX_WLS_RUNTIME schema, encrypts the passwords in the RCUSchema.properties file and finishes the WebLogic DB config tasks that require SYSDBA):



5) Repeat the RCU execution, RCUSchema.properties edit and first WebLogic deploy on each server that will be running WebLogic applications in the environment – EVERY WEBLOGIC SERVER must have a distinct prefix. At least one deployment must be complete on every server before continuing. The last of the schemas are created in the initial deployment, so SYSDBA is required for the first deployment on each server.


6) Now you can remove SYSDBA rights from the account:


7) Complete all other configuration tasks, including additional WebLogic deploy:


8) Verify initial start of services (remember that admin server MUST be running on first start of WebLogic servers) and proper behavior at login:




While there appears to be no way to avoid using an account with SYSDBA when initially configuring WebLogic, the security flags and risks can be reduced long-term using these steps.

I hope you found this useful, check back for more tip and tricks in the future.

Leave a Reply

  • Oracle EPM Cloud Update – Jan’22 (22.01)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Jan 8, 2022 (test environments) and on or after 2AM ET on Saturday, Jan 22, 2022 (production environments)

    January 7, 2022
  • Oracle EPM Cloud Update – Dec’21 (21.12)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Dec 3, 2021 (test environments) and on or after 2AM ET on Saturday, Dec 17, 2021 (production environments).

    December 2, 2021
  • Oracle EPM Cloud Update – Nov’21 (21.11)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Nov 5, 2021 (test environments) and on or after 2AM ET on Saturday, Nov 19, 2021 (production environments).

    November 3, 2021
  • Block Creation in Essbase – Part 2

    The previous post ended with a discussion on using DATACOPY to create blocks. I stated that it was my preferred method of making sure the right blocks were created for use. However, we may run into a situation requiring an “IF” test to determine when we create the blocks. In this situation, we cannot use DATACOPY as it is not syntactically valid inside an IF test.

    October 22, 2021