Does Global Temporary Table help in performance?

I have a large database table that is growing daily. The application I have has a page for the past day data and another for some chosen period of time. Since I'm looking at a very large amount of data for each page (~100k rows) and having charts based on time, I have performance issues. I tried collections for each of these and found out that it is making everything slower and I think because the collection is large and it is not indexed.
Since I don't need the data to be maintained for the session and in fact for each time that I submit a page I need to get the updated data at least for the past day page, I wonder if Global Temporary Table is a good solution for me.
The only reason I want to store the data in a table is to avoid running similar queries for different charts and reports. Is this a valid reason at all?
If this is a good solution, can someone give me a hint on how to do this?
Any help is appreciated.

It all depends on how efficient your query is. You can have a billion row table and still get a fraction of a second response if the data is indexed, and the number of data blocks to be visited to retrieve the data is small. It's all about reducing the number of I/Os to find and retrieve your data with the query. Many aspects of the data, stats, table/index structure etc can influence the efficiency of your query. The SQL forum would be a better place to get into the query tuning, but if this test is fast, you can probably focus elsewhere for now. It will resolve your full resultset, and then just do a count of the result (to avoid sending 100k rows back to the client). We are trying to get an idea of how long it takes to resolve your resultset. Using litterals rather than item names in your sql should be fine for this test. Avoid using V() around item names in your SQL.
select count(*) from ( <your-query-goes-here> );

