Oracle's Infrastructure Now Fully Linux-ized

mbadolato writes "An article over at InformationWeek reports Oracle is aggressively adopting Linux both internally and for its products, despite SCO Group's threats earlier this week that it may sue those who don't pay licensing fees to the company. Chuck Rozwat, an Oracle executive VP, says the company has moved its IT infrastructure to Linux, a year after CEO Larry Ellis issued the mandate. In the coming year, Oracle will move its base development platform to Linux, including putting the open-source operating system on the workstations of 8,000 developers"

Comments

Ellis?

[Anonymous Coward]

Since when did Larry Ellison drop the last two letters of his last name? Come on, editors...

Half right

[Anonymous Coward]

There is precioius little Larry likes more than shoving his thumb into BillG's eye. But it makes perfect sense for them. The OS is free, and it runs nearly everywhere; you can see exactly what it's doing because you can see (and modify) the source code.

As a target platform for their software, it's perfect. Why run Oracle on Windows if you can use Linux on Intel? And if you don't want to spring for the expensive hardware, you aren't gonna use a proprietary Unix.

Nice, but...

[Tar-Palantir]

Could've happened to a nicer company. Ellison won one of the Golden Jackboot awards for pushing a national ID card system backed by Oracle databases. Here's the Google link for the stories.

Re:8000 developers?

[Permission Denied]

Could this have something to do with readline being GPL'd, and Oracle not wanting to release sqlplus under it?

Most likely.

The readline folks are real fanatics. They've continually denied requests to put readline under LGPL - they want to make sure the only things that use readline are GPLed. That is, they're doing this on purpose.

Because of this debacle, the *BSD camp was forced to come up with the editline library for all their stuff. And then you have stuff like Sun's dbx that has its own readline replacement. And Oracle's SQL client, and Sybase's isql, and sqsh, ....

Now, it's not quite trivial to write a readline replacement because you have to deal with all sorts of crufty, non-portable *nix terminal arcana, but it's also not difficult. The problem is that all readline replacements are incompatible with each other. You can customize readline applications through .inputrc - this is really cool because you can make one binding and it works in bash, gdb, your (GPLed) console mp3 player, etc. However, these bindings won't carry over to FreeBSD's cdcontrol program or Sun's dbx.

The GPL also means that I can't use readline for some program I write for a client because these programs are usually internal company things that the company owns and can license however they want - they won't pay me if I stipulate that the code I wrote (which belongs to them) must be licensed under GPL for such a trivial reason. Since my clients won't be too happy paying me to write stupid terminal IO routines, I'm forced to either use plain old fgets or use editline, which (IMHO) is not as nice as readline.

The fanaticism is costing the *nix community some useful functionality, which is kind of sad.

Oh stop your bellyaching.

[moogla]

Plenty of people
have gotten it to work

Re:has anyone implemented Oracle on Linux

[ziegast]

Have things changed?

A "few years ago" was the height of Sun's dot com bubble. If you wanted to run Oracle reliably, you bought Sun/Solaris/Sparc servers along with expensive storage hardware. Trying anything else was "risky". Compared to now, Linux was far more experimental. Oracle had just announced it was going to support Linux. Oracle's support for linux helped put companies like RedHat and VA Linux on the map. Early pioneers tried Oracle on Linux and bot burned. It's gotten alot better today now that Oracle doesn't have to keep chasing the moving target of the distribution du jour or kernel of the month to support their customers.

My biggest gripe about implementing Oracle on Linux is installation. Even with a generic RedHat Advanced Server install (one of their "supported" stable platforms), there are problems with with linking libraries or even just using unzip that just don't seem to make sense (should have been caught in QA). If you don't use their blessed commercial Linux OS distributions, you won't find any suppport from Oracle and scant support from the metalink user community. It helps if you know Unix/Linux enough to debug their shell scripts to figure out what's breaking.

Once we were done installation, our applications and databases ran similar Solaris systems (i.e. knowing how to make patches, managing backups, etc.). Our previously-Sparc-based DBA felt at home using the database tools on Linux. The best part is that our hardware and OS combined cost 25% comparable Sun hardware. We could afford to buy two servers and use the other as a cold backup. If we ever run out of memory, it's dirt cheap to buy more PC DDR SDRAM.

Now that Oracle is reportedly using Linux everywhere, perhaps they'll tune their installation process.

- a sysadmin

Re:8000 developers?

[farnsworth]

...and they still can't make an sqlplus client that supports readline.

Do you need sophisticated, automated input? Use sqlloader. Need sophisticated, automated output? Use rman. Need sophisticated, automated schema management? Use sqlplus.

