Re: Is "_db_block_cache_protect = true" killing my throughput?

It is possible, but I didn't think that the Sun had the necessary features in the O/S to do anything with _db_block_cache_protect or 10049 so they shouldn't have any effect.

Since the problem is INSERT time, the 10210 and 10211 also shouldn't be a problem - these would consume CPU only as a block was due to be written (I think).

I would go for the 10235 as the guilty party. Even so a factor of 10 seems rather extreme. can you give us an idea of the overall scale of the operation -

    inserts per second
    db_block_buffers
    redo parameters
    number of indexes per table

I would knock out all the lines you have told us about, though, I don't think 7.3.4 can really qualify as a beta release any more.

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

Christopher Allen wrote in message ...
>I learned yesterday that my Sun 450 server's Oracle 7.3.4.0.1 installation
>has about 1/10th the throughput (with simple INSERT statements) of the NT
>server sitting next to it running 8.0.5. This surprised me greatly, and
>I've started investigating why the Sun is so much slower. One thing I
>noticed was in the $ORACLE_HOME/dbs/init$ORACLE_SID.ora was this section:
>
> # FOR BETA RELEASE ONLY. Enable debugging modes. Note that these can
> # adversely affect performance. On some non-VMS ports the
db_block_cache_*
> # debugging modes have a severe effect on performance.
> _db_block_cache_protect = true # memory protect
>buffers
> event = "10210 trace name context forever, level 2" # data block checking
> event = "10211 trace name context forever, level 2" # index block checking
> event = "10235 trace name context forever, level 1" # memory heap checking
> event = "10049 trace name context forever, level 2" # memory protect
>cursors
>
>"Severe effect on performance" is certainly the symptom I'm seeing. Before
>commenting out the _db_block_cache_protect parameter, I want to know more
>about what it does. The Oracle online docs returned no matches to the
>phrase "db_block_cache". Can anyone tell me what this does, and what the
>ramifications of disabling it will be?
>
>Thanks,
>Christopher
>
>
Received on Thu Aug 12 1999 - 14:19:18 CDT