Preparing an Existing Database for an Enterprise Deployment

11 Preparing an Existing Database for an Enterprise Deployment

As part of preparing an existing database for an enterprise deployment, you should ensure that the database meets specific requirements. Other tasks include creating database services, using SecureFiles for large objects in the database, and creating database backup strategies. In a Kubernetes deployment, the database should reside outside of the cluster.

This chapter includes the following topics:

About Preparing the Database for an Enterprise Deployment
You have to configure a supported database as part of an Oracle Fusion Middleware enterprise deployment. Most Oracle Fusion Middleware products require a specific set of schemas that must be installed in a supported database. The schemas are installed by using the Oracle Fusion Middleware Repository Creation Utility (RCU).
About Database Requirements
Before you configure the enterprise deployment topology, you have to verify that the database meets the requirements described in the following sections.
Adding Database Options
Oracle Identity Management requires that Oracle JVM and Oracle Text is available in the database. By default, these options are not available in the database created.
Adding XA Views
Oracle Identity Governance requires the use of XA views.
Applying the Database Patches
Ensure that you apply all the necessary database patches. The patches are required only if you are using Oracle Identity Governance.
Creating a PDB Using an Existing PDB as a Template
When you create a database, an empty PDB is created at the same time. This example used the empty PDB to create a secondary PDB with the same configuration.
Creating Database Services
When multiple Oracle Fusion Middleware products are sharing the same database, each product should be configured to connect to a separate, dedicated database service. This service should be different from the default database service.
Preventing Password Timeouts for System Accounts
Using SecureFiles for Large Objects (LOBs) in an Oracle Database
SecureFiles is a new LOB storage architecture introduced in Oracle Database 11g Release 1. It is recommended to use SecureFiles for the Oracle Fusion Middleware schemas, in particular for the Oracle SOA Suite schemas.
About Database Backup Strategies
Performing a database backup at key points in the installation and configuration of an enterprise deployment enables you to recover quickly from any issue that might occur in the later configuration steps.

Parent topic: Preparing for an Enterprise Deployment

About Preparing the Database for an Enterprise Deployment

You have to configure a supported database as part of an Oracle Fusion Middleware enterprise deployment. Most Oracle Fusion Middleware products require a specific set of schemas that must be installed in a supported database. The schemas are installed by using the Oracle Fusion Middleware Repository Creation Utility (RCU).

In an enterprise deployment, Oracle recommends a highly available Real Application Clusters (Oracle RAC) database for the Oracle Fusion Middleware product schemas.

Parent topic: Preparing an Existing Database for an Enterprise Deployment

About Database Requirements

Before you configure the enterprise deployment topology, you have to verify that the database meets the requirements described in the following sections.

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Supported Database Versions

Use the following information to verify what databases are supported by each Oracle Fusion Middleware release and which version of the Oracle database you are currently running:

For a list of all certified databases, refer to Oracle Fusion Middleware Supported System Configurations.

To check the release of your database, query the PRODUCT_COMPONENT_VERSION view:

SQL> SELECT VERSION FROM SYS.PRODUCT_COMPONENT_VERSION WHERE 
         PRODUCT LIKE 'Oracle%';

Oracle Fusion Middleware requires that the database supports the AL32UTF8 character set. Check the database documentation for information on choosing a character set for the database.

For enterprise deployments, Oracle recommends that you use GridLink data sources to connect to Oracle RAC databases.

Note:

For more information about using GridLink data sources and SCAN, see Using Active GridLink Data Sources in Administering JDBC Data Sources for Oracle WebLogic Server.

Use of Active GridLink has specific licensing requirements, including a valid WebLogic Suite license. See Oracle WebLogic Server data sheet.

Parent topic: About Database Requirements

Additional Database Software Requirements

In the enterprise topology, there are two database host computers in the data tier that host the two instances of the RAC database. These hosts are referred to as DBHOST1 and DBHOST2.

Before you install or configure the enterprise topology, you must ensure that the following software is installed and available on DBHOST1 and DBHOST2:

Oracle Clusterware

See Installing Oracle Grid Infrastructure for a Cluster in Oracle Grid Infrastructure Installation Guide for Linux.
Oracle Real Application Clusters

See Installing Oracle RAC and Oracle RAC One Node in Oracle Real Application Clusters Installation Guide for Linux and UNIX.
Time synchronization between Oracle RAC database instances

