Re: Performance problem.
- From: francisco.martinez@xxxxxxxxxxxxxx
- To: ora-apps-dba@xxxxxxxxxxxxx
- Date: Fri, 12 May 2006 08:40:29 -0500 (CDT)
Thank you very much Yury.
I really appreciate your information.
Kind regards,
Francisco Mtz.
> I have got an answer from friend of mine regarding AIX FS related
> questions:
>
>>> Yury, do you have any environment of Apps on AIX?, if so, which kind of
>>> filesystems are you using there?, which mounting options are you using
>>> on
>>> your filesystems? what about minservers and maxservers parameters?
>
>>> I will really appreciate any advice or comment on this.
>
> Friend of my using jfs
> They have got planes to migrate to jfs2 but so far on jfs.
> We are talking about large Telecommunications transactional DB.
> MINIMUM number of servers 1
> MAXIMUM number of servers per cpu 10
>
> Used options are rw.
> There redologs are located FS.
>
> I am not really aware that all those options means, just passing that I
> got.
> Hope this helps,
> Yury
>
>
>
> On 5/11/06, francisco.martinez@xxxxxxxxxxxxxx
> <francisco.martinez@xxxxxxxxxxxxxx> wrote:
>> Hi Yuri,
>>
>> > -- take a look on BUG 4552415.
>>
>> I have asked a guy to take measures on their current system and have a
>> valid "performance" comparision. "Inactive Items report" is not executed
>> so often in their current production environment. I am going to analyze
>> "huge" processes which need improved time.
>>
>> >
>> >> Yury, do you have any environment of Apps on AIX?, if so, which kind
>> of
>> >> filesystems are you using there?, which mounting options are you
>> using
>> >> on
>> >> your filesystems? what about minservers and maxservers parameters?
>> > Unfortunately I haven't.
>> > I think if the performance problem is Apps slowdown then problem is
>> > generic and isn't connected with particular platform. If you are
>> > saying that there is particular SQL which doing fullcsans on huge
>> > table and by your mind it doesn't suppose to do it, then it is Apps
>> > generic problem.
>> > To deal with this type of problems I would look on Metalink for a
>> > particular report name or log a SR within Oracle Support Services.
>> >
>> > I have friends of mine working in telecoms industry they using AIX as
>> > main platform.
>> > I will forward your questions to them.
>>
>> I will really appreciate any advice or comment on this.
>>
>> >
>> > Just wonder that is average IO wait time in your system ? If it is
>> > less then 10-5 ms, I would most likely it isn't HW/OS problem, it is
>> > Apps.
>>
>> I will send to you my "monitoring output" next week, when we are going
>> to
>> "test" this environment again.
>>
>> >
>> > Yury
>> >
>> > PS Can I ask you to send a perfstat report to me?
>>
>> I will send to you "sar -d" output.
>>
>> We opened a TAR last week and analyst told us that "Av Rd(ms)" column
>> must
>> be lower than 20, we had some tablespaces which were upper this value.
>>
>> Keep you updated.
>>
>> I really appreciate your help and comments.
>>
>> Kind regards,
>>
>> Francisco Mtz.
>>
>> >
>> > Results from quick search throught the Metalink.
>> >
>> >> We haven't done SQL's tuning process yet, by the way one of the most
>> >> "huge" processes scheduled to run like request is report "Inactive
>> >> Items"
>> >> which is embeeded in the application (it is taking 15 minutes to
>> >> finish),
>> >> I have traced this process and it is doing a "FULL" scan of a big
>> table
>> >> "MTL_MATERIAL_TRANSACTIONS" (8831854 rows).
>> > 4924206 INCIAR: POOR PERFORMANCE OF CREATE AR INTERCOMPANY
>> > 4552415 CMCPAW LOW PERFOMANCE IN PERIODIC ACTUAL COST WORKER
>> > "Please indicate why should index MTL_MATERIAL_TRANSACTIONS_N5 be
>> > modified?.
>> >
>> > (transaction_date, organization_id) for 11.5.10.
>> > .
>> > This specific index was recreated with this order to improve the first
>> > process 1 (Periodic Cost Acquisition Adjustment Processor) which now
>> takes
>> > 15
>> > minutes to run against over 3 hours it took previously. If we recreate
>> > this
>> > index as you request, process 1 wont be able to use the
>> > MTL_MATERIAL_TRANSACTIONS_N5 on transaction_date index and will be
>> really
>> > slow again. Please indicate if what development needs is to add the
>> > transaction_action_id
>> > columns and if it can be added leaving transaction_date as the first
>> > column.
>> > Please indicate why is development changing a standard index."
>> >
>> > 4719252 PICK SLIP PERFORMANCE WHEN PICK SLIP NUMBER USED
>> > 4455311 CSTPDPPC - PERIODIC COST DISTRIBUTIONS PROCESSOR PERFORMANCE
>> ISSUE
>> >
>>
>>
>>
>>
>
>
> --
> Yury
> +44 7738 013090 (GMT)
> ============================================
> http://otn.oracle.com/ocm/jvelikanovs.html
>
- References:
- Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
Other related posts:
- » Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » RE: Performance problem.
- » Re: Performance problem.
- » RE: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- » Re: Performance problem.
- Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs
- Re: Performance problem.
- From: francisco . martinez
- Re: Performance problem.
- From: Jurijs Velikanovs