Monday, January 27, 2020

Oracle E-Business Suite Release 12.2: Backup and Recovery Guidelines For Online Patching (adop) Cutover (Doc ID 1584097.1)

This document describes how you can, if required, restore an Oracle E-Business Suite Release 12.2 system to the state it was in before an Online Patching cutover phase was run. It is only intended for use in specific scenarios where cutover has failed for some reason.
Note: This document supplements the main Online Patching documentation, which is primarily provided in Oracle E-Business Suite Concepts and Oracle E-Business Suite Maintenance Guide. Both these books are available as part of the Release 12.2 Documentation Library.

In This Document

  1. Prerequisites and Restrictions
  2. Setting Up Flashback
  3. Problem Scenario
  4. Flashing Back the Database
  5. Restoring the File Systems
  6. References
  7. Change Record
  8. Documentation Notices

1. Prerequisites and Restrictions

Oracle E-Business Suite Release 12.2 supports Online Patching, which allows patches to be applied to a copy of the system while users are working on the existing system. The Online Patching cycle consists of several phases, with the critical phase where the changes are committed being called cutover. Up to this phase, you can run a special phase called abort, which will undo the changes made so far in the patching cycle. After cutover is complete, however, you cannot do this.
Note: The procedure described in this document is only intended for use in the event of a failed cutover, and as a last resort. It is not supported for use as a rollback (restoration) option after a successful cutover.
If a cutover error occurs, you should first check the error message and try to determine if the problem can be fixed easily, or (as is true in many cases) cutover can be made to succeed simply by running the command again. Restoring to a point before cutover via Flashback recovery should only be done when the error cannot easily be fixed, and continues to fail on subsequent cutover attempts.
So, before proceeding further with the instructions in this document:
  1. Review failure messages and cutover logs, identify problems, and make corrections as applicable. Issues such as running out of disk space can be corrected easily, whilst issues such as timeouts, deadlocks, and network issues may prove to be transient.
  2. Retry the cutover command.
  3. If cutover still fails, follow the instructions in the rest of this document to restore system availability while you take further diagnostic and corrective actions.
If after cutover you want to revert to the state of the system before the patching cycle was started, you can use the Oracle Database Flashback feature to go back to a designated point in time (a restore point). You should create the restore point just before running the cutover phase.
Note: Before creating the restore point, it is advisable to issue a suitable downtime notification and shut down the web services. This will ensure you do not lose any transactional data, and in effect simply extends slightly the cutover downtime.
Depending on exactly when the failure occurred, you may also need to restore the application tier file systems.
Note: The following prequisites must be met before you proceed with the instructions in this document:
  1. You are ready to perform cutover.
  2. All concurrent managers have been shut down cleanly.
  3. There are no current database transactions being performed by any third-party applications.

2. Setting Up Flashback

All the steps in this section are performed on the database tier, as sysdba.

2.1 Set ARCHIVELOG mode

Ensure the database is in ARCHIVELOG mode. Refer to the documentation on Changing the Database Archiving Mode.

2.2 Enable Fast Recovery Area

You enable the Fast Recovery Area (FRA) by setting two database initialization parameters:
  • DB_RECOVERY_FILE_DEST_SIZE - Specifies the size of the Fast Recovery Area.
  • DB_RECOVERY_FILE_DEST - Specifies the physical location of the Flashback recovery files.
Note: If you are using the Fast Recovery Area to store RMAN backups to disk, the FRA needs to be sized to hold all your datafiles, any incremental backups, and the flashback logs generated during cutover.
If you are not using the Fast Recovery Area to store RMAN backups, the FRA only needs to be large enough to contain the flashback logs for the duration of cutover. The size will depend on your selected retention policy (based on the time needed to perform cutover), and should be sufficient to accommodate your online redo log files. If you set the size too small, you may experience space availability issues, resulting in restoration failure. It is therefore advisable to monitor space utilization: any shortages will be recorded in the database alert log.
To minimize FRA space requirements, the Online Patching cutover phase should be scheduled for a time when there are few online transactions, and batch processing is minimal.
SQL>alter system set db_recovery_file_dest_size = 10G scope=BOTH SID='*';System altered.
SQL>alter system set db_recovery_file_dest = '/d1/oracle/test/ARCH' scope=BOTH SID='*';
System altered.
Note: It is generally advisable to use a server parameter file ("spfile") for managing the database initialization parameters. Refer to the documentation on Managing Initialization Parameters Using a Server Parameter File.

2.3 Specify maximum flashback time

The next command specifies the maximum number of minutes the database may be flashed back. This parameter determines how much flashback log data is kept in the recovery area.
SQL>alter system set db_flashback_retention_target=120;
System altered.
Note: The amount of retention time and space needed will be governed by the amount of time required for cutover. Setting the flashback retention target too high may result in issues if DB_RECOVERY_FILE_DEST_SIZE is set to a large value.

2.4 Activate Flashback

Flashback is activated using the following command:
SQL>alter database flashback on;
Database altered.

2.5 Create restore point

This step will create a restore point called BEFORE_CUTOVER. As shown in the example below, it is also recommended to force a logfile switch both before and after the restore point is created.
SQL>alter system switch logfile;
System altered.
SQL>create restore point BEFORE_CUTOVER guarantee flashback database;
Restore point created.

SQL>alter system switch logfile;
System altered.
You are now ready to flashback the database if needed.
Note: As noted under the FRA description, the Online Patching cutover phase should be scheduled for a time when there are few online transactions and batch processing is minimal. You should confirm that critical concurrent requests are not executing during cutover.  You should also consider putting scheduled concurrent requests on hold prior to creating the BEFORE_CUTOVER flashback restore point.

3. Problem Scenario

You are running an Online Patching cycle:
$ adop phase=prepare...
$ adop phase=apply patches=11111111,22222222
...
$ adop phase=finalize
...
$ adop phase=cutover
Cutover fails, and you need to go back to the state of the system before you ran the cutover phase.
Note: If you had not run the cutover phase, you would have been able to roll back the patch application process by running the adop abort phase. However, this is not possible once cutover has been run.
There are two main parts to the restore procedure:
  • You will at least need to restore the database using the Flashback feature (described in Section 4)
  • Depending on when cutover failed, you may also need to restore the application tier file systems (described in Section 5).
