Poor query performance with BETWEEN
I'm using Oracle Reports 6i.
I needed to add Date range parameters (Starting and Ending dates) to a report. I used lexicals in the Where condition to handle the logic.
If no dates given,
Start_LEX := '/**/' and
End_LEX := '/**/'
If Start_date given,
Start_LEX := 'AND t1.date >= :Start_date'
If End_date given,
End_LEX := 'AND t1.date <= :End_date'
When I run the report with no dates or only one of the dates, it finishes in 3 to 8 seconds.
But when I supply both dates, it takes > 5 minutes.
So I did the following
If both dates are given and Start_date = End date,
Start_LEX := 'AND t1.date = :Start_date'
End_LEX := '/**/'
This got the response back to the 3 - 8 second range.
I then tried this
if both dates are given and Start_date != End date,
Start_LEX := 'AND t1.date BETWEEN :Start_date AND :End_date'
End_LEX := '/**/'
This didn't help. The response was still in the 5+ minutes range.
If I run the query outside of Oracle Reports, in PL/SQL Developer or SQLplus, it returns the same data in 3 - 8 seconds in all cases.
Does anyone know what is going on in Oracle Reports when a date is compared with two values either separately or with a BETWEEN? Why does the query take approx. 60 times as long to execute?
Hi,
Observe access plan first by using BETWEEN as well as using <= >=.
Try to impose logic of using NVL while forming lexical parameters.
Adinath Kamode
Similar Messages
-
Query Performance with Exception aggregation
Hello,
My Query Keyfigures has exception aggregation on order line level as per requirement.
Currently cube holds 5M of records, when we run query its running more than 30min.
We cont remove exception aggregation.
Cube is alredy modeled correctly and we dont want to use the cache.
Does anybody can please advice if there is any other better approach to improve query performance with exception agg?
ThanksHi,
We have the same problem and raised an OSS ticket. They replied us with the note 1257455 which offers all ways of improving performance in such cases. I guess there s nothing else to do, but to precalculate this exception aggregated formula in data model via transformations or ABAP.
By the way, cache can not help you in this case since exc. agg. is calculated after cache retrieval.
Hope this helps,
Sunil -
Poor query performance only with migrated 7.0 queries
Dear Team,
We are facing a serious query performance issue after migration of queries from 3.5 to 7.0.
I executed a query in 3.5 with some variable values which takes fraction of seconds to display the output. But the same migrated query with same variable entries is taking very long time and giving time out error.
We are not using any aggregates in the InfoProvider level.
Both the queries are based on same cube but 3.5 query is taking less time and 7.0 is taking very long time if more selection is done.
I checked for notes where I didn't find specific note for this particular scenario. I found notes only for general query performance improvement.
I want to know the reason why only in 7.0 the same 3.5 query is taking a long time and giving time out error. And please suggest some notes or suggestions related to this scenario.
Regards,
ChanHi,
Queries in BI 7.0 are almost the same as queries in 3.x format.
inorder to check if the problem is in the query runtime (database time) or JAVA runtime (probably rendering) you should try running it from RSRT once in JAVA web and once in ABAP web.
if the problem is only with JAVA web, than u should take the URL and add &profiling=X at the end.
after the query execution u can use statistics which will be shown at the top of the page.
With my experience, the problem is in the rendering phase of the query. Things that could be done is to limit the number of rows shown at each page, that could be done by changing the 0ANALYSIS web template - it's one of the web template parameters.
Tomer. -
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> -
Poor Bluetooth performance with all aluminum Mac Pro
The all aluminum case for pre-mavericks Mac Pro is the primary reason for poor antenna performance of Bluetooth. Aluminum, being a good conductor, acts as a reflector of EMF forming what is known as a Faraday Cage, essentially trapping emissions within the box. Normally, holes drilled in the case would allow enough EMF to pass through the case but the hole size for transmission is directly proportional to the lowest frequency that will pass through easily. An example is the typical microwave oven where the window is actually a conducting sheet with small enough hole such that higher freq light waves pass easily through the sheet but lower frequency microwaves do not. Perhaps if the drive bay covers were made of plastic, transmission of the Bluetooth and wifi would be sufficient. One might carefully nibble a slot or two in the side door but this would surely invalidate any warranty and care would have to be taken not to get aluminum particles inside the computer. This would probably nullify any FCC approval of the machine due to clocking noise interference with other devices. The best approach would probably be a tuned waveguide that passes frequencies only around 2.4 GHz ~ 5 GHz through the case (very similar to the way tuned ports on audio speakers pass a band of frequencies needed to extend bass response). I'm sure Apple will have corrected this design flaw in the new Mac Pro introduced this year. If you have lots of time on your hands you can get a college level text on electromagnetics (Maxwell's Equations, etc.) and derive all the details but with a bit of experimenting and reading about tin can antenna mods to wireless routers you should be able to improve Bluetooth performance significantly.
Thanks for the suggestion. I will have to move my wireless home base station. It is on the same desk as my mini so much less than 5 feet away.
-
Poor query performance in Prod.
I am facing lots of issues in my queries.
The query is working fine in Dev. but after i transported it to Prod. the query is taking too much time to retreive the result.
Why i am facing this issue.
How can i do the performance tuning for the query.?
The query is built on multiprovider and it is also jumping to the ODS for ODS query.
But the query performance is really low and poor in Production.
And to surprise the query is wroking perfectly and faster in Dev.
What can be the suggestion.
Please send documents for performnace tuning, notes number... etc.Are datavolumes huge in Prod Box...dat may be cause 4 d slow runtimes.
<b>Look at below performance improving techs</b>
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cbd2d390-0201-0010-8eab-a8a9269a23c2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/aec09790-0201-0010-8eb9-e82df5763455
Business Intelligence Performance Tuning [original link is broken]
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/cccad390-0201-0010-5093-fd9ec8157802
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/c8c4d794-0501-0010-a693-918a17e663cc
Note 565725 - Optimizing the performance of ODS objects -
Disappointing query performance with object-relational storag
Hello,
after some frustrating days trying to improve query performance on an xmltype table I'm on my wits' end. I have tried all possible combinations of indexes, added scopes, tried out of line and inline storage, removed recursive type definition from the schema, tried the examples from the form thread Setting Attribute SQLInline to false for Out-of-Line Storage (having the same problems) and still have no clue. I have prepared a stripped down example of my schema which shows the same problems as the real one. I'm using 10.2.0.4.0:
SQL> select * from v$version;
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
You can find the script on http://www.grmblfrz.de/xmldbproblem.sql (I tried including it here but got an internal server error) The results are on http://www.grmblfrz.de/xmldbtest.lst . I have no idea how to improve the performance (and if even with this simple schema query rewrite does not work, how can oracle xmldb be feasible for more complex structures?). I must have made a mistake somewhere, hopefully someone can spot it.
Thanks in advance.
--Swen
Edited by: user636644 on Aug 30, 2008 3:55 PM
Edited by: user636644 on Aug 30, 2008 4:12 PMMarc,
thanks, I did not know that it is possible to use "varray store as table" for the reference tables. I have tried your example. I can create the nested table, the scope and the indexes, but I get a different result - full table scan on t_element. With the original table I get an index scan. On the original table there is a trigger (t_element$xd) which is missing on the new table. I have tried the same with an xmltype table (drop table t_element; create table t_element of xmltype ...) with the same result. My script ... is on [google groups|http://groups.google.com/group/oracle-xmldb-temporary-group/browse_thread/thread/f30c3cf0f3dbcafc] (internal server error while trying to include it here). Here is the plan of the query
select rt.object_value
from t_element rt
where existsnode(rt.object_value,'/mddbelement/group[attribute[@name="an27"]="99"]') = 1;
Execution Plan
Plan hash value: 4104484998
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 40 | 2505 (1)| 00:00:38 |
| 1 | TABLE ACCESS BY INDEX ROWID | NT_GROUP | 1 | 20 | 3 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | SYS_C0082879 | 1 | | 2 (0)| 00:00:01 |
|* 3 | FILTER | | | | | |
| 4 | TABLE ACCESS FULL | T_ELEMENT | 1000 | 40000 | 4 (0)| 00:00:01 |
| 5 | NESTED LOOPS SEMI | | 1 | 88 | 5 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 59 | 4 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID| NT_GROUP | 1 | 20 | 3 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | SYS_C0082879 | 1 | | 2 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID| T_GROUP | 1 | 39 | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | SYS_C0082878 | 1 | | 0 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | SYS_IOT_TOP_184789 | 1 | 29 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("NESTED_TABLE_ID"=:B1)
3 - filter( EXISTS (SELECT /*+ ???)
8 - access("NESTED_TABLE_ID"=:B1)
9 - filter("T_GROUP"."SYS_NC0001300014$" IS NOT NULL AND
SYS_CHECKACL("ACLOID","OWNERID",xmltype('<privilege
xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-insta
nce" xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
http://xmlns.oracle.com/xdb/acl.xsd DAV:http://xmlns.oracle.com/xdb/dav.xsd"><read-properties
/><read-contents/></privilege>'))=1)
10 - access("SYS_ALIAS_3"."COLUMN_VALUE"="T_GROUP"."SYS_NC_OID$")
11 - access("NESTED_TABLE_ID"="T_GROUP"."SYS_NC0001300014$")
filter("SYS_XDBBODY$"='99' AND "NAME"='an27')
Edited by: user636644 on Sep 1, 2008 9:56 PM -
Very poor network performance with a G4
I have a white & grey G4 (1.25GHz and 256MB) running OS X 10.4.5. It's exhibiting very poor network performance, e.g. it will not FTP files over a LAN at more than about 40KB/second.
Other nodes on the same switch perform fine, as do other ports on the switch. The machine is set to autodetect for speed & duplex, so my question is -- how do I debug this? I've tried swapping network cables already...
Thanks!
ChrisThis came down to an incompatibility between the G4 and the Cisco. When the switch is set to force 100Mbit but negotiate duplex, the G4 doesn't like it. Going back to auto speed & duplex fixed the problem...
-
Query Performance with Unit Conversion
Hi Experts,
Right now my Customer ask to me to do a improve in the runtime of some queries.
I detect a problem in one related to unit conversion. I execute a workbook statistics and found that the time is focusing in step conversion data.
I'm consulting all the year and is taking around 20 minuts to give us a result. I too much time. The only thing in the query is the conversion data.
How can I to improve the performance? what is the check list in this case?
thanks for you help.
JoseHi Jose,
You might not be able to reduce the unit conversion time here and try to apply the general query performance improvement techniques, e.g. caching the query results etc.
But there is one thing which can help you, if end user is using only one of the unit for e.g. User always execute the report in USD but the source currency is different from USD. In such cases you can create another data source and do the data conversion at the time of data loading so that in the new data source all data will be available in required currency and no conversion will happen at runtime and will improve the query performance drastically.
But above solution is not feasible if there are many currencies and report needs to be run in multiple currency frequently.
Regards,
Durgesh. -
Poor query performance when using date range
Hello,
We have the following ABAP code:
select sptag werks vkorg vtweg spart kunnr matnr periv volum_01 voleh
into table tab_aux
from s911
where vkorg in c_vkorg
and werks in c_werks
and sptag in c_sptag
and matnr in c_matnr
that is translated to the following Oracle query:
SELECT
"SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN 20101201 AND 20101231 AND "MATNR" BETWEEN 000000000100000000 AND 000000000999999999;
Because the field SPTAG is not enclosed by apostropher, the oracle query has a very bad performance. Below the execution plans and its costs, with and without the apostrophes. Please help me understanding why I am getting this behaviour.
##WITH APOSTROPHES
SQL> EXPLAIN PLAN FOR
2 SELECT
3 "SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN '20101201' AND '20101231' AND "MATNR" BETWEEN '000000000100000000' AND '000000000999999999';
Explained.
SQL> SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
Id
Operation
Name
Rows
Bytes
Cost (%CPU)
0
SELECT STATEMENT
932
62444
150 (1)
1
TABLE ACCESS BY INDEX ROWID
S911
932
62444
149 (0)
2
INDEX RANGE SCAN
S911~VAC
55M
5 (0)
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("VKORG"='D004' AND "SPTAG">='20101201' AND
"SPTAG"<='20101231')
2 - access("MANDT"='003' AND "MATNR">='000000000100000000' AND
"MATNR"<='000000000999999999')
##WITHOUT APOSTROPHES
SQL> EXPLAIN PLAN FOR
2 SELECT
3 "SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" , "PERIV" , "VOLUM_01" ,"VOLEH" FROM SAPR3."S911" WHERE "MANDT" = '003' AND "VKORG" = 'D004' AND "SPTAG" BETWEEN 20101201 AND 20101231 AND "MATNR" BETWEEN '000000000100000000' AND '000000000999999999';
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
Explained.
SQL>
PLAN_TABLE_OUTPUT
Id
Operation
Name
Rows
Bytes
Cost (%CPU)
0
SELECT STATEMENT
2334
152K
150 (1)
1
TABLE ACCESS BY INDEX ROWID
S911
2334
152K
149 (0)
2
INDEX RANGE SCAN
S911~VAC
55M
5 (0)
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
1 - filter("VKORG"='D004' AND TO_NUMBER("SPTAG")>=20101201 AND
TO_NUMBER("SPTAG")<=20101231)
2 - access("MANDT"='003' AND "MATNR">='000000000100000000' AND
"MATNR"<='000000000999999999')
Best Regards,
Daniel G.Volker,
Answering your question, regarding the explain from ST05. As a quick work around I created an index (S911~Z9), but still I'd like to solve this issue without this extra index, as primary index would work ok, as long as date was correctly sent to oracle as string and not as number.
SELECT
"SPTAG" , "WERKS" , "VKORG" , "VTWEG" , "SPART" , "KUNNR" , "MATNR" ,
"PERIV" , "VOLUM_01" , "VOLEH"
FROM
"S911"
WHERE
"MANDT" = :A0 AND "VKORG" = :A1 AND "SPTAG" BETWEEN :A2 AND :A3 AND "MATNR"
BETWEEN :A4 AND :A5
A0(CH,3) = 003
A1(CH,4) = D004
A2(NU,8) = 20101201 (NU means number correct?)
A3(NU,8) = 20101231
A4(CH,18) = 000000000100000000
A5(CH,18) = 000000000999999999
SELECT STATEMENT ( Estimated Costs = 10 , Estimated #Rows = 6 )
5 3 FILTER
Filter Predicates
5 2 TABLE ACCESS BY INDEX ROWID S911
( Estim. Costs = 10 , Estim. #Rows = 6 )
Estim. CPU-Costs = 247.566 Estim. IO-Costs = 10
1 INDEX RANGE SCAN S911~Z9
( Estim. Costs = 7 , Estim. #Rows = 20 )
Search Columns: 4
Estim. CPU-Costs = 223.202 Estim. IO-Costs = 7
Access Predicates Filter Predicates
The table originally includes the following indexes:
###S911~0
MANDT
SSOUR
VRSIO
SPMON
SPTAG
SPWOC
SPBUP
VKORG
VTWEG
SPART
VKBUR
VKGRP
KONDA
KUNNR
WERKS
MATNR
###S911~VAC
MANDT
MATNR
Number of entries: 61.303.517
DISTINCT VKORG: 65
DISTINCT SPTAG: 3107
DISTINCT MATNR: 2939 -
Poor query performance in WebI on top of BEx queries
Hello,
We are using Web Inteliigence i BO 3.1 (SP0) to report on BEx queries (BW 7.0).
We experience however that reporting is much quicker for the same set of data when using BEx Analyzer than when using WebI. In BEx it is acceptable, but in WebI it's not.
How can we optimize the performance in this scenario? What tricks are there?
The amount of data is not huge (max 500 000 records in the cube)
BR,
FredrikHi,
Dennis is right. But if you need to upgrade (and you do) than maybe going to the latest SP is better. It is SP4. With SP3 the WebI Option "Query Striping" has been introduced which brings Performance as well.
Also check
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/d0bf4691-cdce-2d10-45ba-d1ff39408eb4
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/109b7d63-7cab-2d10-2fbc-be5c61dcf110
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/006b1374-8f91-2d10-fe9c-f9fa12e2f595
Regards
-Seb. -
Major query performance differnce between oracle 8 and 9
Hello, I have the following query
select distinct UPPER(rf.module), ruf.rpt_seq
from role_func rf, rd_url_func ruf
where role_name = 'ADMIN'
and UPPER(rf.module) not in (select UPPER(ruf.module)
from role_func rf2, rd_url_func ruf2
where UPPER(ruf2.module) = UPPER(rf.module)
and UPPER(rf2.module(+)) = UPPER(ruf2.module)
and rf2.url(+) = ruf2.url
and rf2.role_name(+) = 'ADMIN'
and rf2.url is null)
and UPPER(rf.module) = UPPER(ruf.module)
and ruf.rpt_seq = (SELECT min(rpt_seq)
FROM rd_url_func ruf3
WHERE ruf3.module = ruf.module)
order by ruf.rpt_seq; Now on Oracle 8, this executes almost instantly. On oracle 9, however, this takes a very long time (around 30 seconds?) In both databases I have the same data. Also none of the tables are extremely large- they both contain only about 400 rows. Any suggestions on what could be causing this difference, or at least how I can find out the problem?
Thanksok does this help:
explain plan for select distinct UPPER(rf.module), ruf.rpt_seq
from role_func rf, rd_url_func ruf
where role_name = 'ADMIN'
and UPPER(rf.module) not in (select UPPER(ruf.module)
from role_func rf2, rd_url_func ruf2
where UPPER(ruf2.module) = UPPER(rf.module)
and UPPER(rf2.module(+)) = UPPER(ruf2.module)
and rf2.url(+) = ruf2.url
and rf2.role_name(+) = 'ADMIN'
and rf2.url is null)
and UPPER(rf.module) = UPPER(ruf.module)
and ruf.rpt_seq = (SELECT min(rpt_seq)
FROM rd_url_func ruf3
WHERE ruf3.module = ruf.module)
order by ruf.rpt_seq;
select
substr (lpad(' ', level-1) || operation || ' (' || options || ')',1,30 ) "Operation",
object_name "Object"
from
plan_table
start with id = 0
connect by prior id=parent_id;this is from oracle 8 where it executes fast:
Operation Object
SELECT STATEMENT ()
SORT (UNIQUE)
FILTER ()
HASH JOIN ()
TABLE ACCESS (FULL) RD_URL_FUNC
TABLE ACCESS (FULL) ROLE_FUNC
FILTER ()
FILTER ()
NESTED LOOPS (OUTER)
TABLE ACCESS (FULL) RD_URL_FUNC
TABLE ACCESS (BY INDEX R ROLE_FUNC
INDEX (UNIQUE SCAN) RFUN_PK
SORT (AGGREGATE)
TABLE ACCESS (FULL) RD_URL_FUNCthis is from oracle 9 where it executes slow
Operation Object
SELECT STATEMENT ()
SORT (UNIQUE)
FILTER ()
SORT (GROUP BY)
FILTER ()
HASH JOIN ()
TABLE ACCESS (FULL) ROLE_FUNC
HASH JOIN ()
TABLE ACCESS (FULL) RD_URL_FUNC
TABLE ACCESS (FULL) RD_URL_FUNC
FILTER ()
FILTER ()
NESTED LOOPS (OUTER)
TABLE ACCESS (FULL) RD_URL_FUNC
TABLE ACCESS (BY INDEX ROLE_FUNC
INDEX (UNIQUE SCAN) RFUN_PKcan someone help interpret the difference between the execution plan, and how to make oracle use the first one on oracle 9? -
How can we improve query performance with out indexes?
Hello Experts,
I have a problem with table(calc) which contain 3 crore records and table doesn't have index, on that table one of the view(View_A) created.
When i use the view in below query SELECT count(*)
FROM
Table A INNER JOIN Table B ON (A.a=B.b)
LEFT OUTER JOIN View_A ON ( Table A.a=View_A.a)
LEFT OUTER JOIN View_B ON (Table A.a=View_B.a)
In above query View_A is causing the problem, view_A is created on Calc table. One more thing when i execute select statement on the view it was running fine.
With out View_A query fetching data fine. Update stats of the table also fine. When i run cost plan for scanning only cost % is 90.
Can any help me please?.
Thank you all.
Regards,
Jason.Jason,
Not sure what you are trying to do. But outer joins are bad for performance. So try to avoid them.
You also say that you have a view on a calc table. What are you calculating? Are you using user defined functions maybe?
Regards,
Nico -
Query performance with filters
Hi there,
I've noticed that when I run a query in Answers, if the query has a filter which is not in the displayed columns, the query runs very slowly. However, if I run the same query WITH the filtering column in the displayed columns, the query will return the results almost immediately.
Take the example of a sales report. If I run a query of [Store Number] vs. [Sales Amount] and ctrl-click filter it with the [Region] dimension column equal to 'North America'. The query will take about 5 to 10 minutes to run. However, if I include the [Region] column in the display columns (i.e. [Region], [Store Number] vs. [Sales Amount]) or the "Excluded" columns in Answers, then the query will take less than a minute to run.
I am using Oracle BI to connect to a MS Analysis Services cube by the way.
Any ideas or suggestions on how to improve the performance? I don't want to include the filtering columns in the select query because when users use the dashboard filters, they just want to filter the results by different dimension values instead of seeing them in the report.
Thanks.Thanks.
However, when I run a similar query in the backend (MS Analysis Services), the performance is very good. Only when I try to run the query through Oracle BI, the performance suffers. I know that it has something to do with the way Oracle constructs its query to send back to the Analysis Services.
The main thing about my issue is that in Answers, queries with the filtering columns in both the select and where clauses run much faster than queries with the filtering columns ONLY in the where clause. Why is that, and how to speed it up? -
Poor restore performance with MaxDB 7.6.04.15 and HP Data Protector 6
We encounter severe problems with the MaxDB integration in Data Protector 6. While the backup is finished in two hours (LTO4), the restore takes 9-12 hours.
The source system has the following specs:
CPU: 4x QuadCore
RAM: 48 GB
Cache Size: 25 GB
db size (allocated): 550 GB
27x 30 GB raw devices, located in SAN
SLES 10 SP2
parallelism (# pipes): 14 (tried 4, 8, 28, 2 tapes...)
Target system:
CPU: 2x DualCore
RAM: 8 GB
Cache Size: 4 GB
27x 30 GB raw devices, located in SAN
SLES 10 SP2
We checked the performance of file system restores - works fine with good restore times, so we don't think it's a SAN/tape library issue (e. g. switches etc.).
Some things are quite disturbing:
x_cons <SID> show sus
SERVERDB: <SID>
List of suspend-reasons:
========================
Total Suspends: 428083
Vsuspend (203) : 426288 ( 99.58% ) kb39read_wait
Vsuspend (204) : 1611 ( 0.38% ) kb39write_wait
JobWait BckRec : 1 ( 0.00% ) SrvTasks_BackupServer::WaitForAnyJobFini
No-Work (255) : 183 ( 0.04% ) Task is waiting for work
x_cons <SID> show tasks|grep BUP
T71 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T72 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T73 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T74 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T75 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T76 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T77 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T78 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T79 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T80 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T81 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T82 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T83 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T84 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T85 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T86 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T87 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T88 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T89 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
T92 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T109 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
T111 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T112 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T128 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T129 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T130 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T131 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T132 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T133 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T134 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T135 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T136 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T137 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T138 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T139 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T140 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T141 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T142 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T143 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T144 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
T148 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
I tried changing parameters a bit with no visible effort. The current parameters of the target system are:
2008-09-16 15:54:01 6300 20235 RTE ADMIN=1
2008-09-16 15:54:01 6300 20235 RTE _AK_DUMP_ALLOWED=YES
2008-09-16 15:54:01 6300 20235 RTE ALLOW_MULTIPLE_SERVERTASK_UKTS=YES
2008-09-16 15:54:01 6300 20235 RTE AUTHENTICATION_ALLOW=
2008-09-16 15:54:01 6300 20235 RTE AUTHENTICATION_DENY=
2008-09-16 15:54:01 6300 20235 RTE AUTOSAVE=1
2008-09-16 15:54:01 6300 20235 RTE AUTO_RECREATE_BAD_INDEXES=YES
2008-09-16 15:54:01 6300 20235 RTE BACKUPRESULT=1
2008-09-16 15:54:01 6300 20235 RTE BACKUP_BLOCK_CNT=64
2008-09-16 15:54:01 6300 20235 RTE _BACKUP_HISTFILE=dbm.knl
2008-09-16 15:54:01 6300 20235 RTE _BACKUP_MED_DEF=dbm.mdf
2008-09-16 15:54:01 6300 20235 RTE CACHE_IN_SHARED_MEMORY=NO
2008-09-16 15:54:01 6300 20235 RTE CACHE_SIZE=512000
2008-09-16 15:54:01 6300 20235 RTE CALLSTACKLEVEL=0
2008-09-16 15:54:01 6300 20235 RTE _CAT_CACHE_MINSIZE=262144
2008-09-16 15:54:01 6300 20235 RTE CAT_CACHE_SUPPLY=12864
2008-09-16 15:54:01 6300 20235 RTE CHECKDATA=1
2008-09-16 15:54:01 6300 20235 RTE CHECK_BACKUP=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_COMMON=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_CONVERTER=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_DATACACHE=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_DATAINDEX=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_DATAPAGELOG=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_FBM=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_HASHED_RESULTSET=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_IOMAN=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_KB_REGIONS=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOCK_SUPPLY=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOCK=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOGHISTORY=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOGPAGE=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOGTRANS=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_LOGVOLUME=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_QUERYREWRITE=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_REGIONS=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_SRVTASKS=0
2008-09-16 15:54:01 6300 20235 RTE CHECK_TABLE_WIDTH=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_TASK_SPECIFIC_CATALOGCACHE=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_TRANSLIST=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_TREE_LOCKS=NO
2008-09-16 15:54:01 6300 20235 RTE CHECK_TREE=NO
2008-09-16 15:54:01 6300 20235 RTE CLUSTERED_LOBS=NO
2008-09-16 15:54:01 6300 20235 RTE CLUSTER_WRITE_THRESHOLD=80
2008-09-16 15:54:01 6300 20235 RTE COLUMNCOMPRESSION=YES
2008-09-16 15:54:01 6300 20235 RTE _COMMENT=
2008-09-16 15:54:01 6300 20235 RTE CONTROLPASSWORD=***
2008-09-16 15:54:01 6300 20235 RTE CONTROLUSERID=CONTROL
2008-09-16 15:54:01 6300 20235 RTE CONVERTER_REGIONS=64
2008-09-16 15:54:01 6300 20235 RTE DATABASEFULL=1
2008-09-16 15:54:01 6300 20235 RTE _DATA_CACHE_RGNS=64
2008-09-16 15:54:01 6300 20235 RTE DATA_IO_BLOCK_COUNT=64
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_GROUPS=1
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0001=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0002=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0003=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0004=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0005=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0006=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0007=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0008=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0009=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0010=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0011=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0012=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0013=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0014=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0015=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0016=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0017=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0018=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0019=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0020=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0021=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0022=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0023=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0024=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0025=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0026=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_MODE_0027=NORMAL
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0001=/dev/raw/raw1
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0002=/dev/raw/raw2
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0003=/dev/raw/raw3
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0004=/dev/raw/raw4
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0005=/dev/raw/raw5
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0006=/dev/raw/raw6
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0007=/dev/raw/raw7
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0008=/dev/raw/raw8
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0009=/dev/raw/raw9
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0010=/dev/raw/raw10
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0011=/dev/raw/raw11
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0012=/dev/raw/raw12
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0013=/dev/raw/raw13
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0014=/dev/raw/raw14
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0015=/dev/raw/raw15
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0016=/dev/raw/raw16
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0017=/dev/raw/raw17
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0018=/dev/raw/raw18
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0019=/dev/raw/raw19
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0020=/dev/raw/raw20
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0021=/dev/raw/raw21
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0022=/dev/raw/raw22
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0023=/dev/raw/raw23
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0024=/dev/raw/raw24
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0025=/dev/raw/raw25
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0026=/dev/raw/raw26
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_NAME_0027=/dev/raw/raw27
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0001=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0002=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0003=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0004=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0005=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0006=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0007=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0008=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0009=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0010=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0011=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0012=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0013=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0014=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0015=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0016=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0017=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0018=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0019=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0020=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0021=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0022=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0023=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0024=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0025=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0026=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_SIZE_0027=3932160
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0001=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0002=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0003=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0004=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0005=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0006=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0007=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0008=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0009=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0010=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0011=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0012=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0013=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0014=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0015=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0016=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0017=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0018=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0019=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0020=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0021=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0022=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0023=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0024=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0025=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0026=R
2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0027=R
2008-09-16 15:54:01 6300 20235 RTE DATE_TIME_FORMAT=INTERNAL
2008-09-16 15:54:01 6300 20235 RTE DBFILLINGABOVELIMIT=70L80M85M90H95H96H97H98H99H
2008-09-16 15:54:01 6300 20235 RTE DBFILLINGBELOWLIMIT=70L80L85L90L95L
2008-09-16 15:54:01 6300 20235 RTE DDLTRIGGER=YES
2008-09-16 15:54:01 6300 20235 RTE DEADLOCK_DETECTION=4
2008-09-16 15:54:01 6300 20235 RTE DEFAULT_CODE=ASCII
2008-09-16 15:54:01 6300 20235 RTE _DELAY_COMMIT=NO
2008-09-16 15:54:01 6300 20235 RTE _DELAY_LOGWRITER=0
2008-09-16 15:54:01 6300 20235 RTE DIAG_HISTORY_NUM=2
2008-09-16 15:54:01 6300 20235 RTE DIAG_HISTORY_PATH=/sapdb/data/wrk/PSR/DIAGHISTORY
2008-09-16 15:54:01 6300 20235 RTE _DIAG_SEM=0
2008-09-16 15:54:01 6300 20235 RTE _DW_IO_AREA_FLUSH=50
2008-09-16 15:54:01 6300 20235 RTE _DW_IO_AREA_SIZE=50
2008-09-16 15:54:01 6300 20235 RTE _DW_LRU_TAIL_FLUSH=25
2008-09-16 15:54:01 6300 20235 RTE _DYN_TASK_STACK=NO
2008-09-16 15:54:01 6300 20235 RTE ENABLE_CHECK_INSTANCE=YES
2008-09-16 15:54:01 6300 20235 RTE ENABLE_SYSTEM_TRIGGERS=YES
2008-09-16 15:54:01 6300 20235 RTE ERROR=3
2008-09-16 15:54:01 6300 20235 RTE _EVENTFILE=knldiag.evt
2008-09-16 15:54:01 6300 20235 RTE _EVENTSIZE=0
2008-09-16 15:54:01 6300 20235 RTE EVENT=1
2008-09-16 15:54:01 6300 20235 RTE EXPAND_COM_TRACE=NO
2008-09-16 15:54:01 6300 20235 RTE EXTERNAL_DUMP_REQUEST=NO
2008-09-16 15:54:01 6300 20235 RTE FBM_CLUSTER_MODE=MIXED
2008-09-16 15:54:01 6300 20235 RTE _FBM_LOW_IO_RATE=10
2008-09-16 15:54:01 6300 20235 RTE FBM_VOLUME_BALANCE=10
2008-09-16 15:54:01 6300 20235 RTE FBM_VOLUME_COMPRESSION=50
2008-09-16 15:54:01 6300 20235 RTE FILEDIR_SPINLOCKPOOL_SIZE=10
2008-09-16 15:54:01 6300 20235 RTE FORBID_LOAD_BALANCING=YES
2008-09-16 15:54:01 6300 20235 RTE FORMATTING_MODE=PARALLEL
2008-09-16 15:54:01 6300 20235 RTE FORMAT_DATAVOLUME=YES
2008-09-16 15:54:01 6300 20235 RTE HASHED_RESULTSET_CACHESIZE=262144
2008-09-16 15:54:01 6300 20235 RTE HASHED_RESULTSET=YES
2008-09-16 15:54:01 6300 20235 RTE HEAP_CHECK_LEVEL=0
2008-09-16 15:54:01 6300 20235 RTE HIRES_TIMER_TYPE=CPU
2008-09-16 15:54:01 6300 20235 RTE HS_STORAGE_DLL=libhsscopy
2008-09-16 15:54:01 6300 20235 RTE HS_SYNC_INTERVAL=50
2008-09-16 15:54:01 6300 20235 RTE _IDXFILE_LIST_SIZE=2048
2008-09-16 15:54:01 6300 20235 RTE INDEX_LEAF_CACHING=2
2008-09-16 15:54:01 6300 20235 RTE INIT_ALLOCATORSIZE=262144
2008-09-16 15:54:01 6300 20235 RTE INSTANCE_TYPE=OLTP
2008-09-16 15:54:01 6300 20235 RTE _IOPROCS_FOR_PRIO=0
2008-09-16 15:54:01 6300 20235 RTE _IOPROCS_FOR_READER=1
2008-09-16 15:54:01 6300 20235 RTE _IOPROCS_PER_DEV=2
2008-09-16 15:54:01 6300 20235 RTE _IOPROCS_SWITCH=2
2008-09-16 15:54:01 6300 20235 RTE JOIN_MAXTAB_LEVEL4=64
2008-09-16 15:54:01 6300 20235 RTE JOIN_MAXTAB_LEVEL9=5
2008-09-16 15:54:01 6300 20235 RTE JOIN_SEARCH_LEVEL=0
2008-09-16 15:54:01 6300 20235 RTE JOIN_TABLEBUFFER=128
2008-09-16 15:54:01 6300 20235 RTE _KERNELDIAGFILE=knldiag
2008-09-16 15:54:01 6300 20235 RTE KERNELDIAGSIZE=800
2008-09-16 15:54:01 6300 20235 RTE _KERNELDUMPFILE=knldump
2008-09-16 15:54:01 6300 20235 RTE _KERNELTRACEFILE=knltrace
2008-09-16 15:54:01 6300 20235 RTE KERNELTRACESIZE=2809
2008-09-16 15:54:01 6300 20235 RTE KERNELVERSION=KERNEL 7.6.04 BUILD 015-123-189-221
2008-09-16 15:54:01 6300 20235 RTE _LM_LOCK_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE _LM_REQUEST_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE _LM_TRANS_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE LOAD_BALANCING_CHK=0
2008-09-16 15:54:01 6300 20235 RTE LOAD_BALANCING_DIF=10
2008-09-16 15:54:01 6300 20235 RTE LOAD_BALANCING_EQ=5
2008-09-16 15:54:01 6300 20235 RTE LOCAL_REDO_LOG_BUFFER_SIZE=0
2008-09-16 15:54:01 6300 20235 RTE _LOCKMANAGER_ENABLED=NO
2008-09-16 15:54:01 6300 20235 RTE _LOCK_SUPPLY_BLOCK=100
2008-09-16 15:54:01 6300 20235 RTE LOGABOVELIMIT=50L75L90M95M96H97H98H99H
2008-09-16 15:54:01 6300 20235 RTE LOGFULL=1
2008-09-16 15:54:01 6300 20235 RTE LOGSEGMENTFULL=1
2008-09-16 15:54:01 6300 20235 RTE LOG_BACKUP_TO_PIPE=NO
2008-09-16 15:54:01 6300 20235 RTE LOG_IO_BLOCK_COUNT=8
2008-09-16 15:54:01 6300 20235 RTE LOG_IO_QUEUE=200
2008-09-16 15:54:01 6300 20235 RTE LOG_MIRRORED=NO
2008-09-16 15:54:01 6300 20235 RTE LOG_QUEUE_COUNT=1
2008-09-16 15:54:01 6300 20235 RTE LOG_SEGMENT_SIZE=129024
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_NAME_001=/dev/raw/raw28
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_NAME_002=/dev/raw/raw29
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_SIZE_001=524288
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_SIZE_002=524288
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_TYPE_001=R
2008-09-16 15:54:01 6300 20235 RTE LOG_VOLUME_TYPE_002=R
2008-09-16 15:54:01 6300 20235 RTE LRU_FOR_SCAN=NO
2008-09-16 15:54:01 6300 20235 RTE MAXBACKUPDEVS=32
2008-09-16 15:54:01 6300 20235 RTE MAXCPU=3
2008-09-16 15:54:01 6300 20235 RTE MAXDATAVOLUMES=40
2008-09-16 15:54:01 6300 20235 RTE _MAXEVENTS=100
2008-09-16 15:54:01 6300 20235 RTE _MAXEVENTTASKS=2
2008-09-16 15:54:01 6300 20235 RTE _MAXGARBAGE_COLL=1
2008-09-16 15:54:01 6300 20235 RTE MAXLOCKS=1000000
2008-09-16 15:54:01 6300 20235 RTE MAXLOGVOLUMES=4
2008-09-16 15:54:01 6300 20235 RTE MAXPAGER=64
2008-09-16 15:54:01 6300 20235 RTE MAXRGN_REQUEST=-1
2008-09-16 15:54:01 6300 20235 RTE MAXSERVERTASKS=116
2008-09-16 15:54:01 6300 20235 RTE _MAXTASK_STACK=512
2008-09-16 15:54:01 6300 20235 RTE _MAXTRANS=1604
2008-09-16 15:54:01 6300 20235 RTE MAXUSERTASKS=200
2008-09-16 15:54:01 6300 20235 RTE MAXVOLUMES=45
2008-09-16 15:54:01 6300 20235 RTE MAX_HASHTABLE_MEMORY=5120
2008-09-16 15:54:01 6300 20235 RTE MAX_LOG_QUEUE_COUNT=0
2008-09-16 15:54:01 6300 20235 RTE _MAX_MESSAGE_FILES=0
2008-09-16 15:54:01 6300 20235 RTE MAX_MESSAGE_LIST_LENGTH=100
2008-09-16 15:54:01 6300 20235 RTE MAX_RETENTION_TIME=480
2008-09-16 15:54:01 6300 20235 RTE MAX_SERVERTASK_STACK=500
2008-09-16 15:54:01 6300 20235 RTE MAX_SINGLE_HASHTABLE_SIZE=512
2008-09-16 15:54:01 6300 20235 RTE MAX_SPECIALTASK_STACK=500
2008-09-16 15:54:01 6300 20235 RTE _MBLOCK_DATA_SIZE=32768
2008-09-16 15:54:01 6300 20235 RTE _MBLOCK_QUAL_SIZE=32768
2008-09-16 15:54:01 6300 20235 RTE _MBLOCK_STACK_SIZE=32768
2008-09-16 15:54:01 6300 20235 RTE _MBLOCK_STRAT_SIZE=16384
2008-09-16 15:54:01 6300 20235 RTE MCOD=NO
2008-09-16 15:54:01 6300 20235 RTE MEMORY_ALLOCATION_LIMIT=0
2008-09-16 15:54:01 6300 20235 RTE _MINREPLY_SIZE=4096
2008-09-16 15:54:01 6300 20235 RTE MINSERVERTASKS=116
2008-09-16 15:54:01 6300 20235 RTE MIN_RETENTION_TIME=60
2008-09-16 15:54:01 6300 20235 RTE MONITOR_READ=2147483647
2008-09-16 15:54:01 6300 20235 RTE MONITOR_ROWNO=0
2008-09-16 15:54:01 6300 20235 RTE MONITOR_SELECTIVITY=0
2008-09-16 15:54:01 6300 20235 RTE MONITOR_TIME=2147483647
2008-09-16 15:54:01 6300 20235 RTE _MP_DISP_LOOPS=2
2008-09-16 15:54:01 6300 20235 RTE _MP_DISP_PRIO=DEFAULT
2008-09-16 15:54:01 6300 20235 RTE _MP_RGN_BUSY_WAIT=DEFAULT
2008-09-16 15:54:01 6300 20235 RTE _MP_RGN_DIRTY_READ=DEFAULT
2008-09-16 15:54:01 6300 20235 RTE MP_RGN_LOOP=-1
2008-09-16 15:54:01 6300 20235 RTE _MP_RGN_PRIO=DEFAULT
2008-09-16 15:54:01 6300 20235 RTE _MP_RGN_QUEUE=YES
2008-09-16 15:54:01 6300 20235 RTE NO_SYNC_TO_DISK_WANTED=NO
2008-09-16 15:54:01 6300 20235 RTE OFFICIAL_NODE=
2008-09-16 15:54:01 6300 20235 RTE OMS_HEAP_BLOCKSIZE=10000
2008-09-16 15:54:01 6300 20235 RTE OMS_HEAP_COUNT=8
2008-09-16 15:54:01 6300 20235 RTE OMS_HEAP_LIMIT=0
2008-09-16 15:54:01 6300 20235 RTE OMS_HEAP_THRESHOLD=100
2008-09-16 15:54:01 6300 20235 RTE _OMS_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE _OMS_RGNS=7
2008-09-16 15:54:01 6300 20235 RTE OMS_RUN_IN_UDE_SERVER=NO
2008-09-16 15:54:01 6300 20235 RTE OMS_STREAM_TIMEOUT=30
2008-09-16 15:54:01 6300 20235 RTE OMS_VERS_THRESHOLD=2097152
2008-09-16 15:54:01 6300 20235 RTE ONLINE=1
2008-09-16 15:54:01 6300 20235 RTE OPMSG1=/dev/console
2008-09-16 15:54:01 6300 20235 RTE OPMSG2=/dev/null
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_AGGREGATION=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_FETCH_REVERSE=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_FIRST_ROWS=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_HASHTABLE=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_HASH_MINIMAL_RATIO=1
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_ONEPHASE=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_OPERATOR_SORT=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_OUTER=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_PARALLEL_MINSIZE=1000000
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_JOIN_PARALLEL_SERVERS=0
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_MIN_MAX=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_OPERATOR_JOIN_COSTFUNC=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_OPERATOR_JOIN=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_QUAL_ON_INDEX=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_QUERYREWRITE=OPERATOR
2008-09-16 15:54:01 6300 20235 RTE OPTIMIZE_STAR_JOIN=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIM_CACHE=NO
2008-09-16 15:54:01 6300 20235 RTE OPTIM_INV_ONLY=YES
2008-09-16 15:54:01 6300 20235 RTE OPTIM_JOIN_FETCH=0
2008-09-16 15:54:01 6300 20235 RTE OPTIM_MAX_MERGE=500
2008-09-16 15:54:01 6300 20235 RTE OUTOFSESSIONS=3
2008-09-16 15:54:01 6300 20235 RTE _PACKET_SIZE=131072
2008-09-16 15:54:01 6300 20235 RTE _PAGE_SIZE=8192
2008-09-16 15:54:01 6300 20235 RTE PREALLOCATE_IOWORKER=NO
2008-09-16 15:54:01 6300 20235 RTE _PRIO_BASE_COM=10
2008-09-16 15:54:01 6300 20235 RTE _PRIO_BASE_IOC=80
2008-09-16 15:54:01 6300 20235 RTE _PRIO_BASE_RAV=80
2008-09-16 15:54:01 6300 20235 RTE _PRIO_BASE_REX=40
2008-09-16 15:54:01 6300 20235 RTE _PRIO_BASE_U2U=100
2008-09-16 15:54:01 6300 20235 RTE _PRIO_FACTOR=80
2008-09-16 15:54:01 6300 20235 RTE PROTECT_DATACACHE_MEMORY=NO
2008-09-16 15:54:01 6300 20235 RTE _READAHEAD_BLOBS=32
2008-09-16 15:54:01 6300 20235 RTE REQUEST_TIMEOUT=5000
2008-09-16 15:54:01 6300 20235 RTE RESERVEDSERVERTASKS=75
2008-09-16 15:54:01 6300 20235 RTE _RESTART_TIME=600
2008-09-16 15:54:01 6300 20235 RTE ROW_LOCKS_PER_TRANSACTION=50
2008-09-16 15:54:01 6300 20235 RTE _ROW_RGNS=8
2008-09-16 15:54:01 6300 20235 RTE _RTEDUMPFILE=rtedump
2008-09-16 15:54:01 6300 20235 RTE RTE_TEST_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE RUNDIRECTORY=/sapdb/data/wrk/PSR
2008-09-16 15:54:01 6300 20235 RTE SEQUENCE_CACHE=1
2008-09-16 15:54:01 6300 20235 RTE _SERVERDB_FOR_SAP=YES
2008-09-16 15:54:01 6300 20235 RTE SESSION_TIMEOUT=900
2008-09-16 15:54:01 6300 20235 RTE SET_VOLUME_LOCK=YES
2008-09-16 15:54:01 6300 20235 RTE SHAREDSQL_CLEANUPTHRESHOLD=25
2008-09-16 15:54:01 6300 20235 RTE SHAREDSQL_COMMANDCACHESIZE=262144
2008-09-16 15:54:01 6300 20235 RTE SHAREDSQL=YES
2008-09-16 15:54:01 6300 20235 RTE _SHMKERNEL=24377
2008-09-16 15:54:01 6300 20235 RTE SHOW_MAX_KB_STACK_USE=NO
2008-09-16 15:54:01 6300 20235 RTE SHOW_MAX_STACK_USE=NO
2008-09-16 15:54:01 6300 20235 RTE SIMULATE_VECTORIO=NEVER
2008-09-16 15:54:01 6300 20235 RTE SPINLOCK_BACKOFF_BASE=1
2008-09-16 15:54:01 6300 20235 RTE SPINLOCK_BACKOFF_FACTOR=2
2008-09-16 15:54:01 6300 20235 RTE SPINLOCK_BACKOFF_MAXIMUM=64
2008-09-16 15:54:01 6300 20235 RTE SPINLOCK_LOOP_COUNT=30000
2008-09-16 15:54:01 6300 20235 RTE STANDBY=1
2008-09-16 15:54:01 6300 20235 RTE SUBTREE_LOCKS=NO
2008-09-16 15:54:01 6300 20235 RTE SUPPRESS_CORE=YES
2008-09-16 15:54:01 6300 20235 RTE SYMBOL_DEMANGLING=NO
2008-09-16 15:54:01 6300 20235 RTE SYMBOL_RESOLUTION=YES
2008-09-16 15:54:01 6300 20235 RTE SYSTEMERROR=3
2008-09-16 15:54:01 6300 20235 RTE _TAB_RGNS=8
2008-09-16 15:54:01 6300 20235 RTE _TASKCLUSTER_01=tw;al;ut;100*bup;10*ev,10*gc;
2008-09-16 15:54:01 6300 20235 RTE _TASKCLUSTER_02=ti,100*dw;67*us,39*sv;
2008-09-16 15:54:01 6300 20235 RTE _TASKCLUSTER_03=equalize
2008-09-16 15:54:01 6300 20235 RTE TIME_MEASUREMENT=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_AK=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_ALLOCATOR=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_CATALOG=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_CLIENTKERNELCOM=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_COMMON=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_COMMUNICATION=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_CONVERTER=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DATACACHE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DATACHAIN=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DATAINDEX=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DATAPAM=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DATATREE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DBPROC=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_DEFAULT=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_DELETE=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_FBM=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_FILEDIR=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_FRAMECTRL=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_INDEX=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_INSERT=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_IOMAN=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_IPC=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_JOIN=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_KSQL=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOCKMANAGER=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOCK=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOGACTION=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOGHISTORY=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOGPAGE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOGTRANS=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LOGVOLUME=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_LONG=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_MEMORY=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_MESSAGES=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECTCONTAINER=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECT_ADD=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECT_ALTER=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECT_FREE=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECT_GET=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_OBJECT=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_CONTAINERDIR=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_CONTEXT=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_ERROR=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_FLUSHCACHE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_INTERFACE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_KEYRANGE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_KEY=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_LOCK=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_MEMORY=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_NEWOBJ=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_SESSION=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_STREAM=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_VAROBJECT=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OMS_VERSION=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_OPTIMIZE=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_ORDER_STANDARD=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_ORDER=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGER=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_BUP=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_EV=2
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_GC=20
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_LW=5
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_PG=3
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_SV=5
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_TI=2
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_US=10
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES_UT=5
2008-09-16 15:54:01 6300 20235 RTE TRACE_PAGES=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_PRIMARY_TREE=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_QUERYREWRITE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_RUNTIME=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_SELECT=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_SHAREDSQL=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_SQLMANAGER=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_SRVTASKS=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_STOP_ERRORCODE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_SYNCHRONISATION=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_SYSVIEW=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_TABLE=0
2008-09-16 15:54:01 6300 20235 RTE TRACE_TIME=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_UPDATE=NO
2008-09-16 15:54:01 6300 20235 RTE TRACE_VOLUME=0
2008-09-16 15:54:01 6300 20235 RTE TRANS_HISTORY_SIZE=0
2008-09-16 15:54:01 6300 20235 RTE _TRANS_RGNS=8
2008-09-16 15:54:01 6300 20235 RTE TRANS_THRESHOLD_VALUE=60
2008-09-16 15:54:01 6300 20235 RTE UKT_CPU_RELATIONSHIP=NONE
2008-09-16 15:54:01 6300 20235 RTE _UNICODE=YES
2008-09-16 15:54:01 6300 20235 RTE UPDATESTAT_PARALLEL_SERVERS=0
2008-09-16 15:54:01 6300 20235 RTE UPDATESTAT_SAMPLE_ALGO=1
2008-09-16 15:54:01 6300 20235 RTE UPDSTATWANTED=1
2008-09-16 15:54:01 6300 20235 RTE USED_MAX_LOG_QUEUE_COUNT=3
2008-09-16 15:54:01 6300 20235 RTE USESELECTFETCH=YES
2008-09-16 15:54:01 6300 20235 RTE USEUNICODECOLUMNCOMPRESSION=NO
2008-09-16 15:54:01 6300 20235 RTE USEVARIABLEINPUT=NO
2008-09-16 15:54:01 6300 20235 RTE USE_COROUTINES=YES
2008-09-16 15:54:01 6300 20235 RTE _USE_IOPROCS_ONLY=NO
2008-09-16 15:54:01 6300 20235 RTE USE_OPEN_DIRECT_FOR_BACKUP=YES
2008-09-16 15:54:01 6300 20235 RTE USE_OPEN_DIRECT=YES
2008-09-16 15:54:01 6300 20235 RTE USE_SYSTEM_PAGE_CACHE=YES
2008-09-16 15:54:01 6300 20235 RTE _UTILITY_PROTFILE=dbm.utl
2008-09-16 15:54:01 6300 20235 RTE UTILITY_PROTSIZE=100
2008-09-16 15:54:01 6300 20235 RTE VOLUMENO_BIT_COUNT=8
2008-09-16 15:54:01 6300 20235 RTE _WORKDATA_SIZE=8192
2008-09-16 15:54:01 6300 20235 RTE _WORKSTACK_SIZE=8192
2008-09-16 15:54:01 6300 20235 RTE XP_CONVERTER_REGIONS=0
2008-09-16 15:54:01 6300 20235 RTE XP_DATA_CACHE_RGNS=0
2008-09-16 15:54:01 6300 20235 RTE XP_MAXPAGER=0> Some things are quite disturbing:
>
>
x_cons <SID> show sus
>
> SERVERDB: <SID>
>
> List of suspend-reasons:
> ========================
>
> Total Suspends: 428083
>
> Vsuspend (203) : 426288 ( 99.58% ) kb39read_wait
> Vsuspend (204) : 1611 ( 0.38% ) kb39write_wait
> JobWait BckRec : 1 ( 0.00% ) SrvTasks_BackupServer::WaitForAnyJobFini
> No-Work (255) : 183 ( 0.04% ) Task is waiting for work
What exactly do you find disturbing with that information?
All we see here is how often a specific suspend had been triggered since the database was started. We don't see how long these suspends took and neither do we know what the suspend reason is, that would be important for your current issue.
>
x_cons <SID> show tasks|grep BUP
> T71 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T72 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T73 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T74 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T75 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T76 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T77 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T78 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T79 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T80 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T81 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T82 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T83 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T84 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T85 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T86 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T87 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T88 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T89 6 -1 BUPmed -1 Vsuspend (203) 0 0 1027577(s)
> T92 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T109 6 -1 BUPvol -1 AsynWaitWrite 0 0 1027577(s)
> T111 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T112 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T128 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T129 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T130 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T131 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T132 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T133 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T134 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T135 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T136 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T137 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T138 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T139 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T140 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T141 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T142 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T143 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T144 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
> T148 7 -1 BUPvol -1 AsynWaitWrite 0 0 345248(s)
Ok, here we see that the MaxDB kernel is waiting for writes to the datavolumes to get finished. As we've only one snapshot here, we cannot tell anything more from it. You either should perform several snapshots in a row, or (better!) use the DBAnalyzer with a short sample interval, say 60 seconds.
Also you should enable the time measurement, so that we can have some I/O related timing information.
> I tried changing parameters a bit with no visible effort. The current parameters of the target system are:
What parameters did you change? Why? And to what values did you set them?
>
> 2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0001=R
> 2008-09-16 15:54:01 6300 20235 RTE DATA_VOLUME_TYPE_0002=R
Ok, since you use RAW devices (good choice!) there shouldn't be any issues with the I/O on the OS level.
What's left is: how are the RAW devices physically stored?
Could it be that writing to your RAW devices is pretty expensive?
Ah - before I forget: if you're a SAP customer this should be investigated in a support message!
Best regards,
Lars
Maybe you are looking for
-
i want to take printout of purchase order created via me21n in a smartform . please suggest how should i proceed . any piece of code or link will be highly appreciated . regards navjot
-
ASA 5525-X code 8.6.1 downgrade
Can I downgrade the firewall code to 8.0, it's running 8.6.1 right now.
-
I just upgraded from PS CS4 to CS5. Everything okay except I can't access my third-party plug-ins in CS5 that I was using in CS4. Any suggestions about how to load them in CS5.
-
Why can't i find notification bar story in nfl mobile?
Whenever i get a notification for a story on NFL Mobile and i open the app, the story is nowhere to be found- not in Media, My Team, Fantasy, or anywhere else. What gives?
-
Hi, I want to post an EDI 824(error IDOC) for 855 which is a PO acknowledgement. Now I have all validations in FM "IDOC_INPUT_ORDRSP" processing of 855 IDOC. Now What all steps do i consider to convert the error 855 IDOC into 824 IDOC. Thanks Balu