Install JDK

Since Fusion middleware is based on Java, all the installers included in the media require JDK to be installed on the host machine. Although we have seen in previous step of Installing Fusion Applications provisioning wizard that we can also use the JDK directory included in the installation repository, we must have a permanent Java home location on the host. Since the JDK version included with current release of Fusion Applications is JDK 6, we will install it there.

Although we can get the JDK installer from the Oracle web site as well, in this case we only need to unzip the JDK ZIP file to any desired location. The compressed JDK 6 file (jdk6.zip) is included at <REPOSITORY_LOCATION>/installers/jdk. In this example, we will unzip it to our provisioning installer root directory /app/fusion, but you can select any location.

[fusion@fadbhost ∼]$ cd /app/fusion/

[fusion@fadbhost fusion]$ unzip /stage/installers/jdk/jdk6.zip

This will create a directory named jdk6 at the selected location. In this example, it will be /app/fusion/jdk6. We will specify this directory as Java home in any further installations on this host. Most of the installers can detect the Java home if it is created in the Oracle Base directory.

Installing Fusion Applications Transaction Database

Since we are going with option 1 of the database installation options mentioned previously, we will invoke the Fusion Applications provisioning wizard in order to install the Oracle Database. To install the Applications Transactional database, we need to run Oracle Fusion Applications provisioning wizard from <framework_location>/provisioning/bin.

<framework_location> refers to the location where we installed the Fusion Applications provisioning framework in previous step; for example, /app/fusion.

[fusion@fadbhost ∼]$ cd /app/fusion/provisioning/bin/

[fusion@fadbhost bin]$ export JAVA_HOME=/app/fusion/jdk6

[fusion@fadbhost bin]$ ./provisioningWizard.sh &

The Welcome screen is an informal screen that suggests you check the following two prerequisites.

• The Fusion Applications installation repository (installation stage directory) has been created. We have already done this as part of the earlier steps.

• The installation repository has been populated with the Oracle database installer and required patches. This is also taken care of since we have extracted all required ZIP files into the installation repository, which also includes the database related directories. This is required because the database-creation option will internally invoke the installer from the database directory of the installation repository.

Once you have confirmed that the required prerequisite steps are complete, click Next to proceed to the wizard option selection screen shown in Figure 8-9.

Figure 8-9. Wizard option selection screen

The provisioning option selection screen provides six provisioning-related options.

1. Install an Applications Transaction database.

2. Create a New Applications Environment provisioning response file.

3. Create a response file for extending an existing Fusion Applications environment (available on Fusion Applications 11.1.9 onward).

4. Update an existing Provisioning response file.

5. Provision an Applications environment.

6. Uninstall an Applications environment.

Out of these, only the first option is related to the database, while the other five options are specific to Applications provisioning. We will discuss about the remaining options in next chapter. This option will initiate a short questionnaire for database installation details only. Since most of the database parameters are preselected in the template, they will not be prompted during this wizard.

Select Install an Applications Transactional Database and click Next to proceed to the Security Updates screen. We have already seen this screen where you can optionally enter your email address or Oracle Support credentials to receive updates related to the selected product. Enter the email address or leave the field empty and click Next to proceed to the Database Install Configuration screen, as shown in Figure 8-10.

Figure 8-10. Fusion Applications Database Install Configuration screen

Note that the screen shown in Figure 8-10 is the only screen with database installation related questionnaire unlike a typical database installation. So except for the following details, everything else remains as per the seeded template and is not modifiable at this stage. This screen prompts for the following values to be entered.

• Database Listener Port: The default value is 1521 and we can change it to any preferred value. We had changed the listener port to 1531 for the Identity Management database. In this example, we will keep it to 1521 in order to easily distinguish the databases in provisioning screens. Remember the value specified and enter the same value in the provisioning response file in the next steps.

