Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Need help because of full table scan and Performance

0 views
Skip to first unread message

Martin Sigge

unread,
May 31, 2000, 3:00:00 AM5/31/00
to
Hi,

we have an application (Remedy Action Request System) with 100000
entrys.
For a quers, we have to use LIKE "%xxx% Order by..." and this results in
a full table scan.
This scan need 3 minutes to finish. The ORACLE 7.3.4 is on a NT Server
4.0 with 1GB of RAM
and the ora.ini is like:

db_block_buffers = 50000
db_block_size = 4096
db_files = 100
db_file_multiblock_read_count = 64
log_buffer = 3084000 # 3 MB für SGA 63 M
max_dump_file_size = 16280
sort_area_retained_size=65536
sort_area_size=524288

I think, the buffers and sort size is to small.

Is it correct?

Thank you,

Martin


Sybrand Bakker

unread,
May 31, 2000, 3:00:00 AM5/31/00
to
Comments embedded

Hth,

Sybrand Bakker, Oracle DBA

Martin Sigge <martin...@materna.de> schreef in berichtnieuws
3934D012...@materna.de...


> Hi,
>
> we have an application (Remedy Action Request System) with 100000
> entrys.
> For a quers, we have to use LIKE "%xxx% Order by..." and this results in
> a full table scan.
> This scan need 3 minutes to finish. The ORACLE 7.3.4 is on a NT Server
> 4.0 with 1GB of RAM
> and the ora.ini is like:
>
> db_block_buffers = 50000

way too high. 50000 * 4k means 200M db_block_buffers alone. Probably you are
just forcing the server to fault

> db_block_size = 4096
> db_files = 100
> db_file_multiblock_read_count = 64

way too high, block_size times multiblock_read_count should equal 64k
You are now probably reading records you're never going to use.


> log_buffer = 3084000 # 3 MB für SGA 63 M

again way too high


> max_dump_file_size = 16280
> sort_area_retained_size=65536
> sort_area_size=524288

as this is per process you could increase it to 1M but there it should stop.
>


Please run utlbstat and utlestat and verify my comments

> Thank you,
>
> Martin
>

cgr...@disc.com

unread,
Jun 1, 2000, 3:00:00 AM6/1/00
to martin...@materna.de
You could look into the option of adding the advanced indexing
capabilities of OMNIDEX from DISC to perform fast keyword lookups
instead of slow table scans for LIKE %value%.

See www.disc.com/keyword.html or contact me for more information.

Cheryl Grandy
DISC
cgr...@disc.com
303 444-4000
www.disc.com/home

OMNIDEX - for the fastest applications ever!

In article <3934D012...@materna.de>,


Martin Sigge <martin...@materna.de> wrote:
> Hi,
>
> we have an application (Remedy Action Request System) with 100000
> entrys.
> For a quers, we have to use LIKE "%xxx% Order by..." and this results
in
> a full table scan.
> This scan need 3 minutes to finish. The ORACLE 7.3.4 is on a NT Server
> 4.0 with 1GB of RAM
> and the ora.ini is like:
>
> db_block_buffers = 50000

> db_block_size = 4096
> db_files = 100
> db_file_multiblock_read_count = 64

> log_buffer = 3084000 # 3 MB für SGA 63 M

> max_dump_file_size = 16280
> sort_area_retained_size=65536
> sort_area_size=524288
>

> I think, the buffers and sort size is to small.
>
> Is it correct?
>
> Thank you,
>
> Martin
>
>

--
Cheryl Grandy
DISC
Get OMNIDEX for the fastest
applications ever


Sent via Deja.com http://www.deja.com/
Before you buy.

0 new messages