These activities will be considered in the next two sections.

4. Flashing Back the Database

  1. First, shut down the database, then start it up in mount state:
    SQL>shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL>startup mount
    ORACLE instance started.
  2. Restore the flashback to the specified restore point:
    SQL>flashback database to restore point BEFORE_CUTOVER;
    Flashback complete.
  3. Start the database in read-only mode:
    SQL>alter database open read only;
    Database altered.
    Check all looks as expected.

  4. Shut down the database, start it up in mount state, then open it with the resetlogs option:
    SQL>shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL>startup mount
    ORACLE instance started.
    Total System Global Area 2142679040 bytes
    Fixed Size 1346140 bytes
    Variable Size 520095140 bytes
    Database Buffers 1593835520 bytes
    Redo Buffers 27402240 bytes
    Database mounted.
    SQL>alter database open resetlogs;
    Database altered.
  5. Disable flashback:
    SQL>alter database flashback off;
    Database altered.
  6. Drop the restore point:
    SQL>drop restore point BEFORE_CUTOVER;
    Restore point dropped.
  7. Set recovery file destination:
    SQL>alter system set db_recovery_file_dest='';
    System altered.
  8. Confirm that Flashback has been deactivated:
    SQL>select FLASHBACK_ON from v$database;
    FLASHBACK_ON
    ------------
    NO
This concludes the Flashback activities.
Note: If you are not using FRA, you may want to clean up the flashback space (unless you intend to keep it for the next adop cycle).

5. Restoring the File Systems

Whether you need to perform this step is conditional, depending on whether cutover failed before the file systems were switched. You can identify which of these cases applies by referring to the cutover logs in $NE_BASE/EBSapps/log/adop/<current_session_id>/cutover_<timestamp>/ for your current session id.
Case 1 - If the log messages indicate that cutover failed before the file systems were switched, do a clean shutdown of any services that are running. Then restart all the services using the normal startup script, and go to Section 6.
Case 2 - If the log messages indicate that cutover failed after the file systems were switched, follow Step 5.1 to shut down any services that have started from the new run file system, then follow Step 5.2 to switch the file systems back. After that, go to Section 6.

5.1 Shut down services started from new run file system

  1. Source the environment on the new run file system.
  2. From $ADMIN_SCRIPTS_HOME, shut down all the services (using adstpall.sh on UNIX).
  3. In a multi-node environment, repeat the preceding two steps on all nodes, leaving the admin node until after all the slave nodes.

5.2 Switch file systems back

  1. On all nodes where file systems have been switched, run the following command to switch the file systems back:
    $ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl \
    -action=ctxupdate \
    -contextfile=<full path to new run context file> \
    -patchcontextfile=<full path to new patch file system context file> \
    -outdir=<full path to out directory>
  2. Start up all services from the old run file system (using adstrtal.sh on UNIX).
  3. In a multi-node environment, repeat the preceding two steps on all nodes, starting with the admin node and then proceeding to the slave nodes.

6. Options and Next Steps

After the restore is complete, you have two basic options for proceeding:
  • Abort the current patching cycle, if the issue that required you to restore was caused by the patches you were attempting to apply.
  • Identify and fix any other issues in the current patching cycle, and proceed with patching.

7. References

For more information on the database features involved, plus guidance on setting the parameters to meet your specific requirements, refer to:
  • Chapter 5, Configuring the RMAN Environment, in Oracle Database Backup and Recovery User's Guide 11g Release 2 (11.2), Part No. E10642.
For more information on the Oracle E-Business Suite Online Patching cycle, refer to:
  • Chapter 3, Patching Procedures, in Oracle E-Business Suite Maintenance Guide, Part No.E22954.

7. Change Record

DateDescription
02-Jun-2014
  • Added adop to title.
21-Oct-2013
  • Made minor additions.
05-Sep-2013
  • Added prerequisites.
30-Aug-2013
  • Updated FRA sizing guidance.
28-Aug-2013
  • Updated Section 5.
09-Aug-2013
  • Initial creation.
My Oracle Support Knowledge Document 1584097.1 by Oracle E-Business Suite Development

8. Documentation Notices

Copyright © 2013, 2014, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

12.2 E-Business Suite Applications DBA Steps To Check if a Patch is Applied in 12.2.x using SQL*PLUS (Doc ID 1963046.1)

APPLIES TO:

Oracle E-Business Suite Technology Stack - Version 12.2 to 12.2.7 [Release 12.2]
Oracle Applications Manager - Version 12.2 to 12.2.7 [Release 12.2Cloud to 12.2]
Oracle Trade Management - Version 12.2 to 12.2.7 [Release 12.2]
Oracle Application Object Library - Version 12.2 to 12.2.7 [Release 12.2]
Oracle Applications DBA - Version 12.2 to 12.2.7 [Release 12.2Cloud to 12.2]
Information in this document applies to any platform.

GOAL

The purpose of this document is to explain how to check if a Patch is applied on an environment in Release 12.2.x.

SOLUTION

In eBusiness Suite (EBS) 12.2.x you cannot query the AD_BUGS table to check if patches have been applied.
The AD_BUGS table may have entries for patches that were applied but later the patching cycle was aborted (not really applied).
To check whether a patch is really applied use the AD_PATCH.IS_PATCH_APPLIED pl/sql function.
Using this API is an alternative method for users without access to Oracle Applications Manager's "Patching and Utilities" feature to determine if a certain patch is applied.

Usage:
select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appl_top_id\',\'$patch_no\',\'$language\')
from dual;
To obtain the appl_top_id use the following select to list the appl_tops:
SELECT APPL_TOP_ID , NAME , DESCRIPTION , APPLICATIONS_SYSTEM_NAME , ACTIVE_FLAG FROM APPLSYS.AD_APPL_TOPS;
 
Example sql using the APPL_TOP ID for a specific node in a multinode environment (1045 is the APPL_TOP ID):
SELECT adb.bug_number,ad_patch.is_patch_applied('R12', 1045, adb.bug_number)
FROM ad_bugs adb
WHERE adb.bug_number in (20034256);