The clocks of the database instances must be in sync if they are used by servers in a Fusion Middleware cluster configured with server migration.
Automatic Storage Management (optional)

See Introducing Oracle Automatic Storage Management in Oracle Automatic Storage Management Administrator's Guide.

General Database Characteristics

Character Set – The character set must be unicode compliant. For example: AL32UTF8.
Database Options – The following database options must be installed into the database:
- Oracle JVM
- Oracle Text
Database Views – The following database view must be created on the database:
- XAVIEWS
Database Packages – The following database package must exist in the database:
- DBMS_SHARED_POOL

Parent topic: About Database Requirements

Databases Required

For Oracle Identity and Access Management, a number of separate databases are recommended. Table 11-1 provides a summary of these databases. Which database or databases you use depends on the topology that you are implementing.

For this release of Oracle Identity and Access Management, you must use a separate RCU schema prefix for each domain. This allows different products to use a the same or different databases if required.

If you are planning on creating a Multi-Datacenter, you should use separate databases for Access and Governance. This allows different replication mechanisms to be used for each.

Oracle Identity and Access Management fully supports the use of Container (PDB) databases. If you utilize the same disaster recovery strategy for all components, for example, Active/Passive then, utilizing a single container database provides many benefits.

However, if you are using a hybrid disaster recovery strategy and Oracle Access Manager is using Active/Active multi-data center while everything else is using the Active/Passive strategy, then the Access Manager database must be a separate database from the others because you can use Oracle Data Guard only at the container database level.

Table 11-1 Mapping between Databases and Schemas for an Active/Passive Disaster Recovery Strategy

Container Database	PDB Name	Database Hosts	Scan Address	Service Name	RCU Prefix	Schemas in Database
IAMDB	IADPDB	DBHOST1 DBHOST2	`DBSCAN`	`iadedg.example.com`	EDGIAD	OAM, IAU, MDS, OPSS
IAMDB	IGDPDB	DBHOST1 DBHOST2	`DBSCAN`	`igdedg.example.com`	EDGIGD	OIM, SOAINFRA, MDS, OPSS, ORASDPM, BI, ODS
IAMDB	OAAPDB	DBHOST1 DBHOST2	`DBSCAN`	`oaaedg.example.com`	EDGOAA	OAA
OIRIDB		DBHOST1 DBHOST2	`DBSCAN`	`oiriedg.example.com`	EDGOIRI	OIRI DING

Table 11-2 Mapping between Databases and Schemas for a Hybrid Disaster Recovery Solution

Container Database	PDB Name	Database Hosts	Scan Address	Service Name	RCU Prefix	Schemas in Database
IAMDB1	IADPDB	DBHOST1 DBHOST2	`DBSCAN`	`iadedg.example.com`	EDGIAD	OAM, IAU, MDS, OPSS
IAMDB2	IGDPDB	DBHOST1 DBHOST2	`DBSCAN`	`igdedg.example.com`	EDGIGD	OIM, SOAINFRA, MDS, OPSS, ORASDPM, BI, ODS
IAMDB2	OAAPDB	DBHOST1 DBHOST2	`DBSCAN`	`oaaedg.example.com`	EDGOAA	OAA
OIRIDB		DBHOST1 DBHOST2	`DBSCAN`	`oiriedg.example.com`	EDGOIRI	OIRI DING

Note:

In this scenario, OAAPDB is shown as a separate PDB but it could be placed into IGDPDB, if desired.

Parent topic: About Database Requirements

Minimum Initialization Parameters

The databases must have the following minimum initialization parameters defined:

Table 11-3 Minimum Initialization Parameters for Oracle Databases

