Re: Interesting Marketing

Well Jonathan, you made me go to their website and see for myself, and sure enough, there it was!

The irritating thing about corporate websites, however, is that they are often maintained by marketing folks, who often canıt string together two coherent meaningful sentences to save their lives.

As a case in point, I went from the ³Case Studies² tab, from which you quoted, to the nearby "Database Services" tab, and the following verbiage jumped out at me:

> <quote>
> An ORA-4031 is usually caused when the shared pool gets fragmented (you're not
> necessarily out of shared pool) into smaller pieces over the course of a day
> and a request for a large piece of memory is issued which can't be filled.
> Retrieving information from memory is more than 10,000 times (depending on the
> memory you have) faster than retrieving it from disk, so make sure the SGA is
> large enough.
> </quote>

This quote is two sentences about two entirely different topics. The first sentence describes an ORA-04031 error, which correctly enough is a failure condition related to space in the Shared Pool. Unfortunately, since 7.3 it is less an issue of fragmentation (due to better usage of blocks in the Shared Pool), but more simply exhaustion of available space, but never mind that quibbling detail for now...

In a whopper of a non-sequitor, the second sentence describes retrievals from memory as being ³more than 10,000 times ... faster than disk, so make sure the SGA is large enough². This second sentence is now talking about retrieval performance, not the outright failures from lack of space mentioned in the first sentence. The second sentence should have said something like ³ORA-04031 failures can cause programs to fail, so make sure the Shared Pool is large enough² instead of implying that performance is the big concern when ORA-04031 is erupting everywhere. Incidentally, failures (such as ORA-04031) result in zero performance, not just poor performance... :-)

More interestingly, it is also untrue that retrieval from the memory, especially highly-managed structures like the Shared Pool, is more than 10,000 times faster than disk. This is particularly untrue if there is any form of contention in the Shared Pool such as that resulting from:

• lack of bind-variable use
• SESSION_CACHED_CURSORS defaulting to 0
• frequently-used PL/SQL modules and sequences not pinned
• failure to allocate a Large Pool when one is using I/O slaves, MTS, PQ/PX, or RMAN duplexed backups
• all or several of the above...

Under these conditions at client site just this past week, I saw each retrieval from the Shared Pool take several seconds. Allocating larger SHARED_POOL_SIZE would have had nothing to do with the resolution of any of the above-mentioned problems. As a matter of fact, we observed excellent retrieval times from the I/O subsystem, often hundreds of times faster than the Shared Pool, because the contention in the Shared Pool was throttling the volume of I/O requests by the Oracle instance.

After all, if having everything in memory is really 10,000 times faster than disk, then it should be quite easy to prove. Just allocate a large enough Buffer Cache to accommodate an entire database, and see if real-world performance really improves by a factor of 10,000. Betcha it wonıt. Wanna guess why? :-)

on 5/11/03 1:01 PM, Jonathan Lewis at jonathan_at_jlcomp.demon.co.uk wrote:

>
> I've just discovered why TUSC has such a
> great opinion of itself. From the website:
>
> <quote>
>
> At TUSC, if we identify a project where the odds of success
> are low and we won't be able to sustain the type of client
> involvement that is needed to be successful, we won't get
> involved. We base our decisions on whether the project
> will make sense for both the client and TUSC.
>
> </quote>
>
>
> Am I missing something, or does this really read:
>
> "If it looks too difficult for us, we run away".
>
> or is it
>
> "We only get involved if it looks easy"
>
>
>
> How long has TUSC been around ?
> How's this for the 'Case Study' section of their
> website.
>
> <quote>
>
> Take, for example, one of our very first clients. It had
> a critical program that took days to run. TUSC was
> asked what could be done and our experts quickly
> demonstrated how the program's performance could
> be greatly improved so that the application could run
> in less than an hour.
>
> </quote>
>
>
> If I recall dates correctly, I thnk this means the only
> case study they claim (without any explanation of
> methods to show their skill set) is one from the
> days of Oracle 6. How strange that they don't quote
> a more recent experience.#
>
>
>
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> The educated person is not the person
> who can answer the questions, but the
> person who can question the answers -- T. Schick Jr
>
>
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
>
> ____Denmark__May 21-23rd
> ____Sweden___June
> ____Finland__September
> ____Norway___September
>
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> ____UK_(Manchester)_May x 2
> ____Estonia___June 4th - 6th
> ____Australia_June 18th - 20th (Perth)
> ____Australia_June 23rd - 25th (t.b.a)
> ____USA_(CA, TX)_August
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tim Gorman
  INET: tim_at_sagelogix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).