Re: MaxDB vs MySQL
2007/6/6, Jonah H. Harris [EMAIL PROTECTED]: On 6/6/07, SRM SRM [EMAIL PROTECTED] wrote: I'm confused. Can someone tell me what are the key differences between MySQL and MaxDB. Also, what are the key differences between the underlying db engines (eg, INNODB, etc). TIA. MySQL is and always has been the MySQL database created by TCX DataKonsult AB. It is mainly targeted at the web-tier for the moment. As far as what I hear mysql also targets large scale installations. MaxDB is a rebranded version of SAP's database, SAP DB (which was itself based on ADABAS). MaxDB usage and administration is comparable to Oracle, DB2, and the like; it's built for 24x7 usage and large scale applications (like SAP enterprise apps). 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. 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]
Re: MaxDB vs MySQL
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. hello Robert, i know of more than one (and more than two ;-)) terabyte or near-terabyte installations of maxdb at some sap-asps, large german coffee-roasters and retailers.. ;) further, i agree with you that maxdb-manageability and useability is now where close to (and especially) oracle concerning confusion and complexity. the fact i love about sapdb (i still can't get the word maxdb over my lips) is its simplicity, you can do everything a oltp-db has to do with ease, but you're not crippled by gigabytes of unusefull stuff. but it all depends on the exact use-case. so long, best wishes, flo -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: MaxDB vs MySQL
[...] 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. 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. 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... Just my EUR 0.02. 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]
Re: MaxDB vs MySQL
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]
RE: MaxDB vs MySQL
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. 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. 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. 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.. 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. 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. - 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... 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. 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]
Re: MaxDB vs MySQL
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]
RE: MaxDB vs MySQL
[...] 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]
Re: MaxDB vs MySQL
2007/6/6, Döhr, Markus ICC-H [EMAIL PROTECTED]: [...] 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? Well, we tried but it's difficult with the given tools. For example, at times we experienced a high startup time but were not able to detect which SQL was responsible for this. IMHO that is actually one of the weak spots of MaxDB: with SQL Server I start the profiler and get timings and execution plans, with Oracle I do a session or DB trace and examine with tkprof, look at trace files directly or even use AWR etc. With MaxDB it is really hard to connect performance figures to SQL statements. 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. Certainly. But there is the crucial T point below. I also had a conversation with Joerg end of 2005 who seemed to be interested to learn our issues but when I got back at him I did not get a reply so I stopped asking. Unfortunately (for you) I will be leaving the company I currently work for soon and thus I don't actually have the resources to dig further into this. Also, the product we are talking about is phased out soon. Basically the schema is pretty much a standard snowflake with only few additional indexes. Dimensions are filled via SP calls and fact tables are loaded through loadercli. Queries typically combine data from larger time frames (say a month) and sometimes involve inline views that do totals calculations (to be able to report percentages). If you are interested in more detail please contact me offlist; maybe I can connect you to someone else who might be able to provide you with a demo license and further information so you can investigate in your lab. [...] 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). That's good for you. We OTOH have a large Oracle install at a customer site that uses a NetApp filer and is slow - so far Oracle experts have not been able to optimize it. So it's not all sunshine with the other databases as well (in this case it's Oracle 10g choosing a suboptimal plan). We also have another customer with a really large SQL 2k (3TB I believe) and they actually ran into a bug in the database. I was amazed because I had not expected that. Also I learned along the course that SQL Server 2k apparently is not using native threads internally. 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). But if all volumes reside on a single physical disk (assuming no SAN, but local disk or RAID) then even distribution might actually hurt performance. [...] 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 ;) Well, yes. But I have the impression that it is more often necessary to migrate to a new MaxDB version to get rid of bugs than it is with other RDBMS's. 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,
Re: MaxDB vs MySQL
On 6/6/07, SRM SRM [EMAIL PROTECTED] wrote: I'm confused. Can someone tell me what are the key differences between MySQL and MaxDB. Also, what are the key differences between the underlying db engines (eg, INNODB, etc). TIA. MySQL is and always has been the MySQL database created by TCX DataKonsult AB. It is mainly targeted at the web-tier for the moment. MaxDB is a rebranded version of SAP's database, SAP DB (which was itself based on ADABAS). MaxDB usage and administration is comparable to Oracle, DB2, and the like; it's built for 24x7 usage and large scale applications (like SAP enterprise apps). -Jonah -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MaxDB vs MySQL
What does it cost to run each (say, on an 8-way box w/ 16GB ram)? Technical differences? TIA. From: Jonah H. Harris [EMAIL PROTECTED] To: SRM SRM [EMAIL PROTECTED] CC: [EMAIL PROTECTED], maxdb@lists.mysql.com Subject: Re: MaxDB vs MySQL Date: Wed, 6 Jun 2007 00:23:58 -0400 On 6/6/07, SRM SRM [EMAIL PROTECTED] wrote: I'm confused. Can someone tell me what are the key differences between MySQL and MaxDB. Also, what are the key differences between the underlying db engines (eg, INNODB, etc). TIA. MySQL is and always has been the MySQL database created by TCX DataKonsult AB. It is mainly targeted at the web-tier for the moment. MaxDB is a rebranded version of SAP's database, SAP DB (which was itself based on ADABAS). MaxDB usage and administration is comparable to Oracle, DB2, and the like; it's built for 24x7 usage and large scale applications (like SAP enterprise apps). -Jonah -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] _ Like puzzles? Play free games earn great prizes. Play Clink now. http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2 -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
