10 ways to speed up your r12.1.3 upgradeda… · 10 ways to speed up your r12.1.3 upgrade. mike...

10 Ways to Speed Up your R12.1.3 UpgradeMike Swing

[email protected]

mailto:[email protected]

New Book Available at trutek.com

Performance Tip #1: Review MOS Notes for EBSPerformance Tip #2: Review and Implement the Oracle Release Notes

RecommendationsPerformance Tip #3: Review the Operating System DocumentationPerformance Tip #4: Optimize Your ArchitecturePerformance Tip #5: Optimize Hardware Resources and ConfigurationPerformance Tip #6: Be Aware of Your Network ConfigurationPerformance Tip #7: Avoid In-place UpgradesPerformance Tip #8: Incorporate Plenty of Disk Space to Stage FilesPerformance Tip #9: Implement and Measure ChangePerformance Tip #10: Use Oracle Wait Events to Gather Data and Diagnose the SituationPerformance Tip #11: Get a SAN and Use SnapshotsPerformance Tip #12: Add More MemoryPerformance Tip #13: Tune Memory UsagePerformance Tip #14: Use Solid State Drives (SSDs) Performance Tip #15: Use Automatic Storage Management (ASM) Performance Tip #16: Understanding CPU and I/O UtilizationPerformance Tip #17: Re-Organize Rows When NecessaryPerformance Tip #18: I/O Configuration– Tune the Cost of I/OPerformance Tip #19: Understand ParallelizationPerformance Tip #20: Get More CPUs and Use Parallel Execution (Make Sure Your I/O is

Fast Enough) Performance Tip #21: Increase PARALLEL_MAX_SERVERSPerformance Tip #22: Avoid Using a Threaded CPU Architecture for the Database ServerPerformance Tip #24: Determine the Number of Workers to Use for the UpgradePerformance Tip #25: Tuning phase A35 of patch 6678700Performance Tip #26: Use Automatic Workload Repository (AWR) to Tune phase A35Performance Tip #27: Use Trace to Diagnose Performance IssuesPerformance Tip #28: Look for Functional Scripts and Datafixes from OraclePerformance Tip #29: Set db_file_multiblock_read_count = 8 in the Initialization FilePerformance Tip #30: Increase the Entropy of /dev/random - Performance Tuning

XDOLOADERPerformance Tip #31: Disable ARCHIVELOG Mode and Auditing

Insight Article – 10 Ways to Speed Up your Upgrade

10 Ways to Speed Up your R12.1.3 Upgrade

1. Tune the IO2. Tune the CPUs3. Use Parallel Execution4. Increase PARALLEL_MAX_Servers5. Set PARALLEL_MIN_PERCENT = 06. Set parallel_degree_policy = AUTO7. Increase parallel_threads_per_cpu8. Review the Release Notes9. Avoid an in-place upgrade10. Use Event Tracing to Diagnose Issues

1. Tune the IO

The performance of many software applications is inherently limited by disk I/O. Applications that spend the majority of CPU time waiting for I/O activity to complete are said to be I/O-bound.

Tuning I/O can enhance the performance of the application if the I/O system is operating at or near capacity and is not able to service the I/O requests within an acceptable time. However, tuning I/O cannot help performance if the application is not I/O-bound (for example, when CPU is the limiting factor).

Consider the following database requirements when designing an I/O system:

• Storage, such as minimum disk capacity • Availability, such as continuous (24 x 7) or business hours only • Performance, such as I/O throughput and application response times• Measure the I/O throughput required, simulate the I/O workload to

validate the storage system

1. Tune the IO

Detecting I/O ProblemsAn overly active I/O system can be evidenced by disk queue lengths greater

than two, disk service times that are over 20-30ms, or % I/O Wait> 90% in the following example.

If the I/O system is overly active, check for potential hot spots that could benefit from distributing the I/O across more disks.

Also identify whether the load can be reduce the resource requirements. Using OEM, view the large amount of user I/O.

