true..there's no redo but GTT's do have undo which generates a redo and this is more of an impact in a dg environment than in a regular environment. Correct? Is there a work around for this?
Main Topics
Browse All TopicsWhat are the ramifications of using a global temp table in a Dataguard environment?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
This is the answer I just got from Oracle and they state there is no fix, but that doesn't mean there isn't one that's been found by an expert...
Even greater impact may be felt in a way that the standby database may not
be keeping up with the primary instance.
For example, when primary instance needs about 1 min to generate one 500M redo
and standby about 2 min to apply such a redo then the log archive dest on
standby machine will fill up within few hours with outstanding redo.
DIAGNOSTIC ANALYSIS:
====================
Update/delete on global temporary tables is responsible for most redo
generated (oner redo record/changed row).
It may be that the CTAS for a global temporary table also generates more
redo than the equivalent insert as select statement.
Insert as select is not so bad as it seem to generate roughly only one redo
record/tempfile block.
Hope this helps for the work around question. :)
Ah, very interesting. So you are seeing some redo from the GTT.
But the GTT is not the problem, the sheer transaction volume is the problem.
Redo volume is a product of your user population. If the current primary is servicing that volume without any delay, then there is no bottleneck there.
Standby apply speed is bottlenecked on the standby. So the question is how to speed the managed recovery on the standby.
Are you using logical or physical standby?
What sort of hardware / storage?
Any more specifics?
Recording and tracking Temperature over time is an excellent way to predict failure. Commonly component failures are associated with higher temperatures.
And I'm sure that Al Gore and the gang would be very impressed by your idea to track Global Temp, as then your data can be used to help support the global warming scenario.
I am truly impressed by your EcoScience. I don't see what would be the issue with DataGuard propagating your Global Temperature tables to the standby. It should work fine as long as you aren't using one of those silly temporary tables... certainly you have the option to not do something stupid that may contribute to global warming.
Oh, and Sun V240s are approaching End of Service Life.
http://sunsolve.sun.com/ha
Last order date was 06/06, so EOSL is June, 2011.
I run plenty of databases on V240s... the important question is what is your Disk architecture layed out like. Are you using only internal disk?
i.e. maybe it has enough "disk space" but not enough "I/O per second" to do the job. Using some sort of smart RAID array or NVM Caching array is very helpful. The V240s that I'm happy with I am running the Sun 3510 FC array (and I must admit that in this case, ,the array is twice the price of the host). The array with NVM battery backed cache can support faster synchronous writes which are helpful with keeping up with the heavy redo apply workload on a standby.
Global Temporary Tables : http://www.oracle-base.com
Not Temperature tables.
You had me laughing pretty good.
The point with GTTs is there is less redo working with them than a regular table, as they are stored in temp segments.
But the general idea here is the standby is too slow. So your points relevant.
If Oracle says there are no workarounds then:
1) Rework the application to generate less DML / redo. It could be that areas could be rewritten to optimize the SQL.
2) Find ways to speed up the managed recovery process to keep up with the redo stream. Faster hardware and more IO would be my bet.
Business Accounts
Answer for Membership
by: mrjoltcolaPosted on 2009-09-11 at 12:37:06ID: 25312787
temporary tables cause no redo, so there is no issue, that I am aware of. You don't replicate changes to a temp segment. It is the changes to a regular table that you care about.