or for single app tier installations:
select ad_patch.is_patch_applied('R12',-1,20034256) from dual;
expected results:
EXPLICIT = applied
NOT APPLIED = not applied / aborted

Note: If you are sure patch is applied but it is not showing as applied via the above steps, then update the snapshot manually with the steps below:
1. Start adadmin after source the RUN FS env.
2. Select "2. Maintain Applications Files menu" in "AD Administration Main Menu".
3. In "Maintain Applications Files", select "4. Maintain snapshot information".
4. Select "2. Update current view snapshot" in the "Maintain Snapshot Information".
5. Select "1. Update Complete APPL_TOP" in the "Maintain Current View Snapshot Information".

Friday, January 10, 2020

E-Business Suite Applications Technology Stack Utility / Script To Check The Techstack Component Versions (Forms, Http Server, JDK, Framework, Database, etc) (Doc ID 601736.1)

APPLIES TO:

Oracle E-Business Suite Technology Stack - Version 11.5.10.2 to 12.2 [Release 11.5.10 to 12.2]
Information in this document applies to any platform.

GOAL

How to find the versions of Technology stack components like Forms, iAS, Framework, JDK, OJSP, Database, etc.?

SOLUTION

On Application Tier
  1. Establish the needed environment parameters by sourcing the Applications environment file as the owner of the application tier file system.
  2. Ensure "APPLRGF" variable is set in environment. If not, set it to the same value as "APPLTMP" (Note: If you set the output file directory using -outfile parameter, skip this step and the file will be generated under $APPLRGF/TXK directory).
  3. Navigate to <FND_TOP>/patch/115/bin. Run the utility/command  as follows :

    Operation System
     
    Command Line
    Unix or Linux$ADPERLPRG $FND_TOP/patch/115/bin/TXKScript.pl \
    -script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP \
    -contextfile=$CONTEXT_FILE \
    -appspass=apps \
    -outfile=$APPLTMP/Report_App_Inventory.html

    Note:
    - Run the above command in single line
    - Remove the '\' after each parameter when running the command on a single line
    - Supply the apps user password as is applicable for parameter "-appspass"
    Windows­PERLPRG% %FND_TOP%\patch\115\bin\TXKScript.pl
    -script=%FND_TOP%\patch\115\bin\txkInventory.pl
    -txktop=%APPLTMP% -contextfile=%CONTEXT_FILE%
    -appspass=apps
    -outfile=%APPLTMP%\Report_App_Inventory.html
    Note:
    - Run the above command in single line
    Remove the '\' after each parameter when running the command on a single line
    - Supply the apps user password as is applicable for parameter "-appspass"

    Where:
      
    txktopTemporary working directory use by Perl Modules. Should not be an empty string.
    contextfileLocation of the context file. If not passed, default is picked from the environment.
    appspassAPPS schema password. If not passed, default password is used.
    outfileLocation for the report being generated. If not passed, the default location is <APPLTMP>/TXK

    To generate the report in text format, the parameter "-reporttype=text" needs to be passed to the above commands. For example:
    outfile=$APPLTMP/Report_App_Inventory.txt -reporttype=text
  4. Once the command executes successfully, it should generate the report file in the location specified for "outfile" parameter in above script
  5. In case you have more than one application tier's (multi-node architecture), follow the steps 1-4 on each of the Application tiers
  6. Upload the report output file (default: $APPLTMP/Report_App_Inventory.html )to Oracle Support for review

On Database Tier
  1. Establish the needed environment parameters by sourcing the Database environment file as the owner of the Database tier file system. |
  2. Ensure "ORACLE_HOME" variable is set in environment and correctly pointing to your database ORACLE_HOME.
  3. Navigate to <ORACLE_HOME>/appsutil/bin. Run the utility/command as below (all on a single line):

    Operation System 
                                              
    Command Line
    Unix or Linux$ADPERLPRG $ORACLE_HOME/appsutil/bin/TXKScript.pl
    -script=$ORACLE_HOME/appsutil/bin/txkInventory.pl -txktop=$ORACLE_HOME/appsutil/temp
    -contextfile=$CONTEXT_FILE
    -appspass=apps
    -outfile=$ORACLE_HOME/appsutil/temp/Report_DB_Inventory.html
    Note:- Run the above command in single line
    - Supply the apps user password as is applicable for parameter "-appspass"
    Windows­PERLPRG% %ORACLE_HOME%/appsutil/bin/TXKScript.pl
    -script=%ORACLE_HOME%/appsutil/bin/txkInventory.pl -txktop=%ORACLE_HOME%/appsutil/temp
    -contextfile=%CONTEXT_FILE%
    -appspass=apps
    -outfile=%ORACLE_HOME%/appsutil/temp/Report_DB_Inventory.html
    Note:
    - Run the above command in single line
    - Supply the apps user password as is applicable for parameter "-appspass"

    Where
     
      
    txktopTemporary working directory use by Perl Modules. Should not be an empty string.
    contextfileLocation of the context file.
    appspassAPPS schema password.
    outfileLocation for the report being generated.

    To generate the report in text format, the parameter "-reporttype=text" needs to be passed to the above commands. For example:

    outfile=$ORACLE_HOME/appsutil/temp/Report_DB_Inventory.txt -reporttype=text
  4. Once the command executes successfully, it should generate the report file in the location specified for "outfile" parameter in above script
  5. Upload the report output file (default: $ORACLE_HOME/appsutil/temp/Report_DB_Inventory.html ) to Oracle Support for review

Monday, January 6, 2020

If the Admin Password of an EBS WebLogic Domain is lost or forgotten

As noted earlier, the EBS WebLogic domain uses Node Manager to control startup of the AdminServer and Managed Servers. For the EBS WebLogic domain, the Node Manager and WebLogic AdminServer passwords must be same. If the passwords are different, the AD control scripts will not work properly.
If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps on the run file system. As described in the final step, an fs_clone operation should then be performed to synchronize the run and patch file systems.
  1. Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.
    1. Connect to the Oracle E-Business Suite instance and source the application tier environment file.
    2. Identify the PIDs of Node Manager, AdminServer, and all running Managed Servers:
      $ ps -ef | grep "NodeManager"
      $ ps -ef | grep "weblogic.Name=AdminServer"
      $ ps -ef | grep "weblogic.Name=forms-c4ws_server"
      $ ps -ef | grep "weblogic.Name=forms_server"
      $ ps -ef | grep "weblogic.Name=oafm_server"
      $ ps -ef | grep "weblogic.Name=oacore_server"
    3. Kill all these processes, starting with Node Manager and followed by the Managed Servers.
  2. Back up these folders, and then delete them:
    <EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
    <EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
    <EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
    <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties
    
    
    Where:
    • <EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
    • <server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.
    If the password is not reset correctly, the backed up files and folders can be restored.
    Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.
  3. Set up a new environment to change the WLS AdminServer password.
    1. Start a new session and connect to the Oracle E-Business Suite instance.
    2. Do not source the application tier environment file.
    3. Run the following command to source the WebLogic Server domain environment:
      $ cd <EBS_DOMAIN_HOME>/bin
      $ source setDomainEnv.sh
    4. Run the following commands:
      $ cd <EBS_DOMAIN_HOME>/security
      $ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .
      Where:
      • <wls_adminuser> is the same as the value of context variable s_wls_admin_user
      • <wls_admin_new_password> is the new WLS AdminServer password you wish to set.
      Note: Do not omit the trailing period ('.') in the above command: it is needed to specify the current domain directory.
  4. Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.
    1. Go to the EBS Domain Home:
      $ cd <EBS_DOMAIN_HOME>
    2. Start AdminServer:
      $ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server
      Where:
      • <s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties
      The above command prompts for the WebLogic Server username and password:
      Enter username to boot WebLogic server:
      Enter password to boot WebLogic server: 
      Provide the same credentials as you provided in Step 3.
  5. Change the Node Manager password.
    1. Log in to the WebLogic Administration console.
    2. Click the 'Lock & Edit' button.
    3. In the left panel, click on the EBS Domain link.
    4. Select the 'Security' tab.
    5. Click on the 'Advanced' link.
    6. Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
    7. Edit the 'Confirm Node Manager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.
    8. Save and activate the changes.
  6. The first time, AdminServer has to be stopped from the Admin console. Follow these steps:
    1. Log in to the WebLogic Administration console.
    2. Shut down AdminServer.
  7. Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start Node Manager using the new password.
    1. Launch a new session and connect to the Oracle E-Business Suite instance.
    2. Source the application tier environment file.
    3. Start AdminServer with the following command:
      $ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
  8. Start the Managed Servers. For the first time, all Managed Servers should be started from the WebLogic Server Admin console. This step will create boot.properties files for the respective Managed Servers. Follow these steps:
    1. Log in to the WebLogic Server Administration Console.
    2. Start all Managed Servers, one at a time.
  9. Shut down all the Managed Servers. This is so the new credentials will be picked up at the next startup. Follow these steps:
    1. Log in to the WebLogic AdminServer console.
    2. Shut down all Managed Servers.
    3. Shut down AdminServer.
  10. Shut down Node Manager using the normal AD script.
    $ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop
  11. Copy the boot.properties file for each Managed Server.
    WebLogic Server native scripts use the boot.properties file. The above steps have created the boot.properties file under <EBS_DOMAIN_HOME>/servers/<Managed Server name>/data/nodemanager, which is used by Node Manager. For each Managed Server, copy the newly-generated boot.properties file from<EBS_DOMAIN_HOME>/servers/<Managed Server name>/data/nodemanager to <EBS_DOMAIN_HOME>/servers/<Managed Server name>/security.
    The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.
    To start AdminServer:
    $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start
    To start the Managed Servers:
    $ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start <managed_server_name>
  12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS Domain password on the patch file system:
    1. Launch a new session and connect to the Oracle E-Business Suite instance.
    2. Source the application tier environment file.
    3. Run the following command:
      $ adop phase=fs_clone

Thursday, January 2, 2020

Adding connection filter in EBS

cd $ADMIN_SCRIPTS_HOME
sh adadminsrvctl.sh start

-- add all nodes from run fs
--------------------------
. ~/EBSapps.env run
java -cp $CLASSPATH:$FMW_HOME/wlserver_10.3/server/lib/weblogic.jar oracle.apps.ad.tools.configuration.RegisterNodePreReq add-filter-rule \
-contextfile $CONTEXT_FILE -hostname <isupplier node hostname>


--------------------------

perl adpreclone.pl appsTier -- ## 25 minutes -- started 3.31pm

Sunday, December 29, 2019

Database Performance Tuning Guide

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/tgdba/tuning-result-cache.html#GUID-FA30CC32-17AB-477A-9E4C-B47BFE0968A1


15 Tuning the Result Cache

This chapter describes how to tune the result cache and contains the following topics:

15.1 About the Result Cache

A result cache is an area of memory, either in the Shared Global Area (SGA) or client application memory, that stores the results of a database query or query block for reuse. The cached rows are shared across SQL statements and sessions unless they become stale.
This section describes the two types of result cache and contains the following topics:

15.1.1 Server Result Cache Concepts

The server result cache is a memory pool within the shared pool. This memory pool consists of the SQL query result cache—which stores results of SQL queries—and the PL/SQL function result cache, which stores values returned by PL/SQL functions.
This section describes the server result cache and contains the following topics:
See Also:
15.1.1.1 Benefits of Using the Server Result Cache
The benefits of using the server result cache depend on the application. OLAP applications can benefit significantly from its use. Good candidates for caching are queries that access a high number of rows but return a small number, such as those in a data warehouse. For example, you can use advanced query rewrite with equivalences to create materialized views that materialize queries in the result cache instead of using tables.
See Also:
Oracle Database Data Warehousing Guide for information about using the result cache and advance query rewrite with equivalences
15.1.1.2 Understanding How the Server Result Cache Works
When a query executes, the database searches the cache memory to determine whether the result exists in the result cache. If the result exists, then the database retrieves the result from memory instead of executing the query. If the result is not cached, then the database executes the query, returns the result as output, and stores the result in the result cache.
When users execute queries and functions repeatedly, the database retrieves rows from the cache, decreasing response time. Cached results become invalid when data in dependent database objects is modified.
The following sections contains examples of how to retrieve results from the server result cache:
15.1.1.2.1 How Results are Retrieved in a Query
The following example shows a query of hr.employees that uses the RESULT_CACHE hint to retrieve rows from the server result cache.
SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)
  FROM hr.employees
 GROUP BY department_id;
