[...] > Well, not exactly: it's significant faster on SQL Server *and* Oracle.
That's a hard statement ;) Did you (or someone else) try to find out the reason for this? MaxDB comes by standard installation with a configuration, that is suitable for "usual R/3 OTLP" configurations, this may not be the right one for your environment. If the differences are that significant, I'm sure it would be of interest, why it behaves like this. [...] > True, but there are scenarios where you do not want to lump everything > in one single SAN because you want to reserve part of the IO bandwidth > for particular tasks (parts of the schema). Or you want to be able to > take individual tablespaces offline and manipulate them independently. We have actually two SAN systems but we put the production OLTP, the production BW and production CRM on one box - and still don't reach the cricitical I/O bandwidth where one system slows down the other, even during usual working days where all three systems run on their usual load we don't reach that point (yet). > I understand the reasoning behind MaxDB's approach to distribute data > evenly across volumes but this only works good if you have them on > physically separate disks. Even in that case you might suffer major > data loss if one volume is corrupt. I may be missing something but I > am not aware of a way to extend a volume if you need more space. And > that seems a fairly common thing to do - especially with SAN's which > can grow seamlessly. Then again you might say that multiple volumes on > a single SAN are not a performance issue because there is no > hotspot... You can't "grow" a volume but you can add another one; the system tries then to evenly distribute the data again across all volumes. In low I/O times, the DB also moves the blocks to the new volume so you will end finally with database of even distributed data across all volumes. This is true for usual OLTP databases, for OLAP this concept has changed with the implementation for the BI feature pack (as far as I technically understood the details). [...] > The difference here is that you do not have to migrate from 8 to 10 as > often as you have to migrate from MaxDB 7.5 to newer versions. You usually migrate once from 7.5 to 7.6 ;) I think, that one of the main reasons, why companies decided to use Oracle is: Oracle is well known, widely accepted and the de-facto standard database. If someone chooses a different database, the (I call it) ATV (accepted tolerance value), is MUCH lower with other databases, although many problems, whatever kind, could certainly be solved with an appropriate amount of time. If you have a problem with MaxDB, everyone would say "If we were staying with Oracle...". If Oracle has a big problem in whatever area, you just live with it - because it's Oracle. You take into account and install dozens of patches on your systems, hire additional DBAs just because it's like it is, and it's accepted like this. I'm sure that, if you would invest the same amount of time initially for a MaxDB migration as you needed to get your Oracle databases installed, patched and tuned, you would get almost similar results. Your points are really interesting, it's not about a flame war here but interesting, why one chose to not use MaxDB. Greetz, SIEGENIA-AUBI KG Informationswesen i.A. Markus Döhr SAP-Competence Center/Basis Tel.: +49 6503 917-152 Fax: +49 6503 917-7152 E-Mail: [EMAIL PROTECTED] Internet: http://www.siegenia-aubi.com _________________________________ SIEGENIA-AUBI KG, Industriestraße 1 - 3, 57234 Wilnsdorf-Niederdielfen Kommanditgesellschaft, persönlich haftender Gesellschafter: Wieland Frank, Sitz der Gesellschaft: Wilnsdorf, Registergericht: Amtsgericht Siegen, HRA 3741 Der Inhalt dieser E-Mail und etwaige Anhänge sind vertraulich und können urheber-, patent- oder in anderer Weise rechtlich geschützt sein; sie sind deshalb ausschließlich für den bezeichneten Adressaten bestimmt. Sollten Sie nicht der bezeichnete Adressat dieser E-Mail oder dessen Vertreter sein, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts dieser E-Mail oder der Anhänge unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen und jegliche Originale und Kopien der E-Mail und der Anhänge zu vernichten. Wir weisen ausdrücklich darauf hin, dass die E-Mail-Kommunikation über das Internet unsicher ist, weil unberechtigte Dritte grundsätzlich die Möglichkeit der Kenntnisnahme und Manipulation haben. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
