What are Oracle-Managed Files
Oracle internally uses standard file system interfaces to create and delete files as needed for the following database structures:
  Tablespaces
  Online redo log files
  Control files

This feature does not affect the creation or naming of administrative files such as trace files, audit files, alert files, and core files.

Who Can Use Oracle-Managed Files
对下列数据库比较有用：
  1.Databases that are supported by the following:
    A logical volume manager that supports striping/RAID and dynamically extensible logical volumes
    A file system that provides large, extensible files
  2.Low end or test databases

对 raw disks 系统管理的简化帮助不大。OMF 提供更好的磁盘空间分配功能，由于没有操作系统支持 raw disks 的空间分配（需要手工分配），所以 OMF 帮助不大。OMF 需要操作系统文件系统支持。

Benefits of Using Oracle-Managed Files
1.They make the administration of the database easier.
2.They reduce corruption caused by administrators specifying the wrong file.
3.They reduce wasted disk space consumed by obsolete files.
4.They simplify creation of test and development databases.
5.Oracle-managed files make development of portable third-party tools easier.

Oracle-Managed Files and Existing Functionality
New files can be created as managed files while old ones are administered in the old way. Thus, a database can have a mixture of Oracle-managed and unmanaged files.

Enabling the Creation and Use of Oracle-Managed Files
DB_CREATE_FILE_DEST
  Defines the location of the default file system directory where Oracle creates datafiles or tempfiles when no file specification is given in the creation operation. Also used as the default file system directory for online redo log and control files if DB_CREATE_ONLINE_LOG_DEST_n is not specified.
 
DB_CREATE_ONLINE_LOG_DEST_n
  Defines the location of the default file system directory for online redo log files and control file creation when no file specification is given in the creation operation. You can use this initialization parameter multiple times, where n specifies a multiplexed copy of the online redo log or control file. You can specify up to five multiplexed copies.

注意：
 1.初始参数指定的路径必须存在，Oracle 不会自动创建他们，并且必须有创建文件的权限。
 2.对于 online redo log files and control files 来说，DB_CREATE_ONLINE_LOG_DEST_n 会覆盖 DB_CREATE_FILE_DEST 的设置，如果 DB_CREATE_FILE_DEST 没有设置，而 DB_CREATE_ONLINE_LOG_DEST_n 设置了，那么只有 online redo log 和 control files 使用 OMF。
 3.两个参数都可以用 alter system 和 alter session 来动态设置。

Creating Oracle-Managed Files
  When an Oracle-managed file is created, its filename is written to the alert file. This information can be used to find the file if it is necessary to manually remove the file.

How Oracle-Managed Files are Named
File Type Format Example
Datafile        o1_mf_%t_%u_.dbf    /u01/oradata/payroll/o1_mf_tbs1_2ixfh90q_.dbf
Tempfile        o1_mf_%t_%u_.tmp    /u01/oradata/payroll/o1_mf_temp1_6dygh80r_.tmp
Redo log file   o1_mf_%g_%u_.log    /u01/oradata/payroll/o1_mf_1_wo94n2xi_.log
Control file    o1_mf_%u_.ctl       /u01/oradata/payroll/o1_mf_cmr7t30p_.ctl
 
%t is the tablespace name.
%u is an eight character string that guarantees uniqueness
%g is the online redo log file group number

Caution:
  Do not rename an Oracle-managed file(指直接修改物理文件的文件名，而不是通过 alter database rename file 等命令). Oracle identifies an Oracle-managed file based on its name. If you rename the file, Oracle is no longer able to recognize it as an Oracle-managed file and will not manage the file accordingly.

Creating Control Files
If the datafiles in the database are Oracle-managed files, then the Oracle generated filenames for the files must be supplied in the DATAFILE clause of the statement.

