In Oracle, is there an easy way to fully unwrap a view? eg: If I have a view which is made up of selects on more views, is there some way to unwrap it to just select directly on real tables?
The concept of in-line views can be used to do this. Suppose you have these 2 views:
create or replace view london_dept as
select * from dept
where loc = 'LONDON';
and
create or replace view london_mgr as
select * from emp
where job='MANAGER'
and deptno in (select deptno from london_dept);
In the second view's SQL, the reference to view london_dept can be replaced by an in-line view using the SQL from the london_dept view definition as follows:
select * from emp
where job='MANAGER'
and deptno in (select deptno from (select * from dept
where loc = 'LONDON'));
Of course, you can now see that is overly verbose and could be simplified to:
select * from emp
where job='MANAGER'
and deptno in (select deptno from dept where loc = 'LONDON');
Finally, some advice from Tom Kyte on the advantages and disadvantages of creating views of views
Get the query text of your view.
SELECT text FROM dba_views
WHERE owner = 'the-owner' AND view_name = 'the-view-name';
Parse. Search for view names within the query text.
Get the query text for each view name found. (see item 1.)
Replace each view name in the query with the related query text.
Do this recursively until there are no more views found.
Easy?
EDIT: The above instructions do not do everything required. Thinking about this a little more it gets hairy, grows legs, and maybe another arm. Finding column names, and column names that might be elaborate functions and subqueries. Bringing it all back together with the joins and clauses. The resulting query might look very ugly.
Somewhere within Oracle there may be something that is actually unwrapping a view. I don't know. I am glad I didn't use views that much in Oracle.
Up until Oracle 12.1 the correct answer is no, there is no easy way. Now, in 12.1 there is DBMS_UTILITY.EXPAND_SQL_TEXT : Expand SQL References to Views in Oracle Database 12c Release 1 (12.1) does exactly this. See the documentation of dbms_utility
Related
I have created a user defined report within Oracle SQL Developer, with a bind variable.
The report consists of a master_report (style is table), child_report_a containing with a style of 'table' and child_report_b which is the same query, but with the style of 'script'.
I am able to select a cell/row of my master report, and child_report_a data changes accordingly (ie, it returns the cells of the same date I selected.
However, when I try to view this in child_report_b (With the 'script' style) it errors with "Missing IN or OUT parameter at index:: 1".
So the setup is:
tablea
id_pk (number)
name_pk (varchar2)
1
Jack
2
John
3
Amy
tableb
id_fk (number)
start_time(timestamp(6))
1
01-JAN-23 12.00.00.123000000
2
01-JAN-23 13.00.00.123000000
3
02-JAN-23 14.05.00.123000000
User Defined Report:
master_report (Style=Table):
SELECT * FROM tablea
child_report_a (Style=Table) & child_report_b (Style=Script):
SELECT * FROM tablea a INNER JOIN tableb b ON b.id_fk = a.id_pk WHERE trunc(start_time) = trunc(to_timestamp(:STARTTIME)
Any help is appreciated.
EDIT: Included better example of setup.
My goal is to be able to select a row from the master_report, and the child_report_b would return all results which match the date (as currently happens in child_report_a) in the script format.
Welcome to StackOverflow!
The reporting feature is one of my favorites in SQL Developer, so I will try to get you started.
We can't technically answer your question without a fair bit of guessing. We know what's happening on one side of the JOIN, you have a timestamp that you're using TRUNC on.
But we can't tell what is on the other side of the equality predicate in your JOIN.
Here's a working example, see if this helps you.
Parent Query
select trunc(systimestamp) A
from dual
Child Query
select object_name, object_type, last_ddl_time
from user_objects where :A > (trunc(systimestamp) - 30)
And the report -
To debug your report, substitute the bind :STARTTIME with a literal value that is equivalent to what your parent query would return. If that works, so should your report.
Disclaimer: I work for Oracle and am a product manager for SQL Developer.
So I am new in SQL DEVELOPER tools and I have written a simple select statement like:
SELECT * FROM employee;
it worked fine but there was a yellow warning mark underneath SELECT and I clicked on that and my query changes into the following query:
SELECT "A1"."EMPLOYEE_ID" "EMPLOYEE_ID","A1"."FIRST_NAME" "FIRST_NAME","A1"."LAST_NAME" "LAST_NAME","A1"."SALARY" "SALARY", "A1"."DEPARTMENT_ID" "DEPARTMENT_ID","A1"."MANAGER_ID" "MANAGER_ID","A1"."HIRE_DATE" "HIRE_DATE"
FROM "INTRO_USER"."EMPLOYEE" "A1";
My Quest is what is the difference between these two queries? although their output is the same
The glob * has been expanded to all column of the table. The table name EMPLOYEE is aliased to A1 to make it shorter.
The feature you are seeing is called 'SQL Text Expansion,' and it's setup to allow you to see what your query would look like if you were working with one or more VIEWS.
For example, SELECT * FROM ALL_TABLES is quite complicated. This feature allows you to see what's actually involved when running that SQL.
https://www.thatjeffsmith.com/archive/2014/12/sql-developer-and-a-12c-magic-trick/
There is probably no change or expected delta in the performance or execution plan of the 2 versions of your query.
Is it possible to get a list of used columns in a particular procedure using PL/SQL? I have to check over 500 procedures in my Oracle DB and print out all the columns used in them.
Surprisingly, Oracle does make the calculated table dependencies in PL/SQL available for viewing:
select * from user_dependencies -- can also use all_ or dba_dependencies
where type = 'PROCEDURE' and REFERENCED_TYPE = 'TABLE';
But if you really need column-level dependencies, I think it'll be much more difficult. Here's a very simple answer that'll illustrate some of the problems with the question.
select name, type, line, text, table_name, column_name
from user_source
join user_tab_cols
on text like '%'|| column_name || '%';
So you can search through all your procedures for any strings that match an existing column name. I can think of dozens of problems with this approach; the commenters above mentioned some of them, like how deep into the call stack you want to look. Or depending on how your columns are named, ambiguous names (SID, MODIFIED_DATE, etc) will produce duplicate entries. And there's no way to distinguish between actual references to column names and local variables which happen to have the same spelling. Or comments. And views or synonyms can screw up your searching. It seems like a really tough question. I hope the tables from user_dependencies will be enough for your needs.
There is a table named IM_RESULT_INFO. Because I can see it by SELECT * FROM IM_RESULT_INFO.
But it doesn't exist in table nor view lists in sqldeveloper. I also tested SELECT * FROM all_all_tables and SELECT * FROM dba_tables, and couldn't find the table.
In Eclipse IDE, I searched for it in whole project files, but the only code I found was SELECT ... FROM IM_RESULT_INFO.
I think it is a mixture of tables, but there's no way to analyze it. How can I find it?
It must be a synonym or a view, check the synonyms view to see what object is referenced by it:
SELECT *
FROM all_synonyms
WHERE synonym_name = 'IM_RESULT_INFO'
Or the views view:
SELECT *
FROM all_views
WHERE view_name = 'IM_RESULT_INFO'
You can check in ALL_OBJECTS if you are not sure about the type of an object. It will provide you the Types and other important details also.
For Materialized view please check ALL_MVIEWS.
SELECT *
FROM ALL_OBJECTS
WHERE OBJECT_NAME='IM_RESULT_INFO';
Why inline views are used..??
There are many different reasons for using inline views. Some things can't be done without inline views, for example:
1) Filtering on the results of an analytic function:
select ename from
( select ename, rank() over (order by sal desc) rnk
from emp
)
where rnk < 4;
2) Using ROWNUM on ordered results:
select ename, ROWNUM from
( select ename
from emp
order by ename
);
Other times they just make it easier to write the SQL you want to write.
The inline view is a construct in Oracle SQL where you can place a query in the SQL FROM, clause, just as if the query was a table name.
Inline views provide
Bind variables can be introduced inside the statement to limit the data
Better control over the tuning
Visibility into the code
To get top N ordered rows.
SELECT name, salary,
FROM (SELECT name, salary
FROM emp
ORDER BY salary DESC)
WHERE rownum <= 10;
An inline view can be regarded as an intermediate result set that contributes to the required data set in some way. Sometimes it is entirely a matter of improving maintainability of the code, and sometimes it is logically neccessary.
From the Oracle Database Concepts document there are the inline view concept definition:
An inline view is not a schema object.
It is a subquery with an alias
(correlation name) that you can use
like a view within a SQL statement.
About the subqueries look in Using Subqueries from the Oracle SQL Reference manual. It have a very nice pedagogic information.
Anyway, today is preferred to use the Subquery Factoring Clause that is a more powerfull way of use inline views.
As an example of all together:
WITH
dept_costs AS (
SELECT department_name, SUM(salary) dept_total
FROM employees e, departments d
WHERE e.department_id = d.department_id
GROUP BY department_name),
avg_cost AS
SELECT * FROM dept_costs
WHERE dept_total >
(SELECT avg FROM (SELECT SUM(dept_total)/COUNT(*) avg
FROM dept_costs)
)
ORDER BY department_name;
There you can see one of all:
An inline view query: SELECT SUM...
A correlated subquery: SELECT avg FROM...
A subquery factoring: dept_costs AS (...
What are they used for?:
To avoid creating an intermediate view object: CREATE VIEW ...
To simplify some queries that a view cannot be helpfull. For instance, when the view need to filter from the main query.
You will often use inline views to break your query up into logical parts which helps both readability and makes writing more complex queries a bit easier.
Jva and Tony Andrews provided some good examples of simple cases where this is useful such as Top-N or Pagination queries where you may want to perform a query and order its results before using that as a part of a larger query which in turn might feed a query doing some other processing, where the logic for these individual queries would be difficult to achieve in a single query.
Another case they can be very useful is if you are writing a query that joins various tables together and want to perform aggregation on some of the tables, separating group functions and the processing into different inline views before performing the joins makes managing cardinality a lot easier. If you want some examples, I would be happy to provide them to make it more clear.
Factored subqueries (where you list your queries in the WITH clause at the start of the query) and inline views also often bring performance benefits. If you need to access the results of the subquery multiple times, you only need to run it once and it can be materialized as a Global Temporary Table (how the optimizer acts isn't totally black and white so I won't go into it here but you can do your own research - for example, see http://jonathanlewis.wordpress.com/2007/07/26/subquery-factoring-2/)