A portion of the execution plan of this query might look like the following:
--------------------------------------------------------------
| Id | Operation          | Name                       |Rows
--------------------------------------------------------------
| 0 | SELECT STATEMENT    |                            | 11
| 1 |  RESULT CACHE       | 8fpza04gtwsfr6n595au15yj4y |
| 2 |   HASH GROUP BY     |                            | 11
| 3 |    TABLE ACCESS FULL| EMPLOYEES                  | 107
--------------------------------------------------------------
In this example, the results are retrieved directly from the cache, as indicated in step 1 of the execution plan. The value in the Name column is the cache ID of the result.
The following example shows a query of the V$RESULT_CACHE_OBJECTS view to retrieve detailed statistics about the cached result.
SELECT id, type, creation_timestamp, block_count,
       column_count, pin_count, row_count
  FROM V$RESULT_CACHE_OBJECTS
 WHERE cache_id = '8fpza04gtwsfr6n595au15yj4y';
In this example, the value of CACHE_ID is the cache ID obtained from the explain plan in the earlier example. The output of this query might look like the following:
        ID TYPE       CREATION_ BLOCK_COUNT COLUMN_COUNT  PIN_COUNT  ROW_COUNT
---------- ---------- --------- ----------- ------------ ---------- ----------
         2 Result     06-NOV-11           1            2          0         12
15.1.1.2.2 How Results are Retrieved in a View
Example 15-1 shows a query that uses the RESULT_CACHE hint within a WITH clause view.
Example 15-1 RESULT_CACHE Hint Specified in a WITH View
WITH summary AS
( SELECT /*+ RESULT_CACHE */ department_id, avg(salary) avg_sal
    FROM hr.employees
   GROUP BY department_id )
SELECT d.*, avg_sal
  FROM hr.departments d, summary s
 WHERE d.department_id = s.department_id;
A portion of the execution plan of this query might look like the following:
------------------------------------------------------------------------------------------------
| Id| Operation             | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|  0| SELECT STATEMENT      |                           |   11 |   517 |     7  (29)| 00:00:01 |
|* 1|  HASH JOIN            |                           |   11 |   517 |     7  (29)| 00:00:01 |
|  2|   VIEW                |                           |   11 |   286 |     4  (25)| 00:00:01 |
|  3|    RESULT CACHE       | 8nknkh64ctmz94a5muf2tyb8r |      |       |            |          |
|  4|     HASH GROUP BY     |                           |   11 |    77 |     4  (25)| 00:00:01 |
|  5|      TABLE ACCESS FULL| EMPLOYEES                 |  107 |   749 |     3   (0)| 00:00:01 |
|  6|   TABLE ACCESS FULL   | DEPARTMENTS               |   27 |   567 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------
In this example, the summary view results are retrieved directly from the cache, as indicated in step 3 of the execution plan. The value in the Name column is the cache ID of the result.

15.1.2 Client Result Cache Concepts

The Oracle Call Interface (OCI) client result cache is a memory area inside a client process that caches SQL query result sets for OCI applications. This client cache exists for each client process and is shared by all sessions inside the process. Oracle recommends client result caching for queries of read-only or read-mostly tables.
Note:
The client result cache is distinct from the server result cache, which resides in the SGA. When client result caching is enabled, the query result set can be cached on the client, server, or both. Client caching can be enabled even if the server result cache is disabled.
This section describes the client result cache and contains the following topics:
15.1.2.1 Benefits of Using the Client Result Cache
OCI drivers, such as OCCI, the JDBC OCI driver, and ODP.NET, support client result caching. Performance benefits of using the client result cache include:
  • Reduced query response time
    When queries are executed repeatedly, the application retrieves results directly from the client cache memory, resulting in faster query response time.
  • More efficient use of database resources
    The reduction in server round trips may result in substantial performance savings of server resources, such as server CPU and I/O. These resources are freed for other tasks, thereby making the server more scalable.
  • Reduced memory cost
    The result cache uses client memory, which may be less expensive than server memory.
15.1.2.2 Understanding How the Client Result Cache Works
The client result cache stores the results of the outermost query, which are the columns defined by the OCI application. Subqueries and query blocks are not cached.
The following figure illustrates a client process with a database login session. This client process has one client result cache shared amongst multiple application sessions running in the client process. If the first application session runs a query, then it retrieves rows from the database and caches them in the client result cache. If other application sessions run the same query, then they also retrieve rows from the client result cache.
Figure 15-1 Client Result Cache
Description of Figure 15-1 follows
Description of "Figure 15-1 Client Result Cache"
The client result cache transparently keeps the result set consistent with session state or database changes that affect it. When a transaction changes the data or metadata of database objects used to build the cached result, the database sends an invalidation to the OCI client on its next round trip to the server.
See Also:
Oracle Call Interface Programmer's Guide for details about the client result cache

15.2 Configuring the Result Cache

This section describes how to configure the server and client result cache and contains the following topics:

15.2.1 Configuring the Server Result Cache

By default, on database startup, Oracle Database allocates memory to the server result cache in the shared pool. The memory size allocated depends on the memory size of the shared pool and the selected memory management system:
  • Automatic shared memory management
    If you are managing the size of the shared pool using the SGA_TARGET initialization parameter, Oracle Database allocates 0.50% of the value of the SGA_TARGET parameter to the result cache.
  • Manual shared memory management
    If you are managing the size of the shared pool using the SHARED_POOL_SIZE initialization parameter, then Oracle Database allocates 1% of the shared pool size to the result cache.