If the online redo log files are Oracle-managed files, then the NORESETLOGS or RESETLOGS keyword determines what can be supplied in the LOGFILE clause:
  If the NORESETLOGS keyword is used, then the Oracle generated filenames for the Oracle-managed online redo log files must be supplied in the LOGFILE clause.
  If the RESETLOGS keyword is used, then the online redo log file names can be supplied as with the CREATE DATABASE statement.

Planning for Database Creation
Consider what time zones your database must support.
  Oracle uses a time zone file, located in the Oracle home directory, as the source of valid time zones. If you determine that you need to use a time zone that is not in the default time zone file (timezone.dat), but that is present in the larger time zone file (timezlrg.dat), then you must set the ORA_TZFILE environment variable to point to the larger file.

Manually Creating an Oracle Database
SQL scripts that are required for optimal operation of Oracle
Creating the Data Dictionary
Script Name     Needed For        Description
catalog.sql     All databases     Creates the data dictionary and public synonyms for many of its views
                                  Grants PUBLIC access to the synonyms
catproc.sql     All databases     Runs all scripts required for, or used with PL/SQL
 
catclust.sql    Real              Creates Oracle9i Real Application Clusters data dictionary views
                Application
                Clusters

Creating Additional Data Dictionary Structures
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch53.htm

The "NO" Scripts
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch54.htm

Java Scripts
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96536/ch56.htm

Using Automatic Undo Management: Creating an Undo Tablespace
  You must include the following initialization parameter if you want to operate your database in automatic undo management mode:
    UNDO_MANAGEMENT=AUTO
  If you want to create and name a specific tablespace for the undo tablespace, you can include the UNDO TABLESPACE clause at database creation time. If you omit this clause, and automatic undo management is specified, Oracle creates a default undo tablespace named SYS_UNDOTBS.

Using Oracle-Managed Files
  指定 DB_CREATE_FILE_DEST or DB_CREATE_ONLINE_LOG_DEST_n 初始参数
CREATE DATABASE rbdb1
     USER SYS IDENTIFIED BY pz6r58
     USER SYSTEM IDENTIFIED BY y1tz5p
     UNDO TABLESPACE undotbs
     DEFAULT TEMPORARY TABLESPACE tempts1;

Creating a Locally Managed SYSTEM Tablespace
  The COMPATIBLE initialization parameter must be set to 9.2 or higher, When you specify the EXTENT MANAGEMENT LOCAL clause in the CREATE DATABASE statement.
If you do not specify the EXTENT MANAGEMENT LOCAL clause, the default is to create a dictionary-managed SYSTEM tablespace.
  It is not possible to create a locally managed SYSTEM tablespace and specify UNIFORM extent size.

When you create your database with a locally managed SYSTEM tablespace, ensure the following conditions are met:
  There must be a default temporary tablespace, and that tablespace cannot be the SYSTEM tablespace.
  You must not create rollback segments in dictionary-managed tablespaces. Attempting to create a rollback segment in a dictionary-managed tablespace will fail if the SYSTEM tablespace is locally managed.

When your SYSTEM tablespace is locally managed, there are restrictions on other tablespaces in the database. These restrictions are:
  You cannot create any dictionary-managed tablespaces in the database.
  You cannot migrate a locally managed tablespace to a dictionary-managed tablespace.
  You can transport dictionary-managed tablespaces into the database, but you are not allowed to alter them to read-write.
  Preexisting dictionary-managed tablespaces are allowed to remain in the database, but only in READ ONLY mode. They cannot be altered to READ WRITE.

Oracle also allows you to migrate an existing dictionary-managed SYSTEM tablespace to a locally managed tablespace. using the DBMS_SPACE_ADMIN package. However, there is no procedure for backward migration.

Specifying the Database Time Zone and Time Zone File
Specifying the Database Time Zone
  You set the database's default time zone by specifying the SET TIME_ZONE clause of the CREATE DATABASE statement. If omitted, the default database time zone is the operating system time zone. The database time zone can be changed for a session with an ALTER SESSION statement.

