The warning indicates the trace file has more than one distinct client identifier. That happens if the application changes its client identifier through one of the common methods: executing dbms_application_info.set_client_info, using the end-to-end metrics provided by the JDBC, or setting handle attributes in OCI applications.
The warning needs to be modified to say that profiling multiple *clients* is not recommended or something to that effect.
In your trace file you find the first client identifier on line 11, then a null one on line 72, then a different one on line 90. There are only 3 unique values but they reappear over and over again.
Our opinion, which we have spent considerable time justifying, is that the most effective way to address performance problems is to focus on a single user action and find out where the time goes.
It's ok to collect trace data for more than one task execution but if you do you should filter the trace data so that you Profile only one one task execution at a time.
And it's that mindset that caused us to add code to the Profiler that would warn the user that they are Profiling something that we don't recommend. That is, the warning is saying that the user is Profiling more than just one user task execution.
BTW, the user guide has a small paragraph about this warning. You'll find it if you look for MULTACT.
I hope this helps. Let me know if I can help further.
Last Edit: 4 years 3 months ago by Jeff Holt. Reason: spelling mistake
The administrator has disabled public write access.
Re:profiling multiple services is not recommended
4 years 3 months ago #313
This message is warning you that the trace file contains more than one combination of MODULE, ACTION, and CLIENT_ID (of DBMS_APPLICATION_INFO and DBMS_SESSION), and therefore probably contains database activity related to more than one business task. The primary purpose of the Profiler is to show where your response time is being spent - for one business task. If the measurement exceeds that one business task, then the generated profile is less helpful.
The MULTACT3 is not meant to represent data found in the trace file - that's our own error name, so that it's easy to find in the User Guide.
In a connection pooled environment, this will be common, of couse, and that's one of the reasons we created the Method R Tools product. With MRTools, you can slice and dice the trace files based on the MODULE, ACTION, and CLIENT_ID to drill down into the database activity for a set of executions for a business task. Hopefully, you set the client identifier as well, with DBMS_SESSION.SET_IDENTIFIER, so that you can drill down into each individual execution of that task.
For example, here's the output from mrskew, one of our MRTools suite for your file. I hope this helps.