Re: Why never finished deploying oracle data guard physical standy by

From: Quanwen Zhao <quanwenzhao_at_gmail.com>
Date: Wed, 24 May 2023 15:53:53 +0800
Message-ID: <CABpiuuSJHmd3X+cvHVGXXUX+FZ2HM7ZsJh+Y5ud8ut9EFKUkrg_at_mail.gmail.com>



Hello richard and Mladen :-),

I've used the same path for data file, log file and temp file both on primary and physical standby database, also set db_file_name_convert and log_file_name_convert.

After adding the following parameters on */etc/sysctl.conf* of oracle *primary* database, although *out-of-memory killer* disappeared.

> *vm.overcommit_memory = 1vm.hugetlb_shm_group = 501*

Nevertheless reported the following error on */etc/sysctl.conf *when re-execuring rman duplicate task at 16:16 the day before yesterday, which caused some critical processes of oracle primary database be killed.

May 22 18:06:12 xxxxxx kernel: [205922.984115] *INFO: task jbd2/dm-2-8:3836
> blocked for more than 120 seconds.*
> May 22 18:06:12 xxxxxx kernel: [205923.003932] Not tainted
> 4.1.12-61.1.28.el6uek.x86_64 #2
> May 22 18:06:12 xxxxxx kernel: [205923.006889] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> May 22 18:06:12 xxxxxx kernel: [205923.013026] jbd2/dm-2-8 D
> ffff887e0cb176c0 0 3836 2 0x00000000
> May 22 18:06:12 xxxxxx kernel: [205923.013031] ffff887dcf2b7a58
> 0000000000000046 ffff887dd8815400 ffff887ddaa87000
> May 22 18:06:12 xxxxxx kernel: [205923.013034] ffff887dcf2b7a58
> ffff887dcf2b4008 ffff887e0cb176c0 7fffffffffffffff
> May 22 18:06:12 xxxxxx kernel: [205923.013037] ffff887dcf2b7be0
> 0000000000000002 ffff887dcf2b7a78 ffffffff816c790e

And I have to adjust the value of *vm.dirty_ratio* from the original *10* to *60* on /etc/sysctl.conf. Re-running rman duplicate task on yesterday morning, yes, it's very great. Taking about 9 hours the physical standby database has been fiished deploying during the period of that time primary database is ok.

Afterwards, finished recoving archived logs and started applying archived logs.

Best Regards
Quanwen Zhao

Mladen Gogala <gogala.mladen_at_gmail.com> 于2023年5月23日周二 00:52写道:

> Also, setting db_file_name_convert and log_file_name_convert on the
> standby side might go a long way toward the problem resolution.
>
> On Mon, May 22, 2023, 11:48 richard goulet <rjgoulet_at_comcast.net> wrote:
>
>> Ref:
>>
>> Hello my oracle friends 😄,
>> One of my customers wanna delopy oracle data guard physical standby by rman
>> duplicate using my current oracle 11.2.0.4.0 with single instance, after a
>> series of the tedious DG parameters configuration both on primary and
>> physical standby database I started using rman duplicate to push memory
>> script from primary to physical standby.
>>
>> Yes, my current oracle 11.2.0.4.0 has the volume size of *2.0 t* for data
>> files, the hardware resource is as below:
>> Logic CPUs: 64c, Physical Memory: 512 GB, Disk IO for the read and write
>> speed is probably a bit of bottleneck.
>>
>> Firstly, I use the following shell script to deploy it.
>>
>>
>> But after *3.5 hours*, the log file of rman duplicate has the following
>> error:
>>
>> ......
>>
>> executing command: SET NEWNAME
>>
>>
>> Your issue is that the target system does not have the same filesystem layout as the original. You have 2 options:
>> 1) get your sysadmin to fix the target filesystem to match the original, alternatively if you have access then do the required.
>> 2) use the setnewname command to change the original to match the target:
>> EX: 'setnewname datafile 1 to '/oracle/oradata/<whatever>/datafile/system01.dbf';
>>
>> Mladen Gogala
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed May 24 2023 - 09:53:53 CEST

Original text of this message