Parameter	Development	Small System	Medium System	Large System
`aq_tm_processes`	`1`	`1`	`1`	`1`
`dml_locks`	`200`	`200`	`200`	`200`
`job_queue_processes`	`12`	`12`	`12`	`12`
`open_cursors`	`1600`	`1600`	`1600`	`1600`
`session_max_open_files`	`50`	`50`	`50`	`50`
`sessions`	`4000`	`4000`	`4000`	`4000`
`processes`	`5000`	`5000`	`5000`	`5000`
`sga_target`	`5G`	`28G`	`58G`	`118G`
`pga_aggregate_target`	`2G`	`7G`	`14G`	`29G`
`pga_aggregate_limit`	`0`	`0`	`0`	`0`
`sga_max_size`	`5 G`	`28 G`	`58 G`	`118 G`
`session_cached_cursors`	`1000`	`1000`	`1000`	`1000`
`db_keep_cache_size`	`0`	`800M`	`800M`	`800M`
`cursor_sharing`	`FORCE`	`FORCE`	`FORCE`	`FORCE`
`query_rewrite_integrity`	`TRUSTED`	`TRUSTED`	`TRUSTED`	`TRUSTED`
`query_rewrite_enabled`	`TRUE`	`TRUE`	`TRUE`	`TRUE`
`max_dispatchers`	`0`	`0`	`0`	`0`
`max_shared_servers`	`0`	`0`	`0`	`0`
`disk_asynch_io`	`NATIVE`	`FALSE`	`FALSE`	`FALSE`
`db_securefile`	`TRUE`	`ALWAYS`	`ALWAYS`	`ALWAYS`
`plsql_code_type`	`NATIVE`	`NATIVE`	`NATIVE`	`NATIVE`
`_active_session_legacy_behavior`	`TRUE`	`TRUE`	`TRUE`	`TRUE`

Table 11-4 Additional Requirements for OIG Deployments

Parameter	Development	Small System	Medium System	Large System
`sessions`	`5000`	`5000`	`5000`	`5000`
`open_cursors`	`3000`	`3000`	`3000`	`3000`
`processors`	`5000`	`5000`	`5000`	`5000`
`aq_tm_processes`	`10`	`10`	`10`	`10`
`open_links`	`20`	`20`	`20`	`20`
`nls_sort`	`BINARY`	`BINARY`	`BINARY`	`BINARY`
`shared_servers`	`0`	`0`	`0`	`0`

Oracle recommends you to set these parameters in the database configuration assistant when creating the database. If not, you can adjust them after creating the database, by using the alter system database command. For example:

sqlplus / as sysdba
alter system set aq_tm_processes=1 scope=spfile;

For _parameters, use the syntax:

alter system set "_active_session_legacy_behavior"=true scope=spfile;

After making changes in the spfile, restart the database. For example

srvctl stop database -d iamdb
srvctl start database -d iamdb

Note:

For guidelines on setting up optimum parameters for the database, see Tuning Database Parameters in Tuning Performance.

Parent topic: About Database Requirements

Adding Database Options

Oracle Identity Management requires that Oracle JVM and Oracle Text is available in the database. By default, these options are not available in the database created.

To add these options later, run the following command from db node 1:

dbca -silent -configureDatabase -sourceDB iamdb_iad18h -addDBOption JSERVER,ORACLE_TEXT

Where the database name is the name of the database you created earlier. See Creating the Database.

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Adding XA Views

Oracle Identity Governance requires the use of XA views.

To install these into the database, run the following command:

sqlplus / as sysdba @$ORACLE_HOME/rdbms/admin/xaview.sql

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Applying the Database Patches

Ensure that you apply all the necessary database patches. The patches are required only if you are using Oracle Identity Governance.

Include the database patches from Oracle Text Mandatory Patches.

Also, ensure that you include the latest patch set bundles for the release of database that you are using.

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Creating a PDB Using an Existing PDB as a Template

When you create a database, an empty PDB is created at the same time. This example used the empty PDB to create a secondary PDB with the same configuration.

This example shows the commands used to create a secondary PDB by using the empty PDB. The new database is called OIG and the existing one is called OAM:

sqlplus / as sysdba

Note:

You may need to set ORACLE_HOME and ORACLE_SID to the database you just created to ensure that you are connecting to the correct database, especially if you have more than one database in the compartment. Creating a Database.

create pluggable database IGDPDB from IADPDB keystore identified by syspassword;

Note:

'syspassword' is the database sys password.

Pluggable database created.

show pdbs;


CON_ID     CON_NAME      OPEN MODE      RESTRICTED
-------   ----------     ----------     -----------
 2         PDB$SEED      READ ONLY      NO
 3         IADPDB        READ WRITE     NO
 5         IGDPDB        MOUNTED

alter pluggable database IGDPDB open read write;

Pluggable database altered.

show pdbs;


CON_ID     CON_NAME        OPEN MODE      RESTRICTED
-------   ----------       ----------     ----------
  2        PDB$SEED        READ ONLY      NO
  3        IADPDB          READ WRITE     NO
  5        IGDPDB          READ WRITE     NO

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Creating Database Services

When multiple Oracle Fusion Middleware products are sharing the same database, each product should be configured to connect to a separate, dedicated database service. This service should be different from the default database service.