• Installer’s Directory Location: Enter the location of the Fusion Applications installation repository here. Note that this is not the location of the database installation subdirectory, but the main installation staging directory. The installer will look for a subdirectory named installers in the specified directory. If the installers directory is not found in this location then an error will be displayed on the screen. In this case the directory is /stage.

• Oracle Base: Specify the directory that you want to create as the Oracle Software Base. The subsequent database directories including Oracle home will be created under this directory. You can specify any location that’s writable for the installation user. In this case, we have specified /app/database as the Oracle Base.

• Software Location: Specify the software location that will be same as the Oracle home directory. Once you have specified the Oracle Base value, this field will be automatically populated as <ORACLE_BASE>/product/11.2.0/dbhome_1. For example, /app/database/product/11.2.0/dbhome_1.

• Database File Location: Specify the location for the database files or data files. This location will default to <ORACLE_BASE>/oradata, but you can change it to any desired location on the same or different disk or storage location. In this case, it defaults to /app/database/oradata and is populated automatically so we will leave it unchanged.

• OSDBA group: This value defaults to dba for Unix platforms. In general, you need not change this value and should leave it untouched.

• Global Database Name: Specify the name of the database in <database_name>.<domainname> or <database_name> format, which will also be the default SERVICE_NAME of this new database. For example, fusiondb or fusiondb.paramlabs.com. Select any name of your choice or one based on your organization’s database naming policy. Make sure to provide the same name in any subsequent provisioning-related screens. We have selected fusiondb here.

• Password: Specify the password for all administrator users, including SYS, SYSTEM, SYSMAN, and so on. Make sure to select a complex password here. You can change these passwords after the database has been provisioned. This password will be required to be entered in Fusion Applications Provisioning response file creation as well.

Once all the required values are entered, click Next to proceed with the prerequisite checks, as shown in Figure 8-11.

Figure 8-11. Database installation prerequisite checks status

This screen will run all the required prerequisites, including hardware, operating system, and network, as well as determine the existence of inventory, inventory pointer files, and listener processes. The status of all the prerequisite checks, including any error or warning messages, will be displayed on the same screen between the BUILD_STARTED and BUILD_COMPLETE messages along with the warning or error symbol.

The Retry button is deactivated by default. If there are any errors in the prerequisites check, the Retry button will be activated. In case of warnings, the Retry button will not be activated but if you want to fix the warnings also then you can always click Back to run it again. In case of errors, you can fix the issues in a separate window and then click on the Retry button to rerun the prerequisite checks. Although warnings will not prevent you from continuing the installation, it is always advisable to make sure that there are no errors or warnings in this screen.

Once the prerequisites check is successful, click Next to proceed to the pre-installation summary screen, as shown in Figure 8-12.

Figure 8-12. Database pre-installation summary

Since this is the last screen before you start the database installation, make sure you check the summary details, including the installation path, global database name, listener port, and so on. If you want to modify any details then use the Back button to go back to previous screens. The Back button will be disabled after this screen. Save the pre-installation summary if required and then click Install to begin the database software installation along with the database instance creation.

Once database installation portion completes (at approximately 20% of the overall progress), the provisioning wizard will prompt you to execute the root configuration scripts as shown in Figure 8-13.

Figure 8-13. Root scripts execution prompt

This script will add the required entry in /etc/oratab and other configuration files. Open a new terminal window and run the script <ORACLE_HOME>/root.sh as the root user. The following is example output of the script execution.

[root@fadbhost ]# /app/database/product/11.2.0/dbhome_1/root.sh

Check /app/database/product/11.2.0/dbhome_1/install/root_fadbhost.paramlabs.com_2013-11-01_16-43-36.log for the output of root script

[root@fadbhost ]# more

/app/database/product/11.2.0/dbhome_1/install/root_fadbhost.paramlabs.com_201 3-11-0 1_1 6-43-3 6.log

Performing root user operation for Oracle 11g

The following environment variables are set as:

ORACLE_OWNER= fusion

