Wednesday, November 11, 2015

Different versions of Oracle

Oracle Database 10g New Features

NID utility has been introduced to change the database name and id.
Automated Storage Management (ASM). ASMB, RBAL, ARBx are the new background processes related to ASM.
New memory structure in SGA i.e. Streams pool (streams_pool_size parameter), useful for datapump activities & streams replication.
From Oracle 10g, the spool command can append to an existing one.
SQL> spool result.log append
Ability to rename tablespaces (except SYSTEM and SYSAUX), whether permanent or temporary, using the following command:
SQL> ALTER TABLESPACE oldname RENAME TO newname;

Oracle Database 11g New Features

Ability to mark a table as read only.
SQL> alter table table-name read only;
Temporary tablespace or it's tempfile can be shrinked, up to specified size.
SQL> alter tablespace temp-tbs shrink space;
SQL> alter tablespace temp-tbs shrink space keep n{K|M|G|T|P|E};
Introduction of ADR, single location of all error and trace data in the database, diagnostic_dump parameter
A new parameter is added in 11g, called MEMORY_TARGET, automatic memory management for both the SGA and PGA.
A system privelege is introduced in 11g called SYSASM, and this is granted to users who need to perform ASM related tasks.

Oracle Database 12c New Features

Moving and Renaming datafile is now ONLINE, no need to put datafile in offline.
SQL> alter database move datafile 'path' to 'new_path';
No need to shutdown database for changing archive log mode.
Like sysdba, sysoper & sysasm, we have new privileges, in Oracle 12.1.0.
sysbackup for backup operations
sysdg for Data Guard operations
syskm for key management

Patching:
Centralised patching.
We can retrieve OPatch information using sqlplus query, using DBMS_QOPATCH package
SQL> select dbms_qopatch.get_opatch_lsinventory() from dual;
We can test patches on database copies, rolling patches out centrally once testing is complete.


New Commands
create pluggable database ...
alter pluggable database ...
drop pluggable database ...
New background processes - LREG (Listener Registration), SA (SGA Allocator), RM.
Oracle Database 12c Data Pump will allow turning off redo for the import operation (only).

$ impdp ... transform=disable_archive_logging:y



New features of Oracle Apps EBS 12.2
Use of Oracle WebLogic Server instead of Oracle Containers for Java (OC4J).
Integration between Oracle Enterprise Manager 11g Fusion Middleware Control and Oracle Applications Manager to monitor EBS environments with Oracle WebLogic Server technology.
Enhanced Workflow Worklist notification and management features.
Enhanced internationalization features, including new languages and calendars, and improved diagnostics.
Direct upgrade from EBS 11i (11.5.10.2), 12.0.4, 12.0.6, 12.1.1.12.1.2 & 12.1.3 to 12.2 is possible.
Oracle Single Sign-On is  replaced by Oracle Access Manager.
Oracle Portal replaced by Oracle WebCenter Portal.
Online patching mechanism introduced, that allows to apply patches while the system is up and running, and the users are working as normal.
The AD Online Patching (adop) command-line utility is used to manage the Online Patching cycle.


Difference Between Oracle apps 11i & R12

Summary of Changes :
Component
Release 11i
Release 12
Database
9.2
10.2
Developer
6i
10i
Application Server
1.0
10.1
Client Plug-in
Jinitiator
SUN JRE
Java Containers
Jserv
OC4J

Changes in Detail :
APPMGR
OLD
NEW
APPL_TOP
$HOME/<SID>appl
$HOME/apps/apps_st/appl
COMMON_TOP
$HOME/<SID>comn
$HOME/apps/apps_st/comn
ORACLE_HOME
$HOME/<SID>ora/8.0.6
$HOME/apps/tech_st/10.1.2
IAS_ORACLE_HOME
$HOME/<SID>ora/iAS
$HOME/apps/tech_st/10.1.3
ORACLE
OLD
NEW
ORACLE_HOME
$HOME/<SID>db/10.2.0
$HOME/db/tech_st/10.2.0
ORADATA
$HOME/<SID>data
$HOME/db/apps_st/data
INST_TOP (New Addition)
OLD
NEW
INST_TOP
NA
$HOME/inst/apps/<context_name>


What’s new in Oracle Apps R12

Key points to Note:


Oracle Applications Release 12 is the latest release in the chain of E-Business Suite Releases by Oracle.
This release came up with the new file system model
Autoconfig will not write anything in APPL_TOP, COMMON_TOP area in R12.
All instance specific configurations, log files are written in INST_TOP area. This home provides the ability to share Applications and technology stack.

R12 new features

Applications Server 9i is replaced by 10g (10.1.3.X)
Forms & Reports Version 6i (8.0.6) are replaced by Forms & Reports Version 10g i.e. 10.1.2.X
mod_jserv is replaced by oc4j
Java/ JDK version 1.3.X or 1.4.X will be replaced by JDK 1.5.X
Techstack Components Changes

Database (RDBMS_ORACLE_HOME) - 10.2.0.2
FORMS ORACLE_HOME (8.0.6 ORACLE HOME equivalence) - 10.1.2
OC4J_ORACLE_HOME (iAS ORACLE_HOME equivalence) - 10.1.3
File system level changes

A new top INSTANCE_TOP is introduced in Release 12 for configuration and log files along with the other TOP's in existing in 11i.
All instance specific configurations, log files are written in INST_TOP area. 
This home provides the ability to share Applications and technology stack.

What is INSTANCE TOP


Instance home is the top-level directory for an applications instance which is known as Instance Home and is denoted the environment variable $INST_TOP. 
This contains all the config files, log files, SSL certificates etc.
Advantages of new INSTANCE HOME


The additional Instance Home makes the middle tier easier to manage and organized since the data is kept separate from the config files.
The Instance Home also has the ability to share the Applications and Technology stack code across multiple instances.
Another advantage of the Instance Home is that the autoconfig writes only in INST_TOP so APPL_TOP and ORACLE_HOME can also be made read only file system if required.




Oracle Initialization Parameters

Oracle Initialization Parameters



-MEMORY_TARGET This is the initialization parameter setting for all of the memory allocated to both the PGA and SGA combined (new in 11g). Setting MEMORY_TARGET enables Automatic Memory Management, so Oracle allocates memory for you based on system needs, but you can also set minimum values for key parameters. MEMORY_TARGET is used for everything that SGA_TARGET was used for but now additionally includes the PGA (especially important as MEMORY_TARGET now includes the important area PGA_AGGREGATE_TARGET). Important parameters such as DB_CACHE_SIZE, SHARED_POOL_SIZE, PGA_AGGREGATE_TARGET, LARGE_POOL_SIZE, and JAVA_POOL_SIZE are all set automatically when you set MEMORY_TARGET. Setting minimum values for important initialization parameters in your system is also a very good idea.

-MEMORY_MAX_TARGET This is the maximum memory allocated for Oracle and the maximum value to which MEMORY_TARGET can be set.

-DB_CACHE_SIZE Initial memory allocated to data cache or memory used for data itself. This parameter doesn’t need to be set if you set MEMORY_TARGET or SGA_TARGET, but setting a value for this as a minimum setting is a good idea. Your goal should always be toward a memory resident database or at least toward getting all data that will be queried in memory.

-SHARED_POOL_SIZE Memory allocated for data dictionary and for SQL and PL/SQL statements. The query itself is put in memory here. This parameter doesn’t need to be set if you set MEMORY_TARGET, but setting a value for this as a minimum is a good idea. Note that SAP recommends setting this to 400M. Also note that the Result Cache gets its memory from the shared pool and is set with the RESULT_CACHE_SIZE and RESULT_CACHE_MODE (FORCE/AUTO/MANUAL) initialization parameters. Lastly, an important note for 11g is that this parameter now includes some SGA overhead (12M worth) that it previously did not (in 10g). In 11g, set this 12M higher than you did in 10g!