Specifying the Database Time Zone File
  There are 2 time zone files under the Oracle installation directory:
$ORACLE_HOME/oracore/zoneinfo/timezone.dat
  This is the default. It contains the most commonly used time zones and is smaller, thus enabling better database performance.

$ORACLE_HOME/oracore/zoneinfo/timezlrg.dat
  This file contains the larger set of defined time zones and should be used by users who require zones that are not defined in the default timezone.dat file. Note that this larger set of zone information may affect performance.

To enable the use of the larger time zone datafile, do the following:
  1.Shut down the database.
  2.Set the environment variable ORA_TZFILE to the full path name of the location for the timezlrg.dat file.
  3.Restart the database. 
  Once the larger timezlrg.dat is used, it must continue to be used unless you are sure that none of the nondefault zones are used for data that is stored in the database. Also, all databases that share information must use the same time zone datafile.
To view the time zone names, use the following query:
  SELECT * FROM V$TIMEZONE_NAMES;

Specifying FORCE LOGGING Mode
  Oracle provides a means of forcing the writing of redo records for changes against the database, even where NOLOGGING has been specified in DDL statements. Oracle never generates redo records for temporary tablespaces and temporary segments, so forced logging has no affect for these.

Using the FORCE LOGGING Clause
 1.CREATE DATABASE 语句中使用 FORCE LOGGING 语句
 2.数据库创建之后，用 ALTER DATABASE FORCE LOGGING 语句
 3.取消 FORCE LOGGING 模式：ALTER DATABASE NO FORCE LOGGING

  Independent of specifying FORCE LOGGING for the database, you can selectively specify FORCE LOGGING or NO FORCE LOGGING at the tablespace level. However, if FORCE LOGGING mode is in effect for the database, it takes precedence over the tablespace mode setting. If it is not in effect for the database, then the individual tablespace settings are enforced. Oracle recommends that either the entire database is placed into FORCE LOGGING mode, or individual tablespaces be placed into FORCE LOGGING mode, but not both.

If the database is shut down and restarted, it remains in the same logging mode state. However, if you re-create the control file, the database not restarted in the FORCE LOGGING mode unless you specify the FORCE LOGGING clause in the CREATE CONTROL FILE statement.

Determining the Global Database Name
  You can rename the GLOBAL_NAME of your database using the ALTER DATABASE RENAME GLOBAL_NAME statement. However, you must also shut down and restart the database after first changing the DB_NAME and DB_DOMAIN initialization parameters and re-creating the control file.

DB_NAME Initialization Parameter
  DB_NAME must be set to a text string of no more than eight characters. During database creation, the name provided for DB_NAME is recorded in the datafiles, redo log files, and control file of the database. If during database instance startup the value of the DB_NAME parameter (in the parameter file) and the database name in the control file are not the same, the database does not start.

Specifying Database Block Sizes
Non-Standard Block Sizes
  Tablespaces of non-standard block sizes can be created using the CREATE TABLESPACE statement and specifying the BLOCKSIZE clause. These non-standard block sizes can have any power-of-two value between 2K and 32K: specifically, 2K, 4K, 8K, 16K or 32K. Platform-specific restrictions regarding the maximum block size apply, so some of these sizes may not be allowed on some platforms.

  To use non-standard block sizes, you must configure sub-caches within the buffer cache area of the SGA memory for all of the non-standard block sizes that you intend to use.

Setting Initialization Parameters that Affect the Size of the SGA
  The memory for dynamic components in the SGA is allocated in the unit of granules. Granule size is determined by total SGA size. Generally speaking, on most platforms, if the total SGA size is equal to or less than 128 MB, then granule size is 4 MB. Otherwise, granule size is 16 MB.

  However, there may be some platform dependency. For example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 128 MB. Consult your operating system specific documentation for more details.

  You can query the V$SGA_DYNAMIC_COMPONENTS view to see the granule size that is being used by an instance. The same granule size is used for all dynamic components in the SGA.

  If you specify a size for a component that is not a multiple of granule size, Oracle will round the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB.

  You can see a summary of information about the dynamic components of the SGA in the V$SGA_DYNAMIC_COMPONENTS view. Information about on-going SGA resize operations can be found in the V$SGA_CURRENT_RESIZE_OPS view, and information about the last 100 completed SGA resize operations can be found in the V$SGA_RESIZE_OPS view. To find the amount of SGA memory available for future dynamic SGA resize operations, query the V$SGA_DYNAMIC_FREE_MEMORY view.

