2007/6/6, Döhr, Markus ICC-H <[EMAIL PROTECTED]>:
> > 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?
Yes - I mean concurrent activity.
That's good!
> 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.
If the application is developed only or primarily on a specific database, it's
pretty understandable, that other databases don't perform as the one, it was
developed on.
Well, not exactly: it's significant faster on SQL Server *and* Oracle.
> DTS and backup / restore on SQL Server are also pretty easy - and
> online operations as well.
Backup/restore - yes - but not online (on system backing up, the second is
using that backup *simultaneous* to restore). And that concurrence has an
impact.
True.
> 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.
The SAP note is not for auxiliary products but for the main RDBMS. Well, some
of them are OLAP specific..
Ah, ok.
> Some of the features that I am missing from MaxDB:
>
> - Table partitioning
> - Control over where data goes physically (tablespaces etc.)
You don't have that control on SQL server too.
I beg to differ: the concept is known as filegroup in SQL Server land.
And SQL Server 2005 additionally has partitioning.
Why do you think that is important? I mean, if you have ONE SAN connected, I wouldn't
care if the data is read from oradata1/file1.dbf or oradata2/file2.dbf, there will be no
"hotspot" on a SAN.
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.
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...
> - Introspection capabilities that allow to tune SQL (tracing,
> AWR etc.)
In SAP area you have those possibilities too (SQL-Trace, "select * from
running_commands" etc.), on non-SAP platforms I agree, it may be more difficult.
> Also when I read recent postings here about version migration hassles
> this does not give me confidence in robustness and manageability...
Then try to read an Oracle forum of migration from 8i/9i to 10g...
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.
> 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.
Yes - absolutely.
What I want to say is that for a SAP R/3 system MaxDB is suitable also on
medium to bigger sizes database.
That's still an impressive achievement!
Kind regards
robert
--
Have a look: http://www.flickr.com/photos/fussel-foto/
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
