Tables stored in memory but may be accessed from other sessions

Question

Dear Oracle experts,
it may be a stupid question but I'm searching for the best possibility to create a kind of temporary table which may be accessed from other sessions.
Could you provide some hints/ catchwords to speed up my recherches.
Thank you very much,
Daniel

Answer 1

danielwetzler wrote:
danielwetzler wrote:
I fear that the caching is not suitable for my case because of the reasons decribed in my other postings...First of all I don't think that you need to worry about the effectiveness of the caching in your particular case. In addition Oracle is very clever at when to actually write the dirty blocks from the buffer cache to the disks, so if your amount of data written to the result table is fairly small and no other activity is going on your system it won't get written to disk immediately anyway but stay in memory until any of the conditions are met that trigger the database writer to flush the blocks to disk.
But there are options you could consider if you want to avoid as much of the overhead as possible and to write the results of your calculation to the result table as fast as possible.
You could use direct-path inserts (INSERT /*+ APPEND */) and set the result table to "NOLOGGING". This way no undo and minimum redo is generated.
Note however that there are certain caveats and restrictions to consider when using such an approach, e.g. your result table won't be recoverable (which you say is OK), only one direct-path insert is allowed simultaneously (it blocks the table exclusively, no other DML possible until you commit/rollback the transaction), and the direct-path insert has some restrictions. If any of these apply that prevent the direct-path operation then it silently falls back to "conventional" insert mode which generates undo and redo. One of the more annoying restrictions is that you can't read from a table that has been written to in direct-path mode within the same transaction, you first have to commit the transaction, otherwise you get "ORA-12838: cannot read/modify an object after modifying it in parallel". This means by simply adding the APPEND hint you might break existing logic.
Finally the direct-path insert never re-uses free space in blocks below the current high-water mark, which means if you perform a direct-path insert and afterwards delete rows from the table and repeat again a direct-path insert operation your segment will grow and the empty space in the already used blocks won't get re-used. Best way would be to truncate the table rather than deleting rows from it.
There are workarounds available to overcome some of these direct-path insert limitations (exclusive lock, truncate instead of delete etc.), like using a partitioned table (if you have a suitable edition/license), because direct-path inserts can be restricted to partitions. In this case you can do simultaneous direct-path inserts if you use different partitions, but you need then some kind of logic that determines which partition to use.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/