ORACLE_HOME= /app/database/product/11.2.0/dbhome_1

Creating /etc/oratab file...

Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created

Finished running generic part of root script.

Now product-specific root actions will be performed.

Finished product-specific root actions.

Click OK

Once the script is executed, click OK to continue with the next phases of the overall database installation, as shown in Figure 8-14.

Figure 8-14. Database installation and configuration progress

The Database Installation Progress screen shows the following phases for this task.

• Install: During this phase the database software gets installed with the base release only. The database or instance is not yet created and the database patches or PSU are not applied yet.

• Preconfigure : During the Preconfigure phase the Tech Patch Utility (TPU) and Oracle Configuration Manager (OCM, which is used to upload configuration details to Oracle Support) are configured. All the patches and PSU located in <REPOSITORY_LOCATION>/installers/database/psu and <REPOSITORY_LOCATION>/installers/database/patch are applied to the database home as well. At this moment the database is not created so a database metadata upgrade is not required at this stage.

• Configure: During this phase the database instance, service, and listener are created and configured. It creates the database using a seeded template and sets the necessary parameters. The network configuration files are also created at this stage.

• PostConfigure: At this stage any necessary post patch steps and post-configuration steps are performed. The database is technically installed and ready at this stage.

• Startup: Although the required services are already started by now, this stage makes sure that any components that are not yet started should be started now.

• Validation: This phase performs the database validation for completeness of the installation and runs the validation SQL for checking connectivity and integrity of the database.

After collapsing the status tree, the screen will look like the one shown in Figure 8-15. Its shows a short summary of your overall progress. You may see tick mark (√), an error sign(x), a warning sign (!), or a clock icon (for an ongoing phase), depending on the status of the activity. Once installation until validation is complete, click Next to proceed to the installation summary, as shown in Figure 8-16.

Figure 8-15. Successful completion of each phase

Figure 8-16. Fusion Applications Transaction database post-installation summary

In the summary screen you can see the URL of the configured Fusion Applications Database Enterprise Manager. Make a note of this URL or save the summary for documentation purposes. Click Close to complete the installation and close the wizard.

Running Fusion Applications Repository Creation Utility

After the blank database has been installed, you must create the repository for Fusion Applications components in this database. The RCU performs the following actions on the database.

1. Create empty tablespaces for the Fusion Applications components and schemas.

2. Create required schema owners and populate the required database objects, including tables, views, and so on. Fusion Applications RCU includes both Fusion middleware components as well as Fusion Applications Runtime schema owners.

3. Import the seed data for BI and Fusion Applications schemas using the Oracle Data pump export files included in the RCU.

Fusion Applications installer comes with RCU included in the media. Note that Fusion Applications RCU is available only for Windows and Linux platforms with 64-bit architecture. So if you are hosting your database on Windows 64-bit or Linux x86-64 then you can run the RCU from the database host. But if you have selected a non-Windows and a non-Linux host, you need a remote Windows or Linux machine that can connect to this database from where you can run the RCU and seed the data into the Fusion Applications database. Make sure you have consistent connectivity to the Fusion Applications database from the remote host throughout the RCU process. You may need to open the database port in a firewall if you are running the remote machine from a different network VLAN.

Figure 8-17 shows the two options available to run the RCU—one for Windows/Linux hosts and the later for database hosts with other operating systems. As you can see in the first option, you simply need to unzip the RCU from installation repository to the database host and run it locally. With the second option, we have introduced another host to run the RCU remotely.

Figure 8-17. RCU host and DB host for Windows/Linux versus other operating systems

As you can see, there are two RCU ZIP files available along with Fusion Applications installation repository, under the folder names windows and linux. Since we have selected 64-bit Oracle Linux host for database, we will go ahead with Linux RCU here.