Setting the Buffer Cache Initialization Parameters
  If you intend to use multiple block sizes in your database, you must have the DB_CACHE_SIZE and at least one DB_nK_CACHE_SIZE parameter set. Oracle assigns an appropriate default value to the DB_CACHE_SIZE parameter, but the DB_nK_CACHE_SIZE parameters default to 0, and no additional block size caches are configured.

DB_nK_CACHE_SIZE Initialization Parameters
  These parameters cannot be used to size the cache for the standard block size. For example, if the value of DB_BLOCK_SIZE is 2K, it is illegal to set DB_2K_CACHE_SIZE. The size of the cache for the standard block size is always determined from the value of DB_CACHE_SIZE.

Specifying the Maximum Number of Processes
  The PROCESSES initialization parameter determines the maximum number of operating system processes that can be connected to Oracle concurrently. The value of this parameter must be 6 or greater (5 for the background processes plus 1 for each user process). For example, if you plan to have 50 concurrent users, set this parameter to at least 55.

UNDO_TABLESPACE Initialization Parameter
  When the instance starts up in automatic undo management mode, it selects the first available undo tablespace in the instance for storing undo. A default undo tablespace named SYS_UNDOTBS is automatically created when you execute a CREATE DATABASE statement and the UNDO_MANAGEMENT initialization parameter is set to AUTO. This is the undo tablespace that Oracle normally selects whenever you start up the database.

  If there is no undo tablespace available, the instance will start, but uses the SYSTEM rollback segment. This is not recommended in normal circumstances, and an alert message is written to the alert file to warn that the system is running without an undo tablespace.

ROLLBACK_SEGMENTS Initialization Parameter
  The ROLLBACK_SEGMENTS parameter is a list of the non-system rollback segments an Oracle instance acquires at database startup if the database is to operate in manual undo management mode. List your rollback segments as the value of this parameter. If no rollback segments are specified, the system rollback segment is used.

Setting License Parameters
  Oracle no longer offers licensing by the number of concurrent sessions. Therefore the LICENSE_MAX_SESSIONS and LICENSE_SESSIONS_WARNING initialization parameters have been deprecated.

  If you use named user licensing, Oracle can help you enforce this form of licensing. You can set a limit on the number of users created in the database. Once this limit is reached, you cannot create more users.
Note:
  This mechanism assumes that each person accessing the database has a unique user name and that no people share a user name. Therefore, so that named user licensing can help you ensure compliance with your Oracle license agreement, do not allow multiple users to log in using the same user name.

  To limit the number of users created in a database, set the LICENSE_MAX_USERS initialization parameter in the database's initialization parameter file, as shown in the following example:
LICENSE_MAX_USERS = 200

Setting or Changing Initialization Parameter Values
  For dynamic parameters, you can also specify the DEFERRED keyword. When specified, the change is effective only for future sessions.

  A COMMENT clause allows a comment string to be associated with the parameter update. When you specify SCOPE as SPFILE or BOTH, the comment is written to the server parameter file.
Example:
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=50
                 COMMENT='temporary change on Nov 29'
                 SCOPE=MEMORY;

