Just keep in mind that you can not offline system tablespace ;) 

- Kirti

-----Original Message-----
Sent: Friday, September 20, 2002 2:44 PM
To: Multiple recipients of list ORACLE-L


Nat - I think your process looks fine, bearing in mind that I haven't used
raw devices in years. Others on the list use raw on a daily basis, so may
offer some suggestions. 
   My question was much simpler. Suppose I have a 80-gig. device, and a
20-gig. datafile. Okay, my recollection is that I can use dd to copy that
datafile onto that device. But that leaves 60-gig. (give or take a few megs)
unused. If I copy another datafile to that device, since this isn't a file
system, it will simply overwrite the first file. So I have 60-gig of wasted
space, unless I issue an Oracle command to expand the datafile to use the
rest of the device. You are right, that copying datafiles is MUCH faster
than moving data within Oracle, I'm just curious how you plan to deal with
size mismatches.
   Am I missing something here? 

 
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


-----Original Message-----
Sent: Friday, September 20, 2002 2:09 PM
To: Multiple recipients of list ORACLE-L


Dennis,

We are thinking of doing following steps for our RAW conversions.
Let me know whether it makes sense,

1. Shutdown Database.
2. Take Full Backup
3. Setup all our raw devices ( properly corresponding to our original
filesystem datafiles.)
4. Bring up the database in restricted mode.
4. Bring tablespace offline
5. Use the dd command to move the datafiles to the raw device.
6.  Rename the moved datafile
7. Bring the tablespace online
8. repeat this process till you move all you datafiles.

We feel creating table as select * or export /import is not feasible as our
database is big
(around 400 Gigs ) with very large tables.

Thanks,

----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, September 20, 2002 12:18 PM


Nat - I haven't worked with raw for a few years, but from my dim
recollection, since you are managing what is on the device, first the system
administrator had to tell me how many blocks I could write to. I also dimly
recall the AIX issue, but certainly couldn't recall the answer. Anyway, this
means that you have only a single file on the device. Based on that, my
assumption was that you would want to use the entire disk and it would be
unlikely that your file system file would coincidentally the same size as
your raw device, so you would want to precreate a new tablespace with a
datafile of just the right size. That means that you would need to move the
data itself, not just the datafile. Am I missing something here, or just
brain-dead on Friday?


Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>


-----Original Message-----
Sent: Friday, September 20, 2002 9:33 AM
To: Multiple recipients of list ORACLE-L


Mark,
Thanks for the reply. We are on AIX 4.3.
We are not changing hardware when we move on to RAW devices. Our entire
hardware is going to remain same.
We feel dd is the fastest method of copying the files. But we need to figure
out how many blocks
we should skip in raw devices.(point  2 in NOTES below).
We still do not know how to do that. Metalink says if we use RMAN we do not
need to
do any header calculation . Below is the article from metalink..
Thanks again for your suggestions.

goal: How to convert datafile from raw device to file system

a.. fact: Oracle Server - Enterprise Edition

a.. fix:

Use RMAN to move datafiles from raw devices to file system.

1. Connect to the database:

 $ sqlplus system/manager@orcl

2. Put the tablespace with the datafile, which should be converted, offline:

 SQL> alter tablespace test_ts offline;

3. Start rman and connect it to the database:

 $ rman nocatalog target rman/rman@orcl

4. Move the datafile to file system:

 RMAN> run {
 2> allocate channel c1 type disk;
 3> copy datafile '/dev/raw1' to '/u01/oradata/orcl/test_ts.dbf';
 4> }

5. Rename the moved datafile:

 SQL> alter database rename file '/dev/raw1' to '/u01/oradata/orcl/test_ts.
dbf';

6. Put the tablespace back online:

 SQL> alter tablespace test_ts online;


Notes:
======
1. If you are using RMAN as the backup tool then a backup after the
performed
steps is recommended, because otherwise RMAN treats the copied file as a
backup.

2. Usually Oracle datafiles are moved from filesystem to raw devices using
the dd command. Using dd is the fastest method to accomplish it. However, it
is
necessary to know how many blocks to skip in the raw device (e.g. it is
necessary to skip 64K on Tru64 Unix), so that the information necessary for
the Operating System is not overwritten. The information on how many blocks
to
skip is different on the different platforms. Using RMAN there's no
necessity
to know such platform specific information.

.


----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 5:28 PM


> Hi Nat,
>
> As long as you are not changing hardware platforms, you can use dd.  (Of
> course, I assume you're on some flavor of unix, since you didn't mention
> OS.)
>
> You can just do 'dd if=/path/to/filsystem/datafile
> of=/path/to/raw/volume'.
>
> Of course, your database must be down.
>
> -Mark
>
> On Thu, 2002-09-19 at 14:38, Nat wrote:
> > We are planning to move to raw devices for all our existing file
systems.
> > Our database size is around 400 Gig. What is the recommended method that
you
> > guys feel is best as far as time
> > required to convert and ease of conversion.
> >
> > We feel we cannot use export - import as this may take more time for
> > conversion..
> > I checked many documents to find out  the best method, there are few
> > suggestions to use RMAN to convert to raw.
> > seems it is fastest. At this point we have not configured RMAN on our
> > databases so this suggestion seems to be of no use for us.
> >
> > Please let me know, if any of you went through this exercise and any
> > suggestions and tips will be more beneficial,
> >
> > Thanks in advance,
> --
> --
> Mark J. Bobak
> Oracle DBA
> [EMAIL PROTECTED]
> "It is not enough to have a good mind.  The main thing is to use it
> well."
>   -- Rene Descartes
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Mark J. Bobak
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
> San Diego, California        -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Nat
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Nat
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: DENNIS WILLIAMS
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Deshpande, Kirti
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to