For Linux, the RCU is located at <REPOSITORY_LOCATION>/installers/apps_rcu/linux with the rcuHome_fusionapps_linux.zip filename. We need to unzip this directory in any local location on database server or the remote machine from where we are going to run the RCU. Let’s create a directory on the database server’s local disk. For example, /app/fusion/provisioning/apps_rcu.

[fusion@fadbhost dbs]$ mkdir /app/fusion/provisioning/apps_rcu

The reason we have created the apps_rcu directory under the existing provisioning directory is just to keep the installation-related directories in one location. We will call this location APPS_RCU_HOME.

Now we will extract the compressed RCU file to this location. This will create the Repository Creation Utilities as well as the dump files that the utilities will import to the database. Let’s unzip the file <REPOSITORY_LOCATION>/installers/apps_rcu/linux/rcuHome_fusionapps_linux.zip to APPS_RCU_HOME directory. All dependent components that the Fusion Applications RCU requires are included in this ZIP file.

[fusion@fadbhost dbs]$ cd /app/fusion/provisioning/apps_rcu

[fusion@fadbhost apps_rcu]$ unzip /stage/installers/apps_rcu/linux/rcuHome_fusionapps_linux.zip

Create a temporary directory on the database server. We will extract the data pump export dump files in this directory. Note that regardless of whether you are running RCU from a database host or remote machine, this directory must be created on a database host only since data pump always reads from and writes to the database host itself. Make a note of the location as we will need to enter this location in the next screen when we are required to specify a value for FUSIONAPPS_DBINSTALL_DP_DIR.

[fusion@fadbhost apps_rcu]$ mkdir /app/fusion/provisioning/apps_rcu/dp_dir

The required data pump dump files are located in the newly created RCU directory under location APPS_RCU_HOME/rcu/integration/fusionapps/export_fusionapps_dbinstall.zip. We will extract the contents of this ZIP file to the temporary directory we just created (FUSIONAPPS_DBINSTALL_DP_DIR).

[fusion@fadbhost apps_rcu]$ cd /app/fusion/provisioning/apps_rcu/dp_dir

[fusion@fadbhost dp_dir]$ unzip /app/fusion/provisioning/apps_rcu/rcu/integration/fusionapps/export_fusionapps_dbinstall.zip

Archive: /app/fusion/provisioning/apps_rcu/rcu/integration/fusionapps/export_fusionapps_dbinstall.zip

inflating: fusionapps_dbinstall_latest_06.dmp

inflating: fusionapps_dbinstall_latest_02.dmp

inflating: fusionapps_dbinstall_latest_07.dmp

inflating: fusionapps_dbinstall_latest_04.dmp

inflating: fusionapps_dbinstall_latest_03.dmp

inflating: fusionapps_dbinstall_latest_01.dmp

inflating: fusionapps_dbinstall_latest_05.dmp

inflating: fusionapps_dbinstall_latest_08.dmp

There is another export dump file named otbi.dmp at APPS_RCU_HOME/rcu/integration/biapps/schema location. In order to keep all the export dump files in one location, we will copy this file to the temporary data pump dump directory called FUSIONAPPS_DBINSTALL_DP_DIR.

[fusion@fadbhost ]$ cd /app/fusion/provisioning/apps_rcu/dp_dir

[fusion@fadbhost dp_dir]$ cp -p /app/fusion/provisioning/apps_rcu/rcu/integration/biapps/schema/otbi.dmp .

Now since we have all the required data pump export dump files available locally, we can launch the Repository Creation Utility, which is located at the APPS_RCU_HOME/bin directory with a script name of rcu.

[fusion@fadbhost dp_dir]$ cd /app/fusion/provisioning/apps_rcu/bin

[fusion@fadbhost bin]$ ./rcu

The Welcome screen is informative only and provides information on the purpose of this utility. No action is necessary on this screen. Click Next to see repository creation options, as shown in Figure 8-18.

Figure 8-18. Currently available options in Fusion Applications RCU

