RDBMS -- XTTS (+incremental backups) from Active Dataguard / not supported! /not working! & how does XTTS scripts do these endian conversions of incremental backups?

Hi all,

I just want to highlight something important.

That is;
If we want to use XTTS (Cross Platform Transportable Tablespace) method and reduce its downtime with rman incremental backups; our source database can't be a standby.. It also can't be an Active dataguard environment.

This is because, the script which is in the core of the XTTS method powered by incremental backups, just checks if there are any tablespaces in READ ONLY or OFFLINE mode. Actually it wants all to the tablespaces which are wanted to be migrated, to be in READ WRITE mode.

If the scripts finds a READ ONLY tablespace, it just raises and error ->

RAISE_APPLICATION_ERROR(-20001, 'TABLESPACE(S) IS READONLY OR,
OFFLINE JUST CONVERT, COPY');

I just want to highlight this, as you may be planning to use an Active Dataguard environment for the source database in an XTTS (+incremental backups) based migration project.. As you know, in active dataguard we have read only tablespaces, so this might be an issue for you.

Anyways, actually I was also curios about this READ-WRITE requirement of XTTS (+incremental backups) and yesterday I jumped into the XTTS scripts.

Unfortuneatly, I couldn't find anything about it there.. I couldn't still answer the question Why? Why XTTS(+incremental) method requires the source tablespaces to be in READ-WRITE mode..

However, the perl script named xttdriver.pl just checks it. I couldn't find any clue (no comments in the scripts, no documentation, nothing on web) about this requirement, but look what I have found :)

->

In 12C, RMAN has the capability to convert backups.. In 12C, rman can convert the backup even in cross platform and XXTS actually use this rman's capability to convert the incremental backups from source to target platform..

So if your database is 12C, XTTS (those scripts I mean) use "backup for transport" and "restore from platform" syntax of rman  to convert your backups.

Ofcourse, if your database is an 11G, then those rman commands are not available.. 

So what XTTS does for converting your backups in 11G environments, is using the "sys.dbms_backup_restore" package..

XTTS use it similar to the following form to convert the incremental backups to target platform:

sys.dbms_backup_restore.backupBackupPiece(
bpname => '&&1',
fname => '&&2/xtts_incr_backup',
handle => handle, media => media, comment => comment,
concur => concur, recid => recid, stamp => stamp, check_logical => FALSE,
copyno => 1, deffmt => 0, copy_recid => 0, copy_stamp => 0,
npieces => 1, dest => 0,
pltfrmfr => &&3); --attention here, it gets the platform id 
EXCEPTION
WHEN OTHERS
THEN
DBMS_OUTPUT.put_line ('ERROR IN CONVERSION ' || SQLERRM);
END ;

Also, XTTS applies those converted backups to the datafiles using

"sys.dbms_backup_restore.applyDatafileTo", "sys.dbms_backup_restore.restoreSetPiece" and sys.dbms_backup_restore.restoreBackupPiece".

So, it is still not answered why XTTS(+incremental backups) needs the tablespaces in source to be in READ-WRITE mode, but it is certain that, what XTTS method does is not a magic :) 

I mean, XTTS scripts just do a very good orchestration.. The perl scripts used in XTTS doesn't do conversion using perl capabilities. (note that: endian conversion can also be done using perl functions inside the perl.. ) 

It is actually a  good thing though. I mean, if XTTS scripts would use the perl itself to convert the files, then it will be more complicated right?

Anyways, this made me think that; this XTTS related conversion can even be made manually by executing the necessary rman commands, calling the necessary dbms_backup_restore calls and using exp/imp.. However, it would be a little bit complex, and there would be a support issue for that :)

Well.. That's it.. I just wanted to share this little piece of information, as I found it interesting.

One more thing, before finishing this :) -> 

I must admit that, the rman's convert capability in 12c seems very handy.. So being in 12C is not only good, as it is an up-to-date release (fixed bugs etc..), but it is also good for easing the migration approaches.

One last thing; XTTS method doesn't support compressed backupsets. So the backups used in XTTS must not be compressed backups.. ( else you get -> ORA-19994, "cross-platform backup of compressed backups to different endianess is not supported")

I will revisit this blog post, if I will find the answer for the question -> why does XTTS(+incremental) requires source tablespace to be in READ-WRITE mode? why is there such a restriction? Also you.. If you have an idea, please comment.