That is actually a good question. We mirror the contents of our logical management unit (a disk group) and do not mirror between disk groups. If we supported a RAID 0+1 (with BCL) style approach between disk groups then I would put a hot-mirror-side disk group on the sweet sectors and a cold-mirror-side disk group closer to the spindles and only read the cold-mirror-side in the event of a failure. But, we don’t do that. Instead, we do a quasi-RAID 1+0 **within** the disk group. As such we consume sweet disk for both the primary and secondary extents. In the event of a loss, I’d say our current approach is better because the application will continue to be serviced with I/O from sweet sectors. On the other hand, if there is never a loss we are consuming sweet disk for naught. It is a trade-off.

The other problem with a RAID 0+1 (hot-to-cold) striped-then-mirrored approach is suffered by OLTP workloads because with the typical read/write ratio of OLTP we’d be wildly flailing between the sweet and sour sectors to satisfy the writes. Remember, we are not a one pony show.

Why use the outer part of the disk for everything? I.e., why not use the slower part for mirroring?

Thanks,

CAM

So using the outer 60% of the drives for mirrored user space comes in at roughly 1TB with the SAS option. I think marketing is trying to keep the capacities to nice, simple numbers like 1TB when possible. The remaining space is, of course, usable for colder data, mirrored or un-mirrored.

The math is quite similar for the SATA option.

LGRs production database size was cited, but only a partition (e.g., 1 day of CDRs or some such) was loaded into the Exadata (”half”-rack) system. The queries used partition elimination on both the PROD and the Exadata side so the query touches precisely the same data on both.

Let me try to reflect this back to you.

A. The figures of 1 TB and 3.3 TB respectively for the 12 x 300 MB and 12 x 1 TB disk options understate the case in at least one regard. Namely, they are based on a recommendation that only the outer 60% of the disk be used, EVEN FOR MIRRORING. Thus, it is possible to increase capacity 1.6X over the quoted amounts, albeit at some unspecified performance penalty.

B. The 220 TB figure for the LGR telecommunications database is not relevant for imputing any kind of compression metric, because the whole 220 TB of user data never were loaded onto — and probably wouldn’t have fit onto — the test system.

Do I have it right?

Thanks,

CAM

Eek, first off I have to apologize. I had wires crossed between Beta1 and Beta2 specifically the host hardware for Exadata Storage Server. So, while we did only ship them 6 Exadata cells (as opposed to the 7 of a true half rack) in the Beta2 program, we did not ship them Proliant DL185 hardware as that was the Beta1 platform. Sorry. Having said that, customers should be glad that the platform is the DL180 G5 because it is significantly more capable of handling Exadata Storage Server Software as a workload.

While LDR was not my account, I should add that 6 SAS Exadata Cells actually have room for just under 10TB of mirrored space for user data (using the entirety of each platter). We recommend folks use the short-stroke regions of the platters (e.g., the outer 60%), but they can fill in more if they need/want to. That still wouldn’t accomodate the entirety of LGRs 220TB production dataset of course.

The metrics differed between accounts, but in each measurement we are apples-apples. Allow me to explain. If, for instance, LGR were to transport only a partition of a table from their 220TB production side to a 6-Cell Exadata environment and run the query that only accesses that partition on both systems they do indeed access precisely the same content and amount of data.

So was LDR Telecom really putting 220 TB of user data on 6 Exadata Storage Servers, each of which accomodates 3.3 TB of uncompressed data? Or is there some kind of apples/oranges issue with those figures?