Oracle srl files

This information is composed of the following structures:. Saving mapping information in the data dictionary to maintain a view of the information that is persistent across startup and shutdown operations.

Restoring mapping information into the SGA at instance startup. This avoids the need for a potentially expensive complete rebuild of the mapping information on every instance startup. The external process is responsible for discovering the mapping libraries and dynamically loading them into its address space.

Oracle Database uses mapping libraries to discover mapping information for the elements that are owned by a particular mapping library. This information is used to populate dynamic performance views that can be queried by users. Mapping libraries are vendor supplied.

However, Oracle currently supplies a mapping library for EMC storage. The mapping libraries available to a database server are identified in a special file named filemap.

The mapping structures and the Oracle Database representation of these structures are described in this section. You will need to understand this information in order to interpret the information in the mapping views. A file mapping structure provides a set of attributes for a file, including file size, number of file system extents that the file is composed of, and the file type.

A file system extent mapping structure describes a contiguous chunk of blocks residing on one element. This includes the device offset, the extent size, the file offset, the type data or parity , and the name of the element where the extent resides. Elements may be mirrors, stripes, partitions, RAID5, concatenated elements, and disks. These structures are the mapping building blocks.

This structure contains the subelement number, size, the element name where the subelement exists, and the element offset. Consider an Oracle Database which is composed of two data files X and Y. Both files X and Y reside on a file system mounted on volume A. File X is composed of two extents while file Y is composed of only one extent. Element A is striped to Elements B and C. Element C is mirrored over Elements E and F both physical disks , and is mirrored to those physical disks by way of Subelements E0 and F1, respectively.

The configuration ID captures the version information associated with elements or files. The vendor library provides the configuration ID and updates it whenever a change occurs. Without a configuration ID, there is no way for the database to tell whether the mapping has changed. The configuration IDs are not persistent across instance shutdown. The database is only capable of refreshing the mapping information while the instance is up. This section discusses how to use the Oracle Database file mapping interface.

Ensure that a valid filemap. The filemap. FMON requires that a filemap. Otherwise, it will not start successfully. Note that the ordering of the libraries in this file is extremely important. The libraries are queried based on their order in the configuration file. The file mapping service can be started even if no mapping libraries are available. In this case, the mapping service is constrained in the sense that new mapping information cannot be discovered.

Only restore and drop operations are allowed in such a configuration. The instance does not have to be shut down to set this parameter. You have two options:. In a cold startup scenario, the Oracle Database is just started and no mapping operation has been invoked yet. This forces all of the mapping information in the SGA to be flushed to disk. The various procedures available to you are described in the following table. Brief descriptions of these views are presented here.

This table displays the hierarchical arrangement of storage containers for objects. Each row in the table represents a level in the hierarchy.

The following examples illustrates some of the powerful capabilities of the Oracle Database file mapping feature. This includes:. The following is the result of the query. The following data dictionary views provide useful information about the data files of a database:. Information in this chapter applies to both data files and temp files except where differences are noted. Guidelines for Managing Data Files Data files are physical files of the operating system that store the data of all logical structures in the database.

These numbers are described in the following table: Type of File Number Description Absolute Uniquely identifies a data file in the database. This file number can be used in many SQL statements that reference data files in place of using the file name. Relative Uniquely identifies a data file within a tablespace. For small and medium size databases, relative file numbers usually have the same value as the absolute file number.

However, when the number of data files in a database exceeds a threshold typically , the relative file number differs from the absolute file number. Note: One means of controlling the number of data files in your database and simplifying their management is to use bigfile tablespaces. Bigfile tablespaces comprise a single, very large data file and are especially useful in ultra large databases and where a logical volume manager is used for managing operating system files.

Bigfile tablespaces are discussed in "Bigfile Tablespaces". Consider Possible Limitations When Adding Data Files to a Tablespace You can add data files to traditional smallfile tablespaces, subject to the following limitations: Operating systems often impose a limit on the number of files a process can open simultaneously.

Operating systems impose limits on the number and size of data files. Consider the Performance Impact The number of data files contained in a tablespace, and ultimately the database, can have an impact upon performance. Determine the Size of Data Files When creating a tablespace, you should estimate the potential size of database objects and create sufficient data files. Place Data Files Appropriately Tablespace location is determined by the physical location of the data files that constitute that tablespace.

Store Data Files Separate from Redo Log Files Data files should not be stored on the same disk drive that stores the database redo log files. Creating Data Files and Adding Data Files to a Tablespace You can create data files and associate them with a tablespace using any of the statements listed in the following table.

Changing Data File Size This section describes the various ways to alter the size of a data file, and contains the following topics: Enabling and Disabling Automatic Extension for a Data File Manually Resizing a Data File Enabling and Disabling Automatic Extension for a Data File You can create data files or alter existing data files so that they automatically increase in size when more space is needed in the database.