Another example illustrates setting a complex initialization parameter that takes a list of strings.
ALTER SYSTEM
     SET LOG_ARCHIVE_DEST_4='LOCATION=/u02/oracle/rbdb1/',MANDATORY,'REOPEN=2'
         COMMENT='Add new destimation on Nov 29'
         SCOPE=SPFILE;
  Note that when a value consists of a list of strings, the syntax of the ALTER SYSTEM SET statement does not support editing each element of the list of values by the position or ordinal number. You must specify the complete list of values each time the parameter is updated, and the new list completely replaces the old list.

Deleting Initialization Parameter Values
  For initialization parameters whose values are string values you can restore a parameter to its default value (effectively deleting it), by using the following syntax:
ALTER SYSTEM SET parameter = '';
  For numeric and boolean value parameters, you must specifically set the parameter back to its original default value.

Viewing Parameter Settings
SHOW PARAMETERS
 This SQL*Plus command displays the currently in use parameter values.
 
CREATE PFILE
 This SQL statement creates a text initialization parameter file from the binary server parameter file.
 
V$PARAMETER
 This view displays the currently in effect parameter values.
 
V$PARAMETER2
 This view displays the currently in effect parameter values. It is easier to distinguish list parameter values in this view because each list parameter value appears as a row.
 
V$SPPARAMETER
 This view displays the current contents of the server parameter file. The view returns NULL values if a server parameter file is not being used by the instance.

Administrative Privileges
  The following are the operations that are authorized by the SYSDBA and SYSOPER system privileges:
System Privilege        Operations Authorized
SYSDBA                    Perform STARTUP and SHUTDOWN operations
                          ALTER DATABASE: open, mount, back up, or change character set
                          CREATE DATABASE
                          CREATE SPFILE
                          ARCHIVELOG and RECOVERY
                          Includes the RESTRICTED SESSION privilege
                       Effectively, this system privilege allows a user to connect as user SYS.
 
SYSOPER                   Perform STARTUP and SHUTDOWN operations
                          CREATE SPFILE
                          ALTER DATABASE OPEN/MOUNT/BACKUP
                          ARCHIVELOG and RECOVERY
                          Includes the RESTRICTED SESSION privilege
                       This privilege allows a user to perform basic operational tasks, but without the ability to look at user data.
 
  When you connect with SYSDBA or SYSOPER privileges, you connect with a default schema, not with the schema that is generally associated with your username. For SYSDBA this schema is SYS; for SYSOPER the schema is PUBLIC.

Using ORAPWD
orapwd
Usage: orapwd file=<fname> password=<password> entries=<users>
where
file - name of password file (mand),
password - password for SYS (mand),
entries - maximum number of distinct DBAs and OPERs (opt),
There are no spaces around the equal-to (=) character.

ENTRIES
  This parameter specifies the number of entries that you require the password file to accept. This number corresponds to the number of distinct users allowed to connect to the database as SYSDBA or SYSOPER. The actual number of allowable entries can be higher than the number of users because the ORAPWD utility continues to assign password entries until an operating system block is filled. For example, if your operating system block size is 512 bytes, it holds four password entries. The number of password entries allocated is always multiple of four.

Removing a Password File
Caution:
  Do not remove or modify the password file if you have a database or instance mounted using REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE (or SHARED). If you do, you will be unable to reconnect remotely using the password file. Even if you replace it, you cannot use the new password file, because the timestamps and checksums will be wrong.

Changing the Password File State
  The password file state is stored in the password file. When you first create a password file, its default state is SHARED. You can change the state of the password file by setting the initialization parameter REMOTE_LOGIN_PASSWORDFILE. When you start up an instance, Oracle retrieves the value of this parameter from the parameter file stored on your client machine. When you mount the database, Oracle compares the value of this parameter to the value stored in the password file. If the values do not match, Oracle overwrites the value stored in the file.

Introduction to an Oracle Instance
Connection with Administrator Privileges
  When you connect with SYSDBA privileges, you are in the schema owned by SYS. When you connect as SYSOPER, you are in the public schema. SYSOPER privileges are a subset of SYSDBA privileges.

