Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Using Windows' SUBST to avoid ALTER DATABASE RENAME FILEs?

Re: Using Windows' SUBST to avoid ALTER DATABASE RENAME FILEs?

From: Jacob Share <jacobshare_at_yahoo.com>
Date: Fri, 7 May 2004 09:40:15 +0200
Message-ID: <2g0st3F3bc5hU1@uni-berlin.de>


Michel,
Merci pour la réponse rapide.

I know that at the Windows level, I would normally need to add the desired subst commands in an autoexec.bat to be called at each server boot, since the virtual drives disappear on shutdown.

In our case, the virtual drives will only be used for Oracle instances, so it would be even cleaner to only add the subst commands in the corresponding instances' startup routines. Do you agree? Is this sufficient for the databases to find their pieces at every server reboot?`

Thanks

Jacob

"Michel Cadot" <micadot{at}altern{dot}org> a écrit dans le message de news:409a717b$0$18319$626a14ce_at_news.free.fr...
>
> "Jacob Share" <jacobshare_at_yahoo.com> a écrit dans le message de
> news:9d4c10f3.0405060228.4f479528_at_posting.google.com...
> > Our local deployment strategy uses a standard directory structure for
> > each db instance : <Volume:>/Oracle/<SID>/etc. We need a remote site
> > to send us backups that we'll validate after local restoration. The
> > problem is that they weren't careful and didn't use a standard
> > directory structure. In addition, their .DBFs are spread over many
> > more logical disk partitions than necessary. We're unwilling to
> > replicate this bad practice locally but we want restorations to be as
> > quick and easy as possible (who doesn't?).
> >
> > To get around the need to do many ALTER DATABASE RENAME FILEs at every
> > restoration, we're exploring the idea of using the Windows SUBST
> > command to create virtual drives locally, and then using symbolic
> > links (Win2k's 'junctions') to fill out the structure required by the
> > restored dbs. This way the restored databases would find their pieces
> > where they expect, but in reality they'll be nicely arranged according
> > to our standard.
> >
> > My questions -
> > 1) Will this work?
> > 2) If so, will there be a performance hit?
> > 3) If so, on what order? The local installation is in a development
> > environment, so we'd be willing to accept a certain performance hit if
> > it will save time and keep things clean.
> >
> > We're using Oracle 8.1.7 on Windows 2000 SP3.
> >
> > Thanks
> >
> > Jacob Share
>
> I don't answer all your questions just one: you can use subst
> (Oracle 8.1.7.4, WinNT4):
>
> SVRMGR> host subst o: D:\Oracle\Bases\Mike
> SVRMGR> host dir o:
> Le volume dans le lecteur O s'appelle Michel bis
> Le numéro de série du volume est 2499-EB17
>
> Répertoire de O:\
>
> 06/04/04 17:25 <DIR> .
> 06/04/04 17:25 <DIR> ..
> 30/04/04 22:36 10 022 912 CTL1.ORA
> 06/05/04 18:52 131 584 RL_G1_1.ORA
> 06/05/04 18:52 131 584 RL_G2_1.ORA
> 06/05/04 18:52 131 584 RL_G3_1.ORA
> 06/05/04 18:52 131 584 RL_G4_1.ORA
> 06/04/04 17:25 131 584 RL_G5_1.ORA
> 30/04/04 22:36 1 052 672 TEST2_01.DBF
> 30/04/04 22:36 20 975 616 TS_D0101.ORA
> 30/04/04 22:36 10 489 856 TS_I0101.ORA
> 30/04/04 22:36 20 975 616 TS_R0101.ORA
> 30/04/04 22:36 83 890 176 TS_S0101.ORA
> 30/04/04 22:36 10 489 856 TS_T0101.ORA
> 14 fichier(s) 158 554 624 octets
> 628 465 664 octets libres
> SVRMGR> create tablespace foo datafile 'o:\foo.dbf' size 10m;
> Statement processed.
> SVRMGR> host dir o:
> Le volume dans le lecteur O s'appelle Michel bis
> Le numéro de série du volume est 2499-EB17
>
> Répertoire de O:\
>
> 06/05/04 18:53 <DIR> .
> 06/05/04 18:53 <DIR> ..
> 06/05/04 18:53 10 022 912 CTL1.ORA
> 06/05/04 18:53 10 489 856 FOO.DBF <------------------
> 06/05/04 18:52 131 584 RL_G1_1.ORA
> 06/05/04 18:52 131 584 RL_G2_1.ORA
> 06/05/04 18:52 131 584 RL_G3_1.ORA
> 06/05/04 18:52 131 584 RL_G4_1.ORA
> 06/04/04 17:25 131 584 RL_G5_1.ORA
> 30/04/04 22:36 1 052 672 TEST2_01.DBF
> 30/04/04 22:36 20 975 616 TS_D0101.ORA
> 30/04/04 22:36 10 489 856 TS_I0101.ORA
> 30/04/04 22:36 20 975 616 TS_R0101.ORA
> 30/04/04 22:36 83 890 176 TS_S0101.ORA
> 30/04/04 22:36 10 489 856 TS_T0101.ORA
> 15 fichier(s) 169 044 480 octets
> 627 150 848 octets libres
> SVRMGR> host dir D:\Oracle\Bases\Mike
> Le volume dans le lecteur O s'appelle Michel bis
> Le numéro de série du volume est 2499-EB17
>
> Répertoire de D:\Oracle\Bases\Mike
>
> 06/05/04 18:53 <DIR> .
> 06/05/04 18:53 <DIR> ..
> 06/05/04 18:53 10 022 912 CTL1.ORA
> 06/05/04 18:53 10 489 856 FOO.DBF

<------------------------

> 06/05/04 18:52 131 584 RL_G1_1.ORA
> 06/05/04 18:52 131 584 RL_G2_1.ORA
> 06/05/04 18:52 131 584 RL_G3_1.ORA
> 06/05/04 18:52 131 584 RL_G4_1.ORA
> 06/04/04 17:25 131 584 RL_G5_1.ORA
> 30/04/04 22:36 1 052 672 TEST2_01.DBF
> 30/04/04 22:36 20 975 616 TS_D0101.ORA
> 30/04/04 22:36 10 489 856 TS_I0101.ORA
> 30/04/04 22:36 20 975 616 TS_R0101.ORA
> 30/04/04 22:36 83 890 176 TS_S0101.ORA
> 30/04/04 22:36 10 489 856 TS_T0101.ORA
> 15 fichier(s) 169 044 480 octets
> 627 150 848 octets libres
> SVRMGR> select file_name from dba_data_files where tablespace_name='FOO';
> FILE_NAME
> -------------------------------------------------------------------------
> O:\FOO.DBF
>
> 1 row selected.
> SVRMGR> create table t (col number) tablespace foo;
> Statement processed.
> SVRMGR> insert into t values(0);
> 1 row processed.
> SVRMGR> select * from t;
> COL
> ----------
> 0
> 1 row selected.
> SVRMGR> drop table t;
> Statement processed.
> SVRMGR> drop tablespace foo;
> Statement processed.
>
> Regards
> Michel Cadot
>
>
Received on Fri May 07 2004 - 02:40:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US