Oracle comes with gobs of very powerful tools, and sqlplus is just not designed to do what you think it should be doing. It seems like you are trying to fit a square peg into a round hole. It's like complaining that climbing a fire escape is hard when you live on the third flool. Use the stairs.

BTW, if your doing SW development with oracle, use tora(free) or toad($$$). Both these tools make poking around and doing arbitrary queries a snap. Or, take your pick of the thousands of jdbc-based apps that live on sourceforge.

Re:MySQL/Oracle = Apple/Orange

[kcbrown]

The only way to edit a column definition is to delete it and readd it with the correct properties, which means taking the DB offline, copying the whole table to a temporary table, deleting the offending column, readding the column, and then moving all of the data back into the old table from the temporary one, and now since your columns are in a different order, you have to play fun games to get that to work right.. then you can delete the temporary table, and put the DB back online, PURE TORTURE.

You, sir, are full of shit. Witness (the output isn't exactly what you'd see because of the crappy lameness filter and the limited Slashdot HTML options):

kevin> \d
No relations found.
kevin> create table foo (x integer, y varchar(20), z float);
CREATE TABLE
kevin> insert into foo (x, y, z) values (2, 'hello', 20.5);
INSERT 16997 1
kevin> select * from foo;
x y z
2 hello 20.5
(1 row)

kevin> begin;
BEGIN
kevin> alter table foo add column z2 integer;
ALTER TABLE
kevin> update foo set z2 = z;
UPDATE 1
kevin> alter table foo drop column z;
ALTER TABLE
kevin> alter table foo rename column z2 to z;
ALTER TABLE
kevin> select * from foo;
x y z
2 hello 20
(1 row)

kevin> \d foo
Table "public.foo"
Column Type Modifiers
x integer
y character varying(20)
z integer

kevin> rollback;
ROLLBACK
kevin> \d foo
Table "public.foo"
Column Type Modifiers
x integer
y character varying(20)
z double precision

So: not only can you do the operation without taking the database down, you can do it while within a transaction, and even rollback the entire change if you screw up!

This is under PostgreSQL 7.3.3.

Try that with your vaunted MySQL.

Re:MySQL/Oracle = Apple/Orange

[m_ilya]

It is not that painless. We usually do in our db migration scripts:

1. start transaction
2. rename existing table
3. create a table with new table definition
4. copy data from old table to new
5. drop old table
6. commit transaction

Works well for any table definition changes. Doesn't require taking the DB offline. Doesn't change order of columns unless you want it.

Re:Ok troll I will bite

[kcbrown]

We have been running postgresql for about 3 years in a production environment. The problem with postgresql is that number one it does not scale worth a shit. Number two it cannot be kept online 24/7 that in itself is some major faults. I run a system with databases consisting of simple data only about 15 million records or so. If we load on more than about 20 simultaneous users is slows to a grinding halt.

It seems that people's experiences vary on this. Certainly your complaints were valid in the pre-7.0 days, but PostgreSQL has improved an amazing amount since then, especially after the introduction of 7.2. The current stable version is 7.3.4, and 7.4 is right around the corner.

Much of the scalability issue you mention has to do with the default settings regarding shared memory, buffers, etc. The PostgreSQL developers have been very conservative about the defaults, because they want the database to run on the widest range of hardware possible. Unfortunately that leads to a "least common denominator" approach and the end result is a database that out of the box performs suboptimally on most systems in order to run on almost all of them.

But if you change the tunable parameters to values that are much closer to the actual hardware you're running the database on, the performance increases a great deal.

Some people have gotten very good scalability out of PostgreSQL as a result. I'm sure you're aware of the PHPBuilder article that talks largely about the scalability issues. That was written some time ago, and PostgreSQL has gotten quite a lot better since then.

It doesn't work for everyone. MySQL has the advantage of having a rudimentary replication mechanism out of the box, and its full-text indexing is much easier to set up and use. It's also much easier to upgrade between major versions (PostgreSQL requires that you dump and restore if you're upgrading to a new major version, e.g. 7.3 -> 7.4). But in the general case, PostgreSQL seems to me to be a much more capable database than MySQL is.

I don't know of any other database, commercial or otherwise, that allows you to write stored procedures in Perl, Python, or TCL. That alone might be worth the few tradeoffs.

If you're running a relatively old (7.1 or earlier) version of PostgreSQL, you might want to give 7.3.4 a try. You might be pleasantly surprised.

Heard that PeopleSoft will be running on Linux

[BlackListedCard]

I've heard that PeopleSoft will be the next big guy to run their products under the Linux environment. Better development platform to make changes to their product. Can anyone confirm?