Initialization Parameter Files
Most initialization parameters belong to one of the following groups:
  1.Parameters that name things, such as files
  2.Parameters that set limits, such as maximums
  3.Parameters that affect capacity, such as the size of the SGA, which are called variable parameters

Among other things, the initialization parameters tell Oracle:
  1.The name of the database for which to start up an instance
  2.How much memory to use for memory structures in the SGA
  3.What to do with filled online redo log files
  4.The names and locations of the database control files
  5.The names of undo tablespaces or private rollback segments in the database

Instance and Database Startup
How a Database Is Mounted with Real Application Clusters
  If Oracle allows multiple instances to mount the same database concurrently, then the database administrator can use the initialization parameter CLUSTER_DATABASE to make the database available to multiple instances. The default value of the CLUSTER_DATABASE parameter is false. Versions of Oracle that do not support Real Application Clusters only allow CLUSTER_DATABASE to be false.

  If CLUSTER_DATABASE is false for the first instance that mounts a database, then only that instance can mount the database. If CLUSTER_DATABASE is set to true on the first instance, then other instances can mount the database if their CLUSTER_DATABASE parameters are set to true. The number of instances that can mount the database is subject to a predetermined maximum, which you can specify when creating the database.

Open a Database in Read-Only Mode
  Read-only mode restricts database access to read-only transactions, which cannot write to the datafiles or to the redo log files.

  Disk writes to other files, such as control files, operating system audit trails, trace files, and alert files, can continue in read-only mode. Temporary tablespaces for sort operations are not affected by the database being open in read-only mode. However, you cannot take permanent tablespaces offline while a database is open in read-only mode. Also, job queues are not available in read-only mode.

  Read-only mode does not restrict database recovery or operations that change the database's state without generating redo data. For example, in read-only mode:
  1.Datafiles can be taken offline and online
  2.Offline datafiles and tablespaces can be recovered
  3.The control file remains available for updates about the state of the database
One useful application of read-only mode is that standby databases can function as temporary reporting databases.

Tablespaces Overview

The SYSTEM Tablespace
  In a database with a locally managed SYSTEM tablespace, dictionary tablespaces cannot be created.(ORA-12913 Cannot create dictionary managed tablespace) It is possible to plug in a dictionary managed tablespace using the transportable feature, but it cannot be made writable.

  The SYSTEM tablespace always contains the data dictionary tables for the entire database. The data dictionary tables are stored in datafile 1.

  All data stored on behalf of stored PL/SQL program units (that is, procedures, functions, packages, and triggers) resides in the SYSTEM tablespace.

Undo Tablespaces
  Each database contains zero or more undo tablespaces. In automatic undo management mode, each Oracle instance is assigned one (and only one) undo tablespace.

  In rare circumstances, if the instance does not have a designated undo tablespace, the transaction binds to the system undo segment.
Caution:
  Do not run any user transactions before creating the first undo tablespace and taking it online.

Default Temporary Tablespace
  When the SYSTEM tablespace is locally managed, you must define a default temporary tablespace when creating a database. A locally managed SYSTEM tablespace cannot be used for default temporary storage.

  You cannot make the default temporary tablespace permanent or take it offline.

Multiple Block Sizes
  The block size of the SYSTEM tablespace is the standard block size. This is set when the database is created and can be any valid size.

  You can specify up to four block sizes, in addition to a standard block size. In the initialization file, you can configure subcaches within the buffer cache for each of these block sizes. Subcaches can also be configured while an instance is running. You can create tablespaces having any of these block sizes. The standard block size is used for the system tablespace and most other tablespaces.
Note:
  All partitions of a partitioned object must reside in tablespaces of a single block size.
  Multiple block sizes are useful primarily when transporting a tablespace from an OLTP database to an enterprise data warehouse. This facilitates transport between databases of different block sizes.

