On 16/02/18 21:13, Andrew Kerber wrote:
> Yeah, thats pretty much the problem. My plan is to generate the create
> controlfile command to a sql file prior to the clone operation so that
> its available when needed, rather than going through editing the trace
> file.
Thanks.
> I will probably just write a shell script to call the sql file if
> needed, so that if I am not available when the operation fails, I can
> just have someone run the shell script rather than page me.
I was lucky in that when it happened it was during working hours so I
fixed it there and then. My own workaround is to login to the auxiliary
database as sysdba, just after it is mounted for the clone, and do an
alter database disable block change tracking;
select * from v$block_change_tracking;
That way the clone runs through without any problems. Maybe, just maybe,
you could build the first (or both) into your clone scripts? It needs to
be done in a separate session and it may hang while the clone database
gets its act sorted out.
Might help, maybe.
Most of our cloning, in that contract anyway, was done through the day
from a staging database that we built when we ran our restore testing.
That gave us a copy of production that we could use to provision test
and development databases - after obfuscating any personal data etc.
Anyway, I'm rambling again. Hope you get sorted.
Cheers,
Norm.
--
Norman Dunbar
Dunbar IT Consultants Ltd
Registered address:
27a Lidget Hill
Pudsey
West Yorkshire
United Kingdom
LS28 7LG
Company Number: 05132767
--
//www.freelists.org/webpage/oracle-l
