Table PITR and more Table pitfalls 

27th April 2024

Table point in time recovery seems to be the greatest thing since sliced bread until you start to dive under the covers and comprehend how complex and non magical the whole process is.

First point , when you want to increase the speed of this process you should not try to define additional channels directly in the rman script , instead you need to increase the channel parallelism of the target database in the default configuration. If you separately try to allocate channels that will not be applicable for the rman managed auxiliary instance so you will not see any speedup.

Second point you may have seen my post about the undocumented option keep auxiliary, well bad news is that if you do keep your auxiliary it no longer is an rman managed auxiliary database which means the following note is applicable

2050501.1 

OERR: RMAN-5068 "Table Point-in-Time recovery may not be used with user-managed auxiliary instance" Reference Note (Doc ID 2050501.1)

Action: Retry the operation with an RMAN-managed auxiliary instance.

Bummer .

Finally even with a Rman managed auxiliary you may not taste victory because there is another issue you could hit namely

2231855.1

Rman Restore Table Fails with ORA-29283 RMAN-06962 RMAN-06960 ORA-31626 in 12c (Doc ID 2231855.1) 

 The issue is caused because of Low processes value used by the Automatic instance creation.

Creating automatic instance, with SID='pitr'
RMAN-04031:
initialization parameters used for automatic instance:
db_name=test
db_unique_name=pitr_pitr_test
compatible=12.1.0.0.0
db_block_size=8192
db_files=200
sga_target=1G
processes=80   ======================================================> Low value
diagnostic_dest=< diag directory >
db_create_file_dest=< omf directory >
log_archive_dest_1='location=< omf directory >'

#No auxiliary parameter file used

Ideally someone needs to fix this in RMAN itself. 

I have reached out to folks in the ace community, lets see if someone can help on this ?