Table size effect on query performance

I know this sounds like a very generic question, but, how much does table size affect the performance of a query?
This is a rather unusual case actually. I am running a query on two tables, say, Table1 and Table2. Table1 is roughly 1 million record. Whereas for Table2, I tried using different number of records.
The resultant query returns 150,000 records. If I keep Table2 to 500 records, the query execution time takes 2 minutes. But, if I increase Table2 to 8,000 records, it would take close to 20 minutes!
I have checked the "Explain plan" statement and note that the indexes for the columns used for joining the two tables are being used.
Is it normal for table size to have such a big effect on performance time, even when number of records is under the 10,000 range?
Really appreciate your inputs. Thanks in advance.

Did you update your statistics when you changed the size of Table2? The CBO will probably choose different plans as the size of Table2 changes. If it thinks there are many more or fewer rows, you're likely to have performance issues.
Justin

Similar Messages

Adding indexes to a table is slowing down query performance.

I am running a query against a table which contains approx. 4 million records in it. So I created 4 indexes on the table and noticed that the performance on my query drastically decreased. I went back and began remove and creating the indexes in different combinations. It turns out that whenever two of four indexes are created the performance worsens. The strange thing about this problem is when I do an explain plan on the query the cost is greater when the performance is better and the cost is less when the performance is worse. Also Oracle only uses one out of the four indexes on the table for this query.
I'd like to try to understand what is going on with the Oracle optimizer to try to fix this problem.

