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?
    Thanks

    Hi,
    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,
    Chan

    Hi,
    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 PM

    Marc,
    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!
    Chris

    This 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.
    Jose

    Hi 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,
    Fredrik

    Hi,
    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?
    Thanks

    ok 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

  • Me21n printout

    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.

  • PS CS5 Third Party Plug In

    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?

  • Implementing EDI 824 for 855

    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