Query SQLite / performance

I have a performance problem with a SQLite query:

Constellation:

Table 1 (88933 records):
CREATE TABLE [ItemPrice])
'ItemPrice_NrIntern' nvarchar (20) NOT NULL COLLATE NOCASE.
"ItemPrice_Pricelist" integer NOT NULL,
'ItemPrice_Col3' nvarchar (3) COLLATE NOCASE.
"ItemPrice_Col4" digital,
"ItemPrice_Col5" digital,
"ItemPrice_Col6" (1) COLLATE NOCASE nvarchar,
'ItemPrice_Col7,' integer
'ItemPrice_Col8,' integer
"ItemPrice_Col9" digital,
'ItemPrice_Col10' nvarchar (3) COLLATE NOCASE.
"ItemPrice_Col11" digital,
"ItemPrice_Col12" digital,
"ItemPrice_Col13" digital,
DateTime "ItemPrice_Col14."
KEY ELEMENTARY ([ItemPrice_NrIntern], [ItemPrice_Pricelist])
,
FOREIGN KEY ([ItemPrice_NrIntern])
REFERENCES []([Items_NrIntern]) Items
)

Table 2 (51822 records):
CREATE TABLE [features])
'Items_NrIntern' nvarchar (20) NOT NULL COLLATE NOCASE.
'Items_NrExtern' nvarchar (20) NOT NULL COLLATE NOCASE.
'Items_Text' nvarchar (50) COLLATE NOCASE.
'Items_Col4' nvarchar (4) COLLATE NOCASE.
"Items_Col5" (1) COLLATE NOCASE nvarchar,
'Items_SortNr' nvarchar (20) COLLATE NOCASE, //this column is indexed
'Items_Col7' nvarchar (15) COLLATE NOCASE.
"Items_Col8" (1) COLLATE NOCASE nvarchar,
"Items_Col9" (1) COLLATE NOCASE nvarchar,
'Items_Col10' nvarchar (7) COLLATE NOCASE.
'Items_Col11' nvarchar (7) COLLATE NOCASE.
'Items_Col12' nvarchar (7) COLLATE NOCASE.
DateTime "Items_Col13."
KEY ELEMENTARY ([Items_NrIntern])
)

View:
CREATE VIEW AS SELECT i.Items_SortNr vw1
i.Items_NrIntern
i.Items_NrExtern
i.Items_Text
ITEMS I have
INNER JOIN ItemPrice ip ON i.Items_NrIntern is ip. ItemPrice_NrIntern
WHERE ip. ItemPrice_Pricelist = 1

-------------------------------------------------------------------------

Query 1 (the problem):
If I execute the following query:

SELECT * FROM ORDER BY Items_SortNr LIMIT 50 vw1

.. .in my application on the Simulator to 8900, the execution time is
always from 10 to 11 seconds!

.. .in my app on my BlackBerry 9700, the execution time is
always between 33 and 34 seconds!

If I run the same query in Firefox SQLite Manager, the execution time is
always between 400 and 500 milliseconds!

-------------------------------------------------------------------------

CodeSnip of the execution of the query:
Statement statement = db.createStatement (new String (sql.getBytes("utf-8")));
Statement.Prepare ();
Cursor c = statement.getCursor ();
While (c.next ()) {/ /}<--- executing="" this="" line="" takes="" round="" about="" 10="" sec/simulator="" and="" 33="">
Line r = (Row) c.getRow ();
.
.
.
}

Query 2 (best performance):
If I execute the following query:

