Time of the value of a prepared statement and the differences in execution plan

Hi guys... I have a doubt here that I was not able to specify the search on the internet.

Is on prepared statements...

When I do: con.prepareStatement (query);

then the query is compiled and an execution plan is for this query on the database, I know. But what happens when I do con.close. Is the accessible yet statement caching other executions? to make this example:

Suppose we are joining 20 tables and we have about 10 parameters for this query

public ArrayList getData(String id1, String id2, String id 10) {       ArrayList response=new ArrayList();       Connection con=manager.getConnection();       String query="select name, phone, debtvalue, currency, etc from table1, table2, table3, table4, table20 where                           table1.id=table2.t1id and table2.id=table3.id and table2.fid=? and table1.fid=? and etc etc";//a big query       PreparedStatement pst=con.prepareStatement("select");       pst.setString (1, id1);       pst.setString (2, id2);       pst.setString (3, id3);       .       .       pst.setString (10, id10);       ResultSet rs=pst.executeQuery();       while (rs.next()) {               //do whatever and build the response ArrayList       }       rs.close();       pst.close();       return response; }

Will be the compilation of the prepared statement and this execution plan is available for every performance of the getData method. Or a new plan of compilation and execution is calculated whenever I execute the method? Assuming that the running query takes a long time to maturity it its complexity and runs about 100 times a day in a production environment. It is advisable to use the prepared statement?

Is the precompiled stuff avaible if I use a "" "NEW" "" said PreparedStatement with the same query?

Thank you very much in advance for your answers...

Published by: user4789473 on 25-mar-2013 17:14

If you lose / close the statement prepared, Yes, you lose the ID. If you prepare again the same
SQL, the DBMS must analyze the SQL code again, if to see if there is a query plan
still/already existing for the DBMS session. According to the DBMS, it may or may not
find/have/use plan, he created for the previous statement.

Tags: Oracle

Similar Questions

  • Help! Window 2008 server R2 and R2 2012 window server time synchronize the difference

    Hello Sir/Madam,

    Help! I have a pair of window Server 2008 R2 and a pair of window Server R2 2012, who are the synchronization of time to one destination.

    After that time synchronization is successful, the window Server 2008 R2 clocks are still 1 second faster than those in the 2012 window servers.

    Is there anyone who got the same problem as me?

    Thank you.

    Kind regards
    Samuel

    Please post your query to:

    https://social.technet.Microsoft.com/forums/

    Server issues are better addressed there.

  • time of the request

    Hello

    I know it seems a little absurd, but is there some way through which we can find as a matter of how long will take to run, I have a script that tells me how much percentage of query execution had happened, but I want... If there is anyway some way through which we can find the time to be considered for a query to run?
    Any help from you guys would be really appreciated.

    Thank you
    Aurélie

    AjinkyaSH wrote:

    I know it sounds a bit absurd,

    Why do you think that? As this should also explain why it is difficult to answer such a question... and why Oracle didn't estimate ready and available for us to use.

    Look at the following example. Exact same query.

    SQL> set timing on
    SQL> select count(*) from all_objects;
    
      COUNT(*)
    ----------
         79687
    
    Elapsed: 00:00:05.41
    SQL> select count(*) from all_objects;
    
      COUNT(*)
    ----------
         79687
    
    Elapsed: 00:00:01.64
    

    5.5 seconds against 1.6 seconds... And nothing about the modified query. Same query. Same results. To the difference in execution time caused by a query making of costly physical i/o (PIO) and the other making cheaper/o logic (LIO).

    How do you determine the duration of the front execution when something like PIO against LIO can make such a huge difference?

  • steps to optimize the query on explain plan

    Hello

    Please find the described explain the plan of a query, and suggest me where and how can grant us the request.

    {code}

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

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

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

    |   0 | SELECT STATEMENT |                             |   352K |    60 M |       | 17677 (12) | 00:03:33 |

    |   1.  TRANSFORMATION OF THE TEMPORARY TABLE.                             |       |       |       |            |          |

    |   2.   LOAD SELECT ACE | SYS_TEMP_0FD9FCB72_F58FAD20 |       |       |       |            |          |

    |   3.    VIEW                         |                             |    22G |  3684G |       |    96 M (100) | 320:57:19 |

    |   4.     UNIQUE FATE |                             |    22G |  4837G |   436G |    96 M (1) | 320:57:19 |

    |   5.      CONCATENATION.                             |       |       |       |            |          |

    |*  6 |       HASH JOIN |                             |  1792M |   392G |       | 52682 (26) | 00:10:33 |

    |   7.        VIEW                     | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    |*  8 |         MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    |*  9 |        HASH JOIN |                             |  1792M |   372G |  9320K | 43943 (16) | 00:08:48 |

    |  10.         VIEW                    | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  11.          MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 12 |         EXTERNAL RIGHT HASH JOIN |                             |   676K |   128 M |    19 M | 29255 (1) | 00:05:52 |

    |  13.          VIEW                   | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 14 |           TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 15 |          HASH JOIN |                             |   195K |    34 M |  9240K | 24001 (1) | 00:04:49 |

    |  16.           VIEW                  | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  17.            MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | * 18.           OUTER HASH JOIN |                             |   114K |    17 M |    12 M | 21748 (1) | 00:04:21 |

    | * 19.            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  20.            VIEW                 | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 21.             TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 22.       HASH JOIN |                             |    89 M |    19G |       | 46498 (16) | 00:09:18 |

    |  23.        VIEW                     | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 24.         MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 25.        HASH JOIN |                             |    89 M |    18G |  9320K | 43943 (16) | 00:08:48 |

    |  26.         VIEW                    | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  27.          MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 28.         EXTERNAL RIGHT HASH JOIN |                             |   676K |   128 M |    19 M | 29255 (1) | 00:05:52 |

    |  29.          VIEW                   | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 30 |           TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 31.          HASH JOIN |                             |   195K |    34 M |  9240K | 24001 (1) | 00:04:49 |

    |  32.           VIEW                  | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  33.            MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | * 34 |           OUTER HASH JOIN |                             |   114K |    17 M |    12 M | 21748 (1) | 00:04:21 |

    | * 35 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  36.            VIEW                 | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 37 |             TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 38 |       HASH JOIN |                             |  4480K |  1004M |       | 46189 (15) | 00:09:15 |

    |  39.        VIEW                     | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 40 |         MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 41.        HASH JOIN |                             |  4480K |   952 M |  9320K | 43943 (16) | 00:08:48 |

    |  42.         VIEW                    | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  43.          MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 44 |         EXTERNAL RIGHT HASH JOIN |                             |   676K |   128 M |    19 M | 29255 (1) | 00:05:52 |

    |  45.          VIEW                   | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 46 |           TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 47 |          HASH JOIN |                             |   195K |    34 M |  9240K | 24001 (1) | 00:04:49 |

    |  48.           VIEW                  | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  49.            MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | * 50 |           OUTER HASH JOIN |                             |   114K |    17 M |    12 M | 21748 (1) | 00:04:21 |

    | * 51 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  52.            VIEW                 | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 53 |             TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 54 |       OUTER HASH JOIN |                             |   224KO |    50 M |    14 M | 32597 (4) | 00:06:32 |

    | * 55 |        HASH JOIN |                             | 64775 |    13 M |  7696K | 28458 (5) | 00:05:42 |

    | * 56 |         OUTER HASH JOIN |                             | 37855.  7245K |  5416K | 26763 (5) | 00:05:22 |

    | * 57 |          HASH JOIN |                             | 37675 |  4966K |       |  6436 (18) | 00:01:18 |

    |  58.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 59 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 60 |           HASH JOIN |                             | 37675 |  4525K |  9320K |  4206 (27) | 00:00:51 |

    |  61.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  62.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 63.            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  64.          VIEW                   | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 65 |           TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    |  66.         VIEW                    | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  67.          MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  68.        VIEW                     | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 69 |         TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 70 |       OUTER HASH JOIN |                             | 11201 |  2570K |       | 23267 (6) | 00:04:40 |

    | * 71 |        HASH JOIN |                             |  3239 |   702K |       | 20816 (6) | 00:04:10 |

    | * 72 |         OUTER HASH JOIN |                             |  1893 |   362K |       | 19942 (7) | 00:04:00 |

    | * 73 |          HASH JOIN |                             |  1884 |   248K |       |  6435 (18) | 00:01:18 |

    | * 74 |           HASH JOIN |                             |  1884 |   226K |  9320K |  4206 (27) | 00:00:51 |

    |  75.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  76.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 77 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  78.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 79 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    |  80.          VIEW                   | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 81 |           TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    |  82.         VIEW                    | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  53 M |          MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  84.        VIEW                     | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 85 |         TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 86 |       OUTER HASH JOIN |                             |   560.   128K |       | 23267 (6) | 00:04:40 |

    | * 87.        HASH JOIN |                             |   162. 35964 |       | 20816 (6) | 00:04:10 |

    | * 88.         OUTER HASH JOIN |                             |    95. 18620 |       | 19942 (7) | 00:04:00 |

    | * 89 |          HASH JOIN |                             |    94. 12690 |       |  6435 (18) | 00:01:18 |

    | * 90 |           HASH JOIN |                             |    94. 11562 |  9320K |  4206 (27) | 00:00:51 |

    |  91.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    |  92.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 93 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    |  94.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 95 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    |  96.          VIEW                   | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 97 |           TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    |  98.         VIEW                    | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    |  99.          MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 100.        VIEW                     | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 101 |         TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 102 |       OUTER HASH JOIN |                             |    28.  6580.       | 23267 (6) | 00:04:40 |

    | * 103 |        HASH JOIN |                             |     8.  1776 |       | 20816 (6) | 00:04:10 |

    | * 104 |         OUTER HASH JOIN |                             |     5.   980.       | 19942 (7) | 00:04:00 |

    | * 105 |          HASH JOIN |                             |     5.   675.       |  6435 (18) | 00:01:18 |

    | * 106 |           HASH JOIN |                             |     5.   615 |  9320K |  4206 (27) | 00:00:51 |

    | 107.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 108.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 109 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    | 110.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 111 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | 112.          VIEW                   | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 113 |           TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | 114.         VIEW                    | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 115.          MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 116.        VIEW                     | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 117 |         TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 118 |       OUTER HASH JOIN |                             |     1.   235.       | 23267 (6) | 00:04:40 |

    | * 119 |        OUTER HASH JOIN |                             |     1.   174.       |  9760 (12) | 00:01:58 |

    | * 120 |         HASH JOIN |                             |     1.   161.       |  7309 (16) | 00:01:28 |

    | * 121 |          HASH JOIN |                             |     1.   135.       |  6435 (18) | 00:01:18 |

    | * 122 |           HASH JOIN |                             |     1.   123 |  9320K |  4206 (27) | 00:00:51 |

    | 123 |            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 124.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 125 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    | 126.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 127 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | 128.          VIEW                   | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 129.           MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 130.         VIEW                    | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 131 |          TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | 132.        VIEW                     | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 133 |         TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 134 |       OUTER HASH JOIN |                             |     1.   235.       | 23267 (6) | 00:04:40 |

    | * 135 |        OUTER HASH JOIN |                             |     1.   174.       |  9760 (12) | 00:01:58 |

    | * 136 |         HASH JOIN |                             |     1.   161.       |  7309 (16) | 00:01:28 |

    | * 137 |          HASH JOIN |                             |     1.   135.       |  6435 (18) | 00:01:18 |

    | * 138 |           HASH JOIN |                             |     1.   123 |  9320K |  4206 (27) | 00:00:51 |

    | 139.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 140.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 141 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    | 142.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 143 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | 144.          VIEW                   | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 145.           MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 146.         VIEW                    | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 147 |          TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | 148.        VIEW                     | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 149 |         TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 150 |       OUTER HASH JOIN |                             |     1.   235.       | 23267 (6) | 00:04:40 |

    | * 151 |        OUTER HASH JOIN |                             |     1.   174.       |  9760 (12) | 00:01:58 |

    | * 152 |         HASH JOIN |                             |     1.   161.       |  7309 (16) | 00:01:28 |

    | * 153 |          HASH JOIN |                             |     1.   135.       |  6435 (18) | 00:01:18 |

    | * 154 |           HASH JOIN |                             |     1.   123 |  9320K |  4206 (27) | 00:00:51 |

    | 155.            VIEW                 | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 156.             MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 157 |            MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    | 158.           VIEW                  | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 159 |            MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | 160.          VIEW                   | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 161.           MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 162.         VIEW                    | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 163 |          TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | 164.        VIEW                     | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 165 |         TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 166 |       OUTER HASH JOIN |                             |     1.   235.       | 37689 (26) | 00:07:33 |

    | * 167 |        HASH JOIN |                             |     1.   222.       | 35237 (28) | 00:07:03 |

    | * 168 |         HASH JOIN |                             |     1.   210 |       | 33008 (29) | 00:06:37 |

    | * 169 |          HASH JOIN |                             |  9781.  1776K |       | 22622 (1) | 00:04:32 |

    | * 170 |           FILTER |                             |       |       |       |            |          |

    | * 171 |            OUTER HASH JOIN |                             |  5716 |   893K |    12 M | 21748 (1) | 00:04:21 |

    | * 172 |             MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1085 (2) | 00:00:14 |

    | 173.             VIEW                | ABC_CDE_INDEX_AST_VW |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | * 174 |              TABLE ACCESS FULL | ABC_CDE_INDEX_AST |  1898K |   110 M |       | 13499 (1) | 00:02:42 |

    | 175.           VIEW                  | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 176.            MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | * 177 |          VIEW                   | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 178.           MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 179.         VIEW                    | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 180 |          MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | 181.        VIEW                     | ABC_CDE_INDEX_CHG_VW |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | * 182 |         TABLE ACCESS FULL | ABC_CDE_INDEX_CHG |   818K |    10 M |       |  2448 (1) | 00:00:30 |

    | 183.   LOAD SELECT ACE | SYS_TEMP_0FD9FCB73_F58FAD20 |       |       |       |            |          |

    | 184.    VIEW                         |                             |   145K |    18 M |       |   187 M (1) | 625:08:34 |

    | 185.     UNIQUE FATE |                             |   145K |    22 M |  1215G |   187 M (1) | 625:08:34 |

    | * 186 |      HASH JOIN |                             |  7487M |  1122G |       |   274K (98) | 00:54:59 |

    | 187.       VIEW                      | STAG_MASTER_VW | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 188 |        MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 |   468K |       |  2229 (1) | 00:00:27 |

    | * 189 |       HASH JOIN |                             |  7487M |  1039G |  9320K |   245K (98) | 00:49:06 |

    | 190.        VIEW                     | STAG_MANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | 191.         MAT_VIEW FULL ACCESS | STAG_AANAME_MV |   264K |  6208K |       |   974 (1) | 00:00:12 |

    | * 192 |        HASH JOIN |                             |   248K |    29 M |  9240K |  2995 (1) | 00:00:36 |

    | 193.         VIEW                    | STAG_NAMADDS_VW |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | 194.          MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV |   248K |  6316K |       |   872 (1) | 00:00:11 |

    | * 195 |         MAT_VIEW FULL ACCESS | STAG_ANAME_MV |   113K |    10 M |       |  1075 (1) | 00:00:13 |

    | 196.   UNIQUE FATE |                             |   352K |    60 M |    72 M | 17677 (12) | 00:03:33 |

    | 197.    UNION-ALL |                             |       |       |       |            |          |

    | * 198 |     VIEW                        |                             |   352K |    60 M |       |  1883 (1) | 00:00:23 |

    | 199.      TABLE ACCESS FULL | SYS_TEMP_1234_5678 |   352K |    60 M |       |  1883 (1) | 00:00:23 |

    | * 200 |     FILTER |                             |       |       |       |            |          |

    | * 201 |      OUTER HASH JOIN |                             |     1.   150.       |  1982 (1) | 00:00:24 |

    | * 202 |       HASH JOIN |                             |     1.   142.       |    97 (2) | 00:00:02 |

    | 203.        VIEW                     |                             | 11540 | 92320 |       |    48 (0) | 00:00:01 |

    | 204.         TABLE ACCESS FULL | SYS_TEMP_3456_0987F0 | 11540 |  1 510 K |       |    48 (0) | 00:00:01 |

    | 205.        VIEW                     |                             | 11540 |  1 510 K |       |    48 (0) | 00:00:01 |

    | 206.         TABLE ACCESS FULL | SYS_TEMP_0987F0_3456 | 11540 |  1 510 K |       |    48 (0) | 00:00:01 |

    | 207.       VIEW                      |                             |   352K |  2757K |       |  1883 (1) | 00:00:23 |

    | 208.        TABLE ACCESS FULL | SYS_TEMP_09kjhn0_3456 |   352K |    60 M |       |  1883 (1) | 00:00:23 |

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

    {code}

    Thank you.

    Well, that was just a guess because you don't want to share the query, nor execution plan with actual cardinalities. The goal is probably to avoid the separate.

  • From the differences in speed application with net on and outside

    I have a new custom molding machine which is very fast. I run Win 7 Home Premium installed on a 240 GB Samsung SSD EVO 840. My processor is a

    Intel 3570 K and data are stored on a 1 TB western digital drive.
    My initial response on all programs - no matter the size of loading was almost instantaneous.
    I have inadvertently done something that now affects the loading time. The difference is that I'm on the net or not. My connection is a modem ADSL DLink router.
    If I'm on the net, the programs loading instantly. If I'm not connected to the net, I now experience a delay in the loading of 15 seconds, regardless of the program that I start.
    I'd like suggestions on what could cause this strange behavior and how can I eliminate it. In my view, that the key must be in the delay almost uniform of 15 seconds, which suggests a matter of systems.
    Thank you

    Mrs. Kumar

    Thanks for your suggestions. They put me on the right track and are appreciated.

    My problem seems to have nothing to do with my Windows 7 operating system. Everywhere, it seems to work correctly.

    I have isolated the program causing trouble, but don't have still no cure.

    I run Avast on my virus protection and have for years. I think that the program is the best on the internet. In the latest version, however, it seems to be a problem in their web shield. In their forum, I see that some people report similar problems with Windows 8.

    I'll talk to Avast and look for a solution. In the meantime, figure out where the problem allows me to design workarounds. I have no problem if I:

    1. stay connected to the net.

    2. unconnect on the net, but do not forget to disconnect the cable from my PC.

    3 unconnect and disable Avast web shields

    When I find the specific cause and cure, I will post the solution on the off chance that someone else has a similar problem.

  • What is the correct procedure of DMBS_XPLAN for the query execution plan

    Hello.

    We are on Oracle 11.2.0.3 on Linux. I am dev. DBA and we have about 80 developers Java development team. They want to question the execution plan of queries to resolve the sqls. Generally, they use the GUI tools like the toad to see execution plan. I always use the procedure for the following query execution plan:

    
    

    Select * from
    Table (dbms_xplan.display_cursor (null, null, 'allstats + cost'));

    I should suggest that they use this too rather than rely on tools like the toad - because they can show estimated plan and not the actual plan. And to provide a sql, it is best to use the real plan to work with. Do not take account of 'allstats + cost' part in the command above, but my point is: should I ask them of still rely on sqlplus and not the GUI tools and use the command display_cursor package DBMS_XPLAN?

    I will be grateful for suggestions.

    OrauserN

    You must use the DBMS_XPLAN package and functionality.

    The tool used to run the package doesn't matter. A raw request to DISPLAY_CURSOR will run the same server code in any tool including Toad.

    If you rely on other GUI features (for example a "explain plan" button or similar) then you know what this feature of actuall application running under-the-covers.

    My suggestion would be to assess and consider using Oracle free sql developer version 4 because it is not only FREE but also uses the DBMS_XPLAN correctly.

    http://www.Oracle.com/technetwork/developer-tools/SQL-Developer/downloads/index.html?ssSourceSiteId=ocomen

  • What is the Differenc between classical planning and EPMA

    Hi all

    What is the difference between classical planning and EPMA in terms of functionality. If we choose the EPMA, what are the additional benefits that we will get more classic?

    Please explain in detail medium.

    In what scenarios, we will for the classic planning and of EPMA (we do not use financial management. Only, planning, Essbase and EN)

    Please suggest me. We use the 9.3.1. Customer wants to leverage Hyperion in the future.

    Thanks in advance.

    Kind regards
    Konrad.

    EPMA is really just an improved graphical interface for managing metadata, applications and data synchronizations.

    It is not the most stable piece of software in the 9.3.1 and my preference would be to conventional planning.

    See you soon

    John
    http://John-Goodwin.blogspot.com/

  • Need help: not prepared statement to return the value:

    Hi refugees,

    In LICS, prepared statement does not return any value...

    This is the code...

    String p_person_id = pageContext.getParameter ("person_id");

    Connection Conn = pageContext.getApplicationModule (webBean) .getOADBTransaction () .getJdbcConnection ();

    String payment_query = "select max (payment_date) in the xxbdf_payslip_detail_mv where assingment_id = (select assignment_id from the people_reporting_info where person_id ' + p_person_id + ') ';

    PreparedStaement stmt = stmt.executeQuery ();

    ResultSet rs = stmt.executeQuery ();

    While ((rs! = null) & & RS.) Next

    {

    java.sql.Date sql_date = rs.getDate (1);

    SOP (SQL_DATE)

    / * I tried this also * /.

    java.util.Date util_date = rs.getDate (1);

    SOP();

    String string_date = rs.getString (1);

    SOP();

    }

    and I have to format the date as "DD-MM-RRRR.

    Please give your valuable suggestions refugees...

    Thank you

    Jaya

    Jaya Hey,

    Write the code below in the PR

    Code for the prepared statement


    String PaymentData;

    String p_person_id = pageContext.getParameter ("person_id");

    System.out.println ("The person Id is" + p_person_id); check the id of the person should not be null.

    try {}

    Connection Conn = pageContext.getApplicationModule (webBean) .getOADBTransaction () .getJdbcConnection ();

    String query = "select max (payment_date) in the xxbdf_payslip_detail_mv where assingment_id = (select assignment_id from the people_reporting_info where person_id ' + p_person_id + '); '

    PreparedStatement stmt = conn.prepareStatement (Query);

    ResultSet = stmt. ExecuteQuery();

    While (resultset.next ())

    {

    PaymentData = (String) resultset.getString("payment_date").toString ();

    }

    Conn.Commit ();

    }

    catch (System.Exception e)

    {

    e.printStackTrace ();

    }

    See below the Code for the Date Format Conversion


    cabu.ui.validate.Formatter formatter = new OADateValidater (PaymentData, "dd-MMM-YY" "");

    Thank you

    Dilip

  • Table query result using prepared as a parameter in the prepared statement later

    Hi all

    Very new to PHP. A series of 3 prepared statements (see code below), I'm trying to sink.  This page is triggered from a link on a page that lists the individual and all candidates which works well.  Prepared statement 1 works and displays the data in the columns line wanted specific, bottom access so I would call it record and areas, but I think it is called line and columns here.  Prepared Statement 2 which hands on a table of cross references (we have a many-to-many relationship between candidates and positions, therefore for the table of cross references) works and I can say the $selected_positions charges table, because I can see position_id data in the < body > of the file using this:

    <? PHP

    foreach ($selected_positions as $item) {}

    echo $item. "< br / > ';

    }

    ? >

    Can't take this $selected_positions table and use it as parameter in the prepared statement 3, at least not how I try to do.  So obviously he manages not prepared statement 3 no way is a table that I called $the_positions which is supposed to contain the ID of the post, position of securities and to position the position_id numbers that are in the array $selected_positions.  I can say that 3 of prepared statement is a failure because there is no indication in this table that is in the < body > of the file:

    < table class = "stripes table" >

    < b >

    Identification of the Position < /th > < th >

    < /Th > < th > post number

    Title < th > < /th >

    < /tr >

    <? PHP while ($stmt-> fetch()) {? >}

    < b >

    < td > <? = $position_id;? > < table >

    < td > <? = $position_number;? > < table >

    < td > <? = $title;? > < table >

    < /tr >

    <? PHP}? >

    < /table >

    Here is the PHP script:

    <? PHP

    require_once '... /includes/session_timeout_db.php';

    ? >

    <? PHP

    require_once '... /includes/Connection.php';

    initialize the flag

    $OK = false;

    $conn = dbConnect ('read');

    initialize statement

    $stmt = $conn-> stmt_init();

    If (isset($_GET['candidate_id'])) {}

    $sql = ' SELECT candidate_id, last_name, first_name, society, mas_number, last_modified, notes

    CANDIDATES WHERE candidate_id =?'; }

    If ($stmt-> {prepared ($sql))}

    bind the query parameter

    $stmt-> bind_param ('i', $_GET ['candidate_id']);

    run the query and fetch the result

    $OK = $stmt-> execute();

    bind the results to variables

    $stmt-> bind_result ($candidate_id, $last_name, $first_name, $company, $mas_number, $last_modified, $notes);

    $stmt-> fetch();

    free resources for the second query database

    $stmt-> free_result();

    }

    get the associated positions candidate

    $sql = 'SELECT position_id FROM pos2cands WHERE candidate_id =?';

    If ($stmt-> {prepared ($sql))}

    bind the query parameter

    $stmt-> bind_param ('i', $_GET ['candidate_id']);

    run the query and fetch the result

    $OK = $stmt-> execute();

    $stmt-> bind_result ($position_id);

    Browse the results to store in a table

    $selected_positions = [];

    While ($stmt-> fetch() {)}

    [] $selected_positions = $position_id;

    }

    }

    find data on the position of the table

    $sql = ' SELECT position_id, position_number, title

    FROM place WHERE position_id =?';

    If ($stmt-> {prepared ($sql))}

    bind the query parameter

    $stmt-> bind_param ('i', $_GET [$position_id]);

    run the query and fetch the result

    $OK = $stmt-> execute();

    bind the results to variables

    $stmt-> bind_result ($position_id, $position_number, $title);

    Browse the results to store in a table

    $the_positions = [];

    While ($stmt-> fetch() {)}

    [] $the_positions = $position_id;

    }

    }

    Get the error message if the request fails

    If (isset ($stmt) & &! $OK) {}

    $error = $stmt-> error;

    }

    If (! $stmt) {}

    $error = $conn-> error;

    } else {}

    $numRows = $stmt-> num_rows;

    }

    ? >

    Thank you in advancel

    You want to use the value of request 1 or query2 as a parameter in the query 3, right? Rather than build a table, you can simply use the value returned by each line that the query returns. I use PDO, no MySQLi, so I can't knock out quickly the MySQLi example for you.

    While ($result = $sql-> fetch (PDP::FETCH_ASSOC)) {}
    $field = $result ['domain'];

    Now we can use the value of $field as parameter for the next query.

    The brace that closes the while loop is placed after the last query

    so no need to fill an array with values

    }

    Your approach is doable with a few changes to the way in which you go through the table, but it is unnecessarily complicated.

    You might be able to use a single query to get all the data if you use left joins. With this approach, you start with the table that SHOULD return a result or which requires no dependencies to other tables. The structure is like this:

    SELECT field1, Field2, field3 FROM (SELECT * FROM table1 WHERE field3 = param1) has

    LEFT JOIN (SELECT * FROM table2 WHERE A.field4 = table2.field4) B

    LEFT JOIN table3 ON table3.field5 = B.field5 ORDER BY Field1

    A and B above are aliases for subsets of the table. You can image a (tacit) sign = equal A

  • Take the time between two values

    Hi people,

    I have a problem and I know idea how to solve... I need help.

    The problem is I want to take the time between two values max as you can see in the chart.

    For example, in the image that I have add

    4.5 - 1 840 = 2.66

    And enter this value in the 'time between mostra '.

    It's that I want...

    But what I think is very complicated, because I don't know how to take the time correctly and does remove...

    Thank you very much

    Any solution?

    Hi jocuma,

    I tried something and hope that helps u.

    Just create two arrays of temperature and voltage. First of all, I'll get the value of the voltage when it is more of a certain value and that same index to get the value of time and store in the shift register.

    When I get the second higher than the limit value, I'll get time and subtract the previous value.

  • How to use time with the State in MODE Lab machine

    Hello

    I tried to use the state machine with function elapsed time so sequentially, start and stop my code. The arrangement is to start the code for 1 minute then stop for 5 minutes. I have attached the code, the problem is when I place the function elapsed time, exit the while loop it does not, on the other hand when I place it inside the loop it does not work, but it does not give the right signal to move to the next State.

    Could you please take a look at my code and help me solve this problem.

    Concerning

    Rajab

    Rajab84 wrote:

    APOK thanks for your help

    even with the support on start it continues to turn on the case of waiting

    could you please explain the code for me, the use of the Boolean crossing, increment and equality of functions

    Best regards

    Rajab

    Ok.. I have modded the example to stop after 2 cycles. Also recommend that you take the free online tutorials of LabVIEW.

    1. run the vi. case statement goes to 'initialize', shift registers are initialized to their constants. GoTo 'wait '.
    2. "start" = false, stay in the current state. If true, switch to the "1 min" case
    3. "Reset timer set off with True of the shift register (counter starts at zero). time elapsed "= false, stay in the current state (1 min). If true, goto "5 min" case
    4. "Reset timer set off with True of the shift from the previous case register (counter starts at zero). time elapsed "= false, stay in the current state (5 min). If true, goto "1 min" case. Also, bool crossing is the search for "true-false" function compares '5 min' to add the number of cycle.
    5. Once the number of cycles reaches 2, stop all loop...
  • Must have an e-mail virus, my Outlook send at least 10 people on my contact list a unsolicited to email that I got relative to earn money in your spare time in the United States.

    Must have an e-mail virus, my Outlook send at least 10 people on my contact list a unsolicited to email that I got relative to earn money in your spare time in the United States. How do is stop what's happening, I have anti virus and anti spyware programs but this is not enough!
    original title: e-mail viruses?

    The part that you do not know how?

  • What is the difference btw: block.item and $item.block.item.value in State of form customization


    Hello

    What is the difference btw: block.item and $item.block.item.value in the customization of the form State section

    I've seen this condition as

    triggering event

    the point at which instance

    : PRESS RELEASE. PICKING_RULE not in the ('US_CB_1', 'US_CC_1', 'US_CA_1', 'US_CU_1')

    and

    When the point instacne

    ${item.release.picking_rule.value} not in ('US_CB_1', 'US_CC_1', 'US_CA_1', 'US_CU_1')

    the two are the same or different

    Thanks in advance

    In the particular example that you use, no difference, you are getting the value and comparing it with a set of values.

    The second form of the syntax, however, take into account what follows, while the first only retrieves the value of the field:

    Conditions can refer to properties of objects using a SPEL (simplest Possible Expression Language) syntax. For example, allows you to create a Condition that tests whether a field is displayed or not. These expressions take the following general form:

    ${objectType.objectName.Property}

    Internally, the expression of SPEL is a cover for Oracle Forms builtins like GET_ITEM_PROPERTY, GET_BLOCK_PROPERTY, etc. In addition, expressions of SPEL are supported recovery values of profile, the dictionary of text messages and local Variables (described later).

  • Popup LOV selected the value not in session state

    I have a pop LOV element on a page in my application.  Once the item has been selected in the list presented, I would like to use as part of a select statement.  Select statement failed.  It turns out that the value I want the popup THAT LOV is not being saved in session state, so of course the select statement fails.  I determine this by clicking on the session menu item in the developer bar - the item itself presents itself, but the value is empty.

    What would cause a popup LOV value choice not finish by in session state, and how do I make sure he gets there?

    Thank you!

    If you need the value in a SQL report, you can just set "Elements of Page to submit" in your report to your LOV element definition. Otherwise, create a dynamic fire action when your LOV is changed with a set of pl/sql null process action; then set Page elements to send to your LOV element.

    Alternatively you could do it manually with your own function/Manager javascript using the '$s' Apex API by creating a dynamic action that JavaScript is triggered then the loading of the page:

    $("#PXX_YOUR_LOV").on('change',function(){
      var getValue=$(this).val();
      $s('PXX_YOUR_LOV', getValue);
      });
    

    Changing the value in LOV only updates the HTML code, the element must be submitted to the server so that the value that will be put in session state. The gurus can explain more, but the above methods are what I use depending on the situation.

    see you soon,

    John

  • don't forget the select result of a statement to be used several times in the procedure

    Hi all

    I'm sorry for this kind of question, I'm not newbie, but still need your help.

    My need is remember the select result of a statement to be used several times in the procedure.

    My first guess is to use a temporary table, but I think there's better decisions.

    For example, I should make a heavy request

    Select the code from table_function (param1)

    Then, this query is used to insert a list of the id in table1, delete table2 and update in table 3.

    Help me please do not use if possible temporary tables.

    If there is more than one column, you need to create an object type at the database level. Create a collection of this type of object in the procedure.

    Example:

    CREATE OR REPLACE TYPE "OBJ1" as OBJECT(
            column1 varchar2(256 CHAR),
            column2 varchar2(35 CHAR)
            );
    
    CREATE OR REPLACE TYPE "nt_obj1" as table of OBJ1; -- this could be done at procedure level as well
    
    DECLARE
       t_employee_ids   nt_obj1;
    BEGIN
       SELECT OBJ1(column1,column2)
         BULK COLLECT INTO  t_employee_ids
         FROM table1
        WHERE column3 = NNN
    .............
    .....
    

Maybe you are looking for