A different service name enables you to create role-based database services for Disaster Recovery and Multi-Datacenter topologies.

Note:

The instructions in this section are for the Oracle Database 12c (12.1) release. If you are using another supported database, refer to the appropriate documentation library for more up-to-date and release-specific information.

Beginning with Data Guard 11g Release 2, you can automatically control the startup of database services on primary and standby database by assigning a database role to each service. This service is in addition to the default service created when the database was commissioned. A role based database service will automatically start upon database startup if the management policy of the service is AUTOMATIC and if one of the roles assigned to that service matches the current role of the database; for example, if the database is running as a primary.

Creating a database service in this way means that, the service is started whenever the database with the role primary is started. The service will move between sites as the underlying databases roles are moved through switchover or failover.

If you are planning to use a standard disaster recovery solution as described in Disaster Recovery Guide, then each database service should be defined as a Role Based Database service.

If you are planning on using a multi-datacenter deployment, then the database service created for the Oracle Identity Governance (IGDDB) database should be a role based service.

For more information about connecting to Oracle databases using services, see Overview of Using Dynamic Database Services to Connect to Oracle Databases in Real Application Clusters Administration and Deployment Guide.

In addition, the database service should be different from the default database service. For complete instructions on creating and managing database services for an Oracle Database 12c database, see Overview of Automatic Workload Management with Dynamic Database Services in Real Application Clusters Administration and Deployment Guide.

Runtime connection load balancing requires configuring Oracle RAC Load Balancing Advisory with service-level goals for each service for which load balancing is enabled.

You can configure the Oracle RAC Load Balancing Advisory for SERVICE_TIME or THROUGHPUT. Set the connection load-balancing goal to SHORT.

You create and modify Oracle Database services by using the srvctl utility.

To create and modify a database service:

Add the service to the database and assign it to the instances by using srvctl:
```
srvctl add service -db iamdb1 -service iadedg.example.com -preferred iamdb11, iamdb12 
```
If you use PDB, change the command to the following:
```
srvctl add service -db iamdb1 -pdb iadpdb -service iadedg.example.com -preferred iamdb11, iamdb12 
```
Note:
For the Service Name of the Oracle RAC database, use lowercase letters, followed by the domain name. For example: iadedg.example.com.
If you want to use Oracle Data Guard for disaster protection, then you need to ensure that the database service is started only when the database has a primary role. To do this step, modify the service you created in Step 1 using the following commands:
```
srvctl add service -db iamdb1 -service iadedg.example.com -preferred iabdb11,iamdb12 -pdb iadpdb -role "PRIMARY,SNAPSHOT_STANDBY"
```
```
srvctl modify service -db iamdb1 -service iadedg.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
```
Verify that the service is setup correctly using the command:
```
srvctl config service -db iamdb1 -service iadedg.example.com
```
Start the service:
```
srvctl start service –db iamdb1 –service iadedg.example.com
```
Note:
For complete instructions on creating and managing database services with SRVCTL, see Creating Services with SRVCTL in the Real Application Clusters Administration and Deployment Guide.
Modify the service so that it uses the Load Balancing Advisory and the appropriate service-level goals for runtime connection load balancing.
Use the following resources in the Oracle Database 12c Real Application Clusters Administration and Deployment Guide to set the SERVICE_TIME and THROUGHPUT service-level goals:
- Overview of the Load Balancing Advisory
- Configuring Your Environment to Use the Load Balancing Advisory
For example:
Check the default configuration of the service by using this command:
```
srvctl config service -db iamdb1 -service iadedg.example.com
```
Several parameters are shown. Check the following parameters:
- Connection Load Balancing Goal: Long
- Runtime Load Balancing Goal: NONE
You can modify these parameters by using the following command:
```
srvctl modify service -db iamdb1 -service iadedg.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
```

Restart the service:

srvctl stop service -db iamdb1 -service iadedg.example.com
srvctl start service -db iamdb1 -service iadedg.example.com

Verify the change in the configuration:

srvctl config service -db iamdb1 -service iadedg.example.com

Runtime Load Balancing Goal: SERVICE_TIME
  Service name: iadedg.example.com
  Service is enabled
  Server pool: iamdb1_iadedg.example.com
  ...
  Connection Load Balancing Goal: SHORT
  Runtime Load Balancing Goal: SERVICE_TIME
  ...

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Preventing Password Timeouts for System Accounts