As of the current release, Fusion Applications RCU provides only a Create option for the repository, unlike Identity Management RCU, which provides both Create and Drop options. This option allows us to create necessary database tablespaces, schemas, and objects, and then to seed default data in them.

Make sure that the database for which this RCU is being run does not have any of the existing components installed. You must run this RCU against a newly created blank Fusion Applications Transaction database only. Click Next to proceed to the DB Connection Details screen shown in Figure 8-19.

Figure 8-19. Fusion Applications Transaction Database Connection Details screen

This screen prompts for connection details for the database in which the repository needs to be created. The following information is required to be entered.

• Database Type: We must select Oracle Database here. Although RCU for some non-Applications components supports non-Oracle databases, our required components support Oracle Database only.

• Host Name: For a single-node database, enter the name of the host where we have installed the blank Fusion Applications database. In the case of a RAC database prior to 11gR2, we need to enter the names of the VIP or one of the node names. For 11gR2 and newer databases, enter the SCAN hostname. As this RCU is for Fusion Applications database, only 11gR2 onward is supported. In this case, it is a single-node database so we will enter fadbhost.paramlabs.com.

• Port: The default value for port is 1521. If you are using non-default port for the Fusion Applications database then enter the value which you have configured. In this case we have selected default port 1521.

• Service Name: In the case of a RAC database, enter the service name, while in the case of a single-node database, enter the SID value here. In this case, it is fusiondb.

• Username: Enter a username with SYSDBA privilege. We will enter SYS here.

• Password: Enter the password for the selected user.

• Role: We must select the SYSDBA role here for the SYS user.

Enter the appropriate details of the Fusion Apps database created in the previous step. Click Next to proceed to the prerequisites check, as shown in Figure 8-20.

Figure 8-20. RCU Prerequisites check status

You will now see a pop-up dialog box that shows the status of various prerequisites checks that will run against the database using the connection parameters specified in previous screen. If there were any errors in the previous screen while providing database connection details, you may see failure in validation here. Any errors in these checks will abort the prerequisites check and show the error details in the messages panel of main screen. Once the prerequisite check completes successfully, click OK to proceed to the Components Selection screen, as shown in Figure 8-21.

Figure 8-21. Repository components selection screen

Now you will see Fusion Applications RCU components selection screen. You will notice that unlike Identity Management RCU, we do not have a prefix selection option here. This is because, similar to Oracle E-Business Suite, Fusion Applications also has specific schema names for each of the components and this cannot be changed due to the architecture of most ERP products. You may see the names of each schema being created on the screen and all the names are grayed out to protect them from being changed. Also for Fusion Applications Provisioning, it is mandatory to select all the components included in the RCU regardless of the number of products you are planning to provision. You can collapse the tree nodes, as shown in Figure 8-22, to make sure that all the components are selected.

Figure 8-22. Summary view of selected components

Figure 8-22 shows a summary view of all selected components for your reference. You can see that the RCU includes both the Fusion Applications and Fusion middleware-related components that are required to be loaded in this database. Make sure that all components are selected and click Next to continue with the RCU.

Now the wizard will check the prerequisites for each of the components selected, in this case for all components since everything is selected. Any error will abort the prerequisite checks and you will be asked to fix the error before rerunning the prerequisites checks. Figure 8-23 shows you one possible error in the prerequisites check for Fusion Applications RCU.

Figure 8-23. Example failure condition in prerequisites check

As you can see, you do not see any error messages but only a checkmark in front of the component’s name. The message at the bottom suggests that an error has occurred. Once you click OK, you will be taken back to the previous screen. Now here you will see the actual error in the Messages panel at the bottom. Now in this particular example we are seeing following error, as shown in Figure 8-24.

Figure 8-24. Prerequisites check error message

RCU-6107:DB Init Param Prerequisite failure for: pga_aggregate_target

Current Value is 0. It should be greater than or equal to 4294967296.

RCU-6107:DB Init Param Prerequisite failure for: sga_target

