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.

EBS R12 (12.1) -- interesting behaviour of adpatch -- HOTPATCH Error -> "You must be in Maintenance Mode to apply patches"

There is an interesting behaviour of adpatch, that I wanted to share with you.
This behaviour of adpatch was observed in an EBS 12.1 environment, during an attempt for hot-patching.
What I mean by this interesting behaviour is, actually the exception that adpatch throws during an ordinary hotpatching session. I mean the error that adpatch returned -> "You must be in Maintenance Mode to apply patches"..

As you already know, in EBS 12.1, we can apply patches without enabling maitanence mode.
All we have to do is taking the risk :) and execute the adpatch command with options=hotpatch argument.
This is a very clear thing, that you already know. But what if we try to apply a regular patch(non-hotpatch) and fail just before applying our hotpatch?

As you may guess, adpatch will ask us the question "Do you wish to continue with your previous AutoPatch session [Yes] ?"?
So if we answer Yes and if our previous patch attempt wasn't for applying a hotpatch ( I mean if the previous patch was tried to be applied without the options=hotpatch argument), then the "options=hotpatch" will make adpatch confused.

At this point, adpatch will say "you are trying to apply a patch with options=hotpatch, but you didn't use "options=hotpatch" in your previous patching attempt. As you wanted to continue with your previous Autopatch session, I will take the value of the argument named options regarding your previous patching attempt."

Just after saying that, adpatch will check the previous patching attempt and it will see that the command that you used in the previous patching attempt was "adpatch"(options specified wasn't specificed)..
However; now you are supplying "options" as an argument..

At this point, adpatch will replace your options argument with "NoOptionsSpecified" . It is because you didn't used options argument in your previous patching attempt/session.
So, the adpatch command will become like "adpatch NoOptionsSpecified" .. Weird right? :) but true.. And I think this is a bug.. adpatch should properly handle this situation, but unfortuneatly, it is not able to do so.. Anyways; I won't go into the details..

Then, adpatch will try to apply the patch in question, and it will see the NoOptionsSpecified.

Then quest what? :)

adpatch will report a warning -> "Ignoring unrecognized option: "NoOptionsSpecified"."

So, it will ignore NoOptionsSpecified argument (options=hotpatch was already replace before) and normally it will stop and say -> " You must be in Maintenance Mode to apply patches. You can use the AD Administration Utility to set Maintenance Mode. "

What is lesson learned here? :)
-> after a failed adpatch session, don't say  YES to the question ("Do you wish to continue with your previous AutoPatch session"), if you want to apply a hotpatch just after a failed adpatch session (regular/non-hotpatch session.)

Here is a demo for you ->

[applr12@ermanappsrv  17603319]$ adpatch options=hotpatch
Your previous AutoPatch session did not run to completion.
Do you wish to continue with your previous AutoPatch session [Yes] ?

AutoPatch warning:

The 'options' command-line argument was not specified originally,

but is now set to:

"hotpatch"

AutoPatch will use the original value for 'options'.

AutoPatch warning:

Ignoring unrecognized option: "NoOptionsSpecified".

AutoPatch error:

You must be in Maintenance Mode to apply patches.

You can use the AD Administration Utility to set Maintenance Mode.