The next example disables the automatic extension for the data file. It could be that the file contains data beyond the specified decreased size, in which case the database will return an error.

Altering Data File Availability You can alter the availability of individual data files or temp files by taking them offline or bringing them online. Reasons for altering data file availability include the following: You want to perform an offline backup of a data file.

Note: You can make all data files of a tablespace temporarily unavailable by taking the tablespace itself offline. You must leave these files in the tablespace to bring the tablespace back online, although you can relocate or rename them following procedures similar to those shown in "Renaming and Relocating Data Files".

For more information, see "Taking Tablespaces Offline". Note: This operation does not actually drop the data file. Renaming and Relocating Data Files You can rename data files to either change their names or relocate them. Some possible procedures for doing this are described in the following sections: Procedures for Renaming and Relocating Data Files in a Single Tablespace Procedure for Renaming and Relocating Data Files in Multiple Tablespaces When you rename and relocate data files with these procedures, only the pointers to the data files, as recorded in the database control file, are changed.

Procedures for Renaming and Relocating Data Files in a Single Tablespace The section suggests some procedures for renaming and relocating data files that can be used for a single tablespace. See Also: "Taking Tablespaces Offline" for more information about taking tablespaces offline in preparation for renaming or relocating data files. Procedure for Renaming Data Files in a Single Tablespace To rename data files in a single tablespace, complete the following steps: Take the tablespace that contains the data files offline.

The database must be open. Assume the following conditions: An open database has a tablespace named users that is made up of data files all located on the same disk. You are currently connected with administrator privileges to the open database. You have a current backup of the database. Note: Optionally, the database does not have to be closed, but the data files or temp files must be offline.

In this case, the temp file is taken offline, and queries that attempt to use the temp file will fail while the temp file is offline. See Also: Dropping Tablespaces.

Copying Files Using the Database Server You do not necessarily have to use the operating system to copy a file within a database, or transfer a file between databases as you would do when using the transportable tablespace feature.

This configuration pushes the file. This configuration pulls the file. Note: If a single restartable job transfers several files, then you should consider restart scenarios in which some of the files have been transferred already and some have not been transferred yet.

Mapping Files to Physical Devices In an environment where data files are simply file system files or are created directly on a raw device, it is relatively straight forward to see the association between a tablespace and the underlying device.

You can more easily access this functionality through the Oracle Enterprise Manager. It provides an easy to use graphical interface for mapping files to physical devices. Note: The file mapping interface is not available on Windows platforms. I am newbie, learning Data guard technlogy.

Hi, I have some clairfications. Can you please help me what i am missing. Share Tweet Share. The RFS process will attach Standby Redo Logs only if they are of same size as of Online Redo Log ii Although the standby redo log is only used when the database is running in the standby role , Oracle recommends that you create a standby redo log on the primary database so that the primary database can switch over quickly to the standby role without the need for additional DBA intervention.

Frank says August 20, Great post. Pablo says August 25, Excelent post. Thanks Reply. Bharath says April 26, Hi Atul, Thanks for sharing information which is much needed to administer dataguard. Please reply asap. Legitimate values are from 2K to 32K. In the initialization parameter file or server parameter, 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. 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. Oracle Database Data Warehousing Guide for information about transporting tablespaces in data warehousing environments. A database administrator can bring any tablespace other than the SYSTEM tablespace online accessible or offline not accessible whenever the database is open.

A tablespace is usually online so that the data contained within it is available to database users. However, the database administrator can take a tablespace offline for maintenance or backup and recovery purposes. 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. When a tablespace goes offline or comes back online, this is recorded in the data dictionary in the SYSTEM tablespace. If a tablespace is offline when you shut down a database, the tablespace remains offline when the database is subsequently mounted and reopened.

You can bring a tablespace online only in the database in which it was created because the necessary data dictionary information is maintained in the SYSTEM tablespace of that database. 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. For example, Oracle switches a tablespace from online to offline when the database writer process, DBW n , fails in several attempts to write to a datafile of the tablespace. Users trying to access tables in the offline tablespace receive an error. Oracle Database Utilities for more information about tools for data transfer.

If you create multiple tablespaces to separate different types of data, you take specific tablespaces offline for various procedures.

Other tablespaces remain online, and the information in them is still available for use. However, special circumstances can occur when tablespaces are taken offline.

For example, if two tablespaces are used to separate table data from index data, the following is true:. If the tablespace containing the indexes is offline, then queries can still access table data because queries do not require an index to access the table data. If the tablespace containing the tables is offline, then the table data in the database is not accessible because the tables are required to access the data.

If Oracle has enough information in the online tablespaces to run a statement, it does so. If it needs data in an offline tablespace, then it causes the statement to fail. The primary purpose of read-only tablespaces is to eliminate the need to perform backup and recovery of large, static portions of a database. Read-only tablespaces cannot be modified.

