Re: Difference in writer response time

From: Pap <oracle.developer35_at_gmail.com>
Date: Fri, 9 Apr 2021 00:12:23 +0530
Message-ID: <CAEjw_fhiycwx-5xNbtM98Oz3Dj_SW+PEKna4BTdQuzR-k7SJNg_at_mail.gmail.com>



I need to check on the replication part. But i don't see anything(RMAN L1/L0/Archived log) during that point in time in v$raman_backup_job_details. it looks odd why that RMAN process showing up there. Not sure any other app can spawn RMAN processes?

Yes load wise they are the same as because we are seeing the issue consistently with the same data in the DR while pointing our application and on the next day we point to primary and on primary it just works fine. The avg active session on DR is showing 3 times higher mostly because it gets piled up as it was not able to finish up the work/session as fast as it's happening in the primary side.

Regards
Pap

On Thu, Apr 8, 2021 at 11:57 PM Laurentiu Oprea <laurentiu.oprea06_at_gmail.com> wrote:

> How exactly is the replication set and where extract and replicat are
> located? I see an additional "rman" function in the "DR" side and it looks
> like it is not present in Primary.
>
> Also there is a difference in average active sessions (in "DR" looks 3
> times higher), are you sure these numbers present the same workload?
>
> În joi, 8 apr. 2021 la 21:05, Pap <oracle.developer35_at_gmail.com> a scris:
>
>> Thank you Tanel.
>>
>> Its HP machine and its on file system. No ASM. The filesystemsio_options
>> in gv$paramer showing as "asynch" in both databases. and also
>> disk_asynch_io is also set as TRUE. As I see from AWR, Its HP-UX IA(64
>> bit), 64 core, 8- socket machine in both side.
>>
>> The SAN team confirms not much visible difference between the underlying
>> storage performance between those two sites. So wondering as we don't use
>> data guards could this difference be just because of just the structural
>> difference in table/index structure? But we have all the same volume of
>> data on both sides so not sure how that can play such a big difference. And
>> contrary to that, I see we are doing more work on the Primary(faster) side
>> during that time period as compared to DR(slow side), so how is that
>> possible? I am seeing the direct write is higher on DR i.e. slow side as
>> compared to primary, not sure if that is pointing to something suspicious.
>>
>> I have fetched the wait event section of the AWR from both databases and
>> attaching here(in two tabs as primary and DR wait profile). Although I do
>> see "free buffer waits" in one of the top lists but the major one is 'index
>> contention'(top one is a composite PK index but local index, so less
>> chances of structural difference causing such issues). But again it might
>> be that the DBWR response trend is just a symptom of something else but not
>> the cause as the SAN team is saying no difference there.
>>
>>
>> Regards
>> Pap
>>
>> On Thu, Apr 8, 2021 at 10:34 PM Tanel Poder <tanel_at_tanelpoder.com> wrote:
>>
>>> There's also one usual suspect, I don't see *filesystemio_options*
>>> parameter set, are you running on ASM, not a filesystem, right?
>>>
>>> Thanks,
>>> Tanel.
>>>
>>> On Thu, Apr 8, 2021 at 4:06 AM Pap <oracle.developer35_at_gmail.com> wrote:
>>>
>>>> Hello Lister, We have two databases which are the same in all the
>>>> hardware configurations along with DB parameters and are in sync/replicated
>>>> using golden gate. And those are treated as primary and DR for us and both
>>>> are active. But we are seeing differences in behaviour when our application
>>>> points to primary VS when it points to DR. We are seeing during specific
>>>> times of the day when our system is at its peak, in one of the database i.e
>>>> DR the DBWR response times spikes till ~200+ms slowing down the write
>>>> queries while in another database the dbwr response time stays ~65ms for a
>>>> similar amount of data and transaction volume. So wanted to understand what
>>>> can cause such drastic differences? Note- Its version 11.2.0.4 of Oracle.
>>>>
>>>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Apr 08 2021 - 20:42:23 CEST

Original text of this message