You are perfectly right in a technical frameset, but my point is that chosing on a technical basis is NOT the right method to go. Separate systems with different technologies make sense from a business perspective.

About #7, I’ve seen to many CEOs thinking that, if the technology is the same as the ERP, BI is something operational and not strategic.
In other words, placing the DW together with the OLTP disqualifies the DW and make harder to get resources and visibility.

I totally agree with you that it’s not a matter of deciding if it’s better having one or two data models (I prefer two for all reasons enumerated above), but if it’s factible to have both models in the same box.
Actually, we have a simmilar dilemma at another level when designing disk assignment to OLTP and DW servers from the same HP EVA cabin: it’s supposed that data distribution along disk and virtual arrays are dynamically assigned by cabin intelligence according to usage patterns, so as to optimize throughput.
I imagine that Oracle suggests to bubble up this philosophy to the server node level.
In the case of Exadata it could be easier as architecture should be totally balanced from CPU, memory to HBAs and disk arrays.
In the classic Server+SAN architecture it’s quite different because if still not considering the mission the server would be assigned to, heterogeneous server configurations generate hierarchized usage: newer powerfull servers (many CPUs with much, much Ram) monopolize disk consumption, leaving other older servers waiting for access.

>> You might just want to run a separate brand of DBMS for your OLTP and data warehousing.

Oracle’s philosophy for a long time has been to take the code to the data, not to take the data to the code (eg. integration of OLAP, Data Mining, Rules Management etc), so Exadata 2 as a combined platform is very much in line with that. Having worked on extracting data to data mining and OLAP applications I’m very much inclined to agree with them — data movement is a pain.

However, running analytics against a live OLTP schema is a formidable problem. That doesn’t preclude hosting both types of database on the same machine though, with all the advantages that would bring. It looks like they’ve put soe serious thought into resolving DW and OLTP SLA’s also.

As for the opinion of Teradata, Greenplum etc. … “Man holding hammer says screws will never catch on”. They rather would say that, wouldn’t they? Solving the technical problems of creating a world-class OLTP RDBMS rather exceed those of creating an analytic platform, I’d say.

>>You may want to lay out or index your tables differently for OLTP and data warehousing

Yes. I don’t think that anyone at Oracle Corp. would disagree with that. But they would probably suggest that Exadata 2 as a combined platform helps with that by making the process faster and reducing the complexity of data movement.

>> You may want to lay out your files differently for OLTP and data warehousing (e.g., in terms of block sizes).

Maybe so. It’s a trade off between complexity of management and technical advantages. Oracle have the reputation, somewhat unjustly IMHO, of being high-maintenance and ASM’s SAME approach is obviously intended to address that by offering to take away a decision point about these issues. That decision can still be addressed if you want to though, I would guess.

>> OLTP and analytic workloads step on each other’s toes

In Oracle that tends to be a disk issue. It looks like that is really being addressed though with more advanced query scheduling and I/O balancing (I/O resource management has not been addressed at all as far as I can think in pre-Exadata 2 Oracle), and OLTP-on-flash can only help.

Well I think you’re right to be cautious, but I also think that Oracle are right to pursue this line. They’re obviously putting a lot of effort into whacking the moles of the problem and I think the the discussion above shows that the primary concerns people have about it have been anticipated. Whether the solution is right on the first pass is still to be proven, but it’s an exciting step in the right direction.

I think that if mixed workloads on a single machine are possible then Oracle have positioned themselves to be the only ones capable of reaching it in the near future.

Yes, I agree that the data should be isolated into some kind of separate stuctures for data warehousing. As you say, historical data analysis is not well served by 3NF systems and Peoplesoft or SAP or course are not designed to do that.

However I don’t think that claiming that Exadata 2 is suitable for mixed DW/OLTP workloads is the same thing as saying that you don’t transform and move the data. I think it’s very likely that you would. Whether that’s in the same database or a different one housed on the same machine would be an interesting decision, and I wonder how co-hosting on the same hardware would affect that. Maybe it’s the old-skool in me but I’d look at separate, “co-located” databases first and look to be convinced that they can be part of the same database. Oracle’s CDC solutions or transportable tablespaces would be interesting when running with the same Exadata 2 hardware as both source and target.

Only your #1 and #7 really seem to require separate databases for DW and OLTP. And #7 seems pretty silly to me.

#1 could actually be addressed in a single DBMS by materialized views as well. But it’s an excellent point even so.

1) Your history is there even if your OLTP systems blows up. It’s not a matter of backups: the vendor goes belly up and there’s no further support, your business changes too much to keep using the old system, your new CEO loves a different SW etc.

2) Building such a database forces you to think to an analysis model for your business. A stable model makes comparisons with the past possible. The need for changes in a DW mirrors the need to change the company strategy; changing too often means that your company does not know where she’s going.

3) Building such a database forces you to think to key performance indicators for your business. No business, no matter how small it is, is best managed with the bank bottom line only.

4) Likely you have different systems with different master data. Likely you had them reconciled in your database or you have generated best practices for them.

5) Often business people think by categories not implemented in a business application. Your DW may be the only place where some data may reside and be applied to your analysis model.

6) If you have a decent Business Intelligence system in place, you can cope quickly to unexpected, one shot, requests and be ready when the request is issued again for another one shot.

7) having a different DB on a different technology make the DW users feel special compared to all those data entry people, and make it more acceptable to upper management.

It’s not a technical issue at all. Separating the two worlds makes sense from a business perspective.

In my previous job we stored both the now and the history of our data in our OLTP system. That was possible because the amount of data was small, no need to export the data to a dataware house and delete history in the OLTP system. By the way just storing present and past is hard but storing data with a startdate in the future makes it much, much more complicated. The past will always be the past but the future will become the present first before becoming the past.

Most changes in this system where a combination of update and insert. You could query how ‘life’ was 200 or 600 days ago or how it will be over 50 days.

The business logic was very complicated and I think that splitting the data between an ‘OLTP’ database and a ‘dataware house’ database would have made it even more complicated and it would be costly and error-prone. Should that dataware house only contain history data or maybe future data too? When it has to contain future data too you will have to copy that data to the OLTP system one day.

I don’t understand how a dataware house somehow improves data that have become inconsistent in the OLTP environment. I think it is better to explore the possibilities of stuff like unit tests to improve applications. Or explore the possibilities of unique function based indexes or fast refresh materialized views to check the data consistency if you want.

In my current job the amount of data of my customers is much larger and because of the large amount it is indeed needed to separately store the now data and the old data. Luckily we don’t have to deal with future data:)

OLTP systems are designed to deal with *now*, in a small number of areas they will “track history”, occasionally they do it correctly.

However, most changes in OLTP take the form of an update. I feel a deep sense of joy when an app has a “DateUpdated” field. If I have to rely on the app to tell me the previous value then I’m SOL.

I’m going to quote myself here: “Data isolation is the first step to data quality and integrity in the warehouse.”

And add: A PITA (point in time architecture) is the second step to data quality and integrity in the warehouse.

…and yes I do relish the double entendre of that last acronym.