Sql query slow in new redhat enviornment

Question

We just migrated to a new dev environment in Linux REDHAT5, and now the query is very slow, and I used the TOAD to run the query, it took like 700 msecond to finish, however from any server connection, the sql query takes hours to finish.
I checked toad monitor, it said need to increase db_buffer_cache and shared pool too small.
Also three red alert from toad is:
1. Library Cache get hit ratio: Dynamic or unsharable sql
2. Chained fetch ratio: PCT free too low for a table
3. parse to execute ratio: HIgh parse to execute ratio.
App team said it ran real quick in the old AIX system, however I ran it in old system, and monitored in the toad, it gave me all same 5 red alerts in old system, and it did provide query results a lot quicker though.
Here is the parameters in the old system (11gr1 on AIX):
SQL> show parameter target
NAME TYPE VALUE
-------------------------------- archive_lag_target integer 0
db_flashback_retention_target integer 1440
fast_start_io_target integer 0
fast_start_mttr_target integer 0
memory_max_target big integer 0
memory_target big integer 0
pga_aggregate_target big integer 278928K
sga_target big integer 0
SQL> show parameter shared
NAME TYPE VALUE
-------------------------------- hi_shared_memory_address integer 0
max_shared_servers integer
shared_memory_address integer 0
shared_pool_reserved_size big integer 31876710
shared_pool_size big integer 608M
shared_server_sessions integer
shared_servers integer 0
SQL> show parameter db_buffer
SQL> show parameter buffer
NAME TYPE VALUE
-------------------------------- buffer_pool_keep string
buffer_pool_recycle string
db_block_buffers integer 0
log_buffer integer 2048000
use_indirect_data_buffers boolean FALSE
SQL>
In new 11gr2 Linux REDHAT parameter:
NAME TYPE VALUE
----------- archive_lag_target integer 0
db_flashback_retention_target integer 1440
fast_start_io_target integer 0
fast_start_mttr_target integer 0
memory_max_target big integer 2512M
memory_target big integer 2512M
parallel_servers_target integer 192
pga_aggregate_target big integer 0
sga_target big integer 1648M
SQL> show parameter shared
NAME TYPE VALUE
----------- hi_shared_memory_address integer 0
max_shared_servers integer
shared_memory_address integer 0
shared_pool_reserved_size big integer 28M
shared_pool_size big integer 0
shared_server_sessions integer
shared_servers integer 1
SQL> show parameter buffer
NAME TYPE VALUE
----------- buffer_pool_keep string
buffer_pool_recycle string
db_block_buffers integer 0
log_buffer integer 18857984
use_indirect_data_buffers boolean FALSE
SQL>
Please help. Thanks in advance.

Answer 1

846422 wrote:
why need ddl? we have a sql query slow.The DDL shows the physical structure of the table and physical storage characteristics. All relevant in performance tuning.
As for the SQL query being slow. It is not.
You have not provided any evidence that it is slow. And no, comparing performance with a totally different system is not a valid baseline for comparison. (most cars have 4 wheels, a gearbox and a steering wheel - but that does not mean you can compare different cars like a VW Beetle with a VW Porsche)
What is slow? What are the biggest wait states for the SQL? What does the execution plan say?
You have not defined a problem - you identified a symptom called "+query is slow+". You need to diagnose the condition by determining exactly what the SQL qeury is doing in the database. (and please, do not use TOAD and similar tools in an attempt to do this - do it properly instead)