Introduction of Tablespace

Oracle stores data logically in tablespaces and physically in datafiles associated with the corresponding tablespace.
There are three types of tablespaces: (1) permanent, (2) undo, and (3) temporary.

Permanent – These tablespaces store objects in segments that are permanent – that persist beyond the duration of a session or transaction.
Undo – These tablespaces store  undo segments that may be retained beyond a transaction, but are basically used to:
Provide read consistency for SELECT statements that access tables that have rows that are in the process of being modified.
Provide the ability to rollback a transaction that fails to commit.
Temporary – This tablespace stores segments that are transient and only exist for the duration of a session or a transaction. Mostly, a temporary tablespace stores rows for sort and join operations.

SYSTEM Tablespace

The SYSTEM tablespace is used by the Oracle server to manage the database.
It contains the data dictionary and tables that contain administrative information about the database. These are all contained in the SYS schema and can be accessed only by the SYS user or other administrative users with the required privilege.
Every Oracle database contains a tablespace named SYSTEM, which Oracle creates automatically when the database is created.

• The SYSTEM tablespace is always online when the database is open.
• Accessing it requires a higher level of privilege.
• You cannot rename or drop a SYSTEM tablespace.
• You cannot take a SYSTEM tablespace offline.
• The SYSTEM tablespace always contains the data dictionary tables for the entire database.
• This is a permanent tablespace.

The SYSTEM tablespace could store user data, but this is not normally done—a good rule to follow is to never allow allow the storage of user segments in the SYSTEM tablespace.

SYSAUX Tablespace

This is an auxiliary tablespace to the SYSTEM tablespace. Some components and products that used the SYSTEM tablespace or their own tablespaces in earlier releases of Oracle Database now use the SYSAUX tablespace. Every Oracle Database 10g (or later release) database must have a SYSAUX tablespace.
SYSAUX tablespace stores data for auxiliary applications such as the LogMiner, Workspace Manager, Oracle Data Mining, Oracle Streams, and many other Oracle tools.

• This tablespace is automatically created if you use the Database Creation Assistant software to build an Oracle database.
• ike the SYSTEM tablespace, SYSAUX requires a higher level of security and it cannot be dropped or renamed.
• Do not allow user objects to be stored in SYSAUX. This tablespace should only store system specific objects.
• This is a permanent tablespace.

TEMPORARY Tablespace

A TEMPORARY tablespace is used to manage space for sort operations. Sort operations generate segments, sometimes large segments or lots of them depending on the sort required to satisfy the specification in a SELECT statement's WHERE clause. Sort operations are also generated by SELECT statements that join rows from within tables and between tables. Each database needs to have a specified default temporary tablespace. If one is not specified, then any user account created without specifying a TEMPORARY TABLESPACE clause is assigned a temporary tablespace in the SYSTEM tablespace!.You don't want system users to execute SELECT commands that cause sort operations to take place within the SYSTEM tablespace.
If a default temporary tablespace is not specified at the time a database is created, a DBA can create one by altering the database.
A default temporary tablespace cannot be dropped unless a replacement is created. This is usually only done if you were moving the tablespace from one disk drive to another.
You cannot take a default temporary tablespace offline – this is done only for system maintenance or to restrict access to a tablespace temporarily. None of these activities apply to default temporary tablespaces.
You cannot alter a default temporary tablespace to make it permanent.

Undo Tablespaces

This is the undo tablespace used by the database server to store undo information. If a database uses Automatic Undo Management, then it can only use a single undo tablespace at any given time. This tablespace is created at database creation time.
An undo tablespace cannot be dropped if it is being used by any instance or contains any undo information needed to recover transactions
More than one UNDO tablespace can exist in DB, but only one can be active at a time

USERS, DATA and INDEXES Tablespaces

Most Oracle databases will have a USERS permanent tablespace.
This tablespace is used to store objects created by individual users of the database.
This tablespace is used to store user objects and data. If no default tablespace is
specified when a user is created then the USERS tablespace is the default tablespace for all objects created by that user. For the SYS and SYSTEM users, the default permanent
tablespace is SYSTEM.
For large applications, it is often a practice to create a seprate tablespace to store data for the application. In this case the tablespace may be named whatever name is appropriate to describe the objects stored in the tablespace accurately.
Oracle databases having a DATA (or more than one DATA) tablespace will also have an accompanying INDEXES tablespace.

