I have read the documentaton and I am still stuck. Here is what I
have done so far.

1. Rman target / nocatalog
2. Startup nomount
3. Set dbid to dbid of old database
4. Set oracle_sid to sid of old database
5. Restore spfile to pfile 'location of pfile' from 'location of
autobackup file';
6. Restore controlfile from 'location of autobackup file';
7. Alter database mount

When I get to step 7 it tells that ora-01103: databse name 'old
database name' in controlfile is not 'new database name' How can i
get around this? Or better yet what book is this located in so i can
do a test restore. Thanks in advance.

On Fri, 25 May 2007 15:02:23 -0700, cptkirkh wrote:

Parameter db_name must be the same for the source database ("target") and
the clone ("auxiliary").

--
http://www.mladen-gogala.com

On May 25, 5:27 pm, Mladen Gogala <mgogala.SPAM_ME.... (AT) verizon (DOT) net>
wrote:
So can I jsut create a new DB on the the new server with the same name
as the old DB?

On May 29, 9:37 am, cptkirkh <k... (AT) scic (DOT) com> wrote:
short answer, yes.

On May 29, 10:21 am, EscVector <J... (AT) webthere (DOT) com> wrote:
Ok with that in mind I have one more question. If the server I am
using to do a test restore has a database with the same name and if
there is an application on that server that connects to the production
DB will the application be able to connect to the production DB after
I create a DB by the same name?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cptkirkh wrote:

Naming has little to do with it (or everything...).
As the application connects to the production db, which is
on another machine (names....), the application will still
connect to the original database instance, not the clone.

Depends somewhat on how the application connects:
- - using jdbc, the connection would be of the form
machine_name:listener_port:service_name.
- - using Oracle Net, the connection would either be using
the same form, or a TNS alias.

In the first case, the machine name differs, so the application
will connect to the original database instance.
In the seconds case, you either have the first case, or your
TNS alias would point to the original machine, causing the
application to connect to the original database instance.

In short: it will connect to the original one, unless you
change the way the application connects. You may consider
defining duplicate connections - SQL*Net does try all defined
connections sequentially, until the connection succeeds (or
fails completely, of course)
- --
Regards,
Frank van Bortel

Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFGXGayLw8L4IAs830RAp1lAKCX9stXOAKEhi0QzDQUEZ 0g+8GJuQCeKCXe
C0LSujKkioBUrMuWjqEiHJc=
=J0CK
-----END PGP SIGNATURE-----

On May 29, 12:45 pm, Frank van Bortel <frank.van.bor... (AT) gmail (DOT) com>
wrote:
Thnaks Frank... after talkign to one of the developers I think I am
going to move the app and then do the restore.

On May 29, 11:18 am, cptkirkh <k... (AT) scic (DOT) com> wrote:
If you have metalink access, a search on:
dbid RMAN
may be quite informative. Note: 360962.1 is pretty interesting.

jg
--
@home.com is bogus.
Pocket pacman: http://www.signonsandiego.com/uniont...s_1b29key.html