Home » RDBMS Server » Performance Tuning » performance doubt (11.2.0.2.0)
performance doubt [message #519360] Thu, 11 August 2011 05:44 Go to next message
shashank_kurasrediffmail
Messages: 63
Registered: July 2011
Location: hyderabad
Member

hi all I have a doubt

base on performance it is better to retrive data from view or mention the table names directly?

I have a select statement in from clause one of my table is view (which is having data collected from four tables) my question is whether performance of querry will be improved if i use directly all tables( four tables of a view) instead of a view
Re: performance doubt [message #519362 is a reply to message #519360] Thu, 11 August 2011 05:58 Go to previous messageGo to next message
Michel Cadot
Messages: 68716
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator
Quote:
base on performance it is better to retrive data from view or mention the table names directly?

If you don't need a view then don't define a view.
If you need the view then, teh question does not matter as anyway you need the view.

Quote:
I have a select statement in from clause one of my table is view (which is having data collected from four tables) my question is whether performance of querry will be improved if i use directly all tables( four tables of a view) instead of a view

It depends on the definition of the view and the query.

Regards
Michel
Re: performance doubt [message #519363 is a reply to message #519362] Thu, 11 August 2011 06:07 Go to previous messageGo to next message
shashank_kurasrediffmail
Messages: 63
Registered: July 2011
Location: hyderabad
Member

hi michel,
thanks for reply

my view having four table . but my required data exists only in two tables of a view (remaining two table in a view are unnecessary ) in this case which is better?

[Updated on: Thu, 11 August 2011 06:07]

Report message to a moderator

Re: performance doubt [message #519364 is a reply to message #519363] Thu, 11 August 2011 06:34 Go to previous messageGo to next message
cookiemonster
Messages: 13958
Registered: September 2008
Location: Rainy Manchester
Senior Member
Go directly to the tables.
Re: performance doubt [message #519366 is a reply to message #519364] Thu, 11 August 2011 07:35 Go to previous messageGo to next message
Michel Cadot
Messages: 68716
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator
I agree.

Regards
Michel
Re: performance doubt [message #519368 is a reply to message #519366] Thu, 11 August 2011 08:09 Go to previous messageGo to next message
cookiemonster
Messages: 13958
Registered: September 2008
Location: Rainy Manchester
Senior Member
Generally I think views should be written to answer a specific question. If you want an answer to a different question don't use the view, go to the base tables or create a new view that does what you need.

I've had to rewrite a lot of code where developers had joined views, or nested views, which resulted in queries that either accessed the base tables more times than necessary or accessed tables that weren't needed to get the answer. Unsurprisingly this led to a number of performance problems.
Joining and nesting views can work if each view only accesses one table, but as soon as the views start joining tables you shouldn't try joining or nesting them. Also if you need a query that only needs a subset of what a view does, avoid the view.
Re: performance doubt [message #519372 is a reply to message #519368] Thu, 11 August 2011 09:25 Go to previous messageGo to next message
shashank_kurasrediffmail
Messages: 63
Registered: July 2011
Location: hyderabad
Member

hi michel and cookiemonster,

thanks for explaing clearly.
I avoided view and I took the tables which are necessary and time reduced from 2:51 sec to 1:51 sec ..

thanks for all ..

Re: performance doubt [message #520822 is a reply to message #519360] Wed, 24 August 2011 20:25 Go to previous messageGo to next message
Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA
Senior Member
Depends on many factors some of which have been noted:

1) issue is really, what are your design goals for your system.

2) ** my opinion ** I like views. They let you create ideas in your database beyond simple tables and enforce the idea across applications and queries so that results are consistent.

3) your question is related to the phenomenon known as DUNSEL JOIN REMOVAL. If your databse is designed well, then in the newer versions of Oracle, the issue is resolved somewhat by query optimizations, more so in 11g than 10g. Under the right circumstances, Oracle is able to figure out that the tables are not needed and will remove them from the query before it executes it. Consider this:

SELECT EMP.*
FROM EMP,DEPT
WHERE DEPT.DEPT_ID = EMP.DEPT_ID;


is the above query the same as the below query?

SELECT EMP.*
FROM EMP;


Answer: don't know. It depends. Consder this:

create table emp(emp_id integer not null
                  ,dept_id integer not null)

alter table emp add constraint emp_fk1 foreign key (dept_id) references dept;


Are the two queries the same now? Answer: YES. If they are the same then why do the join to DEPT? Answer: don't bother. If we don't need to do the join, does the CBO know this? Answer: depends, you running 9i or 10g or 11g?


SQL> create table dept
  2  (
  3     dept_id integer not null primary key
  4  )
  5  /

Table created.

SQL> create table emp
  2  (
  3     emp_id integer not null primary key
  4   , dept_id integer not null
  5  )
  6  /

Table created.

SQL> alter table emp add foreign key (dept_id) references dept
  2  /

Table altered.

SQL> set autotrace on
SQL>
SQL> select dept.*
  2  from emp,dept
  3  where dept.dept_id = emp.dept_id
  4  /

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 3956160932

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    13 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMP  |     1 |    13 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
        222  recursive calls
          0  db block gets
         47  consistent gets
          0  physical reads
          0  redo size
        335  bytes sent via SQL*Net to client
        508  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
          0  rows processed

SQL>


Notice anything interesting about the plan vs. the query?

Good luck, Kevin
Re: performance doubt [message #520869 is a reply to message #520822] Thu, 25 August 2011 03:25 Go to previous messageGo to next message
cookiemonster
Messages: 13958
Registered: September 2008
Location: Rainy Manchester
Senior Member
Of course that only works where foreign keys are defined so it's probably not a good idea to rely on it to dig you out of holes.
Re: performance doubt [message #520917 is a reply to message #520869] Thu, 25 August 2011 07:45 Go to previous message
Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA
Senior Member
very true. I get so frustrated with the number of systems I deal with daily that failed to do basic design. 99% of all performance problems are fixed before they ever happen, by managing the basics before code is written.

Kevin
Previous Topic: Insert / Update Performance due to Triggers (merged 2)
Next Topic: SGA_TARGET and shared pool
Goto Forum:
  


Current Time: Fri Nov 22 02:05:21 CST 2024