1. Tune the IO

1. Tune the IO

Use operating system monitoring tools to determine what processes are running on the system as a whole and to monitor disk access to all files.

Reduce any heavy access to disks that contain database files. Utilities, such as sar-d (or iostat) on many UNIX systems and the

administrative performance monitoring tool on Windows systems examine I/O statistics for the entire system.

Check the Oracle wait event data in V$SYSTEM_EVENT to see whether the top wait events are I/O related. I/O related events include db file sequential read, db file scattered read, db file single write, and db file parallel write, and log file parallel write. These are all events corresponding to I/Os performed against data files and log files. If any of these wait events correspond to high average time, then investigate the I/O contention

1. Tune the IO

Tables, Indexes, and TEMP TablespacesIf the files with high I/O are data files belonging to tablespaces that contain

tables and indexes, then identify whether the I/O for those files can be reduced by tuning SQL or application code.

If the files with high-I/O are data files that belong to the TEMP tablespace, then investigate whether to tune the SQL statements performing disk sorts to avoid this activity, or to tune the sorting.

After the application has been tuned to avoid unnecessary I/O, if the I/O layout is still not able to sustain the required throughput, then consider segregating the high-I/O files.

1. Tune the IO

Redo Log FilesIf the high-I/O files are redo log files, then consider splitting the redo log

files from the other files. Possible configurations can include the following:

Placing each redo log group on a separate disk that does not store any other files.

Striping the redo log files across several disks, using an operating system striping tool. (Manual striping is not possible in this situation.)

Avoiding the use of RAID 5 for redo logs.Redo log files are written sequentially by the Log Writer (LGWR) process.

1. Tune the IO

Archived Redo LogsIf the archive process is slow, ensure the archive process reads and

LGWR writes are separated. This is achieved by placing logs on different physical drives.

Mirroring redo log files, or maintaining multiple copies of each redo log file on separate disks, does not slow LGWR considerably. LGWR writes to each disk in parallel and waits until each part of the parallel write is complete. Hence, a parallel write does not take longer than the longest possible single-disk write.

Because redo logs are written serially, drives dedicated to redo log activity require less seek time. This significantly improves the LGWR process.

If the LGWR process is slow, DBWR will wait until LGWR is finished

1. Tune the IO

READSThe Cost Based Optimizer (CBO) determines the Cost based on

Selectivity and Cardinality.The CBO uses selectivity and cardinality to determine the cost for a

specificaccess path. The cardinality is defined as the number of rows that should be returned by the CBO after evaluating the predicates. This is always equal to (number of input rows)* selectivity or the percent of the input rows to be returned. The selectivity plays a crucial role in determining the join order and optimal index.

– Selectivity – Cardinality – Cost

If statistics are available, then the CBO uses them to compute these characteristics. The statistics improve the accuracy.

1. Tune the IO

SelectivitySelectivity is the fraction of rows from a row set. The row set can be a

base table, a view, or the result of a join or a GROUPBY operator. The selectivity is tied to a query predicate, such as sales_date = 'Aug 08 2010', or a combination of predicates, such as sales_date = 'Aug 08 2010' AND promotion_type = 'Off Invoice'.A selectivity of 0.0 means that no rows will be selected from a row set, and a selectivity of 1.0 means that all rows will be selected.

When statistics are available, the CBO uses them to estimate selectivity. For example, for an equality predicate (sales_date = 'Aug 08 2010'), selectivity is set to the reciprocal of the number n of distinct values of sales_date, because the query selects rows that all contain one out of n distinct values.

1. Tune the IO

SelectivityIf a histogram is available on the sales_date column, the CBO uses the

histogram instead of the number of distinct values. The histogram stores the distribution of different values in a column, allowing the CBO to create better selectivity estimates. Creating histograms on columns that contain skewed data helps the CBO generate better selectivity estimates. In the case where a histogram exists, selectivity=density.

Selectivity calculations can become very complex when considering values outside of the valid range, not in predicates, and multiple predicates.

1. Tune the IO

CardinalityCardinality represents the number of rows in a row set. Here, the row set

can be a base table, a view, or the result of a join or GROUPBY operator.The values of num_distinct and density come from the user_tab_columns/user_tab_col_statistics view. We can get the number of input rows from the num_rowscolumn ofthe user_tablesview, so we can determine the cardinality as num_rows * selectivity.

1. Tune the IO

CostThe cost represents units of work or resource used. The query optimizer

uses disk I/O, CPU usage, and memory usage as units of work. So, the cost used by the query optimizer represents an estimate of the number of disk I/Os and the amount of CPU and memory used in performing an operation.

The operation can be scanning a table, accessing rows from a table by using an index, joining two tables together, or sorting a row set. The cost of a query plan is the number of work units that are expected to be incurred when the query is executed and its result produced.

1. Tune the IO

Access PathThe access path determines the number of units of work required to get

data from a base table. The access path can be a table scan, a fast full index scan, or an index scan. During a table scan or fast full index scan, multiple blocks are read from the disk in a single I/O operation. I/O is performed on blocks; the cost of a table scan or a fast full index scan depends on the number of blocks to be scanned and the multiblock read count value. The cost of an index scan depends on the levels in the B-tree, the number of index leaf blocks to be scanned, and the number of rows to be fetched using the rowid in the index keys. The cost of fetching rows using rowids depends on the indexclusteringfactor.

The joincost represents the combination of the individual access costs of the two row sets being joined, plus the cost of the join operation.

1. Tune the IO

Access PathEach table can be organized so that one index path is optimized. The

table below shows some of the indexes on the SALES_DATA table. Consider the SALES_DATA_144_IDX index.

There is one report that is the most frequently run report and takes about 40 minutes to run. By decreasing the time this report runs by 50%, we reduce the overall processing load by 20%, freeing resources to service other requests.

There are four columns in this index: ITEM_ID, LOCATION_ID, SALES_DATE,and IS_PROMOTION. By organizing the table so rows are ordered by ITEM_ID, LOCATION_ID, SALES_DATE, and IS_PROMOTION, and are in adjacent data blocks, we can reduce the load on the I/O system and improve the performance of other processes.

1. Tune the IO

Access Path

1. Tune the IO

Clustering FactorI/O by Blocks, not RowsOracle does I/O by blocks. The optimizer's decision to use full table scans

is influenced by the percentage of blocks accessed, not rows. This is called the index clustering factor. If blocks contain single rows, then rows accessed and blocks accessed are the same.

However, most tables have multiple rows in each block. Consequently, the desired number of rows could be clustered together in a few blocks, or they could be spread out over a larger number of blocks.

The clustering factor is a property of the index, the clustering factor relates to the spread of similar indexed column values within data blocks in the table. A lower clustering factor indicates that the individual rows are concentrated within fewer blocks in the table.

1. Tune the IO

Clustering FactorConversely, a high clustering factor indicates that the individual rows are

scattered more randomly across blocks in the table. Therefore, a high clustering factor means that it costs more to use a range scan to fetch rows by rowid, because more blocks in the table need to be visited to return the data.

1. Tune the IO

Reduce the I/O activity by SQL tuning

Reduce the need to do I/O by managing the workload

Gather system statistics with the DBMS_STATS package, allowing the query optimizer to accurately cost possible access paths that use full scans

Use Automatic Storage Management

Add more disks to reduce the number of I/Os for each disk

Alleviate I/O hot spots by redistributing I/O across existing disks – Striping multiple physical devices, Manually distributing IO

1. Tune the IO – Tune the CPU

IO Waits

CPU Waits

2. Tune the CPU

2. Tune the CPU

In our case, we have 4 cores with 8 threads per core and the CPU_COUNT = 32. One thread is equivalent to 3.125% of the total processing power available. The following diagram above shows one job of phase A35 receiving 3.12% of the CPU, while the other 96.88% remains unused.