• The purpose of separating tables from their associated indexes is to improve I/O efficiency.
• The DATA and INDEXES tablespaces will typically be placed on different disk drives thereby providing an I/O path for each so that as tables are updated, the indexes can also be updated simultaneously.

Data Dictionary

The Oracle data dictionary is the metadata of the database and contains the names and attributes of all objects in the database. The creation or modification of any object causes an update to the data dictionary that reflects those changes. This information is stored in the base tables that are maintained by the Oracle database, but you access these tables by using predefined views rather than reading the tables directly.

The data dictionary:

• Is used by the Oracle database server to find information about users, objects, constraints,and storage
• Is maintained by the Oracle database server as object structures or definitions are modified
• Is available for use by any user to query information about the database
• Is owned by the SYS user
• Should never be modified directly using SQL

The Data Dictionary consists of two components:

Base Tables: These tables store descriptions of objects in the database.

• These are the first objects created in the data dictionary.These are created when the oracle RDBMS software runs a special script named sql.bsq when a database is created by the CREATE DATABASE command – you do not see the sql.bsq script execute, but it does.
  You should never attempt to write to these tables – never use DML commands to attempt to update base tables directly.
  An example Base Table is IND$ that stores index information.

User-Accessible Views: These views summarize information in the base tables in order to make the information easier for a DBA to use.

• These views are created by the catalog.sql script.
• Using the Oracle Universal Installer to create a database, then the catalog.sql and catproc.sql scripts are run automatically.
• An example data dictionary user-accessible view is TABS – it stores information about tables you create as a system user. TABS is a synonym for the view ALL_TABLES.

The Data Dictionary stores information about all database objects created by system users and information systems professionals including tables, views, indexes, clusters, procedures, functions, synonyms, sequences, triggers and the like. For each object, the Data Dictionary stores:

• Disk space allocation (usually in bytes).
• Integrity constraint information.
• Default values for columns.
• Oracle user names (accounts)
• Privilege and role information for users.
• Auditing information – who has accessed/updated objects.

Data Dictionary Usage

The Data Dictionary is used by the Oracle RDBMS as illustrated in the figure shown below.

DBA: These views display information about objects stored in all schemas (a schema is a logical organization of objects belong to an individual system user). These views are named DBA_xxx where xxx is the object name.Because these views belong to the DBA and were created by the owner SYS so these views not access by public .
Example:
SELECT owner, object_name, object_type
FROM SYS.DBA_OBJECTS;

ALL: These views display "all" information that an individual user of the database is authorized to access – this will include information about your objects as well as information about objects for which you have access permissions.
If you connect to the database, the ALL_xxx views will display all information about objects of all database schemas (if you have access permissions).

SELECT owner, object_name, object_type FROM ALL_OBJECTS;

USER: These views display information that you would most likely want to access.

• These USER_xxx views refer to your own objects in your own schema.
• These views display only rows pertinent to you as a user.
• These views are a subset of the ALL views.
• These rows do not usually display the OWNER column.
  

          SELECT object_name, object_type  FROM USER_OBJECTS;

In general, Data Dictionary Views answer questions about:

• when an object was created,
• Is the object part of another objects,
• who owns the object,
• what privileges do you have as a system user,what restrictions are on an object.

Practice selecting information from the following three views: dba_objects, all_objects, user_objects. You may wish to use the SQL*Plus command DESC to describe the views.Additional queries you may wish to execute to practice accessing parts of the data dictionary:
SELECT table_name, comments
FROM dictionary
WHERE table_name LIKE '%SEGMENTS%';

Dynamic Performance Tables and Views

The Oracle Server records database activity to the Dynamic Performance Tables.
These are complemented by Dynamic Performance Views - virtual tables that exist only in memory when the database is running.

• The tables provide real-time condition information about database operation.
• DBAs use these tables—most ,users should not be able to access these tables.
• The tables cannot be altered – they are fixed and are owned by the user SYS.
• All Dynamic Performance Tables have names that begin with the letters V_$.
• Views of these tables are created along with synonyms that begin with the letters V$.
• Information about the database's datafiles and information about all of the dynamic performance tables and views.

Examples Dynamic Performance Table views:
V$CONTROLFILE: Lists the names of the control files
V$DATABASE: Contains database information from the control file.
V$DATAFILE: Contains datafile information from the control file
V$INSTANCE: Displays the state of the current instance
V$PARAMETER: Lists parameters and values currently in effect for the session
V$SESSION: Lists session information for each current session
V$SGA: Contains summary information on the system global area (SGA)
V$SPPARAMETER: Lists the contents of the SPFILE
V$TABLESPACE: Displays tablespace information from the control file
V$THREAD: Contains thread information from the control file
V$VERSION: Version numbers of core library components in the Oracle server

The DUAL Table

Oracle maintains a table named DUAL that is used by Oracle and by user programs to produce a guaranteed known result such as the production of a value through use of an Oracle defined function.
The table has one column named DUMMY and one row containing the value X.
SYS owns the DUAL table, but all users can select from it.
Selecting from DUAL is useful for computing a constant expression with a SELECT statement, since DUAL has only one row, the constant is returned only once.

Example

SQL> select 1+4 from dual;
       1+4
----------
         5

How the Data Dictionary Is Used

Oracle (internally) accesses information about users, schema objects, and storage structures.
This is done to validate a query executed by a system user.
Validates permission and security.
Verifies that referenced objects in queries actually exist.
Oracle modifies the data dictionary for each DDL statement executed.
Oracle users access the data dictionary as a read-only reference.

General Overview
– DICTIONARY, DICT_COLUMNS

• Schema objects
– DBA_TABLES, DBA_INDEXES, DBA_TAB_COLUMNS,
DBA_CONSTRAINTS

• Space allocation
– DBA_SEGMENTS, DBA_EXTENTS

• Database structure
– DBA_TABLESPACES, DBA_DATA_FILES

Modifying the Data Dictionary:

Only Oracle (SYS) should ever modify the data dictionary.During upgrades to new release versions of the Oracle RDBMS, scripts are provided to upgrade the data dictionary.

Row Chaining and Migrating

Whenever  DML operation performed in oracle database ,there are two situations where a data row may not fit into a single data block:

Row chaining The row is too large to fit into one data block when it is first inserted, or the table contains more than 255 columns (the maximum for a row piece).In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment.Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG or LONG RAW.Row chaining in these cases is unavoidable.Due to  insertion of a large row in a data block. The row is too large for the left block, so the database chains the row by placing the first row piece in the left block and the second row piece in the right block.

Row Migration  A row that originally fit into one data block has one or more columns updated so that the overall row length increases, and the block's free space is already completely filled.
In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block.
Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row.The rowid of a migrated row does not change.The left block contains a row that is updated so that the row is now too large for the block. The database moves the entire row to the right block and leaves a pointer to the migrated row in the left block.

When a row is chained or migrated, I/O performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for the row.

• Row chaining is typically caused by INSERT operation.
• Row migration is typically caused by UPDATE operation

Overview of Data Blocks

The Database Block or simply Data Block, is the smallest size unit for input/output from/to disk in an Oracle database.Oracle Database manages the logical storage space in the data files of a database in a unit called a data block, also called an Oracle block or page. A data block is the minimum unit of database I/O.
Data Blocks and Operating System Blocks At the physical level, database data is stored in disk files made up of operating system blocks.A data block may be equal to an operating system block in terms of size, or may be larger in size, and should be a multiple of the operating system block. The database requests data in multiples of data blocks, not operating system blocks.

When the database requests a data block, the operating system translates this operation into a requests for data in permanent storage. The logical separation of data blocks from operating system blocks has the following implications:

• Applications do not need to determine the physical addresses of data on disk.
• Database data can be striped or mirrored on multiple physical disks etc.

Oracle Data Block

Data Blocks is smallest logical unit to store Oracle Data.

• One data block represent specific number of bytes on physical hard disk
• Data Block in Oracle is also called as  logical blocks, Oracle blocks, or pages
• Data Block size is usually multiple of operating system block size
• You can have multiple block sizes with in single database
• Block Size is specified by initialization parameter DB_BLOCK_SIZE

Architecture of Oracle Data Block