-SGA_TARGET If you use Oracle’s Automatic Shared Memory Management, this parameter is used to determine the size of your data cache, shared pool, large pool, and Java pool automatically. Setting this to 0 disables it. This parameter doesn’t need to be set if you set MEMORY_TARGET, but you may want to set a value for this as a minimum setting for the SGA if you’ve calibrated it in previous versions. The SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, and DB_CACHE_SIZE are all set automatically based on this parameter (or MEMORY_TARGET if used).

-PGA_AGGREGATE_TARGET Soft memory cap for total of all users’ PGAs. This parameter doesn’t need to be set if you set MEMORY_TARGET, but setting a value as a minimum setting is a good idea. Note that SAP specifies to set this to 20 percent of available memory for OLTP and 40 percent for OLAP.

-SGA_MAX_SIZE Maximum memory that SGA_TARGET can be set to. This parameter doesn’t need to be set if you set MEMORY_TARGET, but you may want to set a value if you use SGA_TARGET.

-OPTIMIZER_MODE :-FIRST_ROWS, FIRST_ROWS_n, or ALL_ROWS. Although RULE/CHOOSE are definitely desupported and obsolete and people are often scolded for even talking about it, I was able to set the mode to RULE in 11gR2. Consider the following error I received when I set OPTIMIZER_MODE to a mode that doesn’t exist (SUPER_FAST):

-SEC_CASE_SENSITIVE_LOGON The default is TRUE, which makes passwords case sensitive (new in 11g). Set this to FALSE to disable this feature.

-SEC_MAX_FAILED_LOGIN_ATTEMPTS This locks an account if the user fails to enter the correct password after this many tries (new in 11g). The default is 10 (consider lowering this value for very secure systems). The DBA must issue an “ALTER USER username ACCOUNT UNLOCK;” to unlock the account.

-CURSOR_SHARING Converts literal SQL to SQL with bind variables, reducing parse overhead. The default is EXACT. Consider setting it to FORCE after research.

-OPTIMIZER_USE_INVISIBLE_INDEXES The default is FALSE to ensure invisible indexes are not used by default (new in 11g). Set this parameter to TRUE to use all of the indexes and to check which ones might have been set incorrectly to be invisible; this could be a helpful tuning exercise, or it could also bring the system to halt so only use in development.

-OPTIMIZER_USE_PENDING_STATISTICS The default is FALSE to ensure pending statistics are not used, whereas setting this to TRUE enables all pending statistics to be used (new in 11g).

-OPTIMIZER_INDEX_COST_ADJ Coarse adjustment between the cost of an index scan and the cost of a full table scan. Set between 1 and 10 to force index use more frequently. Setting this parameter to a value between 1 and 10 pretty much guarantees index use, however, even when not appropriate, so be careful because it is highly dependent on the index design and implementation being correct. Please note that if you are using Applications 11i, setting OPTIMIZER_INDEX_COST_ADJ to any value other than the default (100) is not supported (see Metalink note 169935.1). I’ve seen a benchmark where this was set to 200. Also, see bug 4483286. SAP suggests that you not set it for OLAP, but set it to 20 for OLTP.

-DB_FILE_MULTIBLOCK_READ_COUNT For full table scans to perform I/O more efficiently, this parameter reads the given number of blocks in a single I/O. The default value is 128 in 11gR2, but it is usually noted not to change this from the default.

-LOG_BUFFER Buffer for uncommitted transactions in memory; it must be set in the PFILE if you want to change it. SAP says to use the default, whereas Oracle Applications sets it to 10M. I’ve seen benchmarks with it set over 100M.

-DB_KEEP_CACHE_SIZE Memory allocated to keep pool or an additional data cache that you can set up outside the buffer cache for very important data that you don’t want pushed out of the cache.

-DB_RECYCLE_CACHE_SIZE Memory allocated to a recycle pool or an additional data cache that you can set up outside the buffer cache and in addition to the keep cache described in item 17. Usually, DBAs set this up for ad hoc user query data with poorly written queries.

-OPTIMIZER_USE_SQL_PLAN_BASELINES The default is TRUE, which means Oracle uses these baselines if they exist (new in 11g). Note that Stored Outlines are deprecated (discouraged but they still work) in 11g, as they are replaced with SQL Plan Baselines.

-OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES The default is FALSE, which means that Oracle does not capture them by default, but if you create some, it will use them as stated in the previous parameter (new in 11g).

-LARGE_POOL_SIZE Total blocks in the large pool allocation for large PL/SQL and a few other Oracle options less frequently used.

-STATISTICS_LEVEL Used to enable advisory information and optionally keep additional OS statistics to refine optimizer decisions. TYPICAL is the default.

-JAVA_POOL_SIZE Memory allocated to the JVM for JAVA stored procedures.

-JAVA_MAX_SESSIONSPACE_SIZE Upper limit on memory that is used to keep track of the user session state of JAVA classes.

-OPEN_CURSORS Specifies the size of the private area used to hold (open) user statements. If you get an “ORA-01000: maximum open cursors exceeded,” you may need to increase this parameter, but make sure you are closing cursors that you no longer need. Prior to 9.2.0.5, these open cursors were also cached and, at times, caused issues (ORA-4031) if OPEN_CURSORS was set too high. As of 9.2.05, SESSION_CACHED_CURSORS now controls the setting of the PL/SQL cursor cache. Do not set the parameter SESSION_CACHED_CURSORS as high as you set OPEN_CURSORS, or you may experience ORA-4031 or ORA-7445 errors. SAP recommends setting this to 2000; Oracle Applications has OPEN_CURSORS at 600 and SESSION_CACHED_CURSORS at 500.

Important Files Of Database

Important Files Of Database

What Is a Control File?

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 data files and redo log files
•The timestamp of the database creation
•The current log sequence number
•Checkpoint information

The control file must be available for writing by the Oracle Database server whenever the database is open. Without the control file, the database cannot be mounted and recovery is difficult.

The control file of an Oracle Database is created at the same time as the database. By default, at least one copy of the control file is created during database creation. On some operating systems the default is to create multiple copies. You should create two or more copies of the control file during database creation. You can also create control files later, if you lose control files or want to change particular settings in the control files.

Multiplex Control Files on Different Disks

Every Oracle Database should have at least two control files, each stored on a different physical disk. If a control file is damaged due to a disk failure, the associated instance must be shut down. Once the disk drive is repaired, the damaged control file can be restored using the intact copy of the control file from the other disk and the instance can be restarted. In this case, no media recovery is required.

The behavior of multiplexed control files is this:
•The database writes to all filenames listed for the initialization parameter CONTROL_FILES in the database initialization parameter file.
•The database reads only the first file listed in the CONTROL_FILES parameter during database operation.
•If any of the control files become unavailable during database operation, the instance becomes inoperable and should be aborted.

Note:

Oracle strongly recommends that your database has a minimum of two control files and that they are located on separate physical disks.

Back Up Control Files

It is very important that you back up your control files. This is true initially, and every time you change the physical structure of your database. Such structural changes include:
•Adding, dropping, or renaming data files
•Adding or dropping a tablespace, or altering the read/write state of the tablespace
•Adding or dropping redo log files or groups

Backing Up Control Files

Use the ALTER DATABASE BACKUP CONTROLFILE statement to back up your control files. You have two options:
•Back up the control file to a binary file (duplicate of existing control file) using the following statement:

 ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/backup/control.bkp';