2. Tune the CPU

3. Use Parallel Execution

Parallelism is the idea of breaking down a task so that, instead of one process doing all of the work, many processes do part of the work at the same time. An example of this is when 12 processes handle 12 different months in a year instead of one process handling all 12 months by itself. The improvement in performance can be quite high.

Parallel execution helps systems scale in performance by making optimal use of hardware resources. If your system's CPUs and disk controllers are already heavily loaded, you need to alleviate the system's load or increase these hardware resources before using parallel execution to improve performance.


The most common example of using parallel execution is for DSS. Complex queries, such as those involving joins or searches of very large tables, are often best run in parallel.

Parallel execution is useful for many types of operations that access significant amounts of data. Parallel execution improves performance for:– Queries – Creation of large indexes – Bulk inserts, updates, and deletes – Aggregations and copying


ALTER INDEX SALES_DATA_144_IDX (parallel 8)ALTER TABLE SALES_DATA PARALLEL (degree 16);ALTER INDEX SALES_DATA_144_IDX (parallel 16)ALTER TABLE SALES_DATA PARALLEL (degree 64);ALTER INDEX SALES_DATA_144_IDX (parallel 64)


Parallel ExecutionOracle maintains a pool of parallel slave processes for each

instance. The parallel coordinator for a SQL statement assigns parallel

tasks to slave processes from this pool. These parallel slave processes remain assigned to a task

until its execution is complete. After that, these processes return to the pool and can be

assigned tasks from some other parallel operation. A parallel slave process serves only one SQL statement at a

time.


PARALLEL_MIN_SERVERS - Specifies the minimum number of parallel slave processes for an instance. When an instance starts up, it creates the specified number of parallel slave processes. The default value for this parameter is 0, meaning that no slave processes will be created at startup.

PARALLEL_MAX_SERVERS - Specifies the maximum number of parallel slave processes that an instance is allowed to have at one time. The default value for PARALLEL_MAX_SERVERS is platform-specific.

4. Increase PARALLEL_MAX_Servers

PARALLEL_MIN_SERVERS - Specifies the minimum number of parallel slave processes for an instance. When an instance starts up, it creates the specified number of parallel slave processes. The default value for this parameter is 0, meaning that no slave processes will be created at startup.

PARALLEL_MAX_SERVERS - Specifies the maximum number of parallel slave processes that an instance is allowed to have at one time. The default value for PARALLEL_MAX_SERVERS is platform-specific.


What happens when you don't have enough parallel-execution servers available? If you start a query with a requested Degree of Parallelism of eight, but only four parallel-execution servers are available, then the number of parallel-execution servers will reach PARALLEL_MAX_SERVERS. In this case, the query will execute with a Degree of Parallelism of four — the four available parallel-execution servers will perform the task.

If there are no available parallel-execution servers, and new ones can't be started, because the limit specified by the PARALLEL_MAX_SERVERS initialization parameter has been reached. In this case, your query will execute in serial.


To identify how many parallel operations were executed with a reduced Degree of Parallelism or in serial, query the V$SYSSTAT view or look in AWR.

SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE 'Parallel%';NAME VALUEParallel operations not downgraded 9Parallel operations downgraded to serial 3Parallel operations downgraded 75 to 99 pct 0Parallel operations downgraded 50 to 75 pct 0Parallel operations downgraded 25 to 50 pct 2Parallel operations downgraded 1 to 25 pct 1

The default Degree of Parallelism with parallel_degree_policy=MANUAL is cpu_count * parallel_threads_per_cpu.

The defaults for our database: CPU_COUNT=32, parallel_threads_per_cpu = 2, or a default DOP of 64.


When we tested increasing PARALLEL_MAX_SERVERS to 512, we saw the following error:


Ultimately, the parameters that worked best for our hardware were:

