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]