Note:
Oracle Database will not allocate more than 75% of the shared pool to the server result cache.
The size of the server result cache grows until it reaches the maximum size. Query results larger than the available space in the cache are not cached. The database employs a Least Recently Used (LRU) algorithm to age out cached results, but does not otherwise automatically release memory from the server result cache.
This section describes how to configure the server result cache and contains the following topics:
15.2.1.1 Sizing the Server Result Cache Using Initialization Parameters
Table 15-1 lists the database initialization parameters that control the server result cache.
Table 15-1 Server Result Cache Initialization Parameters
ParameterDescription
RESULT_CACHE_MAX_SIZE
Specifies the memory allocated to the server result cache. To disable the server result cache, set this parameter to 0.
RESULT_CACHE_MAX_RESULT
Specifies the maximum amount of server result cache memory (in percent) that can be used for a single result. Valid values are between 1 and 100. The default value is 5%. You can set this parameter at the system or session level.
RESULT_CACHE_REMOTE_EXPIRATION
Specifies the expiration time (in minutes) for a result in the server result cache that depends on remote database objects. The default value is 0, which specifies that results using remote objects will not be cached. If a non-zero value is set for this parameter, DML on the remote database does not invalidate the server result cache.
See Also:
Oracle Database Reference for more information about these initialization parameters
To change the memory allocated to the server result cache:
  • Set the value of the RESULT_CACHE_MAX_SIZE initialization parameter to the desired size.
    In an Oracle Real Application Clusters (Oracle RAC) environment, the result cache is specific to each database instance and can be sized differently on each instance. However, invalidations work across instances. To disable the server result cache in a cluster, you must explicitly set this parameter to 0 for each instance startup.
15.2.1.2 Managing the Server Result Cache Using DBMS_RESULT_CACHE
The DBMS_RESULT_CACHE package provides statistics, information, and operators that enable you to manage memory allocation for the server result cache. Use the DBMS_RESULT_CACHE package to perform operations such as retrieving statistics on the cache memory usage and flushing the cache.
This section describes how to manage the server result cache using the DBMS_RESULT_CACHE package and contains the following topics:
15.2.1.2.1 Viewing Memory Usage Statistics for the Server Result Cache
This section describes how to view memory allocation statistics for the result cache using the DBMS_RESULT_CACHE package.
To view memory usage statistics for the result cache:
  • Execute the DBMS_RESULT_CACHE.MEMORY_REPORT procedure.
    Example 15-2 shows an execution of this procedure.
Example 15-2 Using the DBMS_RESULT_CACHE Package
SQL> SET SERVEROUTPUT ON
SQL> EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT
The output of this command might look like the following:
R e s u l t  C a c h e  M e m o r y  R e p o r t
[Parameters]
Block Size = 1024 bytes
Maximum Cache Size = 950272 bytes (928 blocks)
Maximum Result Size = 47104 bytes (46 blocks)
[Memory]
Total Memory = 46340 bytes [0.048% of the Shared Pool]
... Fixed Memory = 10696 bytes [0.011% of the Shared Pool]
... State Object Pool = 2852 bytes [0.003% of the Shared Pool]
... Cache Memory = 32792 bytes (32 blocks) [0.034% of the Shared Pool]
....... Unused Memory = 30 blocks
....... Used Memory = 2 blocks
........... Dependencies = 1 blocks
........... Results = 1 blocks
............... SQL = 1 blocks

PL/SQL procedure successfully completed.
15.2.1.2.2 Flushing the Server Result Cache
This section describes how to remove all existing results and purge the result cache memory using the DBMS_RESULT_CACHE package.
To flush the server result cache:
  • Execute the DBMS_RESULT_CACHE.FLUSH procedure.
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_RESULT_CACHE package

15.2.2 Configuring the Client Result Cache

Table 15-2 lists the database initialization parameters that enable or influence the behavior of the client result cache.
Table 15-2 Client Result Cache Initialization Parameters
ParameterDescription
CLIENT_RESULT_CACHE_SIZE
Specifies the maximum size of the client result cache for each client process. To enable the client result cache, set the size to 32768 bytes or greater. A lesser value, including the default of 0, disables the client result cache.
Note: If the CLIENT_RESULT_CACHE_SIZE setting disables the client cache, then a client node cannot enable it. If the CLIENT_RESULT_CACHE_SIZE setting enables the client cache, however, then a client node can override the setting. For example, a client node can disable client result caching or increase the size of its cache.
CLIENT_RESULT_CACHE_LAG
Specifies the amount of lag time (in milliseconds) for the client result cache. The default value is 3000 (3 seconds). If the OCI application does not perform any database calls for a period of time, then this setting forces the next statement execution call to check for validations.
If the OCI application accesses the database infrequently, then setting this parameter to a low value results in more round trips from the OCI client to the database to keep the client result cache synchronized with the database.
COMPATIBLE
Specifies the release with which Oracle Database must maintain compatibility. For the client result cache to be enabled, this parameter must be set to 11.0.0.0 or higher. For client caching on views, this parameter must be set to 11.2.0.0.0 or higher.
An optional client configuration file overrides client result cache initialization parameters set in the server parameter file.
Note:
The client result cache lag can only be set with the CLIENT_RESULT_CACHE_LAG initialization parameter.
See Also:

15.2.3 Setting the Result Cache Mode

The result cache mode is a database setting that determines which queries are eligible to store result sets in the server and client result caches. If a query is eligible for caching, then the application checks the result cache to determine whether the query result set exists in the cache. If it exists, then the result is retrieved directly from the result cache. Otherwise, the database executes the query and returns the result as output and stores it in the result cache. Oracle recommends result caching for queries of read-only or read-mostly database objects.
When the result cache is enabled, the database also caches queries that call non-deterministic PL/SQL functions. When caching SELECT statements that call such functions, the result cache tracks data dependencies for the PL/SQL functions and the database objects. However, if the function uses data that are not being tracked (such as sequences, SYSDATESYS_CONTEXT, and package variables), using the result cache on queries that call this function can produce stale results. In this regard, the behavior of the result cache is identical to caching PL/SQL functions. Therefore, always consider data accuracy, as well as performance, when choosing to enable the result cache.
To set the result cache mode:
  • Set the value of the RESULT_CACHE_MODE initialization parameter to determine the behavior of the result cache.
    You can set this parameter for the instance (ALTER SYSTEM), session (ALTER SESSION), or in the server parameter file.
    Table 15-3 describes the values for this parameter.
