Re: Unplug problem

Hello Sayan,

Thanks a lot for correcting me.

În lun., 29 mar. 2021 la 06:17, Sayan Malakshinov <xt.and.r_at_gmail.com> a scris:

> Hi Laurentiu,
>
> You don't need intermediate server C, this role can be played by Server B.
>
> Best regards,
> Sayan Malakshinov
> Oracle performance tuning expert
> Oracle Database Developer Choice Award winner
> Oracle ACE Associate
> http://orasql.org
>
> пн, 29 мар. 2021 г., 5:24 Laurentiu Oprea <laurentiu.oprea06_at_gmail.com>:
>
>> If from Server A you don't have direct access to Server B on 1521 but you
>> have an intermediary Server C that has 1521 to B and you have 22 from A to
>> C you can do ssh forwarding:
>> https://www.ssh.com/ssh/tunneling/example
>>
>> maybe you have a jumpbox or something...I seen cases
>>
>> În lun., 29 mar. 2021 la 04:18, Mladen Gogala <gogala.mladen_at_gmail.com>
>> a scris:
>>
>>> I was asked to refresh one of the development PDB tenants from the
>>> corresponding production PDB. The platform is Linux x86_64 (OL 7.7) with
>>> Oracle 19.10 (Jan 2021 RU). Unfortunately, due to security measures,
>>> the only open port between the production server and the development
>>> server is 22. That eliminates remote clone. The tenant size in
>>> production is around 1TB. I opted for unplug pluggable database into
>>> '/tmp/tenant.pdb'. That took almost 2 hours with very fast disk storage
>>> (Pure array) and a powerful CPU. It was single threaded. Is there any
>>> way I can use multiple threads? The .pdb archive is compressed and my
>>> bottleneck was it being run on a single CPU. Is there any trick to do
>>> that with RMAN? The production has 144 cores and I could easily afford
>>> running 12 threads at a time. Unfortunately, I can't restore pluggable
>>> database into another CDB using rman. This was like pulling teeth. I
>>> couldn't get SQL*Net port (it isn't 1521) open so I had to unplug.
>>> Fortunately, I knew what was I in for so I first did unplug to XML,
>>> dropped the pluggable database with "keep datafiles" and plugged it back
>>> in using XML. The whole thing is extremely awkward. The funny thing was
>>> that "CREATE PLUGGABLE DATABASE TESTDB3 USING '/tmp/tenant.pdb'" used 2
>>> cores. It was 4 times as fast as creating the PDB archive. Oracle's
>>> multi-tenant leaves a lot to be improved. I hope that Oracle 21 might
>>> address some of these issues.
>>>
>>> --
>>> Mladen Gogala
>>> Database Consultant
>>> Tel: (347) 321-1217
>>> https://dbwhisperer.wordpress.com
>>>
>>> --
>>> http://www.freelists.org/webpage/oracle-l
>>>
>>>
>>>

--
http://www.freelists.org/webpage/oracle-l