PARALLEL_MIN_PERCENT= 0 (the default)PARALLEL_MAX_SERVERS= 300 (the default was 8)LARGE_POOL_SIZE = varies (dependent on machine and

memory)The performance improvement due to adjusting the

PARALLEL_MAX_SERVERS for our hardware environment was 30%.

5. Set PARALLEL_MIN_PERCENT = 0

If you set the PARALLEL_MIN_PERCENT parameter to anything higher than zero, your SQL statement will be executed only when the minimum percentage of parallel-execution servers is available.

For example, if you set PARALLEL_MIN_PERCENT to 50, and you execute a statement with a requested Degree of Parallelism of 10 when only 4 parallel-execution servers are available, your query will fail with an error message instead of executing with a reduced Degree of Parallelism, as follows:


ALTER SESSION SET PARALLEL_MIN_PERCENT = 50;INSERT /*+ PARALLEL (TEMP_SALES_DATA, 10) */ INTO TEMP_SALES_DATASELECT * FROM SALES_DATA;INSERT /*+ PARALLEL (TEMP_SALES_DATA, 10) */ INTO TEMP_SALES_DATA

*ERROR at line 1:ORA-12827: insufficient parallel query workers available


• In our testing, when we increased the PARALLEL_MAX_SERVERS, we saw CPU utilization increase from 3% to 30%. With PARALLEL_MAX_SERVERS = 8, we saw a Degree of Parallelism of about 8 and only a few processes would run at a time. When we increased the PARALLEL_MAX_SERVERS, this allowed the default Degree of Parallelism to be fully utilized, but still limited by a relatively low DOP of 64.

• The default Degree of Parallelism with parallel_degree_policy = MANUAL is cpu_count * parallel_threads_per_cpu.

• The defaults for our database: CPU_COUNT = 32, and parallel_threads_per_cpu = 2, or a default DOP of 64.

6. Set parallel_degree_policy = AUTO

The default Degree of Parallelism with parallel_degree_policy= MANUAL is cpu_count * parallel_threads_per_cpu.

The defaults for our database: CPU_COUNT = 32, parallel_threads_per_cpu = 2, or a default DOP of 64.

CPU threading for database operations is not efficient. For operations that cannot be parallelized, things just run slower. For these operations, we have the option to increase parallelization just to get back to where we started.

This was illustrated by running the patch on the old database server. Even with 10 year old CPU technology, it ran the single threaded phase A35 in 5 hours and the new T-series took 9 hours to run phase A35.


CPUs act differently than threads, but Oracle counts them like “normal” CPUs. Because of the way some servers use threads and other servers use CPUs or cores only, without threads, this affects the way Oracle calculates CPUs or CPU_COUNT and parallel_threads_per_cpu.

Assume that CPUs that have threads can do as much work as the CPUs without threads. A socket that has two cores, and each core with 8 threads, can provide can provide the processing power of 1 "normal" CPU. Each of these threads can work about 1/16 of a "normal" CPU. The CPUs with threads, get counted during the install as having 16 CPUs even though there are only 2 cores with 8 threads each.


In previous upgrades, with "normal" CPUs and with parallel_max_servers=8, processing is fine for a normal CPU environment.

However, with a threaded CPU, there needs to be more processes to use all the threads, versus the fewer processes the upgrade expects with normal CPUs.

The database was throttled by a low Degree of Parallelism (DOP) and a low value for parallel_max_servers, because of the way the database calculates these values during the install, based on the number of CPUs it thinks there are.


Prior to 11gR2, if there were insufficient parallel servers to satisfy the requested DOP, one of three things might occur:

1. The SQL would be run at a reduced DOP (be downgraded)2. The SQL would run in serial mode (be serialized)3. If PARALLEL_MIN_PERCENT was specified and less than

the nominated percentage of the DOP was achievable, then the SQL statement might terminate with ORA-12827: insufficient parallel query workers available.


There are three levels to Auto DOP:Manual – When we set PARALLEL_MAX_SERVERS to 300,