When Oracle Fusion Middleware products are installed several database schemas are created. These database schemas are associated with the Default password profile, which forces passwords to be changed at periodic intervals, otherwise they are locked out pending the password being changed and the account unlocked. This behaviour may be undesirable for system accounts, as the locking of a system account may result in interrupted service.

It is possible to create a password policy which ages out system passwords on a different schedule to regular database users. Creating a password policy which does not age system accounts should be used with care. It is still a good practice to ensure that system passwords are changed on a periodic basis.

Creating a Password Policy for System Accounts

To create a password policy, run the following command in sqlplus:

CREATE PROFILE SYSTEM_PASSWORD_PROFILE LIMIT PASSWORD_LIFE_TIME <DAYS BEFORE EXPIRY>

Note:

If creating the profile in a container database the profile name must be preceded by c## (this is not the case if created at the PDB level). For example:

CREATE PROFILE C##SYSTEM_PASSWORD_PROFILE LIMIT PASSWORD_LIFE_TIME 360;

To prevent password from never expiring the following profile can be used.

CREATE PROFILE SYSTEM_PASSWORD_PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED;

Assigning Users to the System Password Policy

To assign a user to the System Password Profile issue the following command in sqlplus:

ALTER USER <username> SYSTEM_PASSWORD_PROFILE;

Parent topic: Preparing an Existing Database for an Enterprise Deployment

Using SecureFiles for Large Objects (LOBs) in an Oracle Database

SecureFiles is a new LOB storage architecture introduced in Oracle Database 11g Release 1. It is recommended to use SecureFiles for the Oracle Fusion Middleware schemas, in particular for the Oracle SOA Suite schemas.

Beginning with Oracle Database 11g Release 1, Oracle introduced SecureFiles, a new LOB storage architecture. Oracle recommends that you use SecureFiles for the Oracle Fusion Middleware schemas, in particular for the Oracle SOA Suite schemas. See Using Oracle SecureFiles LOBs in the Oracle Database SecureFiles and Large Objects Developer's Guide.

In Oracle 12c Databases, the default setting for using SecureFiles is PREFERRED . This means that the database attempts to create a SecureFiles LOB unless a BasicFiles LOB is explicitly specified for the LOB or the parent LOB (if the LOB is in a partition or sub-partition). The Oracle Fusion Middleware schemas do not explicitly specify BasicFiles, which means that Oracle Fusion Middleware LOBs defaults to SecureFiles when installed in an Oracle 12c database.

For Oracle 11g databases, the db_securefile system parameter controls the SecureFiles usage policy. This parameter can be modified dynamically. The following options can be used for using SecureFiles:

PERMITTED: Allows SecureFiles to be created (This is the default setting for db_securefile. The default storage method uses BasicFiles).
FORCE: Creates all (new) LOBs as SecureFiles.
ALWAYS: Tries to create LOBs as SecureFiles, but falls back to BasicFiles if not possible (if ASSM is disabled).

Other values for the db_securefile parameter are:

IGNORE: Ignore attempts to create SecureFiles.
NEVER: Disallow new SecureFiles creations.

For Oracle 11g Databases, Oracle recommends that you set the db_securefile parameter to FORCE before you create the Oracle Fusion Middleware schemas with the Repository Creation Utility (RCU).

Note that the SecureFiles segments require tablespaces managed with automatic segment space management (ASSM). This means that LOB creation on SecureFiles will fail if ASSM is not enabled. However, the Oracle Fusion Middleware tablespaces are created by default with ASSM enabled. As a result, with the default configuration, nothing needs to be changed to enable SecureFiles for the Oracle Fusion Middleware schemas.

Parent topic: Preparing an Existing Database for an Enterprise Deployment

About Database Backup Strategies

Performing a database backup at key points in the installation and configuration of an enterprise deployment enables you to recover quickly from any issue that might occur in the later configuration steps.

At key points in the installation and configuration of an enterprise deployment, this guide recommends that you back up your current environment. For example, after you install the product software and create the schemas for a particular Oracle Fusion Middleware product, you should perform a database backup. Performing a backup allows you to perform a quick recovery from any issue that might occur in the later configuration steps.

You can choose to use your own backup strategy for the database, or you can simply make a backup by using operating system tools or RMAN for this purpose.

Oracle recommends that you use Oracle Recovery Manager for the database, particularly if the database was created using Oracle Automatic Storage Management. If possible, you can also perform a cold backup by using operating system tools such as tar.

Parent topic: Preparing an Existing Database for an Enterprise Deployment