On May 25, 1:54 pm, "rogergor..._at_gmail.com" <rogergor..._at_gmail.com>
wrote:
> On May 25, 1:33 pm, zigzag..._at_yahoo.com wrote:
>
>
>
>
>
> > On May 25, 1:23 pm, hasta..._at_hotmail.com wrote:
>
> > > On 25 mai, 00:43, zigzag..._at_yahoo.com wrote:
>
> > > > I have worked so many projects using [the three-tier]
> > > >architecture and performance has never been an issue.
>
> > > Zigzag,
>
> > > If you don't mind, and for better mutual understanding, would
> > > it be possible to have a (very rough) idea of some metrics
> > > for one of these systems ?
>
> > > I'm notably thinking of system purpose and :
>
> > > - size of stored data (in your prefered unit)
> > > - size of daily data growth
> > > - number of simultaneous users (peak would be most welcome)
> > > - average and guaranteed response time for user interface operations
> > > - number of transactions over your prefered time period.
> > > (peak would be most welcome)
>
> > > Really interested. Thanks much.
>
> > > --- Raoul
>
> > Performance is very complex subject with so many variables, In many of
> > our projets there were a few people assigned to do performance
> > measueremts on frequenetly used transactions by users and batch
> > processes.
> > Our database were up to 100GB large. 95% of our queries were indexed
> > based. Systems are used by up to 100 concurrent users Hope it helps.- Hide quoted text -
>
> > - Show quoted text -
>
> I have had way too many issues and hassles with the Java/Hibernate
> crowd. With their insistence that the entire database be loaded into
> memory, (worked on my laptop with 50,000 rows, why CAN'T you load a
> 30GB database into a machine with 4GB of RAM?")
>
> Their insistence on DB independence to the point that they insist
> MAX(user_id) +1 is a valid method of generating a sequence, until the
> ora-00001 errors come up and the DBA is asked to come up with a fix,
> "but we don't want to change application code."
>
> Their insistence that any SQL that returns a resultset is the only SQL
> that can be run with more and more columns and tables added so that
> they only have to maintain 1 SQL statement in the application rather
> than (horrors!!!) maintain dozens or scores of separate SQL queries
> that each do something different. Of course then the DBA is asked to
> optimize a query that is basically SELECT * FROM EVERY_TABLE IN
> MY_SCHEMA and JOIN it to this LINKED_TABLE regardless of what data I
> actually need to display on the page. (It was fast in development and
> when the DB was small. Optimize it, please. Oh, and no don't change
> the query as we NEED all of these columns and we can't change the
> application code. But please make it go faster, certainly Oracle can
> do better than that!!!. And on and on.
>
> Sometimes it's funny, really.
>
> Anyway, time to go on another crusade, this time for enough disk-space
> to properly support a workable RMAN retention policy BEFORE some short-
> sited bean counter decides that disk-space is expensive!!!!- Hide quoted text -
>
> - Show quoted text -
You must have had bad Java Developers. My team always had good
developers who know database very well.We alwyas have balanaced skill
set - user interface developer, database developer, Middleware
experts, Performance Engineers, DBA's etc.
Received on Fri May 25 2007 - 15:53:39 CDT
