Consider going to tablespaces where all the extents are of a uniform size.
I.e., all objects in any one tablespace have the same INITIAL and NEXT
storage parameters.  These tablespaces will never need to be defragmented.

I'm not sure that your outlined procedure will work.  I think that your
cold backup from the 2nd machine will be out of synch (timestamp-wise) with
your control files.  It may be possible to do some recovery to overcome
this but I'm not familiar with that.

You could do an export from the 2nd machine, drop the tablespace(s) on the
1st machine, and do in import.

If you have data that is changing a lot over time, then you could get set
all the objects' NEXT parameter to a uniform size and the tablespaces will
coalesce naturally over time.



                                                                                       
            
                    Harvinder Singh                                                    
            
                    <Harvinder.Singh@Metr        To:     Multiple recipients of list 
ORACLE-L      
                    aTech.com>                   <[EMAIL PROTECTED]>                
            
                    Sent by:                     cc:                                   
            
                    [EMAIL PROTECTED]             Subject:     Better Way Of 
DeFragmentation        
                                                                                       
            
                                                                                       
            
                    09/20/2001 10:35 AM                                                
            
                    Please respond to                                                  
            
                    ORACLE-L                                                           
            
                                                                                       
            
                                                                                       
            




Hi,

We have to defragment one of our production databases..(objects are not
properly sized)..
Since i can't shutdown database for more than 2 hrs and database is read
only and  DML
statements run thru batch jobs 2 days in month. We r thinking of using the
following scheme.

1) export the particular application schema name NMDD of production
database.
2) On second machine run the DDL script which creates all the objects with
proper sizing.
3) Import the data from export taken in step 1.
4) take the cold backup of 2nd machine.
5) copy the backup files from 2nd machine to production machine.....

Is there any better way to get rid of fragmentation without using any third
party tool..
or Is there any flaw in above procedure.

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

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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: 
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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