Every data block has a format or internal structure that enables the database to track the data and free space in the block. This format is similar whether the data block contains table, index, or table cluster data.

Data Block Overhead

Oracle Database uses the block overhead to manage the block itself. The block overhead is not available to store user data.The data block header, table directory, and row directory are referred to collectively as overhead. Some block overhead is fixed in size; the total block overhead size is variable. On average, the fixed and variable portions of data block overhead total 84 to 107 bytes.

Header (Common and Variable) part contains general information about the block, including disk address and segment type(for example, data or index). For blocks that are transaction-managed, the block header contains active and historical transaction information
Table Directory portion of the data block contains information about the table having rows in this block it also contains metadata about tables whose rows are stored in this block and In a table cluster, multiple tables can store rows in the same block.
Row Directory  describes the location of rows in the data portion of the block.The row directory entry contains a address(pointer) to the location of the row on the data block .
Free space is allocated for insertion of new rows and for updates to rows that require additional space (for example, when a trailing null is updated to a nonnull value).
Row Data  part of the block contains the actual data, such as table rows or index key entries

Logical Database Structure

Oracle Database allocates logical space for all data in the database. The logical units of database space allocation are data blocks, extents, segments, and tablespaces. At a physical level, the data is stored in data files on disk. The data in the data files is stored in operating system blocks.
Oracle database logically divided into tow or more tablespaces ,a database is divided into logical storage units called tablespaces, which group related data blocks, extents, and segments.
The combined size of the datafiles in a tablespace is the total storage capacity of the tablespace.Every Oracle database contains a SYSTEM tablespace and a SYSAUX tablespace. Oracle Database creates them automatically when the database is created.
Below diagram for physical and logical storage

Tablespaces :

Tablespaces logically organize data that are physically stored in datafiles.

• A tablespace belongs to only one database, and has at least one datafile that is used to store data for the associated tablespace.
• The term "tablespaces" is misleading because a tablespace can store tables, but can also store many other database objects such as indexes, views, sequences, etc.
• Datafiles are always assigned to only one tablespace and, therefore, to only one database.
• Tablespace is contain one or more segments (table,index etc).

Logical Storage Hierarchy:

A segment contains one or more extents, each of which contains multiple data blocks.

Data Block

A data block is the smallest logical unit of data storage in Oracle Database.
One logical data block corresponds to a specific number of bytes of physical disk space, for example, 2 KB. Data blocks are the smallest units of storage that Oracle Database can use or allocate.

Extent

An extent is a set of logically contiguous data blocks allocated for storing a specific type of information .In the preceding graphic, the 24 KB extent has 12 data blocks, while the 72 KB extent has 36 data blocks.

Segment

A segment is a set of extents allocated for a specific database object, such as a table.
For example, the data for the employees table is stored in its own data segment, whereas each index for employees is stored in its own index segment. Every database object that consumes storage consists of a single segment.
A tablespace is a database storage unit that contains one or more segments.

• A database is made up of one or more tablespaces
• A tablespace is made up of one or more data files, a tablespace contains segments
• A segment (table, index, etc) is made up of one or more extents. A segment exists in a tablespace but may have data in many data files within a tablespace.
• An extent is a continuous set of blocks on a disk. An extent is in a single tablespace and is always in a single file within that tablespace.
• A block is the smallest unit of allocation in the database. A block is the smallest unit of i/o used by the database.

Physical Database Storage Architecture

An Oracle database consists of files

• Datafiles
• Temp files
• Control Files
• Online Redo Log Files
• Archived Redo Log Files
• Parameter Files
• Password Files
• Alert and Trace Log Files
• Backup Files

Datafiles:

Every Oracle database has one or more physical datafiles, which contain all the database data. The data of logical database structures, such as tables and indexes, is physically stored in the datafiles allocated for a database.
At the operating system level, Oracle Database stores database data in structures called data files. Every Oracle database must have data file.

Tempfiles:

Tempfiles are used with TEMPORARY tablespaces and are used for storing temporary data like sort ,spill-over or data for global temporary tables.

Control Files:

Every Oracle Database has a control file, which is a small binary file that records the physical structure of the database. The control file includes: The database name. Names and locations of associated datafiles and redo log files.Every time an instance of an Oracle database is started, its control file identifies the datafiles, tempfiles, and redo log files that must be opened for database operation to proceed.