When a Tablespace Goes Offline
  When a tablespace goes offline, Oracle does not permit any subsequent SQL statements to reference objects contained in that tablespace. Active transactions with completed statements that refer to data in that tablespace are not affected at the transaction level. Oracle saves rollback data corresponding to those completed statements in a deferred rollback segment in the SYSTEM tablespace. When the tablespace is brought back online, Oracle applies the rollback data to the tablespace, if needed.

  An offline tablespace cannot be read or edited by any utility other than Oracle. Thus, offline tablespaces cannot be transposed to other databases.

  Oracle automatically switches a tablespace from online to offline when certain errors are encountered.

Temporary Tablespaces for Sort Operations
  All operations that use sorts, including joins, index builds, ordering, computing aggregates (GROUP BY), and collecting optimizer statistics, benefit from temporary tablespaces.
Syntax:
  1.Create temporary tablespace XXX tempfile '...'
  2.Create tablespace XXX datafile '...' temporary
第一种方法可以指定 EXTENT MANAGEMENT LOCAL，第二种方法只能使用 dictionary managed.
Note:
  Oracle Corporation strongly recommends that you create locally managed temporary tablespaces containing tempfiles by using the CREATE TEMPORARY TABLESPACE statement. The creation of new dictionary-managed tablespaces is scheduled for desupport.

Transport of Tablespaces Between Databases
When you transport tablespaces you can also move index data, so you do not have to rebuild the indexes after importing or loading the table data.
Note:
You can transport tablespaces only between Oracle databases that use the same character set and that run on compatible platforms from the same hardware vendor.

How to Move or Copy a Tablespace to Another Database
  Make the tablespaces read-only, copy the datafiles of these tablespaces, and use export/import to move the database information (metadata) stored in the data dictionary. Both the datafiles and the metadata export file must be copied to the target database.After copying the datafiles and importing the metadata, you can optionally put the tablespaces in read/write mode.
Note:
  In a database with a locally managed SYSTEM tablespace, dictionary tablespaces cannot be created. It is possible to plug in a dictionary managed tablespace using the transportable feature, but it cannot be made writable.

Datafiles Overview
  Oracle creates a datafile for a tablespace by allocating the specified amount of disk space plus the overhead required for the file header.

  Unless table striping is used (where data is spread across more than one disk), the database administrator and end users cannot control which datafile stores a schema object.

Temporary Datafiles
1.Locally managed temporary tablespaces have temporary datafiles (tempfiles), which are similar to ordinary datafiles, with the following exceptions:
2.Tempfiles are always set to NOLOGGING mode.
3.You cannot make a tempfile read-only.
4.You cannot rename a tempfile.
5.You cannot create a tempfile with the ALTER DATABASE statement.
6.When you create or resize tempfiles, they are not always guaranteed allocation of disk space for the file size specified. On certain file systems (for example, UNIX) disk blocks are allocated not at file creation or resizing, but before the blocks are accessed.
  Caution:
    This enables fast tempfile creation and resizing; however, the disk could run of space later when the tempfiles are accessed.
7.Tempfile information is shown in the dictionary view DBA_TEMP_FILES and the dynamic performance view V$TEMPFILE, but not in DBA_DATA_FILES or the V$DATAFILE view.

Control File Contents
A control file contains information such as:
1.The database name
2.The timestamp of database creation
3.The names and locations of associated datafiles and online redo log files
4.Tablespace information
5.Datafile offline ranges
6.The log history
7.Archived log information
8.Backup set and backup piece information
9.Backup datafile and redo log information
10.Datafile copy information
11.The current log sequence number
12.Checkpoint information

  The database name and timestamp originate at database creation. The database name is taken from either the name specified by the initialization parameter DB_NAME or the name used in the CREATE DATABASE statement.

  Control files also record information about checkpoints. Every three seconds, the checkpoint process (CKPT) records information in the control file about the checkpoint position in the online redo log. This information is used during database recovery to tell Oracle that all redo entries recorded before this point in the online redo log group are not necessary for database recovery; they were already written to the datafiles.