What is Holding SAP-DB Back? 457
Derek Neighbors queries: "The current story about MySQL 4.0 has erupted into a Postgres vs. MySQL debate. We at GNU Enterprise, who have used about all Free and Propietary databases, would like to know why exactly people arent using SAP-DB? It clearly is on par with Oracle, is GPL and frankly has an awesome support team in SAP AG. There was a PG vs SAP-DB recently. Someone else mentioned that you can get CDROMs for free. So again the question is 'What exactly is hindering a wider acceptance of SAP-DB in Free/Open Software projects?'"
Why doesn't SAP use it? (Score:3, Insightful)
Umm... (Score:3, Insightful)
PostgreSQL does transactions, hot backups etc, would you consider switching to it?
Re:Umm... (Score:3, Funny)
Bastard DBA From Hell Response:
That's where we keep the temporary table space for users we don't like. Can't get punchcard systems anymore dammit.
Re:The value of backups (Score:3, Informative)
1. Hot backup at 1am Sunday (database is up and running)
2. Nightly backup of archive logs (i.e they contain all the changes to a database.
That will only get you back to the time of your last backup assuming you don't have other realtime copies of your xaction logs and tables. If you're running your db on one big box with box table storage and xaction logs, if some big power surge comes along and crashes the heads of all your drives, all you can do is restore your full and add the xactions up until your last backup. Anything done since that time is gone.
Re:Why doesn't SAP use it? (Score:5, Informative)
Umm, what are you talking about? Of course SAP DB (nee Adabas) has transactions; it's fully ACID, unlike, say, MySQL.
SAP DB is pretty much equivalent to Oracle 7.3.4 which is to say that it's a solid product for many real-world applications, but lacks many of the features for truly high-end deployment, like clustering, complex replication, guaranteed messaging, etc. I'd take Sapdb over MySQL any day, and probably over Postgres too. Another nice thing about SAP DB is that it can emulate Oracle's system tables, so an Oracle DBA can administer a SAP DB system very easily.
Also, SAP-DB doesn't have drivers for some of the more exotic tape systems, unlike DB2 or Oracle. The only tape system we could get working for backups with SAP-DB was an old single drive, manual loader DAT system.
Again, I'm not sure what you are talking about here. Do you mean you can't get an LSM plugin for SAP DB like you can for Oracle? Because that sort of stuff is really just fluff, you can do anything it can do with your regular storage manager (which may even be Legato) with a few simple scripts. I do agree that SAP DB's backup and recovery is primitive compared with Oracle's RMAN.
Replication and messaging (Score:4, Informative)
In my experience
- pulling transaction records from a remote database results in a considerably superior solution to that obtainable with any messaging middleware product
- using duplicated "hot-standby" systems is more manageable and efficient than data replication.
So please don't dismiss PostgreSQL and SAP DB on the basis of checkboxes for features you might not want to use.Re:Why doesn't SAP use it? (Score:2, Informative)
Re:Why doesn't SAP use it? (Score:5, Interesting)
Recently the glassie at my local bar told me that they where the same beer. I didn't believe him, so he did a test. He poured me a crownie and a fosters, and got me to blind compare them. I could not tell the difference. The moral here is that taste is *socially constructed*. That is in non sociology talk, we base our likes and perceptions on the social environment that we are exposed to. It's a wierd thing.
Re:Why doesn't SAP use it? (Score:2, Interesting)
I worked as an SAP Basis admin for about 3 years (got sick of it). I didn't see a single installation (and I saw a lot having worked for Andersen Consulting) that wasn't either DB2, Oracle, or Informix.
Examples...? How about IBM Storage Systems Division, Best Buy, Canadian National Rail, etc, etc...
As for why...
Well, 1. companies have years of trust and investment (systems and training) in other enterprise DB's (like Oracle, DB2, etc).
And 2. I would be hesitant to use an SAP and SAP product. Not because they wouldn't work well together, but because it gives too much control to one company.
Just my $0.02.
-Alex
Oracle (Score:2, Informative)
I think you'll find one of the main strengths of Oracle is it's REPUTATION. People know they can trust it as its been around for years and 'everybody' uses it.
sapdb is too complicated - interbase/firebird. (Score:4, Interesting)
sapdb needs a lot of effort to set up and create a
database, sometimes even worse than the magic juju you need to go through with Oracle.
What surprises me more actually is that Interbase/Firebird is not more successfull.
It is free and as simple to set up/use as mysql in my opinion, but avoids most of the
mysql limitations.
bad source code too (Score:5, Informative)
Another thing I forgot: sapdb is unhackable. If you ever wanted
to see what unmaintainable for normal people code looks like, go no further than to sapdb.
It is incredibly bloated and complex, very crufty internally, written in a weird pascal/C++ mix
with an SAP specific format for the files, has a build system that could be
only described as ununderstandable, no comments.
It is what you would expect from a 20+ years old codebase
I'm glad the SAP Berlin guys understand it (they seem to at least), but I see not much chance to do any changes
on your own. This makes it not very useful as a free software project.
Of course it is still nice that they offer it for free, but for all practical purposes it is like a binary only download. To be fair interbase has some of these problems too, but it has still relatively nicer source than sapdb. mysql is much better in this regard.
Re:bad source code too (Score:2, Interesting)
Re:bad source code too (Score:2)
SAPDB is very easy to maintain, using the SAP tools. I had no major issues with it on our non-prod test system. Why the heck would you try to "hack" it? That's like trying to re-make SSAA or ST03 just for fun. Use it, like it, don't like it, whatever. The tools SAP provides are frequently cheaper, as nice, and as easy to maintain as third-party offerings.
-WS
Re:bad source code too (Score:2, Informative)
Nice
One can be a totalitarian - but not a totalitarianism. The fact that a "Republic" (sic) is a plurality does not change this.
For example, consider the following conversation:
Me: "Of what political affiliation are you?"
Bill Clinton: "I'm a Democrat."
Bill would not say, "I'm a Democratic," obviously. Neither would George Bush answer, "I'm a totalitarianism." Well, perhaps he would, but only because he is an idiot.
I suggest rephrasing your
America - The republic that voted itself into totalitarianism.
This isn't a flame or a troll, or even much of a nitpick. I just happen to agree with you, and would like to see an opinion with which I am in concurrence expressed more eloquently.
Double Negative.. (Score:4, Funny)
That's not a word! You should have said "derstandable"! ;-)
T
Re:sapdb is too complicated - interbase/firebird. (Score:3, Insightful)
However, since it is damm hard to use and build I do not play around with it. As an example look how easy it is to build MySQL, Apache and PHP. DEAD SIMPLE. And look what are the biggest tools LAMP (Linux, Apache, MySQL and PHP) or WAMP (Windows, Apache, MySQL and PHP).
Too complicated and _RUNS AS ROOT_ (Score:2, Insightful)
Both the DBM server and the Replication Manager server must run as user root. The files instdbmsrv and instlserver set the appropriate permissions every time these programs are built.
Seems like as good a reason as any not to use it. What daemons run as root any more? Especially ones that move large amounts of data around like RDBMS's.
We use Postgres or BerkeleyDB.
-- Azaroth
Re: interbase/firebird. (Score:2)
And in any case, the language that I would want to call it from would be Ruby (or possibly Python), and while there are ways already defined to call MySQL, PostGres, BerkeleyDB (SleepyCat), etc. from those languages, it appears that I would need to write an access method to Firebird by myself*, and I don't see why it would be worth the effort. I'm not saying that it wouldn't be, but the documentation seems to assume that I already know why this would be a worthwhile thing, and I don't.
* The Ruby Interbase access method is at version 0.03 (though it is reported to be working fine). Python also has an access method for Interbase (and it says that it works with Firebird, too), but it isn't a part of the standard distribution. Still, that would probably work with few, if any, adaptations. So this isn't a major effort, but why to bother isn't clear.
Re:sapdb is too complicated - interbase/firebird. (Score:2)
tried it .. crashed (Score:2, Interesting)
Re:tried it .. crashed (Score:2)
It was an segmentation fault. and in 99% of those cases it's caused by bad input-checking.
Hmph (Score:2, Interesting)
Re:Hmph (Score:3, Informative)
Linux/PHP/Sap DB tutorial (Score:3, Informative)
I think that this is what you wanted.
Re:Linux/PHP/Sap DB tutorial (Score:2)
Yes? You've tried UnixODBC? (Score:2)
SAP-DB (Score:2, Informative)
As much as everyone maligns M$, nobody ever puts in MS SQL in the conversation. (We're a DB2 shop not M$)
beware of the trolls
On par with Oracle? (Score:4, Informative)
Re:On par with Oracle? (Score:3, Interesting)
I know you're responding to someone else's claim about SAP-DB being on par with Oracle, but the meaningful question is whether SAP-DB deserves more recognition as a free software database solution, isn't it? What do you do if you need to work on your primary database machine and you're running PostgreSQL? You take the machine down in a maintenance window, and if necessary, put up a secondary machine that is "manual standby."
SAP-DB is pretty much the back end of SAP's commercial systems like SAP R/3. I'm sure there are things that Oracle does that SAP-DB doesn't (just like there are systems that actually do things Oracle doesn't, even though your Oracle sales rep won't admit it), but it's difficult to argue that the system doesn't have credibility in the enterprise.
It also supports Microsoft's cluster server on Windows, with failover; they're working on a cross-platform solution for hot standby, according to the website. It does have a batch mode replication manager, too, at least.
Re:On par with Oracle? (Score:5, Informative)
It's a little more complex than that. SAP's R/3 product is an ERP system than competes with Oracle's ERP suite. For example, R/3 General Ledger competes with Oracle Financials. SAP were getting annoyed because every time they won a pitch against Oracle for ERP, Oracle ended up getting some money anyway, because R/3 required a database to run on, and Oracle was the most popular.
So, SAP bought ADABAS as tried to push ADABAS-D as the preferred database for R/3. That way, when they beat Oracle to win business, they would get all the business for themselves. Unfortuately, it never caught on, customers preferred Oracle, partly because it was a better product, and partly because they already had it and people who knew how to use it. So SAP were left with ADABAS-D which no-one wanted, so they renamed it to SAP DB to capitalize on their brand, and jumped on the Open Source bandwagon for some free publicity.
On par with PostgreSQL? (-: (Score:4, Insightful)
If PostgreSQL could magically don an Oracular CIO-level reputation, the bottom half - or more - of the Oracle market would evapourate in a few short years.
Re:On par with PostgreSQL? (-: (Score:5, Informative)
Well, considering PostgreSQL is free, a whole lot less sorry for being picky, but it occurred to that some people might be lost in the irony.
PostgreSQL was never GPL'd. Not even copyleft, but just a plain free software license, can't remember if derived from BSD or MIT X. If one wants copyleft, SAPdb is the only choice now.
Re:On par with PostgreSQL? (-: (Score:2)
What's the advantage of using a copylefted product over a MIT/BSD licensed product? There's none that I can see unless you're going to hack it, and even then, it depends on what you want to do with the end result.
Re:On par with PostgreSQL? (-: (Score:2)
No one can ever make it proprietary. That is, availability assurance.
PostgreSQL is not GPL (Score:4, Informative)
No, it was one of the first on the Open Source block, specifically it has a BSD license. And SAP-DB needs to beat PostgreSQL on several counts for it to be considered:
(a) features, PostgreSQL has them in spades, (b) stability, PostgreSQL is solid, (c) licensing, you can't beat BSD, and most importantly, (d) community, PostgreSQL's user community is just a fanstatic group of fellas.
Re:Wrong - you dont work in an enterprise-level sh (Score:4, Insightful)
Re:Wrong - you dont work in an enterprise-level sh (Score:3, Interesting)
Oracle isn't about db's, only partially about support (to sell you more apps), and most definitely 95% about their application solutions.
Oracle could switch over to postgres is they wished and except for PR issues, it wouldn't significally change their ability to supply solutions to companies that need them.
It's just that for 99.9% of companies out there the apps are just way overkill... must people can get by with postgres or mysql with custom written stuff or downloaded stuff and do just fine. Of course give the open source community a few more years and there will be off the shelf apps that will rivel those of Oracle, I'd be willing to bet.
Re:Wrong - you dont work in an enterprise-level sh (Score:3, Insightful)
You are right about their products being overkill for most companies out there. I've called Oracle knowing exactly what license I need. Before my conversation is over they've always tried to change my requirements and sell me more than I need. They've even suggested I change my server platform to Linux so I can free up some money for buying their additional stuff. If this continues to be their practice, other solutions, maybe even open source might be an alternative for me in the future. But I can see where companies can get tricked into getting more than they need and end up with overkill for a simple solution.
Not in BSD ports tree. (Score:5, Insightful)
Subject says it all. Probably also goes for Linux, (but the argument there would probably be more
"doesn't comes (integrated) with the distribution"
If something gets included with distributions, it spreads much faster
People don't know ? (Score:2, Informative)
What SAP doesn't want you to know... (Score:4, Funny)
Re:What SAP doesn't want you to know... (Score:4, Informative)
Re:What SAP doesn't want you to know... (Score:2)
But why would they black it out?
This is not some paper-only copy, it's HTML! Just delete the offending text.
Putting in black bars is just wacky.
i was going to say... (Score:3, Interesting)
so now i'm wondering what the catch is. too big? bloated? slow?
well, the minimum requirements on Linux [sapdb.org] list a base memory footprint of 128 MB. MySQL runs on just about the smallest box you own, and most people tinkering with MySQL are on budgets of $0, meaning, no new bigger boxes for a long, long time.
I never heard of SAP-DB... (Score:3, Informative)
However, I have had the same question in relation to the open source version of Borland's Interbase, the Interbase fork - Firebird, and the hsql Database Engine.
It seems to me that the community has latched on to MySQL and PostgreSQL as -the- database solutions, and this very acceptance places them higher up the food chain. For instance, hunt around for an open source based Content Managemnet Sysytem (ala SlashCode or PostNuke), and almost invariably it has a MySQL backend.
Re:I never heard of SAP-DB... (Score:2)
It might also have something to do with the fact that SAP itself is pretty much known as a big deal to install. This might be the reason why their clients are mostly Fortune 1000 - it costs a lot to install the software after you buy it.
Re:I never heard of SAP-DB... (Score:4, Interesting)
SAP is sweet in that it is incredibly easy to control the flow of money and goods around a system, but everything requires customization. This is not OTS software. A typical install takes 2 years, and just handling an upgrade will be the hardest 4-5 days of your life. We did 3.1H to 4.6B in a 3 system (development, quality assurance, production) landscape in 2 weeks, and I think we darned near set a record.
SAP is definately only for really large commodity driven companies. If I were the CTO of a medium size business, I would not use an ERP like SAP. I'd use something much lighter weight. Of course, if I were Amazon, Dell, Anheiser-Busch, Pepsico, etc. I would be using SAP. Nothing else comes close when you need to know what, where, when, and how much.
-WS
Re:I never heard of SAP-DB... (Score:2)
And of course there's always a little IBM product called AS/400...
Re:I never heard of SAP-DB... (Score:3, Insightful)
We are talking about SAP-DB, not SAP, the ERP....
Why, then, did this "America - The Republic that voted to become a Totalitarianism. [sic]" post earn a "Score:4, Interesting?"
SAP-DB and SAP are two totally different topics.
Documentation (Score:3, Insightful)
It doesn't exist. The bottom line is that most websites and the like don't need all the features of Oracle. In fact, they don't even need all the features of MySQL or PostgreSQL. Most of them could probably run fine on DBASE. So, the fact that SAP-DB has sixteen billion enterprise features doesn't really make a difference. Combine this with a total lack of third-party documentation for SAP-DB, and it really makes sense to stick with the "standards."
Incidentally, another problem is that, when I develop a web app, I know I can easily find hosting on PostgreSQL (my preferred DB). What hosting providers run SAP-DB? The bottom line is that most web apps run on hosted servers that often don't allow people to run their own DB engines, so this is a big issue.
Ease of Setup and Use are the most critical... (Score:5, Interesting)
In my job I have used literally every DB out there and none of them are easier to setup than Microsoft. It also the easiet to use from the application side. With oracle and other db's you need to know all kinds of listener and config info about where you dbase is. With MS and a few others you just need the servername and dbname and it works. Thats how things should be.
I am quite happy with the way MySQL is coming along.. they finally have a decent admin interface and the other feature they have needed for years... now if installation and usage were just a bit easier they could really compete.
SQLsnake (Score:2)
Actually, with MS you only need the servername and it's as good as 0wn3d (-: and with the advent of SQLsnake, you don't even need that :-)
PostgreSQL is a lot more standard and complete than MySQL, outruns it in many practical situations (ie under enough load that anyone actually cares about performance) and is as easy to set up and use (if not easier) than MySQL; it also has simpler, clearer licencing. The mystery to me is why MySQL has done as well as it has in the face of all of this.
InterBase also seems to hammer MySQL pretty much across the board, but was a late starter. I'd expect to see it do some catching up as more of the application languages abstract their DB interfaces, detaching the DB choice somewhat from application programming and so allowing the DB to be chosen on merit rather than I-was-here-first.
Re:Ease of Setup and Use are the most critical... (Score:3, Insightful)
And that is exactly why MS is around. Any moron (nothing personal mind you, just a generality) can set up a MS SQL database engine. Or for that matter, DNS, mail, etc.
Why should you need to know the things Oracle (or Postgress or MySql) asks you to? Because you need to know what the f*ck you are doing if you are going to manage any database that is important. How many disks should you use? Which data sets go on which disk? How about indexes? What ports should I use and why should I not use the defaults? Where are the default passwords? Why should my commit files be on different disks from my data and indexes?? Why do I need more than one copy of the parameter or control file?
If someone doesn't know the answer to the above questions, then they have no business calling themselves a DBA, or installing a real database that someone else uses or depends on.
Or, in other words, just because you can start a car doesn't mean you get to drive on the freeway.....you have to learn how to use it without killing anyone first.
Re:Ease of Setup and Use are the most critical... (Score:2)
Oracle does get unecessarily complicated when you start attempting to implement their more interesting "enterprise" features. However, you don't seem to be aware of these on either the Oracle or Microsoft end of things.
Already using it (Score:2, Informative)
Applications (Score:5, Insightful)
Unless you are a software genius, the sensible choice is the one with most support in the community. Think perl, mysql.
This creates a network effect that your expertise gets added to the pool of knowledge and thus that pool becomes even more inviting.
Taken to the next step, you see fine languages like Python and fine databases like PostgreSQL fall behind in terms of support because their pool of expertise comes from a smaller number of users. But they do fine because there are so many developers out there who love them. These tools thrive with a a certain "less popular but more excellent" feel.
Sadly, if a third player comes along some years later, then they will have a very hard time getting a following big enough to generate the pool of expertise that leads to having lots of applications. Think Ruby, SAP-DB.
And its applications that determine popularity.
That is the short answer to the question - waht is holding SAP-DB back. Excellence isn't everything - being first on the scene gives huge advantages. And they were nowhere near first...
Patrick
First Mover advantage is evapourating (Score:3, Informative)
In some cases the backend DB needn't even be SQL (great news for tiny high-performance web apps), but where the backend DB does stick closely to SQL standards the applications produced with it are more likely to be portable and scalable.
Because... (Score:2, Funny)
I'll take PostreSQL any day, thank god for that license.
Re:Because... (Score:2)
GPL deals with modifications, not what you use the software for.
Are you modifying Postgre for your installs? Do you give the source code to those modifications for the people you install it for? If so, then GPL isn't an issue
Flooded enterprise market (Score:2)
There will only be two or three REALLY popular entrants, the rest will be left to muck about with single digit usage.
Without belaboring GPL v. Microsoft v. Oracle, I'd recommend you look at the Cola Wars: Coke has the margin (60%+), Followed by Pepsi (30% ish) and _everybody else_ scrounges around for the ramaining 10%.
Why we (I) don't use it... (Score:5, Interesting)
The company I work for uses alot of open source software in it's development - both in terms off server side (linux, apache, etc) and for the application side (Tomcat, JServ, etc).
We don't use SAP-DB because:
I dare say that if we had a pressing business case to learn the extra skill (i.e. we required some of it's fetures on a project that hadn't got the Oracle budget) then we'd consider it.
Then again there are other Dbs that would also cut it in that case too.
MYSQL has a big name in terms of Open Source software and that alone may prevent people from switching from it in favour of a less well known 'brand'.
Re:Why we (I) don't use it... (Score:2)
-WS
Re:Why we (I) don't use it... (Score:2)
Re:Why we (I) don't use it... (Score:2)
> DB2 or Oracle don't even seem to like it (mssql).
Oh yeah? Give me their names and addresses, I'd like to have a good laugh. We're using both Oracle and MSSQL here, and while no-one is denying Oracle's advantages (such as they are), its strengths certainly do NOT lie in ease of use and maintenance. While we certainly have many valid reasons to hate and/or ridicule Microsoft, Enterprise Manager certainly has few peers in the database maintenance world.
PostgreSQL is truly free (as in BSD) (Score:3, Insightful)
As far as I know, PostgreSQL is the only truly free database (in this licensing sense).
But I could be wrong -- I'm standing by to be corrected...
Re:PostgreSQL is truly free (as in BSD) (Score:2)
listen sport, you can use gpl in embedded systems. you've heard of the tivo, right?
there are differences between bsd and the gpl. and they have different strengths. but it would be really nice if bsd advocates would quit being such twats.
the actual question (Score:3, Insightful)
one fine example of this was the boss conversation thread (this one [slashdot.org]).
the point was, its an open source database, why aren't people using it INSTEAD OF PG/MYSQL.
i tend to agree with the complexity side of things as about 3 years ago i tried getting it up and running - without much success. although, friends of mine who know pretty much nothing about unix are running a web solution on apache jakarta (jsp+servlets) using SAPDB as the databaase which they installed from RPMs. they sing its praises all day long.
maybe its the communities fear of a traditionally large $$ corporation giving away its technology?
Of the same reason people use Windows 95. (Score:3, Interesting)
I mentioned Firebird the other day when a guy asked
We use what we're used to, even if it's outdated or pointless. Other stuff is of no interest, Try telling a guy the advantages about Linux over WinXP and you'll know what I mean.
People are using it, and happy with it, but... (Score:5, Informative)
1. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
2. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
3. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
4. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
5. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
6. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
Compensating for this is the VERY skilled and responsive SAPDB development team, and a very strong feature set.
time (Score:5, Insightful)
The originator of the thread should learn that technology doesn't change overnight, and certainly not without the kind of marketing budgets behind Java & C#. Change takes time.
As another answer, I'd ask what is the driving point behind SAPDB? MySQL has/had noteriety for being a very simple system; Postgres had noteriety for advanced research into ORDBMS'es as well as coming out of a university lab that produced two very successful commercial DBs in the past. What's the big focus with SAPDB? All I know so far is that it was an in-house thing that worked for SAP. No idea what that's supposed to mean to me. Maybe someone should answer that first.
Re:time (Score:2)
I don't really know why Greatbridge failed while MySQL AB is succeeding, but it doesn't have anything to do with the quality of the particular databases. Business is a lot more complicated than that. It depends on having a good business model, good management, proper sales channel, reputation, etc.
Why we *are* using it (Score:4, Insightful)
We previously used Postgres for a long time but had two problems with it at that time:
- Postgres required daily database reorganizing (VACUUM) which was a problem in a 24/7 availability scenario
- Postgres didn't scale well beyond a few hundred concurrent database connections on SMP systems
This caused us to look for an alternative. After extensive testing with SAP-DB we decided to start using it on our production systems.
On our production systems we use both Red Hat Linux 7.2 and Solaris 8. On both setups SAP-DB has been rock-solid.
Some of our systems usually have 1000+ concurrent database connections, with all of those doing inserts and updates all the time. SAP-DB has shown that it is able to handle this kind of load without any performance or availability problems and without requiring any database maintenance.
If you are looking for a reliable enterprise scale GPL database, look no further: you'll love SAP-DB.
Main drawbacks for being a succesfull OSS project:
- source code structure takes getting used to
- database setup is quite straightforward, but documentation on getting it to work over ODBC etc. could be better, so new users would have an easier start
Last but not least, online support by the developers from SAP AG is excellent.
Jeroen Boomgaardt
Re:Why we *are* using it (Score:2, Informative)
I'm not against PostgreSQL, Interbase/Firebird, or SAP-DB, I'm just wanting to know why. (I am against MySQL in a medium to large production environment, but we'll wait until 4.1+ materializes.)
First point, "VACUUM" problem. What's wrong with a cron job to do this, nightly? Does it bog the system down too much? Is it unreliable? (I haven't noticed any problems, but my DB is small, right now.) Read about MVCC (I think it's something like multiple version concurrency....) Versioning is better than redo logs, in theory. You need to understand MVCC to understand VACUUM. You can VACUUM live, without killing the DB, and perform hot backups as well, due to MVCC.
Second point, have you tuned it, and are you using PG 7.2+? If you are using older PostgreSQL's (prior to 7.1,) then yes, this is a problem. If you haven't tuned it, there are great docs about tuning. Supposedly, PG 7.1+ is VERY fast at many simultaneous connections, although I know of no 1000+ simultaneous connection benchmarks in existence. (Do you believe benchmarks, anyway?)
If you have tried a newer PG (7.2+,) and have followed all recommendations/tuning guides and still have had these problems, I'd really like to know.
I'm open to PostgreSQL (am using it), Interbase/Firebird, and SAP-DB and want the real scoop on things.
Will PG break under big loads? If so, how big? Does PG have a 24 by 7 problem?
Re:Why we *are* using it (Score:3, Informative)
I believe the issue with VACUUM has since been solved in that it no longer holds any table locks.
Regarding scalability, we found that (again, compared to PG 7.1.2) SAP-DB scales better under high load. Of course we tried tuning both as well as we could. We measured transaction throughput and average as well as individual response times while steadily increasing the number of concurrent clients. We did this on a system with plenty of CPU power (quad Xeon). Once we pushed things to over say 150 concurrent connections, SAP-DB showed far less variation in individual response times and better scalability, beyond what PG was able to achieve.
PostgreSQL is a very fast database and I must admit that I haven't tried 7.2. The only reason being that SAP-DB was better than we expected...
Jeroen Boomgaardt
Maybe it's Pascal? (Score:3, Interesting)
I hope to be able to use SAPDB some day, if PostgreSQL ever breaks for us. Currently, there's nothing pushing us away from PostgreSQL and SAPDB lacks quite a few features we like in PostgreSQL (the extensible type system, which allows us to store IP addresses directly, for example). The documentation seems to unclear in quite a few areas, too. In addition, it seems that native (non-ODBC) backends are no longer supported by SAPDB.
No Multiversion Concurrency Control (Score:2, Informative)
I can't say I've used SAP-DB. However, a quick check of its online documentation reveals that it does NOT do multiversion concurrency control. Oracle does. PostgreSQL does. I believe Interbase/Firebird does. Without it, writing a scalable application is MUCH, MUCH harder because locking keeps getting in the way. Real databases need transactions, but without MVCC, the locking to support them will seriously limit concurrency (and, hence, scalability) in a transactional environment.
If you don't know what MVCC is, read the early chapters in Tom Kyte's book [bookpool.com] or visit his site [oracle.com]. Or read Oracle documentation [oracle.com] (search the page for "Data Concurrency and Consistency").
Many users of Adabas switch to SAP... (Score:2, Interesting)
While Software AG / Adabas introduced a Licence model, making the DB five times more expensive, while offering no support and having the most flawed JDBC-Driver you can think of.
Therefore Adabas users are the first and most likely to switch, maybe other user groups will follow.
Couldn't find an active development tree... (Score:2)
Hopefully I am wrong about this, anyone out there know otherwise?
Also Perl/PHP support doesnt't seem so simple (Score:2)
I would worry about performance and reliability with so many abstraction levels.
One would also wonder what the support for things like BLOB columns, parameter bindings and cursors would look like using this system. Again, anyone out there have experience with this and can set me straight would be appreciated.
Re:Couldn't find an active development tree... (Score:2, Informative)
Exposure (Score:2)
Backup and Recovery (Score:4, Informative)
Several Problems To Overcome (Score:3, Informative)
Marketing is of some importance, and the "other guys" have more of it. There are no books on bookstore shelves on SAP-DB. Few web sites "Powered by SAP-DB."
It's quite a different world, with very different build tools, code documented in German, and the likes. It is not something that is easy to hack on.
You can get a tarball, you can get some RPMs that work in some places, but it's not nearly as available as MySQL and PostgreSQL.
Much of the popularity of MySQL stems from there being integrated ISP tools like CPanel that include a DB manager module specifically for MySQL. Similarly, the joint popularity of MySQL and PHP stems from the groups of developers working together closely to ensure that there is good native support for MySQL in PHP.
In contrast, modules for integrating SAP-DB with Perl, Python, PHP, and the like require some degree of effort in "hacking it into place." It's not as simple as "apt-get install python-sapdb sapdb-dbi php-sapdb".
And TOra doesn't include SAP-DB support.
None of these are particularly "technical" matters indicating things that can't work.
It's not a question of "SAP-DB not being an ACID DBMS" (as some idiot claimed in another thread).
It's really largely a question of systemms integration, with a certain amount of "needs more marketing."
Data types (Score:2)
Take a look at data types in SAPdb. While they have, for example, date and time types that Oracle lacks, they are implemented as especialization of totally unrelated character strings. This is an ugly hack.
Now contrast that with PostgreSQL's data types [postgresql.org]. Elegance speaks for itself.
The Challenges of SAP-DB (Score:2)
1. Sap-DB is GPL with one restriction. If you are a current Sap Customer, forget using Sap-DB (GPL edition) the license forbids it (actually it's more complicated than that, but that's what it boils down to)
2. Horrible install. (a pretty good story about installing SAP that I've pointed out before http://groups.yahoo.com/group/sapdb-general/messa
3. No Dev enviroment. Same thing that (to a lesser degree) holds people back from some of the other OSS databases. Mysql, PGSQL, Interbase all have some sort of dev enviroment avaliable.
And no the WebDB/WebSQL interface don't constitute a dev enviroment.
4. Crappy (but getting much better) doc's.
5. Lack of third party support. I think the PHP support is now sorta there (I see mentions of it, but I also see mentions of probs with it). Until it becomes as common for app support as Pgsql or MySQL..
6. Lack of Admin tools. Gimme an admin tool as good as any of the many Mysql Interfaces, or the PGadmin tool or MMC for MSSQL.
GNU Enterprise (Score:2)
It looks a bit unfinished to me, but the modularisation ideas are pretty neat.
Re:GNU Enterprise (Score:2)
Installation (Score:2, Interesting)
The python that comes with the binary release doesn't even work correctly it seems.
After an hour of adjusting paths, fixing shellscripts and figuring out what else to install I gave up - I'll just stick with Postgres.
Also, the features aren't that impressive. I heard that the "replication manager" is just an dbdump import/export script or something like that (though I hope I'm wrong here)
SAP Today == Microsoft Tomorrow (Score:2)
Why I have not used SAP DB (Score:2, Interesting)
1) SAP DB has only been Open Source for what, a year? Heck, I only heard about it 3 months ago. PostgreSQL has been Open Source for over a decade.
2) SAP DB is a pain to set up. Frankly, I don't have an entire weekend to set up a new RDBMS just to evaluate it. (Unless, of course, I'm being paid to!)
3) SAP DB, unlike PostgreSQL and like MySQL, has the single-company-development problem. PostgreSQL, as an OS project with 25-50 volunteer developers worldwide has survived the death of, so far, 6 companies that supported Postgres or its derivatives. Like MySQL AG, if SAP AG were to go down the tubes, development on SAP DB would halt (though it would still remain available under the GPL).
4) Most importantly
-Josh Berkus
P.S. One volunteer suggested that we consider SAP DB support for OpenOffice.org. Sadly, we had to reject the idea because of the complexity and difficulty of administration for SAP-DB. If someone from SAP is reading this, and you disagree, please join the dev@dba.openoffice.org mailing list and make yourself heard.
the problems with sapdb (Score:3, Insightful)
i do find free software db's amusing though. they tend to be easier to install and manage then the closed source alternatives.
A few reasons why not (Score:3, Interesting)
2) It is from and controlled by SAP. I have worked with these people in the past and I deeply distrust their code and processes;
3) Life is short. I have no time for YADB that has no compelling advantages that I can see;
4) I believe in the importance of things like replication and objrect-relational features that SAP puts down as irrelevant.
Here's why (Score:3, Insightful)
- The build system is so unusual, i.e. completely 'off the wall', that without investing an inordinate amount of time I could not get SAP-DB to even build. "./configure && make; su -c 'make install';" it isn't! For this dedicated OSS devotee, that was a big black cloud forming on the horizon.
- I then installed off the provided CDs via the binary route, it's difficult to believe this, especially as I have been around these dumputer things for 30 years, but I could not find out in a reasonably simple or easy way how to start the daemon! By contrast, PostgreSQL tells you exactly what incantation to offer up at the end of the build process. Big black cloud overhead!
- It needs a minimum of 128Mb. At the the time I did not have sufficient memory on the evaluation machine.
- The web page with the technical information is ( was? ) completely cuckoo when viewed with Netscape 4.x or Mozilla. It's as slow as a wet week, and the information to read is stuck down in the corner in a truly miniscule font size. I'm being drenched in a black cloud rainstorm.
After all that I said to myself, "Umm... I think I'll carry on with PostgreSQL for the time being". Unfortunately for SAP AG time is still being.I have since got a more powerful machine with enough memory to at least try it out. When I've got a spare moment, I'll have another look at it. Spare moments are not exactly thick on the ground right now, so goodness only knows when that will happen.
SAP DB Rebuttal (semi official) (Score:5, Informative)
A. R/3 was originally written for Oracle, so this is a tradition. Up until now, SAP DB hasn't been marketed actively by SAP as not to upset it's many database selling partners. Newer applications are now developed for SAP DB first.
Q. SAP-DB is 20 years old. It has an unmaintainable code base. It is bloated and complex, very crufty internally and written in a weird pascal/C++ mix witha SAP specific format for the files and an uncomprehensible build system.
A. I prefer the word challenging. Parts of it are of course constantly rewritten, so I don't think a single part is actually 20 years old. And I object aliasing '!= make' with 'incomprehensible'. The concepts are actually pretty close to newer build systems like ant. Without it, the criticism would simply read that the make files are incomprehensible.
Q. SAP-DB needs a lot of effort to set up and create a database, sometimes even worse than the magic juju you need to go through with Oracle.
A. Not really true, especially not for a production database. But the entry level documentation could be made better by describing when and how to keep things simple.
Q. Oracle does replication and hot standby. SAP-DB doesn't. These are pretty important features in the enterprise.
A. Replication is not on our agenda (despite the oddly named Replication Manager). Hot standby is currently being implemented.
Q. Not in BSD Ports tree. Probably also goes for Linux, (but the argument there would probably be more "doesn't comes (integrated) with the distribution" If something gets included with distributions, it spreads much faster.
A. True. But our main job is to supply SAP DB for SAP customers. Anything else has to be done by others interested in SAP DB.
Q. harder to install, with a slightly strange mix of admin tools (combination of old/crufty, and new/experimental)
A. Partly a documentation problem. There isn't actually a mix of old and new admin tools. There is a command based API, which is accessible from various programming languages, and there are tools which are implemented on top of this API.
Q. definitely trickier to manage, as you need to learn protocols for setting up, and backing up, databases and their logs, at least. This is true of other RDBMSs of course, but the trend has been toward more self-managing systems.
A. SAP DB is mostly self managing. Some of the tasks were it isn't have severe performance implications (like distribution of data volumes over disks) so simply picking a default is questionable at best.
Q. Relies of ODBC as the cli--which is actually fine (eg, compatible with PHP) but still less familiar to Unix/OSS people
A. There is no standard database API for Unix. But of course anything would be better than a Microsoft API.
Q. Still undergoing stabilizing bugfix cycle, seemingly, although I haven't myself ever encountered a problem with it
A. Insert lame joke about Linux 2.4.
Q. Is, as mentioned, less tolerant of inexpert admins--and more problematic, the error codes are frequently impossible to understand
A. We should probably supply a tool which makes information about the error codes easily accessible from the command line.
Q. Really is difficult, at present, to hack. In general, the code is VERY challenging to work with (particularly the ugly, custom built build system), although it should be said that the SAP internal developers are steadily improving all aspects of the system, and a time WILL come when external developers can see rewards for their hacking efforts.
A. True. Although I still object to the notion that make was presented to mankind on the mount Sinai.
Q. Does SAP have anything close to Oracle's RMAN?
A. SAP DB logs all backups. The DBMGUI can use this log to automate tasks like 'restore from this full backup to this timestamp'. This works also with external backup tools.
Q. Sect Where's the O'Reilly book on SAP-DB?
A. It took some time for PostgreSQL to get books so I guess a SAP DB book is still a year or two away.
Q. Does it have Multi Concurrency Version Control (MVCC)?
A. It is implemented in the undocumented object database part. There are plans to make this also available to the relational database part, but a release date has not been set.
Q. Are there any Free Software success stories of projects using SAP-DB?
A. So far, SAP DB seems to appeal mostly to commercial software vendors for whom Oracle or MS licenses are too expensive/bothersome.
Q. Are there better admin tools?
A. No. Or not yet. But the administration is easily scriptable, so most common tasks can be reduced to a single command.
Re:Worm's eye view (Score:2)
How about Pick? (-: (Score:2)
I'd be interested in RainingData [rainingdata.com] (<span face=poker>now there's a truly inspired name change</span>) nee Pick GPLing their MultiValue database. Overall, a pig to use and maintain compared with something like PostgreSQL, but it still does some neat tricks and has a reasonable community around it.
Re:one more possible reason... (Score:3, Funny)
I guess if you cannot figure out how to open the tgz file in Windows, it is probably better that you are not trying to install SAP. Natural selection is a wonderful thing.
Re:SAP DB vs. Oracle (Score:3, Insightful)
Re:SAP DB vs. Oracle (Score:2)
When SAP/DB was Addabas it was one of the least popular commercial databases, and it run pretty counter to way everyone else it. To be honest aside for the multitude of SQL's there is Postgres and IBM -DB2, there just isn't need for an oddball database that is harder to program for than anything else.