Redo Log Files :

The most crucial structure for recovery operations is the redo log, which consists of two or more pre-allocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.
Redo log files contain a chronological record of changes made to the database, and enable recovery when failures occur.To protect against a failure involving the redo log itself, Oracle Database lets you create a multiplexed redo log so that two or more copies of the redo log can be maintained on different disks.

Archived Redo Log Files:

Archived redo log files are database-generated offline copies of online redo log files. Oracle Database automatically archives redo log files when the database is in ARCHIVELOG mode. Oracle recommends that you enable automatic archiving of the online redo log.Archive redo log files contain history of data changes (redo) that is generated by instance .
When the database is running in ARCHIVELOG mode, the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived.An archived redo log file is a copy of one of the filled members of a redo log group.

Parameter Files:

Parameter  files contain a list of configuration parameters for that instance and database.There are two types of parameter files.

PFILE : The init.ora file (also called the PFILE) is a static parameter file. It contains parameters that specify how the database instance is to start up. For example, some parameters will specify how to allocate memory to the various parts of the system global area.

SPFILE : The spfile.ora is a dynamic parameter file. It also stores parameters to specify how to startup a database; however, its parameters can be modified while the database is running.

Password file : specifies which *special* users are authenticated to startup/shut down an Oracle Instance. its use to authenticate users over network.

Trace Log Files : Each server and background process can write to an associated trace file. When an internal error is detected by a process, the process dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, while other information is for Oracle Support Services. Trace file information is also used to tune applications and instances.

Alert Files : The alert file, or alert log, is a special trace file. The alert log of a database is a chronological log of messages and errors.

Backup files :

To restore a file is to replace it with a backup file. Typically, you restore a file when a media failure or user error has damaged or deleted the original file.
User-managed backup and recovery requires you to actually restore backup files before you can perform a trial recovery of the backups.
Server-managed backup and recovery manages the backup process, such as scheduling of backups, as well as the recovery process, such as applying the correct backup file when recovery is needed.

Connecting to Oracle Instance

Connecting to an Oracle Instance (User Process & Server Process)

Before users can submit SQL statements to an Oracle database, they must connect to an instance.

User Process: 

A database user who needs to request information from the database must first make a connection with the Oracle server. The connection is requested using a database interface tool, such as SQL*Plus, and beginning the user process. The user process does not interact directly with the Oracle server. Rather it generates calls through the user program interface (UPI), which creates a session and starts a server process.

Server Process:

Once a user has established a connection, a server process is started to handle the user processes requests. A server process can be either a dedicated server process or a shared server process. In a dedicated server environment, the server process handles the request of a single user process. Once a user process disconnects, the server process is terminated. In a shared server environment, the server process handles the request of several user processes.The server process communicates with the Oracle server using the Oracle Program Interface.

Connecting to an Oracle Instance:

The user starts a tool such as SQL*Plus,sql developer,toad or runs an application developed using a tool such as Oracle Forms. This application or tool is executed as a user process.
In the most basic configuration, when a user logs on to the Oracle server, a process is created on the computer running the Oracle server. This process is called a server process. The server process communicates with the Oracle instance on behalf of the user process that runs on the client. The server process executes SQL statements on behalf of the user.

User Process is started at the time a database user request  a connection to the oracle server .Server Process connect to the oracle instance and started when a user establish a session .
user process & server process are used to manage the execution of sql/plsql statements.
one-to-one correspondence between the User and Server Processes. This is called a Dedicated Server connection. An alternative configuration is to use a Shared Server where more than one User Process shares a Server Process.
Server Process is the go-between for a Client Process and the Oracle Instance.

Dedicated Server environment – there is a single Server Process to serve each Client Process.

Shared Server environment – a Server Process can serve several User Processes, although with some performance reduction

Connection

A connection is a communication pathway between a user process and an Oracle server. A database user can connect to an Oracle server using tool, sqlplus etc.

Sessions

A session is a specific connection of a user to an Oracle server. The session starts when the user is validated by the Oracle server, and it ends when the user logs out or when there is an abnormal termination. For a given database user, many concurrent sessions are possible if the user logs on from many tools, applications, or terminals at the same time.