Re: Wrapping all tables with packages and scalability

  • From: "Nuno Souto" <dbvision@xxxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 4 May 2004 02:21:38 +1000

----- Original Message ----- 
From: "Vadim Gorbounov" <v.gorbunov@xxxxxxxxx>

> 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@xxxxxxxxxxxxxxx

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: