asked on

10g performance

Hi.

I've almost the same problem with two clients.

In the first, the old server was changed for a new and stronger server, with high performance. When they to that, and also installed oracle, the oracle performance was worst than in the old server. I searched for the parms of old server, and saw that in the new, less memory was allocated to oracle. Then, I changed the parms to became equal. For a few days oracle works fine. But now, I've received a mail telling that the performance slow down again.

In the second client, same application, but a little different study case. They've changed 9i for 10g. It is in automatic memory management. Also in this case, now the performance is worst than in 9i. Analyzing OEM, I saw that oracle is having so much I/O operations. Some updates and inserts was taking a long time to be completed, using so much I/O resources. I know that this can be an development problem. But I have a remote connection scheduled with the client in a few hours, when I'll try to change automatic to manual management, increase block_buffers, shared, and max_size, stop and start oracle server to see if the problem will be resolved. How can an application work worst in 10g than in 9i?
But, in case that this not work... I'll be without any others ideas to solve this problem... someone can help me with some tips if the actions described above doesn't work??

Thanks in advance.

schwertner

Run the statististics. After that flush the shared pool to
force Oracle to recompile and reoptimize the execution plans.

If you run into
ORA-01882: timezone region %s not found
study
Doc ID: 467722.1 DBMS_SCHEDULER And Time Zones ( DST ) Explained.

CREATE OR REPLACE PROCEDURE compute_statistics IS
BEGIN 
   dbms_stats.gather_database_stats(cascade=>true);
END compute_statistics;
/
 
 
set serveroutput on
set linesize 10000
BEGIN
   DBMS_OUTPUT.enable(100000);   
   dbms_scheduler.create_job(
      job_name => 'weekly_stats'
     ,job_type => 'STORED_PROCEDURE'
     ,job_action => 'compute_statistics'
     ,start_date => TO_TIMESTAMP_TZ('2009/10/22 2:10:00.000000 +08:00','yyyy/mm/dd hh24:mi:ss.ff tzh:tzm')
     ,repeat_interval => 'FREQ=WEEKLY'
     ,enabled => TRUE
     ,comments => 'Computes statistics over tables and indexes.'
     );
     DBMS_OUTPUT.PUT_LINE('Job successfully created.');
EXCEPTION 
     WHEN OTHERS THEN
       DBMS_OUTPUT.PUT_LINE(substr(sqlerrm,1,200)); 
END;
/

Open in new window

Thiago_corporative

ASKER

I did it last week... but didn't resolved.

ASKER CERTIFIED SOLUTION

mrjoltcola

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

schwertner

Depends also by the kind of the disk storage.
If it is RAID array then you will experience delay.

Also there analyzing tables and indexes is tricky.
Pay attention on
(cascade=>true)

This commonly is missed and causes that the indexes are not
analyzed.
Also the shared pool should be flushed to force new plans.

After increasing the
db_buffer_cache
and the shared_pool_cache
the DB should work significantly faster.

mrjoltcola

Was there a resolution you could share with us?