•Produce SQL statements that can later be used to re-create your control file:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

This command writes a SQL script to a trace file where it can be captured and edited to reproduce the control file. View the alert log to determine the name and location of the trace file.

Dropping Control Files

You want to drop control files from the database, for example, if the location of a control file is no longer appropriate. Remember that the database should have at least two control files at all times.

1. Shut down the database.

2. Edit the CONTROL_FILES parameter in the database initialization parameter file to delete the old control file name.

3. Restart the database.

Note:

This operation does not physically delete the unwanted control file from the disk. Use operating system commands to delete the unnecessary file after you have dropped the control file from the database.

What Is the Redo Log?

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 Threads

When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a redo thread. In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck.

This chapter describes how to configure and manage the redo log on a standard single-instance Oracle Database. The thread number can be assumed to be 1 in all discussions and examples of statements. For information about redo log groups in an Oracle Real Application Clusters environment, please refer toOracle Real Application Clusters Administration and Deployment Guide.

Redo Log Contents

Redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.

Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.

Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see "How Oracle Database Writes to the Redo Log") and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.

Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.

How Oracle Database Writes to the Redo Log

The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). See "Managing Archived Redo Logs" for more information.

LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 10-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.

Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.

If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the datafiles.

If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the datafiles and the file has been archived.

Active (Current) and Inactive Redo Log Files

Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.

Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.

If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARCn) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the first available active file.

Log Switches and Log Sequence Numbers

A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.

Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.

Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.

Creating Redo Log Groups

To create a new group of redo log files, use the SQL statement ALTER DATABASE with the ADD LOGFILE clause.

The following statement adds a new group of redo logs to the database:

ALTER DATABASE

ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

Note:
Use fully specify filenames of new log members to indicate where the operating system file should be created. Otherwise, the files will be created in either the default or current directory of the database server, depending upon your operating system.

You can also specify the number that identifies the group using the GROUP clause:

ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

Using group numbers can make administering redo log groups easier. However, the group number must be between 1 and MAXLOGFILES. Do not skip redo log file group numbers (that is, do not number your groups 10, 20, 30, and so on), or you will consume unnecessary space in the control files of the database.

Creating Redo Log Members
In some cases, it might not be necessary to create a complete group of redo log files. A group could already exist, but not be complete because one or more members of the group were dropped (for example, because of a disk failure). In this case, you can add new members to an existing group.

To create new redo log members for an existing group, use the SQL statement ALTER DATABASE with the ADD LOGFILE MEMBER clause. The following statement adds a new redo log member to redo log group number 2:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Notice that filenames must be specified, but sizes need not be. The size of the new members is determined from the size of the existing members of the group.

When using the ALTER DATABASE statement, you can alternatively identify the target group by specifying all of the other members of the group in the TOclause, as shown in the following example:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

Note:
Fully specify the filenames of new log members to indicate where the operating system files should be created. Otherwise, the files will be created in either the default or current directory of the database server, depending upon your operating system. You may also note that the status of the new log member is shown as INVALID. This is normal and it will change to active (blank) when it is first used.

Steps for Renaming Redo Log Members

1.     Shut down the database.

2.     SHUTDOWN

3.     Copy the redo log files to the new location.

Operating system files, such as redo log members, must be copied using the appropriate operating system commands. See your operating system specific documentation for more information about copying files.

Note:
You can execute an operating system command to copy a file (or perform other operating system commands) without exiting SQL*Plus by using the HOST command. Some operating systems allow you to use a character in place of the word HOST. For example, you can use an exclamation point (!) in UNIX.

The following example uses operating system commands (UNIX) to move the redo log members to a new location:

mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo

mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo

4.     Startup the database, mount, but do not open it.

5.     CONNECT / as SYSDBA

6.     STARTUP MOUNT

7.     Rename the redo log members.

Use the ALTER DATABASE statement with the RENAME FILE clause to rename the database redo log files.

ALTER DATABASE RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo' TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';

8.     Open the database for normal operation.

The redo log alterations take effect when the database is opened.

ALTER DATABASE OPEN;

Forcing Log Switches

A log switch occurs when LGWR stops writing to one redo log group and starts writing to another. By default, a log switch occurs automatically when the current redo log file group fills.

You can force a log switch to make the currently active group inactive and available for redo log maintenance operations. For example, you want to drop the currently active group, but are not able to do so until the group is inactive. You may also wish to force a log switch if the currently active group needs to be archived at a specific time before the members of the group are completely filled. This option is useful in configurations with large redo log files that take a long time to fill.

To force a log switch, you must have the ALTER SYSTEM privilege. Use the ALTER SYSTEM statement with the SWITCH LOGFILE clause.

The following statement forces a log switch:

ALTER SYSTEM SWITCH LOGFILE;

Clearing a Redo Log File

A redo log file might become corrupted while the database is open, and ultimately stop database activity because archiving cannot continue. In this situation the ALTER DATABASE CLEAR LOGFILE statement can be used to reinitialize the file without shutting down the database.

The following statement clears the log files in redo log group number 3:

ALTER DATABASE CLEAR LOGFILE GROUP 3;

This statement overcomes two situations where dropping redo logs is not possible:
•If there are only two log groups
•The corrupt redo log file belongs to the current group

If the corrupt redo log file has not been archived, use the UNARCHIVED keyword in the statement.

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

This statement clears the corrupted redo logs and avoids archiving them. The cleared redo logs are available for use even though they were not archived.

If you clear a log file that is needed for recovery of a backup, then you can no longer recover from that backup. The database writes a message in the alert log describing the backups from which you cannot recover.

Note:
If you clear an unarchived redo log file, you should make another backup of the database.

If you want to clear an unarchived redo log that is needed to bring an offline tablespace online, use the UNRECOVERABLE DATAFILE clause in the ALTER DATABASE CLEAR LOGFILE statement.

If you clear a redo log needed to bring an offline tablespace online, you will not be able to bring the tablespace online again. You will have to drop the tablespace or perform an incomplete recovery. Note that tablespaces taken offline normal do not require recovery.

Database Architecture

ORACLE HISTORY

The name Oracle refers to either:

Oracle database, the famous database management system (DBMS) that is widely used for business applications, and runs on most mainframe, micro, and personal computers.

Oracle Corporation, the name of the company that sells the Oracle Database Management System.

Origin of the word ORACLE

IBM is an abbreviation for International Business Machines and SUN is an acronym for Stanford University Network (or Networking). However, the word ORACLE is neither an abbreviation nor an acronym (see an English dictionary for the meaning of the word oracle). It appears in uppercase because this is the branding style Oracle Corp. chose for itself. The word Oracle means: Prophecy or prediction; answer to a question believed to come from the gods; a statement believed to be infallible and authoritative; a shrine at which these answers are given

So why is it named Oracle?

Legend has it that Larry Ellison and Bob Miner were working on a consulting project for the CIA (Central Intelligence Agency in USA) where the CIA wanted to use this new SQL language that IBM had written a white paper about. The code name for the project was Oracle (the CIA saw this as the system to give all answers to all questions or something such ;-).

The project eventually died (of sorts) but Larry and Bob saw the opportunity to take what they had started and market it. So they used that project's codename of Oracle to name their new RDBMS engine. Funny thing is, that the CIA was one of Oracle's first customers...

Further speculation:

We received a lot of E-mails recently stating that ORACLE stands for Oak Ridge Automatic Computer and Logical Engine, a computer built by Oak Ridge National Laboratory in the 1950's. For some time this was the fastest computer in the world. It reportedly could do 100 man-years of calculations in an eight-hour work shift. However, we don't believe this has anything to do with the Oracle Database or Oracle Corporation. However, if you have information to the contrary, please let us know.

Yet another mail stated that Oracle stands for Orbital Relational Analytical Computing Logical Equation. Absolutely amazing! As expected, a Google search on this returned zero hits.

Some jokingly refer to ORACLE as One Real A$#@%& called Larry Ellison.

What is oracle?

Definition : Oracle is a powerful relational database management system that offers a large feature set. Along with Microsoft SQL Server, Oracle is widely regarded as one of the two most popular full-featured database systems on the market today.

What is oracle architecture?

Oracle architecture consists of Oracle server, oracle instance and Oracle database.

Oracle server :  The Oracle server is the system that manages databases and provides comprehensive and integrated information management.
 An Oracle server consists of an instance and a database.

Oracle instance: The Oracle instance allows you to access the Oracle database. Also an instance is a gateway in order to access the database,  An instance is a combination of different background process and memory structures are called an instance

Background processes + Memory structure = Oracle Instance

Memory structures consisting of essentially of two memory areas:

Memory area allocated to the SGA (System Global Area): allocated to start the Instance and represents a fundamental component of an Oracle instance. It consists of Several memory areas:
•The shared memory area
•The buffer cache of the database
•Buffer logging and other structures for the management of internal and external locks, statistical data, etc ...
•The LARGE POOL memory area
•The Java memory area

Shared pool

The size of shared pool is defined by the parameter called shared_pool_size . Shared pool contains many components but important components are library cache,data dictionary cache and control structure .

Library cache

Library cache consists of shared sql and pl/sql area . SQL and PL/SQL area stored most recently used sql and pl/sql statements . We cannot declare the size of lib cache ,but it is complete based on shared pool size. If the size of lib cache is small ,the statements are continously reload in the lib cache which can effect the performance . It is managed through LRU.

Data Dictionary cache

The data dictionary cache hold information about database objects like

table

index

column

privileges

view

trigger .. etc .

The data dictionary cache also known as row cache ,because it store the information in the form of rows instead of buffers. If the size of DDC is small ,then database has to query database tables repeatedly which degrade the performance.

Control Structure

Locking information will be stored in control structure.

Database buffer cache

The size of database buffer cache is defined by the parameter called db_cache_size. Database buffer cache hold the data which is fetch or read from the database files . The size of each buffer in the database buffer cache  is equal to the size of oracle block size .

Database buffer cache consist of two independent sub caches.

DB_KEEP_CACHE_SIZE

It will retain the block in the memory which are likely to be used.

DB_RECYCLE_CACHE_SIZE

It will eliminate the blocks from memory which are having little chances of being used .

Buffer modes

unused

The buffer is ready to use or available to use ,as it was never used .

Cleaned

The data has been written to database and available for use .

dirty

The data has been modified but not written to the disk .

redo log buffer

The size of redo log buffer is defined by parameter called log_buffer. It sequentially record all the changes made to database. log_buffer is a static parameter.

Java Pool

The size of java_pool is defined by the parameter called java_pool_size. If you want to execute java commands inside the database then java pool will be used. Whenever you run dbca,netca etc the memory is allocated from java pool .

Large pool

The size of large_pool is defined by the parameter called large_pool_size. Whenever a rman session is initiated the memory is allocated from large pool and once finished the memory is de allocated.

It does not follow LRU algorithm.

Memory allocated for the PGA (Program Global Area) is allocated at the start of the process server. It is reserved for each user process that connects to the Oracle database and is released at the end of the process

PGA

The PGA (Program or Process Global Area) is a memory area (RAM) that stores data and control information for a single process. For example, it typically contains a sort area, hash area, session cursor cache, etc.

Auto tuning

PGA areas can be sized manually by setting parameters like hash_area_size, sort_area_size etc.

To allow Oracle to auto tune the PGA areas, set the WORKAREA_SIZE_POLICY parameter to AUTO and the PGA_AGGREGATE_TARGET to the size of memory that can be used for PGA. This feature was introduced in Oracle 9i.

Oracle 11g allows users to tune both PGA and SGA areas with a single parameter, called MEMORY_TARGET.

Monitor

PGA usage statistics:
select * from v$pgastat;

Determine a good setting for pga_aggregate_target:
select * from v$pga_target_advice order by pga_target_for_estimate;

Show the maximum PGA usage per process:
select max(pga_used_mem), max(pga_alloc_mem), max(pga_max_mem) from v$process;

Background process : manage and implement the relationships between physical structures and memory structures.

There are two categories

•Mandatory background processes: DBWN, PMON, CKPT, LGWR, SMON

•Optional background process: ARCn, LMDn, RECO, CJQ0, LMON, Snnn, Dnnn, Pnnn, LCKn, QMNn


These processes are mandatory and can be found in all typical database environment.

PMON – Process Monitor

Recover failed user process, Releasing resource, Rollback uncommitted Transaction

SMON – System Monitor

Instance recovery, Cleans and releases temporary segments

LGWR – Log Writer (Redo etc.)

Writes redo entries from redo log buffer to disk (Redo log file)

CKPT – Checkpoint

Ensures data consistency and easy database recovery in case of crash by synchronizing all the data file headers and control files with recent checkpoint information.

DBW0…j – DB Writer

Flushing or writing modi?ed dirty data (buffers) from database buffer cache to disks (datafiles). You can configure addition DB writer processes (up to 20) from DBW0-DBW9 and DBWa through DBWj.

RECO – Distributed Recovery

Recoverer is responsible for recovering failed distributed transactions in a distributed database.

MMON & MMNL – Manageability Monitor and Manageability Monitor Lite

MMON performs tasks related to AWR such as taking snapshots, capturing statistics value for recently modified SQL objects and writes when a metric violates its threshold value.

MMNL writes statistics from the Active Session History (ASH) buffer in the SGA to disk. MMNL writes to disk when the ASH buffer is full.

DIAG – Diagnostic Capture

Prior to Oracle database 11g, DIAG was used in RAC environment. Monitors overall health of the instance and performs diagnostic dumps requested by other processes and dumps triggered by process or instance termination.

Followings are optional and used by specific database feature.

ARCn – Archiver Process

Responsible for copying online redo log to archival storage before being reused. Runs only when database is in Archivelog Mode.

CJQ0 – Job Queue Coordinator Process

Job Queue coordinator is responsible for managing scheduled job processes within the database.

Dnnn – Dispatcher Process

Performs network communication in the shared server architecture

MMAN – Memory Manager

Responsible for managing instance memory based on the workloads.

PSP0 – Process Spawner Process

Spawns Oracle background processes whenever needed.

QMNC – AQ (Advanced Queuing) Coordinator Process

Facilitating various background activities required by AQ and Oracle Streams.

These are introduced in Oracle Database 11g. The first three is mandatory and others could be running depending upon the features being used.

DIA0 – Diagnostic

Responsible for detecting hangs and resolving deadlocks

GEN0 – General Task Execution Process

performs required tasks including SQL and DML

VKTM – Virtual Keeper of TiMe Process

Responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20 ms) and available only when running at elevated priority.

DBRM – DataBase Resource Manager

Performs resource manager tasks setting resource plans.

FBDA – Flashback Data Archiver Process

Archives historical rows for tracked tables into flashback data archives and manages archive space, organization, and retention

SMCO – Space Management Coordinator

Coordinates the execution of various space management tasks

Wnnn – Space Management Slaves

Performs various background space management tasks, including proactive space allocation and space reclamation

RCBG – Result Cache BackGround

Handles result cache messages.