Current Value is 0. It should be greater than or equal to 9663676416.

This specific error appears only if you had reduced SGA/PGA/memory size after the database installation to reduce the amount of memory required on a demo or proof-of-concept host. Or if you manually set the MEMORY_TARGET value instead of the SGA and PGA target values.

We have two ways to fix this issue.

• Option 1: Fix the SGA and PGA target values in the database to the suggested values as shown in Table 8-2. This is the only recommended option for production installations.

• Option 2: This is recommended only for demo installations, where you have don’t have the recommended memory allocated to the database. You can temporarily bypass this prerequisite check by manually modifying the RCU prerequisites XML file where the minimum expected values for SGA and PGA are specified. The file is located at APPS_RCU_HOME/rcu/integration/fusionapps/fusionapps.xml.

Make a backup of the existing file before modifying anything.

You can see following sections in this file that relate to the SGA and PGA size.

<DBPrerequisite COMPARE_OPERATOR="GE" DATA_TYPE="NUMBER" PREREQ_TYPE="InitParameter">

<ValidIf DBTYPE="ORACLE"/>

<PrereqIdentifier> sga_target </PrereqIdentifier>

<PrereqValue> 9663676416 </PrereqValue>

</DBPrerequisite>

...

<DBPrerequisite COMPARE_OPERATOR="GE" DATA_TYPE="NUMBER" PREREQ_TYPE="InitParameter">

<ValidIf DBTYPE="ORACLE"/>

<PrereqIdentifier> pga_aggregate_target </PrereqIdentifier>

<PrereqValue> 4294967296 </PrereqValue>

</DBPrerequisite>

Change the values to match with your existing setup. If you used MEMORY_TARGET and kept SGA/PGA values to 0 then you can set these minimum values to 0 as well to avoid prerequisites check error. Once again we want to remind you that this is not recommended option and should be used only if you have no other option to increase the memory size on the database.

Due to a bug in the current version of RCU, you may need to click Back twice and click Next in order to see the prerequisite checks with new values.

You may see each component prerequisites check status and timing information on the screen, as shown in Figure 8-25. Once the prerequisites check is successful, click OK to proceed to the Schema Passwords screen, as shown in Figure 8-26.

Figure 8-25. Successful prerequisites check

Figure 8-26. Specify passwords for schemas to be created

The Schema Passwords screen prompts for selecting the password for each repository schema to be created. It provides three options for password selection. The passwords must contain at least eight characters with a combination of alphanumeric characters and/or special characters.

• Same password for all schemas: This option assigns the same password to all the main and auxiliary schemas.

• Use main schema passwords for Auxiliary schemas: As you can see in the previous screen, the RCU creates main schemas based on the initially selected components and also creates corresponding auxiliary schemas for certain components. This option allows us to select passwords for main schemas and the related auxiliary schemas will be assigned same password as the main schema. The main schemas textbox remains enabled in this option,

• Specify different passwords for all schemas: This option enables all password textboxes and you can assign individual password for each schema as long as it confirms to the password complexity requirement.

For this example, I have selected the first option of selecting the same password for all schemas. Enter and confirm the password. Click Next to proceed to the Custom Variables screen, as shown in Figure 8-27.

Figure 8-27. Fusion Applications RCU Custom Variables screen

Before you enter the values in next screen, you may need to create certain directories which you will need to provide during the RCU and later. Open a new terminal window and create the following directories for custom environment variables.

[fusion@fadbhost ∼]$ mkdir /app/database/applcp

[fusion@fadbhost ∼]$ mkdir /app/database/appllog

[fusion@fadbhost ∼]$ mkdir /app/database/obieebkp

The Custom Variables screen requires you to input the following values. You need to click on the Value cell and paste or type in the required values. Note that due to the data grid size limitation, the text field may not show the complete value entered, but you can resize the wizard window to extend the cell width. You can also use the F2 function key to change the values in the field.

