Re: MaxDB vs MySQL
"Robert Klemme" <[email protected]> Wed, 6 Jun 2007 10:42:09 +0200
| Newsgroups | gmane.comp.db.maxdb |
|---|---|
| Message-ID | <[email protected]> |
Am 06.06.07 schrieb Döhr, Markus ICC-H <[email protected]>: > [...] > > I still cannot believe that there are reasonably large SAP > > applications in production that are based on MaxDB. But that's > > probably only because I haven't seen it myself. :-) However, from my > > experience MaxDB usage comes nowhere close to e.g. Oracle or SQL > > Server - neither performance, nor manageability or robustness wise. > > Our main R/3 database (4.72) is 1.2 TB running with MaxDB 7.6 on Linux, we have avg. reponse times in the R/3 below 400 ms serving 550 - 800 concurrent users, some of our test/development/training systems are even bigger than that (up to 3 TB after client copies); we grow each day between 2 - 4 GB. 1.2TB certainly sounds impressive. With 500-800 concurrent users do you mean "concurrent activity" or "concurrent sessions / connections"? And: is that response time comparable to what you see with other DB products on same / similar hardware? For our type of application (kind of DWH with continuous updates) we never saw performance that came close to the other DB's the products supports - neither for insert / updates nor for queries. We also experience significant higher growth of the database vs. other products for our use case. We also had issues of joins returning different results depending on some DB option for some version of 7.6. > I just did an "online system copy" yesterday from running production to new training system via pipes, I've never seen another database, that is able to do that with so less effort and hazzle; copying that 1.2 TB was a matter of 10 commands, 3,5 hours and a final "load_systab" before the training system can be used. DTS and backup / restore on SQL Server are also pretty easy - and online operations as well. > If I look at the newest Oracle Pachset/Patch note for 10.2 (note 871096 and all dependent) I'm really really happy we don't have to deal with those 30+ single/interim/merge/CPU patches, patches for the "patch program" Opatch, runInstaller, relink issues et al. If someone calls that "managable" and "robust", then I am certainly missing something... In my experience much of the patches are needed for auxiliary programs. If you use the RDBMS only then that is pretty stable as far as I can tell. Some of the features that I am missing from MaxDB: - Table partitioning - Control over where data goes physically (tablespaces etc.) - Introspection capabilities that allow to tune SQL (tracing, AWR etc.) Also when I read recent postings here about version migration hassles this does not give me confidence in robustness and manageability... That's my 0.02 EUR. It might well be that all these are non issues for other deployments - that's simply what we have experienced. Kind regards robert -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[email protected]