Oracle's Response (3)
10. Big deal, so do operating systems, unless you fflush() the buffer. This is incredibly petty.
Go to Fractal Site Confession: Oracle cannot print when you tell it to do so. This one petty gripe will cost your company about $5,000 for each such PL/SQL procedure. Migration scripts, batch scripts and cron scripts all fall into this category. Because Oracle cannot print real-time within PL/SQL, Oracle will force you to invent an elaborate alternative. You will have to create sequences, create and manage log tables, and program your procedures to write its log into those tables. Then you must write database client programs which simulate tail -f for each log table. This one petty item has cost Engage, Inc about $20,000 in two months. All they needed was a simple print statement that worked, but Oracle didn't have it.

I have told you the effects, but let me explain the technical reason using flush and buffer words. Oracle creates one buffer for all print statements in a procedure. Any time Oracle executes a print statement, its text goes into this buffer. Oracle never flushes this buffer while the procedure is running; therefore, you never see the text as the print statements execute. Oracle flushes the buffer only after the procedure ends. You see your messages, but only after the procedure finishes. When your procedure takes over 15 minutes to run and you need to see what is happening while it is running, you are out of luck. That is when Oracle becomes unacceptable.

Oracle also restricts the size of the buffer to 1 MB. Go past that and your messages get axed. So in Oracle, you must live in the dark, be ignorant about what is going on, and live with a 1 MB henchman. Don't underestimate the henchman. Filling the buffer with 1 MB of text is easy to do.
Go to Oracle
11. Wrong again. Oracle implements the array interface, something Sybase lacks, where you can load up an array of say 100 records, and with a single INSERT (or SELECT) statement insert (or fetch) 100 rows.
Mr. Conway does not understand the point. The point of Fact 11 is that Sybase and other databases can send hundreds of different insert, select, create, etc. commands to the server with a single go. This is called a batch of commands in Sybase. Oracle has no concept of batch. That is why Mr. Conway has no clue what I am talking about. He cannot imagine being able to execute an insert followed by a select statement with one 'go'. Oracle forces you to execute each command separately. In Oracle, to execute different statements all at once, you must contain all the commands within the equivalent of a stored procedure fragment, i.e., a PL/SQL block. SQL grammar and I/O rules radically change inside PL/SQL blocks.. Because Oracle cannot execute different commands all at once, 100 different commands will take 100 separate trips to the server.
12. While this is technically true, there is a different server-side way of doing the same thing. Is client-side timeout really a feature? What if you have a very long running query that times out in mid-stream? What a waste of resources. Oracle does have a resource governor which can limit the number of CPU cycles or I/Os a single statement can execute.
Confession: Oracle has no client-side timeouts. 20% of the problems on comp.database.oracle are because the client hangs waiting for the server. It is not a matter of CPU or I/O. The server itself has hung. So the client just sits there, and sits there. And then sits some more. No error message. Nothing. You just wait and wait. Oracle doesn't report a problem to the client (like Sybase would) because Oracle has no real-time messages. After 4 hours, you begin to wonder. Since you don't get any messages, you think everything is fine. You guess that your query is just taking a long time . . . which is normal for Oracle. 6 hours pass. Perhaps you should take a trip to the alert log. After rummaging through Oracle's shanty-town directory trees, there in the alert log, nestled amongst the core dumps, you see that you had ran out of rollback space. That happened 5 hours 59 minutes 59 seconds ago. What should have taken 1 second has cost you 6 hours and a tuft of hair

Had you been able to set a time-out, your insert statement would have aborted seconds after you initiated it. You wouldn't have waited and guessed for 6 hours. Mr. Conway says, "It is a waste of time to abort your query in midstream." Which is true, but that is not the problem. The problem is that the Oracle server itself has hung. It's not doing anything other than writing trace messages. No CPU. No I/O. The resource governor doesn't engage because nothing is happening. The server has hung. Therefore your client has hung. And because of Oracle's lack of client-side timeouts, you can not gracefully recover the client.

"Would client-side timeouts be called a feature?"  I call it a necessity. If you want to be able to gracefully handle network and server hangs, then it is imperative. It is normal practice for a competent programmer to estimate how much time his queries take to run and to use those times to set appropriate time-out values. If he knows his queries could take 5 hours, he'll set his query timeout to something like 7 hours. If the programmer expects his queries to complete in 1 second, he'll set his timeout to 10 seconds. The programmer wants his program to work. When the server or the network has a problem, he wants his program to recover gracefully. He wants his program to timeout and then gracefully handle the problem. Hanging processes, including clients, require baby sitting. Baby sitters are expensive. And no-one, no-one wants to get paged in the middle of the night. Yet all that baby sitting stuff is normal for Oracle, because Oracle provides no way to prevent it.

The lack of client-side timeout implies a far worse problem. For a program to be capable of time-outs, the program must have the ability to abort asynchronous events. This ability is so fundamental that Sybase never mentions they have it. It would be like a house manufacturer boasting that it uses rebar to build foundations. Ask the builder whether he uses rebar and he'll say, "Of course, we use rebar. What idiot home builder wouldn't?"

Oracle doesn't. Oracle does not want you to know it either. Why don't they have it? Because rebar was invented several years after Oracle laid its foundation. Oracle hopes that you will never find out. They are counting on your ignorance of program construction. Oracle diverts your attention to their penthouses. "Doesn't 'Most Scalable' and 'Market Share' look nice? Look how big our building is. Look at how many people live in it." And so you buy it. Little did you notice that the first floor has sunk into the mud. The very day you give Oracle to your database staff, is the day your budget begins filling the money pit. For the very day they attempt to install it, they will forever be inventing ways to prop it up. As the Leaning Tower is to Italy, Oracle programming will be to your company. Along with the props come the excuses. The Excuse, with a capital "E", will be "Well, Oracle has market share." Your programmers will use it on you. And you will use it on your CEO to explain why your department has empty pockets.

© 2010 Talus Software. All Rights Reserved.

Home | Buy Software | Privacy