VKRM – Virtual Scheduler for Resource Manager Process

Schedules Resource Manager Activity. Serves as centralized scheduler for Resource Manager activity. VKRM manages the CPU scheduling for all managed Oracle processes.

User process : The program which interacts with the database by starting a connection. It communicates only with the process server.

Servers process : Represents the program that interact directly with the Oracle server. It responds to all requests and return results. It can be dedicated to a client    or a server shared by many.

Oracle database: An Oracle database consists of operating system files, also known as database files, that provide the actual physical storage for database information. The database files are used to ensure that the data is kept consistent and can be recovered in the event of a failure of the instance.

An Oracle Database :The general purpose of a database is to store and retrieve related information. An Oracle database has a logical and a physical structure. The physical structure of the database is the set of operating system files in the database.

An Oracle database consists of three file types:

Data files containing the actual data in the database
Redo logs containing a record of changes made to the database to enable recovery of the data in case of failures
Control files containing information necessary to maintain and verify database integrity

Other Key File Structures

The Oracle server also uses other files that are not part of the database:

• The parameter file defines the characteristics of an Oracle instance. For example, it contains parameters that size some of the memory structures in the SGA.

• The password file authenticates users privileged to start up and shut down an Oracle instance.

• Archived redo log files are offline copies of the redo log files that may be necessary to recover from media failures.

Physical Structure :

Other key files exist and are required to start up and use a database, for example: parameter files, configuration files, password files and so on. However, the physical structure of an Oracle database includes only three types of files: control files, data files, and redo log files.

Control File : 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

The timestamp of the database creation

The current log sequence number

Checkpoint information

The control file must be available for writing by the Oracle Database server whenever the database is open. Without the control file, the database cannot be mounted and recovery is difficult.

The control file of an Oracle Database is created at the same time as the database. By default, at least one copy of the control file is created during database creation. On some operating systems the default is to create multiple copies. You should create two or more copies of the control file during database creation. You can also create control files later, if you lose control files or want to change particular settings in the control files.

Redo log files : The most crucial structure for recovery operations is the redo log, which consists of two or more preallocated 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.

Datafile : Database datafiles are physical files stored on disk. These files are used to store data on disk. Database datafiles are only written to by the DBWR processes that we introduced you to earlier (there is an exception or two to this statement, but for now, assume that this point this true).

These database datafiles are associated with Oracle tablespaces, which are logical containers for tables and indexes.

Oracle Parameter file Concepts
The parameter file (sometimes called init.ora) contains configuration information for the database to use at startup time. The parameter file you configure how much RAM the database is going to use, where to find the control files, where to write trace files, and a whole host of other information. In most cases the database will not start without a parameter file. Oracle allows you to have a manual parameter file (called a PFILE) or a server-side parameter file (called a SPFILE).

What is password file?

Password file : If the DBA wants to start up an Oracle instance there must be a way for Oracle to authenticate this DBA. That is if (s)he is allowed to do so. Obviously, his password cannot be stored in the database, because Oracle cannot access the database before the instance is started up. Therefore, the authentication of the DBA must happen outside of the database. There are two distinct mechanisms to authenticate the DBA: using the password file or through the operating system.

The init parameter remote_login_passwordfile specifies if a password file is used to authenticate the DBA or not. If it set either to shared or exclusive a password file will be used.

What is the difference between a PFILE and SPFILE:

A PFILE is a static, client-side text file that must be updated with a standard text editor like "notepad" or "vi". This file normally reside on the server, however, you need a local copy if you want to start Oracle from a remote machine. DBA's commonly refer to this file as the INIT.ORA file.

An SPFILE (Server Parameter File), on the other hand, is a persistent server-side binary file that can only be modified with the "ALTER SYSTEM SET" command. This means you no longer need a local copy of the pfile to start the database from a remote machine. Editing an SPFILE will corrupt it, and you will not be able to start your database anymore.


(FROM 10G)>> PFILE= If the database is running with pfile and we want to change parameter then the parameter will be change in only memory with the current instance not in the pfile.

Show parameter (name of the parameter)

Example: Sql>alter system set db_recovery_dest=’/u01/xyz’

SPFILE= (server parameter file) if the database is running with spfile and we want to change parameter then the parameter will be change in memory plus+ spfile (by default it changes in both memory and spfile).

Example :>sqlplus> alter system set db_recovery_dest=’/u02/oracle/xyz’ >>>>this change in both

alter system set db_recovery_dest=’/u02/oracle/xyz’ >>>>(scope=both,spfileor memory)

What is Schema?

A schema is the set of objects (tables, views, indexes, etc) that belongs to an user account. It is often used as another way to refer to an Oracle account.

The CREATE SCHEMA statement lets one specify (in a single SQL statement) all data and privilege definitions for a new schema. One can also add definitions to the schema later using DDL statements.

Cursor

A cursors is a pointer used to fetchrows from a result set. One can think of a cursor as a data structure that describes the results returned from a SQL SELECT statement. One of the variables in this structure is a pointer to the next record to be fetched from the query results.

Constraint

A constraint is a data rule or restriction that is enforced within the database rather than at application or object level.

There  are five types of constraints. they  are
•primary key
•unique key
•foreign key (references)
•check constraint
•NOT NULL

Coalesce

Coalesce is an SQL function that returns the first expression that is NOT NULL.

Meaning of coalesce (verb)
 to grow together; to merge; to unite

Block

A block can refer to:
•Data block - A data block is the smallest unit of storage in an Oracle database. Every database has a default block size, although blocks in different tablespaces may have different block sizes.
•Forms block - A Forms block is a container for items (eg. fields). Blocks can be related to tables in the database.

Byte

A byte is a series of 8 bits. Also called a character. Computer storage space is measured in bytes.

Unit 
Abbreviation
Value

A kilobyte
1 KB
1024 bytes
A megabyte
1 MB
1024 KB
A gigabyte
1 GB
1024 MB
A terabyte
1 TB
1024 GB
An exabyte
1 EB
1024 TB

Connect string

A connect string is a string used to identify and connect to a remote database. Connect strings are defined in a local TNSNAMES.ORA file, Oracle Names Server or OID directory.

When you connect, specify the username/password@connectstring

Data dictionary

A data dictionary is repository of metadata (information about data), such as its meaning, relationships to other data, origin, usage and format. The dictionary assists company management, database administrators, systems analysts and application programmers in effectively planning, controlling and evaluating the collection, storage and use of data.

Oracle's data dictionary is stored in the SYS schema.

Directory

The term directory can refer to:
•Operating system directory, a container or folder created with the "mkdir" command for organizing and storing files on a computer's hard disk.
•An Oracle directory, database object pointing to an operating system directory on the database server machine for reading and writing files. Also see UTL_FILE.
•Oracle Internet Directory (or OID), a standard LDAP directory server available with the Oracle Application Server

Flashback

Flashback is an Oracle database facility to quickly move an entire database or a table back to a prior state for recovery purposes. It can also be used to allow users to view data in a database "as it was", at a specified point in the past, even though committed transactions have since been applied.

History

Flashback was first introduced with Oracle 9i with Oracle's Flashback Query feature.

Oracle 10g added the following features:
•Flashback Database
•Flashback Drop
•Flashback Table
•Flashback Version Query
•Flashback Transaction Query

Oracle 11g added Flashback Transaction and Total Recall (or Flashback Data Archive).

Enable database flashback
shutdown immediate;
startup mount;
alter database archivelog;
alter database flashback on;
alter database open;
SELECT flashback_on, log_mode FROM v$database;

Function

A function is a block of PL/SQL code named and stored within the database. A function always returns a single value to its caller.