• Fusion Applications Custom Variables

  • Directory on database machine where the FA install dumps are located: Specify the directory where you have extracted the main data pump export dump files earlier. Note that even if you are running the RCU from a remote machine, the data pump directory must be created on database server only. In this case we extracted them at /app/fusion/provisioning/apps_rcu/dp_dir. Specify the same value here.

  • Directory for the APPLCP_FILE_DIR directory object: The first directory that we created for the APPLCP_FILE_DIR variable. For example, /app/database/applcp.

  • Directory for APPLLOG_DIR directory object: The second directory that we created for the APPLLOG_DIR variable. For example, /app/database/appllog.

  • Directory for OBIEE backup directory object: The third directory that we created for the OBIEE backup custom variable. For example, /app/database/obieebkp.

• Secure Enterprise Search

  • Do you have Advanced Compression Option (ACO) License? (Y/N): Default value is N (No). You can select the value appropriately. We will not change this at the moment.

  • Do you have Oracle Partitioning option License? (Y/N) : Default value is N (No). You can select the appropriate value. We will leave this unchanged at the moment.

• Master and Work Repository

  • Master repository ID (001) : The default value is 501. Leave this unchanged.

  • Supervisor password: Set up the password for the ODI supervisor here. Make a note of this password since you will need to enter it during Applications Provisioning response file creation.

  • Confirm supervisor password: Enter the same password as above.

  • Work repository type: Select the work repository type. The available options are (D) Development and (E) Execution. The default value is D and we will keep it the same.

  • Work Repository ID (001): The default value is 501. Leave this unchanged.

  • Work Repository Name (WORKREP): The default value is FUSIONAPPS_WREP. Leave this value unchanged.

  • Work Repository Password (Default None): Enter the same password as the ODI Supervisor here.

  • Confirm Work Repository Password: Confirm the same password as above.

• Oracle Transactional BI

  • Directory on the database server where OTBI import/export files are stored: We have extracted Business Intelligence Transactional BI export files in the same location as the main export data pump directory. You can specify a different directory as well but we suggest you keep the same data pump directory to avoid any confusion. We will enter /app/fusion/provisioning/apps_rcu/dp_dir again here.

• Activity Graph and Analytics

  • Install Analytics with Partitioning (Y/N): Default value is N (NO). We will leave this unchanged.

Once all these values are entered and verified, click Next to continue to the Map Tablespaces screen, as shown in Figure 8-28.

Figure 8-28. Map default and temporary tablespaces for schemas being provisioned

Now you will see the screen for mapping tablespaces for each component schema owner. This screen mainly shows four columns.

• Component : This column lists the RCU components selected under the Select Components screen you saw earlier.

• Schema Owner: This column lists the default schema owner for the specific component.

• Default Tablespace: This column lists the default tablespace for the specific schema’s objects. Note that the schema objects could also be stored in different tablespaces as well but the default one is specified here.

• Temp Tablespace: This column lists the default temporary tablespace for the given schema.

When you click the default or temporary tablespace name, you will see a list of the values to be selected. You could even select existing tablespaces. Any new tablespaces that are to be created will be prefixed with an asterisk (*) sign.

On the same screen you will see two more buttons—Additional Tablespaces and Manage Tablespaces. When you click Additional Tablespaces button, you will see the pop-up screen shown in Figure 8-29.

Figure 8-29. Specify Additional Tablespaces screen

The Specify Additional Tablespaces screen will show the additional tablespaces to be created for the selected components in addition to their existing default tablespaces. These tablespaces are required to store a specific type of additional objects for the selected components. None of these tablespaces exist in a blank Transactional database, hence all these tablespaces will be created in the further screens. In this screen, you can also select from a list of values but it’s better to leave these unchanged unless you have a specific reason to change the tablespace.

Table 8-3 shows each of the tablespaces created for Fusion Applications and the contents of the objects created in each. Note that not all of these tablespaces will have objects created during the RCU. We will look at this after the completion of RCU.