Table 15-3 Values for the RESULT_CACHE_MODE Parameter
ValueDescription
MANUAL
Query results can only be stored in the result cache by using a query hint or table annotation. This is the default and recommended value.
FORCE
All results are stored in the result cache. If a query result is not in the cache, then the database executes the query and stores the result in the cache. Subsequent executions of the same SQL statement, including the result cache hint, retrieve data from the cache. Sessions uses these results if possible. To exclude query results from the cache, the /*+ NO_RESULT_CACHE */ query hint must be used.
Note: FORCE mode is not recommended because the database and clients will attempt to cache all queries, which may create significant performance and latching overhead. Moreover, because queries that call non-deterministic PL/SQL functions are also cached, enabling the result cache in such a broad-based manner may cause material changes to the results.
See Also:
Oracle Database Reference for information about the RESULT_CACHE_MODE initialization parameter

15.2.4 Requirements for the Result Cache

Enabling the result cache does not guarantee that a specific result set will be included in the server or client result cache. In order for results to be cached, the following requirements must be met:
15.2.4.1 Read Consistency Requirements
For a snapshot to be reusable, it must have read consistency. For a result set to be eligible for caching, at least one of the following conditions must be true:
  • The read-consistent snapshot used to build the result must retrieve the most current, committed state of the data.
  • The query points to an explicit point in time using flashback query.
If the current session has an active transaction referencing objects in a query, then the results from this query are not eligible for caching.
15.2.4.2 Query Parameter Requirements
Cache results can be reused if they are parameterized with variable values when queries are equivalent and the parameter values are the same. Different values or bind variable names may cause cache misses. Results are parameterized if any of the following constructs are used in the query:
  • Bind variables
  • The SQL functions DBTIMEZONESESSIONTIMEZONEUSERENV/SYS_CONTEXT (with constant variables), UID, and USER
  • NLS parameters
15.2.4.3 Restrictions for the Result Cache
Results cannot be cached when the following objects or functions are in a query:
  • Temporary tables and tables in the SYS or SYSTEM schemas
  • Sequence CURRVAL and NEXTVAL pseudo columns
  • SQL functions CURRENT_DATECURRENT_TIMESTAMPLOCAL_TIMESTAMPUSERENV/SYS_CONTEXT (with non-constant variables), SYS_GUIDSYSDATE, and SYS_TIMESTAMP
The client result cache has additional restrictions for result caching.
Note:
Result cache does not work on an Active Data Guard standby database opened in read-only mode.
See Also:
Oracle Call Interface Programmer's Guide for information about additional restrictions for the client result cache

15.3 Specifying Queries for Result Caching

This section describes how to specify queries for result caching and contains the following topics:

15.3.1 Using SQL Result Cache Hints

Use result cache hints at the application level to control caching behavior. The SQL result cache hints take precedence over the result cache mode and result cache table annotations.
This section describes how to use SQL result cache hints and contains the following topics:
See Also:
Oracle Database SQL Language Reference for information about the RESULT_CACHE and NO_RESULT_CACHE hints
15.3.1.1 Using the RESULT_CACHE Hint
When the result cache mode is MANUAL, the /*+ RESULT_CACHE */ hint instructs the database to cache the results of a query block and to use the cached results in future executions.
Example 15-3 shows a query that uses the RESULT_CACHE hint.
Example 15-3 Using the RESULT_CACHE Hint
SELECT /*+ RESULT_CACHE */ prod_id, SUM(amount_sold)
  FROM sales 
 GROUP BY prod_id
 ORDER BY prod_id;
In this example, the query instructs the database to cache rows for a query of the sales table.
15.3.1.2 Using the NO_RESULT_CACHE Hint
The /*+ NO_RESULT_CACHE */ hint instructs the database not to cache the results in either the server or client result caches.
Example 15-4 shows a query that uses the NO_RESULT_CACHE hint.
Example 15-4 Using the NO_RESULT_CACHE Hint
SELECT /*+ NO_RESULT_CACHE */ prod_id, SUM(amount_sold) 
  FROM sales 
 GROUP BY prod_id
 ORDER BY prod_id;
In this example, the query instructs the database not to cache rows for a query of the sales table.
15.3.1.3 Using the RESULT_CACHE Hint in Views
The RESULT_CACHE hint applies only to the query block in which the hint is specified. If the hint is specified only in a view, then only these results are cached. View caching has the following characteristics:
  • The view must be one of the following types:
    • A standard view (a view created with the CREATE ... VIEW statement)
    • An inline view specified in the FROM clause of a SELECT statement
    • An inline view created with the WITH clause
  • The result of a view query with a correlated column (a reference to an outer query block) cannot be cached.
  • Query results are stored in the server result cache, not the client result cache.
  • A caching view is not merged into its outer (or referring) query block.
    Adding the RESULT_CACHE hint to inline views disables optimizations between the outer query and inline view to maximize reusability of the cached result.
The following example shows a query of the inline view view1.
SELECT *
  FROM ( SELECT /*+ RESULT_CACHE */ department_id, manager_id, count(*) count
           FROM hr.employees 
          GROUP BY department_id, manager_id ) view1
 WHERE department_id = 30;
In this example, the SELECT statement from view1 is the outer block, whereas the SELECT statement from employees is the inner block. Because the RESULT_CACHE hint is specified only in the inner block, the results of the inner query are stored in the server result cache, but the results of the outer query are not cached.
Assume that the same session run a query of the view view2 as shown in the following example.
WITH view2 AS
( SELECT /*+ RESULT_CACHE */ department_id, manager_id, count(*) count
    FROM hr.employees 
   GROUP BY department_id, manager_id ) 
SELECT *
  FROM view2 
 WHERE count BETWEEN 1 and 5;
In this example, because the RESULT_CACHE hint is specified only in the query block in the WITH clause, the results of the employees query are eligible to be cached. Because these results are cached from the query in the first example, the SELECT statement in the WITH clause in the second example can retrieve the cached rows.

15.3.2 Using Result Cache Table Annotations

