Knowledge From : http://gavinsoorma.com/2012/04/performing-a-database-clone-using-a-data-guard-physical-standby-database/
A common DBA task is to perform regular clones and database refreshes of the production database for the purpose of setting up training or test or development environments.
If we are having a physical standby Data Guard environment, then we can easily offload the potentially I/O and CPU intensive backup process required for creating these clone or duplicate databases to the standby site.
Here are a few examples of using the physical Standby database in a Data Guard environment to create a clone of the primary production database.
In the first example we use RMAN to perform the backup and restore and in the second example we are using OS commands to just copy files ONLINE from Standby host to the target host.
Note that in 11g, we can take the backup of the control file from the Standby database. In 10g, we have to take the backup of the controlfile from the primary database.
I was installing NFS server on otherwise public host recently, and noticed that conventional wisdom about securing NFS server is somewhat dated. My goal was to expose NFS on two internal interfaces without exposing it to whole wide Internet (assumptions about network security changed a lot since NFS was designed, sadly).
For a start, you are probably running rpcbind instead of portmap on recent Debian installations. So you will need to modify flags which are passed to portmap on startup:
root@rsync1:~# cat /etc/default/rpcbind
OPTIONS="-w -l -h 172.16.10.2 -h 192.168.0.219"
You will also need to add following line:
root@rsync1:~# grep rpcbind /etc/hosts.deny
Now you will notice that rpcinfo -p still works OK on localhost. That’s because rpcbind will always add loopback address, so we have to test it from another machine:
root@rsync1-dev:~# rpcinfo -p 192.168.0.219
rpcinfo: can't contact portmapper: RPC: Authentication error; why = Client credential too weak
Standby database process status: You can run following query on standby database to see what MRP and RFS processes are doing, which block of which archivelog sequences are being shipped or being applied.
SQL> select process, status, thread#, sequence#, block#, blocks from v$managed_standby ;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
——— ———— ———- ———- ———- ———-
ARCH CLOSING 1 69479 932864 261
ARCH CLOSING 1 69480 928768 670
ARCH CLOSING 2 75336 933888 654
ARCH CLOSING 2 78079 930816 842
ARCH CLOSING 1 69475 943104 79
RFS IDLE 0 0 0 0