RE: PITR with BIGFILE tablespace

It would be useful to see if there is a consistent "always works - always fails" size boundary, but that would also be a tedious binary search. IF we had such a boundary as a known (or could not find limit in the usual and routine case) that would also be a useful think to know whether we should be trouble shooting Mladen's case from the standpoint "it fails because it is too large a bigfile point in time recovery" versus something else.

Thanks for the precise clarifications, gentlemen.

What am I bid for the largest bigfile successfully recovered to a point in time?

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala Sent: Saturday, March 06, 2021 12:01 PM
To: Shane Borden
Cc: ORACLE-L
Subject: Re: PITR with BIGFILE tablespace

Hi Shane,

I didn't receive any help from support. I was unable to restore the pluggable database with a bigfile (8.7 TB) tablespace. Oracle is 12.2 with July 2020 patch. I didn't do anything special except specifying section size=32GB. Platform is Linux, running on ASM. The statement about testing is my personal conjecture.

Regards

On 3/6/21 4:29 AM, Shane Borden wrote:
> What am I missing? I’ve done many PITR on pluggable databases with BIGFILE table spaces with no issues.
>
> Also is ORACLE saying that they don’t test RMAN with big files? Sounds like a rogue support person because I can’t believe that. I’d be raising hell if that’s true.
>
> Shane Borden
> sborden76_at_yahoo.com
> Sent from my iPhone
>
>> On Mar 5, 2021, at 11:19 PM, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:
>>
>> I was lazy and I created a BIGFILE tablespace to alleviate the pain with constant space monitoring and adding 32767M files to the tablespace. However, there was a logical corruption caused by running a wrong script on the schema, so I was told to restore the pluggable database to the point in time before the script was run. And that is where the trouble started:
>>
>> 915389 alter database recover datafile list clear
>> 915390 Completed: alter database recover datafile list clear
>> 915391 2021-03-03T22:13:09.935629-05:00
>> 915392 RMAN In-place recover pluggable database id 3 to scn 0
>> 915393 Pluggable Database PSH_8141 (3) incomplete recovery start set
>> at change 45008648710, at 03/03/2021 10:30:55
>> 915394 Pluggable Database Media Recovery Start
>> 915395 2021-03-03T22:13:09.939521-05:00
>> 915396 Serial Media Recovery started
>> 915397 Pluggable Database Media Recovery Log
>> /data/archive/1_65868_1031066218.dbf
>> 915398 2021-03-03T22:13:12.996469-05:00
>> 915399 Incomplete Recovery applied until change 44962012457 time
>> 03/03/2021 09:00:15
>> 915400 Errors in file /app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_86417_86514.trc (incident=13548103) (PDBNAME=CDB$ROOT):
>> 915401 ORA-00600: internal error code, arguments:
>> [kcpSetPDBIncompleteRecoverySCN-1], [44962012457], [45008648710], [],
>> [], [], [], [], [], [], [], []
>> 915402 Incident details in:
>> /app/oracle/diag/rdbms/orcl/orcl/incident/incdir_13548103/orcl_ora_86
>> 417_86514_i13548103.trc
>> 915403 2021-03-03T22:13:14.351287-05:00
>> 915404 Some DDE async actions failed or were cancelled
>> 915405 2021-03-03T22:13:14.407330-05:00
>> 915406 Use ADRCI or Support Workbench to package the incident.
>>
>> Long story short, the tenant was lost. It was impossible to do PITR on the tablespace with 8.7 TB file. I even tried recovering the whole database. I contacted the Oracle support but they weren't able to help. The Oracle version is 12.2.0.1, the platform is Linux x86_64. Be aware that bigfile tablespaces can result in the inability to do point in time recovery. I haven't tried the complete recovery, because that would also bring back the results of the "masking" script. Apparently, Oracle isn't testing backup and recovery with the bigfile tablespaces, so surprises are possible. I thought that the feature will be stable by 12.2, but alas, no luck.
>>
>>
>> --
>> Mladen Gogala
>> Database Consultant
>> Tel: (347) 321-1217
>> https://dbwhisperer.wordpress.com
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>

--
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