-
Notifications
You must be signed in to change notification settings - Fork 186
temporary tablespace usage #1169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
You should probably consider limiting the packages that are getting reported. If you want to gather coverage on entire schema containing 2400+ packages, consider the lines of code that will be scanned and reported back in HTML report.
See this section of coverage documentation |
You could also try using different coverage reporter (I suggest Coveralls) and see if you face the same problem. Also, can you perhaps provide full error stack? It could be valuable to see at which statement it actually failed. |
Hi, here are your answers and some observations
if ut_run syntax is
then after about 5 minutes this is what I receive back exactly
if ut_run syntax is
runs fine but in about 1 minute (!)
is 2,595,931 (lines) and 152 (size_MB) |
update: I forgot to say and it maybe related that installation was done with session parameter securefile=none also running with
takes 6 minutes the first time (ie. after running for full schema or with coveralls) |
Hi @dsnz
One more question One more request declare
l_coverage_run_id raw(32);
begin
l_coverage_run_id := 'A6AA5B7361251CE6E053020011ACA055';
-- l_coverage_run_id := sys_guid;
ut_runner.coverage_start(l_coverage_run_id);
ut.run('<package>');
ut_runner.coverage_stop();
end;
/
--now you can try different coverage reporters passing the persisted ID of coverage run.
select * from table( ut_coverage_html_reporter().get_report(
a_coverage_options => ut_coverage_options(
include_objects => ut_varchar2_list('<package2>', '<package3>'),
coverage_run_id => 'A6AA5B7361251CE6E053020011ACA055'
)
) ); Make sure the coverage run is different each time you execute |
Hi @jgebal ,
after that I run the select as you said but it fails due to bad argument types for this time I watched more closely how space was consumed in the temp tablespace and I saw that not all was consumed |
Thanks @dsnz We would need to investigate if it's the actual data in GTT table that is used or is it the SQL Query running into some odd execution plan. From the line number where the execution fails, it seems that it's the query itself. So we would need to understand what is going on in your system that querying data dictionary is causing problems. To do that, can you check if:
with
trigger_source_offsets as (
select min(s.line) - 1 offset, s.owner, s.name, s.type
... This is the SQL that is failing. Is this your local database or a shared DB installed on some server? |
Hi, here are the experiments I did according to your requests (and some more)
but it still fails with unable to extend temp segment message there is also a new dbms_xplan.display_cursor for child cursor 1 (after gathering system statistics)
and it run successfully in about 5m (!) |
Is the problem still reproducible after gathering data-dictionary statistics? |
Would you be able to try installing utPLSQL referenced feature branch?
This, plus one more optimization, caused the plan to change
To (after change):
In your plans, the problem was line:
Where you have 20G/158G of temp used to do a With the proposed change the SORT-MERGE-ANTI-JOIN should be replaced with more optimal HASH-JOIN-RIGHT-ANTI. This will prevent the temp consumption for SORT operation. |
@dsnz I'm closing this issue for now and consider it resolved. |
Hi,
I have installed latest utplsql v3.1.11 on a 19.3.0.0.0 for a training initially and then hopefully for real development testing.
The database is not managed by me but I have access to enough system views,
In the schema that the tests will be run there are about 2400+ packages
For a simple test suite, the standard text reporter returns instantly the result.
However the html reporter with coverage is stuck for a long time and then ends with
ORA-01652: unable to extend temp segment by ... in tablespace ...
The database has a 32 GB temp tablespace which is almost all free and I can verify from dba_temp_free_space that
when starting the test all free space is being eaten away until the error message comes out.
I have found that I can limit the scope of coverage to certain packages and run the test
(though 1 minute runtime for a single package of 150 lines seems excessive)
but it is desired to test the whole software in the end (and have coverage for all packages).
The amount of 32 GB seems too big. Furthermore I have no guidance on how to estimate the total necessary temp size in GB
in order to tell the administrators.
So I would like to ask:
The text was updated successfully, but these errors were encountered: