10gR2 Spatital + Partitioning Performance Issues
I'm trying to get spatial working reasonably with a (range) partitioned table, containing a single 2D point value, all local indexes.
If I query directly against a single partition, or have a restriction which "prunes" down to one partition, perfromance is reasonabe, and the plan looks like this;
Rows Row Source Operation
1 SORT AGGREGATE (cr=3303 pr=0 pw=0 time=1598104 us)
2596 PARTITION RANGE SINGLE PARTITION: 2 2 (cr=3303 pr=0 pw=0 time=1584119 us)
2596 TABLE ACCESS BY LOCAL INDEX ROWID FOO PARTITION: 2 2 (cr=3303 pr=0 pw=0 time=1581494 us)
2596 DOMAIN INDEX FOO_SDX (cr=707 pr=0 pw=0 time=1550312 us)
If my query is a bit looser, and ends up hitting 2 or more partitions, things degrade substantially, and I end up with a plan like this:
Rows Row Source Operation
1 SORT AGGREGATE (cr=10472 pr=0 pw=0 time=6592543 us)
5188 PARTITION RANGE INLIST PARTITION: KEY(INLIST) KEY(INLIST) (cr=10472 pr=0 pw=0 time=3349053 us)
5188 TABLE ACCESS BY LOCAL INDEX ROWID FOO PARTITION: KEY(INLIST) KEY(INLIST) (cr=10472 pr=0 pw=0 time=6586055 us)
5188 BITMAP CONVERSION TO ROWIDS (cr=5955 pr=0 pw=0 time=6539205 us)
2 BITMAP AND (cr=5955 pr=0 pw=0 time=6539145 us)
2 BITMAP CONVERSION FROM ROWIDS (cr=514 pr=0 pw=0 time=209088 us)
5188 SORT ORDER BY (cr=514 pr=0 pw=0 time=206661 us)
5188 DOMAIN INDEX FOO_SDX (cr=514 pr=0 pw=0 time=158447 us)
12 BITMAP OR (cr=5441 pr=0 pw=0 time=7052201 us)
6 BITMAP CONVERSION FROM ROWIDS (cr=2650 pr=0 pw=0 time=3356960 us)
1000000 SORT ORDER BY (cr=2650 pr=0 pw=0 time=3173026 us)
1000000 INDEX RANGE SCAN PK_FOO_IDX PARTITION: KEY(INLIST) KEY(INLIST) (cr=2650 pr=0 pw=0 time=193 us)(object id 63668)
6 BITMAP CONVERSION FROM ROWIDS (cr=2791 pr=0 pw=0 time=3292124 us)
1000000 SORT ORDER BY (cr=2791 pr=0 pw=0 time=3153435 us)
1000000 INDEX RANGE SCAN PK_FOO_IDX PARTITION: KEY(INLIST) KEY(INLIST) (cr=2791 pr=0 pw=0 time=1000160 us)(object id 63668)
Now this is a simple test case. My real situation is a bit more complex, with more data, more partitions, and another table joined in to do the partition pruning, but it comes down to the same issues.
I've tried various hints, but have not been able to change the plan substantially.
I've written a similar test case with btree indexes and it does not have these problems, and actually does pretty good with simple MBR type queries.
I'll post another message with the spatial test case script...
--Peter
Here is the test script (kind of long):
--create a partitioned table with local spatial index...
create table foo (
pid number not null, --partition_id
id number not null,
location MDSYS.SDO_GEOMETRY null --needs to be null for CTAS to work
PARTITION BY RANGE (pid) (
PARTITION P0 VALUES LESS THAN (1)
create index pk_foo_idx on foo(pid, id) local;
alter table foo add constraint pk_foo
primary key (pid, id)using index pk_foo_idx;
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'FOO',
'LOCATION',
mdsys.sdo_dim_array(
mdsys.sdo_dim_element('Longitude', -180, 180, 50),
mdsys.sdo_dim_element('Latitude', -90, 90, 50)
8307);
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'FOO1',
'LOCATION',
mdsys.sdo_dim_array(
mdsys.sdo_dim_element('Longitude', -180, 180, 50),
mdsys.sdo_dim_element('Latitude', -90, 90, 50)
8307);
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'FOO2',
'LOCATION',
mdsys.sdo_dim_array(
mdsys.sdo_dim_element('Longitude', -180, 180, 50),
mdsys.sdo_dim_element('Latitude', -90, 90, 50)
8307);
commit;
--local spatial index on main partitioned table
CREATE INDEX foo_sdx ON foo (location)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('layer_gtype=POINT') LOCAL;
--staging tables for exchanging with partitions later
create table foo1 as select * from foo where 1=2;
create table foo2 as select * from foo where 1=2;
declare
v_lon number;
v_lat number;
begin
for i in 1..1000000 loop
v_lat := DBMS_RANDOM.value * 20;
v_lon := DBMS_RANDOM.value * 20;
insert into foo1 (pid, id, location) values
(1, i, MDSYS.SDO_GEOMETRY(2001,8307,MDSYS.SDO_POINT_TYPE(v_lon,v_lat,null),NULL,NULL));
insert into foo2 (pid, id, location) values
(2, 1000000+i, MDSYS.SDO_GEOMETRY(2001,8307,MDSYS.SDO_POINT_TYPE(v_lon,v_lat,null),NULL,NULL));
end loop;
end;
commit;
--index everything the same way
create index pk_foo_idx1 on foo1(pid, id);
alter table foo1 add constraint pk_foo1
primary key (pid, id)using index pk_foo_idx1;
create index pk_foo_idx2 on foo2(pid, id);
alter table foo2 add constraint pk_foo2
primary key (pid, id)using index pk_foo_idx2;
CREATE INDEX foo_sdx1 ON foo1 (location)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('layer_gtype=POINT');
CREATE INDEX foo_sdx2 ON foo2 (location)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
PARAMETERS ('layer_gtype=POINT');
exec dbms_stats.gather_table_stats(user, 'FOO', cascade=>true);
exec dbms_stats.gather_table_stats(user, 'FOO1', cascade=>true);
exec dbms_stats.gather_table_stats(user, 'FOO2', cascade=>true);
alter table foo add partition p1 values less than (2);
alter table foo add partition p2 values less than (3);
alter table foo exchange partition p1 with table foo1 including indexes;
alter table foo exchange partition p2 with table foo2 including indexes;
drop table foo1;
drop table foo2;
--ok, now lets run some queries
set timing on
alter session set events '10046 trace name context forever, level 12';
--easy one, single partition (trace ET=0.18s)
select count(*) from (
select d.pid, d.id
from foo partition(p1) d
where
sdo_filter(d.location, SDO_geometry(
2003,8307,NULL,
SDO_elem_info_array(1,1003,3),
SDO_ordinate_array(0.1,0.1, 1.1,1.1))
) = 'TRUE'
Rows Row Source Operation
1 SORT AGGREGATE (cr=3303 pr=0 pw=0 time=1598104 us)
2596 PARTITION RANGE SINGLE PARTITION: 2 2 (cr=3303 pr=0 pw=0 time=1584119 us)
2596 TABLE ACCESS BY LOCAL INDEX ROWID FOO PARTITION: 2 2 (cr=3303 pr=0 pw=0 time=1581494 us)
2596 DOMAIN INDEX FOO_SDX (cr=707 pr=0 pw=0 time=1550312 us)
--partition pruning works for 1 partition (trace ET=0.18s),
--uses pretty much the same plan as above
select count(*) from (
select d.pid, d.id
from foo d
where
d.pid = 1 and
sdo_filter(d.location, SDO_geometry(
2003,8307,NULL,
SDO_elem_info_array(1,1003,3),
SDO_ordinate_array(0.1,0.1, 1.1,1.1))
) = 'TRUE'
--heres where the trouble starts (trace ET=6.59s)
select count(*) from (
select d.pid, d.id
from foo d
where
d.pid in (1,2) and
sdo_filter(d.location, SDO_geometry(
2003,8307,NULL,
SDO_elem_info_array(1,1003,3),
SDO_ordinate_array(0.1,0.1, 1.1,1.1))
) = 'TRUE'
Rows Row Source Operation
1 SORT AGGREGATE (cr=10472 pr=0 pw=0 time=6592543 us)
5188 PARTITION RANGE INLIST PARTITION: KEY(INLIST) KEY(INLIST) (cr=10472 pr=0 pw=0 time=3349053 us)
5188 TABLE ACCESS BY LOCAL INDEX ROWID FOO PARTITION: KEY(INLIST) KEY(INLIST) (cr=10472 pr=0 pw=0 time=6586055 us)
5188 BITMAP CONVERSION TO ROWIDS (cr=5955 pr=0 pw=0 time=6539205 us)
2 BITMAP AND (cr=5955 pr=0 pw=0 time=6539145 us)
2 BITMAP CONVERSION FROM ROWIDS (cr=514 pr=0 pw=0 time=209088 us)
5188 SORT ORDER BY (cr=514 pr=0 pw=0 time=206661 us)
5188 DOMAIN INDEX FOO_SDX (cr=514 pr=0 pw=0 time=158447 us)
12 BITMAP OR (cr=5441 pr=0 pw=0 time=7052201 us)
6 BITMAP CONVERSION FROM ROWIDS (cr=2650 pr=0 pw=0 time=3356960 us)
1000000 SORT ORDER BY (cr=2650 pr=0 pw=0 time=3173026 us)
1000000 INDEX RANGE SCAN PK_FOO_IDX PARTITION: KEY(INLIST) KEY(INLIST) (cr=2650 pr=0 pw=0 time=193 us)(object id 63668)
6 BITMAP CONVERSION FROM ROWIDS (cr=2791 pr=0 pw=0 time=3292124 us)
1000000 SORT ORDER BY (cr=2791 pr=0 pw=0 time=3153435 us)
1000000 INDEX RANGE SCAN PK_FOO_IDX PARTITION: KEY(INLIST) KEY(INLIST) (cr=2791 pr=0 pw=0 time=1000160 us)(object id 63668)
--this performs better but is ugly and non-general (trace ET=0.35s)
select count(*) from (
select d.pid, d.id
from foo d
where
d.pid = 1 and
sdo_filter(d.location, SDO_geometry(
2003,8307,NULL,
SDO_elem_info_array(1,1003,3),
SDO_ordinate_array(0.1,0.1, 1.1,1.1))
) = 'TRUE'
UNION ALL
select d.pid, d.id
from foo d
where
d.pid = 2 and
sdo_filter(d.location, SDO_geometry(
2003,8307,NULL,
SDO_elem_info_array(1,1003,3),
SDO_ordinate_array(0.1,0.1, 1.1,1.1))
) = 'TRUE'
);
Similar Messages
-
Performance issues with version enable partitioned tables?
Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
Object Name Rows Bytes Cost Object Node In/Out PStart PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE 1 249
UPDATE SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI 1 266 249
PARTITION RANGE ALL 1 9
TABLE ACCESS FULL SIG.SIG_QUA_IMG_LT 1 259 2 1 9
VIEW SYS.VW_NSO_1 1 7 247
NESTED LOOPS 1 739 247
NESTED LOOPS 1 677 247
NESTED LOOPS 1 412 246
NESTED LOOPS 1 114 244
INDEX RANGE SCAN WMSYS.MODIFIED_TABLES_PK 1 62 2
INDEX RANGE SCAN SIG.QIM_PK 1 52 243
TABLE ACCESS BY GLOBAL INDEX ROWID SIG.SIG_QUA_IMG_LT 1 298 2 ROWID ROW L
INDEX RANGE SCAN SIG.SIG_QUA_IMG_PKI$ 1 1
INDEX RANGE SCAN WMSYS.WM$NEXTVER_TABLE_NV_INDX 1 265 1
INDEX UNIQUE SCAN WMSYS.MODIFIED_TABLES_PK 1 62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben -
Insert performance issue with Partitioned Table.....
Hi All,
I have a performance issue during with a table which is partitioned. without table being partitioned
it ran in less time but after partition it took more than double.
1) The table was created initially without any partition and the below insert took only 27 minuts.
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:27:35.20
2) Now I re-created the table with partition(range yearly - below) and the same insert took 59 minuts.
Is there anyway i can achive the better performance during insert on this partitioned table?
[ similerly, I have another table with 50 Million records and the insert took 10 hrs without partition.
with partitioning the table, it took 18 hours... ]
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4195045590
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 643K| 34M| | 12917 (3)| 00:02:36 |
|* 1 | HASH JOIN | | 643K| 34M| 2112K| 12917 (3)| 00:02:36 |
| 2 | VIEW | index$_join$_001 | 69534 | 1290K| | 529 (3)| 00:00:07 |
|* 3 | HASH JOIN | | | | | | |
| 4 | INDEX FAST FULL SCAN| PK_ACCOUNT_MASTER_BASE | 69534 | 1290K| | 181 (3)| 00:00
| 5 | INDEX FAST FULL SCAN| ACCOUNT_MASTER_BASE_IDX2 | 69534 | 1290K| | 474 (2)| 00:00
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | TB_SISADMIN_BALANCE | 2424K| 87M| | 6413 (4)| 00:01:17 |
Predicate Information (identified by operation id):
1 - access("A"."VENDOR_ACCT_NBR"=SUBSTR("B"."ACCOUNT_NO",1,8) AND
"A"."VENDOR_CD"="B"."COMPANY_NO")
3 - access(ROWID=ROWID)
Open C1;
Loop
Fetch C1 Bulk Collect Into C_Rectype Limit 10000;
Forall I In 1..C_Rectype.Count
Insert test
col1,col2,col3)
Values
val1, val2,val3);
V_Rec := V_Rec + Nvl(C_Rectype.Count,0);
Commit;
Exit When C_Rectype.Count = 0;
C_Rectype.delete;
End Loop;
End;
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:51:01.22
Edited by: user520824 on Jul 16, 2010 9:16 AMI'm concerned about the view in step 2 and the index join in step 3. A composite index with both columns might eliminate the index join and result in fewer read operations.
If you know which partition the data is going into beforehand you can save a little bit of processing by specifying the partition (which may not be a scalable long-term solution) in the insert - I'm not 100% sure you can do this on inserts but I know you can on selects.
The APPEND hint won't help the way you are using it - the VALUES clause in an insert makes it be ignored. Where it is effective and should help you is if you can do the insert in one query - insert into/select from. If you are using the loop to avoid filling up undo/rollback you can use a bulk collect to batch the selects and commit accordingly - but don't commit more often than you have to because more frequent commits slow transactions down.
I don't think there is a nologging hint :)
So, try something like
insert /*+ hints */ into ...
Select
A.Ing_Acct_Nbr, currency_Symbol,
Balance_Date, Company_No,
Substr(Account_No,1,8) Account_No,
Substr(Account_No,9,1) Typ_Cd ,
Substr(Account_No,10,1) Chk_Cd,
Td_Balance, Sd_Balance,
Sysdate, 'Sisadmin'
From Ideaal_Cons.Tb_Account_Master_Base A,
Ideaal_Staging.Tb_Sisadmin_Balance B
Where A.Vendor_Acct_Nbr = Substr(B.Account_No,1,8)
And A.Vendor_Cd = b.company_no
;Edited by: riedelme on Jul 16, 2010 7:42 AM -
Performance issues with pipelined table functions
I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
TYPE resultset_typ IS REF CURSOR;
TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
TYPE table_typ IS TABLE OF row_typ;
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ;
c_default_limit CONSTANT PLS_INTEGER := 100;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ
IS
o_resultset resultset_typ;
BEGIN
OPEN o_resultset FOR
SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB;
RETURN o_resultset;
END base_query;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
IS
aa_source_data table_typ;-- := table_typ ();
BEGIN
LOOP
FETCH p_source_data
BULK COLLECT INTO aa_source_data
LIMIT p_limit_size;
EXIT WHEN aa_source_data.COUNT = 0;
/* Process the batch of (p_limit_size) records... */
FOR i IN 1 .. aa_source_data.COUNT
LOOP
PIPE ROW (aa_source_data (i));
END LOOP;
END LOOP;
CLOSE p_source_data;
RETURN;
END processor;
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT /*+ PARALLEL(t, 5) */ colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM TABLE (processor (base_query (argA, argB),100)) t
GROUP BY colC
ORDER BY colC
END with_pipeline;
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM (SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB)
GROUP BY colC
ORDER BY colC;
END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PMEarthlink wrote:
Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701 -
Many-to-many performance issue
I realize that many-to-many joins have been discussed before (yes, I looked through many threads), but I'm having a slight variation on the issue. Our data warehouse has been functioning for a couple of years now, but we're now experiencing a dramatic degradation in report performance. I'll tell you everything I know and what I've tried. My hope is that someone will have an idea that hasn't occurred to me yet.
The troubling data links deal with accounts and account_types. Each transaction will have one account, but each account can have multiple account_types and each account_type is made up of multiple accounts. It ends up looking like this:
Transaction_cube --< account_dimension >--< account_type_table
Given the many-to-many relationship between account and account_type, this is the only architecture I could come up with that will maintain data integrity in the transaction cube.
I know that this is the cause of the performance issues because the reports run normally when this is removed. The volume of data obviously increases over time, but the problem appeared very suddenly -- not a gradual degradation that one would expect from a volume issue. The cube is partitioned by year and we're a little below last year's growth.
The other fact to throw in is that the account_type table did increase in size by an additional 30% when we first noticed the problem. However, the business was able to go back and remove half of the account_types (unused types) so now the table has fewer rows than it had before we noticed the problem (~15k rows in the account_type table).
We have tried pinning the table so that it remain in memory, but that did not help. I tried creating a materialized view combining accounts and account_types with a similar lack of improvement. I've tried adding indexes, but there is still a full-table scan. All database objects are analyzed nightly after the data load is completed.
I'm fresh out of ideas at this point. Any suggestions and/or ideas would be greatly appreciated.I've thought about that. What it would mean would be aprox. 20 additional columns for each of the different account_types. Unfortunately, that would also mean that all the reports that use the account_type would have to have a condition:
WHERE acct_type1='Income Stmt." OR acct_type2='Income Stmt." OR ....
Since the account_types are not set up in a hierarchy and there must be only one row for account, I'm not sure that this is a feasible solution.
Thank you for the suggestion. -
QUERY PERFORMANCE AND DATA LOADING PERFORMANCE ISSUES
WHAT ARE QUERY PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES...PLZ URGENT
WHAT ARE DATALOADING PERFORMANCE ISSUES WE NEED TO TAKE CARE PLEASE EXPLAIN AND LET ME KNOW T CODES PLZ URGENT
WILL REWARD FULL POINT S
REGARDS
GURUBW Back end
Some Tips -
1)Identify long-running extraction processes on the source system. Extraction processes are performed by several extraction jobs running on the source system. The run-time of these jobs affects the performance. Use transaction code SM37 Background Processing Job Management to analyze the run-times of these jobs. If the run-time of data collection jobs lasts for several hours, schedule these jobs to run more frequently. This way, less data is written into update tables for each run and extraction performance increases.
2)Identify high run-times for ABAP code, especially for user exits. The quality of any custom ABAP programs used in data extraction affects the extraction performance. Use transaction code SE30 ABAP/4 Run-time Analysis and then run the analysis for the transaction code RSA3 Extractor Checker. The system then records the activities of the extraction program so you can review them to identify time-consuming activities. Eliminate those long-running activities or substitute them with alternative program logic.
3)Identify expensive SQL statements. If database run-time is high for extraction jobs, use transaction code ST05 Performance Trace. On this screen, select ALEREMOTE user and then select SQL trace to record the SQL statements. Identify the time-consuming sections from the results. If the data-selection times are high on a particular SQL statement, index the DataSource tables to increase the performance of selection (see no. 6 below). While using ST05, make sure that no other extraction job is running with ALEREMOTE user.
4)Balance loads by distributing processes onto different servers if possible. If your site uses more than one BW application server, distribute the extraction processes to different servers using transaction code SM59 Maintain RFC Destination. Load balancing is possible only if the extraction program allows the option
5)Set optimum parameters for data-packet size. Packet size affects the number of data requests to the database. Set the data-packet size to optimum values for an efficient data-extraction mechanism. To find the optimum value, start with a packet size in the range of 50,000 to 100,000 and gradually increase it. At some point, you will reach the threshold at which increasing packet size further does not provide any performance increase. To set the packet size, use transaction code SBIW BW IMG Menu on the source system. To set the data load parameters for flat-file uploads, use transaction code RSCUSTV6 in BW.
6)Build indexes on DataSource tables based on selection criteria. Indexing DataSource tables improves the extraction performance, because it reduces the read times of those tables.
7)Execute collection jobs in parallel. Like the Business Content extractors, generic extractors have a number of collection jobs to retrieve relevant data from DataSource tables. Scheduling these collection jobs to run in parallel reduces the total extraction time, and they can be scheduled via transaction code SM37 in the source system.
8). Break up your data selections for InfoPackages and schedule the portions to run in parallel. This parallel upload mechanism sends different portions of the data to BW at the same time, and as a result the total upload time is reduced. You can schedule InfoPackages in the Administrator Workbench.
You can upload data from a data target (InfoCube and ODS) to another data target within the BW system. While uploading, you can schedule more than one InfoPackage with different selection options in each one. For example, fiscal year or fiscal year period can be used as selection options. Avoid using parallel uploads for high volumes of data if hardware resources are constrained. Each InfoPacket uses one background process (if scheduled to run in the background) or dialog process (if scheduled to run online) of the application server, and too many processes could overwhelm a slow server.
9). Building secondary indexes on the tables for the selection fields optimizes these tables for reading, reducing extraction time. If your selection fields are not key fields on the table, primary indexes are not much of a help when accessing data. In this case it is better to create secondary indexes with selection fields on the associated table using ABAP Dictionary to improve better selection performance.
10)Analyze upload times to the PSA and identify long-running uploads. When you extract the data using PSA method, data is written into PSA tables in the BW system. If your data is on the order of tens of millions, consider partitioning these PSA tables for better performance, but pay attention to the partition sizes. Partitioning PSA tables improves data-load performance because it's faster to insert data into smaller database tables. Partitioning also provides increased performance for maintenance of PSA tables for example, you can delete a portion of data faster. You can set the size of each partition in the PSA parameters screen, in transaction code SPRO or RSCUSTV6, so that BW creates a new partition automatically when a threshold value is reached.
11)Debug any routines in the transfer and update rules and eliminate single selects from the routines. Using single selects in custom ABAP routines for selecting data from database tables reduces performance considerably. It is better to use buffers and array operations. When you use buffers or array operations, the system reads data from the database tables and stores it in the memory for manipulation, improving performance. If you do not use buffers or array operations, the whole reading process is performed on the database with many table accesses, and performance deteriorates. Also, extensive use of library transformations in the ABAP code reduces performance; since these transformations are not compiled in advance, they are carried out during run-time.
12)Before uploading a high volume of transaction data into InfoCubes, activate the number-range buffer for dimension IDs. The number-range buffer is a parameter that identifies the number of sequential dimension IDs stored in the memory. If you increase the number range before high-volume data upload, you reduce the number of reads from the dimension tables and hence increase the upload performance. Do not forget to set the number-range values back to their original values after the upload. Use transaction code SNRO to maintain the number range buffer values for InfoCubes.
13)Drop the indexes before uploading high-volume data into InfoCubes. Regenerate them after the upload. Indexes on InfoCubes are optimized for reading data from the InfoCubes. If the indexes exist during the upload, BW reads the indexes and tries to insert the records according to the indexes, resulting in poor upload performance. You can automate the dropping and regeneration of the indexes through InfoPackage scheduling. You can drop indexes in the Manage InfoCube screen in the Administrator Workbench.
14)IDoc (intermediate document) archiving improves the extraction and loading performance and can be applied on both BW and R/3 systems. In addition to IDoc archiving, data archiving is available for InfoCubes and ODS objects.
Hope it Helps
Chetan
@CP.. -
Performance issue of frequently data inserted tables
Hi all,
Have a table named raw_trap_store having columns as trap_id(number,PK),Source_IP(varchar2), OID(varchar2),Message(CLOB) and received_time(date).
This table is partitioned across 24 partitions where partitioning column being received_time. (every hour's data will be stored in each partition).
This table is getting inserted with 40-50 records/sec on an average. Overall number of records for a day will be around 2.8-3 million. Data will be retained for 2 days.
No updates will be happening on this table.
Performance issue:N
Need a report which involves selection of records from this table based on certain values of Source IP (filtering condition on source_ip column).
Need a report which involves selection of records from this table based on certain values of OID (filtering condition on OID column).
But, if i create an index on SourceIP and OID column, then inserts are getting slow. (have created a normal index. not partitioned index)
Please help me to address the above issue.Giving the nature of your report (based on Source_IP and OID) and the nature of your table partitioning (range partitioned by received_time), you have already made a good decision to create these particular indexes as a normal (b-tree or global) and not locally partitioned. Because if you have locally partitioned them, your reports will not eliminate partitions (because they do not include the partition key in their where clause) and hence your index range scans will scan all 24 partitions generating a lot of logical I/O
That is said, remember that generally we insert once and select many times. You have to balance that. If you are sure that it is the creation of your two indexes that has decreased the insert performance then you may set them at in an unusable state before the insert and rebuild them after. But this might be a good advice only if the volume of data to be inserted is much bigger than the existing volume of data before the insert.
And if you are not deleting from the table and the table does not contain triggers and integrity constraints (like FK constraint) then you can opt for a direct path insert using the hint /*+ append */
Best regards
Mohamed Houri
<mod. action: removed unecessary blog ref.>
Message was edited by: Nicolas.Gasparotto -
Performance issue with two unbanalnced hierarchies in a single report
Hi All
We are facing the performance issue with one of the report which houses two unbalanced hierarchies (having 18 levels) - skipped & ragged. Basically its a part of OBIAPPS financila analytics .
The query is below :
Could anyone let me know how to improve the performane. Any parameter that should be looked at while using unbalanced hierarchies.
WITH SAWITH0
AS ( SELECT SUM (T91707.OTHER_LOC_AMT) AS c1,
MAX (T314768.HIER2_CODE) AS c2,
MAX (T314768.HIER3_CODE) AS c3,
MAX (T314768.HIER4_CODE) AS c4,
MAX (T314768.HIER5_CODE) AS c5,
MAX (T314768.HIER6_CODE) AS c6,
MAX (T314768.HIER7_CODE) AS c7,
MAX (T314768.HIER8_CODE) AS c8,
MAX (T314768.HIER9_CODE) AS c9,
MAX (T314768.HIER10_CODE) AS c10,
MAX (T314768.HIER11_CODE) AS c11,
MAX (T314768.HIER12_CODE) AS c12,
MAX (T314768.HIER13_CODE) AS c13,
MAX (T314768.HIER14_CODE) AS c14,
MAX (T314768.HIER15_CODE) AS c15,
MAX (T314768.HIER16_CODE) AS c16,
MAX (T314768.HIER17_CODE) AS c17,
MAX (T314768.HIER18_CODE) AS c18,
MAX (T314768.HIER19_CODE) AS c19,
MAX (T314768.HIER20_CODE) AS c20,
T314768.HIER1_NAME AS c21,
T314768.HIER1_CODE AS c22,
T314914.HIER1_NAME AS c24,
T314914.HIER10_NAME AS c25,
T314914.HIER11_NAME AS c26,
T314914.HIER12_NAME AS c27,
T314914.HIER13_NAME AS c28,
T314914.HIER14_NAME AS c29,
T314914.HIER15_NAME AS c30,
T314914.HIER16_NAME AS c31,
T314914.HIER17_NAME AS c32,
T314914.HIER18_NAME AS c33,
T314914.HIER19_NAME AS c34,
T314914.HIER2_NAME AS c35,
T314914.HIER20_NAME AS c36,
T314914.HIER3_NAME AS c37,
T314914.HIER4_NAME AS c38,
T314914.HIER5_NAME AS c39,
T314914.HIER6_NAME AS c40,
T314914.HIER7_NAME AS c41,
T314914.HIER8_NAME AS c42,
T314914.HIER9_NAME AS c43,
T314914.HIER20_CODE AS c44,
T314914.HIER1_CODE AS c45,
T314914.HIER10_CODE AS c46,
T314914.HIER11_CODE AS c47,
T314914.HIER12_CODE AS c48,
T314914.HIER13_CODE AS c49,
T314914.HIER14_CODE AS c50,
T314914.HIER15_CODE AS c51,
T314914.HIER16_CODE AS c52,
T314914.HIER17_CODE AS c53,
T314914.HIER18_CODE AS c54,
T314914.HIER19_CODE AS c55,
T314914.HIER2_CODE AS c56,
T314914.HIER3_CODE AS c57,
T314914.HIER4_CODE AS c58,
T314914.HIER5_CODE AS c59,
T314914.HIER6_CODE AS c60,
T314914.HIER7_CODE AS c61,
T314914.HIER8_CODE AS c62,
T314914.HIER9_CODE AS c63
FROM W_HIERARCHY_D T314768 /* Dim_W_HIERARCHY_D_Segment11 */
W_GL_SEGMENT_D T315677 /* Dim_W_GL_SEGMENT_D_Segment11 */
W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
WHERE ( T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91397.ACCOUNT_SEG11_CODE = T315677.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG11_ATTRIB = T315677.SEGMENT_LOV_ID
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T314768.HIER_CODE = T315677.SEGMENT_LOV_ID
AND T314768.HIER_NAME = T315677.SEGMENT_LOV_NAME
AND T314768.HIERARCHY_ID = T315677.SEGMENT_VAL_CODE
AND T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T315677.SEGMENT_LOV_NAME =
'Responsibility_Centre_Functional'
AND T315677.SEGMENT_LOV_ID = 1000163
AND T315731.SEGMENT_LOV_NAME = 'Account_Master'
AND T315731.SEGMENT_LOV_ID = 1000165
AND ( T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER11_CODE IS NULL)
AND (T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER12_CODE IS NULL)
AND ( T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER8_CODE IS NULL)
AND ( T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER9_CODE IS NULL)
AND ( T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER10_CODE IS NULL)
AND ( T314914.HIER1_CODE IN ('ALL_LI')
OR T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022'))
AND ( T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER2_CODE IS NULL)
AND ( T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER3_CODE IS NULL)
AND ( T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER4_CODE IS NULL)
AND ( T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER5_CODE IS NULL)
AND ( T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER6_CODE IS NULL)
AND ( T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER7_CODE IS NULL)
AND T314768.HIER1_CODE IS NOT NULL
AND T314914.HIER20_CODE IS NOT NULL
AND T314914.HIER13_CODE IS NULL
AND T314914.HIER14_CODE IS NULL
AND T314914.HIER15_CODE IS NULL
AND T314914.HIER16_CODE IS NULL
AND T314914.HIER17_CODE IS NULL
AND T314914.HIER18_CODE IS NULL
AND T314914.HIER19_CODE IS NULL)
GROUP BY T314768.HIER1_CODE,
T314768.HIER1_NAME,
T314914.HIER1_CODE,
T314914.HIER1_NAME,
T314914.HIER2_CODE,
T314914.HIER2_NAME,
T314914.HIER3_CODE,
T314914.HIER3_NAME,
T314914.HIER4_CODE,
T314914.HIER4_NAME,
T314914.HIER5_CODE,
T314914.HIER5_NAME,
T314914.HIER6_CODE,
T314914.HIER6_NAME,
T314914.HIER7_CODE,
T314914.HIER7_NAME,
T314914.HIER8_CODE,
T314914.HIER8_NAME,
T314914.HIER9_CODE,
T314914.HIER9_NAME,
T314914.HIER10_CODE,
T314914.HIER10_NAME,
T314914.HIER11_CODE,
T314914.HIER11_NAME,
T314914.HIER12_CODE,
T314914.HIER12_NAME,
T314914.HIER13_CODE,
T314914.HIER13_NAME,
T314914.HIER14_CODE,
T314914.HIER14_NAME,
T314914.HIER15_CODE,
T314914.HIER15_NAME,
T314914.HIER16_CODE,
T314914.HIER16_NAME,
T314914.HIER17_CODE,
T314914.HIER17_NAME,
T314914.HIER18_CODE,
T314914.HIER18_NAME,
T314914.HIER19_CODE,
T314914.HIER19_NAME,
T314914.HIER20_CODE,
T314914.HIER20_NAME),
SAWITH1
AS (SELECT SUM (D1.c1) OVER () AS c1,
MAX (D1.c2) OVER (PARTITION BY D1.c22) AS c2,
MAX (D1.c3) OVER (PARTITION BY D1.c22) AS c3,
MAX (D1.c4) OVER (PARTITION BY D1.c22) AS c4,
MAX (D1.c5) OVER (PARTITION BY D1.c22) AS c5,
MAX (D1.c6) OVER (PARTITION BY D1.c22) AS c6,
MAX (D1.c7) OVER (PARTITION BY D1.c22) AS c7,
MAX (D1.c8) OVER (PARTITION BY D1.c22) AS c8,
MAX (D1.c9) OVER (PARTITION BY D1.c22) AS c9,
MAX (D1.c10) OVER (PARTITION BY D1.c22) AS c10,
MAX (D1.c11) OVER (PARTITION BY D1.c22) AS c11,
MAX (D1.c12) OVER (PARTITION BY D1.c22) AS c12,
MAX (D1.c13) OVER (PARTITION BY D1.c22) AS c13,
MAX (D1.c14) OVER (PARTITION BY D1.c22) AS c14,
MAX (D1.c15) OVER (PARTITION BY D1.c22) AS c15,
MAX (D1.c16) OVER (PARTITION BY D1.c22) AS c16,
MAX (D1.c17) OVER (PARTITION BY D1.c22) AS c17,
MAX (D1.c18) OVER (PARTITION BY D1.c22) AS c18,
MAX (D1.c19) OVER (PARTITION BY D1.c22) AS c19,
MAX (D1.c20) OVER (PARTITION BY D1.c22) AS c20,
D1.c21 AS c21,
D1.c22 AS c22,
SUM (
D1.c1)
OVER (
PARTITION BY D1.c46,
D1.c47,
D1.c48,
D1.c49,
D1.c50,
D1.c51,
D1.c52,
D1.c53,
D1.c54,
D1.c55,
D1.c45,
D1.c44,
D1.c56,
D1.c57,
D1.c58,
D1.c59,
D1.c60,
D1.c61,
D1.c62,
D1.c63,
D1.c22)
AS c23,
D1.c24 AS c24,
D1.c25 AS c25,
D1.c26 AS c26,
D1.c27 AS c27,
D1.c28 AS c28,
D1.c29 AS c29,
D1.c30 AS c30,
D1.c31 AS c31,
D1.c32 AS c32,
D1.c33 AS c33,
D1.c34 AS c34,
D1.c35 AS c35,
D1.c36 AS c36,
D1.c37 AS c37,
D1.c38 AS c38,
D1.c39 AS c39,
D1.c40 AS c40,
D1.c41 AS c41,
D1.c42 AS c42,
D1.c43 AS c43,
D1.c44 AS c44,
D1.c45 AS c45,
D1.c46 AS c46,
D1.c47 AS c47,
D1.c48 AS c48,
D1.c49 AS c49,
D1.c50 AS c50,
D1.c51 AS c51,
D1.c52 AS c52,
D1.c53 AS c53,
D1.c54 AS c54,
D1.c55 AS c55,
D1.c56 AS c56,
D1.c57 AS c57,
D1.c58 AS c58,
D1.c59 AS c59,
D1.c60 AS c60,
D1.c61 AS c61,
D1.c62 AS c62,
D1.c63 AS c63
FROM SAWITH0 D1)
SELECT DISTINCT
38 AS c1,
D1.c24 AS c2,
D1.c25 AS c3,
D1.c26 AS c4,
D1.c27 AS c5,
D1.c28 AS c6,
D1.c29 AS c7,
D1.c30 AS c8,
D1.c31 AS c9,
D1.c32 AS c10,
D1.c33 AS c11,
D1.c34 AS c12,
D1.c35 AS c13,
D1.c36 AS c14,
D1.c37 AS c15,
D1.c38 AS c16,
D1.c39 AS c17,
D1.c40 AS c18,
D1.c41 AS c19,
D1.c42 AS c20,
D1.c43 AS c21,
D1.c21 AS c22,
NULL AS c23,
NULL AS c24,
NULL AS c25,
NULL AS c26,
NULL AS c27,
NULL AS c28,
NULL AS c29,
NULL AS c30,
NULL AS c31,
NULL AS c32,
NULL AS c33,
NULL AS c34,
NULL AS c35,
NULL AS c36,
NULL AS c37,
NULL AS c38,
NULL AS c39,
NULL AS c40,
NULL AS c41,
D1.c44 AS c42,
D1.c45 AS c43,
D1.c46 AS c44,
D1.c47 AS c45,
D1.c48 AS c46,
D1.c49 AS c47,
D1.c50 AS c48,
D1.c51 AS c49,
D1.c52 AS c50,
D1.c53 AS c51,
D1.c54 AS c52,
D1.c55 AS c53,
D1.c56 AS c54,
D1.c57 AS c55,
D1.c58 AS c56,
D1.c59 AS c57,
D1.c60 AS c58,
D1.c61 AS c59,
D1.c62 AS c60,
D1.c63 AS c61,
NULL AS c62,
D1.c22 AS c63,
NULL AS c64,
NULL AS c65,
NULL AS c66,
NULL AS c67,
NULL AS c68,
NULL AS c69,
NULL AS c70,
NULL AS c71,
NULL AS c72,
NULL AS c73,
NULL AS c74,
NULL AS c75,
NULL AS c76,
NULL AS c77,
NULL AS c78,
NULL AS c79,
NULL AS c80,
NULL AS c81,
D1.c23 AS c82,
CASE WHEN 1 = 1 THEN 1 ELSE 0 END AS c83,
CASE
WHEN D1.c2 IS NULL
AND D1.c3 IS NULL
AND D1.c4 IS NULL
AND D1.c5 IS NULL
AND D1.c6 IS NULL
AND D1.c7 IS NULL
AND D1.c8 IS NULL
AND D1.c9 IS NULL
AND D1.c10 IS NULL
AND D1.c11 IS NULL
AND D1.c12 IS NULL
AND D1.c13 IS NULL
AND D1.c14 IS NULL
AND D1.c15 IS NULL
AND D1.c16 IS NULL
AND D1.c17 IS NULL
AND D1.c18 IS NULL
AND D1.c19 IS NULL
AND D1.c20 IS NULL
THEN
1
ELSE
0
END
AS c84
FROM SAWITH1 D1
WHERE ( D1.c44 IS NOT NULL
AND D1.c50 IS NULL
AND D1.c49 IS NULL
AND D1.c22 IS NOT NULL
AND D1.c51 IS NULL
AND D1.c52 IS NULL
AND D1.c53 IS NULL
AND D1.c54 IS NULL
AND D1.c55 IS NULL)
/* Formatted on 12/17/2012 7:49:44 PM (QP5 v5.139.911.3011) */
WITH OBICOMMON0
AS (SELECT T156337.ROW_WID AS c2,
T156337.MCAL_PERIOD_WID AS c3,
ROW_NUMBER ()
OVER (PARTITION BY T156337.MCAL_PERIOD_WID
ORDER BY T156337.MCAL_PERIOD_WID DESC)
AS c4,
T156337.MCAL_PERIOD_NAME AS c5,
T156337.MCAL_PER_NAME_YEAR AS c6
FROM W_MCAL_DAY_D T156337 /* Dim_W_MCAL_DAY_D_Fiscal_Day */
WHERE (T156337.MCAL_CAL_NAME = 'Accounting')),
SAWITH0
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c2 AS c2,
D1.c3 AS c3
FROM OBICOMMON0 D1),
SAWITH1
AS (SELECT DISTINCT
MIN (D1.c1) OVER (PARTITION BY D1.c3) AS c1, D1.c2 AS c2
FROM SAWITH0 D1),
SAWITH2
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c3 AS c2,
D1.c5 AS c3,
D1.c6 AS c4
FROM OBICOMMON0 D1),
SAWITH3 AS (SELECT DISTINCT MIN (D1.c1) OVER (PARTITION BY D1.c2) AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4
FROM SAWITH2 D1),
SAWITH4
AS ( SELECT SUM (T91707.TD_OTHER_REP_AMT) AS c1,
T314914.HIER1_NAME AS c2,
D2.c3 AS c3,
T314914.HIER1_CODE AS c4,
D2.c2 AS c5
FROM W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
SAWITH1 D4,
SAWITH3 D2
WHERE ( T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91707.ACCT_PERIOD_END_DT_WID = D4.c2
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T315731.SEGMENT_LOV_NAME =
'Account_Retail_Distribution'
AND T315731.SEGMENT_LOV_ID = 1000165
AND D2.c1 = D4.c1
AND (D2.c4 IN ('2011', '2012')))
GROUP BY T314914.HIER1_CODE,
T314914.HIER1_NAME,
D2.c2,
D2.c3)
SELECT D1.c1 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c5 AS c5,
D1.c6 AS c6
FROM ( SELECT DISTINCT 0 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c1 AS c5,
D1.c5 AS c6
FROM SAWITH4 D1
ORDER BY c2 NULLS FIRST, c4 NULLS FIRST, c3) D1
WHERE ROWNUM <= 65001Hello Gurus, Experts
Any help/tips here ... -
Experiencing strange performance issues after a hard drive failure - Help!
I bought my mid-2012 i5 Macbook Pro in December of 2012. I realized when shopping for computers that I wanted an SSD installed, but that it would be a lot cheaper if I bought the SSD and installed it rather than customizing it in the Apple Store. So I bought a nice Samsung 128GB SSD (820 or 840 - can't remember which) and did the installation. I went ahead and installed two 4GB sticks of RAM while I was at it. Everything was just dandy: my boot time was just under 9 seconds, and all of my data-heavy apps booted in no-time at all. Then all **** broke loose.
About two weeks ago, I opened my computer and I got the dreaded "? File Folder" notification with a gray screen. I immediately thought hard drive failure. No matter how many times I tried to boot, the computer just would not talk to the SSD anymore. I used Internet Recovery to get into my Disk Utility, and the entire partition was gone. I assumed the worst but wanted to be sure - I bought a hard drive enclosure and hooked the SSD up to an older Macbook, and lo and behold: it worked perfectly. I was not only able to recover data, but I could write data to the drive. Nothing appeared wrong with the drive when I plugged it into the old Macbook, but my newer Macbook still would not recognize it. Even my fiance's Windows 7 PC recognized the drive as "?" (since it was formatted for Mac, but hey - it recognized that it existed!).
I decided to re-install the original HDD that came with the 2012 Macbook Pro (the one I removed in favor of the SSD). I was able to re-install the OS and I can boot up at will, but everything is different. The performance issues are extremely noticeable. I can't have more than two programs running at one time without the spinning wheel of death appearing. My boot time went from 9 seconds to 2 minutes. I know that SSDs increase performance, so there is some slight performance downgrade to be expected since I am using a mechanical drive now -- but these are not normal issues. Sometimes I can't even type a web address into Safari without the wheel appearing. iTunes, and specifically the App Store, take minutes to open - and I have no media is on iTunes.
Here's the thing: I have tried just about anything to fix this problem that Google can pull up. I've verified the HDD, I've booted into Safe Mode, reset RAM and cache, run benchmarks and other performance tests, entered all sorts of weird language into Command Prompt, and studied Activity Monitor - I can't find a single red flag that would indicate anything being wrong. It appears to be a perfectly functioning, updated computer.
I'm thinking a piece of hardware failed that triggered the error with the SSD. I'm not really sure though since all of my performance tests indicate perfectly functioning hardware. I'm a little afraid to take it to the Apple store because I know they'll tell me it's my fault for opening the computer and replacing the hard drive in the first place.
Any ideas? At this point anything to salvage this computer would be helpful.Spin Cycle,
were those other computers which were able to recognize your SSD in its external enclosure also Macs? Do you know if your SSD has its most recent firmware revision installed? (If it doesn’t, its installer can be downloaded from the Samsung SSD firmware page for burning onto a bootable DVD.) I haven’t used the 830 myself, so I don’t know what its reputation is with Macs. I have an 840 PRO in my MacBook Pro, which has been trouble-free for me, but my understanding is that the 840 EVO has had trouble with Macs in its earlier firmware revisions — so I’m wondering if the 830 has a known track record with Macs, good or bad. -
Oracle 11g Migration performance issue
Hello,
There a performance issue with Migration from Oracle 10g(10.2.0.5) to Oracle 11g(11.2.0.2).
Its very simple statement hanging for more than a day and later found that query plan is very very bad. Example of the query is given below:
INSERT INTO TABLE_XYZ
SELECT F1,F2,F3
FROM TABLE_AB, TABLE_BC
WHERE F1=F4;
While looking at cost in Explain plan :
on 10g --> 62567
0n 11g --> 9879652356776
Strange thing is that
Scenario 1: if I issue just query as shown below, will display rows immediately :
SELECT F1,F2,F3
FROM TABLE_AB, TABLE_BC
WHERE F1=F4;
Scenario 2: If I create a table as shown below, will work correctly.
CREATE TABLE TABLE_XYZ AS
SELECT F1,F2,F3
FROM TABLE_AB, TABLE_BC
WHERE F1=F4;
What could be the issue here with INSERT INTO <TAB> SELECT <COL> FROM <TAB1>?Table:
CREATE TABLE AVN_WRK_F_RENEWAL_TRANS_T
"PKSRCSYSTEMID" NUMBER(4,0) NOT NULL ENABLE,
"PKCOMPANYCODE" VARCHAR2(8 CHAR) NOT NULL ENABLE,
"PKBRANCHCODE" VARCHAR2(8 CHAR) NOT NULL ENABLE,
"PKLINEOFBUSINESS" NUMBER(4,0) NOT NULL ENABLE,
"PKPRODUCINGOFFICELIST" VARCHAR2(2 CHAR) NOT NULL ENABLE,
"PKPRODUCINGOFFICE" VARCHAR2(8 CHAR) NOT NULL ENABLE,
"PKEXPIRYYR" NUMBER(4,0) NOT NULL ENABLE,
"PKEXPIRYMTH" NUMBER(2,0) NOT NULL ENABLE,
"CURRENTEXPIRYCOUNT" NUMBER,
"CURRENTRENEWEDCOUNT" NUMBER,
"PREVIOUSEXPIRYCOUNT" NUMBER,
"PREVIOUSRENEWEDCOUNT" NUMBER
SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT
TABLESPACE "XYZ" ;
Explain Plan(With Insert Statement and Query):_
INSERT STATEMENT, GOAL = ALL_ROWS Cost=9110025395866 Cardinality=78120 Bytes=11952360
LOAD TABLE CONVENTIONAL Object owner=ODS Object name=AVN_WRK_F_RENEWAL_TRANS
NESTED LOOPS OUTER Cost=9110025395866 Cardinality=78120 Bytes=11952360
TABLE ACCESS FULL Object owner=ODS Object name=AVN_WRK_F_RENEWAL_TRANS_1ST Cost=115 Cardinality=78120 Bytes=2499840
VIEW PUSHED PREDICATE Object owner=ODS Cost=116615788 Cardinality=1 Bytes=121
SORT GROUP BY Cost=116615788 Cardinality=3594 Bytes=406122
VIEW Object owner=SYS Object name=VW_DAG_1 Cost=116615787 Cardinality=20168 Bytes=2278984
SORT GROUP BY Cost=116615787 Cardinality=20168 Bytes=4073936
NESTED LOOPS OUTER Cost=116614896 Cardinality=20168 Bytes=4073936
VIEW Object owner=SYS Cost=5722 Cardinality=20168 Bytes=2157976
NESTED LOOPS Cost=5722 Cardinality=20168 Bytes=2097472
HASH JOIN Cost=924 Cardinality=1199 Bytes=100716
NESTED LOOPS
NESTED LOOPS Cost=181 Cardinality=1199 Bytes=80333
TABLE ACCESS BY INDEX ROWID Object owner=ODS Object name=INWARDSPOLICYDETAILS Cost=159 Cardinality=1199 Bytes=39567
INDEX RANGE SCAN Object owner=ODS Object name=IX_INWPOLDTLS_SYSCOMPANYBRANCH Cost=7 Cardinality=1199
INDEX UNIQUE SCAN Object owner=ODS Object name=PK_AVN_D_MASTERPOLICYDETAILS Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=ODS Object name=AVN_D_MASTERPOLICYDETAILS Cost=1 Cardinality=1 Bytes=34
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYLOBMAPPING Cost=741 Cardinality=288498 Bytes=4904466
VIEW PUSHED PREDICATE Object owner=ODS Cost=4 Cardinality=1 Bytes=20
FILTER
SORT AGGREGATE Cardinality=1 Bytes=21
TABLE ACCESS BY GLOBAL INDEX ROWID Object owner=ODS Object name=AVN_F_TRANSACTIONS Cost=4 Cardinality=1 Bytes=21
INDEX RANGE SCAN Object owner=ODS Object name=PK_AVN_F_TRANSACTIONS Cost=3 Cardinality=1
VIEW PUSHED PREDICATE Object owner=ODS Cost=5782 Cardinality=1 Bytes=95
SORT GROUP BY Cost=5782 Cardinality=2485 Bytes=216195
VIEW Object owner=SYS Object name=VW_DAG_0 Cost=5781 Cardinality=2485 Bytes=216195
SORT GROUP BY Cost=5781 Cardinality=2485 Bytes=278320
HASH JOIN Cost=5780 Cardinality=2485 Bytes=278320
VIEW Object owner=SYS Object name=VW_GBC_15 Cost=925 Cardinality=1199 Bytes=73139
SORT GROUP BY Cost=925 Cardinality=1199 Bytes=100716
HASH JOIN Cost=924 Cardinality=1199 Bytes=100716
NESTED LOOPS
NESTED LOOPS Cost=181 Cardinality=1199 Bytes=80333
TABLE ACCESS BY INDEX ROWID Object owner=ODS Object name=INWARDSPOLICYDETAILS Cost=159 Cardinality=1199 Bytes=39567
INDEX RANGE SCAN Object owner=ODS Object name=IX_INWPOLDTLS_SYSCOMPANYBRANCH Cost=7 Cardinality=1199
INDEX UNIQUE SCAN Object owner=ODS Object name=PK_AVN_D_MASTERPOLICYDETAILS Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=ODS Object name=AVN_D_MASTERPOLICYDETAILS Cost=1 Cardinality=1 Bytes=34
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYLOBMAPPING Cost=741 Cardinality=288498 Bytes=4904466
VIEW Object owner=SYS Object name=VW_GBF_16 Cost=4854 Cardinality=75507 Bytes=3850857
SORT GROUP BY Cost=4854 Cardinality=75507 Bytes=2340717
VIEW Object owner=ODS Cost=4207 Cardinality=75507 Bytes=2340717
SORT GROUP BY Cost=4207 Cardinality=75507 Bytes=1585647
PARTITION HASH ALL Cost=3713 Cardinality=75936 Bytes=1594656
TABLE ACCESS FULL Object owner=ODS Object name=AVN_F_TRANSACTIONS Cost=3713 Cardinality=75936 Bytes=1594656
Explain Plan(Only Query):_
SELECT STATEMENT, GOAL = ALL_ROWS Cost=62783 Cardinality=89964 Bytes=17632944
HASH JOIN OUTER Cost=62783 Cardinality=89964 Bytes=17632944
TABLE ACCESS FULL Object owner=ODS Object name=AVN_WRK_F_RENEWAL_TRANS_1ST Cost=138 Cardinality=89964 Bytes=2878848
VIEW Object owner=ODS Cost=60556 Cardinality=227882 Bytes=37372648
HASH GROUP BY Cost=60556 Cardinality=227882 Bytes=26434312
VIEW Object owner=SYS Object name=VW_DAG_1 Cost=54600 Cardinality=227882 Bytes=26434312
HASH GROUP BY Cost=54600 Cardinality=227882 Bytes=36005356
HASH JOIN OUTER Cost=46664 Cardinality=227882 Bytes=36005356
VIEW Object owner=SYS Cost=18270 Cardinality=227882 Bytes=16635386
HASH JOIN Cost=18270 Cardinality=227882 Bytes=32587126
HASH JOIN Cost=12147 Cardinality=34667 Bytes=2912028
HASH JOIN Cost=10076 Cardinality=34667 Bytes=2322689
TABLE ACCESS FULL Object owner=ODS Object name=AVN_D_MASTERPOLICYDETAILS Cost=137 Cardinality=34667 Bytes=1178678
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYDETAILS Cost=9934 Cardinality=820724 Bytes=27083892
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYLOBMAPPING Cost=741 Cardinality=866377 Bytes=14728409
VIEW Object owner=ODS Cost=5195 Cardinality=227882 Bytes=13445038
HASH GROUP BY Cost=5195 Cardinality=227882 Bytes=4785522
PARTITION HASH ALL Cost=3717 Cardinality=227882 Bytes=4785522
TABLE ACCESS FULL Object owner=ODS Object name=AVN_F_TRANSACTIONS Cost=3717 Cardinality=227882 Bytes=4785522
VIEW Object owner=ODS Cost=26427 Cardinality=227882 Bytes=19369970
HASH GROUP BY Cost=26427 Cardinality=227882 Bytes=18686324
VIEW Object owner=SYS Object name=VW_DAG_0 Cost=26427 Cardinality=227882 Bytes=18686324
HASH GROUP BY Cost=26427 Cardinality=227882 Bytes=25294902
HASH JOIN Cost=20687 Cardinality=227882 Bytes=25294902
VIEW Object owner=SYS Object name=VW_GBC_15 Cost=12826 Cardinality=34667 Bytes=2080020
HASH GROUP BY Cost=12826 Cardinality=34667 Bytes=2912028
HASH JOIN Cost=12147 Cardinality=34667 Bytes=2912028
HASH JOIN Cost=10076 Cardinality=34667 Bytes=2322689
TABLE ACCESS FULL Object owner=ODS Object name=AVN_D_MASTERPOLICYDETAILS Cost=137 Cardinality=34667 Bytes=1178678
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYDETAILS Cost=9934 Cardinality=820724 Bytes=27083892
TABLE ACCESS FULL Object owner=ODS Object name=INWARDSPOLICYLOBMAPPING Cost=741 Cardinality=866377 Bytes=14728409
VIEW Object owner=SYS Object name=VW_GBF_16 Cost=7059 Cardinality=227882 Bytes=11621982
HASH GROUP BY Cost=7059 Cardinality=227882 Bytes=6836460
VIEW Object owner=ODS Cost=5195 Cardinality=227882 Bytes=6836460
HASH GROUP BY Cost=5195 Cardinality=227882 Bytes=4785522
PARTITION HASH ALL Cost=3717 Cardinality=227882 Bytes=4785522
TABLE ACCESS FULL Object owner=ODS Object name=AVN_F_TRANSACTIONS Cost=3717 Cardinality=227882 Bytes=4785522 -
Hi DB Gurus,
Our application is inserting 60-70K records in a table in each transaction. When multiple sessions are open on this table user face performance issues like application response is too slow.
Regarding this table:
1.Size = 56424 Mbytes!
2.Count = 188,858,094 rows!
3.Years of data stored = 4 years
4.Average growth = 10 million records per month, 120 million each year! (has grown 60 million since end of June 2007)
5.Storage params = 110 extents, Initial=40960, Next=524288000, Min Extents=1, Max Extents=505
6.There are 14 indexes on this table all of which are in use.
7. Data is inserted through bulk insert
8. DB: Oracle 10g
Sheer size of this table (56G) and its rate of growth may be the culprits behind performance issue. But to ascertain that, we need to dig out more facts so that we can decide conclusively how to mail this issue.
So my questions are:
1. What other facts can be collected to find out the root cause of bad performance?
2. Looking at given statistics, is there a way to resolve the performance issue - by using table partition or archiving or some other better way is there?
We've already though of dropping some indexes but it looks difficult since they are used in reports based on this table (along with other tables)
3. Any guess what else can be causing this issue?
4. How many records per session can be inserted in a table? Is there any limitation?
Thanks in advance!!Run STATSPACK and check what it says are the issues. Try and find the particular INSERT statement in the list of all SQL. Look at all the sections of the report, including block contention, which may show you are waiting for data blocks or index blocks, etc, or even things like latch contention too. Make sure you run it when the INSERT is happening during one of your busy periods.
Given that you are using Oracle 10g, I assume you are using all the automatic settings now:
o Local Tablespace Management
o Automatic Segment Space Management
o Automatic Undo Management
If not, you should be. Prior to all this, Oracle always inserted into the last block in a table, which could become a bottleneck point. And space allocation of new blocks was also a problem. When these settings were introduced it alleviated most of these problems, and meant that Oracle could scale far better on such INSERT intensive workloads. If you are not using these for some reason or other, then you need to look at the number of FREELISTS you have on the table, and the setting of INITRANS.
Also, how many columns does this table have? And how big is an average row. And what is your block size? You can get these from the data dictionary:
select count (*) from user_tab_columns where table_name = '<tablename>' ;
select avg_row_len from user_tables where table_name = '<tablename>' ;
show parameter db_block_size
Replace <tablename> with the name of your table, in uppercase.
I ask because a very large row in a small data block will always fill the block quickly and cause new blocks to be allocated. If so, you may just have to live with this.
And I would be suspicious about all 14 indexes being needed. Are they all single column indexes, or do you have any multi-column indexes? Do any of them share the same leading columns? Again, if you need all 14 indexes, then you must suffer the overhead of maintaining these indexes. But unless you have something like 50 columns in this table, I would guess that there is some overlap between these indexes.
John -
Please advice. OLAP_TABLE performance is slow and SELECT did not return data after running for > 10 hours.
ISSUES:
(1) I started with only one measure and one dimension in the OLAP_TABLE statement and it returned data. However, when I added the remaining measures and dimensions, the statement never return data. The end user required all 20 measures and all 7 dimensions. How can I overcome the performance issue and get the data from the cube? Please HELP!
(2) The cube is compressed. I read articles saying that OLAP_TABLE cannot use the LOOP keyword when cube is being compressed. I have already using MODEL keyword and the statement did not come back. How can I improve the performance and return data?
(3) Can I create MV using OLAP_TABLE in 10g? If not, is there anyway to get around without MV because the VIEW is killing the performance so badly (it simply did not return and has to be killed manually).
(4) I also used “AWM plug-in” to create the relational table view. However, all 20 measures and 7 dimensions must be included. It exceeded 4000 characters in single PL/SQL function parameter and caused the limitmap error. So the “AWM plug-in” did not work for me.
Appreciate all of our help!
(*) DATA
1 Fact; 7 Dimensions; 1 cube; 20 measures
POSITION_FACT - 9,387,384 rows
DIM_BUSINESS_DAY - 2 rows - 1 hierarchy - 2 levels - 1 attribute
DIM_INSTRUMENT_TYPE - 16 rows - 1 hierarchy - 2 levels - 1 attribute
DIM_RISK_TYPE - 21 rows - 1 hierarchy - 2 levels - 1 attribute
DIM_BOOK - 673 rows - 1 hierarchy - 10 levels - 2 attributes
DIM_CURVE - 4,869 rows - 1 hierarchy - 6 levels - 1 attribute
DIM_REFERENCE_ENTITY - 3,756 rows - 1 hierarchy - 7 levels - 3 attributes
DIM_POSITION - 745,957 rows - 1 hierarchy - 2 levels - 9 attributes
(*) CUBE CREATED IN AWM:
fully pre-aggregated;
used global composites;
used compassion by integer;
partition by business date;
took minimum ~ 30 minutes to build the cube.
ENVIRONMENT:
(*) Oracle Database 10g Release 2 Patch Set 2 (10.2.0.3.0) 64-bit
(*) 3 products installed in Oracle Home: Interim patches: 5746153 (OLAP 'A' patch), 5556081, 5557962
(*) AWM 10.2.0.3.0A
(*) SQL
CREATE OR REPLACE VIEW vw_cube_bi_nrdb_vw_fl AS
SELECT * FROM TABLE(OLAP_TABLE(
'bi_nrdb DURATION SESSION',
MEASURE am_value_total AS NUMBER FROM bi_nrdb_vw_total
MEASURE am_value_03m AS NUMBER FROM bi_nrdb_vw_am_03m
MEASURE am_value_06m AS NUMBER FROM bi_nrdb_vw_am_06m
MEASURE am_value_09m AS NUMBER FROM bi_nrdb_vw_am_09m
MEASURE am_value_01y AS NUMBER FROM bi_nrdb_vw_am_01y
MEASURE am_value_18m AS NUMBER FROM bi_nrdb_vw_am_18m
MEASURE am_value_02y AS NUMBER FROM bi_nrdb_vw_am_02y
MEASURE am_value_03y AS NUMBER FROM bi_nrdb_vw_am_03y
MEASURE am_value_04y AS NUMBER FROM bi_nrdb_vw_am_04y
MEASURE am_value_05y AS NUMBER FROM bi_nrdb_vw_am_05y
MEASURE am_value_06y AS NUMBER FROM bi_nrdb_vw_am_06y
MEASURE am_value_07y AS NUMBER FROM bi_nrdb_vw_am_07y
MEASURE am_value_08y AS NUMBER FROM bi_nrdb_vw_am_08y
MEASURE am_value_09y AS NUMBER FROM bi_nrdb_vw_am_09y
MEASURE am_value_10y AS NUMBER FROM bi_nrdb_vw_am_10y
MEASURE am_value_12y AS NUMBER FROM bi_nrdb_vw_am_12y
MEASURE am_value_15y AS NUMBER FROM bi_nrdb_vw_am_15y
MEASURE am_value_20y AS NUMBER FROM bi_nrdb_vw_am_20y
MEASURE am_value_30y AS NUMBER FROM bi_nrdb_vw_am_30y
MEASURE am_value_40y AS NUMBER FROM bi_nrdb_vw_am_40y
DIMENSION dim_business FROM dim_business_day WITH
ATTRIBUTE dt_business FROM dim_business_day_long_description
DIMENSION dim_risk_type FROM dim_risk_type WITH
ATTRIBUTE id_risk_type FROM dim_risk_type_long_description
DIMENSION dim_instrument_type FROM dim_instrument_type WITH
ATTRIBUTE id_instrument_type FROM dim_instrument_type_long_description
DIMENSION dim_book FROM dim_book WITH
ATTRIBUTE nm_dim_book FROM dim_book_long_description
ATTRIBUTE trader FROM dim_book_trader
DIMENSION dim_reference_entity FROM dim_reference_entity WITH
ATTRIBUTE nm_dim_reference_entity FROM dim_reference_entity_long_description
ATTRIBUTE nm_spn_moody_rating FROM dim_reference_entity_spn_moody_rating
ATTRIBUTE nm_spn_sp_rating FROM dim_reference_entity_spn_sp_rating
DIMENSION dim_position FROM dim_position WITH
ATTRIBUTE id_buysell FROM dim_position_buysell
ATTRIBUTE id_coupon FROM dim_position_coupon
ATTRIBUTE id_cusip FROM dim_position_cusip
ATTRIBUTE id_isin FROM dim_position_isin
ATTRIBUTE id_instrument_name FROM dim_position_instrument_name
ATTRIBUTE id_maturity FROM dim_position_maturity
ATTRIBUTE id_mtm FROM dim_position_mtm
ATTRIBUTE id_notional FROM dim_position_notional
MODEL
DIMENSION BY (dim_business, dt_business, dim_risk_type, id_risk_type, dim_instrument_type, id_instrument_type,
dim_book, nm_dim_book, trader, dim_reference_entity, nm_dim_reference_entity, nm_spn_moody_rating,
nm_spn_sp_rating, dim_position, id_buysell, id_coupon, id_cusip, id_isin, id_instrument_name,
id_maturity, id_mtm, id_notional)
MEASURES (am_value_total, am_value_03m, am_value_06m, am_value_09m, am_value_01y,
am_value_18m,am_value_02y, am_value_03y, am_value_04y, am_value_05y,
am_value_06y, am_value_07y,am_value_08y, am_value_09y, am_value_10y,
am_value_12y, am_value_15y, am_value_20y, am_value_30y, am_value_40y)
RULES UPDATE SEQUENTIAL ORDER ();(1a) Thank you so much! The SQL “the CREATE OR REPLACE VIEW vw_cube_bi_nrdb_vw_fl…” the SQL I provided from my previous was the OLAP_STATEMENT I ran for > 10 hrs and killed manually. Please advice.
I have business requirements to display all 7 dimensions and 20 measures for reporting. So I can’t really filter my dimensions much.
(1b) Separately, I also follow your advice to add the WHERE clause after I created the VIEW vw_cube_bi_nrdb_vw_fl, see below statement and received error.
SQL> select * from vw_cube_bi_nrdb_vw_fl
where dt_business = '06/23/2008'
and ID_RISK_TYPE ='CR01'
and ID_INSTRUMENT_TYPE='VANILLA CDS'
and dim_book='BOOK_63272279'
AND dim_reference_entity='GFN_0113182'
and dim_position='3645636' ;
select * from vw_cube_bi_nrdb_vw_fl
ERROR at line 1:
ORA-32638: Non unique addressing in MODEL dimensions
(4) I received below error when I ran “AWM plug-in” to create a VIEW from AWM. I have already uncheck fields that I do not need and only keeping the measures and dimensions I need. Sorry for the long err below:
AUG-21-2008 12:14:47: . Creating view for cube BI_NRDB_AGGR
AUG-21-2008 12:14:48: ..... generating limitmap for cube
AUG-21-2008 12:14:48: ... generating limitmap for cube
AUG-21-2008 12:14:48: ..... mapping table out of date for cube BI_NRDB_AGGR. Updating mapping table.
AUG-21-2008 12:14:48: ... populating mapping for cube BI_NRDB_AGGR
AUG-21-2008 12:14:48: ..... clearing mappings for the cube
AUG-21-2008 12:14:48: ..... collecting metadata for measures in cube
AUG-21-2008 12:14:48: ..... retrieving dimensions for the cube. Need limitmap for each dimension.
AUG-21-2008 12:14:48: ... generating limitmap for DIM_BUSINESS_DAY
AUG-21-2008 12:14:48: ..... mapping table out of date for dimension DIM_BUSINESS_DAY. Updating mapping table.
AUG-21-2008 12:14:48: ... populating dimension map for DIM_BUSINESS_DAY
AUG-21-2008 12:14:48: ..... clearing mappings for the dimension
AUG-21-2008 12:14:48: ..... retrieving physical objects
AUG-21-2008 12:14:48: ..... checking for value hierarchies
AUG-21-2008 12:14:48: ..... retrieving label for dimension levels
AUG-21-2008 12:14:48: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:48: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:48: ..... retrieving hierarchy information
AUG-21-2008 12:14:48: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:48: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:48: ... completed populating mapping for DIM_BUSINESS_DAY
AUG-21-2008 12:14:48: ... generating limitmap for DIM_INSTRUMENT_TYPE
AUG-21-2008 12:14:48: ..... mapping table out of date for dimension DIM_INSTRUMENT_TYPE. Updating mapping table.
AUG-21-2008 12:14:48: ... populating dimension map for DIM_INSTRUMENT_TYPE
AUG-21-2008 12:14:48: ..... clearing mappings for the dimension
AUG-21-2008 12:14:48: ..... retrieving physical objects
AUG-21-2008 12:14:48: ..... checking for value hierarchies
AUG-21-2008 12:14:48: ..... retrieving label for dimension levels
AUG-21-2008 12:14:48: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:48: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:48: ..... retrieving hierarchy information
AUG-21-2008 12:14:49: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:49: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:49: ... completed populating mapping for DIM_INSTRUMENT_TYPE
AUG-21-2008 12:14:49: ... generating limitmap for DIM_RISK_TYPE
AUG-21-2008 12:14:49: ..... mapping table out of date for dimension DIM_RISK_TYPE. Updating mapping table.
AUG-21-2008 12:14:49: ... populating dimension map for DIM_RISK_TYPE
AUG-21-2008 12:14:49: ..... clearing mappings for the dimension
AUG-21-2008 12:14:49: ..... retrieving physical objects
AUG-21-2008 12:14:49: ..... checking for value hierarchies
AUG-21-2008 12:14:49: ..... retrieving label for dimension levels
AUG-21-2008 12:14:49: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:49: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:49: ..... retrieving hierarchy information
AUG-21-2008 12:14:49: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:49: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:49: ... completed populating mapping for DIM_RISK_TYPE
AUG-21-2008 12:14:49: ... generating limitmap for DIM_BOOK
AUG-21-2008 12:14:49: ..... mapping table out of date for dimension DIM_BOOK. Updating mapping table.
AUG-21-2008 12:14:49: ... populating dimension map for DIM_BOOK
AUG-21-2008 12:14:49: ..... clearing mappings for the dimension
AUG-21-2008 12:14:49: ..... retrieving physical objects
AUG-21-2008 12:14:49: ..... checking for value hierarchies
AUG-21-2008 12:14:49: ..... retrieving label for dimension levels
AUG-21-2008 12:14:49: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:49: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:49: ..... retrieving hierarchy information
AUG-21-2008 12:14:49: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:49: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:50: ... completed populating mapping for DIM_BOOK
AUG-21-2008 12:14:50: ... generating limitmap for DIM_CURVE
AUG-21-2008 12:14:50: ..... mapping table out of date for dimension DIM_CURVE. Updating mapping table.
AUG-21-2008 12:14:50: ... populating dimension map for DIM_CURVE
AUG-21-2008 12:14:50: ..... clearing mappings for the dimension
AUG-21-2008 12:14:50: ..... retrieving physical objects
AUG-21-2008 12:14:50: ..... checking for value hierarchies
AUG-21-2008 12:14:50: ..... retrieving label for dimension levels
AUG-21-2008 12:14:50: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:50: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:50: ..... retrieving hierarchy information
AUG-21-2008 12:14:50: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:50: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:50: ... completed populating mapping for DIM_CURVE
AUG-21-2008 12:14:50: ... generating limitmap for DIM_REFERENCE_ENTITY
AUG-21-2008 12:14:50: ..... mapping table out of date for dimension DIM_REFERENCE_ENTITY. Updating mapping table.
AUG-21-2008 12:14:50: ... populating dimension map for DIM_REFERENCE_ENTITY
AUG-21-2008 12:14:50: ..... clearing mappings for the dimension
AUG-21-2008 12:14:50: ..... retrieving physical objects
AUG-21-2008 12:14:50: ..... checking for value hierarchies
AUG-21-2008 12:14:50: ..... retrieving label for dimension levels
AUG-21-2008 12:14:50: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:50: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:50: ..... retrieving hierarchy information
AUG-21-2008 12:14:50: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:50: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:51: ... completed populating mapping for DIM_REFERENCE_ENTITY
AUG-21-2008 12:14:51: ... generating limitmap for DIM_POSITION
AUG-21-2008 12:14:51: ..... mapping table out of date for dimension DIM_POSITION. Updating mapping table.
AUG-21-2008 12:14:51: ... populating dimension map for DIM_POSITION
AUG-21-2008 12:14:51: ..... clearing mappings for the dimension
AUG-21-2008 12:14:51: ..... retrieving physical objects
AUG-21-2008 12:14:51: ..... checking for value hierarchies
AUG-21-2008 12:14:51: ..... retrieving label for dimension levels
AUG-21-2008 12:14:51: ..... populating mapping info for the DIMENSION clause
AUG-21-2008 12:14:51: ..... populating mapping info for the INHIERARCHY clause
AUG-21-2008 12:14:51: ..... retrieving hierarchy information
AUG-21-2008 12:14:51: ..... populating mapping info for the HIERARCHY and FAMILYREL clauses for hierarchy PRIM
AUG-21-2008 12:14:51: ..... populating mapping info for the ATTRIBUTE clause
AUG-21-2008 12:14:51: ... completed populating mapping for DIM_POSITION
AUG-21-2008 12:14:51: ... completed generating limitmap for cube BI_NRDB_AGGR
AUG-21-2008 12:14:51: ..... assigning limitmap to variable in the AW
AUG-21-2008 12:14:51: ..... BI_NRDB_AGGR_CUBE_LIMITMAP found. Will update the variable
AUG-21-2008 12:14:51: ..... defining view BI_DEMO.BI_NRDB_AGGR_CUBEVIEW over the cube
AUG-21-2008 12:14:51: **
AUG-21-2008 12:14:51: ** ERROR: View not created.
AUG-21-2008 12:14:51: ** CAUSE: CREATE VIEW statement failed
AUG-21-2008 12:14:51: ORA-36804: The OLAP_TABLE function encountered an error while parsing the LIMITMAP.
AUG-21-2008 12:14:51: *** DEBUG INFORMATION ***
AUG-21-2008 12:14:51: VIEW CREATION DDL ((truncated after 3900 characters)
AUG-21-2008 12:14:51: CREATE OR REPLACE VIEW BI_DEMO.BI_NRDB_AGGR_CUBEVIEW AS
SELECT *
FROM table(OLAP_TABLE ('BI_DEMO.BI_NRDB duration session',
'&(BI_NRDB_AGGR_CUBE_LIMITMAP)'))
MODEL
DIMENSION BY (
DIM_BUSINESS_DAY,
DIM_INSTRUMENT_TYPE,
DIM_RISK_TYPE,
DIM_BOOK,
DIM_CURVE,
DIM_REFERENCE_ENTITY,
DIM_POSITION)
MEASURES (
DIM_BUSINE_PRIM_PRNT,
DIM_BUSINE_ALL_BUSINE_LVLDSC,
DIM_BUSINE_BUSINESS_D_LVLDSC,
DIM_BUSINE_LDSC,
DIM_BUSINE_LEVEL,
DIM_INSTRU_PRIM_PRNT,
DIM_INSTRU_ALL_INSTRU_LVLDSC,
DIM_INSTRU_INSTRUMENT_LVLDSC,
DIM_INSTRU_LDSC,
DIM_INSTRU_LEVEL,
DIM_RISK_T_PRIM_PRNT,
DIM_RISK_T_ALL_RISK_T_LVLDSC,
DIM_RISK_T_RISK_TYPE_LVLDSC,
DIM_RISK_T_LDSC,
DIM_RISK_T_LEVEL,
DIM_BOOK_PRIM_PRNT,
DIM_BOOK_ALL_BOOK_LVLDSC,
DIM_BOOK_SYSTEM_LVLDSC,
DIM_BOOK_REGION_LVLDSC,
DIM_BOOK_BUSINESS2_LVLDSC,
DIM_BOOK_BUSINESS1_LVLDSC,
DIM_BOOK_BUSINESS_LVLDSC,
DIM_BOOK_DESK_LVLDSC,
DIM_BOOK_RISKSTRIPE_LVLDSC,
DIM_BOOK_SUBRISKSTR_LVLDSC,
DIM_BOOK_BOOK_LVLDSC,
DIM_BOOK_TRADER,
DIM_BOOK_LDSC,
DIM_BOOK_LEVEL,
DIM_CURVE_PRIM_PRNT,
DIM_CURVE_ALL_CURVE_LVLDSC,
DIM_CURVE_CURRENCY_LVLDSC,
DIM_CURVE_SENIORITY_LVLDSC,
DIM_CURVE_CURVE_OWNE_LVLDSC,
DIM_CURVE_CURVE_NAME_LVLDSC,
DIM_CURVE_CURVE_LVLDSC,
DIM_CURVE_LDSC,
DIM_CURVE_LEVEL,
DIM_REFERE_ALL_GFN_LVLDSC,
DIM_REFERE_GFN_INDUST_LVLDSC,
DIM_REFERE_GFN_COUNTR_LVLDSC,
DIM_REFERE_GFN_LVLDSC,
DIM_REFERE_SPN_INDUST_LVLDSC,
DIM_REFERE_SPN_COUNTR_LVLDSC,
DIM_REFERE_SPN_LVLDSC,
DIM_REFERE_LDSC,
DIM_REFERE_SPN_SP_RATING,
DIM_REFERE_SPN_MOODY_RATING,
DIM_REFERE_LEVEL,
DIM_REFERE_PRIM_PRNT,
DIM_POSITI_PRIM_PRNT,
DIM_POSITI_ALL_POSITI_LVLDSC,
DIM_POSITI_TRADE_ID_LVLDSC,
DIM_POSITI_COUPON,
DIM_POSITI_MATURITY,
DIM_POSITI_INSTRUMENT_NAME,
DIM_POSITI_NOTIONAL,
DIM_POSITI_BUYSELL,
DIM_POSITI_CUSIP,
DIM_POSITI_ISIN,
DIM_POSITI_LDSC,
DIM_POSITI_MTM,
DIM_POSITI_LEVEL,
TOTAL,
AM_40Y,
AM_30Y,
AM_20Y,
AM_15Y,
AM_12Y,
AM_10Y,
AM_09Y,
AM_08Y,
AM_07Y,
AM_06Y,
AM_05Y,
AM_04Y,
AM_03Y,
AM_02Y,
AM_18M,
AM_01Y,
AM_09M,
AM_06M,
AM_03M,
OLAP_CALC
) RULES UPDATE SEQUENTIAL ORDER()
AUG-21-2008 12:14:51: LIMITMAP (truncated after 3900 characters):
AUG-21-2008 12:14:51: DIMENSION DIM_BUSINESS_DAY FROM DIM_BUSINESS_DAY WITH -
HIERARCHY DIM_BUSINE_PRIM_PRNT FROM DIM_BUSINESS_DAY_PARENTREL(DIM_BUSINESS_DAY_HIERLIST \'PRIM\') -
INHIERARCHY DIM_BUSINESS_DAY_INHIER -
FAMILYREL DIM_BUSINE_ALL_BUSINE_LVLDSC, -
DIM_BUSINE_BUSINESS_D_LVLDSC -
FROM DIM_BUSINESS_DAY_FAMILYREL(DIM_BUSINESS_DAY_LEVELLIST \'ALL_BUSINESS_DAY\'), -
DIM_BUSINESS_DAY_FAMILYREL(DIM_BUSINESS_DAY_LEVELLIST \'BUSINESS_DAY\') -
LABEL DIM_BUSINESS_DAY_LONG_DESCRIPTION -
ATTRIBUTE DIM_BUSINE_LDSC FROM DIM_BUSINESS_DAY_LONG_DESCRIPTION -
ATTRIBUTE DIM_BUSINE_LEVEL FROM DIM_BUSINESS_DAY_LEVELREL-
DIMENSION DIM_INSTRUMENT_TYPE FROM DIM_INSTRUMENT_TYPE WITH -
HIERARCHY DIM_INSTRU_PRIM_PRNT FROM DIM_INSTRUMENT_TYPE_PARENTREL(DIM_INSTRUMENT_TYPE_HIERLIST \'PRIM\') -
INHIERARCHY DIM_INSTRUMENT_TYPE_INHIER -
FAMILYREL DIM_INSTRU_ALL_INSTRU_LVLDSC, -
DIM_INSTRU_INSTRUMENT_LVLDSC -
FROM DIM_INSTRUMENT_TYPE_FAMILYREL(DIM_INSTRUMENT_TYPE_LEVELLIST \'ALL_INSTRUMENT_TYPE\'), -
DIM_INSTRUMENT_TYPE_FAMILYREL(DIM_INSTRUMENT_TYPE_LEVELLIST \'INSTRUMENT_TYPE\') -
LABEL DIM_INSTRUMENT_TYPE_LONG_DESCRIPTION -
ATTRIBUTE DIM_INSTRU_LDSC FROM DIM_INSTRUMENT_TYPE_LONG_DESCRIPTION -
ATTRIBUTE DIM_INSTRU_LEVEL FROM DIM_INSTRUMENT_TYPE_LEVELREL-
DIMENSION DIM_RISK_TYPE FROM DIM_RISK_TYPE WITH -
HIERARCHY DIM_RISK_T_PRIM_PRNT FROM DIM_RISK_TYPE_PARENTREL(DIM_RISK_TYPE_HIERLIST \'PRIM\') -
INHIERARCHY DIM_RISK_TYPE_INHIER -
FAMILYREL DIM_RISK_T_ALL_RISK_T_LVLDSC, -
DIM_RISK_T_RISK_TYPE_LVLDSC -
FROM DIM_RISK_TYPE_FAMILYREL(DIM_RISK_TYPE_LEVELLIST \'ALL_RISK_TYPE\'), -
DIM_RISK_TYPE_FAMILYREL(DIM_RISK_TYPE_LEVELLIST \'RISK_TYPE\') -
LABEL DIM_RISK_TYPE_LONG_DESCRIPTION -
ATTRIBUTE DIM_RISK_T_LDSC FROM DIM_RISK_TYPE_LONG_DESCRIPTION -
ATTRIBUTE DIM_RISK_T_LEVEL FROM DIM_RISK_TYPE_LEVELREL-
DIMENSION DIM_BOOK FROM DIM_BOOK WITH -
HIERARCHY DIM_BOOK_PRIM_PRNT FROM DIM_BOOK_PARENTREL(DIM_BOOK_HIERLIST \'PRIM\') -
INHIERARCHY DIM_BOOK_INHIER -
FAMILYREL DIM_BOOK_ALL_BOOK_LVLDSC, -
DIM_BOOK_SYSTEM_LVLDSC, -
DIM_BOOK_REGION_LVLDSC, -
DIM_BOOK_BUSINESS2_LVLDSC, -
DIM_BOOK_BUSINESS1_LVLDSC, -
DIM_BOOK_BUSINESS_LVLDSC, -
DIM_BOOK_DESK_LVLDSC, -
DIM_BOOK_RISKSTRIPE_LVLDSC, -
DIM_BOOK_SUBRISKSTR_LVLDSC, -
DIM_BOOK_BOOK_LVLDSC -
FROM DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'ALL_BOOK\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'SYSTEM\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'REGION\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'BUSINESS2\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'BUSINESS1\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'BUSINESS\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'DESK\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'RISKSTRIPE\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'SUBRISKSTRIPE\'), -
DIM_BOOK_FAMILYREL(DIM_BOOK_LEVELLIST \'BOOK\') -
LABEL DIM_BOOK_LONG_DESCRIPTION -
ATTRIBUTE DIM_BOOK_TRADER FROM DIM_BOOK_TRADER -
ATTRIBUTE DIM_BOOK_LDSC FROM DIM_BOOK_LONG_DESCRIPTION -
ATTRIBUTE DIM_BOOK_LEVEL FROM DIM_BOOK_LEVELREL-
DIMENSION DIM_CURVE FROM DIM_CURVE WITH -
HIERARCHY DIM_CURVE_PRIM_PRNT FROM DIM_CURVE_PARENTREL(DIM_CURVE_HIERLIST \'PRIM\') -
INHIERARCHY DIM_CURVE_INHIER -
FAMILYREL DIM_CURVE_ALL_CURVE_LVLDSC, -
DIM_CURVE_CURRENCY_LVLDSC, -
DIM_CURVE_SENIORITY_LVLDSC, -
DIM_CURVE_CURVE_OWNE_LVLDSC, -
DIM_CURVE_CURVE_NAME_LVLDSC, -
DIM_CURVE_CURVE_LVLDSC -
FROM DIM_CURVE_FAMILYREL(DIM_CURVE_LEVELLIST \'ALL_CURVE\'), -
DIM_CURVE_FAMILYREL(DIM_CURVE_LEVELLIST \'CURRENCY\'), -
DIM_CURVE_FAMILYREL(DIM_CURVE_LEVELLIST \'SENIORITY\'), -
DIM_CURVE_FAMILYREL(DIM_CURVE_LEVELLIST \'CURVE_OWNER\'), -
DIM_CURVE_FAMILYREL(DIM_CURVE_LE
AUG-21-2008 12:14:51: **
AUG-21-2008 12:14:51: ** ERROR: Unable to create view over cube BI_NRDB_AGGR.
AUG-21-2008 12:14:51: ORA-36804: The OLAP_TABLE function encountered an error while parsing the LIMITMAP. -
Oracle 10.2.0.3 performance issue
Hi all,
I have a performance issue in the database I currently maintain.
Here's the specifications:
- Windows 2003 Server 64bit
- Oracle 10g 10.2.0.3 patch 31
- Application Server 10gR2 OC4J (Forms and Report Services)
The server was re-installed about 3 weeks ago after it got viruses.
I believe my setup on the memory parameters were fine because for two weeks the system ran fine and the end of day process is also increasing in terms of time.
However, starting 2 days ago in the middle of no where, the end of day process started to get really slow (from 11 minutes became 1 hour).
The IT standby in my client will normally do an analyze schema and after that every thing will be back to normal again.
I turned off the GATHER_STATS_JOB 2 weeks ago and replaced it with DBMS_STATS.GATHER_DATABASE_STATS which I scheduled to execute every Friday.
This problem occurred even before the server was re-installed and as usual, analyze schema (GATHER_SCHEMA_STATS) will fix it.
I don't have much options currently, and analyzing the schema seems to be the only solution which normally we never do for other clients (at not everyday analyzing schema).
I hope any of you could help me out with any solution on how to trace the exact problem on this.
Thank you,
AdhikaHi Satish,
This end of day process basically will insert some values to certain tables and also generating reports afterward.
I managed to get the AWR report within the time of the end of day process.
sql execute elapsed time is on the top of Time Model Statistics.
What I don't understand here is why is this issue happened only after 2 weeks?
I suspected that this might be because Oracle pick the wrong execution plan, and normally a wrong execution plan caused by outdated statistics on the indexes and tables, but what I cannot understand is why this is happening on Monday morning where in Friday night GATHER_DATABASE_STATS ran successfully.
Yesterday when the analyze schema was executed again, this morning I got another email saying that the performance issue occurred again.
The top most wait events are: db file sequential read, db file scattered read, log file parallel write, LNS Wait on SENDREQ, and log file sequential read.
Thank you,
Adhika -
Oracle Advance Compression Deletion Performance issue in 11g R1
Hi,
We have implemented OAC in our datawarehouse environment to enable table and index compression. We tested in our Test machine and we gained almost 600GB due to advance compression without any issues and all the informatica loads are running fine. And hence we implemented the same in our production but unfortunately two sessions which are involving deletion of data are taking more time (3 times of actual timing) for completion which affects our production environment.
The tables creating issue are all non partitioned tables.
I need to know whether Oracle Advance Compression will decrease delete performance? and is there any way to disable advance compression on those particular tables?
Our environment details:
DB earlier version: 11.1.0.6
DB current version : Oracle 11.1.0.7
Applied PSU: 11.1.0.7.6
Operating system: Solaris 5.9
Syntax used for compression:
ALTER TABLE TABLE_NAME MOVE COMPRESS FOR ALL OPERATIONS;
Thanks in Advance.Hi,
Thanks for your reply.
The note is for update performance issue and also I have applied necessary patches for improving update performance.
The update sessions are all working fine. only the deletion sessions are creating problem.
Could someone help me out to clear this problem.
Thanks,
VBK -
Hi All,
What is buffering number?How it is useful in performance issue? Tell me the option where it is available? To set this what are navigational steps?
Thanks inadvance.
YogeswarHi Yogi,
A nice weblog by Vikas Please do check this.on number range buffering,
/people/vikash.agrawal/blog/2006/04/05/load-lots-of-data-147faster148-with-buffering-number-range
Check these links.
FAQ - The Future of SAP NetWeaver Business Intelligence in the Light of the NetWeaver BI&Business Objects Roadmap
https://www.sdn.sap.com/irj/sdn/developerareas/bi?rid=/webcontent/uuid/b4674415-0b01-0010-ae81-deb009860b7e [original link is broken]
following are the links that may help you
http://help.sap.com/search/highlightContent.jsp
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/biw/s-u/sap%20bw%20business%20planning%20and%20simulation%20-%20how%20to%20guides%20list.htm
http://help.sap.com/search/highlightContent.jsp
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/afbad390-0201-0010-daa4-9ef0168d41b6
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b7bdde90-0201-0010-26b1-dcda5e0b394d
How to improve performance in reporting side?
Query Performance Techniques:
1. Check Query propertiesUse RSRT tcode
2. Check whether cube is compressed
3. Optimize query definition
4. Analyze query execution
5. Check for additional indexes
6. Archive unwanted data
7. Check for partitioning options
8. Check for additional aggregates ( Consider DB ratio and KPI ratio)
9. Check for parallelization options
10. Use Nav attributes instead of hierarchies, use free char and filters.
Possible causes for the performance :
A) High Database Runtime
B) High OLAP Runtime
C) High Frontend Runtime
Depending upon your analysis
A)Strategy - High Database Runtime
Check if an aggregate is suitable (use All data to get values "selected records to transferred records", a high number here would be an indicator for query performance improvement using an aggregate)
Check if database statistics are update to data for the Cube/Aggregate, use Tcode RSRV output (use database check for statistics and indexes)
Check if the read mode of the query is unfavourable - Recommended (H)
B)Strategy - High OLAP Runtime
Check if a high number of Cells transferred to the OLAP (use "All data" to get value "No. of Cells")
a) Use RSRT technical Information to check if any extra OLAP-processing is necessary (Stock Query, Exception Aggregation, Calc. before Aggregation, Virtual Char. Key Figures, Attributes in Calculated Key Figs, Time-dependent Currency Translation) together with a high number of records transferred.
b) Check if a user exit Usage is involved in the OLAP runtime?
c) Check if large hierarchies are used and the entry hierarchy level is as deep as possible. This limits the levels of the hierarchy that must be processed.
C)Strategy - High Frontend Runtime
1) Check if frontend PC are within the recommendation (RAM, CPU Mhz)
2) Check if the bandwidth for WAN connection is sufficient.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1e553368-0601-0010-49ab-c429607f3eb3
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5401ab90-0201-0010-b394-99ffdb15235b
check this, you can download lot of performance materials
Business Intelligence Performance Tuning [original link is broken] [original link is broken] [original link is broken]
and e-learning -> intermediate course and advance course
https://www.sdn.sap.com/irj/sdn/developerareas/bi?rid=/webcontent/uuid/fe5b0b5e-0501-0010-cd88-c871915ec3bf [original link is broken]
e.g
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/10b589ad-0701-0010-0299-e5c282b7aaad
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/d9fd84ad-0701-0010-d9a5-ba726caa585d
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/8e6183ad-0701-0010-e083-9ab1c6afe6f2
performance tools in bw 3.5
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/media/uuid/07a4f070-0701-0010-3b91-a6bf7644c98f
(here also you can download the presentation by righ click the disk drive icon)
Check the following links,
FAQ - The Future of SAP NetWeaver Business Intelligence in the Light of the NetWeaver BI&Business Objects Roadmap
Business Intelligence Performance Tuning [original link is broken] [original link is broken] [original link is broken]
http://help.sap.com/saphelp_nw04/helpdata/en/06/b5f8926ba22b45bc9eaa589f1c835b/content.htm
Some bw docs/ performance material
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1955ba90-0201-0010-d3aa-8b2a4ef6bbb2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/3a699d90-0201-0010-bc99-d5c0e3a2c87b
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
and don't miss bw performance knowledge centre, there are e-learning
Business Intelligence Performance Tuning [original link is broken] [original link is broken] [original link is broken]
Hope this Helps.
<removed>
Regards,
Ravikanth.
Maybe you are looking for
-
Should have got another 3gs... iphone 4 has given me a head ache!
Ok so I had an iphone 3gs, for 2 years and it was great! It died last week from a fall. So I decide to get an iphone4, 32 gig. So far, since I got it tonight, itunes has made me restore 4 times now. Not 3, but 4. Every time I get done, itunes shows t
-
Installation 11.1.2 (32 bit binaries) on win 64 bit server
Hi, I downloaded 11.1.2 and extarcted in one folder. double click on InstallTool.cmd---> error "windows cannot find 'D:Hyperion11.1.2\jre\winAMD64\1.6.0\bin\java'. Make sure you typed the name correctly and try again. to search for a file, click the
-
ITunes Helper Module has stopped working
I just downloaded the new version of iTunes and now iTunes and Quicktime wont open at all. When I click on iTunes or when I first turn the computer on, a window pops up that says the iTunes Helper module has stopped working. Then another window pops
-
Cannot open attachments with .eml extension and this not listed in Firefox Applications.
Have been receiving attachments from trusted friends that have .eml file extensions and they won't open. The Firefox Application list doesn't include this. Any idea how to open them?
-
HELP - What firewire do I buy for macbook pro?
I have a 6 year old digital camera that does not connect to my macbook with my current firewire cables (the cables has no hook up on computer end). Where can I find an updated firewall cable that connects to my older camera and newer computer? Thanks