Hemant K Chitale said...You created the backup (datafile copy) on '/host/backups/prod'. This is *seperate* from the NFS from "nas1" ?
So, effectively, you used 2 NFS mounts, /host/backups/prod accessible from both Production and Clone server and /u01/nfs_shares/clonedb/test mounted only on the Clone server ?
The backup is a Datafile copy. Does clonedb.pl expect only a Datafile copy backup ? It cannot work with RMAN BackupSets to use RMAN RESTORE ?
(RMAN BackupSets would have an obvious advantage -- disk space requirements for /host/backups/prod would be lesser).
Your example does not show a RECOVER DATABASE which would have been necessary for a Datafile backup created with 'BEGIN BACKUP','END BACKUP' ?
1) Read the text. The backup location in this case is a CIFS share, not NFS. The backup files are read-only, so it doesn't matter how they are presented. They can be CIFS, NFS, local files etc.
2) Yes. Must be datafile copies. Backup sets are not supported.
3) Yes. If files are fuzzy then recovery would be needed. This is done just like any other database. Recover by applying the archived redo logs. It was unnecessary here as database had no activity during backup and didn't ask for recovery. More information about recovery will come with the MOS note (I believe).
Hemant K Chitale said...Yes, I didn't differentiate between CIFS and NFS (I don't see a difference in this being CIFS or NFS). In either case, the backup location is separate from the NFS from "nas1". So, we have 1 full datafile copy of the database to CIFS and then that copy is copied by RMAN to the NFS mount point.
My point was "So, effectively, you used 2 NFS mounts" (or "1 CIFS and 1 NFS mount").
The prod datafiles are on a local drive. The RMAN backup makes datafile copies to CIFS. The clone server reads directly from the CIFS share and only write changed blocks to the NFS share.
There is only 1 NFS mount (the clone copy-on-write location). RMAN never uses an NFS share in my example. The backup is never copied to the NFS share, it always stay on the CIFS share.
The point of using CIFS rather than NFS is I wanted to show the only bit that is using the DNFS Clonedb feature is the copy-on-write. You could easily copy the backup files onto a local file system on the clone server and run it from there.
So no, there are not two NFS locations, and no, RMAN doesn't copy the datafile copies from CIFS to NFS.
Brooks said...Great article. One thing that may be worth noting is that the file sizes reported back by the ls command for the change files are actually full sized. I went through the process several times thinking I was doing something wrong because I kept ending up with full size files. It wasn't until I realized you were using the du command to show that the files were actually small.
I've added a sentence to make that point a little clearer, so the next reader won't get confused.
Thanks for the heads-up.
Victor said...when i execute the @dbrem.sql,here is the problem occurs:
alter database open resetlogs
ERROR at line 1:
ORA-01190: control file or data file 1 is from before the last RESETLOGS
Then i check the SCN,here is the result:the scn for the v$database is 786175,the scn for the v$datafile is also 786175,but for the v$datafile_header is 786174,i tried a few times,but the result is the same.
Try again, but this time but the database into backup mode before creating the image copy backup. It is in the script, but commented out.
It is a wonderful article to discuss thin technology to clone database.
Do you try to clone second instance using incremental image copy level 1 when the first instance is still using image copy level 0 ?
Remember, anything that is not in the initial image file copy will need to be recovered and those recovered blocks will be written to the copy-on-write location, so as not to affect the original image copy backups. You can recover different clones to different time points, but you will reduce overall space savings.
DO NOT ask technical questions here! They will be deleted!
These comments should relate to the contents of a specific article. Constructive criticism is good. Advertising and offensive comments are bad and will be deleted!
If you post personal information (name, email address etc.) you are agreeing to them being stored and displayed. Feel free to remain anonymous.