Now let’s look at the screen that pops up when we click the Manage Tablespaces button. This screen allows you to manage the tablespaces selected in the earlier two screens. We have seen two types of tablespaces—Default and Additional. For default tablespaces, we cannot change any values on the screen including tablespace name, type, block size or storage type, number of datafiles, or the name or size of datafiles, as shown in Figure 8-30.

Figure 8-30. Manage Tablespaces: Default Tablespace

When you select an additional tablespace, you will be allowed to change all configuration values of the tablespace, including adding or removing a new tablespace that can be selected for any component. Figure 8-31 shows an example of the Manage Tablespaces screen.

Figure 8-31. Manage Tablespaces: Additional Tablespace

Once you have reviewed the tablespaces and all related screens, click Next to continue creating the tablespaces. Note that the schemas will not be created now since the tablespaces are the prerequisites to create database schemas. The wizard will now prompt you for confirmation in order to create all new tablespaces, as shown in Figure 8-32.

Figure 8-32. Tablespaces creation confirmation prompt

This will create the new tablespaces while leaving the existing tablespaces untouched, even if their specification is not as per the default specification required by the RCU. Once you click OK, the tablespace creation will begin as shown in Figure 8-33.

Figure 8-33. Tablespaces creation progress

This pop-up screen will show you overall progress of all tablespaces instead of the individual ones. You can connect to the database or OS in different window to monitor the progress of the tablespaces creation if required. Once the tablespaces are created, click OK to proceed with the pre-repository creation summary, as shown in Figure 8-34.

Figure 8-34. Pre-Repository Creation Summary screen

The Pre-Repository Creation Summary screen lists the components selected, the schema owner, and the default, temporary, and additional tablespaces created for all the components in a consolidated view. If you want to change the tablespace mapping for any of the component schemas, you can click the Back button to go to the previous screen. Note that mapping existing tablespaces will not invoke the tablespace creation again if you select from the existing tablespaces only. Review the details and click Create to start creating the database schemas and related objects.

Now the RCU will start creating repository schemas and objects and then will load the seed data. The screen will display the progress of each component along with the timing information, as shown in Figure 8-35. This might take long time depending on the machine configuration. Note that this screen will close automatically and move to the next screen once the repository has been created.

Figure 8-35. Fusion Applications repository creation progress

You might wonder what exactly happens behind the scenes when the repository is being created. We have two important directories involved at this point. First, the data pump directory where we have extracted the export dump files and second, the directory named <APPS_RCU_HOME>/rcu/integration. This directory contains subdirectories for each of the components being loaded. The subdirectory for each component has a set of XML files along with SQL files that run on the database to create schema objects and load the data. If you remember, we extracted the dump file from this location only.

During repository creation, each of these SQLs runs and the logs are created at <APPS_RCU_HOME>/rcu/log/logdir.<timestamp>. You will see a different log file for each of the components. In case of any errors or for troubleshooting long-running tasks, you can review the log file for specific components in this directory.

During the repository creation, for Oracle BI and Fusion Applications components, it will invoke the data pump import jobs as well. The import log files will be created in the same location as the temporary data pump directory where you extracted the export dump files. You can also monitor the progress and any errors in these log files. The filename will be of the import_<timestamp>.log format. You can also check the name of the running jobs from the DBA_DATAPUMP_JOBS table in case you want to monitor the progress of the job by attaching to running data pump import job.

Once the repository is created, the screen will move to the final post-RCU summary screen, as shown in Figure 8-36.

Figure 8-36. Post-RCU summary screen

The final summary screen shows the status of each repository component created along with the log file name and the timing information for each component. The screen will also display the name of overall RCU log file and the location of component logs, where you can find the log files mentioned in the grid. It also displays the overall execution time needed to create the repository. The time can vary depending on the configuration of database and host. Review the summary and click Close to finish the Fusion Applications RCU.