RE: Methods to clone large production database
- From: "Pal, Raj" <Raj.Pal@xxxxxxxxxxxx>
- To: <don@xxxxxxxxx>, <rjamya@xxxxxxxxx>
- Date: Wed, 28 Mar 2007 11:12:20 -0600
9 hours seems long for 750Gb to disk. I'm seeing 10hrs:40min for a
9.8Tb (segment size alone) database. Mind you, there are 32 cpus and
196 Gb mem, but the backup is writing to SAN attached Clariion-ATA disk
(fairly slow... and inexpensive). We're also using 33 channels with not
too much of a performance hit. So for the 750Gb 0hr backup... are you
using a catalog database? If so, how?
Since the original post was for an alternative to RMAN duplicate for the
creation of the other database... try "RMAN copy" of datafiles.
Recovery will be necessary, but "hot-backup-mode" will not be necessary.
When duplicating the database mentioned above, we mount disk to the
host, RMAN copy the datafiles over, and then remount the disk to the
host we want to duplicate the database on. This was only done due to
the size of the database and the fact that we have had past issues with
"hot-backup-mode" for large databases. Works well, so is appropriate
for same host replication if you can't get the duplicate to work.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Don Seiler
Sent: Wednesday, March 28, 2007 9:31 AM
To: rjamya@xxxxxxxxx
Cc: Allen, Brandon; oracle-l@xxxxxxxxxxxxx
Subject: Re: Methods to clone large production database
Prior to RMAN, we would go tablespace-by-tablespace, putting them into
BACKUP mode, then doing a gzip -c to copy and compress the datafiles
on the fly. This was done to disk, and then that disk was copied to
tape the next morning. The whole backup process took less than 3
hours on our ~750gb database, which we did in full every night. We
could do restores for development by basically emulating a disaster
recovery from one of the backups.
Now we're on RMAN on 10gR2, and a level 0 backup takes over 9 hours.
I'm certain that I have some tuning to do, but we're living with doing
one level 0 on Saturday night when we have an extended window without
many users. The rest of the week we do a level 1 with block change
tracking enabled, and it takes 20-40 minutes, which is very nice, and
makes the 9 hour level 0 much more easier to swallow for now. As
before, we backup to disk. I also then use rsync to push copies of
the backup disk slab to our development server as well as a third box
for safe-keeping.
For cloning, I run an RMAN "duplicate database" command. We have a
retention policy of 7 days, so the developers can request a restore to
any point in the last 7 days for their development instances.
Don.
On 3/27/07, rjamya <rjamya@xxxxxxxxx> wrote:
> we use raw files. take hot backup and create a create_controlfile.
After the
> hot backup, we run multiple dd's over private network from one server
to
> another. once those are copied (and renamed) over, we manipulate
control
> file script and create the control file, and preform recovery to the
scn.
> Along with data files, we also copy over archive logs to help in
recovery.
>
> rjamya
>
>
> On 3/27/07, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
> >
> >
> > What exactly is the "raw copy method"? Do you just mean that you
put the
> database/tablespaces in backup mode and copy with the OS utilities?
Or is
> it something to do with raw storage, in which case I didn't think you
could
> use the OS copy utilities, but I'm not really sure since I've never
worked
> with raw storage.
> >
> > Thanks,
> > Branddon
>
--
Don Seiler
http://seilerwerks.blogspot.com
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
