I’m not shure, though, whether tmp.mount.hm4: After swap.target is releated, really, because the implemented change is already present on my systems (systemd‘s). I’m much more tending to suspect widespread storage fragmentation on the swap area to cause the relatively long term swap off run-times. In addition, I almost only experienced the issue for systems that have been up for a longer number of days, say from 90 days onwards.
I already published a post about rman> duplicate... a couple of years ago (Rman duplicating an oracle database in a new sid two host scenario), still on 10g at that time and using a backup set being transfered to a new host. With 11g, however, rman> duplicate... offers another option to not only restore from a source backup, leaving source online, but from an up and running database (with takes archivelog mode and some rman catalogued entries in the control file or catalogue nevetheless). Following below therefore, I’m going to show the do’s for an rman> duplicate ... from active database... in a same host scenario, on windows again, using orapwd and oradim as well as lsnrctl this time. The main difference, however, is employing the spfile clause of the duplicate command, such that rman will set up the destination spfile on its own. Only some file name mappings, actually like before, need to be specified. My main reference to review any new features was Duplicating a Database from the oracle 11g1 docs, other references, concerning errors that showed up underway, will be given below.
Ok, working on the same host, nothing is due to be done for software installation and stuff and we can immediately set up the new instance (note that source will be denoted tgt, for target and the destination aux for auxiliary, respectively). Firstly, we create a new password file for destination, with the same sysdba password as on source.
cd /d e:\oracle\product\11.2.0\dbhome_1\database
orapwd file=PWDAUX.ora ignorecase=y force=y
Wanted to write this post for ages… More than ever to record my findings and sample applications of this, in words, really really powerful sql statement with all its options and, well, probable pitfalls. Credits to be premetioned go to Tim @ oracle-base.com for the 9i introduction of merge (MERGE Statement) and the according 10g update (MERGE Statement Enhancements in Oracle Database 10g). I also used the latest docs @ Oracle being of 12c (MERGE), not revealing any newer functionality beyond 10g.
Ok so, what’s important to understand first? The basic idea? Well, from my point of view and generally spoken, merge always applies a source dataset to a target dataset by behalf of selecting from source and target via a join condition. No matter where the dataset comes from or goes to, a table or a view or whatever, one should quite simply always think of a source and a target selection in action. The basic pseudo-code statement may so far just look like so, executing the matched or not matched blocks when the target-source-join-conditions become true or false.
merge into __target__ using ( __source__ )
on ( __target-source-join-conditions__ )
when matched then
update set col = val, ...
delete where __target-delete-conditions__
when not matched then
insert (col, ...) values (val, ...)