Granule

A granule is a unit of contiguous virtual memory allocated to a process.

Oracle instance

If an Oracle instance starts up, it allocates the SGA (System Global Area) in granule sized memory units. The size of these granules depends on your database version and somtimes even on the operating system port. For example, for Oracle 9i it is typically 4MB if your SGA is smaller than 128MB and 16MB if your SGA is bigger. For later releases it is typically 4MB if your SGA is smaller than 1GB and 16MB if your SGA is bigger. Issue the below query to get your instance's exact granule size:

SQL> SELECT * FROM v$sgainfo WHERE name = 'Granule Size';
NAME                                  BYTES RES
-------------------------------- ---------- ---
Granule Size                        4194304 No

What is index?

An  alphabetical listing of names and topics along with page numbers where they are discussed.

Index

An index is a special database object that lets you quickly locate particular records based on key column values. Indexes are essential for good database performance.

The index creation process requires a temporary segment if the data cannot be sorted in memory. Indexes can be created with the nologging option.

What is view?

In databasetheory, a view consists of a stored query accessible as a virtual table composed of the result set of a query. Unlike ordinary tables (base tables) in a relational database, a view does not form part of the physical schema: it is a dynamic, virtual table computed or collated from data in the database. Changing the data in a table alters the data shown in subsequent invocations of the view.

What is table?

A  set of data arranged in rows and columns.

What is object?

An object in image processing is an identifiable portion of an image that can be interpreted as a single unit.

What is listerner?

The Listener is a named process which runs on the Oracle Server, awaiting requests from Clients to connect to the Instance.By default, the Listener name is (amazingly enough)“Listener” (but you can call it anything you like).It listens for connection requests on a particular port (the default port number in 8.0 and above is 1521, but once again you can set this to any valid port number if you wish).A client knows where to contact the Listener (the machine it’s running on, and the port it’s listening on) because a local configuration file, called “tnsnames.ora”, gives it the necessary information. More advanced configurations can dispense with the tnsnames.ora (for example, you can opt to install a “Names Server”, which does the same job of telling the client where to find the
 Listener).

What is oracle SID?

The Oracle System ID (SID) is used to uniquely identify a particular database on a system. For this reason, one cannot have more than one database with the same SID on a computer system.

When using RAC, all instances belonging to the same database must have unique SID's.

What is ORACLE BASE?

ORACLE_BASE is an environment variable used as base directory for an OFA(optimal flexible architecture) installation. On Unix systems, this is usually /app/oracle or /u01/app/oracle.

What is ORACLE HOME?

ORACLE_HOME refers to either:

a directory where the Oracle software is installed; or an environment variable pointing to the directory where the Oracle software is installed.

What is data block?

At the finest level of granularity(pieces join to make one component), Oracle stores data in data blocks (also called logical blocks, Oracle blocks, or pages). One data block corresponds to a specific number of bytes of physical database space on disk.

What is extent?

An extent is a contiguous set (side-by-side) of Oracle data blocks allocated to a segment within a tablespace.

The size of an extent is controlled by storage parameters used when you CREATE or ALTER the segment (INITIAL, NEXT and PCT_INCREASE) and tablespace parameters.

What is Segment?

A  segment is a database object that has space allocated to it - for example, a table, index, materialized view, etc. A segment consists of one or more extents allocated within a tablespace.

What is tablespace?

A tablespace is a storage location where the actual data underlying database objects can be kept. It is the physical portion of the database used to allocate storage for all DBMS(database management system) managed segments. ...

What Is a Dirty Block?

Whenever a server process changes or modifies a data block, it becomes a dirty block. Once a server process makes changes to the data block, the user may commit transactions, or transactions may not be committed for quite some time. In either case, the dirty block is not immediately written back to disk.

Writing dirty blocks to disk takes place under the following two conditions:

* When a server process cannot find a clean, reusable buffer after scanning a threshold number of buffers, then the database writer process writes the dirty blocks to disk.

* When the checkpoint takes place, the database writer process writes the dirty blocks to disk.

What is Program Global Area (PGA)

A Program Global Area (PGA) is a memory region that contains data and control information for a server process. It is a non-shared memory region created by Oracle when a server process is started. Access to the PGA is exclusive to that server process and it is read and written only by Oracle code acting on its behalf. It contains a private SQL area and a session memory area.

A private SQL area contains data such as bind information and runtime memory structures. Each session that issues a SQL statement has a private SQL area. Session memory is the memory allocated to hold a session�s variables (logon information) and other information related to the session. For a shared server, the session memory is shared and not private.

LRU

LRU (Least Recently Used) is an algorithm Oracle uses when it needs to make room for new information in the memory space allocated. It replaces the oldest (LRU) data to make room for new data.

 Latch

A latch is an internal Oracle mechanism used to protect data structures in the SGA from simultaneous access. Atomic hardware instructions like TEST-AND-SET are used to implement latches. Latches are more restrictive than locks in that they are always exclusive. Latches are never queued, but will spin or sleep until it obtains a resource or times out. Latches are important for performance tuning.

Lock

Database locks are used to provide concurrency control. Locks are typically acquired at row or table level. Common database lock types are: Shared, eXclusive, Row Share, Row eXclusive, etc.

Common uses of locks are:
•ensure that only one user can modify a record at a time;
•ensure that a table cannot be dropped if another user is querying it;
•ensure that one user cannot delete a record while another is updating it.

Listener

The Oracle Listener is a process listening for incoming database connections. This process is only needed on the database server side. The listener is controlled via the lsnrctl utility. Configuration is done via the listener.ora file.

Logminer

Oracle LogMiner is an Oracle database facility that allows data in redo log files to be extracted and analysed.

LogMiner is typically used to:
•Track database changes for audit purposes
•Undo user errors or logical corruption

After mining the logs, query the V$LOGMNR_CONTENTS view to list all logical change operation conducted on the database. The rows will contain both redo SQL and undo SQL.

Metadata

Metadata is data that is used to describe other data. Data definitions are sometimes referred to as metadata. Examples of metadata include schema, table, index, view and column definitions.

Merge

MERGE (sometimes also called UPSERT) is a SQL command that performs a series of conditional update and/or insert operations. A row is updated if it exists, inserted if it doesn't. Merge was first introduced with Oracle 9i.

Materialized View

A materialized view (MV) is similar to a view but the data is actually stored on disk (view that materializes). Materialized views are often used for summary and pre-joined tables, or just to make a snapshot of a table available on a remote system. A MV must be refreshed when the data in the underlying tables is changed.

MMON

MMON (Memory Monitor) is a background process that gathers memory statistics (snapshots) stores this information in the AWR (automatic workload repository). MMON is also responsible for issuing alerts for metrics that exceed their thresholds.

This process was introduced in Oracle 10g.

MMAN

MMAN (Memory Manager) is a background process that manages the dynamic resizing of SGA memory areas as the workload increases or decreases.

This process was introduced in Oracle 10g.

MMNL

MMNL (MMON Lite) is a background process that assists the MMON process. This process will flush the ASH buffer to AWR tables when the buffer is full or a snapshot is taken.

Transaction

Logical unit of work that contains one or more SQL statements. All statements in a transaction are committed or rolled back together.

Trigger

Stored database procedure automatically invoked whenever a table or view ismodified, for example by INSERT, UPDATE, or DELETE operations

view

A view is a custom-tailored presentation of the data in one or more tables. A view can also be thought of as a "stored query." Views do not actually contain or store data; they derive their data from the tables on which they are based. Like tables, views can be queried, updated, inserted into, and deleted from, with some restrictions. All operations performed on a view affect the base tables of the view.

buffer cache

The database buffer cache is the portion of the SGAthat holds copies of data blocks read from data files. All user processes concurrently connected to the instance share access to the database buffer cache.

commit

Make permanent changes to data (inserts, updates, deletes) in the database. Before changes are committed, both the old and new data exist so that changes can be stored or the data can be restored to its prior state.

database buffer

One of several types of memory structures that stores information within the system global area. Database buffers store the most recently used blocks of data.

Database buffer cache

Memory structure in the system global area that stores the most recently used blocks of data.

Database link

A named schema object that describes a path from one database to another. Database links are implicitly used when a reference is made to a global object name in a distributed database.

DBTZ

Database time zone.

SDTZ

Current session time zone.

Dedicated server

A database server configuration in which a server process handles requests for a single user process.

row

Set of attributes or values pertaining to one entity or record in a table. A row is a collection of column information corresponding to a single record.

ROWID

A globally unique identifier for a row in a database. It is created at the time the row is inserted into a table, and destroyed when it is removed from a table.

schema

Collection of database objects, including logical structures such as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. A schema has the name of the user who controls it.

synonym

An alias for a table, view, sequence, or program unit.

PCTFREE is a block storage parameter used to specify how much space should be left in a database block for future updates. For example, for PCTFREE=10, Oracle will keep on adding new rows to a block until it is 90% full. This leaves 10% for future updates (row expansion).

When using Oracle Advanced Compression, Oracle will trigger block compression when the PCTFREE is reached. This eliminates holes created by row deletions and maximizes contiguous free space in blocks.

Monitor

See the PCTFREE setting for a table:
SQL> SELECT pct_free FROM user_tables WHERE table_name = 'EMP';
  PCT_FREE
----------
        10

PCTINCREASE

PCTINCREASE refers to the percentage by which each next extent (beginning with the third extend) will grow. The size of each subsequent extent is equal to the size of the previous extent plus this percentage increase.

This parameter is only relevant when using old Dictionary Managed tablespaces.

PCTUSED

PCTUSED is a block storage parameter used to specify when Oracle should consider a database block to be empty enough to be added to the freelist. Oracle will only insert new rows in blocks that is enqueued on the freelist. For example, if PCTUSED=40, Oracle will not add new rows to the block unless sufficient rows are deleted from the block so that it falls below 40% empty.

This parameter is ignored for objects created in locally managed tablespaces with Segment Space Management (ASSM) specified as AUTO.

Package

A package is a collection of procedures and functions stored within the database.

A package usually has a specification and a body stored separately in the database. The specification is the interface to the application and declares types, variables, exceptions, cursors and subprograms. The body implements the specification.

When a procedure or function within the package is referenced, the whole package gets loaded into memory. So when you reference another procedure or function within the package, it is already in memory.

Parse tree

A Parse tree is a parsed representation of the grammar of a computer language. This parsed representation is stored in a tree structure.

For example, the grammar of a SQL statement must be parsed into a parse tree before it can be understood and executed by a computer.

Privilege

A privilege is a special right or permission granted to a user or a role to perform specific actions. Granted privileges can be revoked when necessary. For example, one must grant the CREATE SESSION privilege to a database user before that user is allowed to login. Likewise, the CREATE TABLE privilege is required before a user can create new database tables. •role - grouping of privileges

Procedure

A procedure is a block of PL/SQL code named and stored within the database.

Process

A process is a running program. It consists of a virtual memory address space, state (registers, stack, variables, etc.), program code, and other operating system resources.

Query

A query is a SQL SELECT statement that reads data from tables and views within the database, and returns the result set to the requester. Queries cannot change data within the database, use DML statements if you need to make changes.
•Select - statement used for querying the database.
•Join - query data from several tables.
•Subquery - SELECT statement in the WHERE- or HAVING-clause of another SELECT statement.
•Inline view - SELECT statement in the FROM-clause of another SELECT statement.

ROWID

Every record has a unique ROWID within a database representing the physical location on disk where the record lives.

From Oracle 8 the ROWID format and size changed from 8 to 10 bytes. Note that ROWID's will change when you reorganize or export/import a table. In case of a partitioned table, it also changes if the row migrates from a partition to another one during an UPDATE.

Restore

Restore is the action of getting data back to a prior consistent state from a prior taken backup. After a restore the database may need to recovered to roll it forward in time to a particular point oin time.

RMAN

RMAN (Recovery Manager) is a utility used to backup, restore, recover and clone Oracle databases.

Role

A role is a named list or group of privileges that are collected together and granted to users or other roles.

Rollback Segment

A Rollback Segment is a database object containing before-images of data written to the database.

Rollback segments are used to:
•Undo changes when a transaction is rolled back
•Ensure other transactions do not see uncommitted changes made to the database
•Recover the database to a consistent state in case of failures

Instead of creating Rollback Segments, users running Oracle 10g or greater should use Undo Segments instead.

Row

A row is a component of a relational table. In nonrelational terms, a row is called a record. A row is not named (in contrast to a column). Each row in a table has one value in each column of the table.

Schemas and Schema Objects

A schema is a collection of database objects. A schema is owned by a database user and has the same name as that user. Schema objects are the logical structures that directly refer to the database’s data. Schema objects include structures like tables, views, and indexes. (There is no relationship between a tablespace and a schema. Objects in the same schema can be in different tablespaces, and a tablespace can hold objects from different schemas.)


Tables 

Tables are the basic unit of data storage in an Oracle database. Database tables hold all user-accessible data. Each table has columns and rows. Oracle stores each row of a database table containing data for less than 256 columns as one or more row pieces. A table that has an employee database, for example, can have a column called employee number, and each row in that column is an employee’s number.

PL/SQL Overview

PL/SQL is Oracle’s procedural language extension to SQL. PL/SQL combines the ease and flexibility of SQL with the procedural functionality of a structured programming language, such as IF ... THEN, WHILE, and LOOP.When designing a database application, consider the following advantages of using stored PL/SQL:

PL/SQL code can be stored centrally in a database. Network traffic between applications and the database is reduced, so application and system performance increases. Even when PL/SQL is not stored in the database, applications can send blocks of PL/SQL to the database rather than individual SQL statements, thereby reducing network traffic.

Data access can be controlled by stored PL/SQL code. In this case, PL/SQL users can access data only as intended by application developers, unless another access route is granted.

PL/SQL blocks can be sent by an application to a database, running complex operations without excessive network traffic.

The following sections describe the PL/SQL program units that can be defined and stored centrally in a database.


PL/SQL Program Units

Program units are stored procedures, functions, packages, triggers, and anonymous

Transactions.

Procedures and Functions Procedures and functions are sets of SQL and PL/SQL statements grouped together as a unit to solve a specific problem or to perform a set of related tasks. They are created and stored in compiled form in the database and can be run by a user or a database application. Procedures and functions are identical, except that functions always return a single value to the user. Procedures do not return values.

Packages :Packages encapsulate and store related procedures, functions, variables, and other constructs together as a unit in the database. They offer increased functionality (for example, global package variables can be declared and used by any procedure in the package). They also improve performance (for example, all objects of the package are parsed, compiled, and loaded into memory once).

Database Triggers: Database triggers are PL/SQL, Java, or C procedures that run implicitly whenever a table or view is modified or when some user actions or database system actions occur. Database triggers can be used in a variety of ways for managing your database. For example, they can automate data generation, audit data modifications, enforce complex integrity constraints, and customize complex security authorizations.

Autonomous Blocks :You can call autonomous transactions from within a PL/SQL block. When an autonomous PL/SQL block is entered, the transaction context of the caller is suspended. This operation ensures that SQL operations performed in this block (or other blocks called from it) have no dependence or effect on the state of the caller’s transaction context.


XML Overview

XML, eXtensible Markup Language, is the standard way to identify and describe data on the Web. It is a human-readable, machine-understandable, general syntax for describing hierarchical data, applicable to a wide range of applications, databases, e-commerce, Java, web development, searching, and so on.

The Oracle server includes the Oracle XML DB, a set of built-in high-performance

XML storage and retrieval technologies. The XML DB fully absorbs the W3C XML data model into the Oracle server and provides new standard access methods for navigating and querying XML. You get all the advantages of relational database technology and XML technology at the same time. Key aspects of the XML database include the following:

Process Architecture

A process is a "thread of control" or a mechanism in an operating system that can run a series of steps. Some operating systems use the terms job or task. A process generally has its own private memory area in which it runs. An Oracle server has two general types of processes: user processes and Oracle processes.

User (Client) Processes

User processes are created and maintained to run the software code of an application program (such as a Pro*C/C++ program) or an Oracle tool (such asEnterprise Manager). User processes also manage communication with the server process through the program interface, which is described in a later section.

Oracle Processes

Oracle processes are invoked by other processes to perform functions on behalf of the invoking process. The different types of Oracle processes and their specific functions are discussed in the following sections.

Server Processes Oracle creates server processes to handle requests from connected user processes. A server process communicates with the user process and interacts with Oracle to carry out requests from the associated user process. For example, if a user queries some data not already in the database buffers of the SGA, then the associated server process reads the proper data blocks from the datafiles into the SGA.


Privileges

A privilege is a right to run a particular type of SQL statement. Some examples of privileges include the right to: Connect to the database (create a session) Create a table in your schema Select rows from someone else’s table Execute someone else’s stored procedure

The privileges of an Oracle database can be divided into two categories: system

privileges and schema object privileges.

System Privileges System privileges allow users to perform a particular system wide action or a particular action on a particular type of schema object. For example, the privileges to create a tablespace or to delete the rows of any table in the database are system privileges. Many system privileges are available only to administrators and application developers because the privileges are very powerful.

Schema Object Privileges Schema object privileges allow users to perform a particular action on a specific schema object. For example, the privilege to delete rows of a specific table is an object privilege. Object privileges are granted (assigned) to users so that they can use a database application to accomplish specific tasks.

Roles

Oracle provides for easy and controlled privilege management through roles. Roles are named groups of related privileges that you grant to users or other roles.

Storage Settings and Quotas

Oracle provides a way to direct and limit the use of disk space allocated to the database for each user, including default and temporary tablespaces and tablespace quotas. Default Tablespace Each user is associated with a default tablespace. When a user creates a table, index, or cluster and no tablespace is specified to physically contain the schema object, the user’s default tablespace is used if the user has the privilege to create the schema object and a quota in the specified default tablespace. The default tablespace feature provides Oracle with information to direct space use in situations where schema object’s location is not specified.

Temporary Tablespace Each user has a temporary tablespace. When a user runs a SQL statement that requires the creation of temporary segments (such as the creation of an index), the user’s temporary tablespace is used. By directing all users’temporary segments to a separate tablespace, the temporary tablespace feature can reduce I/O contention among temporary segments and other types of segments. Tablespace Quotas Oracle can limit the collective amount of disk space available to the objects in a schema. Quotas (space limits) can be set for each tablespace available to a user. The tablespace quota security feature permits selective control over the amount of disk space that can be consumed by the objects of specific schemas.

Profiles and Resource Limits

Each user is assigned a profile that specifies limitations on several system resources available to the user, including the following: Number of concurrent sessions the user can establish CPU processing time available for: The user’s session A single call to Oracle made by a SQL statement Amount of logical I/O available for: The user’s session A single call to Oracle made by a SQL statement Amount of idle time available for the user’s session, Amount of connect time available for the user’s session Password restrictions: Account locking after multiple unsuccessful login attempts Password expiration and grace period Password reuse and complexity restrictions

Different profiles can be created and assigned individually to each user of the database. A default profile is present for all users not explicitly assigned a profile.

The resource limit feature prevents excessive consumption of global database system resources.


Transparent Application Failover

Transparent Application Failover (TAF) enables an application user to automatically reconnect to a database if the connection fails. Active transactions rollback, but the new database connection, made by way of a different node, is identical to the original. This is true regardless of how the connection fails.

With Transparent Application Failover, a client notices no loss of connection as long as there is one instance left serving the application. The database administrator controls which applications run on which instances and also creates a failover order for each application.


Introduction to the Data Dictionary

One of the most important parts of an Oracle database is its data dictionary, which is a read-only set of tables that provides information about the database. A data dictionary contains:

_ The definitions of all schema objects in the database (tables, views, indexes, clusters, synonyms, sequences, procedures, functions, packages, triggers, and so on)

_ How much space has been allocated for, and is currently used by, the schema objects

_ Default values for columns

_ Integrity constraint information

_ The names of Oracle users

_ Privileges and roles each user has been granted

_ Auditing information, such as who has accessed or updated various schema objects

_ Other general database information


The data dictionary is structured in tables and views, just like other database data.

All the data dictionary tables and views for a given database are stored in that database’s SYSTEM tablespace. Not only is the data dictionary central to every Oracle database, it is an important tool for all users, from end users to application designers and database administrators. Use SQL statements to access the data dictionary. Because the data dictionary is read-only, you can issue only queries (SELECT statements) against it’s tables and views.


Structure of the Data Dictionary

The data dictionary consists of the following:

Base Tables

The underlying tables that store information about the associated database. Only Oracle should write to and read these tables. Users rarely access them directly because they are normalized, and most of the data is stored in a cryptic format.

User-Accessible Views

The views that summarize and display the information stored in the base tables of the data dictionary. These views decode the base table data into useful information, such as user or table names, using joins and WHERE clauses to simplify the information. Most users are given access to the views rather than the base tables. SYS, Owner of the Data Dictionary


The Oracle user SYS owns all base tables and user-accessible views of the data

dictionary. No Oracle user should ever alter (UPDATE, DELETE, or INSERT) any rows or schema objects contained in the SYS schema, because such activity can compromise data integrity. The security administrator must keep strict control of this central account.

Caution: Altering or manipulating the data in data dictionary tables can permanently and detrimentally affect the operation of a database.


How the Data Dictionary Is Used

The data dictionary has three primary uses:

Oracle accesses the data dictionary to find information about users, schema objects, and storage structures.

_ Oracle modifies the data dictionary every time that a data definition language (DDL) statement is issued.

_ Any Oracle user can use the data dictionary as a read-only reference for information about the database.

Caution: No data in any data dictionary table should be altered or deleted by any user.

The DUAL Table

The table named DUAL is a small table in the data dictionary that Oracle and user-written programs can reference to guarantee a known result. This table has one column called DUMMY and one row containing the value X.

Transaction Control Statements

Transaction control statements manage the changes made by DML statements and group DML statements into transactions. They enable you to:

_ Make a transaction’s changes permanent (COMMIT)

_ Undo the changes in a transaction, either since the transaction started or since a savepoint (ROLLBACK)

_ Set a point to which you can roll back (SAVEPOINT)

_ Establish properties for a transaction (SET TRANSACTION)


Parsing

Parsing is one stage in the processing of a SQL statement. When an application issues a SQL statement, the application makes a parse call to Oracle. During the parse call, Oracle:

_ Checks the statement for syntactic and semantic validity

_ Determines whether the process issuing the statement has privileges to run it

_ Allocates a private SQL area for the statements