Re: (long) Sniffing redo logs to maintain cache consistency?

"Andrej Gabara" <andrej_at_kintana.com> wrote in message news:11a3a163.0302280636.2d9ccac4_at_posting.google.com...
> "Telemachus" <tollg_at_tendwa.rns.net> wrote in message
news:<Uen7a.12163$V6.16434_at_news.indigo.ie>...
> > I have to say that post should be stapled to developers foreheads ...
>
> Ha :) That statement is almost as funny as
> >>That was a relatively "I'm on your side" post from Sybrand<<.
>
> You're blessed by being naturally funny.

It must be the gift of the Irish.

<snip>

> Here are some problems we are facing, and probably all that use the
session
> facade plus DAO pattern:
>
> (1) One of our customers installed our app server and noticed it's using
> *only* 300MB in production. He asked us what he can configure in order
> for our app server to use the 4GB of memory that is available.
[Nowadays,
> a new server box ships with that much ram]

I very nearly ended up with yet another unusable coffee stained keyboard after this one. The only possible answer is that 300mb is all it needs (for his load at his site). Servers tend to come with at least 72gb of disk space as well, did he complain that the software didn't come on 10 CD's.

> So, obviously times have changed. Memory-conservation is not really an
> issue any longer. It's the opposite. The question is what can you do
to
> take advantage of this extra memory. Why conserve resources when there
> are plenty available and you can take advantage of it?

Use resources when they add to the performance or reliability of your app. That is what they are there for.

> The answer seems to be to cache more transactional data in the app
server.
> And if that duplicates some of the work the database is doing, that's
> ok! The customer doesn't mind if the app uses caching effectively to
> improve performance and reduce load on the database, even when
> some work is duplicated that the database is so good at.

Why on earth is doing the same work twice a good idea? *Moving* the work *might* be a good idea - though I doubt it, duplicating should only be done for very good reasons indeed - I have a big box with lots of ram isn't one of them.

> In the end, it's not the design with the highest performance that wins.
It's
> the most elegant design that solves critical problems and has acceptable
> performance. Over time, the thinking of what is acceptable performance
> changes because cpus run faster and memory gets cheaper.

Sadly its usually the design with the best marketing that wins :(. Sometimes even when performance isn't acceptable.

> Please no impolite replies from disgruntled Oracle DBA's, please! If you
> have time to waste, go rebuild an index or whatever.

Sorry if this seems impolite, but part of the reason for the lack of gruntledness tends to be that the DBA is held responsible (I think correctly) for the performance and scalability of the *application*. If the app is poorly designed then its nearly always the database that gets the blame.

--
Niall Litchfield
Oracle DBA
Audit Commission UK