Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Example:  Converting Tablespace on the Target Platform

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.


Suppose there is a need to transport tablespaces RESEARCH, datafiles /oracle/oradata/rec/rec01.dbf and /oracle/oradata/rec/rec02.dbf, and PL, datafiles /oracle/oradata/pl/proj01.dbf and /oracle/oradata/pl/proj02.dbf, from a source database running on a Sun Solaris host to a destination database running on a Linux PC host. The plan is to perform conversion on the target host. The unconverted datafiles will be temporarily stored in the directory /tmp/oracle/transport_solaris/ on the target host. When the datafiles are plugged into Oracle, they will be stored in /oradata/oracle/rec/.

The example assumes that the following steps have been carried out in preparation for the tablespace transport:

The source tablespaces to be transported are set to be read-only, the Export utility has been used to create the metadata information file, which is named research.dchmp, the research.dmp and the unconverted tablespace datafiles to be transported have been gathered and copied to the destination host, to the /tmp/oracle/transport_solaris/ directory.

The subdirectory structure from the files original location has been preserved, that is, the datafiles are stored as:

/tmp/oracle/transport_solaris/rec/research01.dbf
/tmp/oracle/transport_solaris/rec/research02.dbf
/tmp/oracle/transport_solaris/pl/proj01.dbf
/tmp/oracle/transport_solarisr/pl/proj02.dbf

Now RMAN's CONVERT command can be used to convert the datafiles to be transported into the destination host's format and deposit the results in /oracle/oradata/rec.

The following should be noted:

* Datafiles must be identified by their names, not by their tablespace name. The local instance has no way of knowing the desired tablespace datafile names until the tablespace is plugged in.

* The FORMAT argument controls the naming and location of the converted datafiles.

* The source or destination platform cannot be specified by the user. RMAN determines the source platform by examining the datafile, and the target platform defaults to the platform of the host running the RMAN conversion.

% rman TARGET /
RMAN> CONVERT DATAFILE='/tmp/oracle/transport_solaris/*'
DB_FILE_NAME_CONVERT=
'/tmp/oracle/transport_solaris/research', '/oracle/oradata/rec/research',
'/tmp/oracle/transport_solaris/pl','/oracle/oradata/pl'

The result is a set of converted datafiles in the /oracle/oradata/rec/ and /oracle/oradata/pl directories, named thus:

/oracle/oradata/rec/research01.dbf
/oracle/oradata/rec/research02.dbf
/oracle/oradata/pl/proj01.dbf
/oracle/oradata/pl/proj02.dbf

Now follow the usual method for tablespace transport. Use Import to plug the converted tablespaces metadata into the new database, and as a final step, make the tablespaces read-write if needed.

Bigfile Tablespace Overview

A bigfile tablespace (BFT) is a tablespace containing a single file that can have a very large size. The traditional tablespace is referred to as a smallfile tablespace (SFT). A SFT contains multiple, relatively small files.  The BFT has the following characteristics:

* An Oracle database can contain both bigfile and smallfile tablespaces.

* System default is to create the traditional SFT.

* The SYSTEM and SYSAUX tablespaces are always created using the system default type.

* BFT?s are supported only for locally managed tablespaces with automatic segment-space management. There are two exceptions when BFT segments are manually managed: Locally managed undo tablespace and Temporary tablespace

BFT?s are intended to be used with Automated Storage Management (ASM) or other logical volume managers that support RAID.  However, it can also be used without ASM.

BFT Benefits

BFT has the following benefits:

* It simplifies large database tablespace management by reducing the number of datafiles needed.

* It simplifies datafile management with Oracle-managed files and ASM by eliminating the need for adding new datafiles and dealing with multiple files.

* It allows the creation of a BFT of up to eight exabytes in size, and significantly increases the storage capacity of an Oracle database.

* It follows the concept that a tablespace and a datafile are logically equivalent.

rowids of Rows that belong to BFTs do not contain the relative file number.

* SFT has a four piece format: OOOOOOFFFBBBBBBRRR, in which:

* OOOOOO is the data object number of the segment.

* FFF is the tablespace-relative datafile number of the datafile that contains the row.

* BBBBBB is the data block that contains the row.

* RRR is the slot number identifying the row inside a particular block.

 


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

http://www.rampant-books.com/book_2004_1_10g_grid.htm


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational