Go to the FreeLists Home Page Home Signup Help Login
 



[oracle-l] || [Date Prev] [05-2004 Date Index] [Date Next] || [Thread Prev] [05-2004 Thread Index] [Thread Next]

Re: Wrapping all tables with packages and scalability

  • From: Вадим Горбунов <v.gorbunov@xxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 3 May 2004 12:46:36 +0400
Ryan,

This design concept may have scalability restrictions from quite different
point.
Batch processing may be where there is no good way around, except good old
plain SQL.
JDBC does not support proc batch calls? and even if it would, Oracle would
not be able to translate if to batch DML - no way it knew what's inside
PL/SQL.

Personally, I was involved into one project (Weblogic+Oracle), where this
approach caused serious performance problems. Once we redesined most
DML-intensive pieces of code using batch pattern, we've got really valuable
performance improvement, saved 10 CPUs.



Vadim


----- Original Message -----
From: "Ryan" <ryan.gaffuri@xxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Sunday, May 02, 2004 7:32 PM
Subject: Wrapping all tables with packages and scalability


> I met a guy about 2 months ago who used this design concept. Its basically
object oriented abstraction in the database. Each table has a package. Each
package has all the methods that operate on the table(all the SQL). SQL is
returned with REF Cursors. I  know Steve Fuerstein advocates this.
> He was stating that in a high transaction system with a max of about 700
transactions/second, he was unable to get his parse/execute ratio above 75%.
He noticed that Oracle did not always use bind variables on the dictionary
cache elements used by these packages.
>
> Anyone else notice this? I have not tested it.
> ----------------------------------------------------------------
> 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 http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------


----------------------------------------------------------------
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 http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------




[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.