Re: very impressed by 11g
From: John Hurley <johnthehurley_at_gmail.com>
Date: Wed, 25 Apr 2012 07:13:13 -0700 (PDT)
Message-ID: <a61a7a62-6955-4fa1-af48-6ec38386da9c_at_h20g2000yqd.googlegroups.com>
On Apr 25, 4:33 am, "Gerard H. Pille" <ghpi..._at_hotmail.com> wrote:
> Op woensdag 25 april 2012 01:06:44 UTC+2 schreef Mladen Gogala het volgende:
>
> > On Tue, 24 Apr 2012 21:50:44 +0200, Gerard H. Pille wrote:
>
> > > There was nothing to be done about it, we didn't find any specific
> > > queries that were responsible, but the system kept hitting 100% cpu.
>
> > So, what was using all that CPU? Any particular process? Did you look
> > into V$SESSMETRIC? V$SQLSTAT? Are execution plans different? What is the
> > precise version of 11G that you have? There is a known bug in 11.2.0.2:
> > when automatic baseline collection is turned on, CPU is being burnt like
> > crazy.
>
> It was all the little processes together. We keep session statistics so we will be able to compare now the users are back to their workstations.
>
> compatible = "11.2.0.0"
> was
> compatible = "10.1.0"
>
> servr1.DBRMG>select version from v$instance;
> VERSION
> -----------------
> 11.2.0.2.0
>
> It looks like we don't capture the plan baselines automatically:
> servr1.DBRMG>show parameter optim
> ...
>
> NAME TYPE VALUE
> ------------------------------------ ----------- ------------------------------
> object_cache_optimal_size integer 102400
> optimizer_capture_sql_plan_baselines boolean FALSE
> optimizer_dynamic_sampling integer 0
> optimizer_features_enable string 11.2.0.2
> optimizer_index_caching integer 50
> optimizer_index_cost_adj integer 10
> optimizer_mode string CHOOSE
> optimizer_secure_view_merging boolean TRUE
> optimizer_use_invisible_indexes boolean FALSE
> optimizer_use_pending_statistics boolean FALSE
> optimizer_use_sql_plan_baselines boolean TRUE
> plsql_optimize_level integer 2
Date: Wed, 25 Apr 2012 07:13:13 -0700 (PDT)
Message-ID: <a61a7a62-6955-4fa1-af48-6ec38386da9c_at_h20g2000yqd.googlegroups.com>
On Apr 25, 4:33 am, "Gerard H. Pille" <ghpi..._at_hotmail.com> wrote:
> Op woensdag 25 april 2012 01:06:44 UTC+2 schreef Mladen Gogala het volgende:
>
> > On Tue, 24 Apr 2012 21:50:44 +0200, Gerard H. Pille wrote:
>
> > > There was nothing to be done about it, we didn't find any specific
> > > queries that were responsible, but the system kept hitting 100% cpu.
>
> > So, what was using all that CPU? Any particular process? Did you look
> > into V$SESSMETRIC? V$SQLSTAT? Are execution plans different? What is the
> > precise version of 11G that you have? There is a known bug in 11.2.0.2:
> > when automatic baseline collection is turned on, CPU is being burnt like
> > crazy.
>
> It was all the little processes together. We keep session statistics so we will be able to compare now the users are back to their workstations.
>
> compatible = "11.2.0.0"
> was
> compatible = "10.1.0"
>
> servr1.DBRMG>select version from v$instance;
> VERSION
> -----------------
> 11.2.0.2.0
>
> It looks like we don't capture the plan baselines automatically:
> servr1.DBRMG>show parameter optim
> ...
>
> NAME TYPE VALUE
> ------------------------------------ ----------- ------------------------------
> object_cache_optimal_size integer 102400
> optimizer_capture_sql_plan_baselines boolean FALSE
> optimizer_dynamic_sampling integer 0
> optimizer_features_enable string 11.2.0.2
> optimizer_index_caching integer 50
> optimizer_index_cost_adj integer 10
> optimizer_mode string CHOOSE
> optimizer_secure_view_merging boolean TRUE
> optimizer_use_invisible_indexes boolean FALSE
> optimizer_use_pending_statistics boolean FALSE
> optimizer_use_sql_plan_baselines boolean TRUE
> plsql_optimize_level integer 2
Sorry did not see the 11.2.0.2 stuff ... may have a number of bugs in that version that are now fixed in 11.2.0.3 ... Received on Wed Apr 25 2012 - 09:13:13 CDT