Comments on: Oracle Exadata V2 – Flash Cache

By: osborne

osborne — Sat, 26 Nov 2011 00:26:20 +0000

Thanks Robin.

By: Robin Moffatt

Robin Moffatt — Fri, 25 Nov 2011 20:18:06 +0000

Hi Kerry,

The whitepaper has moved : http://www.oracle.com/technetwork/database/exadata/exadata-smart-flash-cache-366203.pdf

One day Oracle will learn how to implement redirects when they move their website content around ….

By: osborne

osborne — Sun, 23 Oct 2011 18:33:45 +0000

Yes – set processing generally wins over 1 row at a time processing regardless of the platform, but with Exadata the difference can be magnified.

Kerry

By: JoeG

JoeG — Fri, 21 Oct 2011 05:02:34 +0000

I meant to say if we do a insert into table1 select * from table2 the process runs much faster than processing 1 row at a time from Informatica load.

By: JoeG

JoeG — Fri, 21 Oct 2011 05:00:40 +0000

I think we ran into an issue with Informatica processing 1 row at a time. Insert into table1 form table2 it completes successfully in about 1 hour time for 12.5 million rows. When i add parallel dml and do it in parallel it completes in about 6 minutes. Without looking I am making an assumption the Information server slowed down due to high memory usage.

By: osborne

osborne — Mon, 17 Oct 2011 23:14:08 +0000

Hi Joe,

I’m not sure what you’re asking here. Are you just curious why the table sizes don’t match?

Kerry

By: osborne

osborne — Mon, 17 Oct 2011 23:13:03 +0000

Hi Joe,

I’m not sure what the problem you’re trying to solve is. Are you trying to make you’re insert go faster? If so, sharing a little more info like the statement will be helpful. Also why you you are working this issue (is it slower than on another platform or than other similar inserts)?

Kerry

By: JoeG

JoeG — Mon, 17 Oct 2011 16:42:29 +0000

We are on exadata 11gr2, version BP 10. Load table is truncated prior to single row inserts, insert into table1(col1…col262) values(v1…..v262);

The table we are loading from has same number of columns and process is done by informatica with ~10000 row commit frequency. There are 4 indexes on the target table. Also the target table uses more blocks, from dba_segments, than the target. Both have same storage parameters.

Any advice on what to look at would be appreciated.

Thanks,
Joe

By: JoeG

JoeG — Mon, 17 Oct 2011 16:06:04 +0000

Kerry, we are having a issue with a table with 262 columns. From what I have read having a table over 255 columns causes performance issues. Is there a way to determine if that is what is happening? I am currently tracing a session and we have lots of “cell single block physical read” wait events. Its an INSERT statement with following stats:

call count cpu elapsed disk query current rows
——- —— ——– ———- ———- ———- ———- ———-
Parse 0 0.00 0.00 0 0 0 0
Execute 439 602.53 1399.50 1329033 54696 136314235 43900
Fetch 0 0.00 0.00 0 0 0 0
——- —— ——– ———- ———- ———- ———- ———-
total 439 602.53 1399.50 1329033 54696 136314235 43900

By: osborne

osborne — Sat, 12 Feb 2011 01:26:55 +0000

John,

I’m not sure what the concerns about redundancy would be. Exadata systems are generally set up with diskgroups using normal or high redundancy (2 or 3 way mirroring). The failure groups are usually set up so that each storage cell represents a separate failure group. So if you choose high redundancy you should be able to loose two storage cells without loosing any data. If your co-workers don’t trust the software supplied redundancy provided by ASM that is another issue.

I would definitely want to do some testing to prove to myself that putting the log files on flash disks really gave me the performance improvement I was hoping for, as the results of my (admittedly limited) experiments in that area have been somewhat mixed. The downside of persueing this approach is that any flash that you use as disk decreases the amount available for caching data. Not as big a deal if you can get most of it into the SGA, but nevertheless, it’s something to consider.

It sounds like a very interesting system. Good luck. I’d be very interested in hearing more as your evaluation/testing proceeds.

Kerry