Need Advise on Global Temporary tables or Materialized views or Views

Need advise on a plsql procedure working on.
I had 6 tables having 200,000 rows in total intially,but will get added a maximum 20,000 rows daily by a batch process.
I am writing a plsql code that takes an input ,for example customer_id, and is required to get all the data for that customer_id and
had to do some complex calculation that includes stepwise validations before giving the output.Now while doing the logic it has the get the data for that customer_id from all the tables.
There may be 100 records for that particular customer_id.
I need advise on the below options.
1.Use of global temporary tables get those 100 records and do the calculation part on that Global Temporary table.
2.Use of Views or Materialized views.
3.Using the Record Structures(like table types for those records) and then do the logic on them
As Performance is the key point here i would like pull all the data at once into memory and then do the calculations instead of hitting the database many times, this is my main idea(correct me if am wrong).Also please advise if there are any other options
I am using ORACLE 10G.
Thanks
Rede

The approach that many advocate for here (including myself) is to do as much in SQL as possible. So, copying to GTTs or using record structures is probably not the solution you should be after.
If you can provide the following details we may be able to steer you down the right path
1. Oracle version (SELECT * FROM V$VERSION)
2. Sample data in the form of CREATE / INSERT statements.
3. Expected output
4. Explanation of expected output (A.K.A. "business logic")
5. Use \ tags for #2 and #3. See FAQ (Link on top right side) for details.
Ideally try and re-create the problem, simplifying it as much as possible, without losing context. Use #1-#5 above as a base for posting your simplified problem here. Then we may be able to give you a solution specific to your problem.

Similar Messages

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,

Global Temporary Tables in active data guard.

HI Gurus,
Please help me with below query. Google confusing me a lot.
1) We have an ADG (RAC Setup) 11gr2 with ASM. Is it possible to create global temporary tables in ADG. Because Devlopers are not able to create temp tables. Its giving error as
ORA-16000: database open for read-only access
2) Do we need to create Global Temporary tables in Active node or passive node??
Please help.
Regards,
Nikhil Mehta.

Hi Meser,
thanks for your response.
We are using it for Reporting purpose only.
SQL> select open_mode from v$database;
OPEN_MODE
READ ONLY WITH APPLY
Regards,
Nikhil Mehta.

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.

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

How can i create a Global Temporary Table inside a Stored Procedure....

Hi...
I need to create a Global Temporary Table inside a Stored
Procedure....
I have no idea how to do that....
Please....if u can send me a sample, send to me....
Thanks a lot

To create a global temporary table inside a stored procedure,
the minimal syntax would be:
CREATE OR REPLACE PROCEDURE procedure_name
AS
BEGIN
EXECUTE IMMEDIATE 'CREATE GLOBAL TEMPORARY TABLE table_name'
|| '(column_name NUMBER)';
END procedure_name;
As Todd stated, it would probably be better to create the global
temporary table outside of the procedure:
SQL> CREATE GLOBAL TEMPORARY TABLE table_name
2 (column_name NUMBER);
Table created.
You can also specify things like ON COMMIT PRESERVE ROWS or ON
COMMIT DELETE ROWS.
It may be that there is something else, like a PL/SQL table of
records or a cursor, that would suit your needs better. It is
difficult to guess without knowing what you want to do with it.

Transaction with Global Temporary Table

Problem:
Transaction starts with few DML statements and in the middle we are calling a JAVA method which creates the dynamic global temporary table and proceeding with few DML statements, if one of the statement fails, in the exception clause we are trying to rollback and transactions after the DDL (create global temp table) are rolled back and transactions before the DDL (create global temp table) are committed.
We cannot pre-create the global temporary table, since we do not know the number of temp table to be pre-created.
How we can resolve this issue? The same concept works for SQL server.
Example of our issue:
--drop table table1 purge;
--drop table t_id purge;
Create table table1 (col1 number, col2 varchar2(20));
Insert into table1 values (1, 'Test1');
Create global temporary table t_id (id number);
Insert into table1 values (2, 'Test2');
Rollback;
After the rollback you can see only the 'Test1' record.

> We cannot pre-create the global temporary table, since we do not know the number of temp table to be pre-created.
I don't see how one procedure could need to create an unknown number of temporary tables. Do they all have different (and unknown) column lists? Couldn't you combine them into a single table with a key to distinguish betweeen the different sets of rows?

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> );

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

Global temporary table in a store procedure

Hi,
I REALLY need to create a global temporary table in a stored procedure but I don't know how .........
My solution was
create or replace procedure test(
as
begin
execute immediate 'create global temporary table t(x number,..) ;';
end;
but the table is not created. What I am doing wrong and how to resolve the problem?
Thanks.

There is NO valid reason to create a GTT on the fly (except during installation of a package). This defeats the entire logic behind it. Precreate it and use it by a million users at the same time and it won't care. For more information On GTT's see.
http://download-west.oracle.com/docs/cd/A87860_01/doc/appdev.817/a76939/adg03sch.htm#7807

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

Best to use in terms of tuning Global Temporary table or PLSQL Table type

Hi All,
which one is best to use in terms of tuning Global Temporary table or PLSQL table type?
Thanks in Advance.
Regards
Deepika

user8828028 wrote:
which one is best to use in terms of tuning Global Temporary table or PLSQL table type?The answer to which one is better depends on the requirements - and an informed decision as to which one to use to address those requirements.
Thus it is important to understand how these work. They are nothing alike.
PL/SQL collections reside in the PGA. Can only be used in SQL via binding. Cannot be indexed. Temp tables on the other hand does not use expensive PGA. Does not need to be bind in SQL. Can be indexed. Etc.
Sure, a (surgical) saw and scalpel are both used on the operating table - but for very different 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?

Need Advise on Global Temporary tables or Materialized views or Views

Similar Messages

Maybe you are looking for