Manual would use 200 servers on one query, 100 servers on another query and then, no other queries would be run in parallel, because all the servers were used.

Limited – when accessing tables and indexes that have been defined with the parallel clause, Oracle will decide on the Degree of Parallelism based on the query and system resources. This option does not use parallelism on queries that don’t use a parallel hint.

Auto – Oracle will decide on the Degree of Parallelism for every query. In addition, two exciting new features are enabled: parallel statement queuing and in-memory parallel execution.


Parallel statement queuing is in itself a reason to use auto-DOP: When Oracle determines that a statement should run with 8 parallel processes, but only 6 are available – Oracle will not degrade the statement.

It will queue it and execute when the processes become available.

This is a huge deal. The ETL process that took 24 hours because it degraded?

Now it can queue for an hour while waiting for that index rebuild to finish, and then run with the optimal DOP, finishing just an hour later than expected and not 22 hours later.


In-memory parallel execution means that Oracle will not automatically use direct path for parallel processing I/O.

Instead, depending on the size of the object, its volatility and the size of the buffer cache, Oracle may decide to load the blocks that are needed by the query to the buffer cache.

In 11gR2, if PARALLEL_DEGREE_POLICY is AUTO, then the default behavior is instead to block the SQL from executing until enough parallel workers become available.

7. Increase parallel_threads_per_cpu

Now we have plenty of parallel servers, and parallel_degree_policyis set to AUTO. However, the system was still only using one or two threads at a time and the average CPU utilization was about 6%. Since, we are using a multi-threaded architecture, we increased parallel_threads_per_cpu from 2 to 8:

7. Increase parallel_threads_per_cpu

In our testing, when we increased the parallel_threads_per_cpufrom 2 to 8, performance really took off. Now we are seeing large numbers of jobs running very quickly with an increased load on the server. This is because the PARALLEL_MAX_SERVERS = 300 and the default DOP before increasing PARALLEL_THREADS_PER_CPU was 64. We could never use more than 64 of the 300 parallel servers.

8. Review the Release Notes

MOS Doc. ID: 761568.1, Oracle E-Business Suite Installation and Upgrade Notes Release 12 (12.1.1) for Oracle Solaris on SPARC (64-bit).

Java Performance on T-series Systems with UltraSPARC T1/T2/T2 Plus/T3/T4 processors : There was a known issue with the Java Runtime Environment (JRE) on systems with UltraSPARC T1/T2/T2 Plus/T3/T4 processors which are multi-socket, multi-core and can run multiple threads in parallel. As the JRE treats the systems using these processors (T-series systems) as a server class machine, the server can appear to be a very large CPU machine and each Java Virtual Machine (JVM) could spawn anywhere from 32 to over 256 garbage collector threads.

MOS Doc. ID: 761568.1, Oracle E-Business Suite Installation and Upgrade Notes Release 12 (12.1.1) for Oracle Solaris on SPARC (64-bit)

8. Review the Release Notes

MOS Doc. ID: 761568.1, Oracle E-Business Suite Installation and Upgrade Notes Release 12 (12.1.1) for Oracle Solaris on SPARC (64-bit)

See SPARC T4-2 Server Achieves World Record on Oracle E-Business Suite R12 Benchmark for more information about parameters to increase parallelism, see http:\www.oracle.com\us\solutions\performance-scalability\sparc-t4-2-e-business-bmark-1855323.html

For the parameters not listed in this pdf, refer to MOS Doc. ID: 396009.1, Database Initialization Parameters for Oracle Applications R12.

You can run the script from MOS Doc. ID: 174605.1, bde_chk_cbo.sql -Reports Database Initialization Parameters related to an Apps 12 or 11i instance.

9. Avoid an in-place upgrade

An in-place upgrade is an upgrade that is performed on the existing production server. There are many risks to consider if you perform an in-place upgrade.

