Comments on: Plan is same, Wait profile is different ?

By: Damir Vadas

Damir Vadas — Wed, 13 Jul 2011 22:10:40 +0000

Nice point Coskan.
Enjoyed reading ….

Damir Vadas

By: Coskan Gundogar

Coskan Gundogar — Sun, 10 Jul 2011 11:09:35 +0000

Hi Jagjeet,

You are right it normally asks for other parameters as well if you want to see the runtime of a sql for a spesific session. At this occasion I am sure that this is the one I run so I only pass the sql_id but if you want to see session id spesific then better you also pass sql_id and sid together like below

undefine sql_id session_id
set long 10000000
set longchunksize 10000000
select dbms_sqltune.report_sql_monitor (sql_id=>’&sql_id’,session_id=>&session_id) from dual;

By: Jagjeet Singht

Jagjeet Singht — Wed, 06 Jul 2011 15:59:00 +0000

Excellent approach, thanks for sharing. waiting for other series on upgrade.

For dbms_Sqltune.report_sql_monitor, it requires additional parameters to report sqls for other sessions. But here you simply passed sql_id. Did these sqls were run from your session only ?

Regards,
Jagjeet Singh

By: Anand

Anand — Wed, 06 Jul 2011 02:11:45 +0000

Nice diagnostic approach. Thanks for sharing it

By: jgarry

jgarry — Fri, 24 Jun 2011 23:28:43 +0000

RAC specs are exactly same plus all parameters are same ?

Ignore the parameters behind the curtain, bwahaha.

Excellent example! I especially liked the part where the spread of sqls made such a difference. That’s the kind of trap a load test could easily miss.

By: coskan gundogar

coskan gundogar — Fri, 24 Jun 2011 13:15:26 +0000

John, Thank you very much for stopping by and your comments. The shared_pool_reserved_size is not set explicitly in our case.

QA> show spparameter shared

SID NAME TYPE VALUE
——– —————————– ———– —————————-
* hi_shared_memory_address integer
* max_shared_servers integer
* shared_memory_address integer
* shared_pool_reserved_size big integer
* shared_pool_size big integer
* shared_server_sessions integer
* shared_servers integer

it normally should have been auto adjusted to its default which is 5% of the value of SHARED_POOL_SIZE but a little higher in our case which is I am not sure why.

When it comes to 10GB-8GB is just for the flexibility to grow “online” in case of a problem and secure the additional 2GB space to this database. I always find it more practical to give resources gradually to the end users so we can track down the real usage and not letting them waste the resources. When you have resource somebody will use it but real question is should they

By: John

John — Fri, 24 Jun 2011 12:53:45 +0000

Coskan, I think this is an excellent blog entry as it takes the reader through a good diagnostic approach and is well written and displayed.

I noted that in your seemingly similar environments shared_pool_reserved_size is 278M on prod and only 67M on QA

What do you see as the benefit of setting sga_max_size as 10Gb but sga_target to only use 8Gb. Teh additional 2Gb is still grabbed by oracle and is therefore unusable to anybody else. I appreciate that you can grow the database parameters later, without a bounce, but to my mind you might as well use that extra 2Gb in the buffer cache for now.
regards
John