Mark,
Below is the information you requested.
DATABASE: 10.2.0.3.0
QUERY:
select distinct object, object_access from betweb_objects
where instr(object_access,'RES\') = 0
and object_access_type = 'ADM'
and object in (select distinct object
from betweb_objects
where instr(object_access,'RES\') = 0
and object_access_type = 'NTK'
and object not like '%.%'
and substr(object_access,instr(object_access,'\')+1) in (select distinct substr(object_access,instr(object_access,'\')+1)
from betweb_objects
where object_access_type = 'NTK'
and instr(object_access,'RES\') = 0
minus
select distinct upper(id)
from uamp.ad_users
where status = 'A'))
TABLE:
BETWEB_OBJECTS
OBJECT                VARCHAR2
OBJECT_ACCESS           VARCHAR2
OBJECT_ACCESS_TYPE      VARCHAR2
INDEXES ON BETWEB_OBJECTS:
BETWEB_OBJECTS_IDX1
OBJECT
BETWEB_OBJECTS_IDX2
OBJECT_ACCESS
BETWEB_OBJECTS_IDX3
OBJECT_ACCESS_TYPE
BETWEB_OBJECTS_IDX4
OBJECT_ACCESS
OBJECT_ACCESS_TYPE
TABLE:
AD_USERS
ID                VARCHAR2
DOMAIN           VARCHAR2
FNAME           VARCHAR2
LNAME           VARCHAR2
INITIALS           VARCHAR2
TITLE           VARCHAR2
DN                VARCHAR2
COMPANY           VARCHAR2
DEPARTMENT      VARCHAR2
PHONE           VARCHAR2
MANAGER           VARCHAR2
STATUS           VARCHAR2
DISPLAY_NAME      VARCHAR2
EXPLAIN PLAN when performance is better:
SELECT STATEMENT      Rows=13,414      Time=643,641      Cost=53,636,676      Bytes=6,948,452
HASH UNIQUE           Rows=13,414      Time=643,641      Cost=53,636,676      Bytes=6,948,452
HASH JOIN           Rows=694,646,835      Time=428           Cost=35,620      Bytes=359,827,060,530
VIEW VW_NSO_1           Rows=542           Time=42           Cost=3,491           Bytes=163,684
MINUS
SORT UNIQUE           Rows=542                               Bytes=9,756
INDEX FAST FULL SCAN BETWEB_OBJECTS_IDX4 Rows=26,427      Time=40           Cost=3,302           Bytes=475,686
SORT UNIQUE           Rows=16,228                          Bytes=178,508
TABLE ACCESS FULL AD_USERS Rows=16,360      Time=2           Cost=113           Bytes=179,960
HASH JOIN                Rows=128,163,623      Time=322           Cost=26,805      Bytes=27,683,342,568
TABLE ACCESS FULL BETWEB_OBJECTS Rows=9,161           Time=154           Cost=12,805      Bytes=989,388
TABLE ACCESS FULL BETWEB_OBJECTS Rows=25,106      Time=154           Cost=12,822          Bytes=2,711,448
EXPLAIN PLAN when performance is worse:
SELECT STATEMENT      Rows=13,414      Time=22,614      Cost=1,884,484      Bytes=2,897,424
HASH UNIQUE           Rows=13,414      Time=22,614      Cost=1,884,484      Bytes=2,897,424
HASH JOIN                Rows=128,163,623      Time=322           Cost=26,805      Bytes=27,683,342,568
TABLE ACCESS FULL BETWEB_OBJECTS Rows=9,161           Time=154           Cost=12,805      Bytes=989,388
TABLE ACCESS FULL BETWEB_OBJECTS Rows=25,106      Time=154           Cost=12,822      Bytes=2,711,448
MINUS
SORT UNIQUE NOSORT      Rows=209           Time=40           Cost=3,305           Bytes=3,762
INDEX FAST FULL SCAN BETWEB_OBJECTS_IDX4 Rows=264           Time=40           Cost=3,304           Bytes=4,752
SORT UNIQUE NOSORT      Rows=164           Time=2           Cost=115           Bytes=1,804
TABLE ACCESS FULL AD_USERS Rows=164           Time=2           Cost=114           Bytes=1,804

Table Sizes Optimized in Query

Hi Experts,
When I was run the query, I am not getting the data in the query but when I checked the data in the cube, the data is available there. I went RSRT there I checked the technical information in that <b>Table Sizes Optimized is showing RED</b>. What is this error How to solve this problem?
Thanks in Advance
Ravi.

Hi Ravi,
What was the fix for this issue ?
Appreciate your help.
Thanks

Excel Pivot Table with Date Hierarchies - query performance degradation

For the sake of this explanation, I’m going to try and keep it simple. Slicing the data by additional dimensions only makes the issue worse. I’ll keep this description to one fact table and three dimensions. Also, I’m fairly new to SSAS Tabular; I’ve worked
with SSAS Multidimensional in the past.
We’ve got a fact table that keeps track of bill pay payments made over time. Currently, we only have about six months of data, with the fact row count at just under 900,000 rows. The grain is daily.
There is an Account dimension (approx. 460,000 rows), with details about the individual making a payment.
There is a Payment Category dimension (approx.. 35,000 rows), which essentially groups various Payees into groups which we like to report on: Automobile Loan, Mortgage, Insurance, etc.
There is the requisite Date dimension (exactly 62093 rows-more days than we need?), which allows visibility as to what is being paid when.
Using this DW model, I’ve created a SSAS BISM Tabular model, from which Excel 2010 is ultimately used to perform some analysis, using Pivot Tables. In the tabular model, for easier navigation (doing what I’ve always done in SSAS MultiDimensional), I’ve created
several Date Hierarchies, Year-Month, Year-Quarter-Month, etc.
There are currently only two measures defined in the Tabular model: one for the “Sum of PaymentAmount”; one for the “PaymentsProcessed”.
OK, in Excel 2010, using a Pivot Table, drag the “Sum of PaymentAmount” measure to the Values section, next to/under the PivotTable Field List. Not too exciting, just the grand total of all Payments, for all time.
Drag the “YearMonth” hierarchy (from the Date dimension) to the “Column Labels” section. After expanding the year hierarchy to see the months, now the totals are for each of the months, for which we have data, for June through November, 2013.
Drag the “PaymentCategory” (from the Payment Categories dimension) to the “Report Filter” section. Filter accordingly: We just want to see the monthly totals for “Automobile Loans”.
Now, some details. Drag the “AccountSK” (hiding the actual account numbers) to the “Row Labels” section. This shows all accounts that have made Automobile Loan payments over the last six months, showing the actual payment amounts.
So far, so good. Remember, I’m using a Date Hierarchy here, in this case “YearMonth”
Now, if any of the other attributes on the Account dimension table, say “CreditScore”, or “LongName”, are subsequently dragged over to the “Row Lables” section, under the “AccountSK”, the results will never come back, before timing out or by giving up and
pressing ESCape!
If this exact scenario is done by removing the Date Hierarchy, “YearMonth” from the “Column Labels” and replace it with “Year” and “MonthName” attributes from the Date dimension, these fields not being in any sort of hierarchy, adding an additional “Account”
attribute does not cause any substantial delay.
What I’m trying to find out is why is this happening? Is there anything I can do as a work around, other than what I’ve done by not using a Date Hierarchy? Is this a known issue with DAX and the query conversion to MDX? Something else?
I’ve done a SQL Profiler trace, but I’m not sure at this point what it all means. In the MDX query there is a CrossJoin involved. There are also numerous VertiPaq Scans which seems to be going through each and every AccountSK in the Account dimension, not
just the ones filtered, to get an additional attribute (About 3,600 accounts which are “Automobile Loan” payments.).
Any thoughts?
Thanks! Happy Holidays!
AAO

Thanks for your reply Marco. I've been reading your book, too, getting into Tabular.
I've set up the Excel Pivot Table using either the Year/MonthName levels, or the YearMonth hierarchy and then adding the additional attribute for the CreditScore.
Incidentally, when using the YearMonth hierarchy and adding the CreditScore, all is well, if the Year has not been "opened". When this is done, I suspect the same thing is going on.
From SQL Profiler, each of the individual MDX queries below (formatted a bit for readability).
Thanks!
// MDX query using separate Year and MonthName levels, NO hierarchy.
SELECT
NON EMPTY
Hierarchize(
DrilldownMember(
CrossJoin(
{[Date].[Year].[All],[Date].[Year].[Year].AllMembers},
{([Date].[MonthName].[All])}
,[Date].[Year].[Year].AllMembers, [Date].[MonthName]
DIMENSION PROPERTIES PARENT_UNIQUE_NAME,HIERARCHY_UNIQUE_NAME
ON COLUMNS,
NON EMPTY
Hierarchize(
DrilldownMember(
CrossJoin(
{[Accounts].[AccountSK].[All],[Accounts].[AccountSK].[AccountSK].AllMembers},
{([Accounts].[CreditScore].[All])}
,[Accounts].[AccountSK].[AccountSK].AllMembers, [Accounts].[CreditScore]
DIMENSION PROPERTIES PARENT_UNIQUE_NAME,HIERARCHY_UNIQUE_NAME
ON ROWS
FROM [PscuPrototype]
WHERE ([PaymentCategories].[PaymentCategory].&[Automobile Loan],[Measures].[Sum of PaymentAmount])
CELL PROPERTIES VALUE, FORMAT_STRING, LANGUAGE, BACK_COLOR, FORE_COLOR, FONT_FLAGS
// MDX query using separate YearMonth hierarchy (Year, MonthName).
SELECT
NON EMPTY
Hierarchize(
DrilldownMember(
{{DrilldownLevel({[Date].[YearMonth].[All]},,,INCLUDE_CALC_MEMBERS)}},
{[Date].[YearMonth].[Year].&[2013]},,,INCLUDE_CALC_MEMBERS
DIMENSION PROPERTIES PARENT_UNIQUE_NAME,HIERARCHY_UNIQUE_NAME
ON COLUMNS,
NON EMPTY
Hierarchize(
DrilldownMember(
CrossJoin(
{[Accounts].[AccountSK].[All],[Accounts].[AccountSK].[AccountSK].AllMembers},
{([Accounts].[CreditScore].[All])}
,[Accounts].[AccountSK].[AccountSK].AllMembers, [Accounts].[CreditScore]
DIMENSION PROPERTIES PARENT_UNIQUE_NAME,HIERARCHY_UNIQUE_NAME
ON ROWS
FROM [PscuPrototype]
WHERE ([PaymentCategories].[PaymentCategory].&[Automobile Loan],[Measures].[Sum of PaymentAmount])
CELL PROPERTIES VALUE, FORMAT_STRING, LANGUAGE, BACK_COLOR, FORE_COLOR, FONT_FLAGS
AAO

Table size is too big Performance issue.

Hi,
Let us assume that we have table which has about 160 columns in it. About 120 of these columns are Varchar data type with about 100-3000 size each column.
This table also has about 2 Millions Rows in it. I am not sure if these are considered as big sized tables?
Does tables like these a good representation of data. I am in doubt as the size of the table is very big and might take long time for queries. We have about 10 indexes on this table.
What kind of precautions have to be taken when these kind of tables are involved in the database and they required for the application.
Database version is Oracle 10.2.0.4
i know the question is bit vague, but i am just wondering what needs to be done , and from where i have to start to dig into the issue just in case I get performance issues while trying to select the data or update the data.
i also want to know if there is any idle size for the tables and any thing that is more than that needs to be treated differently.
Thanking you
Rocky

Any table with more than about 50 columns should be viewed with suspicion. That doesn't mean that there aren't appropriate uses for tables with 120 or 220 columns but it does mean they are reasonably rare.
What does bother me about your first paragraph is the number of text columns with sizes up to 3K. This is highly indicative of a bad design. One thing is for sure ... no one is writing a report and printing it on anything smaller than a plotter.
2M rows is small by almost any definition so I wouldn't worry about it. Partitioning is an option but only if partition pruning will can be demonstrated to work with your queries and we haven't seen any of them nor would we have any idea what you might use as a partition key or the type of partitioning so any intelligent discussion of this option would require far more information from you.
There are no precautions that relate to anything you have written. You've told us nothing about security, usage, transaction volumes, or anything else important to such a consideration.
What needs to be done, going forward, is for someone that understands normalization to look at this table, examine the business rules, examine the purpose to which it will be put, and most importantly the reports and outputs that will be generated against it, and either justify or change the design. Then with an assessment of the table completed ... you need to run SQL and examine the plans generated using DBMS_XPLAN and timing as compared to your Service Level Agreement (SLA) with the system's customers.

How to improve Query performance on large table in MS SQL Server 2008 R2

I have a table with 20 million records. What is the best option to improve query performance on this table. Is partitioning the table into filegroups is a best option or splitting the table into multiple smaller tables?

Hi bala197164,
First, I want to inform that both to partition the table into filegroups and split the table into multiple smaller tables can improve the table query performance, and they are fit for different situation. For example, our table have one hundred columns and
some columns are not related to this table object directly (for example, there is a table named userinfo to store user information, it has columns address_street, address_zip,address_ province columns, at this time, we can create a new table named as Address,
and add a foreign key in userinfo table references Address table), under this situation, by splitting a large table into smaller, individual tables, queries that access only a fraction of the data can run faster because there is less data to scan. Another
situation is our table records can be grouped easily, for example, there is a column named year to store information about product release date, at this time, we can partition the table into filegroups to improve the query performance. Usually, we perform
both of methods together. Additionally, we can add index to table to improve the query performance. For more detail information, please refer to the following document:
Partitioning:
http://msdn.microsoft.com/en-us/library/ms178148.aspx
CREATE INDEX (Transact-SQL):
http://msdn.microsoft.com/en-us/library/ms188783.aspx
TechNet
Subscriber Support
If you are
TechNet Subscription user and have any feedback on our support quality, please send your feedback
here.
Allen Li
TechNet Community Support

DB Query to get table sizes and classification in OIM Schema

My customer's OIM Production DB size has gone upto 300 gb. They want to know why. Like they want to know "what kind of data" is the reason for such a large size of DB. Is there a way to find out, from OIM schema, what are sizes for each table (like ACT, USR etc) and classify them into User Data, Config Data, Audit Data, Recon Data, etc?
Any help is very much appreciated in this regard.
Regards
Vinay

You can categorize tables using information from below link:
http://rajnishbhatia19.blogspot.in/2008/08/oim-tables-descriptions-9011.html
You can count number of rows for tables using:
select count(*) from tablename;
Find major tables whose size is to be calculated and find avg length of a row (by adding attribute lengths defined).
Finally, calculate the table size using below query:
select TABLE_NAME, ROUND((AVG_ROW_LEN * NUM_ROWS / 1024), 2) SIZE_KB from USER_TABLES order by TABLE_NAME;
regards,
GP

Speed up table query performance

Hi,
I have a table with 200mil rows (approx 30G size). What are the multiple ways to improve query performance on this table? We have tried indexing, but doesn't help much. Partitioning - I am not sure how to use it, since there is no clear criteria for creating partitions. What other options could I use?
If this is in the wrong forum, please suggest appropriate forum.
Thanks in advance.

Assuming you have purchased the partitioning option from Oracle and are not violating the terms of your license agreement then partitioning is the way to go.
For the concept docs go to http://tahiti.oracle.com
For demos of all of the various forms of partitioning go to Morgan's Library at www.psoug.org and look up partitioning.
New partitioning options have been added in 11gR1 so some of the demos may not work for you: Most will.

Poor query performance when joining CONTAINS to another table

We just recently began evaluating Oracle Text for a search solution. We need to be able to search a table that can have over 20+ million rows. Each user may only have visibility to a tiny fraction of those rows. The goal is to have a single Oracle Text index that represents all of the searchable columns in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending order by score. What we're seeing is that query performance from TOAD is extremely fast when we write a simple CONTAINS query against the Oracle Text indexed table. However, when we attempt to first reduce the rows the CONTAINS query needs to search by using a WITH we find that the query performance degrades significantly.
For example, we can find all the records a user has access to from our base table by the following query:
SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID;
This query can execute in <100 ms. In the working example, this query returns around 1200 rows of the primary key duns_loc.
Our search query looks like this:
SELECT score(1), d.*
FROM duns d
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
The :search value in this example will be 'highway'. The query can return 246k rows in around 2 seconds.
2 seconds is good, but we should be able to have a much faster response if the search query did not have to search the entire table, right? Since each user can only "view" records they are assigned to we reckon that if the search operation only had to scan a tiny tiny percent of the TEXT index we should see faster (and more relevant) results. If we now write the following query:
WITH subset
AS
(SELECT d.duns_loc
FROM duns d
JOIN primary_contact pc
ON d.duns_loc = pc.duns_loc
AND pc.emp_id = :employeeID
SELECT score(1), d.*
FROM duns d
JOIN subset s
ON d.duns_loc = s.duns_loc
WHERE CONTAINS(TEXT_KEY, :search,1) > 0
ORDER BY score(1) DESC;
For reasons we have not been able to identify this query actually takes longer to execute than the sum of the durations of the contributing parts. This query takes over 6 seconds to run. We nor our DBA can seem to figure out why this query performs worse than a wide open search. The wide open search is not ideal as the query would end up returning records to the user they don't have access to view.
Has anyone ever ran into something like this? Any suggestions on what to look at or where to go? If anyone would like more information to help in diagnosis than let me know and i'll be happy to produce it here.
Thanks!!

Sometimes it can be good to separate the tables into separate sub-query factoring (with) clauses or inline views in the from clause or an in clause as a where condition. Although there are some differences, using a sub-query factoring (with) clause is similar to using an inline view in the from clause. However, you should avoid duplication. You should not have the same table in two different places, as in your original query. You should have indexes on any columns that the tables are joined on, your statistics should be current, and your domain index should have regular synchronization, optimization, and periodically rebuild or drop and recreate to keep it performing with maximum efficiency. The following demonstration uses a composite domain index (cdi) with filter by, as suggested by Roger, then shows the explained plans for your original query, and various others. Your original query has nested loops. All of the others have the same plan without the nested loops. You could also add index hints.
SCOTT@orcl_11gR2> -- tables:
SCOTT@orcl_11gR2> CREATE TABLE duns
2    (duns_loc NUMBER,
3      text_key VARCHAR2 (30))
4 /
Table created.
SCOTT@orcl_11gR2> CREATE TABLE primary_contact
2    (duns_loc NUMBER,
3      emp_id       NUMBER)
4 /
Table created.
SCOTT@orcl_11gR2> -- data:
SCOTT@orcl_11gR2> INSERT INTO duns VALUES (1, 'highway')
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
2 /
1 row created.
SCOTT@orcl_11gR2> INSERT INTO duns
2 SELECT object_id, object_name
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> INSERT INTO primary_contact
2 SELECT object_id, namespace
3 FROM   all_objects
4 WHERE object_id > 1
5 /
76027 rows created.
SCOTT@orcl_11gR2> -- indexes:
SCOTT@orcl_11gR2> CREATE INDEX duns_duns_loc_idx
2 ON duns (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> CREATE INDEX primary_contact_duns_loc_idx
2 ON primary_contact (duns_loc)
3 /
Index created.
SCOTT@orcl_11gR2> -- composite domain index (cdi) with filter by clause
SCOTT@orcl_11gR2> -- as suggested by Roger:
SCOTT@orcl_11gR2> CREATE INDEX duns_text_key_idx
2 ON duns (text_key)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 FILTER BY duns_loc
5 /
Index created.
SCOTT@orcl_11gR2> -- gather statistics:
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- variables:
SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
SCOTT@orcl_11gR2> EXEC :employeeid := 1
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
SCOTT@orcl_11gR2> EXEC :search := 'highway'
PL/SQL procedure successfully completed.
SCOTT@orcl_11gR2> -- original query:
SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
SCOTT@orcl_11gR2> WITH
2    subset AS
3       (SELECT d.duns_loc
4        FROM      duns d
5        JOIN      primary_contact pc
6        ON      d.duns_loc = pc.duns_loc
7        AND      pc.emp_id = :employeeID)
8 SELECT score(1), d.*
9 FROM   duns d
10 JOIN   subset s
11 ON     d.duns_loc = s.duns_loc
12 WHERE CONTAINS (TEXT_KEY, :search,1) > 0
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 4228563783
| Id | Operation                      | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                   |     2 |    84 |   121   (4)| 00:00:02 |
|   1 | SORT ORDER BY                 |                   |     2 |    84 |   121   (4)| 00:00:02 |
|* 2 |   HASH JOIN                    |                   |     2 |    84 |   120   (3)| 00:00:02 |
|   3 |    NESTED LOOPS                |                   |    38 | 1292 |    50   (2)| 00:00:01 |
|   4 |     TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 5 |      DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | DUNS_DUNS_LOC_IDX |     1 |     5 |     1   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL           | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("D"."DUNS_LOC"="PC"."DUNS_LOC")
   5 - access("CTXSYS"."CONTAINS"("D"."TEXT_KEY",:SEARCH,1)>0)
   6 - access("D"."DUNS_LOC"="D"."DUNS_LOC")
   7 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- queries with better plans (no nested loops):
SCOTT@orcl_11gR2> -- subquery factoring (with) clauses:
SCOTT@orcl_11gR2> WITH
2    subset1 AS
3       (SELECT pc.duns_loc
4        FROM      primary_contact pc
5        WHERE pc.emp_id = :employeeID),
6    subset2 AS
7       (SELECT score(1), d.*
8        FROM      duns d
9        WHERE CONTAINS (TEXT_KEY, :search,1) > 0)
10 SELECT subset2.*
11 FROM   subset1, subset2
12 WHERE subset1.duns_loc = subset2.duns_loc
13 ORDER BY score(1) DESC
14 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- inline views (sub-queries in the from clause):
SCOTT@orcl_11gR2> SELECT subset2.*
2 FROM   (SELECT pc.duns_loc
3           FROM   primary_contact pc
4           WHERE pc.emp_id = :employeeID) subset1,
5          (SELECT score(1), d.*
6           FROM   duns d
7           WHERE CONTAINS (TEXT_KEY, :search,1) > 0) subset2
8 WHERE subset1.duns_loc = subset2.duns_loc
9 ORDER BY score(1) DESC
10 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("PC"."DUNS_LOC"="D"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PC"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- ansi join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 JOIN   primary_contact
4 ON     duns.duns_loc = primary_contact.duns_loc
5 WHERE CONTAINS (duns.text_key, :search, 1) > 0
6 AND    primary_contact.emp_id = :employeeid
7 ORDER BY SCORE(1) DESC
8 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- old join:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns, primary_contact
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc = primary_contact.duns_loc
5 AND    primary_contact.emp_id = :employeeid
6 ORDER BY SCORE(1) DESC
7 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 153618227
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN                   |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2> -- in clause:
SCOTT@orcl_11gR2> SELECT SCORE(1), duns.*
2 FROM   duns
3 WHERE CONTAINS (duns.text_key, :search, 1) > 0
4 AND    duns.duns_loc IN
5          (SELECT primary_contact.duns_loc
6           FROM   primary_contact
7           WHERE primary_contact.emp_id = :employeeid)
8 ORDER BY SCORE(1) DESC
9 /
SCORE(1)   DUNS_LOC TEXT_KEY
        18          1 highway
1 row selected.
Execution Plan
Plan hash value: 3825821668
| Id | Operation                     | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|   1 | SORT ORDER BY                |                   |    38 | 1406 |    83   (5)| 00:00:01 |
|* 2 |   HASH JOIN SEMI              |                   |    38 | 1406 |    82   (4)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| DUNS              |    38 | 1102 |    11   (0)| 00:00:01 |
|* 4 |     DOMAIN INDEX              | DUNS_TEXT_KEY_IDX |       |       |     4   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS FULL          | PRIMARY_CONTACT   | 4224 | 33792 |    70   (3)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("DUNS"."DUNS_LOC"="PRIMARY_CONTACT"."DUNS_LOC")
   4 - access("CTXSYS"."CONTAINS"("DUNS"."TEXT_KEY",:SEARCH,1)>0)
   5 - filter("PRIMARY_CONTACT"."EMP_ID"=TO_NUMBER(:EMPLOYEEID))
SCOTT@orcl_11gR2>

SELECT query performance : One big table Vs many small tables

Hello,
We are using BDB 11g with SQLITE support. I have a query about 'select' query performance when we have one huge table vs. multiple small tables.
Basically in our application, we need to run select query multiple times and today we have one huge table. Do you guys think breaking them into
multiple small tables will help ?
For test purposes we tried creating multiple tables but performance of 'select' query was more or less same. Would that be because all tables will map to only one database in backed with key/value pair and when we run lookup (select query) on small table or big table it wont make difference ?
Thanks.

Hello,
There is some information on this topic in the FAQ at:
http://www.oracle.com/technology/products/berkeley-db/faq/db_faq.html#9-63
If this does not address your question, please just let me know.
Thanks,
Sandra

Give me the sql query which calculte the table size in oracle 10g ecc 6.0

Hi expert,
Please give me the sql query which calculte the table size in oracle 10g ecc 6.0.
Regards

Orkun Gedik wrote:
select segment_name, sum(bytes)/(1024*1024) from dba_segments where segment_name = '<TABLE_NAME>' group by segment_name;
Hi,
This delivers possibly wrong data in MCOD installations.
Depending on Oracle Version and Patchlevel dba_segments does not always have the correct data,
at any time esp. for indexes right after being rebuild parallel (Even in DB02 because it is using USER_SEGMENTS).
Takes a day to get the data back in line (never found out, who did the correction at night, could be RSCOLL00 ?).
Use above statement with "OWNER = " in WHERE for MCOD or connect as schema owner and use USER_SEGMENTS.
Use with
segment_name LIKE '<TABLE_NAME>%'
if you like to see the related indexes as well.
For partitioned objects, a join from dba_tables / dba_indexes to dba_tab_partitions/dba_ind_partitions to dba_segments
might be needed, esp. for hash partitioned tables, depending on how they have been created ( partition names SYS_xxxx).
Volker

Having more LTSs in logical dimension table hit the query performance?

Hi,
We have a logical table having around 19 LTSs. Having more LTSs in logical dimension table hit the query performance?
Thanks,
Anilesh

Hi Anilesh,
Its kind of both YES and NO. Here is why...
NO:
LTS are supposed to give BI Server an optimistic and logical way to retrieve the data. So, having more Optimistic LTS might help the BI Server with some good options tailored to a variety of analysis requests.
YES:
Many times, we have to bring in multiple physical tables as a part of single LTS (Mostly when the physical model is a snowflake) which might cause performance issues. Say there is a LTS with two tables "A" and "B", but for a ad-hoc analysis just on columns in "A", the query would still include the join with table "B" if this LTS is being used. We might want to avoid this kind of situations with multiple LTS each for a table and one for both of them.
Hope this helps.
Thank you,
Dhar

Effect of Restricted Keyfigure & calculated keyfigure in query performance

Hi,
What is the effect of Restricted Keyfigure & calculated keyfigure in Query Performance?
Regards
Anil

As compared to formulas that are evaluated during query execution, calculated key figures are pre-calculated and their definitions are stored in the metadata repository for reuse in queries. The incorporation of business metrics and key performance indicators as calculated key figures, such as gross profit and return on investment (which are frequently used, widely understood, and rarely changed), improve query performance and ensure that calculated key figures are reported consistently by different users. Note that this approach improves query runtime performance but slows InfoCube or ODS object update time. As a rule of thumb, if multiple and frequently used queries use the same formula to compute calculated fields, use calculated key figures instead of formulas.
RKFs result in additional database processing and complexity in retrieving the query result and therefore should be avoided when possible.
other than performance, there might be other considerations to determine which one of the options should be used.
If the RKF's are query specific and not used anywhere in majority of other queries, I would go for structure selections. And from my personal exp, sometimes all the developers end up with so many RKF and CKF's that you get easily lost in the web and not to mention the duplication.
if the same structure is needed widely across most of the queries, that might be a good idea to have global structure to be available across the provider, which might considerable cut down the development time.

Query to find indexes bigger in size than tables sizes

Team -
I am looking for a query to find the list of indexes in a schema or in a entire database which are bigger in size than the respective tables size .
Db version : Any
Thanks
Venkat

results are the same in my case
1 select di.owner, di.index_name, di.table_name
2 from dba_indexes di, dba_segments ds
3 where ds.blocks > (select dt.blocks
4               from dba_tables dt
5               where di.owner = dt.owner
6               and di.leaf_blocks > dt.blocks
7               and   di.table_name = dt.table_name)
8* and ds.segment_name = di.index_name
SQL> /
OWNER                      INDEX_NAME                TABLE_NAME
SYS                      I_CON1                     CON$
SYS                      I_OBJAUTH1                OBJAUTH$
SYS                      I_OBJAUTH2                OBJAUTH$
SYS                      I_PROCEDUREINFO1            PROCEDUREINFO$
SYS                      I_DEPENDENCY1                DEPENDENCY$
SYS                      I_ACCESS1                ACCESS$
SYS                      I_OID1                     OID$
SYS                      I_PROCEDUREC$                PROCEDUREC$
SYS                      I_PROCEDUREPLSQL$           PROCEDUREPLSQL$
SYS                      I_WARNING_SETTINGS           WARNING_SETTINGS$
SYS                      I_WRI$_OPTSTAT_TAB_OBJ#_ST     WRI$_OPTSTAT_TAB_HISTORY
SYS                      I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST WRI$_OPTSTAT_HISTGRM_HISTORY
SYS                      WRH$_PGASTAT_PK                WRH$_PGASTAT
SYSMAN                      MGMT_STRING_METRIC_HISTORY_PK MGMT_STRING_METRIC_HISTORY
DBADMIN                  TSTNDX                     TSTTBL
15 rows selected

Query Performance Issues on a cube sized 64GB.

Hi,
We have a non-time based cube whose size is 64 GB . Effectively, I can't use time dimension for partitioning. The transaction table has ~ 850 million records. We have 20+ dimensions among which 2 of the dimensions have 50 million records.
I have equally distributed the fact table records among 60 partitions. Each partition size is around 900 MB.
The processing of the cube is not an issue as it completes in 3.5 hours. The issue is with the query performance of the cube.
When an MDX query is submitted, unfortunately, in majority of the cases the storage engine has to scan all the partitions (as our cube is not time dependent and we can't find a suitable dimension that will fit the bill to partition measure group based
on it.)
I'm aware of the cache warming and usage based aggregation(UBO) techniques.
However, the cube is available for users to perform adhoc queries and hence the benefits of cache warming and UBO may cease to contribute to the performance gain as there is a high probability that each user may look at the data from different perspectives
(especially when we have 20 + dimensions) as day(s) progress.
Also, we have 15 + average calculations (calculated measures) in the cube. So, the storage engine sends all the granular data that the formula engine might have requested (could be millions of rows) and then perform the average calculation.
A look at the profiler suggested that considerable amount of time has been spent by storage engine to gather the records (from 60 partitions).
FYI - Our server has RAM 32 GB and 8 cores and it is exclusive to Analysis Services.
I would appreciate comments from anyone who has worked on a large cube that is not time dependent and the steps they took to improve the adhoc query performance for the users.
Thanks
CoolP

Hello CoolP,
Here is a good articles regarding how to tuning query performance in SSAS, please see:
Analysis Services Query Performance Top 10 Best Practices:
http://technet.microsoft.com/en-us/library/cc966527.aspx
Hope you can find some helpful clues to tuning your SSAS Server query performance. Moreover, there are two ways to improve the query response time for an increasing number of end-users:
Adding more power to the existing server (scale up)
Distributing the load among several small servers (scale out)
For detail information, please see:
http://technet.microsoft.com/en-us/library/cc966449.aspx
Regards,
Elvis Long
TechNet Community Support

Table size effect on query performance

Similar Messages

Maybe you are looking for