You can also use table annotations to control result caching. Table annotations affect the entire query, not query segments. The primary benefit of using table annotations is avoiding the necessity of adding result cache hints to queries at the application level. Because a table annotation has a lower precedence than a SQL result cache hint, you can override table and session settings by using hints at the query level.
Table 15-4 describes the valid values for the RESULT_CACHE table annotation.
Table 15-4 Values for the RESULT_CACHE Table Annotation
ValueDescription
DEFAULT
If at least one table in a query is set to DEFAULT, then result caching is not enabled at the table level for this query, unless if the RESULT_CACHE_MODE initialization parameter is set to FORCE or the RESULT_CACHE hint is specified. This is the default value.
FORCE
If all the tables of a query are marked as FORCE, then the query result is considered for caching. The table annotation FORCE takes precedence over the RESULT_CACHE_MODE parameter value of MANUAL set at the session level.
This section describes how to use the RESULT_CACHE table annotations and contains the following topics:
15.3.2.1 Using the DEFAULT Table Annotation
The DEFAULT table annotation prevents the database from caching results at the table level.
Example 15-5 shows a CREATE TABLE statement that uses the DEFAULT table annotation to create a table sales and a query of this table.
Example 15-5 Using the DEFAULT Table Annotation
CREATE TABLE sales (...) RESULT_CACHE (MODE DEFAULT);

SELECT prod_id, SUM(amount_sold)
  FROM sales 
 GROUP BY prod_id 
 ORDER BY prod_id;
In this example, the sales table is created with a table annotation that disables result caching. The example also shows a query of the sales table, whose results are not considered for caching because of the table annotation.
See Also:
Oracle Database SQL Language Reference for information about the CREATE TABLE statement and its syntax
15.3.2.2 Using the FORCE Table Annotation
The FORCE table annotation forces the database to cache results at the table level.
Using the sales table created in Example 15-5, assume that you decide to force result caching for this table, you can do so by using the FORCE table annotation.
Example 15-6 shows an ALTER TABLE statement that uses the FORCE table annotation on the sales table.
Example 15-6 Using the FORCE Table Annotation
ALTER TABLE sales RESULT_CACHE (MODE FORCE);

SELECT prod_id, SUM(amount_sold)
  FROM sales 
 GROUP BY prod_id 
HAVING prod_id=136;

SELECT /*+ NO_RESULT_CACHE */ * 
  FROM sales
 ORDER BY time_id DESC;
This example includes two queries of the sales table. The first query, which is frequently used and returns few rows, is eligible for caching because of the table annotation. The second query, which is a one-time query that returns many rows, uses a hint to prevent result caching.

15.4 Monitoring the Result Cache

To view information about the server and client result caches, query the relevant database views and tables.
Table 15-5 describes the most useful views and tables for monitoring the result cache.
Table 15-5 Views and Tables with Information About the Result Cache
View/TableDescription
V$RESULT_CACHE_STATISTICS
Lists various server result cache settings and memory usage statistics.
V$RESULT_CACHE_MEMORY
Lists all the memory blocks in the server result cache and their corresponding statistics.
V$RESULT_CACHE_OBJECTS
Lists all the objects whose results are in the server result cache along with their attributes.
V$RESULT_CACHE_DEPENDENCY
Lists the dependency details between the results in the server result cache and dependencies among these results.
CLIENT_RESULT_CACHE_STATS$
Stores cache settings and memory usage statistics for the client result caches obtained from the OCI client processes. This statistics table contains entries for each client process that uses result caching. After the client processes terminate, the database removes their entries from this table. The client table contains information similar to V$RESULT_CACHE_STATISTICS.
DBA_TABLESUSER_TABLESALL_TABLES
Contains a RESULT_CACHE column that shows the result cache mode annotation for the table. If the table is not annotated, then this column shows DEFAULT. This column applies to both server and client result caches.
See Also:
Oracle Database Reference for more information about these views and tables.
The following example shows a query of the V$RESULT_CACHE_STATISTICS view to monitor server result cache statistics.
COLUMN name FORMAT a20
SELECT name, value
  FROM V$RESULT_CACHE_STATISTICS;
The output of this query might look like the following:
NAME                          VALUE
--------------------     ----------
Block Size (Bytes)             1024
Block Count Maximum            3136
Block Count Current              32
Result Size Maximum (Blocks)    156
Create Count Success              2
Create Count Failure              0
Find Count                        0
Invalidation Count                0
Delete Count Invalid              0
Delete Count Valid                0
The following example shows a query of the CLIENT_RESULT_CACHE_STATS$ table to monitor the client result cache statistics.
SELECT stat_id, SUBSTR(name,1,20), value, cache_id
  FROM CLIENT_RESULT_CACHE_STATS$
 ORDER BY cache_id, stat_id;
The output of this query might look like the following:
STAT_ID    NAME OF STATISTICS      VALUE   CACHE_ID
=======    ==================      =====   ========
    1      Block Size               256         124
    2      Block Count Max          256         124
    3      Block Count Current      128         124
    4      Hash Bucket Count       1024         124
    5      Create Count Success      10         124
    6      Create Count Failure       0         124
    7      Find Count                12         124
    8      Invalidation Count         8         124
    9      Delete Count Invalid       0         124
   10      Delete Count Valid         0         124
The CLIENT_RESULT_CACHE_STATS$ table contains statistics entries for each active client process performing client result caching. Every client process has a unique cache ID.
To find the client connection information for the sessions performing client caching:
  1. Obtain the session IDs from the CLIENT_REGID column in the GV$SESSION_CONNECT_INFO view that corresponds to the CACHE_ID column in the CLIENT_RESULT_CACHE_STATS$ table.
  2. Query the relevant columns from the GV$SESSION_CONNECT_INFO and GV$SESSION views.
For both server and client result cache statistics, a database that is optimized for result caching should show relatively low values for the Create Count Failure and Delete Count Valid statistics, while showing relatively high values for the Find Count statistic.

Oracle E-Business Suite Release 12.2 System Schema Migration

In This Document Section 1: Overview of the EBS System Schema Section 2: Requirements for Using the EBS System Schema Section 3: Migrating t...