Lessee... RedHat buys JBoss, something Oracle wants. Red Hat needs Oracle way more than Oracle needs RedHat. Oracle's wanted to commoditize OS's forever -- hence Oracle is the same everywhere. Same libraries, same APIs, same interfaces. Oracle wants their own Linux distro to simplify their own support challenges and to more effectively compete with Redmond in the x86 space.
Suddenly RedHat takes one in the neck to the tune of a billion dollars. Suddenly RedHat's way cheaper if he decides to buy it, and if he doesn't, he's managed to cripple a company that he perceives as a competitor.
Who here wasn't surprised by this?
Fucketh not with Larry Ellison, for he has the political and financial will to break everyone but Microsoft and IBM. Hell, I think he rather enjoys exercising it.
Copy the data? Why would you want to do that? It's already on the network somewhere, assuming it's not a JBOD internal storage architecture. And if it is, why bother upgrading it? It's a toy system.
Further, if your database is web-facing and a driver of revenue but isn't highly available -- clustered, RAC'd, gridded, or what have you -- whoever architected that system has earned a pink slip.
Certs are important to your bosses, because they're able to bill higher rates depending on the alphabet soup on your resume.
Such billing differentials may or may not roll down to your salary.
They're only important to you as a CONsultant because you're less likely to have to burn bench time if you've got more certs, because you can be placed in different roles on different projects.
1. Ensure the database layer is a parallelizeable RDBMS that has a concurrent access mechanism and is running on a multicore/multiCPU box.
2. Grid/Parallelize the application layer -- i.e., ensure you can run parallel jobs with discrete data.
3. If that doesn't help, then grid the database layer.
If your application isn't built to scale today -- see the second point -- all the grid in the world won't help you.
I agree with you that it sounds like the code needs some optimization -- 10-30 minutes to process is 5 to 15 trades per second, and that's ridiculously slow. One thing you haven't addressed is the I/O subsystem -- if you're using crappy disk in a I/O intensive batch system, it can kill you. If you were to move to a grid, you'd have to move to some sort of SAN/NAS in order for your application to function. Of course, you can move to a SAN/NAS without being on a grid or in a cluster.
Oracle's got lots of performance diagnostic tools to help you determine what's going on between the time the app makes a database call and the app gets control back, if that's what you're running. Okay, only one really good one (extended SQL trace), but it's really good. If you're running Oracle, get a trace or a statspack report of one of your batch runs to try to determine what the performance issue is before you spend any money chasing an architectural solution.
There's nothing in the Constitution itself that says people are suppose to vote for senators or presidents.
Incorrect.
While the Constitution originally left the selection of electors for president and U.S. Senators as a responsibility of the legistatures of the states, Amendment XVII (1913) mandates that Senators are to be "elected by the people thereof." It may not have been put there by the Framers, but it's there now.
And I tend to disagree with your contention that a Senator should be able to be "called on the carpet" for not voting according to the will of the people. That's what we have elections for -- if a Senator failed to exercise the will of the Legislature that selected it, I'm sure the Legislature would collect in due time. Until then, that responsibility is the Senator's to discharge.
Micromanagement doesn't work for techies -- what makes you think it works better for politicians?
Doing it that way everywhere would certainly yield an electoral college result that is significantly more representative of the collective will of each state's voters.
Further, the electors of the electoral college are representatives of the various states, and therefore state laws govern their actions. You'd need a constitutional amendment to change that, and all bets are off if that happens.
Remember -- you don't vote for President. Your state does. Tradition may argue otherwise, but "each state shall appoint, in such manner as the Legislature thereof may direct, a number of electors..." That's the law, and it's one of those big nasty constitutional ones.
I would counter that the ratio of testosterone to estrogen -- i.e. environmental factors -- would determine how a stem cell would express itself. That's exactly what happens during gestation -- various hormone levels determine vocal pitch.
All humans are conceived bisexed or hermaphroditic -- it's what the sex chromosomes do during gestation that makes the difference.
http://www.straightdope.com/classics/a1_093.html
Reporter: "After all that you've just gone through, I have to ask you the same question a lot of people back home are asking about space these days. Is it worth it? Should we just pull back, forget the whole thing as a bad idea, and take care of our own problems, at home?"
Sinclair: "No. We have to stay here, and there's a simple reason why. Ask ten different scientists about the environment, population control, genetics - and you'll get ten different answers. But there's one thing every scientist on the planet agrees on: whether it happens in a hundred years, or a thousand years, or a million years, eventually our sun will grow cold, and go out. When that happens, it won't just take us, it'll take Marilyn Monroe, and Lao-tsu, Einstein, Maruputo, Buddy Holly, Aristophanes - all of this. All of this was for nothing, unless we go to the stars."
Oracle wants an OS that runs on commodity (x86) hardware, so that it can publish a virtual machine with Oracle preconfigured. (Reference the Oracle appliance of days of yore.)
Why?
Because virtualization is hot in databases. Having lots of servers spinning idle that you may need (and paying Oracle for the privilege) is costly, and Larry sees market share, well, if not eroding, then certainly being nibbled at. By shipping a distro with Oracle preconfigured, he:
1. Shows a commitment to his customers for a lower TCO. (Remember, the amount of time the IT staff spends installing and working through issues with the software stack counts.) 2. Punches SQL Server in the mouth. 3. Takes more control of his destiny by being able to more effectively tune the OS for database tasks, yielding better performance and price-performance in things like TPC-C and TPC-H.
Oracle needs to use a Linux distro that has traction within the data center, and in the US, that's either Novell (SuSE) or Red Hat. Those are the only distros officially supported by Oracle now, which probably helps to explain their traction within the data center.
Oracle will buy one. It's just a matter of which one.
And if I were RedHat's CEO, I'd be really careful pissing off Larry. It's not like Larry's afraid to, I don't know, buy your company so he can fire your ass. *cough*Siebel*cough*
If you're running a medium to large system on the mainframe, it's very likely that you do use partitioning. Otherwise purging data, backing up data, or searching through billion-row indexes is not going to be as performant as possible.
Performance is often achieved by writing to the low-level. Generic code and generic SQL performs... generically.
And as someone who's ported commercial software between DB2 z/OS, DB2 LUW, and Oracle, I can tell you that the "slightly different" code is not so "slight" when you're actually elbows deep in it. The devil is in the details, and that 1% you so blithely dismiss can chomp down quite firmly on your backside when you least expect it.
Oracle Server is Oracle Server regardless of where you implement it -- Windows, Unix, or OS/390. I agree that there are differences in the kernel code and the process model (used on Unix) versus the thread model (used on Windows). However, those are not differences that are relevant to the users -- the same initialization parameters and SQL syntax apply regardless of platform.
DB2 is not DB2 regardless of where you implement it.
You can migrate an Oracle database from z/OS to z/Linux with import/export. You cannot migrate a DB2 database from z/OS to z/Linux without possibly having to redesign and reimplement various schema objects.
That's a significant difference, and it's one that causes lots of heartburn for those of us who maintain applications that support multiple databases. You figure you'd only need two database code lines -- one for Oracle, one for DB2. However, you need three -- one for Oracle, one for DB2, and one for DB2 UDB.
However, for non-production systems -- generally dev, test, and qa environments -- the use of VMware for both Windows and Linux is hot-hot-hot. Those platforms are generally woefully underutilized, where the utilization numbers are on the order of 5-10% during the working day, lower during off hours.
Collapsing several system's environments like that into a single VMware server can save lots and lots of money paid for :
Systems Data Center Space Data Center Operating Costs
Besides, I remember having seen something about all the VMWare releases except for the top-of-the-line one being more or less free now.
1. Reference the remote table directly. 2. Set up replication to continuously replicate the tables at the remote database to the local database. 3. Use import/export (or impdp/expdp) to create a dump file which is portable cross-os and cross-release. 4 Issue "create table X as select * from X@otherdb;"... but I'm guessing anything that might require reading the documentation will be considered way too hard for the GP.
Oracle is a big, complicated piece of software. If the GP wants toy software, well, he knows where to find it.
DB2 also runs on the mainframe -- you know, OS's like OS/390 and z/OS. That DB2 -- which is the one most people mean when referring to DB2 unless they say DB2 UDB -- is from a completely different code base, and works very, very differently. Little things like "the number of columns that can constitute a unique index" and "how partitioning works" differ wildly between the two DB2 "Universal Database" implementations. So if you want to move databases off z/OS onto a z/Linux partition or onto AIX, well, you really can't. Certainly not simply and easily. (There used to be three code lines for DB2, but they finally renamed DB2 for AS/400 to DB/400.)
However, Oracle Server has the same implementation rules -- columns per key, block sizes, how partitioning works -- on every platform where Oracle Server runs. That's the big portability difference. You can migrate a database to a different O/S and you won't have to redesign or kludge something up so it looks the same.
And they like the BlackBerry. (Hell, it's a lot more convenient than trying to boot up a laptop and pay the Marriott ten freaking bucks for internet access, and a thousand times more convenient that unlugging your desktop-replacement laptop.)
Why do they like it? It. Just. Works. It gets email from point A to point B, fast. It's fully integrated with either Exchange/Outlook and Notes, which covers, what... 90% of the Fortune 500 companies? The people who use BlackBerries religiously are the people to whom the ability to communicate with their ilk is their livelihood.
Slashdot, you are not the target demographic for BlackBerries. You are simply blue sky sales, so what you think about the technology, UI, or comparables really aren't freaking relevant.
The real problem with people blithely throwing around $40k/proc is that it covers a single case for the Oracle database server, analogous to quoting the price of Windows as $4,000 -- after all, that's the price of Windows 2003 Data Center Edition.
Oracle has solutions at several price points with increasing capacity. People act like that's a bad thing.
There's a world of difference between storing formatted reports and storing the source data from which the reports were generated in a way that can be queried and reanalyzed to answer the questions your reports didn't answer when you ran them.
The first is an archival system, the second is a data warehouse.
Further, querying the normalized (current) data about things like customers and products when looking backward in time will result in inaccurate results. If you change the price of a product, suddenly the profitability of that product changes for sales which have already took place.
Lastly, renormalizing all of that data isn't free. Once you've got an image of a period of time, reflecting what happened and when, you're better off storing it that way and not having to do it all over again.
Of course, if you have an Oracle database running on a server in the wild that's vulnerable to this exposure, you're an idiot considering this vulnerability was known about months ago.
But none of that is relevant. If Big Company doesn't respond according to Slashdot's time constraints -- and right sprightly, too! -- well, they're evil. Actually more evil because they have wealth, power, and greater marketshare than all the OSS database engines, which is evil, as well as because they dared ship code which was discovered to have a vulnerability, which is even eviler.
It took 20 minutes of webflailing to find patches on metalink?
Over what, 1200 baud? Where you trying to whistle into a modem with a microphone?
I can find "the latest patches" in... lessee.
Login. Click tab at top right called "Patches and Updates" -- deviously named and not at all intuitive.
On the next page, there's: Simple Search Advanced Search E-business Suite Recommended Patch List Quick Links to the Latest Patchsets, Minipacks, and Maintenance Packs Your Saved Searches
Wow... where to go next? If you're crazy enough to pick the quick links, you get...
A list of Oracle products. I assume by your posting you were looking for patches for Oracle Database.... and there it is the third product listed at the top, with that nefarious alphabetical ordering.
Now it gets tricky... it uses mouseover to have you drag to the specific hardware and OS you need a patch for, then you drag to the particular patch. If you don't know the hardware and OS, you shouldn't be getting patches anyway.
It took me... 3 whole clicks to find the latest patchset for Oracle 9i for Solaris on the SPARC platform, once I logged in.
If finding Oracle patches is beyond your skills and deductive abilities, I fear the results of your bioinformatic research.
Howeever, according to the last Slashdot groupthink good vs. evil pamplet I received, information wants to be free, so OED must be evil, and therefore wrong.
And when the OED adds the transitive verb accepted use definition which you understood but chose to be pedantic about, will Smoot be retroactively correct?
Slashdot Mirror
http://slashdot.org/comments.pl?sid=183901&cid=151 90614
Lessee...
RedHat buys JBoss, something Oracle wants.
Red Hat needs Oracle way more than Oracle needs RedHat.
Oracle's wanted to commoditize OS's forever -- hence Oracle is the same everywhere. Same libraries, same APIs, same interfaces.
Oracle wants their own Linux distro to simplify their own support challenges and to more effectively compete with Redmond in the x86 space.
Suddenly RedHat takes one in the neck to the tune of a billion dollars. Suddenly RedHat's way cheaper if he decides to buy it, and if he doesn't, he's managed to cripple a company that he perceives as a competitor.
Who here wasn't surprised by this?
Fucketh not with Larry Ellison, for he has the political and financial will to break everyone but Microsoft and IBM. Hell, I think he rather enjoys exercising it.
Copy the data? Why would you want to do that? It's already on the network somewhere, assuming it's not a JBOD internal storage architecture. And if it is, why bother upgrading it? It's a toy system.
Further, if your database is web-facing and a driver of revenue but isn't highly available -- clustered, RAC'd, gridded, or what have you -- whoever architected that system has earned a pink slip.
Certs are important to your bosses, because they're able to bill higher rates depending on the alphabet soup on your resume.
Such billing differentials may or may not roll down to your salary.
They're only important to you as a CONsultant because you're less likely to have to burn bench time if you've got more certs, because you can be placed in different roles on different projects.
1. Ensure the database layer is a parallelizeable RDBMS that has a concurrent access mechanism and is running on a multicore/multiCPU box.
2. Grid/Parallelize the application layer -- i.e., ensure you can run parallel jobs with discrete data.
3. If that doesn't help, then grid the database layer.
If your application isn't built to scale today -- see the second point -- all the grid in the world won't help you.
I agree with you that it sounds like the code needs some optimization -- 10-30 minutes to process is 5 to 15 trades per second, and that's ridiculously slow. One thing you haven't addressed is the I/O subsystem -- if you're using crappy disk in a I/O intensive batch system, it can kill you. If you were to move to a grid, you'd have to move to some sort of SAN/NAS in order for your application to function. Of course, you can move to a SAN/NAS without being on a grid or in a cluster.
Oracle's got lots of performance diagnostic tools to help you determine what's going on between the time the app makes a database call and the app gets control back, if that's what you're running. Okay, only one really good one (extended SQL trace), but it's really good. If you're running Oracle, get a trace or a statspack report of one of your batch runs to try to determine what the performance issue is before you spend any money chasing an architectural solution.
Further error: Electors hold state office, not federal office.
Incorrect.
While the Constitution originally left the selection of electors for president and U.S. Senators as a responsibility of the legistatures of the states, Amendment XVII (1913) mandates that Senators are to be "elected by the people thereof." It may not have been put there by the Framers, but it's there now.
And I tend to disagree with your contention that a Senator should be able to be "called on the carpet" for not voting according to the will of the people. That's what we have elections for -- if a Senator failed to exercise the will of the Legislature that selected it, I'm sure the Legislature would collect in due time. Until then, that responsibility is the Senator's to discharge.
Micromanagement doesn't work for techies -- what makes you think it works better for politicians?
You mean like the way Maine and Nebraska do it today?
g e/
http://en.wikipedia.org/wiki/U.S._Electoral_Colle
Doing it that way everywhere would certainly yield an electoral college result that is significantly more representative of the collective will of each state's voters.
Further, the electors of the electoral college are representatives of the various states, and therefore state laws govern their actions. You'd need a constitutional amendment to change that, and all bets are off if that happens.
Remember -- you don't vote for President. Your state does. Tradition may argue otherwise, but "each state shall appoint, in such manner as the Legislature thereof may direct, a number of electors..." That's the law, and it's one of those big nasty constitutional ones.
Let's see... crushing enemies, seeing them driven before you, and hearing the lamentation of their women.... what else could they possibly need?
I would counter that the ratio of testosterone to estrogen -- i.e. environmental factors -- would determine how a stem cell would express itself. That's exactly what happens during gestation -- various hormone levels determine vocal pitch. All humans are conceived bisexed or hermaphroditic -- it's what the sex chromosomes do during gestation that makes the difference. http://www.straightdope.com/classics/a1_093.html
Season 1, Episode 4: Infection http://www.midwinter.com/lurk/countries/us/guide/0 04.html
Reporter: "After all that you've just gone through, I have to ask you the same question a lot of people back home are asking about space these days. Is it worth it? Should we just pull back, forget the whole thing as a bad idea, and take care of our own problems, at home?"
Sinclair: "No. We have to stay here, and there's a simple reason why. Ask ten different scientists about the environment, population control, genetics - and you'll get ten different answers. But there's one thing every scientist on the planet agrees on: whether it happens in a hundred years, or a thousand years, or a million years, eventually our sun will grow cold, and go out. When that happens, it won't just take us, it'll take Marilyn Monroe, and Lao-tsu, Einstein, Maruputo, Buddy Holly, Aristophanes - all of this. All of this was for nothing, unless we go to the stars."
Oracle wants an OS that runs on commodity (x86) hardware, so that it can publish a virtual machine with Oracle preconfigured. (Reference the Oracle appliance of days of yore.)
Why?
Because virtualization is hot in databases. Having lots of servers spinning idle that you may need (and paying Oracle for the privilege) is costly, and Larry sees market share, well, if not eroding, then certainly being nibbled at. By shipping a distro with Oracle preconfigured, he:
1. Shows a commitment to his customers for a lower TCO. (Remember, the amount of time the IT staff spends installing and working through issues with the software stack counts.)
2. Punches SQL Server in the mouth.
3. Takes more control of his destiny by being able to more effectively tune the OS for database tasks, yielding better performance and price-performance in things like TPC-C and TPC-H.
Oracle needs to use a Linux distro that has traction within the data center, and in the US, that's either Novell (SuSE) or Red Hat. Those are the only distros officially supported by Oracle now, which probably helps to explain their traction within the data center.
Oracle will buy one. It's just a matter of which one.
And if I were RedHat's CEO, I'd be really careful pissing off Larry. It's not like Larry's afraid to, I don't know, buy your company so he can fire your ass. *cough*Siebel*cough*
You must not work in San Francisco.
I'll just say this much:
If you're running a medium to large system on the mainframe, it's very likely that you do use partitioning. Otherwise purging data, backing up data, or searching through billion-row indexes is not going to be as performant as possible.
Performance is often achieved by writing to the low-level. Generic code and generic SQL performs... generically.
And as someone who's ported commercial software between DB2 z/OS, DB2 LUW, and Oracle, I can tell you that the "slightly different" code is not so "slight" when you're actually elbows deep in it. The devil is in the details, and that 1% you so blithely dismiss can chomp down quite firmly on your backside when you least expect it.
Oracle Server is Oracle Server regardless of where you implement it -- Windows, Unix, or OS/390. I agree that there are differences in the kernel code and the process model (used on Unix) versus the thread model (used on Windows). However, those are not differences that are relevant to the users -- the same initialization parameters and SQL syntax apply regardless of platform.
DB2 is not DB2 regardless of where you implement it.
You can migrate an Oracle database from z/OS to z/Linux with import/export. You cannot migrate a DB2 database from z/OS to z/Linux without possibly having to redesign and reimplement various schema objects.
That's a significant difference, and it's one that causes lots of heartburn for those of us who maintain applications that support multiple databases. You figure you'd only need two database code lines -- one for Oracle, one for DB2. However, you need three -- one for Oracle, one for DB2, and one for DB2 UDB.
However, for non-production systems -- generally dev, test, and qa environments -- the use of VMware for both Windows and Linux is hot-hot-hot. Those platforms are generally woefully underutilized, where the utilization numbers are on the order of 5-10% during the working day, lower during off hours.
Collapsing several system's environments like that into a single VMware server can save lots and lots of money paid for :
Systems
Data Center Space
Data Center Operating Costs
Besides, I remember having seen something about all the VMWare releases except for the top-of-the-line one being more or less free now.
Heck, he could set up database links and:
... but I'm guessing anything that might require reading the documentation will be considered way too hard for the GP.
1. Reference the remote table directly.
2. Set up replication to continuously replicate the tables at the remote database to the local database.
3. Use import/export (or impdp/expdp) to create a dump file which is portable cross-os and cross-release.
4 Issue "create table X as select * from X@otherdb;"
Oracle is a big, complicated piece of software. If the GP wants toy software, well, he knows where to find it.
You're both wrong.
DB2 also runs on the mainframe -- you know, OS's like OS/390 and z/OS. That DB2 -- which is the one most people mean when referring to DB2 unless they say DB2 UDB -- is from a completely different code base, and works very, very differently. Little things like "the number of columns that can constitute a unique index" and "how partitioning works" differ wildly between the two DB2 "Universal Database" implementations. So if you want to move databases off z/OS onto a z/Linux partition or onto AIX, well, you really can't. Certainly not simply and easily. (There used to be three code lines for DB2, but they finally renamed DB2 for AS/400 to DB/400.)
However, Oracle Server has the same implementation rules -- columns per key, block sizes, how partitioning works -- on every platform where Oracle Server runs. That's the big portability difference. You can migrate a database to a different O/S and you won't have to redesign or kludge something up so it looks the same.
It is the same. That's the difference.
... salesweenies and marketroids are.
And they like the BlackBerry. (Hell, it's a lot more convenient than trying to boot up a laptop and pay the Marriott ten freaking bucks for internet access, and a thousand times more convenient that unlugging your desktop-replacement laptop.)
Why do they like it? It. Just. Works. It gets email from point A to point B, fast. It's fully integrated with either Exchange/Outlook and Notes, which covers, what... 90% of the Fortune 500 companies? The people who use BlackBerries religiously are the people to whom the ability to communicate with their ilk is their livelihood.
Slashdot, you are not the target demographic for BlackBerries. You are simply blue sky sales, so what you think about the technology, UI, or comparables really aren't freaking relevant.
I agree that no one ever should pay that; however, that is what Oracle EE is still listed at on a per-processor basis:
s pRte.jsp?section=11468
http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctD
The real problem with people blithely throwing around $40k/proc is that it covers a single case for the Oracle database server, analogous to quoting the price of Windows as $4,000 -- after all, that's the price of Windows 2003 Data Center Edition.
Oracle has solutions at several price points with increasing capacity. People act like that's a bad thing.
You are mistaken.
There's a world of difference between storing formatted reports and storing the source data from which the reports were generated in a way that can be queried and reanalyzed to answer the questions your reports didn't answer when you ran them.
The first is an archival system, the second is a data warehouse.
Further, querying the normalized (current) data about things like customers and products when looking backward in time will result in inaccurate results. If you change the price of a product, suddenly the profitability of that product changes for sales which have already took place.
Lastly, renormalizing all of that data isn't free. Once you've got an image of a period of time, reflecting what happened and when, you're better off storing it that way and not having to do it all over again.
There is a huge difference between "runs" and "runs at equivalent throughput with equivalent hardware."
Nietzche's got prior art for Superman anyhow.
Remember, this is Slashdot. Big Company Bad.
Of course, if you have an Oracle database running on a server in the wild that's vulnerable to this exposure, you're an idiot considering this vulnerability was known about months ago.
But none of that is relevant. If Big Company doesn't respond according to Slashdot's time constraints -- and right sprightly, too! -- well, they're evil. Actually more evil because they have wealth, power, and greater marketshare than all the OSS database engines, which is evil, as well as because they dared ship code which was discovered to have a vulnerability, which is even eviler.
It took 20 minutes of webflailing to find patches on metalink?
Over what, 1200 baud? Where you trying to whistle into a modem with a microphone?
I can find "the latest patches" in... lessee.
Login.
Click tab at top right called "Patches and Updates" -- deviously named and not at all intuitive.
On the next page, there's:
Simple Search
Advanced Search
E-business Suite Recommended Patch List
Quick Links to the Latest Patchsets, Minipacks, and Maintenance Packs
Your Saved Searches
Wow... where to go next? If you're crazy enough to pick the quick links, you get...
A list of Oracle products. I assume by your posting you were looking for patches for Oracle Database.... and there it is the third product listed at the top, with that nefarious alphabetical ordering.
Now it gets tricky... it uses mouseover to have you drag to the specific hardware and OS you need a patch for, then you drag to the particular patch. If you don't know the hardware and OS, you shouldn't be getting patches anyway.
It took me... 3 whole clicks to find the latest patchset for Oracle 9i for Solaris on the SPARC platform, once I logged in.
If finding Oracle patches is beyond your skills and deductive abilities, I fear the results of your bioinformatic research.
OED requires payment to access. Hell, they want $30/month for access to a freaking dictionary! http://www.oed.com/subscribe/individuals-amer.html
I guess they've got leverage.
Howeever, according to the last Slashdot groupthink good vs. evil pamplet I received, information wants to be free, so OED must be evil, and therefore wrong.
And when the OED adds the transitive verb accepted use definition which you understood but chose to be pedantic about, will Smoot be retroactively correct?