Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Need help with RMAN duplicate database, hangs on sbtpcstart event.....

Re: Need help with RMAN duplicate database, hangs on sbtpcstart event.....

From: GovindanK <>
Date: Wed, 7 Feb 2007 00:58:15 UT
Message-Id: <>

 Interesting. I was searching for sbtpcstart in Metalink and found that you had solved it by mentioning nofilenamecheck.

On Tue, 6 Feb 2007 11:27:45 -0500, "Bobak, Mark" <> said:


  I'm running on Sparc Solaris 9, and I'm trying to duplicate a database via RMAN.

  Here's what I'm doing.

  First, to connect, I do:

  rman target / catalog rman/rman_at_rmancat auxiliary "sys/******@pep1"

  Then I run:
  run {
  allocate auxiliary channel t1 type sbt_tape;   set until time "to_date('Feb 02 2007 08:00:00','Mon DD YYYY HH24:MI:SS')";   DUPLICATE TARGET DATABASE to pep1 nofilenamecheck   LOGFILE

  GROUP 1 ('/dev/vx/rdsk/redodg/pep1-redo01a','/dev/vx/rdsk/redodg/pep1-redo01b') size 199M reuse,
  GROUP 2 ('/dev/vx/rdsk/redodg/pep1-redo02a','/dev/vx/rdsk/redodg/pep1-redo02b') size 199M reuse,
  GROUP 3 ('/dev/vx/rdsk/redodg/pep1-redo03a','/dev/vx/rdsk/redodg/pep1-redo03b') size 199M reuse,
  GROUP 4 ('/dev/vx/rdsk/redodg/pep1-redo04a','/dev/vx/rdsk/redodg/pep1-redo04b') size 199M reuse,
  GROUP 5 ('/dev/vx/rdsk/redodg/pep1-redo05a','/dev/vx/rdsk/redodg/pep1-redo05b') size 199M reuse,
  GROUP 6 ('/dev/vx/rdsk/redodg/pep1-redo06a','/dev/vx/rdsk/redodg/pep1-redo06b') size 199M reuse,
  GROUP 7 ('/dev/vx/rdsk/redodg/pep1-redo07a','/dev/vx/rdsk/redodg/pep1-redo07b') size 199M reuse,
  GROUP 8 ('/dev/vx/rdsk/redodg/pep1-redo08a','/dev/vx/rdsk/redodg/pep1-redo08b') size 199M reuse;

  In terms of output, I get:
  allocated channel: t1
  channel t1: sid=20 devtype=SBT_TAPE
  channel t1: VERITAS NetBackup for Oracle - Release 5.1 (2006040521)   executing command: SET NEWNAME
  Starting Duplicate Db at 06-FEB-07
  Then I get all the auto-generated NEWNAME commands from specifying nofilename.

  Finally, I get:
  Starting restore at 06-FEB-07
  channel t1: starting proxy datafile restore   channel t1: specifying datafile(s) for proxy restore   restoring datafile 00001 to /oracle/tmpdata/system_test   proxy file handle=bk_5945_41_613681223_ppi98227_41_1   restoring datafile 00002 to /dev/vx/rdsk/prd1dg/vtools01   proxy file handle=bk_5945_30_613681223_ppi98227_30_1   restoring datafile 00003 to /dev/vx/rdsk/prd1dg/vtools02   proxy file handle=bk_5945_42_613681223_ppi98227_42_1   restoring datafile 00004 to /dev/vx/rdsk/prd1dg/vpqdsidx01   proxy file handle=bk_5945_43_613681223_ppi98227_43_1   restoring datafile 00005 to /dev/vx/rdsk/prd1dg/vpqdsidx02   proxy file handle=bk_5945_44_613681223_ppi98227_44_1   restoring datafile 00006 to /dev/vx/rdsk/prd1dg/vpqdmidx01   proxy file handle=bk_5945_3_613681223_ppi98227_3_1   restoring datafile 00007 to /dev/vx/rdsk/prd1dg/vpqdmidx02   proxy file handle=bk_5945_45_613681223_ppi98227_45_1   restoring datafile 00008 to /dev/vx/rdsk/prd1dg/vpqdmidx03   proxy file handle=bk_5945_46_613681223_ppi98227_46_1   restoring datafile 00009 to /dev/vx/rdsk/prd1dg/vpqdmidx04   proxy file handle=bk_5945_47_613681223_ppi98227_47_1   restoring datafile 00010 to /dev/vx/rdsk/prd1dg/vascxlidx41   proxy file handle=bk_5945_31_613681223_ppi98227_31_1   restoring datafile 00011 to /dev/vx/rdsk/prd1dg/vascxlidx42   proxy file handle=bk_5945_32_613681223_ppi98227_32_1   restoring datafile 00012 to /dev/vx/rdsk/prd1dg/vdocxlidx41   proxy file handle=bk_5945_335_613681223_ppi98227_335_1   …

  And that continues for all the datafiles, and then it hangs……

  If I look at V$SESSION_WAIT on the auxiliary server, I see it's waiting on sbtpcstart wait event. I left it running over night. It waited on that event for over 20 hours.

  Does anyone have any idea what's going on here??



  Mark J. Bobak
  Senior Oracle Architect
  ProQuest Information & Learning

  There is nothing so useless as doing efficiently that which shouldn’t be done at all. –Peter F. Drucker, 1909-2005

Received on Tue Feb 06 2007 - 18:58:15 CST

Original text of this message