If you plan to do an in-place upgrade, your test servers for the upgrade certainly aren’t configured the same as production and you can never get accurate timing information for your production in-place upgrade. Without the chance to test the upgrade on your production system, you can'tbe certain of the downtime required, or any other configuration issues that may take significant time to resolve.


I recommend buying a new, faster server and cloning the production system to the upgrade server, so you’ll know exactly how long it will take to upgrade.

This allows you to measure the upgrade time on the actual machine you’ll use for the production upgrade. I also recommend making the investment in your upgrade server early in your upgrade project.

This allows plenty of time upfront to tune the environment, and if it is a faster machine, having it sooner will increase how quickly your technical staff can churn out new test instances.


The other big advantage to using a separate non-production environment is that you can configure the system with new patches and files to the filesystem that you couldn’t apply to a production environment without risking potential issues for the current production environment.

For example, you can perform an operating system upgrade without the risk of applying and testing it on your production environment.

The file systems can be prepared in advance and tested repeatedly so you can know for certain that the upgrade works on that system, with those init.ora settings and kernel parameters, with the copy of the Apps Tier that was staged on a previous upgrade and the merged patches also staged in a patch directory.


Another advantage to not performing an in-place upgrade is that if the upgrade fails, you won’t have to restore the production server, because it has been left unchanged and is ready to be put back into production if necessary.

When installing the R12.1.1 software, the installer updates AutoConfig parameters in the database and entries in the oraInventory. This can make recovery to the 11i instance more complex.

An in-place upgrade is a huge risk – an error during the upgrade in which changes are made to the oraInventory and AutoConfigsettings in the database could make falling back to production require recovering from a backup instead of simply switching back to the old environment.

10. Use Event Tracing

Activating Event 10046 is a more detailed trace that that provided by alter session set sql_trace=true

Turn On Tracing for Event 10046oradebug setospid OSPID-number

oradebug unlimitoradebug event 10046 trace name context forever, level 12oradebug tracefile_name

Trace Location11g R1 and AboveIntroduced in Oracle Database 11g Release 1, traces and core files are placed in the location of the DIAGNOSTIC_DEST initialization parameter.

SQL> show parameter diagnostic_dest


Session TracingThis tracing can be used where the session is accessible to the user prior to the start of the statement(s) to be traced. To gather 10046 trace at the session level:

alter session set tracefile_identifier='10046'; alter session set timed_statistics = true;alter session set statistics_level=all;alter session set max_dump_file_size = unlimited;

alter session set events '10046 trace name context forever,level12';

-- Execute the queries or operations to be traced here --


Tracing a Process After it has StartedIf trace from an existing session is required then oradebug can be used to attach to the session and initiate 10046 tracing. The first step is to identify the session to be traced by some means. For example, in SQL*Plus, start a session to find the OS process id (spid) for the target session:

select p.PID,p.SPID,s.SIDfrom v$process p,v$session swhere s.paddr = p.addrand s.sid = &SESSION_ID/

SPID is the operating system Process identifier (os pid)PID is the Oracle Process identifier (ora pid)


Once the OS process id for the process has been determined then the trace can be initialized. Let’s assume that the process to be traced has an OSpid of 9834. Login to SQL*Plus as a sysdba and execute the following:

connect / as sysdbaoradebug setospid 9834oradebug unlimitoradebug event 10046 trace name context forever,level 12

Remember to replace the example '9834' value with the actual os pid.


The output from TKPROF shows that each time a SQL statement is run, the mcafee_sensor_mon_pkg executes. This package takes .36 seconds.


The mcafee_sensor_mon_pkg.post procedure is called when a sql statement is executed by the patch. Over the 33K SQL calls that trigger this procedure, during phase A35, we measured a total time of 11880 seconds waiting for McAfee to complete.

This equated to 3.3 hours just during phase A35, waiting for McAfee. As soon as we turned off the trigger for this event, the time to complete phase A35 was decreased to about 1 hour.

10 ways to speed up your r12.1.3 upgradeda… · 10 ways to speed up your r12.1.3 upgrade. mike...

Documents