After updating the tablespace, you can then reset it to be read only. Also, if you need to recover your database, you do not need to recover any read-only tablespaces, because they could not have been modified.

You can manage space for sort operations more efficiently by designating one or more temporary tablespaces exclusively for sorts.

Doing so effectively eliminates serialization of space management operations involved in the allocation and deallocation of sort space. A single SQL operation can use more than one temporary tablespace for sorting. For example, you can create indexes on very large tables, and the sort operation during index creation can be distributed across multiple tablespaces.

All operations that use sorts, including joins, index builds, ordering, computing aggregates GROUP BY , and collecting optimizer statistics, benefit from temporary tablespaces. The performance gains are significant with Real Application Clusters.

One or more temporary tablespaces can be used only for sort segments. A temporary tablespace is not the same as a tablespace that a user designates for temporary segments, which can be any tablespace available to the user. No permanent schema objects can reside in a temporary tablespace. Sort segments are used when a segment is shared by multiple sort operations. One sort segment exists for every instance that performs a sort operation in a given tablespace.

Temporary tablespaces provide performance improvements when you have multiple sorts that are too large to fit into memory. The sort segment of a given temporary tablespace is created at the time of the first sort operation. The sort segment expands by allocating extents until the segment size is equal to or greater than the total storage demands of all of the active sorts running on that instance.

Oracle Database Performance Tuning Guide for information about setting up temporary tablespaces for sorts and hash joins. A transportable tablespace lets you move a subset of an Oracle database from one Oracle database to another, even across different platforms. You can clone a tablespace and plug it into another database, copying the tablespace between databases, or you can unplug a tablespace from one Oracle database and plug it into another Oracle database, moving the tablespace 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. You can transport tablespaces across platforms. Many, but not all, platforms are supported for cross-platform tablespace transport. This can be used for the following:.

Provide an easier and more efficient means for content providers to publish structured data and distribute it to customers running Oracle on a different platform. Simplify the distribution of data from a data warehouse environment to data marts which are often running on smaller platforms. A tablesp ace repository is a collection of tablespace sets. Tablespace repositories are built on file group repositories, but tablespace repositories only contain the files required to move or copy tablespaces between databases.

Different tablespace sets may be stored in a tablespace repository, and different versions of a particular tablespace set also may be stored. A version of a tablespace set in a tablespace repository consists of the following files:. Both the datafiles and the metadata export file must be copied to the target database.

The transport of these files can be done using any facility for copying flat files, such as the operating system copying facility, ftp, or publishing on CDs. These files have identical on disk formats for file header blocks, which are used for file identification and verification. Oracle Database Administrator's Guide for details about how to move or copy tablespaces to another database, including details about transporting tablespaces across platforms.

Oracle Streams Concepts and Administration for more information on ways to copy or transport files. A t ablespace in an Oracle database consists of one or more physical datafiles.

A datafile can be associated with only one tablespace and only one database. Oracle creates a datafile for a tablespace by allocating the specified amount of disk space plus the overhead required for the file header.

When a datafile is created, the operating system under which Oracle runs is responsible for clearing old information and authorizations from a file before allocating it to Oracle. If the file is large, this process can take a significant amount of time. When a datafile is first created, the allocated disk space is formatted but does not contain any user data.

However, Oracle reserves the space to hold the data for future segments of the associated tablespace—it is used exclusively by Oracle. As the data grows in a tablespace, Oracle uses the free space in the associated datafiles to allocate extents for the segment. The data associated with schema objects in a tablespace is physically stored in one or more of the datafiles that constitute the tablespace.

Note that a schema object does not correspond to a specific datafile; rather, a datafile is a repository for the data of any schema object within a specific tablespace. Oracle allocates space for the data associated with a schema object in one or more datafiles of a tablespace. Therefore, a schema object can span one or more datafiles. 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.

You can alter the size of a datafile after its creation or you can specify that a datafile should dynamically grow as schema objects in the tablespace grow. This functionality enables you to have fewer datafiles for each tablespace and can simplify administration of datafiles. All of the datafiles of a tablespace are taken offline or brought online as a unit when you take the tablespace offline or bring it online, respectively. You can take individual datafiles offline.

However, this is usually done only during some database recovery procedures. Locally managed temporary tablespaces have temporary datafiles tempfile s , which are similar to ordinary datafiles, with the following exceptions:. 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.

The database control file is a small binary file necessary for the database to start and operate successfully. A control file is updated continuously by Oracle during database use, so it must be available for writing whenever the database is open.

If for some reason the control file is not accessible, then the database cannot function properly. A control file contains information about the associated database that is required for access by an instance, both at startup and during normal operation. Control file information can be modified only by Oracle; no database administrator or user can edit a control file.