SELECT * FROM vw1 WHERE (Items_NrIntern AS 65 %') ORDER BY Items_SortNr)

.. .in my application on the Simulator to 8900, the execution time is
always between 160 and 180 milliseconds

If I run the same query in Firefox SQLite Manager, the execution time is
still between 70 and 100 milliseconds!

-------------------------------------------------------------------------

Now, I created the view as follows (without a JOIN):
CREATE VIEW vw1 AS SELECT ip. ItemPrice_NrIntern
'Items_NrExtern' AS Items_NrExtern
'Items_Text' AS Items_Text
1 AS Items_SortNr
OF ip ItemPrice
WHERE ip. ItemPrice_Pricelist = 1

If I run the query 1 now, it takes between 250 and 350 milliseconds!

Now, I created the view as follows (without a JOIN):
CREATE VIEW vw1 AS SELECT i.Items_NrIntern AS ItemPrice_NrIntern
i.Items_NrExtern
i.Items_Text
i.Items_SortNr
ITEMS I have

If I run the query 1 now, it takes between 850 and 1100 milliseconds!

-------------------------------------------------------------------------

Any suggestions?

THX.
Martin
BlackBerry JDE 5

I had once a very long request because of an ORDER BY.

Try to remove your ORDER BY and sorting later in java with SimpleSortingVector: I'm not fond of this type, but in this way, I came from 12 to 2 seconds.

Tags: BlackBerry Developers

Similar Questions

  • The identical query, unusable performance in an environment - please help

    We strive to improve 10.2.0.4 to 11.2.0.2, but one of our considered requests is completely wrong (30 seconds in our current environment, 4000 in our upgraded environment).

    Note that the caveat is that it will be very difficult for me to edit the SQL code (his coming of another group of TI, as well as their position is that he should not have to be changed given the fact that it works so well in the current production environment).

    The query is exactly the same in both environments and transports the SQL_ID, but explain the plans are different.

    The environment in which the application works is version 10.2.0.4 and time the trace is 30,15 seconds, 841 rows returned.
    The new environment is 11.2.0.2, the elapsed time is 4035 seconds, 841 rows returned.

    The environments are comparable in terms of CPU/memory/IO (the two are written for on our NetApp NFS mounts)

    SGA_MAX/TARGET and PGA_AGGREGATE_TARGET are the same in both environments, as well as HASH_AREA_SIZE and SORT_AREA_SIZE.

    The table database is identical, and all of the indexes are the same in both environments. His stats were collected and this behavior has persisted through several reboots of the databases.

    I ran traces on statements in both environments and the performance difference seems to be due to direct path read/write temp:

    The SQL
    SELECT DISTINCT
             a.emplid,
             a.name,
             rds.sa_get_stdnt_email_fn (a.emplid),
             a.req_term,
             a.req_term_ldesc,
             CASE
                WHEN (a.req_acad_plan = 'PKINXXXBBS' AND a.cum_gpa >= d.gpa)
                THEN
                   NVL (c.num_met, 0) + 1
                WHEN (b.gpa >= d.gpa AND a.req_acad_plan <> 'PKINXXXBBS')
                THEN
                   NVL (c.num_met, 0) + 1
                ELSE
                   NVL (c.num_met, 0)
             END
                AS "Requirement Status",
             a.cum_total_passed AS "Cumulative Units",
             a.admit_term,
             a.admit_term_ldesc,
             a.acad_plan,
             a.acad_plan_ldesc,
             a.academic_level,
             a.academic_level_ldesc,
             TO_CHAR (a.rpt_date, 'MM/DD/YYYY') AS rpt_date,
             TO_CHAR (NVL (b.gpa, 0), '0.000') AS gpa,
             TO_CHAR (NVL (a.cum_gpa, 0), '0.000') AS cum_gpa
        FROM sa.rec_sm_stdnt_deg_completion a,
             (  SELECT DISTINCT
                       CASE
                          WHEN SUM (b_sub.units_earned) = 0 THEN 0
                          ELSE SUM (b_sub.grade_points) / SUM (b_sub.units_earned)
                       END
                          AS gpa,
                       b_sub.emplid,
                       b_sub.acad_career,
                       b_sub.acad_plan,
                       b_sub.req_acad_plan,
                       b_sub.req_term,
                       b_sub.academic_level,
                       b_sub.rqrmnt_group
                  FROM sa.rec_sm_stdnt_deg_completion b_sub,
                       hrsa_extr.ps_rq_grp_tbl g3,
                       hrsa_extr.ps_rq_main_tbl m3
                 WHERE     b_sub.req_acad_plan IS NOT NULL
                       AND b_sub.acad_career = 'UGRD'
                       AND b_sub.acad_prog = 'UBACH'
                       AND b_sub.acad_plan = b_sub.req_acad_plan
                       AND b_sub.grade <> 'IP'
                       AND b_sub.impact_flag = 'Y'
                       AND g3.effdt =
                              (SELECT MAX (g3_ed.effdt)
                                 FROM hrsa_extr.ps_rq_grp_tbl g3_ed
                                WHERE     g3_ed.rqrmnt_group = g3.rqrmnt_group
                                      AND g3_ed.effdt <= b_sub.req_term_begin_date)
                       AND g3.rqrmnt_group = b_sub.rqrmnt_group
                       AND m3.effdt =
                              (SELECT MAX (m3_ed.effdt)
                                 FROM hrsa_extr.ps_rq_main_tbl m3_ed
                                WHERE     m3_ed.requirement = m3.requirement
                                      AND m3_ed.effdt <= b_sub.req_term_begin_date)
                       AND m3.requirement = b_sub.requirement
              GROUP BY b_sub.emplid,
                       b_sub.acad_career,
                       b_sub.acad_plan,
                       b_sub.req_acad_plan,
                       b_sub.req_term,
                       b_sub.academic_level,
                       b_sub.rqrmnt_group) b,
             (  SELECT c_sub.emplid,
                       c_sub.acad_career,
                       c_sub.acad_plan,
                       c_sub.req_acad_plan,
                       c_sub.req_term,
                       c_sub.academic_level,
                       c_sub.rqrmnt_group,
                       COUNT (*) AS num_met
                  FROM sa.rec_sm_stdnt_deg_completion c_sub,
                       hrsa_extr.ps_rq_grp_tbl g2,
                       hrsa_extr.ps_rq_main_tbl m2
                 WHERE     c_sub.rqrmnt_line_status = 'COMP'
                       AND c_sub.grade <> 'IP'
                       AND c_sub.impact_flag = 'Y'
                       AND c_sub.acad_career = 'UGRD'
                       AND c_sub.acad_prog = 'UBACH'
                       AND c_sub.acad_plan = c_sub.req_acad_plan
                       AND g2.effdt =
                              (SELECT MAX (g2_ed.effdt)
                                 FROM hrsa_extr.ps_rq_grp_tbl g2_ed
                                WHERE     g2_ed.rqrmnt_group = g2.rqrmnt_group
                                      AND g2_ed.effdt <= c_sub.req_term_begin_date)
                       AND g2.rqrmnt_group = c_sub.rqrmnt_group
                       AND m2.effdt =
                              (SELECT MAX (m2_ed.effdt)
                                 FROM hrsa_extr.ps_rq_main_tbl m2_ed
                                WHERE     m2_ed.requirement = m2.requirement
                                      AND m2_ed.effdt <= c_sub.req_term_begin_date)
                       AND m2.requirement = c_sub.requirement
              GROUP BY c_sub.emplid,
                       c_sub.acad_career,
                       c_sub.acad_plan,
                       c_sub.req_acad_plan,
                       c_sub.req_term,
                       c_sub.academic_level,
                       c_sub.rqrmnt_group) c,
             hrsa_extr.ps_smo_rdr_imp_pln d,
             hrsa_extr.ps_rq_grp_tbl g,
             hrsa_extr.ps_rq_main_tbl m
       WHERE     a.acad_career = 'UGRD'
             AND a.acad_prog = 'UBACH'
             AND a.req_acad_plan IN (N'NUPPXXXBBS', N'NURPBASBBS', N'NURPXXXBBS')
             AND a.academic_level IN (N'10', N'20', N'30', N'40', N'50', N'GR')
             AND a.acad_plan = a.req_acad_plan
             AND a.impact_flag = 'Y'
             AND g.effdt =
                    (SELECT MAX (g_ed.effdt)
                       FROM hrsa_extr.ps_rq_grp_tbl g_ed
                      WHERE     g_ed.rqrmnt_group = g.rqrmnt_group
                            AND g_ed.effdt <= a.req_term_begin_date)
             AND g.rqrmnt_group = a.rqrmnt_group
             AND m.effdt =
                    (SELECT MAX (m_ed.effdt)
                       FROM hrsa_extr.ps_rq_main_tbl m_ed
                      WHERE     m_ed.requirement = m.requirement
                            AND m_ed.effdt <= a.req_term_begin_date)
             AND m.requirement = a.requirement
             AND a.emplid = b.emplid(+)
             AND a.acad_career = b.acad_career(+)
             AND a.acad_plan = b.acad_plan(+)
             AND a.req_acad_plan = b.req_acad_plan(+)
             AND a.academic_level = b.academic_level(+)
             AND a.req_term = b.req_term(+)
             AND a.rqrmnt_group = b.rqrmnt_group(+)
             AND a.emplid = c.emplid(+)
             AND a.acad_career = c.acad_career(+)
             AND a.acad_plan = c.acad_plan(+)
             AND a.req_acad_plan = c.req_acad_plan(+)
             AND a.academic_level = c.academic_level(+)
             AND a.req_term = c.req_term(+)
             AND a.rqrmnt_group = c.rqrmnt_group(+)
             AND d.acad_plan = a.req_acad_plan
    ORDER BY 6 DESC, 2 ASC;
    New environment (11.2.0.2), takes 4000 seconds according to tkprof

    Explain plan
    PLAN_TABLE_OUTPUT
    -------------------------------------------------------------------------------------------------------------------------
    Plan hash value: 4117596694
    
    -------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                                 | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    -------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                          |                             |     1 |   314 | 15231   (1)| 00:03:03 |
    |   1 |  SORT UNIQUE                              |                             |     1 |   314 | 15230   (1)| 00:03:03 |
    |   2 |   NESTED LOOPS OUTER                      |                             |     1 |   314 | 15227   (1)| 00:03:03 |
    |   3 |    NESTED LOOPS OUTER                     |                             |     1 |   285 | 15216   (1)| 00:03:03 |
    |   4 |     NESTED LOOPS                          |                             |     1 |   256 | 15205   (1)| 00:03:03 |
    |   5 |      NESTED LOOPS                         |                             |     1 |   241 | 15204   (1)| 00:03:03 |
    |   6 |       NESTED LOOPS                        |                             |     1 |   223 | 15203   (1)| 00:03:03 |
    |   7 |        NESTED LOOPS                       |                             |    17 |   731 | 15186   (1)| 00:03:03 |
    |   8 |         VIEW                              | VW_SQ_3                     |   998 | 27944 | 15186   (1)| 00:03:03 |
    |   9 |          HASH GROUP BY                    |                             |   998 | 62874 | 15186   (1)| 00:03:03 |
    |  10 |           MERGE JOIN                      |                             | 29060 |  1787K| 15184   (1)| 00:03:03 |
    |  11 |            SORT JOIN                      |                             |    26 |  1248 | 15180   (1)| 00:03:03 |
    |  12 |             TABLE ACCESS BY INDEX ROWID   | REC_SM_STDNT_DEG_COMPLETION |    26 |  1248 | 15179   (1)| 00:03:03 |
    |* 13 |              INDEX SKIP SCAN              | REC0SM_STDNT_DEG_IDX        |    26 |       | 15168   (1)| 00:03:03 |
    |* 14 |            SORT JOIN                      |                             |  1217 | 18255 |     4  (25)| 00:00:01 |
    |  15 |             INDEX FAST FULL SCAN          | PS3RQ_GRP_TBL               |  1217 | 18255 |     3   (0)| 00:00:01 |
    |* 16 |         INDEX UNIQUE SCAN                 | PS_RQ_GRP_TBL               |     1 |    15 |     0   (0)| 00:00:01 |
    |* 17 |        TABLE ACCESS BY USER ROWID         | REC_SM_STDNT_DEG_COMPLETION |     1 |   180 |     1   (0)| 00:00:01 |
    |* 18 |       INDEX RANGE SCAN                    | PS_RQ_MAIN_TBL              |     1 |    18 |     1   (0)| 00:00:01 |
    |  19 |        SORT AGGREGATE                     |                             |     1 |    18 |            |          |
    |  20 |         FIRST ROW                         |                             |     1 |    18 |     2   (0)| 00:00:01 |
    |* 21 |          INDEX RANGE SCAN (MIN/MAX)       | PS_RQ_MAIN_TBL              |     1 |    18 |     2   (0)| 00:00:01 |
    |* 22 |      INDEX FULL SCAN                      | PS0SMO_RDR_IMP_PLN          |     1 |    15 |     1   (0)| 00:00:01 |
    |* 23 |     VIEW PUSHED PREDICATE                 |                             |     1 |    29 |    11  (19)| 00:00:01 |
    |  24 |      SORT GROUP BY                        |                             |     1 |    52 |    11  (19)| 00:00:01 |
    |  25 |       VIEW                                | VM_NWVW_5                   |     1 |    52 |    10  (10)| 00:00:01 |
    |* 26 |        FILTER                             |                             |       |       |            |          |
    |  27 |         SORT GROUP BY                     |                             |     1 |   165 |    10  (10)| 00:00:01 |
    |* 28 |          FILTER                           |                             |       |       |            |          |
    |  29 |           NESTED LOOPS                    |                             |     1 |   165 |     7   (0)| 00:00:01 |
    |  30 |            NESTED LOOPS                   |                             |     1 |   147 |     6   (0)| 00:00:01 |
    |  31 |             NESTED LOOPS                  |                             |     1 |   117 |     5   (0)| 00:00:01 |
    |* 32 |              TABLE ACCESS BY INDEX ROWID  | REC_SM_STDNT_DEG_COMPLETION |     1 |    90 |     4   (0)| 00:00:01 |
    |* 33 |               INDEX RANGE SCAN            | REC1SM_STDNT_DEG_IDX        |     1 |       |     3   (0)| 00:00:01 |
    |* 34 |              INDEX RANGE SCAN             | PS_RQ_GRP_TBL               |     1 |    27 |     1   (0)| 00:00:01 |
    |  35 |               SORT AGGREGATE              |                             |     1 |    15 |            |          |
    |  36 |                FIRST ROW                  |                             |     1 |    15 |     2   (0)| 00:00:01 |
    |* 37 |                 INDEX RANGE SCAN (MIN/MAX)| PS_RQ_GRP_TBL               |     1 |    15 |     2   (0)| 00:00:01 |
    |* 38 |             INDEX RANGE SCAN              | PS_RQ_MAIN_TBL              |     1 |    30 |     1   (0)| 00:00:01 |
    |* 39 |            INDEX RANGE SCAN               | PS_RQ_MAIN_TBL              |     1 |    18 |     1   (0)| 00:00:01 |
    |* 40 |    VIEW PUSHED PREDICATE                  |                             |     1 |    29 |    11  (19)| 00:00:01 |
    |  41 |     SORT GROUP BY                         |                             |     1 |    32 |    11  (19)| 00:00:01 |
    |  42 |      VIEW                                 | VM_NWVW_4                   |     1 |    32 |    10  (10)| 00:00:01 |
    |* 43 |       FILTER                              |                             |       |       |            |          |
    |  44 |        SORT GROUP BY                      |                             |     1 |   166 |    10  (10)| 00:00:01 |
    |* 45 |         FILTER                            |                             |       |       |            |          |
    |* 46 |          FILTER                           |                             |       |       |            |          |
    |  47 |           NESTED LOOPS                    |                             |     1 |   166 |     7   (0)| 00:00:01 |
    |  48 |            NESTED LOOPS                   |                             |     1 |   148 |     6   (0)| 00:00:01 |
    |  49 |             NESTED LOOPS                  |                             |     1 |   118 |     5   (0)| 00:00:01 |
    |* 50 |              INDEX RANGE SCAN             | PS_RQ_GRP_TBL               |     1 |    27 |     2   (0)| 00:00:01 |
    |* 51 |              TABLE ACCESS BY INDEX ROWID  | REC_SM_STDNT_DEG_COMPLETION |     1 |    91 |     3   (0)| 00:00:01 |
    |* 52 |               INDEX RANGE SCAN            | REC1SM_STDNT_DEG_IDX        |     1 |       |     2   (0)| 00:00:01 |
    |* 53 |             INDEX RANGE SCAN              | PS_RQ_MAIN_TBL              |     1 |    30 |     1   (0)| 00:00:01 |
    |* 54 |            INDEX RANGE SCAN               | PS_RQ_MAIN_TBL              |     1 |    18 |     1   (0)| 00:00:01 |
    |  55 |          SORT AGGREGATE                   |                             |     1 |    15 |            |          |
    |  56 |           FIRST ROW                       |                             |     1 |    15 |     2   (0)| 00:00:01 |
    |* 57 |            INDEX RANGE SCAN (MIN/MAX)     | PS_RQ_GRP_TBL               |     1 |    15 |     2   (0)| 00:00:01 |
    -------------------------------------------------------------------------------------------------------------------------
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      6.59       6.66          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2   1521.36    4028.91    2256624  240053408          0         841
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        4   1527.95    4035.57    2256624  240053408          0         841
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      Disk file operations I/O                        3        0.07          0.11
      db file sequential read                     10829        0.12         16.62
      direct path write temp                      72445        0.30        293.71
      direct path read temp                       72445        0.58       2234.14
      asynch descriptor resize                       22        0.00          0.00
      SQL*Net more data to client                     9        0.00          0.00
      SQL*Net message from client                     2        0.84          1.25
    ********************************************************************************
    The current production (10.2.0.4), takes 30 seconds
    PLAN_TABLE_OUTPUT
    -------------------------------------------------------------------------------------------------------------------------
    Plan hash value: 2178773127
    
    ------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                                | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                         |                             |     1 |   331 | 89446   (2)| 00:17:54 |
    |   1 |  SORT UNIQUE                             |                             |     1 |   331 | 89445   (2)| 00:17:54 |
    |   2 |   NESTED LOOPS                           |                             |     1 |   331 | 89440   (2)| 00:17:54 |
    |   3 |    NESTED LOOPS                          |                             |     1 |   316 | 89439   (2)| 00:17:54 |
    |*  4 |     HASH JOIN OUTER                      |                             |     1 |   298 | 89438   (2)| 00:17:54 |
    |*  5 |      HASH JOIN OUTER                     |                             |     1 |   240 | 59625   (2)| 00:11:56 |
    |   6 |       NESTED LOOPS                       |                             |     1 |   182 | 29815   (2)| 00:05:58 |
    |*  7 |        TABLE ACCESS FULL                 | REC_SM_STDNT_DEG_COMPLETION |     1 |   167 | 29814   (2)| 00:05:58 |
    |*  8 |        INDEX FULL SCAN                   | PS0SMO_RDR_IMP_PLN          |     1 |    15 |     1   (0)| 00:00:01 |
    |   9 |       VIEW                               |                             |     1 |    58 | 29809   (2)| 00:05:58 |
    |  10 |        HASH GROUP BY                     |                             |     1 |    71 | 29809   (2)| 00:05:58 |
    |  11 |         VIEW                             |                             |     1 |    71 | 29809   (2)| 00:05:58 |
    |* 12 |          FILTER                          |                             |       |       |            |          |
    |  13 |           HASH GROUP BY                  |                             |     1 |   198 | 29809   (2)| 00:05:58 |
    |  14 |            NESTED LOOPS                  |                             |     1 |   198 | 29806   (2)| 00:05:58 |
    |* 15 |             HASH JOIN                    |                             |     1 |   171 | 29805   (2)| 00:05:58 |
    |* 16 |              HASH JOIN                   |                             |     4 |   572 | 29802   (2)| 00:05:58 |
    |* 17 |               TABLE ACCESS FULL          | REC_SM_STDNT_DEG_COMPLETION |     4 |   452 | 29798   (2)| 00:05:58 |
    |  18 |               INDEX FAST FULL SCAN       | PS2RQ_MAIN_TBL              |  1035 | 31050 |     3   (0)| 00:00:01 |
    |  19 |              INDEX FAST FULL SCAN        | PS2RQ_MAIN_TBL              |  1035 | 28980 |     3   (0)| 00:00:01 |
    |* 20 |             INDEX RANGE SCAN             | PS_RQ_GRP_TBL               |     1 |    27 |     1   (0)| 00:00:01 |
    |  21 |              SORT AGGREGATE              |                             |     1 |    15 |            |          |
    |  22 |               FIRST ROW                  |                             |     1 |    15 |     2   (0)| 00:00:01 |
    |* 23 |                INDEX RANGE SCAN (MIN/MAX)| PS_RQ_GRP_TBL               |     1 |    15 |     2   (0)| 00:00:01 |
    |  24 |      VIEW                                |                             |     1 |    58 | 29813   (2)| 00:05:58 |
    |  25 |       HASH GROUP BY                      |                             |     1 |    45 | 29813   (2)| 00:05:58 |
    |  26 |        VIEW                              |                             |     1 |    45 | 29813   (2)| 00:05:58 |
    |* 27 |         FILTER                           |                             |       |       |            |          |
    |  28 |          HASH GROUP BY                   |                             |     1 |   199 | 29813   (2)| 00:05:58 |
    |  29 |           NESTED LOOPS                   |                             |     1 |   199 | 29810   (2)| 00:05:58 |
    |* 30 |            HASH JOIN                     |                             |     1 |   172 | 29809   (2)| 00:05:58 |
    |* 31 |             HASH JOIN                    |                             |     8 |  1152 | 29805   (2)| 00:05:58 |
    |* 32 |              TABLE ACCESS FULL           | REC_SM_STDNT_DEG_COMPLETION |     7 |   798 | 29802   (2)| 00:05:58 |
    |  33 |              INDEX FAST FULL SCAN        | PS2RQ_MAIN_TBL              |  1035 | 31050 |     3   (0)| 00:00:01 |
    |  34 |             INDEX FAST FULL SCAN         | PS2RQ_MAIN_TBL              |  1035 | 28980 |     3   (0)| 00:00:01 |
    |* 35 |            INDEX RANGE SCAN              | PS_RQ_GRP_TBL               |     1 |    27 |     1   (0)| 00:00:01 |
    |  36 |             SORT AGGREGATE               |                             |     1 |    15 |            |          |
    |  37 |              FIRST ROW                   |                             |     1 |    15 |     2   (0)| 00:00:01 |
    |* 38 |               INDEX RANGE SCAN (MIN/MAX) | PS_RQ_GRP_TBL               |     1 |    15 |     2   (0)| 00:00:01 |
    |* 39 |     INDEX RANGE SCAN                     | PS_RQ_MAIN_TBL              |     1 |    18 |     1   (0)| 00:00:01 |
    |  40 |      SORT AGGREGATE                      |                             |     1 |    18 |            |          |
    |  41 |       FIRST ROW                          |                             |     1 |    18 |     2   (0)| 00:00:01 |
    |* 42 |        INDEX RANGE SCAN (MIN/MAX)        | PS_RQ_MAIN_TBL              |     1 |    18 |     2   (0)| 00:00:01 |
    |* 43 |    INDEX RANGE SCAN                      | PS_RQ_GRP_TBL               |     1 |    15 |     1   (0)| 00:00:01 |
    |  44 |     SORT AGGREGATE                       |                             |     1 |    15 |            |          |
    |  45 |      FIRST ROW                           |                             |     1 |    15 |     2   (0)| 00:00:01 |
    |* 46 |       INDEX RANGE SCAN (MIN/MAX)         | PS_RQ_GRP_TBL               |     1 |    15 |     2   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------------------------------------
    call     count       cpu    elapsed       disk      query    current        rows
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    Parse        1      1.49       1.51          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2     18.25      28.63     463672     932215          0         836
    ------- ------  -------- ---------- ---------- ---------- ----------  ----------
    total        4     19.75      30.15     463672     932215          0         836
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      db file scattered read                      14262        0.31         13.13
      latch: shared pool                              1        0.01          0.01
      db file sequential read                         7        0.00          0.00
      direct path write temp                        493        0.00          0.00
      direct path read temp                         493        0.00          0.00
      SQL*Net more data to client                    40        0.00          0.00
      SQL*Net message from client                     2        0.83          1.23
    ********************************************************************************
    Published by: ngilbert on June 26, 2012 16:40

    Published by: ngilbert on June 26, 2012 16:41

    Hello

    as is almost always the case, your bad plan is the result of messed up the cardinality estimates. The biggest problem seems to be the cardinality in steps 12 and 13 of the bad plan:

    |  12 |             TABLE ACCESS BY INDEX ROWID   | REC_SM_STDNT_DEG_COMPLETION |    26 |  1248 | 15179   (1)| 00:03:03 |
    |* 13 |              INDEX SKIP SCAN              | REC0SM_STDNT_DEG_IDX        |    26 |       | 15168   (1)| 00:03:03 |
    

    that is the estimated cardinality is 26. But if we look at the map, we see that the actual number of lines is 4 orders of magnitude (!) higher than that. So of course this goes wrong from there: the optimizer uses weird join methods, wrong join order etc.

    And if we look at the predicate:

    13 - access("A"."ACAD_CAREER"='UGRD' AND "A"."ACAD_PROG"='UBACH' AND "A"."IMPACT_FLAG"='Y')
           filter("A"."ACAD_PLAN"="A"."REQ_ACAD_PLAN" AND "A"."ACAD_PROG"='UBACH' AND "A"."IMPACT_FLAG"='Y' AND
                  "A"."ACAD_CAREER"='UGRD')
    

    We can assume that the problem is related to the related predicates: you select lines of tables with 4 equality predicates, but 260 k lines survive this filtering. The optimizer thinks that it is closer to 26, not 260 k, but it's probably because the predicates are not really independent.

    There is another thing that seems suspicious: filter predicate is redundant with the predicates of access. There is another discussion on OTN not so long ago, and it turned out to be a symptom of a bug (which makes it even more suspect, is that it was also a SKIP SCAN). See:

    Re: CBO does not consider cheaper NL-Plan without guidance

    Hope that was helpful.

    Best regards
    Nikolai

  • Wait for the asynchronous query SQLite?

    Is it possible to force a wait on an asynchronous request of SQLite?

    I have a situation where I am currently using an alert before the return of my result set to debugging purposes. With the alert in place, everything works perfectly. When I leave the alert - it gives me an object not defined.

    At first I thought it was just a delay introduced by the caveat, so I wrote a function of delay it implemented and tested with the same result, object not defined. I even extended the delay of 15 seconds, but he always comes back with an undefined object.

    My question is this, the alert/event handler should do anything other than the introduction of a delay in the single processing thread. Is it possible to emulate this?

    I included my code below.

    function getMsgInboxList()
    {
     var sTime = new Date();
     try
     {
      if ( ! db)
      {
       openDB();
      }
     try
      {
      db.transaction(function (tx)
      {
       tx.executeSql("SELECT * FROM InboundMessages WHERE messagetype IN (0,1,2,3,4)  ORDER BY received DESC;", [], genMsgList);
                }
             );
          }
          catch (Error)
          {
             alert("Fn Err : " + Error);
          }
       }
       catch (Err)
       {
          alert("Fn level2 Error : " + Err);
       }
    
       var eTime = new Date();
       var el = eTime - sTime;
    
    // **This is the alert that seems to control the return of data **
       alert("SQL Function genMsgboxList Elapsed : " + el);
    
       var counter1 = 0;
       do
       {
            pausecomp(100);
            counter1 += 100;
            if (counter1 >= 5000)
                {
                alert("invalid iHTML string");
                return;
                }
       }
       while(!iHTMLString);
    
       return iHTMLString;
    }
    
    function genMsgList (tx2, rs)
    {
       var starttime = new Date();
       try
       {
          var len = rs.rows.length, i;
          iHTMLString = "";
          for (i = 0; i < len; i ++ )
          {
             MSGreceived[i]      = rs.rows.item(i).received;
    
             x = new Date(MSGreceived[i]);
             rYear = x.getFullYear();
             rMonth = x.getMonth();
             rDay = x.getDate();
             rTime = x.toLocaleTimeString();
    
             rDateString = rMonth + "/" + rDay + "/" + rYear + " " + rTime;
    
             HTMLString = "
    \n" + "
    " + rDateString + "<\/div>\n" + "<\/div>\n"; iHTMLString = iHTMLString + HTMLString; } } catch (Error) { alert("Callback loop err : \n" + Error); } var counter2 = 0; do { pausecomp(100); counter2 += 100; if (counter2 >= 5000) { alert("fn2 invalid iHTML string"); return; } } while(!iHTMLString); var finishtime = new Date(); var elapsed = finishtime - starttime; //alert("Elapsed SQL callback : " + elapsed); return iHTMLString; }

    Hello

    As a test, have you tried something simple like that?

    var iHTMLString;
    global variable

    function getMsgInboxList() {}
    If (! db) {}
    openDB();
    }

    DB.transaction (function (tx) {}
    tx.executeSql ("SELECT * FROM InboundMessages WHERE messagetype IN (0,1,2,3,4) ORDER BY received DESC;', [---], CallBackHandleResult");
    (}, errorHandler, CallBackContinue);
    }

    function CallBackHandleResult (tx2, rs) {}
    for (i = 0; i<>
    iHTMLString iHTMLString = + '
    ';
    }
    }

    function CallBackContinue() {}
    Alert (iHTMLString);
    }

    Check if it works first, then add the code.

    Andrew has soon

  • How to query this performance internally

    Dear all,

    This query selects the nth highest paid employee details, we can achieve this by rank or desnse_rank functions also
    But these execution is easily understandable. But not able to understand how this below a correlated subquery Iam running in-house. Please help me on this query
    Select * from emp where & n = (select count (distinnct b.sal) of emp b where a.sal < = b.sal)

    Thanks in advance

    Hello

    To facilitate understanding, I prefer it written this way:

    select * from emp a where (select count(distinct b.sal) from emp b where a.sal<=b.sal) = &n ;
    

    It means then:
    Select the lines of the emp table for which the number of distinct lower wages is n.
    In other words => for each lines of the PGE, it counts the number of distinct treatments that are below the current line; If the number is & n, the current emp lines is displayed

  • View Blackberry Java Sqlite query result rows in the form of pages

    How can I display the rows resulting from the query sqlite one at a time in the form of question pages where a buttonfield (then) displays the next line (question) when you press. I was able to display all the rows at once with the following code:

    Statement st = null;
    try {}
    St = db.createStatement ("SELECT * FROM Questions by Qid asc");
    St.Prepare ();
    Cursor c = st.getCursor ();
    If (c == null) {}
    Dialog.Alert ("unable to retrieve from the database");
    }
    Line r;
    {while (c.Next ())}
    r = c.getRow ();

    String opt = "option" + r.getInteger (0);
    Option RadioButtonGroup = new RadioButtonGroup();
    Add (new LabelField (r.getInteger (0) + "." + r.getString (1)));
    Add (new RadioButtonField (r.getString (2), option, false));
    Add (new RadioButtonField (r.getString (3), option, false));
    Add (new RadioButtonField (r.getString (4), option, false));
    Add (new SeparatorField());
    }
    } catch (Exception e) {}
    e.printStackTrace ();
    } {Finally
    try {}
    St.Close ();
    } catch (DatabaseException e) {}
    }
    }

    But no progress with splitting into separate view. Do you know how to go about it?

    I thought the usual way to proceed would be for the SQL query to provide lines to return to the screen, and then the screen would have a loop by pushing another modal screen with the following Question.  If this player from the screen not from the query.  Who is?

  • Behavior inconsistent performance Oracle query

    Consider the following query:

    SELECT * FROM ( SELECT ARRM.*, ROWNUM FROM CRS_ARRANGEMENTS ARRM WHERE CONCAT(ARRM.NBR_ARRANGEMENT, ARRM.TYP_PRODUCT_ARRANGEMENT) > CONCAT('0000000000000000', '0000') ORDER BY ARRM.NBR_ARRANGEMENT, ARRM.TYP_PRODUCT_ARRANGEMENT, ARRM.COD_CURRENCY) WHERE ROWNUM < 1000;

    This query is performed on a table that has 10 000 000 entries. While running the query Oracle SQL Developer or my application it takes 4 minutes to run! Unfortunately, it's also the behaviour within the application I am writing. Change the value of 1000 to 10 has no impact, which suggests that he made a full table scan.

    However when the squirrel running the query returns within a few milliseconds. How is that possible? Explain plan generated in squirrel gives:

    Explain plan in SQuirreL

    But a plan different explain is generated in Oracle SQL Developer, for the same query:

    Explain plan in Oracle SQL Developer

    No idea how this difference in behavior is possible? I can't understand it. I tried with JPA and raw JDBC. In the application, I need to parse through 10 000 000 records and this query is used for pagination, so 4 minutes of waiting is not an option (which would take 27 days).

    Note: I use the same Oracle jdbc driver into a squirrel and my application so it's not the source of the problem.

    I also posted this to other web sites, for example

    http://StackOverflow.com/questions/28896564/Oracle-inconsistent-performance-behaviour-of-query

    OK - I created a test (below) case and got the same exact results you did 'test' - a FFS using SQL index * more. I then tested with SQL Developer and got the same results. You are 100 billion sure that you did not have two databases somewhere with the same name?

    SQL> create table crs_arrangements
      2  (nbr_arrangement varchar2(16) not null,
      3   product_arrangement varchar2(4) not null,
      4   cod_currency varchar2(3) not null,
      5   filler1 number,
      6  filler2 number);                                             
    
    Table created.                                                    
    
    SQL> alter table crs_arrangements add constraint crs_pk primary key
      2  (nbr_arrangement, product_arrangement, cod_currency);        
    
    Table altered.                                                    
    
    REM generate some data
    
    SQL> select count(*) from crs_arrangements;          
    
      COUNT(*)
    ----------
      10000000                                           
    
    SQL> exec dbms_stats.gather_table_stats('HR', 'CRS_ARRANGEMENTS', cascade=>true);
    
    SQL> ed
    Wrote file afiedt.buf                                                        
    
      1  explain plan for
      2  SELECT * FROM
      3    ( SELECT ARRM.*, ROWNUM FROM CRS_ARRANGEMENTS ARRM
      4      WHERE CONCAT(ARRM.NBR_ARRANGEMENT, ARRM.PRODUCT_ARRANGEMENT) > CONCAT('
    0000000000000000', '0000')
      5* ORDER BY ARRM.NBR_ARRANGEMENT, ARRM.PRODUCT_ARRANGEMENT, ARRM.COD_CURRENCY)
    WHERE ROWNUM < 1000
    SQL> /                                                                       
    
    -------------------
    | Id  | Operation                      | Name             | Rows  | Bytes | Cost
    (%CPU)| Time     |
    --------------------------------------------------------------------------------
    -------------------
    |   0 | SELECT STATEMENT               |                  |   999 | 55944 |  112
    7   (0)| 00:00:14 |
    |*  1 |  COUNT STOPKEY                 |                  |       |       |
           |          |
    |   2 |   VIEW                         |                  |  1000 | 56000 |  112
    7   (0)| 00:00:14 |
    |   3 |    COUNT                       |                  |       |       |
           |          |
    |   4 |     TABLE ACCESS BY INDEX ROWID| CRS_ARRANGEMENTS |   500K|    17M|  112
    7   (0)| 00:00:14 |
    |*  5 |      INDEX FULL SCAN           | CRS_PK           |  1000 |       |   13
    0   (0)| 00:00:02 |      
    

    However, as noted earlier in this thread:

    alter session set NLS_SORT = FRENCH;
    
    |   0 | SELECT STATEMENT        |                  |   999 | 55944 |       | 202
    85   (1)| 00:04:04 |
    |*  1 |  COUNT STOPKEY          |                  |       |       |       |
            |          |
    |   2 |   VIEW                  |                  |   500K|    26M|       | 202
    85   (1)| 00:04:04 |
    |*  3 |    SORT ORDER BY STOPKEY|                  |   500K|    17M|    24M| 202
    85   (1)| 00:04:04 |
    |   4 |     COUNT               |                  |       |       |       |
            |          |
    |*  5 |      TABLE ACCESS FULL  | CRS_ARRANGEMENTS |   500K|    17M|       | 155
    48   (1)| 00:03:07 | 
    

    Can you check your preferences of SQL Developer under database-> NLS and ensure that sorting is set to BINARY? I wonder if either he is on something else in SQL Developer or maybe your by default, the database is not BINARY and squirrel is assigning BINARY when connecting.

  • poor cardinality of bad query performance

    I have a query, whose performance is unsatisfactory.

    It produces (11.2.0.2) next track. The slowest part of the query is the functioning of the UNION-ALL on two fast full scans indexes on PRODUCTS_DATES indices. These clues are in the two tables that make up a notice, V_SALES_ALL.

    The estimation of cardinality for the full scans seems to be out - 100 lines against 78,000,000 and 1 703 000 respectively. The estimate of 100 strangely resembles a defect because the two tables are, as I said, an interior view. In fact, if I break up of the view to its constituent tables, queries run in a tenth of the time.


    How can I fix this misinformation, most likely created by the view?

    I'm reading the right trace?

    Regs

    Johnnie


    Rows Row Source operation
    ------- ---------------------------------------------------
    321 SORT GROUP BY (cr = 6759441 pr = 176970 pw = 176955 time = 480 US cost = 63 = 896 card = 14 size)
    5322875 NESTED LOOPS (cr = 6759441 pr = 176970 pw = 176955 time = 109327744-en)
    5322875 NESTED LOOPS (cr = 241360 pr = 176970 pw = 176955 time = 55796544 US cost = size 62 = 896 card = 14)
    5322875 HASH JOIN (cr = 241049 pr = 176970 pw = 176955 time = 7774711 US cost = size 48 = map 280 = 14)
    80445738 VIEW V_SALES_ALL (cr 241001 pr = 0 pw = time = 0 = 569162368 cost = US size 4 = 1800 map = 200)
    80445738 UNION-ALL (cr = 241001 pr = 0 pw = time 0 = 404890176 en)
    78742696 INDEX FAST FULL SCAN PRODUCTS_DATES_IDX (cr = 235954 pr = 0 pw = time 0 = 85524904 US cost = size 2 = 900 card = 100) (object id 221975)
    1703042 INDEX FAST FULL SCAN PRODUCTS_DATES_IDX_HARD (cr = 5047 pr = 0 pw = time 0 = 1850486 US cost = size 2 = 900 card = 100) (object id 241720)
    2238 VIEW index$ _join$ _003 (cr = 48 pr = 0 pw = time 0 = US cost = size 44 14474 = 24618 card = 2238)
    JOIN by HASH 2238 (cr = 48 pr = 0 pw = time 0 = 9737 US)
    2238 PRODUCTS_GF_INDEX2 INDEX RANGE SCAN (cr = 8 pr = 0 pw = time 0 = 2609 US cost = size 6 = 24618 card = 2238) (object id 255255)
    16206 INDEX FAST FULL SCAN PRODUCTS_GF_PK (cr = 40 pr = 0 pw = time 0 = 20415 US cost = size 45 = 24618 card = 2238) (object id 255253)
    5322875 INDEX UNIQUE SCAN DATES_PK (cr = 311 pr = 0 pw = time 0 = 0 US cost = 0 size = 0 = 1 card) (object id 151306)
    5322875 ACCESS BY ROWID DATES TABLE INDEX (cr 6518081 pr = 0 pw = time = 0 = 0 US cost = 1 size = 44 = 1 card)


    Implementation plan of lines
    ------- ---------------------------------------------------
    0 SELECT STATEMENT MODE: FIRST_ROWS
    321 TRI (GROUP BY)
    5322875-HASH JOIN
    TABLE 5322875 ACCESS MODE: ANALYZED (FULL) OF "DATES" (TABLE)
    5322875-HASH JOIN
    80445738 VIEW OF "index$ _join$ _003 ' (VIEW)
    80445738-HASH JOIN
    MODE 78742696 INDEX: SCANNED (SCAN INTERVAL) OF
    "PRODUCTS_GF_INDEX2" (INDEX)
    MODE 1703042 INDEX: ANALYZED (FULL SCAN) OF
    "PRODUCTS_GF_PK" ((UNIQUE) INDEX)
    2238 VIEW OF "V_SALES_ALL" (VIEW)
    2238 UNION-ALL
    INDEX 2238 MODE: ANALYZED (COMPLETE ANALYSIS) OF
    "PRODUCTS_DATES_IDX" (INDEX)
    HOW TO INDEX 16206: ANALYZED (COMPLETE ANALYSIS) OF
    "PRODUCTS_DATES_IDX_HARD" (INDEX)

    Johnnie d wrote:
    I have a query, whose performance is unsatisfactory.

    It produces (11.2.0.2) next track. The slowest part of the query is the functioning of the UNION-ALL on two fast full scans indexes on PRODUCTS_DATES indices. These clues are in the two tables that make up a notice, V_SALES_ALL.

    The estimation of cardinality for the full scans seems to be out - 100 lines against 78,000,000 and 1 703 000 respectively. The estimate of 100 strangely resembles a defect because the two tables are, as I said, an interior view. In fact, if I break up of the view to its constituent tables, queries run in a tenth of the time.

    Implementation plan of lines
    ------- ---------------------------------------------------
    0 SELECT STATEMENT MODE: FIRST_ROWS

    You run with optimizer_mode = first_rows_100?

    If yes then you may have found a bug in the code of first_rows_N. 100 seem to have been pushed inside the view in a way that has made Oracle to the full index full scans while only "intend" to find 100 rows in each table. There catches the limit of 100 as the actual limit in deciding which online source to use as the hash and which will serve to the probe.

    If you want the entire result set, or a large part of it, you could add the all_rows education indicator.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

  • How to use a parameter query to select and display the data in the table of the façade

    Hiiiiii

    I am using Access 2007 database
    I want to select the specific data in the database using control of the chain as 'select product, size, weight of ProductInfo where barcode (chain control) =?'  and also display the same table of façade.

    I use the connected database toolkit.
    I saw the example of the parameterized insert, but it did not help to use parameterized select query, as well as to display data of parameterized select query.

    I looked for example on parameterized select query, but I don't have any.
    So pls guide me how to do this. I would like to know the other method (if any) that the use of parameter query to perform the same thing.
    If possble pls share a vi reference.
    Thank you!!!

    HII szewczak
    Thanks for the reply
    but I did not getsolution in one of your shared links
    My problem is solved. There is no need to use the parameter query to select control values
    In my case I want to display data from database where bar code is even entered by the user
    I use the data function DB TOOL CHOOSE and create the condition of chain based on concatenation of strings

  • Performance problem with SQL for recovering data in FACT and Dimension Table

    Hello

    We have a query that performs very slow when extracting data in FACT and the DIMENSION Table.

    SQL and Plan are in the attachment.

    Please suggest how this can be improved.

    The version of DB is 11.2.0.4

    Kind regards

    VN

    Slow is a very relative term, for about 1 hour is slow for some 1s is slow. So please always quantify your settings.

    The first thing caught my eye is done 4 times ia_oasis_tot_prov_cur_d access. Try to isolate which and change it like this and see if it returns the same result.

    select case when a.clm_capitn_ia_bil_prov_edw_sk = b.prov_edw_sk then b.prov_id end ben_billing_prov
         , case when a.clm_capitn_attnd_prov_edw_sk  = b.prov_edw_sk then b.prov_id end ben_attending_prov
         , case when a.clm_capitn_ia_pcp_edw_sk      = b.prov_edw_sk then b.prov_id end ben_pcp_number
         , case when a.clm_capitn_ia_ipa_prov_edw_sk = b.prov_edw_sk then b.prov_id end ben_ipa_number
      from edw.clm_capitn_f partition (jan2015) a
      left join
           edw.ia_oasis_tot_prov_cur_d b
        on (
               a.clm_capitn_ia_bil_prov_edw_sk = b.prov_edw_sk
            or a.clm_capitn_attnd_prov_edw_sk  = b.prov_edw_sk
            or a.clm_capitn_ia_pcp_edw_sk      = b.prov_edw_sk
            or a.clm_capitn_ia_ipa_prov_edw_sk = b.prov_edw_sk
           )
    

    If it works this means allows you to reduce certain I/O.

  • Feature helps performance call (COLLECTION ITERATOR PICKLER FETCH)

    11.2.0.3

    Solaris 10

    I need assistance with our implementation of the policy of restricting access. From our plans of execution and trace files, we see our political function run when querying tables restricted. This, of course, is planned and is done in a hash against the returned results join by the query . The function fills a set IDs based on the roles that the user has and pushes those predicates against object_1.

    -------------------------------------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    -------------------------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                  |  5331 |   786K |  1358 (21) | 00:00:03:

    |*  1 |  HASH JOIN RIGHT SEMI |                  |  5331 |   786K |  1358 (21) | 00:00:03:

    |   2.   COLLECTION ITERATOR PICKLER FETCH | GET_PERMISSIONS | 16360. 32720 |    20 (10) | 01:00:00 |

    |   3.   TABLE ACCESS FULL | OBJECT_1 |   634K |    90 M |  1302 (19) | 00:00:03:

    -------------------------------------------------------------------------------------------------------

    The problem we have is with reports where the optimizer find it more effective to make an IMBRIQUEE LOOP between an object and the object of access restricted. The function is then called as as many times as the operation of nested loop runs. When a report may take a few seconds, it will be take minutes to complete because the function is called thousands of times. These reports are very long and complex but below is an example where I forced the nested loop (query takes too long without additional predicate).

    SELECT / * + USE_NL (obj1, obj2) * /.

    Ob1.ID

    Of ob1, ob2 object_2 object_1

    WHERE ob1.obj2_id = ob2.id (+) AND obj1.obj_name IN ('SOME_VALUE');

    ---------------------------------------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time     |

    ---------------------------------------------------------------------------------------------------------

    |   0 | SELECT STATEMENT |                  |  3620 |   190K |   137 (2) | 01:00:00 |

    |   1.  NESTED EXTERNAL LOOPS |                  |  3620 |   190K |   137 (2) | 01:00:00 |

    |   2.   TABLE ACCESS BY INDEX ROWID | OBJECT_1 |  3620 |   123K |   135 (1) | 00:00:01 |

    |*  3 |    INDEX SKIP SCAN | OBJECT1_FK_I |  3620 |       |    22 (0) | 01:00:00 |

    |   4.   SEE PUSHED PREDICATE. OBJECT_2 |     1.    19.     1 (0) | 01:00:00 |

    |   5.    SEMI NESTED LOOPS.                  |     1.    19.    21 (10) | 01:00:00 |

    |   6.     TABLE ACCESS BY INDEX ROWID | OBJECT_2 |     1.    17.     1 (0) | 01:00:00 |

    |*  7 |      INDEX UNIQUE SCAN | OBJECT_2_PK |     1.       |     1 (0) | 01:00:00 |

    |*  8 |     COLLECTION ITERATOR PICKLER FETCH | GET_PERMISSIONS |   137.   274.    20 (10) | 01:00:00 |

    ---------------------------------------------------------------------------------------------------------

    We have reports where the function is called more than 100 000 times and can take 12 minutes additional to complete. I'm not the developer of these reports or our policies, but I do my best to help in tune. I can force it to use hash joins, where possible, and the time of the request is excellent. There is, Unfortunately, thousands of these reports with different degrees of performance degradation because this function so that the developers are wondering if there are other alternatives. Is there a way to tell the optimizer to use of hash joins when dealing with this function? I looked at using different policy types (currently "SHARED_CONTEXT_SENSITIVE"), but neither contributed to improve performance. I've been all over the internet and have not been able to find a similar situation. I tried to be comprehensive, but I do not know I missed some vital information, then please let me know if I can explain it. Thoughts appreciated.

    Thank you.

    CREATE OR REPLACE FORCE VIEW SOME_SCHEMA. SECURITY_ID_TEMP

    (

    ID,

    CONT_CN

    )

    AS

    SELECT id, cont_cn

    TABLE (CAST (some_pkg.get_ids AS rls_array)) t;

    And this latter view is probably what is causing the problem. That's what I said in my answer:

    A possible explanation is that your political function is a predicate that uses a collection.
    . . .
    Probably the political predicate sometimes involves a small number of elements and many other times.

    And it is the predicate that you just posted:

    IF ii_user_is_exempt (some_user)

    THEN

    predicate: = NULL;

    ON THE OTHER

    predicate: = 'security_id in (select id from security_id_v);

    END IF;

    RETURN of predicate;

    The policy predicate is querying a view based on a collection. How the optimizer supposed to know how "rows" are in this collection 'rls_array' which is used as if it were a table?

    As you return a NULL predicate in some cases. I've never tested it, but I would warn against it. See the doc of security

    http://docs.Oracle.com/CD/E25054_01/network.1111/e16543/VPD.htm#CIHBEIFC

    Creating a function to generate the dynamic WHERE Clause

    To generate the dynamics WHERE clause (predicate), you must create a function (not a procedure) which defines the restrictions you want to apply. In general, the security administrator creates this function in its own schema. For a more complex behavior, such as including other functions or adding controls to track logon attempts, create these features within a package.

    The function should have the following behavior:

    • It takes as arguments a scheme name and a name of object (table, view, or synonym) as inputs. Set the input parameters to contain this information, but do not specify the schema name and object themselves within the service. The strategy that you create with the DBMS_RLS (described in "creating a policy to attach the function to the objects you want to protect") provides the namespace of the schema and object to which the policy applies. You must create the parameter for the schema first, the setting for the object.
    • It must provide a return value for the predicate in the WHERE clause that will be generated. The return value for the WHERE article is always a VARCHAR2 data type.
    • It must generate a valid WHERE clause. This code can be as simple as the example in "tutorial: creating a Simple Oracle virtual private Database Policy ', in that its WHERE clause is the same for all users who log on.

    I wonder the use of this collection as part of your policy mechanism.

    TABLE (CAST (some_pkg.get_ids AS rls_array)) t;

    First - each user has its own State of package. This means that each user has its own collection; This isn't a master collection (ID game) that is shared by all users. A real table, is where the data will be shared by all users should exist.

    Second - this function 'get_ids' (I guess this is a feature rather than a grouping variable?) may actually be to interview one or more tables every time it is called. This means that EACH query that performs a user must first call that 'get_ids' that works while it asks a few real tables to obtain information and make a collection.

    Even if a required collection to be used it must be created ONCE and then come back as needed.

    This security architecture raises some red flags for me. It's the first thing that I looked at.

    Yes, I know, any changes that might involve serious implications and require a substantial analysis, testing and implementation. But my suspicion is that where the root of the problem.

    My assumption is at this time that your collection of 'rls_array', used as a table, is the cause of the problem. Oracle does not have statistics on the result set of this "table", and of one query to another, has no way to know if the number of 'lines' changes significantly.

    Oracle could use some dynamic sampling to try to estimate things and inspiring that sampling is changing the execution plan. You could try to find a query which causes problems and to see how the number of items in collection compares the number of a normal query.

    Short of this thorough/fix analysis which I think is necessary, your best bet may be to investigate pinning on an implementation plan; forcing the use of a basic plan for this query little matter that runs it.

    If you want to study Sql Plan Management and this way opens up a new thread for this issue/question and provide a link to the current thread.

    Here is an article from Oracle to become familiar with SPM

    http://www.Oracle.com/technetwork/issue-archive/2009/09-Mar/o29spm-092092.html

    And here is sample thread "How to force Oracle to use an implementation Plan" to give you an idea of the use of the mechanism.

    https://community.Oracle.com/thread/991149?TSTART=0

    See Jonathan Lewis's response in this thread.

    There are many other threads and documentation, SPM, if you want to continue that.

  • ADF 12 c, ADF application run twice the search query

    Hi all

    I use JDeveloper 12.1.2 version and I'm working on the performance of the component of motion of the ADF.

    I notice that when you click on the button to search for a query of the ADF component, the sql query is performed 2 times (I drop a test seen as a request of the adf and a table).

    The first time you do a search from the first query has no filter. After the first search the two queries are always the same. Is this a known bug?

    How can I removed the second query not useful?

    Kind regards

    Sébastien

    This is a known bug (https://java.net/jira/browse/ADFEMG-159) and is fixed 12.1.3. The seams heading a different error, but reading the whole comments, you'll see your mistake.

    Timo

  • How to perform account on a Table hierarchical Oracle based on the Parent link

    Hello


    I have the following to Oracle 11 g R2 hierarchical table definition:


    Table Name: TECH_VALUES:
      ID,
      GROUP_ID,
      LINK_ID
      PARENT_GROUP_ID,
      TECH_TYPE

    Above the hierarchical table definition, some examples of data might look like this:


    ID      GROUP_ID      LINK_ID      PARENT_GROUP_ID      TECH_TYPE 
    ------- ------------- ------------ -------------------- --------------
    1       100           LETTER_A     0
    2       200           LETTER_B     0
    3       300           LETTER_C     0
    4       400           LETTER_A1    100                  A 
    5       500           LETTER_A2    100                  A 
    6       600           LETTER_A3    100                  A 
    7       700           LETTER_AA1   400                  B 
    8       800           LETTER_AAA1  700                  C 
    9       900           LETTER_B2    200                  B 
    10      1000          LETTER_BB5   900                  B 
    12      1200          LETTER_CC1   300                  C
    13      1300          LETTER_CC2   300                  C
    14      1400          LETTER_CC3   300                  A
    15      1500          LETTER_CCC5  1400                 A
    16      1600          LETTER_CCC6  1500                 C
    17      1700          LETTER_BBB8  900                  B
    18      1800          LETTER_B     0
    19      1900          LETTER_B2    1800                 B 
    20      2000          LETTER_BB5   1900                 B 
    21      2100          LETTER_BBB8  1900
                     B


    Keeping in mind that there are only three Types of technology, i.e. A, B and C, but could not span on different LINK_IDs , how can I do a count on these three different TECH_TYPEs based solely on the ID of parent link where the parent group id is 0 and there are children below them?

    NOTE: It is also possible to have parents in dual link ID such as LETTER_B and all values of children but different group ID.

    I'm basically after a table/report query that looks like this:

    Link ID        Tech Type A         Tech Type B          Tech Type C
    -------------- ------------------- -------------------- -------------------
    LETTER_A      
    3                   1                    1
    LETTER_B      
    0                   3                    0
    LETTER_C      
    2                   0                    3
    LETTER_B      
    0                   3                    0

    Be hierarchical and my table can consist more of 30 000 files, I must also ensure that performance to produce the report above shown here query is fast.

    Obviously, in order to produce the report above, I need to gather all necessary County outages based on TECH_TYPE for all parents of the link id where the PARENT_GROUP_ID = 0 and store it in a table according to the guidelines of this report layout.

    Hope someone can help with maybe a combined query that performs the counties as well as stores the information in a new table called LINK_COUNTS, which will be based on this report. Columns of this table will be:

    ID,

    LINK_ID,

    TECH_TYPE_A,

    TECH_TYPE_B,

    TECH_TYPE_C

    At the end of this entire requirement, I want to be able to update the LINK_COUNTS table based on the results returned by the sample data above in a SQL UPDATE transaction as the link ID parent top-level already exists within my table LINK_COUNTS, just need to provide values for breaking County for each parent node link , i.e.

    LETTER_A

    LETTER_B

    LETTER_C

    LETTER_B

    using something like:

    UPDATE link_counts

    SET (TECH_TYPE_A,TECH_TYPE_B,TECH_TYPE_C) =

       (with xyz  where link_id = LINK_COUNTS.link_id .... etc

    Which must match exactly the above table/report

    Thank you.

    Tony.

    Hi, John,.

    Thanks for posting the sample data.

    John Spencer wrote:

    ...  If you need to hide the ID column, then you could simply encapsulate another external query around me. ...

    Or simply not display the id column:

    Select link_id, -id,

    Count (case when tech_type = 'A' end then 1) tech_a.

    Count (case when tech_type = 'B' then 1 end) tech_b,.

    Count (case when tech_type = "C" then 1 end) tech_c

    of (connect_by_root select link_id link_id,)

    the connect_by_root ID, tech_type

    of sample_data

    Start with parent_group_id = 0

    connect prior group_id = parent_group_id)

    Link_id group, id

    order by link_id, id;

    Same results, using SELECT... PIVOT

    WITH got_roots AS

    (

    SELECT CONNECT_BY_ROOT link_id AS link_id

    Id CONNECT_BY_ROOT ID

    tech_type

    OF sample_data

    START WITH parent_group_id = 0

    CONNECT BY PRIOR group_id = parent_group_id

    )

    SELECT link_id, tech_a, tech_b, tech_c

    OF got_roots

    PIVOT (COUNT (*)

    FOR tech_type IN ('A' AS tech_a

    'B' AS tech_b

    'C' AS tech_c

    )

    )

    Id ORDER BY link_id

    ;

  • How do I know what sql query is taken on time for the concurrent program

    Hi Sir,

    I am running simultaneous program, which takes time to run, I want to know what sql query causing performance

    Thanaks,

    Anthony

    Hi Anthony,.

    Activate the traces on the simultaneous program and then run tkprof on trace file.

    Octavio

  • Performance SDO_DISTANCE

    Table A_SPATIAL has 15 million records with different values of longitude and latitude. I also have the SDO_GEOMETRY shape, which stores the column SDO_GEOMETRY (2001, 8307, MDSYS.) SDO_POINT_TYPE (LONGITUDE, LATITUDE, NULL), NULL, NULL).

    I created the function and the index below:

    create or replace function get_long_lat_pt(longitude in number,  
                                             latitude in number)  
    return SDO_GEOMETRY deterministic is  
    begin  
    return sdo_geometry(2001, 8307,  
                    sdo_point_type(longitude, latitude, NULL),NULL, NULL);  
    end;  
    / 
    INSERT INTO user_sdo_geom_metadata VALUES(  
    'A_SPATIAL', -- table  
    'SHAPE', -- function  
       mdsys.sdo_dim_array( 
          mdsys.sdo_dim_element('LONGITUDE', -180, 180, 0.005),  
          mdsys.sdo_dim_element('LATITUDE', -90, 90, 0.005)  
       ), 
       8307  -- SRID  
        ); 
    commit;  
    CREATE INDEX A_SPATIAL_SHAPE_IDX  
    ON A_SPATIAL(Shape)  
    INDEXTYPE IS MDSYS.SPATIAL_INDEX;  
    
    

    Then when I run the query below, it performs a full table scan. Even though I have the index above, the index get used because I use SDO_DISTANCE to wrap around her, I guess. The longitude and latitude provided to the get_long_lat_pt function below are some user input, and they all vary.

    select * from A_SPATIAL where  
    SDO_GEOM.SDO_DISTANCE(SHAPE, get_long_lat_pt(95.224, 31.601), 1, 'unit=MILE') < 20;  
    
    

    Issues related to the:

    1. What is the optimal way of running this query to perform the best? I guess the full table scan is obvious as I need to calculate the distance, but is there a way to improve the performance?

    2 is the index above or even useful at all?

    3. I use SDO_WITHIN_DISTANCE in my case, but it would run a full table in any case scan because I still need to calculate the distance. He would perform better than the example above?

    Thank you.

    The only difference in your queries (Simplified) is the max_resolution of the additional parameter, it is only applied in the other, but max_resolution = 400 is big enough?

    Don't know if it makes a difference separating the parameters with ',' I got the same result.

    'distance=400, max_resolution=400 , unit=mile') = 'TRUE';
    
    'distance=400 max_resolution=400, unit=mile') = 'TRUE';
    

    You can try to force ORACLE to use the INDEX and the execution of test plan:

    SELECT /*+ INDEX (g a_spatial_shape_idx) */
           SDO_GEOM.SDO_DISTANCE(shape, get_long_lat_pt(95.224, 31.601),0.001,'unit=mile') dist
      FROM a_spatial g
     WHERE SDO_WITHIN_DISTANCE(shape, get_long_lat_pt(95.224, 31.601),'distance=400 unit=mile') = 'TRUE'
     ORDER BY dist;
    

    If you can use the postal code instead of lat/lon for the query results, of course, create an index on the zip code, use it in the WHERE clause and test execution plan.

  • Reconstruction of the table should be performed after removal of most of its data?

    Hi all
    We are on Oracle 10.2.0.4 on Solaris 10. There is a table in my DB of production that has 872944 number of lines. Most of his data is now useless, that it must keep, based on a date column in the table just last a month of rest data and delete data. Thus, after the array will be just 3000 lines.

    However, as the table was huge earlier (872 k lines before you remove), the deletion of data releases his oracle blocks and reduced the size of the table? Otherwise, this will help in the reconstruction of the line (redefined online) table so that the query that performs a full scan on this table goes faster?

    I checked using an example of a table that simply deleting data does not remove the oracle blocks - they remain in the user_tables for this table and complete the table scan cost remains the same. I think that after this deletion, I have to do a re-definition of table online, which is the right decision so we have a query that makes the full table scan?

    Thank you

    If read you about the orders, you will find that they require a DDL lock. Your users should not notice this.

Maybe you are looking for

  • VERY slow photo - does not load

    I have constant problems with Apple TV.  I have the latest model and the software. Photos will generally display thumbnails of all the pictures, but I can't ever see when selected.  She just a spinning top trying to load them and never stops and it n

  • Laptop will not feed after update

    I woke up last night around 03:00 when the computer says that it will re-start in 16 minutes to install updates. I have advanced and closed all programs and clicked the button 'restart now '. Now, when I push the power button, the power button and a

  • Failure of T61p NVidia 570 m

    Hi all I turned on my T61p as usual last night and the status lights came on as usual but nothing showed on the screen. I then disconnected the battery, he left, reconnected it, same thing. I have reset the CMOS by unplugging the CMOS battery and let

  • Multicast in router Cisco RV325 support

    Hi team, I have a simple network with a router of 325 RV with a multicast server in one vlan (send to 224.1.1.1 on UDP 5000), and I have several receivers in one vlan, connected to the same router.  I enabled multicasting across the port and it does

  • Bar side of Smartphones blackBerry on web pages

    Is there an easier way to go up and down the web page other than the track bar?