Similar Messages

  • Will Partitioning improve performance on Global Temporary Table

    Dear Guru,
    In one of complicated module I am using Global Temporary Table (GTT) for intermediate processing i.e. It will store required data in it but the rows of the data goes into 10,00,000 - 20,00,000.
    Can Partitioning or Indexing on Global Temporary Table improve the performance?
    Thanking in Advance
    Sanjeev

    Sounds like an odd use of a GTT to me, but I'm sure there are valid reasons...
    Presumably you are going to be processing all of these rows in some way? In which case I can't see how partitioning, even if it's possible (And I don't think it is) would help you.
    Indexes - sure, that might help, but again, if you are reading all/most of these rows anyway they might not help or even get used.
    Can you give a bit more detail about exactly what you are doing?
    Edited by: Carlovski on Nov 24, 2010 12:51 PM

  • Performance issue with Oracle Global Temporary table

    Hi
    Oracle version : 10.2.0.3.0 - Production
    We have an application in Java / Oracle. Users request comes in XML and oracle parser parses it and inserts it into Global temporary tables and then Business Stored procedure picks data from these GTT's and do the required processing.
    in the end data required response data is again inserted into response GTT's from which Response XML is generated.
    Question : Is the use of Global temporary tables in Oracle degrades performance as we have large number of GTT's in our application approx. 5-600 such tables.
    Regards,
    Vikas Kumar

    Hi All,
    Here is architecture of my application:
    Java application creates XML from the screen values and then inserts that XML
    into a framework(separate DB schema) table . then Java calls a Stored Procedure from same framework DB and in SP we have following steps.
    1. It fatches XML from the XML type table and inserts XML into screen specific XML TYPE table in the framework DB Schema. This table has a trigger which parses XML and then inserts XML values into GTT which are created in separate product schemas.
    2. it calls Product SP and then in product SP we have business logic. Product SP
    does the execution and then inserts response into Response GTT.
    3. Response XML is created by using XML generation function and response GTT.
    I hope u will understand my architeture this time and now let me know if GTT are good in this scenario or not. also please not that i need data in GTT only during execution and not after that. i dont want to do specific delete which i have to do if i am using normal tables.
    Regards,
    Vikas Kumar

  • Performance slow on DELETE command on global temporary table!

    Hi,
    I have a delete on a global temporary table that is taking long time!.
    Anyone have a clue about how to improve delete command's against global temporary table??
    Tks,
    Paulo Portugal

    Same problem here!
    <QUOTE>
    SELECT DISTINCT PDT_CHILD.SUP_ID, PDT_CHILD.SUB_ID,
    PDT_CHILD.SUB_LEAF_FLAG_ID
    FROM
    PJI_FP_AGGR_RBS_T PDT_CHILD WHERE 1=1 AND PDT_CHILD.SUP_ID = :B2 AND
    PDT_CHILD.SUP_ID <> PDT_CHILD.SUB_ID AND PDT_CHILD.WORKER_ID = :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 88561 20.71 20.23 0 0 0 0
    Fetch 90269 926.19 906.80 45 45164134 0 176545
    total 178831 946.91 927.03 45 45164134 0 176545
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 173 (APPS) (recursive depth: 1)
    Rows Execution Plan
    0 SELECT STATEMENT MODE: ALL_ROWS
    0 HASH (UNIQUE)
    0 TABLE ACCESS (FULL) OF 'PJI_FP_AGGR_RBS_T' (TABLE (TEMP))
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    latch: row cache objects 1 0.00 0.00
    direct path write temp 3 0.00 0.00
    direct path read temp 3 0.00 0.00
    </QUOTE>
    The fetch is too high for TEMP table... Any help would be much appreciated!
    Note: Please teach me on how we can format the above in my future posts in OTN forums.
    ===

  • HELP global temporary table ----URGENT

    HI ALL,
    create global temporary table FLIGHT_SCHEDULE ( STARTDATE DATE, ENDDATE DATE, COST NUMBER ) on commit preserve rows;
    I a not able to get return value in cursor
    but if this table is normal i.e. not temprary then it is returnng cursor
    ORA-24338 statment handel not exucuted error comming
    Please help
    Regards

    The code you posted looks alright.
    Perhaps you did not post the code with the problem?

  • Need help with global temporary table

    Can anyone please help, the following line of code :
    CREATE GLOBAL TEMPORARY TABLE tbl_bulknodes_temp ( obt_uuid VARCHAR2 ) ON COMMIT DELETE ROWS
    Yeilds the following error both in PL/SQL and running it in SQL PLUS
    Error starting at line 1 in command:
    CREATE GLOBAL TEMPORARY TABLE tbl_bulknodes_temp ( obt_uuid VARCHAR2 ) ON COMMIT DELETE ROWS
    Error report:
    SQL Error: ORA-00906: missing left parenthesis

    Hi,
    You have to put length to varchar2 column...
    SQL> CREATE GLOBAL TEMPORARY TABLE tbl_bulknodes_temp ( obt_uuid VARCHAR2(30) ) ON COMMIT DELETE ROWS;
    Table created
    SQL> CREATE GLOBAL TEMPORARY TABLE tbl_bulknodes_temp2 ( obt_uuid VARCHAR2 ) ON COMMIT DELETE ROWS;
    CREATE GLOBAL TEMPORARY TABLE tbl_bulknodes_temp2 ( obt_uuid VARCHAR2 ) ON COMMIT DELETE ROWS
    ORA-00906: missing left parenthesis
    SQL> Regards,

  • Use of global temporary tables in Procedures

    Hi
    I am using global temporary tables in the procedures. Loading data in the same table through many procedures. I am fetching the data from the global temporary table in PRO-C by a cursor. Will this degrade performance?
    Please help me..
    Thanks in Advance...

    Will this degrade performance?That depends... in comparison to what?
    Loading data into temporary tables will generally be more efficient than loading data into permanent tables because Oracle needs to do less to protect this data since it is inherently transient. On the other hand, loading the data into a table in the first place tends to be more expensive than alternatives like using a single SQL statement, a pipelined table function, or an in memory collection.
    Justin

  • Life time of data in a Global Temporary Table.

    Dear Friends,
    I have a global temporary table in which I insert some values via a backend package, when forms start up and accessing it via the same package when user performs some changes in it - storing the value and during exit saving it in the master table. My problem is the data is not accessible while processing. I'm using Oracle9i Enterprise Edition Release 9.2.0.1.0 database and Forms [32 Bit] Version 6.0.8.8.0. I also give you the script in using which I created the temporary table.
    CREATE GLOBAL TEMPORARY TABLE GTT_PRA
    A1 VARCHAR2(10 BYTE) NOT NULL,
    A2 VARCHAR2(15 BYTE) NOT NULL,
    A3 VARCHAR2(10 BYTE) NOT NULL
    ON COMMIT DELETE ROWS;
    Why is that so? Please help me.
    With Regards,
    Senthil .A. Perumal.

    Dear Arun,
    Thank you for your script. But I'm accessing a large table, so for each and every process, the table get populated and grows very large giving some space problem, that is why I'm deleting rows when commiting. I would appreciate your help.
    Dear Yogesh,
    From the same forms I'm calling the backend package - will that be a different session. Once I'm calling to populate the table and next time I'm calling to store the user modified data and finally calling to store the data to master table. I think all are in the same sessions. Please reply me.
    Thank you dear friends fr your immediate response. I would really appreciate it.
    Regards,
    Senthil .A. Perumal.

  • How we cn avoid the sequence in remote tables through global temporary tabl

    Hi,
    We have table xx_interface_qualifiers in the remote db and we are inserting the data like this and its on a loop
    INSERT INTO xx_interface_qua
    (interface_id,
    list_line_interface_id, excluder_flag,
    qualifier_context, qualifier_attribute,
    qualifier_attr_value, qualifier_precedence,
    comparison_operator_code, start_date_active,
    end_date_active, list_header_name, list_line_no,
    creation_date, created_by, last_update_date,
    last_updated_by, interface_attribute1
    VALUES (xx_interface_qua_s.NEXTVAL,
    ttt, 'Y',
    xxx, xxx2,
    xxx3, xxx4,
    '=', SYSDATE,
    NULL, xxx4, -1,
    SYSDATE, '-1', SYSDATE,
    '-1', 44 );
    We are trying to avoid the hitting of the database every time for a sequence and try to implement the global temporary tables,i mean to say 1st we need to insert the data to TEMP table and then from temp table we cn inseert all the data to xx_interface_qual in a single shot to improve the performance.
    But how we cn avoid the sequence in this case as we do not know the sequence in remote side.
    Please suggest any other way to improve the performance.
    Regards
    Das

    797846 wrote:
    We have table xx_interface_qualifiers in the remote db and we are inserting the data like this and its on a loop
    We are trying to avoid the hitting of the database every time for a sequence and try to implement the global temporary tables,i mean to say 1st we need to insert the data to TEMP table and then from temp table we cn inseert all the data to xx_interface_qual in a single shot to improve the performance.
    But how we cn avoid the sequence in this case as we do not know the sequence in remote side.Does not make sense. I/O is the slowest database operation.
    You have an unknown performance problem (that you claim is due to a sequence, but failed to provide any evidence for). Now you want to create more I/O, by writing the data twice. Once into a temp table and then again into the destination table. And do that in order to increase performance?
    I do not see how this can solve the underlying, and unknown, performance issue that you claim exists.
    Any problem solution needs to start with correctly and comprehensively identifying the problem.
    You cannot solve a problem without first knowing WHAT the problem is.

  • Direct Path Loading Issues with Global Temporary Tables - OCI & OCILib

    I am writing some code to import data into a warehouse from a CPU grid which computes risk data. Due to the fact a computing grid is used there will be many clients which can load the data concurrently and at any point in time.
    Currently the import uses Binding in OCCI and chunking with a prepared statement to import the data into a global temporary table in a staging area after which a stored procedure is called within the same session which will process the data and load the data into a star schema.
    The GTT has the advantage that if any clients have issues no dirty data will be left and each client only sees their own instance of the data.
    I have been looking at using direct path loading to increase the performance of the load and have written some OCI code to perform the same task. I have manged to import the data into a regular heap based table using the OCI direct path apis. However when I try and use the same code to import against a Global Temporary Table I get an OCI Error (ORA-00600: internal error code, arguments: [6979], [16], [1], [1318528], [], [], [], [], [], [], [], [])
    I get error when the function OCIDirPathPrepare is executed. The same issue occurs in both OCI and OCILib.
    Is it not possible to use Direct Path Loading against a Global Temporry Table ? Because you can use the /*+ APPEND */ hint and load global temporary tables this way from tools like SQL Devloper / toad which is surely informing the SQL Engine to use Direct Path ?
    Looking at the table USER_OBJECTS I can see that for a Global Temporary Table the DATA_OBJECT_ID is null. Does this mean that it is impossible to us a direct path load into Global Temporary Tables ?
    Any ideas / suggestions would be really appreciated. If this means redesigning the application then I would appreciate suggestions which would allow many client to quick write processes in a parallel fashion. If this means creating a new parition in a Heap Table for each writer and direct path loading into this table then so be it.
    Thanks
    H
    Edited by: 813640 on 19-Nov-2010 11:08

    Replying to my own message in case anyone else is interested.
    I have now managed to successfully load data using direct path into a global temporary table with OCI. There appears to be no reason why this approach will not work.
    I loaded data into the temporary table and then issued a select count(*) on the table from within the session and from a new session. The results were as expected.
    The resaon for the ORA-006000 error was due to the fact that I had enabled table level parallel loading
    ie
    OCIAttrSet((dvoid *) context, (ub4) OCI_HTYPE_DIRPATH_CTX, *(ub1) 1*, (ub4)0, (ub4) OCI_ATTR_DIRPATH_PARALLEL, errhp)
    When loading a Global Temporary Table the OCI_ATTR_DIRPATH_PARALLEL attribute needs to be zero
    This makes sense, since the temp table does not have any partitions so it would not be possible to write in parallel to multiple paritions.
    Edited by: 813640 on 22-Nov-2010 08:42

  • Create view for Global Temporary Table

    if view is create for global temporary table so exactly how it works which helps regarding application performance.
    Regaards,
    Sambit Ray

    A view is just a stored query. It can be on global temporary tables or regular one, makes no difference.

  • Scalability issue with global temporary table.

    Hi All,
    Does create global temporary table would lock data disctionary like create table? if yes would not it be a scalable issue with multi user environment?
    Thanks and Regards,
    Rudra

    Billy  Verreynne  wrote:
    acadet wrote:
    am I correct in interpreting your response that we should be using GTT's in favour of bulk operations and collections and in memory operations? No. I said collections cannot scale. This means due to the fact that collections reside in expensive PGA memory, you cannot stuff large data volumes into them. Thus they do not make an ideal storage bin for temporary data (e.g. data loaded from file or a web service). GTTs otoh do not suffer from the same restrictions, can be indexed and offer vastly better scalability and so on.
    Multiple passes are often needed using such a data structure. Or filtering to find specific data. As a GTT is a SQL native, it offers a lot more flexibility and performance in this regard.
    And this makes sense - as where do we put out persistent data? Also in tables, but ones of a persistent and not temporary kind like a GTT.
    Collections are pretty useful - but limited in size and capability.
    Rudra states:
    I want to pull out few metrices from differnt tables and processing itIf this can't be achieved in a SQL statement, unless Rudra is a master of understatement then I would see GTT's as a waste of IO and programming effort. I agree.
    My comments however were about choices for a temporary data storage bin in PL/SQL.I agree with your general comments regarding temporary storage bins in Oracle, but to say that collections don't scale is putting to narrow a definition on scaling. True, collections can be resource intensive in terms of memory and CPU requirements, but their persistence will generally be much shorter than other types of temporary storage. Given the right characteristics, collections will scale and given the wrong characteristics GTT's wont scale.
    As you say it is all about choice. Getting back to the theme of this thread though, the original poster should be made aware that well designed and well coded applications are most likely to scale. Creating tables on the fly is generally considered bad practice and letting the database do what it does best, join tables in queries at the SQL level is considered good practice. The rest lies somewhere in between and knowing when to do which is why we get paid the big bucks (not). ;-)
    Regards
    Andre

  • Using Global Temporary Table in OBIEE 11

    Hi,
    THe requirement is to run a database function before the report runs. This Function accepts 5 parameters (Presentation Variable) and populates a GTT Global Temporary Table.
    This GTT is configured in presentation Layer.
    Issue:
    1. Created a dummy report which returns only one row and called the fucntion using "Evaluate" in this.
    2. Created 2nd report using GTT Columns.
    All these 2 reports placed on dashboard and Presentation variable are set in the prompt. The first one runs correctly and populate the "Regular Table". Means when I create a regular table instead of GTT I can see the correct record. But if I change it to GTT then the data does not get populated in this table.
    Any Inputs?
    Regards

    HI,
    If you are using a GTT, you need to run the function which populates the GTT before OBI server executes the select query on that table.
    In your case, the OBI server is executing the select query from the table before the data is populated in the table.
    In order to force the BI server to run the query after the GTT is populated, you need to specify the condition in the connection pool settings under the connection scripts tab.
    In the execute before query, enter your physical query which runs the function to populate the GTT.
    Hope this helps !
    Thanks,
    Vineeth

  • When to use global temporary tables?

    which are the probable situations when one can think of using global temporary tables?

    In my experience, most often GTTs are used by developers from other RDBMSs who have become used to needing 'intermediate tables' created on the fly to hold data while they 'loop and commit to free locks'.
    These developer may not have had enough exposure to Oracle's concurrency model and therefore use the 'other' concurrency model as the basis for an application port - usually followed up by a call to the forum for assistance in performance tuning. <g>
    That said, legitimate uses for GTTs include staging or scrubbing table for data transport or preparation, eg: ETL into a warehouse, when the intermediate data is
    a) reproducible (therefore does not need to be logged); and
    b) the results of the intermediate operation, but not the source, are stored in permanent tables.
    Some developers also use GTTs to hold the equivalent to a 'temporary materialized view' specifically for complex reporting purposes.

  • Insert slow into Global Temporary Table...

    I am working with a stored procedure that does a select into a global temporary table and it is really slow. I have read up on the append hint and know that it is not a solution since GTT's are in the temporary table space which are thus always appended and never have logs.
    Is there something else that I need to know about performance for GTT? I find it hard to believe that Oracle would find it acceptable to take 50 seconds to insert 3300 rows.

    My apologies in advance as my skill level with Oracle is not as high as I would like for this type of analysis and remediation.
    I had thought of it being the select as well but if I run it by itself it takes about 1 second. The interesting part is when I explain plan on it with the Insert, the SQL plan changes.
    Here is the Non-insert explain plan:
    <code class="jive-code jive-java">
    Plan hash value: 3474166068
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 51 | 8 (38)| 00:00:01 |
    | 1 | HASH GROUP BY | | 1 | 51 | 8 (38)| 00:00:01 |
    | 2 | VIEW | VM_NWVW_1 | 1 | 51 | 7 (29)| 00:00:01 |
    | 3 | HASH UNIQUE | | 1 | 115 | 7 (29)| 00:00:01 |
    | 4 | NESTED LOOPS | | | | | |
    | 5 | NESTED LOOPS | | 1 | 115 | 6 (17)| 00:00:01 |
    | 6 | NESTED LOOPS | | 1 | 82 | 5 (20)| 00:00:01 |
    | 7 | SORT UNIQUE | | 1 | 23 | 2 (0)| 00:00:01 |
    | 8 | TABLE ACCESS BY INDEX ROWID| PEAKSPEAKDAYSEG$METERMASTER | 1 | 23 | 2 (0)| 00:00:01 |
    |* 9 | INDEX RANGE SCAN | IDX_PDSEG$MTR_SEGID | 1 | | 1 (0)| 00:00:01 |
    |* 10 | TABLE ACCESS BY INDEX ROWID | FC_FFMTR_DAILY | 1 | 59 | 2 (0)| 00:00:01 |
    |* 11 | INDEX RANGE SCAN | FC_FFMTRDLY_IDX10 | 2461 | | 2 (0)| 00:00:01 |
    |* 12 | INDEX UNIQUE SCAN | FC_METER_PK | 1 | | 0 (0)| 00:00:01 |
    | 13 | TABLE ACCESS BY INDEX ROWID | FC_METER | 1 | 33 | 1 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    9 - access("SM"."SEGID"=584)
    10 - filter(TO_DATE(TO_CHAR("V"."MEASUREMENT_DAY"),'YYYYMMDD')>=TO_DATE(' 2002-01-01 00:00:00',
    'syyyy-mm-dd hh24:mi:ss') AND TO_DATE(TO_CHAR("V"."MEASUREMENT_DAY"),'YYYYMMDD')<TO_DATE(' 2003-01-01
    00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND ("V"."ADJUSTED_TOTAL_VOLUME"<>0.0 OR
    ROUND("V"."ADJUSTED_TOTAL_ENERGY",3)<>0.0))
    11 - access("V"."METER_NUMBER"="SM"."METER_ID")
    12 - access("M"."METER_NUMBER"="V"."METER_NUMBER")
    </code>
    Here is the Insert explain plan:
    <code class="jive-code jive-java">
    Plan hash value: 4282493455
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | INSERT STATEMENT | | 39 | 2886 | | 7810 (1)| 00:01:34 |
    | 1 | LOAD TABLE CONVENTIONAL | PEAKDAY_TEMP_CONSECUTIVEVALUES | | | | | |
    | 2 | HASH GROUP BY | | 39 | 2886 | | 7810 (1)| 00:01:34 |
    |* 3 | HASH JOIN RIGHT SEMI | | 39 | 2886 | | 7809 (1)| 00:01:34 |
    | 4 | VIEW | VW_NSO_1 | 1 | 10 | | 2 (0)| 00:00:01 |
    | 5 | NESTED LOOPS | | 1 | 27 | | 2 (0)| 00:00:01 |
    |* 6 | INDEX UNIQUE SCAN | PK_PEAKSPEAKDAYSEG | 1 | 4 | | 0 (0)| 00:00:01 |
    | 7 | TABLE ACCESS BY INDEX ROWID | PEAKSPEAKDAYSEG$METERMASTER | 1 | 23 | | 2 (0)| 00:00:01 |
    |* 8 | INDEX RANGE SCAN | IDX_PDSEG$MTR_SEGID | 1 | | | 1 (0)| 00:00:01 |
    | 9 | VIEW | PEAKS_RP_PEAKDAYMETER | 3894 | 243K| | 7807 (1)| 00:01:34 |
    | 10 | SORT UNIQUE | | 3894 | 349K| 448K| 7807 (1)| 00:01:34 |
    | 11 | NESTED LOOPS | | | | | | |
    | 12 | NESTED LOOPS | | 3894 | 349K| | 7722 (1)| 00:01:33 |
    | 13 | TABLE ACCESS FULL | FC_METER | 637 | 21021 | | 18 (0)| 00:00:01 |
    |* 14 | INDEX RANGE SCAN | FC_FFMTRDLY_IDX11 | 6 | | | 10 (0)| 00:00:01 |
    |* 15 | TABLE ACCESS BY INDEX ROWID| FC_FFMTR_DAILY | 6 | 354 | | 12 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    3 - access("METER_ID"="METER_ID")
    6 - access("GS"."SEGID"=584)
    8 - access("SM"."SEGID"=584)
    14 - access("M"."METER_NUMBER"="V"."METER_NUMBER")
    filter(TO_DATE(TO_CHAR("V"."MEASUREMENT_DAY"),'YYYYMMDD')>=TO_DATE(' 2002-01-01 00:00:00', 'syyyy-mm-dd
    hh24:mi:ss') AND TO_DATE(TO_CHAR("V"."MEASUREMENT_DAY"),'YYYYMMDD')<TO_DATE(' 2003-01-01 00:00:00', 'syyyy-mm-dd
    hh24:mi:ss'))
    15 - filter("V"."ADJUSTED_TOTAL_VOLUME"<>0.0 OR ROUND("V"."ADJUSTED_TOTAL_ENERGY",3)<>0.0)
    </code>
    As you can see there is a real spike in the cost and yet the only thing that was done was the addition of the Insert to GTT. From what I can ascertain the solution may be in an alternate SQL or finding some way to push Oracle into running the query as it would have for the first execution (non-insert).
    I tried creating a simple view out of the SELECT statement to see if that would precompile it but in the end it ran exactly the same way.
    The next thing that I am going to try is removing the PEAKS_RP_PEAKDAYMETER view by going more direct.
    I have not done the trace file analysis yet. Should I still do that?

Maybe you are looking for