| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Wrapping all tables with packages and scalability
> Ok, I must admit, sometime reducing network traffic helps scalability.
No. EVERY time. Not just sometimes.
> That is, when network is the bottleneck.
It is ALWAYS the bottleneck. We're talking multi-tier. Tiers don't happen out of thin air, they MUST have a network to work. The more nodes you add to multi-tier to scale, the bigger problem you have with scalability of the network.
> Sometime DB cpu is the most difficult to scale in 3-tier systems.
Most definitely not and NEVER EVER with Oracle. And that I won't even debate!
> I believe, stored procedures by themself may not
> help save CPU cycles, and there are very common cases where it turns out
> quite opposite.
You believe wrong. Name one.
> SP wrappers are good to facilitate application maintenance,
> but when it comes to scalability one may need to sacrifice maintenance for
> performance.
They got nothing to do with maintenance and they scale as well as ANY solution you may care to put forward. Provide concrete examples other than just vague "Scott Amblerisms".
> Not really true. It just happens different way.
> Oracle performs
> serialization and deserialization both on jdbc driver and database side.
No it does not. Anywhere. And it's got NOTHING to do with serialisation. Stop dropping J2EE notions, concepts and common place terms out of context, they mean absolutely nothing in this case and you chose the wrong person to drop them by.
> might save network roundtrips, but when it comes to CPU there might be
> unpleasant surprises.
No there aren't. Not one. Again, provide concrete examples rather than just vague J2EE notions.
> I don't get it. You can get ref cursor back from stor. proc. Than fetch
> rows. BUT, you pass one set of parms and get one object (ref cursor) at a
> time from stored procedure. It doesn't look batch processing to me.
It doesn't look like batch processing to me either. I do doubt you understand what you mean by batch processing.
> And Oracle doc says: "Executing a batch that includes an operation that
> attempts to return a result set will cause an exception.". True.
> Check
>
http://download-west.oracle.com/docs/cd/B10501_01/java.920/a96654/oraperf.ht
> m#1056233
Bingo. I just KNEW you didn't have the foggiest what you meant by "batch processing". It's about high time that you J2EE heads get told that you cannot continue to re-define words and concepts of IT totally out of context.
Here we go again with the deranged J2EE notion that updates have to be batched from individual object instances... Here is a piece of advice that you can chose to follow or not, your choice:
Learn what batch means, then come back here trying to tell us that a repeated update is a "batch" operation...
> Nop, I perfectly understood this. To be precise, yes, one definitely uses
> object types to define something, but ultimately passes objects (actual
> data),
No, you do NOT pass objects. It's IMPOSSIBLE to pass objects in the Java sense to an Oracle SP using PL/SQL and JDBC. Oracle doesn't have the foggiest of what the Java class looks like. The only thing you can pass are structs in JDBC parlance, which you can map to Object Types. Not Oracle Objects, which are completely different and not very useful, IMHO. Not yet.
> and these objects must be serialized and deserialized,
> and my point
> is, I do not care much about serializetion price on App server side, it is
> easy to add more servers when needed, but I care about this price on
> database side, because it is more difficult to scale the database.
No. "Serialised" and "de-serialised" are two totally moronic concepts that J2EE uses to mean "write" and "read" multiple instances of an object from offline storage, respectively. Databases were designed and optimised to do PRECISELY that much faster than ANY other piece of software. There is NO WAY you can scale an app server to read or write from-to offline storage in a fashion that is more scalable than a database. Do NOT even go there!
> Serialization CPU price is high enough to go back to many SQL calls and
many
> network roundtrips when DB is really busy.
If you do it the cretin J2EE way, yes indeed it is. If you become smart and rely on technology that has been tuned and optimised to do that job long before you were born, then you won't have the slightest problem.
You see, in TRUE batch processing you do NOT send multiple update
statements,
you send ONE update statement that acts on multiple sets of data.
That is how you ensure scalability. Set processing, rather than discrete,
repeated operations. Which are not (and were not EVER) scalable.
> Serialization/deserialization is
> not cheap in general,
Actually, it is dirt cheap. It is extraordinarily expensive if it is done using the deranged J2EE EJB concepts.
> and Oracle server side implementation is not most
> efficient too.
I dispute that remark from any angle you may care to discuss it. So will just about EVERYONE here.
> It is easy to collect stat from 10046 traces to see how much
> it costs.
10046 tells you nothing in absolute terms, so stop dropping "facts" out of the blue sky. 10046 tells you in relative terms how many operations of a given type it takes to do some SQL statement. That's it. That doesn't allow you to extrapolate that it is efficient overall in absolute wall clock terms or not. The only thing you can do with a 10046 is compare it to another of the same kind. Besides, provide one example where you could perform one operation faster than a 10046 tells you it's done.
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision_at_optusnet.com.au
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Mon May 03 2004 - 11:30:29 CDT
 |
 |