Coverage Report doesn't run (or takes forever) #970
Comments
|
Hi did you try 3.1.7? There were improvements in terms of overall performance. |
|
Hey, I'll try it. |
|
What schema are you running coverage on? |
|
I'm running on the application schema. Not many packages/triggers. About 30 packages and 60 triggers. Shouldn't take this long. I remember running the same "Coverage Report" not so long ago and it was fine. The only big change I can recall was changing the Oracle from non-pdb to pdb. Other than that is the same. I will get utPLSQL upgraded in the server this week and will try again. Table stats seem to be fine too. |
|
Hi guys, I upgraded utPLSQL to 3.1.7 but it didn't fix the issue. Whenever I run a Coverage Report it gets stuck. The findings I have so far are:
I will be troubleshooting this today. If someone has any idea or suggestion they'd be very appreciated :) |
|
Another finding here: The DBA also pointed another related session under the module "JDBC Thin Client". He said this session was waiting due to a Don't know if that helps somehow |
|
Hey @rafael-trevisan , which version of utplsql-cli are you using? |
|
Here you go |
|
The session gets stuck waiting for PX and this is the explain plan: |
|
Another thing here. If I run within SQLDev the Coverage Report for a single package, it works: However, if I remove the filter for the objects, it gets stuck again with the same wait event in the same query. |
|
Hi guys, Some update on this. The DBA did some investigation, and after commenting out (for only testing purpose) the line 60 of The line we commented out is: If we put this line back, the session gets stuck again and never finishes. Would this be safe to use as a workaround or could that bring potentially problem that we aren't aware? |
|
I believe it will report incorrectly on lines for triggers. Would be interesting to see what executions plans are selected. |
|
I will try to get the execution plan here. Would there be a way to run the Coverage Report only for packages then? I mean, I know there are parameters to filter including/excluding object names, but am not sure about object types. |
|
I don't think so but that's probably a good enhancements idea. |
|
I do have all my source code in files. I tried to use this mapping parameter once but I didn't get much lucky. My current folder structure is: How would be the |
|
From docs: http://utplsql.org/utPLSQL/v3.1.7/userguide/coverage.html In that section of documentation there are couple good examples. |
|
Hello, Regards, |
|
Also in PDB? |
|
Yes. |
|
Well I have tried with your 'utPLSQL-demo-project-develop' and it is working so I do believe the framework do not like big schema. |
|
Hmm, the schema I’m running it isn’t that big.
The problem seems to be sub-querying the `dba_source`. If I open sqldev and do a simple query with `dba_source` within a sub-query, my session also gets stuck due to PX wait event.
I am not sure though what to do 🤔
Just by imagining all the back and forth with Oracle Support attaching logs and screenshots I already get too bored...
It seems Oracle hasn’t unit tested sub-querying the dictionary view in PDB lol
… On Jul 11, 2019, at 7:16 AM, tetardv ***@***.***> wrote:
Well I have tried with your 'utPLSQL-demo-project-develop' and it is working so I do believe the framework do not like big schema.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@rafael-trevisan, I'm not sure what is causing the problem. But your database configuration leads to a parallel query on the data dictionary views. I made some tests and forced parallel executions with various degrees. In my cases this lead to much longer execution times. Hence, I suggest to try the following based on the example you posted previously. |
|
Would be helpful to hint these queries that access the data dictionary to not run in parallel?
I am asking that because I run this report from the utPLSQL-cli and I am not sure if I can disable the parallel for that particular session.
… On Jul 12, 2019, at 12:21 AM, Philipp Salvisberg ***@***.***> wrote:
@rafael-trevisan, I'm not sure what is causing the problem. But your database configuration leads to a parallel query on the data dictionary views. I made some tests and forced parallel executions with various degrees. In my cases this lead to much longer execution times.
Hence, I suggest to try the following based on the example you posted previously.
alter session disable parallel query;
alter session disable parallel dml;
begin
ut.run(
'my_schema', ut_coverage_html_reporter()
);
end;
/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Currently, you can't make cli set specific session parameters. |
|
Shouldn't this be fixed at DB itself? |
|
hello, regards, |
@rafael-trevisan first of all we have to find the root cause. So, the questions remains. How long did the anonymous PL/SQL block ran in your environment (with disable parallel query and parallel dml)? |
|
Yes, definitely. I meant as a workaround until 2020 when Oracle replies the SR
… On Jul 12, 2019, at 5:47 AM, Jacek Gębal ***@***.***> wrote:
Shouldn't this be fixed at DB itself?
Seems like your database is misconfigured and querying dba_source goes parallel causing performance issiues.
It will be hard for utplsql to address all possible db config challenges.
We could add noparrallel hint to coverage query though I'm not sure if it's right thing to do.
We might fix it for some and break it for others.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@rafael-trevisan and what is the runtime without parallel query/dml? Without this information we do not know if this is a viable workaround. |
I'll uncomment the line |
@tetardv I suggest to run before trying to run the coverage report again. |
But we already know that commenting out this line helps and that it produces a false result. So, I suggest to test it without changing the utPLSQL code. Thanks. |
|
Hi all, disabling the parallel in the session didn't resolve the issue. It changed indeed the wait event from PX deq something to db file sequential read, but it never finished running the report. After continuing the investigation it became clear that Interestingly, line 66 seems to have thought about this issue 🤔 Anyways, in the end the DBA changed a bit the query to keep the We will post here the code he changed, but I hope this comment helps to understand and explain the issue. |
|
Thanks @rafael-trevisan The idea is to separate the more complex query (on Triggers) from the one that is more straightforward. |
|
hello, Regards, |
Can you provide the modified query text? |
Below is the change we have made. |
The coverage report doesn't run or takes forever.
version: 18.0.0.0.0
compatibility: 18.0.0
ut_version: v3.1.3.2402
Edition: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0
Port String: x86_64/Linux 2.4.xx
Information about client software
SQLDeveloper, SQLPlus, utPLSQL-cli
To Reproduce
./utplsql run ***/***@host:1521/*** -f=ut_coverage_html_reporter -o=coverage.htmlExpected behavior
A HTML file with the coverage report
Details of the issue
A couple of "utPLSQL" and "JDBC Thin Client" database sessions get stuck waiting forever for the following wait-events:
The SQL running queries are:
and
Running the tests works fine. Only the Coverage Report doesn't run.
The text was updated successfully, but these errors were encountered: