The earliest version of PostgreSQL with which Slony-I is compatible is version 7.3.3. That's because Slony-I needs namespace support, which didn't really solidify until then.
Rod Taylor has reported that he "hacked together" a version for 7.2, but the only way I'd be inclined to use that is if I was paying Rod to set it up...
When I did upgrades of 7.2 systems to 7.4, I used eRServer, a Java-based replication system from which Slony-I inherited many of its design ideas. (The name "Slony" is a conscious nod to Vadim Mikheev, one of the main creators of erServer...)
I'll have to add documentation on how one would do this to the Slony-I FAQ...
We did some benchmarking of the behaviour of a Sun disk array for PostgreSQL; couldn't see a significant difference between having a separate "little array" and folding it into a bigger one.
What seemed to be of value was to put WAL onto a separate array simply out of the knowledge that those disks would get burned through faster, and we'd know they would have a higher replacement incidence.
What I'd like to do to fix that is to have a few GB of SSD, where heavy writes wouldn't hurt any disks.
But once you have a smart enough controller with battery backed cache, how the disks are physically configured gets less and less important.
Seeing as he had time to prepare, the paucity of articulation of concrete benefits of Ingres suggests that there's no story to tell.
I have long heard stories about the query optimizer being better than anything else out there; if there's only faint truth, it's still worth mentioning.
He certainly had a chance to mention any features he wanted to point out. That's a marketer's job, isn't it?
In the absence of that, and considering that there sure appear to be some, this suggests to me that Ingres has gone "to the place where software goes to die."
The way I'd love to see them used is as a cheaper way of doing "SSD."
The common way to do SSD is thus:
Have CPU and a whack of RAM that pretend to be a disk
Need small battery to preserve RAM state if power goes out
Need big battery to support dumping RAMdisk state onto a disk drive if power goes out
Flash (of whatever variety) allows this to get lower powered, because the system reduces to:
RAM + CPU as before
Flash device to preserve data if the power goes off
Battery to keep RAM + CPU + Flash device going long enough to finish dumping data
Data only needs to be written out to the flash device when power goes off , so the only reason to be worried about the lifetime of the flash part is if you expect to have tens of thousands of power outages to cope with.
If you're having that many power outages, it'll probably be the power supplies blowing up first, as they probably don't have tens of thousands of cycles in them:-).
MySQL and PostgreSQL are really no different than debating linux distrubutions
No, the differences are quite consequential, much more like differences between Linux and (say) Windows.
Consider:
PostgreSQL is developed as a community project. Some developers are sponsored by companies, much as is the case with most projects in the "open source community," but the results are essentially publicly owned.
MySQL(tm) is none of the above; it is, altogether, a proprietary system closely held by a single small company, where all the developers are the employees of that company. There are, therefore, all the risks associated with the product being closely held.
When you look at different Linux distributions, they are deeply similar because probably well over 90% of the source code is plucked from the very same "rivers" of projects. All the distributions use some version of Linux, GCC, GLIBC, Perl, Python, Apache, GNOME, KDE, and such.
Distributions have persistent differences in the form of installation tools, but that's a small portion of the system.
The technologies are really hugely different, as are the attitudes of the respective development "communities" towards relational database technology.
The PostgreSQL team has a clear respect for the SQL standards, and prefer very much to conform to SQL standards. The MySQL implementors have had to be dragged, pretty much kicking and screaming, towards promising that they'll conform with ANSI some day. (Of course, that's likely to still have plenty of documented flaws.)
I have done some work on pg_autovacuum, but have been not entirely thrilled with it, and, furthermore, am really not thrilled with the integration with the backend.
We have numerous servers that run a bunch of backends (so that each one has its own cache; ARC in 8.0 may relieve that need somewhat), and something we don't want is to have big vacuums chewing up I/O bandwidth on multiple backends concurrently.
I'd much rather have a "user space" daemon, so to speak, that can manage vacuums for multiple backends.
This also has much the same merit of having things run in user space rather than in the Linux kernel. It's much easier and safer to write user space code because it's not sitting in the kernel, where a single bad pointer reference can trash the system.
The architecture I'm thinking of is to have
A "queue" of tables and databases needing vacuuming
A process that checks activity on pg_class and pg_database to find work
Something analagous to a crontab indicating both tables that the DBAs know should either be frequently vacuumed, or never vacuumed
The "queue" would serialize the activity, thereby limiting the degree to which vacuuming would injure overall system activity, across all instances.
With 8.0, there's actually two ways that this becomes better still...
The ARC revisions means that vacuums don't trash buffer caches
There's a "sleepy vacuum" thing that was almost added to 7.4 where you can set vacuums to sleep a few milliseconds every few blocks.
That cuts the I/O consumption of vacuums.
That resolves the two things that were badly wrong with vacuuming too much.
Building this "Nothing Sucks Like A VAX" vacuum system, will, however, have to wait 'til I get the set of Slony-I configuration tools fully up to "production desires" as well as doing the Next Generation Replication Monitor...
Re:Does the on-disk format still change at every r
on
PostgreSQL 8.0 Enters Beta
·
· Score: 3, Informative
They change the format because it it is necessary in order to implement the new features that they are adding in.
One of the points of Slony-I is to provide an answer to this very problem. Slony-I supports versions 7.3, 7.4, and 8.0, and may be used to support a short-outage upgrade path.
Suppose you have a 7.3 database, and want an 8.0 one. You set up replication between the 7.3 database and the new 8.0 one. It may take a couple of days for the new one to get up to date, but you don't have to shut the 7.3 one down.
Once the databases are more or less in sync, you do a MOVE SET to change the "master" to be the 8.0 database. Since they are nearly in sync, this should only take a few seconds. Presto! The 8.0 database is the "master," and you can switch over to it with whatever brief outage is needed to get your application to point to a new server.
The fact that MySQL AB is a small company that entirely controls the source code base for their product strikes me as being a downright enormous business risk.
The changes away from friendliness of licensing towards users of free software that have taken place over the last year is a pretty clear demonstration of that business risk.
It would surprise me not at all if the venture capital folks decided that MySQL Version 5 would ultimately not be released in an "open source" form (once the alpha testing is done). After all, they have to get something back on their investment, and giving away licenses for free isn't a traditional VC-approved "business model."
If you think that's off, I'll amiably go along with the thought that elimination of the "open source" version might wait until they get enough functionality in that they can pitch it as an alternative backend to Oracle for SAP customers...
The problem with NULL values is that they wind up weakly doing too many things all at once, and not being implemented consistently, even within a single SQL implementation.
They're sort of like zero, except that there are already perfectly good notions of zero there to use already.
For instance, MySQL generally takes the approach is that NULL is "zero," and typically can't tell the difference between the two.
Alternatively, NULL indicates that something is "unknown."
It would be reasonable to interpret, from that, that any time a NULL enters into a calculation, it should be treated as a "contagion" that makes the result unknown.
Thus, if field "quantity" contains any nulls, then select sum(quantity) from some_table should return NULL .
The fact that these two treatments are not used consistently either within or across products means that the use of NULLs tends to make it difficult to predict application behaviour.
The more you use NULLs, the more trouble they tend to cause.
From what I can see, what has happened in most cases thus far is that distributions have stalled at/reverted to XFree86 4.3; they have not yet started installing the x.org codebase.
For instance, Debian is still running XFree86 4.3.
Well, this means that you've got something that amounts to a [rough] equivalent to yesteryear's M68030, which was nicely up to running Real UNIX(tm) (none of this 'ucLinux' stuff), but which is, price-wise and other-glue-wise, equivalent to the previous ColdFire series.
It may not add massive functionality, but if it allows building more reliable systems, due to use of MMU, that seems hardly a bad thing.
We've got a barrel of E450's that are incredibly stable. Power outages are the reason they go down, and they get pretty abused by QA activities.
(It used to be that the DB servers were bottlenecks, so they were groaning under the strain; with some significant upgrades, the application servers become bottlenecks...)
I don't feel anywhere near as confident about any of the newer boxes...
Reliability of their big systems isn't what it should be. I know I have seen an uncomfortable number of crashes of big, expensive servers that ought not to crash.
Everybody isn't reporting it because it's embarrassing to have spent a million bucks and gotten a "lemon."
Next year's hardware budget will likely go to their competitors around where I am; if that happens pretty widely, that will pinch Sun pretty badly.
Probably the most effective thing to do with Java would be to put effort into refining the quality of the existing systems. Making it better, faster, and more reliable without touching the APIs strikes me as a good approach. Improvements that avoid becoming a "money pit" for either Sun or users of Java would be a good thing...
Because it would suffer from two problems, not just one:
It wouldn't be a native OS-X application, using Aqua/Quartz/such;
It more than likely was a Motif app on Solaris, and it's not obvious that that's readily deployable on OS-X without deploying a bunch of other software.
But you're certainly right about the rest; Solaris could readily be a bigger market for FM than MacOS.
Backplane has all of the licensing downsides to MySQL; it looks as though they have taken their policies direct from MySQL AB. And where MySQL has been able to get a cycle of "bait and switch" in to hook people on the product before hitting them up with the real license, Backplane has been quite up front about the product being intended as a "we charge you if you use it" one, which will certainly discourage people from donating free effort to it.
It's an interesting system in that it is really quite different from all the other SQL databases.
Unfortunately, as you suggest, its approach is quite opposite to being relational. It would be interesting to see something based on Tutorial D. There are a couple of projects on SourceForge, but neither are at all useful at this stage. The appropriate approach would probably be to implement a Tutorial D language atop PostgreSQL. After all, that's the approach Dataphor takes; it implements D4 atop Oracle or DB/2.
They should have better warnings about it...
on
FreeBSD 5.2 Released
·
· Score: 1
"If the FreeBSD team could get away with it, they would probably use warnings like "Contains live plague bacteria. Beware the Rabid Hippopotami. May cause nausea and vomiting."
In addition, there are actually functioning 64 bit chips and 64 bit operating systems running on PPC. (AIX being notable; I'm not certain whether or not Linux or *BSD do 64 bits on appropriate generations of PPC yet..)
What if the Chinese government handled this "honestly," blocking actual spam producers. It seems more than likely that there honestly are a bunch of "spam producers" in Taiwan.
I'm not being ironic; I'm not being snide; I'm quite certain that there are a bunch of spam servers in that part of the world, and it would be totally unremarkable for the Chinese regime to, well, yes, gleefully block them.
If they really are "spam servers," then there's little way for this to do other than reflect reasonably well on the Chinese regime.
Note also that if some of the spam servers are, ahem, "politically motivated," that doesn't prevent the messages that they are sending from being, well, pointless spam.
Whatever side I might be on in such political conflagrations as the "Abortion Issue," the "Homosexual Agenda" (or lack thereof), whether or not SUVs are the coming saviors of the world economy or agents of its impending destruction, Bush's New World Order, Clinton's Previous New World Order, the politically motivated messages that get sent out by mindless advocates on all sides of those sorts of issues are, as far as I am concerned, worthless spam.
That includes messages from the ones I might imagine I agree with, by the way.
It is not at all obvious that Taiwanese propaganda is "not spam" by virtue of being politically motivated against the Chinese regime...
It means that you have to have some (likely heuristic) process that rummages around for metadata.
For instance, those MP3 files are quite likely to have ID3 tags assigned to them, indicating the artist, album, track number, and possibly even the name of the song.
It is easy enough to look at a file using /usr/bin/file and say: That looks like an MP3 file! Why don't I extract ID3 tags by running id3 -l on it?
There is quite a lot of information that can be gotten by running stat and file , and if you have further actions to take for some set of document formats (MP3, OggVorbis, PNG, GIF, JPeg, MS Office formats, OpenOffice.org formats, HTML, and some others), you can probably get a significant amount of useful metadata in a totally automated manner.
SQL is only slower if you have written your applications in a manner that use it badly.
That means that you have written an application which submits vast numbers of "network model" (not unlike CODASYL) queries to navigate through the data.
Journalling of filesystems is no panacea; it is about as easy to lose a filesystem as it is to lose a database.
If Mongol hordes ravage your server room, putting sword to the disk arrays, it makes no difference whether you are structuring your data using filesystems or using databases.
If your filesystem becomes corrupt, you also lose everything.
And how does that meta data gets to the db? Oh, right, it will rely on file extensions and other hacks:)
Perhaps in "Version 0.1."
It makes a lot of sense to put a fair bit of analysis into this, in the longer term, particularly if there is some intent to draw in some "full text search" information.
Thus, rather than assuming that.mp3 indicates MP3 data, it would be sensible to use /usr/bin/file to ascertain that the file signature is MP3 file with ID3 version 2.3.0 tag , and then use an MP3-specific tool to pull out the ID3 tags and store them in the database.
Similarly, if file finds that a file is a PDF of some version number, it should store that version number. If it finds a GIF with some particular resolution, or TIF tags, it should store that.
Heuristics will go a long way here; if there is heuristic logic for handling MP3s, PDFs, common graphics formats, HTML, DocBook SGML/XML, documents generated using Word, Excel, PowerPoint, OpenOffice.org, that can draw a LOT of useful metadata into the database.
I had to look up his name, as I didn't recall it offhand:-).
The point is, nonetheless, serious, if a little bit off topic. This story (Microsoft using R/3 on OS/400) is exactly the sort of thing that it is convenient for Microsoft to see disappear from the web.
University students that leap into a world where they think all research can be done on the Web have some Serious Risks in that not only can't you guarantee that things written are necessarily the truth, but you also can't guarantee that they will remain available as knowledge.
Paper records can't get rm -rf/* ed out of existence; since they have to get distributed to each site they are accessed at, it is much tougher to expunge them than data that might sit only on one server. A US law might mandate burning all copies of "Journal of Foo, Volume 27, Issue 3," but that won't forcibly affect copies in other countries...
It is NOT "a software package;" the "collection of programs" you are alluding to is not called "SAP," but rather R/3 . Recently, they have also been hawking a sort of "distribution" under the name MySAP, but that does not change that "SAP" is the name of the company.
As to the "runs best on Oracle," I don't think one can readily distinguish whether there is actually any technical merit to that or whether it's a marketing ploy that SAP, Oracle, and consultants all agree is in their interests to believe...
Slashdot Mirror
The earliest version of PostgreSQL with which Slony-I is compatible is version 7.3.3. That's because Slony-I needs namespace support, which didn't really solidify until then.
Rod Taylor has reported that he "hacked together" a version for 7.2, but the only way I'd be inclined to use that is if I was paying Rod to set it up...
When I did upgrades of 7.2 systems to 7.4, I used eRServer, a Java-based replication system from which Slony-I inherited many of its design ideas. (The name "Slony" is a conscious nod to Vadim Mikheev, one of the main creators of erServer...)
I'll have to add documentation on how one would do this to the Slony-I FAQ ...
The slick part isn't having a huge battery, but rather having a form factor that's similar enough to plain old disks.
What I'd love to see is the combination of:
- A bunch of RAM,
- Enough Compact Flash to cover all of the contents of RAM
- Enough battery to give enough time to serialize the cache to CF if power dies
Long battery life isn't necessary; you just need long enough to write it all out to CF.And yes, 1-2GB would be enough to be immensely useful.
What seemed to be of value was to put WAL onto a separate array simply out of the knowledge that those disks would get burned through faster, and we'd know they would have a higher replacement incidence.
What I'd like to do to fix that is to have a few GB of SSD, where heavy writes wouldn't hurt any disks.
But once you have a smart enough controller with battery backed cache, how the disks are physically configured gets less and less important.
It wasn't as "cool" a universe as Known Space, but it was one with characters that were way more "human."
I have long heard stories about the query optimizer being better than anything else out there; if there's only faint truth, it's still worth mentioning.
He certainly had a chance to mention any features he wanted to point out. That's a marketer's job, isn't it?
In the absence of that, and considering that there sure appear to be some, this suggests to me that Ingres has gone "to the place where software goes to die."
The common way to do SSD is thus:
- Have CPU and a whack of RAM that pretend to be a disk
- Need small battery to preserve RAM state if power goes out
- Need big battery to support dumping RAMdisk state onto a disk drive if power goes out
Flash (of whatever variety) allows this to get lower powered, because the system reduces to:- RAM + CPU as before
- Flash device to preserve data if the power goes off
- Battery to keep RAM + CPU + Flash device going long enough to finish dumping data
Data only needs to be written out to the flash device when power goes off , so the only reason to be worried about the lifetime of the flash part is if you expect to have tens of thousands of power outages to cope with.If you're having that many power outages, it'll probably be the power supplies blowing up first, as they probably don't have tens of thousands of cycles in them :-).
No, the differences are quite consequential, much more like differences between Linux and (say) Windows.
Consider:
MySQL(tm) is none of the above; it is, altogether, a proprietary system closely held by a single small company, where all the developers are the employees of that company. There are, therefore, all the risks associated with the product being closely held.
Distributions have persistent differences in the form of installation tools, but that's a small portion of the system.
The PostgreSQL team has a clear respect for the SQL standards, and prefer very much to conform to SQL standards. The MySQL implementors have had to be dragged, pretty much kicking and screaming, towards promising that they'll conform with ANSI some day. (Of course, that's likely to still have plenty of documented flaws.)
We have numerous servers that run a bunch of backends (so that each one has its own cache; ARC in 8.0 may relieve that need somewhat), and something we don't want is to have big vacuums chewing up I/O bandwidth on multiple backends concurrently.
I'd much rather have a "user space" daemon, so to speak, that can manage vacuums for multiple backends.
This also has much the same merit of having things run in user space rather than in the Linux kernel. It's much easier and safer to write user space code because it's not sitting in the kernel, where a single bad pointer reference can trash the system.
The architecture I'm thinking of is to have
The "queue" would serialize the activity, thereby limiting the degree to which vacuuming would injure overall system activity, across all instances.
With 8.0, there's actually two ways that this becomes better still...
That cuts the I/O consumption of vacuums.
That resolves the two things that were badly wrong with vacuuming too much.
Building this "Nothing Sucks Like A VAX" vacuum system, will, however, have to wait 'til I get the set of Slony-I configuration tools fully up to "production desires" as well as doing the Next Generation Replication Monitor ...
One of the points of Slony-I is to provide an answer to this very problem. Slony-I supports versions 7.3, 7.4, and 8.0, and may be used to support a short-outage upgrade path.
Suppose you have a 7.3 database, and want an 8.0 one. You set up replication between the 7.3 database and the new 8.0 one. It may take a couple of days for the new one to get up to date, but you don't have to shut the 7.3 one down.
Once the databases are more or less in sync, you do a MOVE SET to change the "master" to be the 8.0 database. Since they are nearly in sync, this should only take a few seconds. Presto! The 8.0 database is the "master," and you can switch over to it with whatever brief outage is needed to get your application to point to a new server.
The fact that MySQL AB is a small company that entirely controls the source code base for their product strikes me as being a downright enormous business risk.
The changes away from friendliness of licensing towards users of free software that have taken place over the last year is a pretty clear demonstration of that business risk.
It would surprise me not at all if the venture capital folks decided that MySQL Version 5 would ultimately not be released in an "open source" form (once the alpha testing is done). After all, they have to get something back on their investment, and giving away licenses for free isn't a traditional VC-approved "business model."
If you think that's off, I'll amiably go along with the thought that elimination of the "open source" version might wait until they get enough functionality in that they can pitch it as an alternative backend to Oracle for SAP customers...
- They're sort of like zero, except that there are already perfectly good notions of zero there to use already.
- Alternatively, NULL indicates that something is "unknown."
The fact that these two treatments are not used consistently either within or across products means that the use of NULLs tends to make it difficult to predict application behaviour.For instance, MySQL generally takes the approach is that NULL is "zero," and typically can't tell the difference between the two.
It would be reasonable to interpret, from that, that any time a NULL enters into a calculation, it should be treated as a "contagion" that makes the result unknown.
Thus, if field "quantity" contains any nulls, then select sum(quantity) from some_table should return NULL .
The more you use NULLs, the more trouble they tend to cause.
From what I can see, what has happened in most cases thus far is that distributions have stalled at/reverted to XFree86 4.3; they have not yet started installing the x.org codebase.
For instance, Debian is still running XFree86 4.3.
It may not add massive functionality, but if it allows building more reliable systems, due to use of MMU, that seems hardly a bad thing.
(It used to be that the DB servers were bottlenecks, so they were groaning under the strain; with some significant upgrades, the application servers become bottlenecks...)
I don't feel anywhere near as confident about any of the newer boxes...
Reliability of their big systems isn't what it should be. I know I have seen an uncomfortable number of crashes of big, expensive servers that ought not to crash.
Everybody isn't reporting it because it's embarrassing to have spent a million bucks and gotten a "lemon."
Next year's hardware budget will likely go to their competitors around where I am; if that happens pretty widely, that will pinch Sun pretty badly.
Probably the most effective thing to do with Java would be to put effort into refining the quality of the existing systems. Making it better, faster, and more reliable without touching the APIs strikes me as a good approach. Improvements that avoid becoming a "money pit" for either Sun or users of Java would be a good thing...
- It wouldn't be a native OS-X application, using Aqua/Quartz/such;
- It more than likely was a Motif app on Solaris, and it's not obvious that that's readily deployable on OS-X without deploying a bunch of other software.
But you're certainly right about the rest; Solaris could readily be a bigger market for FM than MacOS.It's an interesting system in that it is really quite different from all the other SQL databases.
Unfortunately, as you suggest, its approach is quite opposite to being relational. It would be interesting to see something based on Tutorial D. There are a couple of projects on SourceForge, but neither are at all useful at this stage. The appropriate approach would probably be to implement a Tutorial D language atop PostgreSQL. After all, that's the approach Dataphor takes; it implements D4 atop Oracle or DB/2.
"If the FreeBSD team could get away with it, they would probably use warnings like "Contains live plague bacteria. Beware the Rabid Hippopotami. May cause nausea and vomiting."
-- Michael Lucas, re: FreeBSD-CURRENT
In addition, there are actually functioning 64 bit chips and 64 bit operating systems running on PPC. (AIX being notable; I'm not certain whether or not Linux or *BSD do 64 bits on appropriate generations of PPC yet..)
What if the Chinese government handled this "honestly," blocking actual spam producers. It seems more than likely that there honestly are a bunch of "spam producers" in Taiwan.
I'm not being ironic; I'm not being snide; I'm quite certain that there are a bunch of spam servers in that part of the world, and it would be totally unremarkable for the Chinese regime to, well, yes, gleefully block them.
If they really are "spam servers," then there's little way for this to do other than reflect reasonably well on the Chinese regime.
Note also that if some of the spam servers are, ahem, "politically motivated," that doesn't prevent the messages that they are sending from being, well, pointless spam.
Whatever side I might be on in such political conflagrations as the "Abortion Issue," the "Homosexual Agenda" (or lack thereof), whether or not SUVs are the coming saviors of the world economy or agents of its impending destruction, Bush's New World Order, Clinton's Previous New World Order, the politically motivated messages that get sent out by mindless advocates on all sides of those sorts of issues are, as far as I am concerned, worthless spam.
That includes messages from the ones I might imagine I agree with, by the way.
It is not at all obvious that Taiwanese propaganda is "not spam" by virtue of being politically motivated against the Chinese regime...
For instance, those MP3 files are quite likely to have ID3 tags assigned to them, indicating the artist, album, track number, and possibly even the name of the song.
It is easy enough to look at a file using /usr/bin/file and say: That looks like an MP3 file! Why don't I extract ID3 tags by running id3 -l on it?
There is quite a lot of information that can be gotten by running stat and file , and if you have further actions to take for some set of document formats (MP3, OggVorbis, PNG, GIF, JPeg, MS Office formats, OpenOffice.org formats, HTML, and some others), you can probably get a significant amount of useful metadata in a totally automated manner.
That means that you have written an application which submits vast numbers of "network model" (not unlike CODASYL) queries to navigate through the data.
If Mongol hordes ravage your server room, putting sword to the disk arrays, it makes no difference whether you are structuring your data using filesystems or using databases.
The only answer to this involves doing BACKUPS.
Perhaps in "Version 0.1."
It makes a lot of sense to put a fair bit of analysis into this, in the longer term, particularly if there is some intent to draw in some "full text search" information.
Thus, rather than assuming that .mp3 indicates MP3 data, it would be sensible to use /usr/bin/file to ascertain that the file signature is MP3 file with ID3 version 2.3.0 tag , and then use an MP3-specific tool to pull out the ID3 tags and store them in the database.
Similarly, if file finds that a file is a PDF of some version number, it should store that version number. If it finds a GIF with some particular resolution, or TIF tags, it should store that.
Heuristics will go a long way here; if there is heuristic logic for handling MP3s, PDFs, common graphics formats, HTML, DocBook SGML/XML, documents generated using Word, Excel, PowerPoint, OpenOffice.org, that can draw a LOT of useful metadata into the database.
The point is, nonetheless, serious, if a little bit off topic. This story (Microsoft using R/3 on OS/400) is exactly the sort of thing that it is convenient for Microsoft to see disappear from the web.
University students that leap into a world where they think all research can be done on the Web have some Serious Risks in that not only can't you guarantee that things written are necessarily the truth, but you also can't guarantee that they will remain available as knowledge.
Paper records can't get rm -rf /* ed out of existence; since they have to get distributed to each site they are accessed at, it is much tougher to expunge them than data that might sit only on one server. A US law might mandate burning all copies of "Journal of Foo, Volume 27, Issue 3," but that won't forcibly affect copies in other countries...
It is NOT "a software package;" the "collection of programs" you are alluding to is not called "SAP," but rather R/3 . Recently, they have also been hawking a sort of "distribution" under the name MySAP, but that does not change that "SAP" is the name of the company.
As to the "runs best on Oracle," I don't think one can readily distinguish whether there is actually any technical merit to that or whether it's a marketing ploy that SAP, Oracle, and consultants all agree is in their interests to believe...