Kumars
Oracle DBA
1.
1.1.
1.2.
1.3.
1.4.
1.6.
1.7.
1.8.
Normalization _________________________________________________________ 21
2.1.
2.2.
Competitors ___________________________________________________________ 40
2.3.
2.4.
2.5.
3.1.
3.2.
3.3.
4.
4.1.
4.2.
4.3.
4.6.
5.
5.1.
5.2.
5.3.
5.4.
6.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
6.9.
their respective DBMSs have grown in orders of magnitudes. For decades it has been unlikely that a
complex information system can be built effectively without a proper database supported by a
DBMS. The utilization of databases is now spread to such a wide degree that virtually every
technology and product relies on databases and DBMSs for its development and commercialization,
or even may have such embedded in it. Also, organizations and companies, from small to large,
heavily depend on databases for their operations.
No widely accepted exact definition exists for DBMS. However, a system needs to provide
considerable functionality to qualify as a DBMS. Accordingly its supported data collection needs to
meet respective usability requirements (broadly defined by the requirements below) to qualify as a
database. Thus, a database and its supporting DBMS are defined here by a set of general
requirements listed below. Virtually all existing mature DBMS products meet these requirements to
a great extent, while less mature either meet them or converge to meet them.
suited as a modeling language. For this reason a different model, the entity-relationship model
which emerged shortly later (1976), gained popularity for database design.
In the period since the 1970s database technology has kept pace with the increasing resources
becoming available from the computing platform: notably the rapid increase in the capacity and
speed (and reduction in price) of disk storage, and the increasing capacity of main memory. This has
enabled ever larger databases and higher throughputs to be achieved.
The rigidity of the relational model, in which all data is held in tables with a fixed structure of rows
and columns, has increasingly been seen as a limitation when handling information that is richer or
more varied in structure than the traditional 'ledger-book' data of corporate information systems:
for example, document databases, engineering databases, multimedia databases, or databases used
in the molecular sciences. Various attempts have been made to address this problem, many of them
gathering under banners such as post-relational or NoSQL. Two developments of note are the object
database and the XML database. The vendors of relational databases have fought off competition
from these newer models by extending the capabilities of their own products to support a wider
variety of data types.
Savings account and customer records are kept in permanent system files.
Application programs are written to manipulate files to perform the following tasks:
Debit or credit an account.
Add a new account.
Find an account balance.
Generate monthly statements.
2. Development of the system proceeds as follows:
o New application programs must be written as the need arises.
o New permanent files are created as required.
o but over a long period of time files may be in different formats, and
o Application programs may be in different languages.
3. So we can see there are problems with the straight file-processing approach:
o Data redundancy and inconsistency
Same information may be duplicated in several places.
All copies may not be updated properly.
o Difficulty in accessing data
May have to write a new application program to satisfy an unusual request.
E.g. find all customers with the same postal code.
Could generate this data manually, but a long job...
o Data isolation
Data in different files.
These problems and others led to the development of database management systems.
When multiple users access the database concurrently the actions of a user should be uninterrupted
and unaffected by actions of other users. These concurrent actions should maintain the DB's
consistency (i.e., keep the DB from corruption).
Recovery from failure and disaster
All computer systems, including DBMSs, are prone to failures for many reasons (both software and
hardware related). Failures typically corrupt the DB, typically to the extent that it is impossible to
repair it without special measures. The DBMS should provide automatic recovery from failure
procedures that repair the DB and return it to a well defined state.
Backup and restore
Sometimes it is desired to bring a database back to a previous state (for many reasons, e.g., cases
when the database is found corrupted due to a software error, or if it has been updated with
erroneous data). To achieve this a backup operation is done occasionally or continuously, where
each desired database state (i.e., the values of its data and their embedding in database's data
structures) is kept within dedicated backup files (many techniques exist to do this effectively). When
this state is needed, i.e., when it is decided by a database administrator to bring the database back
to this state (e.g., by specifying this state by a desired point in time when the database was in this
state), these files are utilized to restore that state.
Data independence
Data independence pertains to a database's life cycle (see Database building, maintaining, and
tuning below). It strongly impacts the convenience and cost of maintaining an application and its
database, and has been the major motivation for the emergence and success of the Relational
model, as well as the convergence to a common database architecture. In general the term "data
independence" means that changes in the database's structure do not require changes in its
application's computer programs, and that changes in the database at a certain architectural level
(see below) do not affect the database's levels above. Data independence is achieved to a great
extent in contemporary DBMS, but it is not completely attainable, and achieved at different degrees
for different types of database structural changes.
1.4.1.
Database Types
These days, when you talk about databases in the wild, you are primarily talking about two types:
analytical databases and operational databases.
Let's examine each type.
Analytic Databases
Analytic databases (a.k.a. OLAP- On Line Analytical Processing) are primarily static, read-only
databases which store archived, historical data used for analysis. For example, a company might
store sales records over the last ten years in an analytic database and use that database to analyze
marketing strategies in relationship to demographics.
On the web, you will often see analytic databases in the form of inventory catalogs such as the one
shown previously from Amazon.com. An inventory catalog analytical database usually holds
descriptive information about all available products in the inventory.
Web pages are generated dynamically by querying the list of available products in the inventory
against some search parameters. The dynamically-generated page will display the information about
each item (such as title, author, ISBN) which is stored in the database.
Operational Databases
Operational databases (a.k.a. OLTP On Line Transaction Processing), on the other hand, are used to
manage more dynamic bits of data. These types of databases allow you to do more than simply view
archived data. Operational databases allow you to modify that data (add, change or delete data).
These types of databases are usually used to track real-time information. For example, a company
might have an operational database used to track warehouse/stock quantities. As customers order
products from an online web store, an operational database can be used to keep track of how many
items have been sold and when the company will need to reorder stock.
Perhaps the most intuitive way to visualize this type of relationship is by visualizing an upside down
tree of data. In this tree, a single table acts as the "root" of the database from which other tables
"branch" out.
You will be instantly familiar with this relationship because that is how all windows-based directory
management systems (like Windows Explorer) work these days.
Relationships in such a system are thought of in terms of children and parents such that a child may
only have one parent but a parent can have multiple children. Parents and children are tied together
by links called "pointers" (perhaps physical addresses inside the file system). A parent will have a list
of pointers to each of their children.
This child/parent rule assures that data is systematically accessible. To get to a low-level table, you
start at the root and work your way down through the tree until you reach your target. Of course, as
you might imagine, one problem with this system is that the user must know how the tree is
structured in order to find anything!
The hierarchical model however, is much more efficient than the flat-file model we discussed earlier
because there is not as much need for redundant data. If a change in the data is necessary, the
change might only need to be processed once. Consider the student flatfile database example from
our discussion of what databases are:
Name
Address
Course
Grade
C+
As we mentioned before, this flatfile database would store an excessive amount of redundant data.
If we implemented this in a hierarchical database model, we would get much less redundant data.
Consider the following hierarchical database scheme:
However, as you can imagine, the hierarchical database model has some serious problems. For one,
you cannot add a record to a child table until it has already been incorporated into the parent table.
This might be troublesome if, for example, you wanted to add a student who had not yet signed up
for any courses.
Worse, yet, the hierarchical database model still creates repetition of data within the database. You
might imagine that in the database system shown above, there may be a higher level that includes
multiple course. In this case, there could be redundancy because students would be enrolled in
several courses and thus each "course tree" would have redundant student information.
Redundancy would occur because hierarchical databases handle one-to-many relationships well but
do not handle many-to-many relationships well. This is because a child may only have one parent.
However, in many cases you will want to have the child be related to more than one parent. For
instance, the relationship between student and class is a "many-to-many". Not only can a student
take many subjects but a subject may also be taken by many students. How would you model this
relationship simply and efficiently using a hierarchical database? The answer is that you wouldn't.
Though this problem can be solved with multiple databases creating logical links between children,
the fix is very kludgy and awkward.
Faced with these serious problems, the computer brains of the world got together and came up with
the network model.
Network model
In this model a hierarchical relationship between two record types (representing real-world entities)
is established by the set construct. A set consists of circular linked lists where one record type, the
set owner or parent, appears once in each circle, and a second record type, the subordinate or child,
may appear multiple times in each circle. In this way a hierarchy may be established between any
two record types, e.g., type A is the owner of B. At the same time another set may be defined where
B is the owner of A. Thus all the sets comprise a general directed graph (ownership defines a
direction), or network construct. Access to records is either sequential (usually in each record type)
or by navigation in the circular linked lists.
This model is more general and powerful than the hierarchical, and has been the most popular
before being replaced by the Relational model. It has been standardized by CODASYL. Popular DBMS
products that utilized it were Cincom Systems' Total and Cullinet's IDMS. IDMS gained a
considerable customer base and exists and supported until today. In the 1980s it has adopted the
Relational model and SQL in addition to its original tools and languages.
In many ways, the Network Database model was designed to solve some of the more serious
problems with the Hierarchical Database Model. Specifically, the Network model solves the problem
of data redundancy by representing relationships in terms of sets rather than hierarchy. The model
had its origins in the Conference on Data Systems Languages (CODASYL) which had created the Data
Base Task Group to explore and design a method to replace the hierarchical model.
The network model is very similar to the hierarchical model actually. In fact, the hierarchical model
is a subset of the network model. However, instead of using a single-parent tree hierarchy, the
network model uses set theory to provide a tree-like hierarchy with the exception that child tables
were allowed to have more than one parent. This allowed the network model to support many-tomany relationships.
Visually, a Network Database looks like a hierarchical Database in that you can see it as a type of
tree. However, in the case of a Network Database, the look is more like several trees which share
branches. Thus, children can have multiple parents and parents can have multiple children.
Nevertheless, though it was a dramatic improvement, the network model was far from perfect.
Most profoundly, the model was difficult to implement and maintain. Most implementations of the
network model were used by computer programmers rather than real users. What was needed was
a simple model which could be used by real end users to solve real problems.
So how do you find data in a relational database if there is no map (like a hierarchy defined by
pointers) to follow?
Well, in the relational model, operations that manipulate data do so on the basis of the data values
themselves. Thus, if you wish to retrieve a row from a table for example, you do so by comparing
the value stored within a particular column for that row to some search criteria.
For example, you might say (not getting into syntax yet) "Give me all the rows from the 'STUDENTS'
table which have 'Selena' in the 'FIRST_NAME' column."
The database might return a list which looks essentially like this:
Selena Sol
SID-001 213-456-7890
SID-991 310-234-6475
You could then use the data from a retrieved row to query another table. For example, you might
say "Okay, I want to know what grade 'Selena Sol' received in 'Underwater Basket Weaving 101'. So I
will now use the 'Student ID' number from my previous query as the keyword in my next query. I
want the row in the 'Underwater Basket Weaving Course' table where student ID equals 'SID-001'.
This data access methodology makes the relational model a lot different from and better than the
earlier database models because it is a much simpler model to understand. This is probably the main
reason for the popularity of relational database systems today.
Another benefit of the relational system is that it provides extremely useful tools for database
administration. Essentially, tables can not only store actual data but they can also be used as the
means for generating meta-data (data about the table and field names which form the database
structure, access rights to the database, integrity and data validation rules etc).
Thus everything within the relational model can be stored in tables. This means that many relational
systems can use operations recursively in order to provide information about the database. In other
words, a user can query information concerning table names, access rights, or some data and the
results of these queries would then be presented to the user in the form of a table.
This makes database administration as easy as usage!
Entity-relationship model
In software engineering, an Entity Relationship model (ER model for short) is an abstract way to
describe a database. It usually starts with a relational database, which stores data in tables. Some of
the data in these tables point to data in other tables - for instance, your entry in the database could
point to several entries for each of the phone numbers that are yours. The ER model would say that
you are an entity, and each phone number is an entity, and the relationship between you and the
phone numbers is 'has a phone number'. Diagrams created to design these entities and relationships
are called entityrelationship diagrams or ER diagrams.
Object model
In recent years, the object-oriented paradigm has been applied in areas such as engineering and
spatial databases, telecommunications and in various scientific domains. The conglomeration of
object oriented programming and database technology led to this new kind of database. These
databases attempt to bring the database world and the application-programming world closer
together, in particular by ensuring that the database uses the same type system as the application
program. This aims to avoid the overhead (sometimes referred to as the impedance mismatch) of
converting information between its representation in the database (for example as rows in tables)
and its representation in the application program (typically as objects). At the same time, object
databases attempt to introduce key ideas of object programming, such as encapsulation and
polymorphism, into the world of databases.
A variety of these ways have been tried[by whom?] for storing objects in a database. Some products
have approached the problem from the application-programming side, by making the objects
manipulated by the program persistent. This also typically requires the addition of some kind of
query language, since conventional programming languages do not provide language-level
functionality for finding objects based on their information content. Others[which?] have attacked the
problem from the database end, by defining an object-oriented data model for the database, and
defining a database programming language that allows full programming capabilities as well as
traditional query facilities.
Object relational model
XML as a database data model
Other database models
Products offering a more general data model than the relational model are sometimes classified
as post-relational. Alternate terms include "hybrid database", "Object-enhanced RDBMS" and
others. The data model in such products incorporates relations but is not constrained by E.F. Codd's
Information Principle, which requires that all information in the database must be cast explicitly in
terms of values in relations and in no other way
Some of these extensions to the relational model integrate concepts from technologies that predate the relational model. For example, they allow representation of a directed graph with trees on
the nodes. The German company sones implements this concept in its GraphDB.
Some post-relational products extend relational systems with non-relational features. Others arrived
in much the same place by adding relational features to pre-relational systems. Paradoxically, this
allows products that are historically pre-relational, such as PICK and MUMPS, to make a plausible
claim to be post-relational.
The resource space model (RSM) is a non-relational data model based on multi-dimensional
classification.
DBMS developers - These are the people that design and build the DBMS product, and the only
ones who touch its code. They are typically the employees of a DBMS vendor (e.g., Oracle, IBM,
Microsoft, Sybase), or, in the case of Open source DBMSs (e.g., MySQL), volunteers or people
supported by interested companies and organizations. They are typically skilled systems
programmers. DBMS development is a complicated task, and some of the popular DBMSs have
been under development and enhancement (also to follow progress in technology) for
decades.
Application developers and database administrators - These are the people that design and
build a database-based application that uses the DBMS. The latter group members design the
needed database and maintain it. The first group members write the needed application
programs which the application comprises. Both are well familiar with the DBMS product and
use its user interfaces (as well as usually other tools) for their work. Sometimes the application
itself is packaged and sold as a separate product, which may include the DBMS inside (see
embedded database; subject to proper DBMS licensing), or sold separately as an add-on to the
DBMS.
Application's end-users (e.g., accountants, insurance people, medical doctors, etc.) - These
people know the application and its end-user interfaces, but need not know nor understand
the underlying DBMS. Thus, though they are the intended and main beneficiaries of a DBMS,
they are only indirectly involved with it.
1.8. Normalization
In the field of relational database design, normalization is a systematic way of ensuring that a
database structure is suitable for general-purpose querying and free of certain undesirable
characteristicsinsertion, update, and deletion anomaliesthat could lead to a loss of data
integrity.
A standard piece of database design guidance is that the designer should create a fully normalized
design;
selective denormalization can
subsequently
be
performed,
but
only
for performance reasons. However, some modeling disciplines, such as the dimensional
modeling approach to data warehouse design, explicitly recommend non-normalized designs, i.e.
designs that in large part do not adhere to 3NF. Normalization consists of normal forms that are
1NF,2NF,3NF,BOYCE-CODD NF (3.5NF),4NF and 5NF
Database normalization is the process of organizing the fields and tables of a relational database to
minimize redundancy and dependency. Normalization usually involves dividing large tables into
smaller (and less redundant) tables and defining relationships between them. The objective is to
isolate data so that additions, deletions, and modifications of a field can be made in just one table
and then propagated through the rest of the database via the defined relationships.
Edgar F. Codd, the inventor of the relational model, introduced the concept of normalization and
what we now know as the First Normal Form (1NF) in 1970.[1] Codd went on to define the Second
Normal Form (2NF) and Third Normal Form (3NF) in 1971,[2] and Codd and Raymond F.
Boyce defined the Boyce-Codd Normal Form (BCNF) in 1974.[3] Informally, a relational database
table is often described as "normalized" if it is in the Third Normal Form.[4] Most 3NF tables are free
of insertion, update, and deletion anomalies.
A standard piece of database design guidance is that the designer should create a fully normalized
design; selective denormalization can subsequently be performed for performance reasons.
1.8.1.
Objectives of normalization
A basic objective of the first normal form defined by Codd in 1970 was to permit data to be queried
and manipulated using a "universal data sub-language" grounded in first-order logic. (SQL is an
example of such a data sub-language, albeit one that Codd regarded as seriously flawed.)
The objectives of normalization beyond 1NF (First Normal Form) were stated as follows by Codd:
To free the collection of relations from undesirable insertion, update and deletion
dependencies;
To reduce the need for restructuring the collection of relations, as new types of data are
introduced, and thus increase the life span of application programs;
To make the relational model more informative to users;
To make the collection of relations neutral to the query statistics, where these statistics are
liable to change as time goes by.
1.8.2.
Functional dependency
In a given table, an attribute Y is said to have a functional dependency on a set of
attributes X (written X Y) if and only if each X value is associated with precisely one Y value. For
example, in an "Employee" table that includes the attributes "Employee ID" and "Employee Date of
Birth", the functional dependency {Employee ID} {Employee Date of Birth} would hold. It follows
from the previous two sentences that each {Employee ID} is associated with precisely one
{Employee Date of Birth}.
Trivial functional dependency
A trivial functional dependency is a functional dependency of an attribute on a superset of itself.
{Employee ID, Employee Address} {Employee Address} is trivial, as is {Employee Address}
{Employee Address}.
Full functional dependency
An attribute is fully functionally dependent on a set of attributes X if it is:
not functionally dependent on any proper subset of X. {Employee Address} has a functional
dependency on {Employee ID, Skill}, but not a full functional dependency, because it is also
dependent on {Employee ID}.
Transitive dependency
A transitive dependency is an indirect functional dependency, one in which XZ only by virtue
of XY and YZ.
Multivalued dependency
A multivalued dependency is a constraint according to which the presence of certain rows in a table
implies the presence of certain other rows.
Join dependency
A table T is subject to a join dependency if T can always be recreated by joining multiple tables each
having a subset of the attributes of T.
Superkey
A superkey is a combination of attributes that can be used to uniquely identify a database record. A
table might have many superkeys.
Candidate key
A candidate key is a special subset of superkeys that do not have any extraneous information in
them: it is a minimal superkey.
Examples: Imagine a table with the fields <Name>, <Age>, <SSN> and <Phone Extension>. This table
has many possible superkeys. Three of these are <SSN>, <Phone Extension, Name> and <SSN,
Name>. Of those listed, only <SSN> is a candidate key, as the others contain information not
necessary to uniquely identify records ('SSN' here refers to Social Security Number, which is unique
to each person).
Non-prime attribute
A non-prime attribute is an attribute that does not occur in any candidate key. Employee Address
would be a non-prime attribute in the "Employees' Skills" table.
Prime attribute
A prime attribute, conversely, is an attribute that does occur in some candidate key.
Primary key
Most DBMSs require a table to be defined as having a single unique key, rather than a number of
possible unique keys. A primary key is a key which the database designer has designated for this
purpose.
1.8.3.
Normal forms
The normal forms (abbrev. NF) of relational database theory provide criteria for determining a
table's degree of vulnerability to logical inconsistencies and anomalies. The higher the normal form
applicable to a table, the less vulnerable it is. Each table has a "highest normal form" (HNF): by
definition, a table always meets the requirements of its HNF and of all normal forms lower than its
HNF; also by definition, a table fails to meet the requirements of any normal form higher than its
HNF.
The normal forms are applicable to individual tables; to say that an entire database is in normal
form n is to say that all of its tables are in normal form n.
Newcomers to database design sometimes suppose that normalization proceeds in an iterative
fashion, i.e. a 1NF design is first normalized to 2NF, then to 3NF, and so on. This is not an accurate
description of how normalization typically works. A sensibly designed table is likely to be in 3NF on
the first attempt; furthermore, if it is 3NF, it is overwhelmingly likely to have an HNF of 5NF.
Achieving the "higher" normal forms (above 3NF) does not usually require an extra expenditure of
effort on the part of the designer, because 3NF tables usually need no modification to meet the
requirements of these higher normal forms.
The main normal forms are summarized below.
1NF
First normal
form
2NF
Second
normal form
3NF
Third normal
form
Elementary
EKNF Key Normal
Form
In
Brief definition
[2]
E.F. Codd
1971
C. Zaniolo
1982 [10]
BCNF
BoyceCodd
normal form
Raymond F.
1974 [11]
Boyce and E.F. Codd
4NF
Fourth
normal form
Ronald Fagin
1977 [12]
5NF
Fifth normal
form
Ronald Fagin
1979 [13]
Ronald Fagin
1981
[14]
2002
[15]
Domain/key
DKNF
normal form
6NF
Sixth normal
form
1.8.4.
Normalization Example
We will demonstrate the process of normalisation (to 3NF) by use of an example. Normalisation is a
bottom-up technique for database design, normally based on an existing system (which may be
paper-based). We start by analysing the documentation, eg reports, screen layouts from that
system. We will begin with the Project Management Report, which describes projects being worked
upon by employees. This report is to be 'normalised'. Each of the first four normalisation steps is
explained.
Step 1
Select the data source (ie the report from the previous page) and convert into an unnormalised
table (UNF). The process is as follows:
Create column headings for the table for each data item on the report (ignoring any
calculated fields). A calculated field is one that can be derived from other information on
the form. In this case total staff and average hourly rate.
Enter sample data into table. (This data is not simply the data on the report but a
representative sample. In this example it shows several employees working on several
projects. In this company the same employee can work on different projects and at a
different hourly rate.)
Remove duplicate data. (In this example, for the chosen key of Project Code, the values for
Project Code, Project Title, Project Manager and Project Budget are duplicated if there are
two or more employees working on the same project. Project Code chosen for the key and
duplicate data, associated with each project code, is removed. Do not confuse duplicate
data with repeating attributes which is descibed in the next step.
Step 2
Transform a table of unnormalised data into first normal form (1NF). any repeating attributes to a
new table. A repeating attribute is a data field within the UNF relation that may occur with multiple
values for a single value of the key. The process is as follows:
Remove these repeating attributes to a new table together with a copy of the key from the
UNF table.
Assign a key to the new table (and underline it). The key from the original unnormalised
table always becomes part of the key of the new table. A compound key is created. The
value for this key must be unique for each entity occurrence.
Notes:
After removing the duplicate data the repeating attributes are easily identified.
In the previous table the Employee No, Employee Name, Department No, Department
Name and Hourly Rate attributes are repeating. That is, there is potential for more than one
occurrence of these attributes for each project code. These are the repeating attributes and
have been to a new table together with a copy of the original key (ie: Project Code).
A key of Project Code and Employee No has been defined for this new table. This
combination is unique for each row in the table.
Project Title
Project Manager
Project Budget
PC010
Pensions System
M Phillips
24500
PC045
Salaries System
H Martin
17400
PC064
HR System
K Lewis
12250
Project Code
Employee No. Employee Name Department No. Department Name Hourly Rate
PC010
S10001
A Smith
L004
IT
22.00
PC010
S10030
L Jones
L023
Pensions
18.50
PC010
S21010
P Lewis
L004
IT
21.00
PC045
S10010
B Jones
L004
IT
21.75
PC045
S10001
A Smith
L004
IT
18.00
PC045
S31002
T Gilbert
L028
Database
25.50
PC045
S13210
W Richards
L008
Salary
17.00
PC064
S31002
T Gilbert
L028
Database
23.25
PC064
S21010
P Lewis
L004
IT
17.50
PC064
S10034
B James
L009
HR
16.50
Step 3
Transform 1NF data into second normal form (2NF). Remove any -key attributes (partial
Dependencies) that only depend on part of the table key to a new table.
What has to be determined "is field A dependent upon field B or vice versa?" This means: "Given a
value for A, do we then have only one possible value for B, and vice versa?" If the answer is yes, A
and B should be put into a new relation with A becoming the primary key. A should be left in the
original relation and marked as a foreign key.
Ignore tables with (a) a simple key or (b) with no non-key attributes (these go straight to 2NF with
no conversion).
The process is as follows:
Take each non-key attribute in turn and ask the question: is this attribute dependent on one part of
the key?
If yes, remove the attribute to a new table with a copy of the part of the key it is dependent
upon. The key it is dependent upon becomes the key in the new table. Underline the key in
this new table.
If no, check against other part of the key and repeat above process
If still no, ie: not dependent on either part of the key, keep attribute in current table.
Notes:
The first table went straight to 2NF as it has a simple key (Project Code).
Employee name, Department No and Department Name are dependent upon Employee No
only. Therefore, they were moved to a new table with Employee No being the key.
However, Hourly Rate is dependent upon both Project Code and Employee No as an
employee may have a different hourly rate depending upon which project they are working
on. Therefore it remained in the original table.
Project Title
Project
Manager
Project
Budget
PC010
Pensions System
M Phillips
24500
PC045
Salaries System
H Martin
17400
PC064
HR System
K Lewis
12250
Project
Code
Employee
No.
PC010
S10001
PC010
Hourly
Rate
Employee
No.
Employee
Name
Department
No.
Department
Name
22.00
S10001
A Smith
L004
IT
S10030
18.50
S10030
L Jones
L023
Pensions
PC010
S21010
21.00
S21010
P Lewis
L004
IT
PC045
S10010
21.75
S10010
B Jones
L004
IT
PC045
S10001
18.00
S31002
T Gilbert
L028
Database
PC045
S31002
25.50
S13210
W Richards
L008
Salary
PC045
S13210
17.00
S10034
B James
L009
HR
PC064
S31002
23.25
PC064
S21010
17.50
PC064
S10034
16.50
Step 4
Data in second normal form (2NF) into third normal form (3NF).
Remove to a new table any non-key attributes that are more dependent on other non-key attributes
than the table key.
What has to be determined is "is field A dependent upon field B or vice versa?" This means: "Given a
value for A, do we then have only one possible value for B, and vice versa?" If the answer is yes,
then A and B should be put into a new relation, with A becoming the primary key. A should be left in
the original relation and marked as a foreign key.
Ignore tables with zero or only one non-key attribute (these go straight to 3NF with no conversion).
The process is as follows: If a non-key attribute is more dependent on another non-key attribute
than the table key:
Move the dependent attribute, together with a copy of the non-key attribute upon which it
is dependent, to a new table.
Make the non-key attribute, upon which it is dependent, the key in the new table. Underline
the key in this new table.
Leave the non-key attribute, upon which it is dependent, in the original table and mark it
a foreign key (*).
Notes:
The project team table went straight from 2NF to 3NF as it only has one non-key attribute.
Project Title
Project Manager
Project Budget
PC010
Pensions System
M Phillips
24500
PC045
Salaries System
H Martin
17400
PC064
HR System
K Lewis
12250
Project Code
Employee No.
PC010
S10001
22.00
PC010
S10030
18.50
PC010
S21010
21.00
PC045
S10010
21.75
PC045
S10001
18.00
PC045
S31002
25.50
PC045
S13210
17.00
064
S31002
23.25
PC064
S21010
17.50
PC064
S10034
16.50
Hourly Rate
Employee No.
Employee Name
S10001
A Smith
L004
S10030
L Jones
L023
S21010
P Lewis
L004
S10010
B Jones
L004
S31002
T Gilbert
L023
S13210
W Richards
L008
S10034
B James
L0009
Department No.
Department Name
L004
IT
L023
Pensions
L028
Database
L008
Salary
Department No. *
L009
HR
design. Disregarding these rules may result in less than perfect database design, but should
not affect functionality.
1.8.5.
Denormalization
Databases intended for online transaction processing (OLTP) are typically more normalized than
databases intended for online analytical processing (OLAP). OLTP applications are characterized by a
high volume of small transactions such as updating a sales record at a supermarket checkout
counter. The expectation is that each transaction will leave the database in a consistent state. By
contrast, databases intended for OLAP operations are primarily "read mostly" databases. OLAP
applications tend to extract historical data that has accumulated over a long period of time. For such
databases, redundant or "denormalized" data may facilitate business intelligenceapplications.
Specifically, dimensional tables in a star schema often contain denormalized data. The denormalized
or redundant data must be carefully controlled during extract, transform, load (ETL) processing, and
users should not be permitted to see the data until it is in a consistent state. The normalized
alternative to the star schema is the snowflake schema. In many cases, the need for denormalization
has waned as computers and RDBMS software have become more powerful, but since data volumes
have generally increased along with hardware and software performance, OLAP databases often still
use denormalized schemas.
Denormalization is also used to improve performance on smaller computers as in computerized
cash-registers and mobile devices, since these may use the data for look-up only (e.g. price lookups).
Denormalization may also be used when no RDBMS exists for a platform (such as Palm), or no
changes are to be made to the data and a swift response is crucial.
Non-first normal form (NF or N1NF)
In recognition that denormalization can be deliberate and useful, the non-first normal form is a
definition of database designs which do not conform to first normal form, by allowing "sets and sets
of sets to be attribute domains" (Schek 1982). The languages used to query and manipulate data in
the model must be extended accordingly to support such values.
One way of looking at this is to consider such structured values as being specialized types of values
(domains), with their own domain-specific languages. However, what is usually meant by non-1NF
models is the approach in which the relational model and the languages used to query it are
extended with a general mechanism for such structure; for instance, the nested relational
model supports the use of relations as domain values, by adding two additional operators
(nest and unnest) to the relational algebra that can create and flatten nested relations, respectively.
Consider the following table:
First Normal Form
Person
Favourite Colour
Bob
Blue
Bob
Red
Jane
Green
Jane
Yellow
Jane
Red
Assume a person has several favourite colours. Obviously, favourite colours consist of a set of
colours modeled by the given table. To transform a 1NF into an NF table a "nest" operator is
required which extends the relational algebra of the higher normal forms. Applying the "nest"
operator to the 1NF table yields the following NF table:
Non-First Normal Form
Person Favourite Colours
Favourite Colour
Bob
Blue
Red
Favourite Colour
Jane
green
yellow
red
To transform this NF table back into a 1NF an "unnest" operator is required which extends the
relational algebra of the higher normal forms. The unnest, in this case, would make "colours" into its
own table.
Atomicity states that database modifications must follow an all or nothing rule. Each
transaction is said to be atomic. If one part of the transaction fails, the entire transaction
fails. It is critical that the database management system maintain the atomic nature of
transactions in spite of any DBMS, operating system or hardware failure.
Consistency states that only valid data will be written to the database. If, for some reason, a
transaction is executed that violates the databases consistency rules, the entire transaction
will be rolled back and the database will be restored to a state consistent with those rules.
On the other hand, if a transaction successfully executes, it will take the database from one
state that is consistent with the rules to another state that is also consistent with the rules.
Isolation requires that multiple transactions occurring at the same time not impact each
others execution. For example, if Joe issues a transaction against a database at the same
time that Mary issues a different transaction, both transactions should operate on the
database in an isolated manner. The database should either perform Joes entire transaction
before executing Marys or vice-versa. This prevents Joes transaction from reading
intermediate data produced as a side effect of part of Marys transaction that will not
eventually be committed to the database. Note that the isolation property does not ensure
which transaction will execute first, merely that they will not interfere with each other.
Durability ensures that any transaction committed to the database will not be lost.
Durability is ensured through the use of database backups and transaction logs that
facilitate the restoration of committed transactions in spite of any subsequent software or
hardware failures.
Take a few minutes to review these characteristics and commit them to memory. If you spend any
significant portion of your career working with databases, youll see them again and again. They
provide the basic building blocks of any database transaction model.
1.10.
Database design
Database design is the process of producing a detailed data model of a database. This logical
data model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a Data Definition Language, which can then be used
to create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an
overall database system. Principally, and most correctly, it can be thought of as the logical
design of the base data structures used to store the data. In the relational model these are
the tables and views. In an object database the entities and relationships map directly to object
classes and named relationships. However, the term database design could also be used to
apply to the overall process of designing, not just the base data structures, but also the forms
and queries used as part of the overall database application within the database management
system (DBMS).
The process of doing database design generally consists of a number of steps which will be
carried out by the database designer. Usually, the designer must:
Superimpose a logical structure upon the data on the basis of these relationships.
2.
Oracle Basics
2.1.Oracle History
Oracle has a 3 decade history, outlasting many of its predecessors. This brief summary traces the
evolution of Oracle from its initial inception to its current status as the world moist flexible and
robust database management system.
Founded in August 1977 by Larry Ellison, Bob Miner, Ed Oates and Bruce Scott, Oracle was initially
named after "Project Oracle" a project for one of their clients, the C.I.A, and the company that
developed Oracle was dubbed "Systems Development Labs", or SDL. Although they may not have
realized it at the time, these four men would change the history of database management forever.
In 1978 SDL was renamed Relational Software Inc (RSI) to market their new database.
1979 - Oracle release 2
The first commercial RDBMS was built using PDP-11 assembler language. Although they created a
commercial version of RDBMS in 1977, it wasn't available for sale until 1979 with the launch of
Oracle version 2. The company decided against starting with version 1 because they were afraid that
the term "version 1" might be viewed negatively in the marketplace. USA Air Force and then CIA
were the first customers to use Oracle 2.
In 1982 there was another change of the companys name, from RSI to Oracle Systems Corporation
so as to match its popular database name. The current company name comes from a CIA project
that Larry Ellison had previously worked on code named Oracle.
1983 - Oracle release 3
The Oracle version 3 was developed in 1983. This version was assembled using C programming
language and could run in mainframes, minicomputers, and PCs or any hardware with a C
compiler. It supported the execution of SQL statements and transactions. This version also included
new options of pre-join data to increase Oracle optimization.
1984 - Oracle release 4
Despite the advances introduced in version 3, demand was so great that Oracle was compelled to
improve the software even further with the release of version 4 in 1984. Oracle version 4 included
support for reading consistency, which made it much faster than any previous version. Oracle
version 4 also brought us the introduction of the export/import utilities and the report writer, which
allows one the ability to create a report based on a query.
1985 - Oracle release 5
With the introduction of version 5 in 1985, Oracle addressed the increasing use of the internet in
business computing. This version was equipped with the capability to connect clients software
through a network to a database server. The Clustering Technology was introduced in this version
as well and Oracle became the pioneer using this new concept which would later be known as
Oracle Real Application Cluster in version 9i. Oracle version 5 added some new security features
such as auditing, which would help determine who and when someone accessed the database.
Oracle version 5.1 was launched in 1986 and allowed for supporting distributed queries. Later that
same year Oracle released SQL*Plus, a tool that offers ad hoc data access and report writing. 1986
also brought the release of SQL*Forms, an application generator and runtime system with facilities
for simple application deployment.
1988 - Oracle release 6
The PL/SQL language came with Oracle version 6 in 1988. This version provided a host of new
features including the support of OLTP high-speed systems, hot backup capability and row level
locking which locks only the row or rows being used during a writing operation, rather than locking
an entire table. Prior to the hot backup feature, database administrators were required to
shutdown the database to back it up. Once the hot backup feature was introduced, DBAs could do
a backup while the database was still online.
Oracle Parallel Server was introduced in Oracle version 6.2 and was used with DEC VAX Cluster. This
new feature provided high availability because more than one node (server) could access the data in
database. With the increased availability this feature also accelerated the performance of the
system that was sharing users connections between nodes.
1992 - Oracle release 7
1992 was a memorable year for Oracle. The company announced Oracle version 7, which was the
culmination of four years of hard work and two years of customer testing before release to
market. This version of Oracle provided a vast array of new features and capabilities in areas such
as security, administration, development, and performance. Oracle 7 also addressed security
concerns by providing full control of who, when, and what users were doing in the database. Version
7 also allowed us to monitor every command, the use of privileges and the users access to a
particular item. With Oracle 7 users could use stored procedures and had triggers to enforce
business-rules. Roles were created at this version to make the security maintenance easier for users
and privileges. The two-phase commit was added to support distributed transactions.
Oracle7 Release 7.1 introduced some good new capabilities for database administrators, such as
parallel recovery and read-only tablespaces. For the application developments, Oracle inserted the
dynamic SQL, user-defined SQL functions and multiple same-type triggers. The first 64-bit DBMS was
introduced within this version as well as the VLM (Very Large Memory) option. The feature Oracle
Parallel Query could make some complex queries run 5 to 20 times faster.
In 1996 Oracle 7.3 was shipped, offering customers the ability to manage all kinds of data types;
including video, color images, sounds and spatial data. 1996 also brought the release of Oracle's
first biometric authentication for a commercially available database. This technology could analyze
human characteristics, both physical and behavioral, for purposes of authentication.
1997 - Oracle release 8
The Oracle 8 Database was launched in 1997 and was designed to work with Oracle's network
computer (NC). This version supported Java, HTML and OLTP.
1998 - Oracle release 8i
Just one year later Oracle released Oracle 8i which was the first database to support Web
technologies such as Java and HTTP. In 2000 Oracle 8i Parallel Server was working with Linux which
eliminated costly downtime.
2001 - Oracle release 9i
Oracle Real Application Cluster came with Oracle 9i Database in 2001. This featureprovides software
for clustering and high availability in Oracle database environments. Supporting native XML was also
a new feature of Oracle 9i and this was the first relational database to have these characteristics.
Version 9i release 2 enabled Oracle to integrate relational and multidimensional database.
Despite the fact that hard disks were becoming cheaper, data was increasing very quickly in
databases and Oracle 9i came with a special technology named table compression that reduced the
size of tables by 3 to 10 times and increased the performance when accessing those tables.
2003 - Oracle release 10g
Although Oracle 9i had only been in the market for two years, Oracle launched version 10g in
2003. The release of 10g brought us the introduction to Grid Computing technology. Data centers
could now share hardware resources, thus lowering the cost of computing infrastructure. 10g was
also the first Oracle version to support 64-bit on Linux. With Oracle Database 10g and Real
Application Cluster it was now possible to move from very expensive SMP boxes and mainframes to
an infrastructure that relies on low costs such as UNIX or Windows servers, which have high
availability, scalability and performance.
Oracle has long strived to make their software products available through the internet; but this
effort was only enhanced with the creation of the 10g Express Edition. With the introduction of the
10g Express Edition in 2005, Oracle gave small business and startup corporations a viable option to
integrate Oracle into the workplace at no cost.
2007 - Oracle release 11g
The latest version of Oracle Database is 11g which was released on July 11th2007. This version
introduced more features than any other in Oracle history. This version includes:
Oracle Database Replay, a tool that captures SQL statements and lets you replay them all in
another database to test the changes before you actually apply then on a production
database;
Transaction Management using Log Miner and Flashback Data Archive to get DML
statements from redo log files;
Online Patching;
Oracle is known for growth and change, which is why it is important to continually study its history
and previous lessons learned while embracing new features and functionality. Throughout its history
Oracle has acquired Database and Software Applications companies in order to provide more
complete solutions to its customers and increase the credibility of its products. Today Oracle has
more than 320,000 customers and is present in 145 countries making it one of the elite companies
in its field.
2.2.Competitors
Oracle's main competitors in the database business are:
Microsoft SQL Server
IBM with DB2 and Informix
Sybase with their Sybase System
CA with Ingres
Software AG with ADABAS and MaxDB
Open source databases (free, but normally way behind their commercial equivalents):
MySQL
PostgreSQL
EnterpriseDB
Oracle's main competitors in the middleware/ application servers business are:
IBM WebSphere
BEA WebLogic (until January 2008 when they bought the company)
Oracle's main competitors in the applications business are:
SAP R/3
Bulk Binds - Improve performance by reducing the overhead associated with context switches
between the PL/SQL and SQL engines.
Collections - Use collections in PL/SQL to perform array processing.
COM Automation In Oracle8i - Invoke methods in COM objects from PL/SQL using the COM
automation cartridge.
Complex Recordsets - Build complex recordsets using temporary or PL/SQL tables within stored
procedures.
Data Encryption - Dbms_Obfuscation_Toolkit - Encrypt and decrypt data using the
Dbms_Obfuscation_Toolkit package.
DBMS_APPLICATION_INFO : For Code Instrumentation - Track session and long operation
activity more accurately using these built-in procedures and views.
The DBMS_System Package - The DBMS_System package contains a number of routines that can
be useful on occasion.
Explain Plan Usage - A quick guide to using AUTOTRACE and EXPLAIN PLAN.
Export BLOB - A simple method for exporting the contents of a BLOB datatype to the filesystem.
Export CLOB - A simple method for exporting the contents of a CLOB datatype to the filesystem.
File Handling From PL/SQL - Perform basic file manipulation from PL/SQL using this simple API.
Import BLOB - A simple method for importing the contents of a file into a BLOB datatype.
Import CLOB - A simple method for importing the contents of a file into a CLOB datatype.
InterMedia - Import-Export Of Images - Prior to Oracle 8.1.7 the interMedia support for import
and export of data was a little flunky. Even now the API forces you to use directory object to
access the file system. The code supplied here will free you from the constraints of interMedia.
JServer - Java In The Database - The first steps along the route to placing java code in an Oracle
8i database.
Native Dynamic SQL - The introduction of Native Dynamic SQL has made Dynamic SQL quicker
and more readable.
Object Types - Create your first Object Types and store them in the database.
Parse XML Documents - Explode unstructured XML documents into relational tables using the
XDK for PL/SQL.
Shell Commands From PL/SQL - Use this simple method to perform shell commands from within
PL/SQL.
TKPROF And Oracle Trace - Learn how to produce and interpret trace files for specific queries.
Using Ref Cursors To Return Recordsets - Return recordsets from Oracle stored procedures.
Auditing - Basic setup instructions to allow the auditing of user actions.
Constraint Checking Updates - Explains the modifications to constraint checking including
deferrable consrtaints and constraint states.
Cost Based Optimizer (CBO) And Database Statistics - Lists the available mechanisms for
gathering database statistics that are used by the cost based optimizer.
Detect And Correct Corruption - Learn the different methods of detecting and correcting table
block corruption.
Dropping Columns - Hide unused columns or completely remove them.
DIY Dynamic Views - Query external data as if it were a relational table.
Function Based Indexes - Allow queries to use indexes even when you are performing a function
on the indexed column.
Index Organized Tables - Save space and improve the performance of tables which are
predominantly access by their primary keys.
Locally Managed Tablespaces - Reduce contention on the system tables by delegating extent
management to individual tablespaces.
LogMiner - Analyze archived redo logs to identify specific specific statements and undo them.
Partitioned Tables And Indexes - Reduce tables and indexes to a more managable size and
simultaneously improve performance.
Recovery Manager (RMAN) - Explanation of RMANs basic backup, recovery and reporting
functionality.
Refreshing Stale Statistics - Keep your optimizer statistics up to date without increasing the load
on the server.
Replication (Simple) - Using materialized views (snapshots) to replicate data on a remote
database.
Replication (Advanced) - Using Oracle Advanced Replication for two-way data replication.
Resource Manager - Prevent batch processes interfering with your OLTP transactions by using
this simple PL/SQL API to assign a priority to each type of session.
Statspack - Analyze the performance of your system using the replacement for the
UTLBSTAT/UTLESTAT scripts.
Standby Database - Keep an up-to-date copy of the production database ready for failover in the
event of a disaster.
Temporary Tables - Most applications need temporary tables to store information during
complex data processing. See how Oracle can manage your temporary tables and keep your
data secure.
Virtual Private Databases (VPD) - Lists the basic steps required to setup a Virtual Private
Database, allowing multiple users interact with a single schema whilst shielding non-relevant
data.
9i Highlights
Oracle9i: New Features For Administrators Exam Tips - Some tips on what to expect when
upgrading your OCP to Oracle9i.
ANSI ISO SQL Support In Oracle9i - Check out the new SQL enhancements to bring Oracle in line
with the ANSI/ISO SQL: 1999 standards.
Automatic Segment Free Space Management - Reduce segment header contention and wasted
space within blocks by switching from using FreeLists to Automatic Segment Free Space
Management.
Automatic Undo Management - Replace you existing rollback segments with self-tuning undo
segments.
Bitmap Join Indexes - Increase the performance and reduce the size of your data warehouse.
Character Semantics And Globalization - Prevent storage problems associated with mutlibyte
character sets by using character semantics when defining table columns.
Data Guard - Oracle9i Data Guard is the new name for Oracle8i Standby Database incorporating
a large number of new features. This article discusses those relevant to the Oracle9i Database:
New Features For Administrators OCP exam.
Export And Import Enhancements In Oracle9i - See what new functionality has been
incorporated into the Export and Import utilities in Oracle9i.
Flashback Query - Get a consistent view of the data at a previous point in time.
High Availability Enhancements in Oracle9i - Reduce downtime for users by using the new high
availability features of Oracle9i.
Index Organized Table (IOT) Enhancements in Oracle9i - Better support for secondary indexes
and improved online maintenance make IOTs nearly as flexible as heap tables.
Index Skip Scanning - See how Oracle9i uses composite indexes even when the leading edge is
not referenced.
LOB Enhancements In Oracle9i - Kickstart the conversion from LONG and RAW columns to CLOB
and BLOB columns.
LogMiner Enhancements In Oracle9i - A summary of the new features introduced in Oracle9i.
Memory Management In Oracle9i - See how easy memory management has become in Oracle9i.
Metadata API - Extract DDL or XML definitions of all database objects using this simple API.
Multiple Block Sizes - Improve efficiency by having multiple block sizes that relate more closely
to the operations that are being performed.
Oracle Managed Files - Let Oracle manage operating system level file placement, naming and
cleanup.
Partitioning Enhancements In Oracle9i - Check out the additions and enhancements to
partitioning in Oracle9i.
A brief overview of the DBMS_SCHEDULER support in SQL Developer 3.1. Performance
Enhancements In Oracle9i - Read about some of the new performance features in Oracle9i.
Persistent Initialization Parameters - Make database parameter changes persist between
shutdowns.
Real Application Clusters - A brief introduction to the Oracle9i replacement for Oracle Parallel
Server.
Recovery Enhancements In Oracle9i - Reduce unplanned downtime by using the new crash,
instance and media recovery features of Oracle9i.
Recovery Manager (RMAN) Enhancements In Oracle9i - Use the latest RMAN features which
make backup and recovery quicker and more reliable.
Resource Manager Enhancements In Oracle9i - Manage system resources more precisely using
the Resource Manager enhancements in Oracle9i.
Resumable Space Allocation - Make long running operations suspend rather than abort if they
encounter space errors.
Scalable Session Management - Learn about the new session management features in Oracle9i.
Security Enhancements In Oracle9i - A run through the new security features available in
Oracle9i, focusing on those relevant for the Oracle9i Database: New Features For Administrators
OCP exam.
SQL New Features In Oracle9i - Check out the new SQL features with emphasis on those relevant
for the Oracle9i Database: New Features For Administrators OCP exam.
Workspace Management In Oracle9i - Allow multiple transactionally consistent environments to
exist within one database.
10g highlights
Automatic Database Diagnostic Monitor (ADDM) in Oracle Database 10g - This article describes
several methods for producing reports from the Automatic Database Diagnostic Monitor
(ADDM) in Oracle 10g.
Automatic SQL Tuning in Oracle Database 10g - This article the discusses the new features which
automate the tuning of SQL statements in Oracle 10g.
Automatic Storage Management (ASM) in Oracle Database 10g - Automatic Storage
Management (ASM) is a new feature introduced in Oracle 10g to simplify the storage and
administration of Oracle files.
Automatic Workload Repository (AWR) in Oracle Database 10g - The automatic workload
repository (AWR) is the latest evolution of statspack which provides the central information
store for all Oracle 10g self-tuning functionality.
Database Security Enhancements in Oracle Database 10g - Oracle 10g contains many
improvements to Virtual Private Database (VPD), Fine Grained Auditing (FGA) and data
encryption.
DBMS_FILE_TRANSFER Package in Oracle Database 10g - Use this new API to make binary copies
of files on the local server or to transfer files between the local server and remote servers.
Flashback New Features and Enhancements in Oracle Database 10g - Use the new and enhanced
features of flashback technology to view old data, track data changes and recover from
accidental data loss without reverting to LogMiner or point in time recoveries.
Improved VLDB Support in Oracle Database 10g - Take advantage of the improvements in Very
Large Database (VLDB) support in Oracle 10g.
Installation Enhancements in Oracle Database 10g - This article provides a brief description of
the installation enhancements which are relevant to the OCP upgrade exam for Oracle 10g.
MERGE Statement Enhancements in Oracle Database 10g - Learn about the enhancements to
the merge statement in Oracle Database 10g.
Oracle Data Pump in Oracle Database 10g - Test drive the Oracle 10g replacement for the EXP
and IMP utilities.
Performance Tuning Enhancements in Oracle Database 10g - Oracle 10g includes many
performance tuning enhancements which take some of the mystery out of being a DBA.
PL/SQL Enhancements in Oracle Database 10g - Get to grips with the Oracle 10g enhancements
to PL/SQL using simple cut & paste examples.
Resource Manager Enhancements in Oracle Database 10g - In Oracle 10g resource manager is
more flexible and even easier to configure than before. Check out the enhancements here.
RMAN Enhancements in Oracle Database 10g - Check out the large number of enhancements in
the Oracle 10g version of RMAN. If you are not currently using this tool you're running out of
excusses.
Services in Oracle Database 10g - Run applications on a subset of Real Application Cluser (RAC)
nodes using services.
Server Configuration in Oracle Database 10g - Oracle 10g includes some changes relating to
basic server configuration which are relevant to the OCP upgrade exam.
Scheduler in Oracle Database 10g - Oracle Database 10g includes a flexible scheduler to replace
the DBMS_JOB package.
Space, Object, and Transaction Management in Oracle Database 10g - A description of the new
features relating to space, object and transaction management in Oracle 10g.
SQL Access Advisor in Oracle Database 10g - Use this advisor to get suggestions for indexes and
materialized views that might help system performance.
SQL*Plus Enhancements in Oracle Database 10g - Check out enhancements to SQL*Plus in
Oracle Database 10g.
Tablespace Management Enhancements in Oracle Database 10g - Oracle 10g includes several
small but neat enhancements related to tablespace management.
Upgrading to Oracle Database 10g - This article provides a brief overview of the areas involved
in upgrading existing databases to Oracle 10g.
Adaptive Cursor Sharing in Oracle Database 11g Release 1 - Overcome the problems associated
with using bind variables against indexed columns containing skewed data.
Automated Database Maintenance Task Management in Oracle Database 11g Release 1 Reduce the impact of automated maintenance tasks on your system by controlling how and
when they run.
Automatic Memory Management in Oracle Database 11g Release 1 - Oracle 11g takes the next
step down the road to making manual memory management a thing of the past.
Automatic SQL Tuning in Oracle Database 11g Release 1 - Take advantage of the Automatic SQL
Tuning features of Oracle 11g Release 1.
Automatic Storage Manager (ASM) Enhancements in Oracle Database 11g Release 1 - This article
provides an overview of the main Automatic Storage Manager (ASM) enhancements in Oracle
Database 11g Release 1.
AWR Baseline Enhancements in Oracle Database 11g Release 1 - Oracle 11g has extended the
AWR baseline functionality and made alert threshold creation more flexible.
Case Sensitive Passwords in Oracle Database 11g Release 1 - Understand the implications and
administration of this new security feature in Oracle 11g.
Cross-Session PL/SQL Function Result Cache in Oracle Database 11g Release 1 - Improve the
performance of PL/SQL functions across the whole database instance by caching return values.
Database Replay in Oracle Database 11g Release 1 - Capture workloads on a production system
and replay them exactly as they happened on a test system.
Database Resident Connection Pool (DRCP) in Oracle Database 11g Release 1 - Use the database
resident connection pool to reduce the resource requirements of applications that do not
support connection pooling.
Data Recovery Advisor in Oracle Database 11g Release 1 - Automatically identify, diagnose and
repair corruption or loss of persistent data on disk using this new feature.
DDL With the WAIT Option (DDL_LOCK_TIMEOUT) - Avoid unnecessary "ORA-00054: resource
busy" errors in 11g.
Fine-Grained Access to Network Services in Oracle Database 11g Release 1 - Take control of the
external
services
accessed
by
the UTL_TCP, UTL_INADDR, UTL_HTTP, UTL_SMTP,
and UTL_MAIL packages.
Finer Grained Dependency Management in Oracle Database 11g Release 1 - See how finer
grained dependency management in 11g reduces the extent of invalidations associated with
schema changes.
Flashback and LogMiner Enhancements in Oracle Database 11g Release 1 - See how Oracle 11g
Release 1 makes tracking data changes and recovering from logical errors easier because of
enhancements to Flashback and LogMiner.
Invisible Indexes in Oracle Database 11g Release 1 - Take control of the indexes available to the
optimizer by using invisible indexes in 11g.
Miscellaneous New Features in Oracle Database 11g Release 1 - A collection of new features and
enhancements listed in the miscellaneous section of "Oracle Database 11G: New Features for
Administrators" OCP syllabus.
Online Table Redefinition Enhancements in Oracle Database 11g Release 1 - Take advantage of
the reduced invalidations associated with online table redefintions in 11g.
Partitioning Enhancements in Oracle Database 11g Release 1 - An introduction to the
partitioning enhancements in Oracle 11g Release 1.
Query Result Cache in Oracle Database 11g Release 1 - Improve the performance of SQL across
the whole database instance by caching query results.
Read-Only Tables in Oracle Database 11g Release 1 - Protect data in static tables using the readonly table feature in Oracle 11g Release 1.
Resource Manager Enhancements in Oracle Database 11g Release 1 - An overview of the
resource manager enhancements in Oracle Database 11g Release 1.
RMAN Enhancements in Oracle Database 11g Release 1 - An overview of all the RMAN
enhancements in Oracle Database 11g Release 1.
Scheduler Enhancements in Oracle Database 11g Release 1 - Oracle 11g adds more functionality
to the Oracle scheduler.
SecureFiles in Oracle Database 11g Release 1 - Compress, deduplicate and encrypt LOBs using
the new LOB functionality in Oracle 11g.
SQL Access Advisor in Oracle Database 11g Release 1 - Use this advisor to get suggestions for
indexes, materialized views and partitioning schemes to improve system performance.
SQL Performance Analyzer in Oracle Database 11g Release 1 - Compare the performance of the
statements in an SQL tuning set before and after database changes.
SQL Plan Management in Oracle Database 11g Release 1 - Maintain consistent SQL performance
regardless of changes in optimizer version, optimizer statistics, schema changes, system settings
and SQL profile creation.
Statistics Collection Enhancements in Oracle Database 11g Release 1 - Provide the optimizer
with additional selectivity information and avoid new statistics adversely affecting performance.
Table Compression Enhancements in Oracle Database 11g Release 1 - Save space and improve
performance of OLTP systems using the enhanced table compression in 11g.
Tablespace Encryption in Oracle Database 11g Release 1 - Simplify the administration of
transparent data encryption (TDE) using tablespace encryption.
Temporary Tablespace Enhancements in Oracle Database 11g Release 1 - Take advantage of
better visibility and management of temporary tablespaces usage in 11g.
Upgrading to Oracle Database 11g - This article provides a brief overview of the areas involved
in upgrading existing databases to Oracle 11g.
2.4.
Database Objects
Oracle Database recognizes objects that are associated with a particular schema and objects that are
not associated with a particular schema, as described in the sections that follow.
Schema Objects
A schema is a collection of logical structures of data, or schema objects. A schema is owned by a
database user and has the same name as that user. Each user owns a single schema. Schema objects
can be created and manipulated with SQL and include the following types of objects:
List of few schema objects
Clusters
Constraints
Database links
Database triggers
Dimensions
External procedure libraries
Index-organized tables
Indexes
Indextypes
Java classes, Java resources, Java sources
Materialized views
Materialized view logs
Object tables
Object types
Object views
Operators
Packages
Sequences
Stored functions, stored procedures
Synonyms
Tables
Views
Non-schema Objects
Other types of objects are also stored in the database and can be created and manipulated with SQL
but are not contained in a schema:
Contexts
Directories
Parameter files (PFILEs) and server parameter files (SPFILEs)
Profiles
Roles
Rollback segments
Tablespaces
Users
o
o Tables
Oracle stores information in the form of tables. For eg you can have a table named as climate in
which you can store information about the climate of a place in the form of columns which could
be the temperature, name of the place, date, humidity, etc.
In the terms of a relational database, one can call a table as an entity and the columns as it
attributes.
o Indexes
Indexing is a concept of listing of keywords accompanied by the location of information of the
subject. Indexes are used to speed up the processing, especially searching.
o Views
A view is a way of hiding the logic that created the joined table just displayed. For example:
create view AB
select A.x, B.y from A, B where A.x = B.y;
You can query it as select x, y from AB.
Note: AB is the view name, A, B are the Table names with x and y as their column names
respectively.
For views, you dont need to specify the tables as the logic is hidden inside the views.
o Synonyms
A synonym is a name assigned to a table or view that may be used refer to it thereafter. If you
have an access to another users table, you may create a synonym for it and refer to it by the
synonym alone, without entering the users name as a qualifier. Using synonyms is a good way to
implement location transparency.
o Sequences
Tables usually have a primary key which uniquely identifies a row in a table. A sequence is a
unique number generator which can be assigned to the primary keys of the tables.
Eg create sequence xyz
increment by 1
start with 1;
o Partitions
Partitioning provides tremendous advantages to applications by improving manageability,
performance and availability.
Partitioning allows a table, index or index-organized table to be subdivided into smaller pieces.
Each piece of database object is called a partition.
Techniques for partitioning tables:
Range Partitioning
List Partitioning
Hash Partitioning
Composite Range-Hash Partitioning
Composite Range-List Partitioning
o Clusters
A cluster is a schema object that contains data from one or more tables, all of which have one or
more columns in common.
All the rows from all the tables that share the same cluster key are stored.
After you create a cluster, you add tables to it. A cluster can contain a maximum of 32 tables.
Package
Packages are PL/SQL constructs that allow related objects to be stored together. A package has
two separate parts. Each of them is stored separately in the data dictionary.
A package can include procedures, functions, cursors, types, and variables.
Eg create or replace package XYZ as
procedure p1 (p_id IN tablename.id % type, , ..)
end XYZ;
o Table spaces
A table space is an area on disk which comprises of one or more disk files. A tablespace can
contain many tables, clusters or indexes.
One or more tablespaces together make a database.
Each table has a single area of diskspace called a segment set aside for it in the table space.
Each segment has an initial area on disk space set aside for it in the table space called the initial
extent.
Once it has been used up, another extent is set aside for it.
o Constraint
Constraints help understand how the tables and columns are related to each other.
The constraint information is accessible under the USER_constraint view.
The constraints include the following columns
Owner - - - of constraint
Constraint_name
Constraint_type
Table_name
Search_condition
R_Owner - - owner of the foreign key referenced table.
R_constraint_name
Delete_rule
Status
Rules for naming schema objects and schema object location qualifiers
A quoted identifier begins and ends with double quotation marks ("). If you name a schema
object using a quoted identifier, then you must use the double quotation marks whenever you
refer to that object.
You can use either quoted or nonquoted identifiers to name any database object, with one exception:
database links must be named with nonquoted identifiers. In addition, Oracle strongly recommends
that you not use quotation marks to make usernames and passwords case sensitive.
The following list of rules applies to both quoted and nonquoted identifiers unless otherwise
indicated:
1. Names must be from 1 to 30 bytes long with these exceptions:
Non-quoted identifiers cannot be Oracle Database reserved words. Quoted identifiers can be
reserved words, although this is not recommended.
Depending on the Oracle product you plan to use to access a database object, names might be
further restricted by other product-specific reserved words.
Note:
The reserved word ROWID is an exception to this rule. You cannot use the
uppercase word ROWID as a name, even in double quotation marks. However, you
can use the word with one or more lower case letters (for example, "Rowid" or
"rowid").
The Oracle SQL language contains other words that have special meanings. These words include
datatypes, function names, the dummy system table DUAL, and keywords (the uppercase words in SQL
statements, such as DIMENSION, SEGMENT, ALLOCATE, DISABLE, and so forth). These words are not
reserved. However, Oracle uses them internally in specific ways. Therefore, if you use these words as
names for objects and object parts, then your SQL statements may be more difficult to read and may
lead to unpredictable results.
In particular, do not use words beginning with SYS_ as schema object names, and do not use the
names of SQL built-in functions for the names of schema objects or user-defined functions.
You should use ASCII characters in database names, global database names, and database link
names, because ASCII characters provide optimal compatibility across different platforms and operating
systems.
Non-quoted identifiers must begin with an alphabetic character from your database character
set. Quoted identifiers can begin with any character.
Non-quoted identifiers can contain only alphanumeric characters from your database character
set and the underscore (_), dollar sign ($), and pound sign (#). Database links can also contain periods (.)
and "at" signs (@). Oracle strongly discourages you from using $ and # in nonquoted identifiers.
Quoted identifiers can contain any characters and punctuations marks as well as spaces.
However, neither quoted nor non-quoted identifiers can contain double quotation marks.
Within a namespace, no two objects can have the same name.
The following schema objects share one namespace:
Tables
Views
Sequences
Private synonyms
Stand-alone procedures
Stand-alone stored functions
Packages
Materialized views
User-defined types
Indexes
Constraints
Clusters
Database triggers
Private database links
Dimensions
Because tables and views are in the same namespace, a table and a view in the same schema
cannot have the same name. However, tables and indexes are in different namespaces.
Therefore, a table and an index in the same schema can have the same name.
Each schema in the database has its own namespaces for the objects it contains. This means, for
example, that two tables in different schemas are in different namespaces and can have the
same name.
Each of the following non-schema objects also has its own namespace:
User roles
Public synonyms
Tablespaces
Profiles
By enclosing names in double quotation marks, you can give the following names to different
objects in the same namespace:
employees
"employees"
"Employees"
"EMPLOYEES"
Note that Oracle interprets the following names the same, so they cannot be used for different
objects in the same namespace:
employees
EMPLOYEES
"EMPLOYEES"
Columns in the same table or view cannot have the same name. However, columns in different
tables or views can have the same name.
Procedures or functions contained in the same package can have the same name, if their
arguments are not of the same number and datatypes. Creating multiple procedures or functions with
the same name in the same package with different arguments is called overloading the procedure or
function.
Schema Object Naming Examples
The following examples are valid schema object names:
last_name
horse
hr.hire_date
"EVEN THIS & THAT!"
a_very_long_and_valid_name
The following example is not valid, because it exceeds 30 characters:
a_very_very_long_and_valid_name
Although column aliases, table aliases, usernames, and passwords are not objects or parts of
objects, they must also follow these naming rules unless otherwise specified in the rules
themselves.
Schema Object Naming Guidelines
Here are several helpful guidelines for naming objects and their parts:
Use full, descriptive, pronounceable names (or well-known abbreviations).
Use consistent naming rules.
Use the same name to describe the same entity or attribute across tables.
When naming objects, balance the objective of keeping names short and easy to use with the
objective of making names as descriptive as possible. When in doubt, choose the more
descriptive name, because the objects in the database may be used by many people over a
period of time. Your counterpart ten years from now may have difficulty understanding a table
column with a name like pmdd instead of payment_due_date.
Using consistent naming rules helps users understand the part that each table plays in your
application. One such rule might be to begin the names of all tables belonging to
the FINANCE application with fin_.
Use the same names to describe the same things across tables. For example, the department
number
columns
of
the
sample employees and departments tables
are
both
named department_id.
2.5.
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 Database 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.
objects that are used systemwide. Users should avoid naming their own schema objects with the same
names as those used for public synonyms.
Scope
USER
ALL
DBA
Views with the prefix USER usually exclude the column OWNER. This column is implied in
the USER views to be the user issuing the query.
Some DBA views have additional columns containing information useful to the administrator.
Refer to the user's own private environment in the database, including information about
schema objects created by the user, grants made by the user, and so on
Display only rows pertinent to the user
Have columns identical to the other views, except that the column OWNER is implied
Return a subset of the information in the ALL views
Can have abbreviated PUBLIC synonyms for convenience
For example, the following query returns all the objects contained in your schema:
SELECT object_name, object_type FROM USER_OBJECTS;
The table named DUAL is a small table in the data dictionary that Oracle Database and userwritten programs can reference to guarantee a known result. This table has one column
called DUMMY and one row containing the value X.
The USER, ALL, and DBA views show information about schema objects that are accessible to
you, at different levels of privilege.
The V$ views show performance-related information.
The _PRIVS views show privilege information for different combinations of users, roles, and
objects.
APPENDIX 1.docx
2.5.10.
System Packages
Oracle List of Supplied packages is in Appendix 2 below:
APPENDIX 2.docx
2.6.
Type definitions
Table definitions
Table data
Table indexes
Integrity constraints, views, procedures, and triggers
Bitmap, function-based, and domain indexes
When you import the tables the import tool will perform the actions in the following order, new tables
are created, data is imported and indexes are built, triggers are imported, integrity constraints are
enabled on the new tables, and any bitmap, function-based, and/or domain indexes are built. This
sequence prevents data from being rejected due to the order in which tables are imported. This
sequence also prevents redundant triggers from firing twice on the same data
When you just type exp or imp at o/s prompt it will run in interactive mode i.e. these tools will
prompt you for all the necessary input. If you supply command line arguments when calling exp or
imp then it will run in command line mode
Description (Default)
USERID
username/password
BUFFER
FILE
COMPRESS
GRANTS
INDEXES
DIRECT
LOG
ROWS
CONSISTENT
cross-table consistency(N)
FULL
OWNER
TABLES
RECORDLENGTH
length of IO record
INCTYPE
RECORD
TRIGGERS
STATISTICS
PARFILE
parameter filename
CONSTRAINTS
OBJECT_CONSISTENT
FEEDBACK
FILESIZE
FLASHBACK_SCN
FLASHBACK_TIME
QUERY
RESUMABLE
RESUMABLE_NAME
RESUMABLE_TIMEOUT
TTS_FULL_CHECK
TABLESPACES
TRANSPORT_TABLESPACE
TEMPLATE
Description (Default)
USERID
username/password
BUFFER
FILE
SHOW
IGNORE
GRANTS
INDEXES
ROWS
LOG
FULL
FROMUSER
TOUSER
list of usernames
TABLES
Keyword
Description (Default)
RECORDLENGTH
length of IO record
INCTYPE
COMMIT
PARFILE
parameter filename
CONSTRAINTS
DESTROY
INDEXFILE
SKIP_UNUSABLE_INDEXES
FEEDBACK
TOID_NOVALIDATE
FILESIZE
STATISTICS
RESUMABLE
RESUMABLE_NAME
RESUMABLE_TIMEOUT
COMPILE
STREAMS_CONFIGURATION
STREAMS_INSTANITATION
"DEPT"
4 rows imported
. . importing table
"EMP"
14 rows imported
Example, Importing Tables of One User account into another User account
For example, suppose Ali has exported tables into a dump file mytables.dmp. Now Scott wants to
import these tables. To achieve this Scott will give the following import command
$imp scott/tiger FILE=mytables.dmp FROMUSER=ali TOUSER=scott
Then import utility will give a warning that tables in the dump file were exported by user Ali and
not you and then proceed.
As a DBA user, issue the following SQL query to get the exact name of all tablespaces. You
will need this information later in the process.
SQL> SELECT tablespace_name FROM dba_tablespaces;
As a DBA user, perform a full export from the source database, for example:
> exp system/manager FULL=y FILE=myfullexp.dmp
o
o
o
Move the dump file to the target database server. If you use FTP, be sure to copy it in
binary format (by entering binary at the FTP prompt) to avoid file corruption.
Create a database on the target server.
Before importing the dump file, you must first create your tablespaces, using the
information obtained in Step 1. Otherwise, the import will create the corresponding
datafiles in the same file structure as at the source database, which may not be
compatible with the file structure on the target system.
As a DBA user, perform a full import with the IGNORE parameter enabled:
> imp system/manager FULL=y IGNORE=y FILE=myfullexp.dmp
Using IGNORE=y instructs Oracle to ignore any creation errors during the import and
permit the import to complete.
Database Exports/Imports
The FULL parameter indicates that a complete database export is required. The following is an example
of the full database export and import syntax.
expdp system/password@db10g full=Y directory=TEST_DIR dumpfile=DB10G.dmp
logfile=expdpDB10G.log
impdp system/password@db10g full=Y directory=TEST_DIR dumpfile=DB10G.dmp
logfile=impdpDB10G.log
The following code shows how they can be used as command line parameters.
expdp scott/tiger@db10g schemas=SCOTT include=TABLE:"IN ('EMP', 'DEPT')"
directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log
expdp scott/tiger@db10g schemas=SCOTT exclude=TABLE:"= 'BONUS'"
directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log
If the parameter is used from the command line, depending on your OS, the special characters in the
clause may need to be escaped, as follows. Because of this, it is easier to use a parameter file.
include=TABLE:\"IN (\'EMP\', \'DEPT\')\"
A single import/export can include multiple references to the parameters, so to export tables, views and
some packages we could use either of the following approaches.
INCLUDE=TABLE,VIEW,PACKAGE:"LIKE '%API'"
or
INCLUDE=TABLE
INCLUDE=VIEW
INCLUDE=PACKAGE:"LIKE '%API'"
The valid object type paths that can be included or excluded can be displayed using
the DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_OBJECTS, and TABLE_EXPORT_OBJECTS views.
Miscellaneous Information
Unlike the original exp and imp utilities all data pump ".dmp" and ".log" files are created on the Oracle
server, not the client machine.
All data pump actions are performed by multiple jobs (server processes not DBMS_JOB jobs). These jobs
are controlled by a master control process which uses Advanced Queuing. At runtime an advanced
queue table, named after the job name, is created and used by the master control process. The table is
dropped on completion of the data pump job. The job and the advanced queue can be named using
the JOB_NAME parameter. Cancelling the client process does not stop the associated data pump job.
Issuing "ctrl+c" on the client during a job stops the client output and presents a command prompt. Typing
"status" at this prompt allows you to monitor the current job.
Export> status
Job: SYS_EXPORT_FULL_01
Operation: EXPORT
Mode: FULL
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: D:\TEMP\DB10G.DMP
bytes written: 4,096
Worker 1 Status:
State: EXECUTING
Object Schema: SYSMAN
Object Name: MGMT_CONTAINER_CRED_ARRAY
Object Type: DATABASE_EXPORT/SCHEMA/TYPE/TYPE_SPEC
Completed Objects: 261
Total Objects: 261
Data pump performance can be improved by using the PARALLEL parameter. This should be used in
conjunction with the "%U" wildcard in the DUMPFILE parameter to allow multiple dumpfiles to be created
or read.
expdp scott/tiger@db10g schemas=SCOTT directory=TEST_DIR parallel=4
dumpfile=SCOTT_%U.dmp logfile=expdpSCOTT.log
The DBA_DATAPUMP_JOBS view can be used to monitor the current jobs.
system@db10g> select * from dba_datapump_jobs;
OWNER_NAME
-------------------------------------------JOB_MODE
ATTACHED_SESSIONS
-----------------------------------------SYSTEM
FULL
1
JOB_NAME
OPERATION
------------------------------ --------------STATE
DEGREE
EXPORT
1
Once the job has started the status can be checked using.
system@db10g> select * from dba_datapump_jobs;
External Tables
Oracle has incorporated support for data pump technology into external tables. The
ORACLE_DATAPUMP access driver can be used to unload data to data pump export files and
subsequently reload it. The unload of data occurs when the external table is created using the "AS"
clause.
The syntax to create the external table pointing to an existing file is similar, but without the "AS" clause.
DROP TABLE emp_xt;
CREATE TABLE emp_xt (
EMPNO
NUMBER(4),
ENAME
VARCHAR2(10),
JOB
VARCHAR2(9),
MGR
NUMBER(4),
HIREDATE DATE,
SAL
NUMBER(7,2),
COMM
NUMBER(7,2),
DEPTNO
NUMBER(2))
ORGANIZATION EXTERNAL (
TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY test_dir
LOCATION ('emp_xt.dmp')
);
SELECT * FROM emp_xt;
Help
The HELP=Y option displays the available parameters.
EXPDP
expdp help=y
Export: Release 10.1.0.2.0 - Production on Tuesday, 23 March, 2004 8:33
Copyright (c) 2003, Oracle.
The Data Pump export utility provides a mechanism for transferring data
objects
between Oracle databases. The utility is invoked with the following command:
Example: expdp scott/tiger DIRECTORY=dmpdir DUMPFILE=scott.dmp
You can control how Export runs by entering the 'expdp' command followed
by various parameters. To specify parameters, you use keywords:
Format: expdp KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
Example: expdp scott/tiger DUMPFILE=scott.dmp DIRECTORY=dmpdir
SCHEMAS=scott
or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
USERID must be the first parameter on the command line.
Keyword
Description (Default)
----------------------------------------------------------------------------ATTACH
Attach to existing job, e.g. ATTACH [=job name].
CONTENT
Specifies data to unload where the valid keywords are:
(ALL), DATA_ONLY, and METADATA_ONLY.
DIRECTORY
Directory object to be used for dumpfiles and logfiles.
DUMPFILE
List of destination dump files (expdat.dmp),
e.g. DUMPFILE=scott1.dmp, scott2.dmp,
dmpdir:scott3.dmp.
ESTIMATE
Calculate job estimates where the valid keywords are:
(BLOCKS) and STATISTICS.
ESTIMATE_ONLY
Calculate job estimates without performing the export.
EXCLUDE
Exclude specific object types, e.g. EXCLUDE=TABLE:EMP.
FILESIZE
Specify the size of each dumpfile in units of bytes.
FLASHBACK_SCN
SCN used to set session snapshot back to.
FLASHBACK_TIME
Time used to get the SCN closest to the specified time.
FULL
Export entire database (N).
HELP
Display Help messages (N).
INCLUDE
Include specific object types, e.g. INCLUDE=TABLE_DATA.
JOB_NAME
Name of export job to create.
LOGFILE
Log file name (export.log).
NETWORK_LINK
Name of remote database link to the source system.
NOLOGFILE
Do not write logfile (N).
PARALLEL
Change the number of active workers for current job.
PARFILE
Specify parameter file.
QUERY
SCHEMAS
STATUS
TABLES
only.
TABLESPACES
TRANSPORT_FULL_CHECK
TRANSPORT_TABLESPACES
unloaded.
VERSION
FILESIZE
commands.
Oracle 11g Release 1 (11.2) altered the format of the help output as well as adding the following
parameters.
CLUSTER
Utilize cluster resources and distribute workers across the Oracle RAC.
Valid keyword values are: [Y] and N.
SERVICE_NAME
Name of an active Service and associated resource group to constrain Oracle
RAC resources.
SOURCE_EDITION
Edition to be used for extracting metadata.
IMPDP
impdp help=y
Import: Release 10.1.0.2.0 - Production on Saturday, 11 September, 2004 17:22
Copyright (c) 2003, Oracle.
The Data Pump Import utility provides a mechanism for transferring data
objects
between Oracle databases. The utility is invoked with the following command:
Example: impdp scott/tiger DIRECTORY=dmpdir DUMPFILE=scott.dmp
You can control how Import runs by entering the 'impdp' command followed
by various parameters. To specify parameters, you use keywords:
Format: impdp KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
Example: impdp scott/tiger DIRECTORY=dmpdir DUMPFILE=scott.dmp
USERID must be the first parameter on the command line.
Keyword
Description (Default)
----------------------------------------------------------------------------ATTACH
Attach to existing job, e.g. ATTACH [=job name].
CONTENT
Specifies data to load where the valid keywords are:
(ALL), DATA_ONLY, and METADATA_ONLY.
DIRECTORY
Directory object to be used for dump, log, and sql
files.
DUMPFILE
List of dumpfiles to import from (expdat.dmp),
e.g. DUMPFILE=scott1.dmp, scott2.dmp,
dmpdir:scott3.dmp.
ESTIMATE
Calculate job estimates where the valid keywords are:
(BLOCKS) and STATISTICS.
EXCLUDE
Exclude specific object types, e.g. EXCLUDE=TABLE:EMP.
FLASHBACK_SCN
SCN used to set session snapshot back to.
FLASHBACK_TIME
Time used to get the SCN closest to the specified time.
FULL
Import everything from source (Y).
HELP
Display help messages (N).
INCLUDE
Include specific object types, e.g. INCLUDE=TABLE_DATA.
JOB_NAME
Name of import job to create.
LOGFILE
Log file name (import.log).
NETWORK_LINK
Name of remote database link to the source system.
NOLOGFILE
Do not write logfile.
PARALLEL
Change the number of active workers for current job.
PARFILE
Specify parameter file.
QUERY
Predicate clause used to import a subset of a table.
REMAP_DATAFILE
Redefine datafile references in all DDL statements.
REMAP_SCHEMA
Objects from one schema are loaded into another schema.
REMAP_TABLESPACE
Tablespace object are remapped to another tablespace.
REUSE_DATAFILES
Tablespace will be initialized if it already exists
(N).
SCHEMAS
List of schemas to import.
SKIP_UNUSABLE_INDEXES Skip indexes that were set to the Index Unusable state.
SQLFILE
STATUS
Keyword
Description (Default)
----------------------------------------------------------------------------DATA_OPTIONS
Data layer flags where the only valid value is:
SKIP_CONSTRAINT_ERRORS-constraint errors are not fatal.
PARTITION_OPTIONS
Specify how partitions should be transformed where the
valid keywords are: DEPARTITION, MERGE and (NONE)
REMAP_DATA
Specify a data conversion function,
e.g. REMAP_DATA=EMP.EMPNO:REMAPPKG.EMPNO
Oracle 11g Release 1 (11.2) altered the format of the help output as well as adding the following
parameters.
CLUSTER
Utilize cluster resources and distribute workers across the Oracle RAC.
Valid keyword values are: [Y] and N.
SERVICE_NAME
Name of an active Service and associated resource group to constrain Oracle
RAC resources.
SOURCE_EDITION
Edition to be used for extracting metadata.
TARGET_EDITION
Edition to be used for loading metadata.
Much greater data and metadata filtering capability than was provided by the original Export
utility. Data Pump supports filtering the metadata that is exported and imported based upon
objects and object types, using INCLUDE and EXCLUDE parameters.
Different modes for unloading/loading portions of the database including: full database mode,
schema mode, table mode, tablespace mode, and transportable tablespace mode.
Allow you to specify how partitioned tables should be handled during import operations, using
the PARTITION_OPTIONS parameter.
The original Export/Import utilities are required for the following types of database upgrades and
downgrades:
If you are upgrading from a release prior to Oracle Database 10g Release 1 (10.1), then you must
use the original Export/Import utilities to move the data. Likewise, if you are downgrading your
database to a release prior to Oracle Database 10g Release 1 (10.1), then you must use the
original Export/Import utilities.
If you must downgrade backward to a release prior to Oracle Database 10g Release 1 (10.1),
then the original Export utility continues to provide support to ensure backward compatibility.
If you are moving tables of XMLType or tables containing XMLType columns (schema and nonschema-based) from Oracle Database 11g Release 1 (11.1) to Oracle Database 10g Release 2
(10.2).
Comparison of command-line parameters from Original Export and Import to Data Pump
Data Pump commands have a similar look and feel to the original Export and Import commands,
but are different. Below are a few examples that demonstrate some of these differences.
DUMPFILE=scott.dmp
Example export of an entire database to a dump file with all GRANTS, INDEXES, and data
Original Import:
> exp username/password FULL=y FILE=dba.dmp GRANTS=y INDEXES=y ROWS=y
Data Pump Import:
>
expdp
username/password
FULL=y
INCLUDE=GRANT
DIRECTORY=dpump_dir1 DUMPFILE=dba.dmp CONTENT=ALL
INCLUDE=
INDEX
Data Pump offers much greater metadata filtering than original Export and Import. The
INCLUDE parameter allows you to specify which object (and its dependent objects) you want
to keep in the export job. The EXCLUDE parameter allows you to specify which object (and its
dependent objects) you want to keep out of the export job. You cannot mix the two
parameters in one job.
Both parameters work with Data Pump Import as well, and you can use different INCLUDE and
EXCLUDE options for different operations on the same dump file.
Tuning Parameters
Unlike original Export and Import, which used the BUFFER, COMMIT, COMPRESS, CONSISTENT,
DIRECT, and RECORDLENGTH parameters, Data Pump needs no tuning to achieve maximum
performance. Data Pump chooses the best method to ensure that data and metadata are
exported and imported in the most efficient manner. Initialization parameters should be sufficient
upon installation.
Data Pump Import can always read dump file sets created by older versions of Data Pump
Export.
Note that Data Pump Import cannot read dump files produced by original Export.
Parallelism
Data Pump Export and Import operations are processed in the database as a Data Pump job,
which is such more efficient that the client-side execution of original Export and Import. Now Data
Pump operations can take advantage of the servers parallel processes to read or write multiple
data streams simultaneously (PARALLEL is only available in the Enterprise Edition of Oracle
Database.)
The number of parallel processes can be changed on the fly using Data Pumps interactive
command-line mode. You may have a certain number of processes running during the day and
decide to change that number if more system resources become available at night (or vice versa).
Make sure your system is well balanced across CPU, memory, and I/O.
Have at least one dump file for each degree of parallelism. If there arent enough dump files,
performance will not be optimal because multiple threads of execution will be trying to access
the same dump file.
Put files that are members of a dump file set on separate disks so that they will be written and
read in parallel.
For export operations, use the %U variable in the DUMPFILE parameter so multiple dump files
can be automatically generated.
Example:
> expdp username/password DIRECTORY=dpump_dir1 JOB_NAME=hr DUMPFILE=par_exp%u.dmp
PARALLEL=4
REMAP
REMAP_TABLESPACE This allows you to easily import a table into a different tablespace from
which it was originally exported. The databases have to be 10.1 or later.
Example:
> impdp username/password REMAP_TABLESPACE=tbs_1:tbs_6 DIRECTORY=dpumpdir1
DUMPFILE=employees.dmp
REMAP_DATAFILES This is a very useful feature when you move databases between platforms
that have different file naming conventions. This parameter changes the source datafile name to
the target datafile name in all SQL statements where the source datafile is referenced. Because
the REMAP_DATAFILE value uses quotation marks, its best to specify the parameter within a
parameter file.
Example:
The parameter file, payroll.par, has the following content:
DIRECTORY=dpump_dir1 FULL=Y DUMPFILE=db_full.dmp
REMAP_DATAFILE=C:\DB1\HRDATA\PAYROLL\tbs6.dbf:/db1/hrdata/payroll/tbs6.dbf
You can then issue the following command:
> impdp username/password PARFILE=payroll.par
See the status of the job. All of the information needed to monitor the jobs execution is
available.
Add more dump files if there is insufficient disk space for an export file.
Change the default size of the dump files.
Stop the job (perhaps it is consuming too many resources) and later restart it (when more
resources become available).
Restart the job. If a job was stopped for any reason (system failure, power outage), you can
attach to the job and then restart it.
Increase or decrease the number of active worker processes for the job. (Enterprise Edition
only.)
Attach to a job from a remote site (such as from home) to monitor status
Network Mode
Data Pump gives you the ability to pass data between two databases over a network (via a
database link), without creating a dump file on disk. This is very useful if youre moving data
between databases, like data marts to data warehouses, and disk space is not readily available.
Note that if you are moving large volumes of data, Network mode is probably going to be slower
than file mode.
Network export creates the dump file set on the instance where the Data Pump job is running and
extracts the metadata and data from the remote instance.
Network export gives you the ability to export read-only databases. (Data Pump Export cannot run
locally on a read-only instance because the job requires write operations on the instance.) This is
useful when there is a need to export data from a standby database.
Generating SQLFILES
In original Import, the INDEXFILE parameter generated a text file which contained the SQL
commands necessary to recreate tables and indexes that you could then edit to get a workable
DDL script.
With Data Pump, its a lot easier to get a workable DDL script. When you run Data Pump Import
and specify the SQLFILE parameter, a text file is generated that has the necessary DDL (Data
Definition Language) in it to recreate all object types, not just tables and indexes.
Although this output file is ready for execution, the DDL statements are not actually executed, so
the target system will not be changed.
SQLFILEs can be particularly useful when pre-creating tables and objects in a new database. Note
that the INCLUDE and EXCLUDE parameters can be used for tailoring sqlfile output. For example, if
you want to create a database that contains all the tables and indexes of the source database, but
that does not include the same constraints, grants, and other metadata, you would issue a
command as follows:
>impdp
username/password
DIRECTORY=dpumpdir1
SQLFILE=dpump_dir2:expfull.sql INCLUDE=TABLE, INDEX
DUMPFILE=expfull.dmp
The SQL file named expfull.sql is written to dpump_dir2 and would include SQL DDL that could be
executed in another database to create the tables and indexes as desired.
What makes Data Pump faster than original Export and Import?
There are three main reasons that Data Pump is faster than original Export and Import.
First, the Direct Path data access method (which permits the server to bypass SQL and go right
to the data blocks on disk) has been rewritten to be much more efficient and now supports
Data Pump Import and Export.
Second, because Data Pump does its processing on the server rather than in the client, much
less data has to be moved between client and server.
Finally, Data Pump was designed from the ground up to take advantage of modern hardware
and operating system architectures in ways that original Export/ and Import cannot. These
factors combine to produce significant performance improvements for Data Pump over
original Export and Import.
How much faster is Data Pump than the original Export and Import utilities?
For a single stream, Data Pump Export is approximately 2 times faster than original Export and
Data Pump Import is approximately 15 to 40 times faster than original Import. Speed can be
dramatically improved using the PARALLEL parameter.
Are Data Pump dump files and original Export and Import dump files compatible?
No, the dump files are not compatible or interchangeable. If you have original Export dump
files, you must use original Import to load them.
How can I monitor my Data Pump jobs to see what is going on?
In interactive mode, you can get a lot of detail through the STATUS command. In SQL, you can
query the following views:
DBA_DATAPUMP_JOBS - all active Data Pump jobs and the state of each job
USER_DATAPUMP_JOBS summary of the users active Data Pump jobs
DBA_DATAPUMP_SESSIONS all active user sessions that are attached to a Data Pump
job.
V$SESSION_LONGOPS shows all progress on each active Data Pump job.
Conclusion
Data Pump is fast and flexible. It replaces original Export and Import starting in Oracle Database
10g. Moving to Data Pump is easy, and opens up a world of new options and features.
Whos DBA?
A database administrator (short form DBA) is a person responsible for the installation,
configuration, upgrade, administration, monitoring and maintenance of databases in an
organization.
The role includes the development and design of database strategies, system monitoring and
improving database performance and capacity, and planning for future expansion requirements.
They may also plan, co-ordinate and implement security measures to safeguard the database.
He / She should possess skills the following:
The job titles that DBAs might hold could be among the list below:
DBAs are also known by the titles Database Coordinator or Database Programmer.
The role is closely related to the other jobs of Database Analyst, Database
Modeller, Programmer Analyst, and Systems Manager.
Some organizations have a hierarchical level of database administrators, generally
3.2.
Reason 2: A DBA cares to do the right job the first time. Again, you can even let it boil down to
the self serving desire to not let the database be the cause for blame of a production outage. I
dont care, Im still going to make sure that the database environment I support is running as
well as it should and that we arent sacrificing best practices and performance (at least not
always!) for the sake of Well fix it later
DBAs Can Make Users Happy
How well are your systems running? Performance complaints? Do you have a DBA? If you dont
and the systems have a database back end it is incredibly likely that you are suffering from a lack
of database TLC. I dont know how many times I have been asked to consult on an engagement
to just make it faster! or inherited horrible performing environments that were easily fixed
with DBA 101 stuff (updating statistics, rebuilding indexes, the right settings, etc.). I know that
because I do some consulting on the side, I might be eating into some billable time here but
thats fine, I have a busy life with the family, church and full time work. As a DBA, I usually know
where to start looking for database performance problems. As a DBA, I usually know what
planned maintenance to do on the database server and databases to keep things running
smoothly. If you had a DBA, you would have less performance related fires; you wouldnt have
to pay an invoice to a consultant to come in and save the day. Your SYS Admin could help figure
out an issue but, if they dont have a lot of hands on and academic knowledge of database
performance tuning and troubleshooting, it is going to take longer and could potentially include
painful results if guesses/blind stabs are made. They specialize in a different skill set.
Reason 3: Database Administrators can prevent (or more easily resolve) performance issues or
troubleshooting situations.
Oh No!!! Everything is down!
Picture a disaster scenario. System is belly up, drives are burned, whatever. How quickly do you
want to be up? Your director, VP or CIO wants it yesterday and they want to know why your
people are running around in panic mode looking stuff up on search engines.
A good Database Administrator (again, hopefully) is practicing restores or devising clever ways
to sample for restore failure possibilities. They are thinking about disaster scenarios and
possible responses to them. They have done restores before and have likely dealt with strange
errors, corruption or common failure scenarios. Hopefully they are familiar with forums and
know where to help find (and test) information. They can think on their feet about the
ramifications of various recovery options or settings changes in a time of crisis.
Reason 4: Even if you stuffed your DBA in a closet on moth balls and only opened the door
when danger strikes the time saved in that disaster and the possible data saved during that
disaster justifies a DBA role in a lot of companies.
Your Data Is Your Business
How much do you rely on your data? Analysis of trends. Sales Forecasts. Payroll data. Sales data.
Customer lists. Partner lists. Inventory. Shipping and Tracking information. You name the piece
of your business; it is highly likely that you cant name 2 or 3 that dont have data stored in a
database. What happens if you lose that? What happens if you cant get to it fast enough?
What happens if you cant trust it to be accurate?
Reason 5: Your data is pretty important. You might have hired a Microsoft Exchange
experienced system administrator because you realize how important e-mail is to your
company. How useful is that e-mail system without your core systems described above? How
much does your organization spend on various forms of insurance?
How Can I Get a DBA?
I could go on with more reasons. I could give you horror stories. I could tell you about the
strange things vendors have requested (and the responses Ive gotten when questioning those
requests Things like look.. no one ever complained about that before). I could go out and
find statistics that talk about companies closing their doors because of data loss. I think you get
the point though.
If you have database instances and applications running, the simple truth is that you probably
have enough work to keep a DBA busy. Maybe you could start smaller and get someone on
retainer. I do that with some companies as an advisor/mentor. There are plenty of other people
offering the same types of services, some larger companies dedicated to providing remote DBA
or DBA Advisory services. Maybe you can hire someone with a good DBA background who has
other interests and could wear a second hat for you.
I would say that in the New England job market, this must be a known fact It seems like
database roles are always being advertised or actively recruited, even in the down economy. So I
would say get your DBA search on and fill that role already! Do it quick before the most
experienced DBAs are gobbled up.
I think its clear what I think You Need To Hire a Oracle DBA (Be that a full time person or at
least a consultant to come in and help ensure things are running well)
3.3.
Plan the relational design of the database objects and the storage characteristics for each of
these objects. By planning the relationship between each object and its physical storage before
creating it, you can directly affect the performance of the database as a unit. Be sure to plan for
the growth of the database. In distributed database environments, this planning stage is
extremely important. The physical location of frequently accessed data dramatically affects
application performance.
During the planning stage, develop a backup strategy for the database. You can alter the logical
storage structure or design of the database to improve backup efficiency. It is beyond the scope
of this book to discuss relational and distributed database design. If you are not familiar with
such design issues, please refer to accepted industry standard documentation.
Task 4: Create and Open the Database
After you complete the database design, you can create the database and open it for normal
use. You can create a database at installation time, using the Database Configuration Assistant,
or you can supply your own scripts for creating a database.
Task 5: Back Up the Database
After you create the database structure, carry out the backup strategy you planned for the
database. Create any additional redo log files, take the first full database backup (online or
offline), and schedule future database backups at regular intervals.
Task 6: Enroll System Users
After you back up the database structure, you can enroll the users of the database in
accordance with your Oracle license agreement, and grant appropriate privileges and roles to
these users.
Task 7: Implement the Database Design
After you create and start the database, and enroll the system users, you can implement the
planned logical structure database by creating all necessary tablespaces. When you have
finished creating tablespaces, you can create the database objects.
Task 8: Back Up the Fully Functional Database
When the database is fully implemented, again back up the database. In addition to regularly
scheduled backups, you should always back up your database immediately after implementing
changes to the database structure.
Task 9: Tune Database Performance
Optimizing the performance of the database is one of your ongoing responsibilities as a DBA.
Oracle Database provides a database resource management feature that helps you to control
the allocation of resources among various user groups.
Task 10: Download and Install Patches
After installation and on a regular basis, download and install patches. Patches are available as
single interim patches and as patch sets (or patch releases). Interim patches address individual
software bugs and may or may not be needed at your installation. Patch releases are collections
of bug fixes that are applicable for all customers.
Patch releases have release numbers. For example, if you installed Oracle Database 10.2.0.0, the
first patch release will have a release number of 10.2.0.1.
Task 11: Roll Out to Additional Hosts
After you have an Oracle Database installation properly configured, tuned, patched, and tested,
you may want to roll that exact installation out to other hosts. Reasons to do this include the
following:
You have multiple production database systems.
You want to create development and test systems that are identical to your production
system.
Instead of installing, tuning, and patching on each additional host, you can clone your tested
Oracle Database installation to other hosts, saving time and eliminating inconsistencies. There
are two types of cloning available to you:
Cloning an Oracle homejust the configured and patched binaries from the Oracle home
directory and subdirectories are copied to the destination host and fixed to match the new
environment. You can then start an instance with this cloned home and creates a database. You
can use the Enterprise Manager Clone Oracle Home tool to clone an Oracle home to one or
more destination hosts. You can also manually clone an Oracle home using a set of provided
scripts and Oracle Universal Installer.
Cloning a databaseThe tuned database, including database files, initialization parameters, and
so on, are cloned to an existing Oracle home (possibly a cloned home).You can use the
Enterprise Manager Clone Database tool to clone an Oracle database instance to an existing
Oracle home
Role of Oracle Database Administrator:
Oracle Database administrator is the cumulative role of multiple responsibilities. Do you know
this? Let me explain this thing. Oracle DBA can play as Application support in development or
may play as system analysis with system administrator or network administrator. Oracle DBA
has capability to plan capacity management with storage administrator.
Therefore we can say that roles and responsibilities of database administrator differ with
requirements and capability of database in various situations. After introduction of Oracle
Automatic Storage Management, Oracle DBA is able to act as storage administrator. For
troubleshooting of Oracle network and Oracle RAC network, he or she can play as network
administrator too. Due to these reasons, Oracle database administration is very difficult task and
it requires high expertise. Only expert Oracle DBA is able to provide Support for Oracle. Complex
database environment demands expert database services with strong service level
agreement with remote dba plans.
Hence we see that, under one name "Oracle Database Administrator" there are various roles as
following:
4.
Oracle Architecture
On a very high level Oracle Architecture can be divided into Database vs. Instance:
Objectives
These notes introduce the Oracle server architecture. The architecture includes physical
components, memory components, processes, and logical structures.
4.1.
System users can connect to an Oracle database through SQLPlus or through an application
program like the Internet Developer Suite (the program becomes the system user). This
connection enables users to execute SQL statements.
The act of connecting creates a communication pathway between a user process and an Oracle
Server. As is shown in the figure above, the User Process communicates with the Oracle Server
through a Server Process. The User Process executes on the client computer. The Server
Process executes on the server computer, and actually executes SQL statements submitted by
the system user.
The figure shows a 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.
Sessions: When a user connects to an Oracle server, this is termed a session. The User Global
Area is session memory and these memory structures are described later in this document. The
session starts when the Oracle server validates the user for connection. The session ends when
the user logs out (disconnects) or if the connection terminates abnormally (network failure or
client computer failure).
A user can typically have more than one concurrent session, e.g., the user may connect using
SQLPlus and also connect using Internet Developer Suite tools at the same time. The limit of
concurrent session connections is controlled by the DBA.
If a system users attempts to connect and the Oracle Server is not running, the system user
receives the Oracle Not Available error message.
4.2.
4.3.
Memory Structures
The memory structures include three areas of memory:
System Global Area (SGA) this is allocated when an Oracle Instance starts up.
Program Global Area (PGA) this is allocated when a Server Process starts up.
User Global Area (UGA) this is allocated when a user connects to create a session.
The SHOW SGA SQL command will show you the SGA memory allocations. This is a recent clip
of the SGA for the DBORCL database at SIUE. In order to execute SHOW SGA you must be
connected with the special privilege SYSDBA (which is only available to user accounts that are
members of the DBA Linux group).
SQL> connect / as sysdba
Connected.
SQL> show sga
Total System Global Area 1610612736 bytes
Fixed Size
2084296 bytes
Variable Size
1006633528 bytes
Database Buffers
587202560 bytes
Redo Buffers
14692352 bytes
Early versions of Oracle used a Static SGA. This meant that if modifications to memory
management were required, the database had to be shutdown, modifications were made to
the init.ora parameter file, and then the database had to be restarted.
Oracle 9i, 10g, and 11g use a Dynamic SGA. Memory configurations for the system global area
can be made without shutting down the database instance. The advantage is obvious. This
allows the DBA to resize the Database Buffer Cache and Shared Pool dynamically.
Several initialization parameters are set that affect the amount of random access memory
dedicated to the SGA of an Oracle Instance. These are:
SGA_MAX_SIZE: This optional parameter is used to set a limit on the amount of virtual
memory allocated to the SGA a typical setting might be 1 GB; however, if the value
for SGA_MAX_SIZE in the initialization parameter file or server parameter file is less than the
sum the memory allocated for all components, either explicitly in the parameter file or by
default, at the time the instance is initialized, then the database ignores the setting for
SGA_MAX_SIZE. For optimal performance, the entire SGA should fit in real memory to
eliminate paging to/from disk by the operating system.
DB_CACHE_SIZE: This optional parameter is used to tune the amount memory allocated to
the Database Buffer Cache in standard database blocks. Block sizes vary among operating
systems. The DBORCL database uses 8 KB blocks. The total blocks in the cache defaults
to 48 MB on LINUX/UNIX and 52 MB on Windows operating systems.
LOG_BUFFER: This optional parameter specifies the number of bytes allocated for the Redo
Log Buffer.
SHARED_POOL_SIZE: This optional parameter specifies the number of bytes of memory
allocated to shared SQL and PL/SQL. The default is 16 MB. If the operating system is based
on a 64 bit configuration, then the default size is 64 MB.
LARGE_POOL_SIZE: This is an optional memory object the size of the Large Pool defaults
to zero. If the init.ora parameterPARALLEL_AUTOMATIC_TUNING is set to TRUE, then the
default size is automatically calculated.
JAVA_POOL_SIZE: This is another optional memory object. The default is 24 MB of
memory.
The size of the SGA cannot exceed the parameter SGA_MAX_SIZE minus the combination of the
size of the additional parameters, DB_CACHE_SIZE, LOG_BUFFER, SHARED_POOL_SIZE,
LARGE_POOL_SIZE and JAVA_POOL_SIZE.
Memory is allocated to the SGA as contiguous virtual memory in units termed granules. Granule
size depends on the estimated total size of the SGA, which as was noted above, depends on the
SGA_MAX_SIZE parameter. Granules are sized as follows:
If the SGA is less than 1 GB in total, each granule is 4 MB.
If the SGA is greater than 1 GB in total, each granule is 16 MB.
Granules are assigned to the Database Buffer Cache, Shared Pool, Java Pool, and other memory
structures, and these memory components can dynamically grow and shrink. Using contiguous
memory improves system performance. The actual number of granules assigned to one of these
memory components can be determined by querying the database view
named V$BUFFER_POOL.
Granules are allocated when the Oracle server starts a database instance in order to provide
memory addressing space to meet the SGA_MAX_SIZE parameter. The minimum is 3
granules: one each for the fixed SGA, Database Buffer Cache, and Shared Pool. In practice,
you'll find the SGA is allocated much more memory than this. The SELECT statement shown
below shows a current_size of 1,152 granules.
SELECT name, block_size, current_size, prev_size, prev_buffers
FROM v$buffer_pool;
NAME
BLOCK_SIZE CURRENT_SIZE PREV_SIZE PREV_BUFFERS
-------------------- ---------- ------------ ---------- -----------DEFAULT
8192
560
576
71244
For additional information on the dynamic SGA sizing, enroll in Oracle's Oracle11g Database
Performance Tuning course.
The Program Global Area is also termed the Process Global Area (PGA) and is a part of memory
allocated that is outside of the Oracle Instance.
It stores data and control information for a single Server Process or a single Background
Process.
It is allocated when a process is created and the memory is scavenged by the operating
system when the process terminates. This is NOT a shared part of memory one PGA to
each process only.
The content of the PGA varies, but as shown in the figure above, generally includes the
following:
Private SQL Area: Stores information for a parsed SQL statement stores bind variable
values and runtime memory allocations. A user session issuing SQL statements has a Private
SQL Area that may be associated with a Shared SQL Area if the same SQL statement is being
executed by more than one system user. This often happens in OLTP environments where
many users are executing and using the same application program.
Dedicated Server environment the Private SQL Area is located in the Program Global Area.
Shared Server environment the Private SQL Area is located in the System Global Area.
Session Memory: Memory that holds session variables and other session information.
SQL Work Areas: Memory allocated for sort, hash-join, bitmap merge, and bitmap create
types of operations.
Oracle 9i and later versions enable automatic sizing of the SQL Work Areas by setting
the WORKAREA_SIZE_POLICY
=
AUTO parameter
(this
is
the
default!)
and PGA_AGGREGATE_TARGET = n (where n is some amount of memory established by the
DBA). However, the DBA can let the Oracle DBMS determine the appropriate amount of
memory.
A session that loads a PL/SQL package into memory has the package state stored to the
UGA. The package state is the set of values stored in all the package variables at a specific time.
The state changes as program code the variables. By default, package variables are unique to
and persist for the life of the session.
The OLAP page pool is also stored in the UGA. This pool manages OLAP data pages, which are
equivalent to data blocks. The page pool is allocated at the start of an OLAP session and
released at the end of the session. An OLAP session opens automatically whenever a user
queries a dimensional object such as a cube.
Note: Oracle OLAP is a multidimensional analytic engine embedded in Oracle Database
11g. Oracle OLAP cubes deliver sophisticated calculations using simple SQL queries - producing
results with speed of thought response times.
The UGA must be available to a database session for the life of the session. For this reason, the
UGA cannot be stored in the PGA when using a shared server connection because the PGA is
specific to a single process. Therefore, the UGA is stored in the SGA when using shared server
connections, enabling any shared server process access to it. When using a dedicated
server connection, the UGA is stored in the PGA.
The granule size that is currently being used for the SGA for each component can be viewed in
the view V$SGAINFO. The size of each component and the time and type of the last resize
operation performed on each component can be viewed in the view
V$SGA_DYNAMIC_COMPONENTS.
SQL> select * from v$sgainfo;
More...
NAME
BYTES RES
-------------------------------- ---------- --Fixed SGA Size
2084296 No
Redo Buffers
14692352 No
Buffer Cache Size
587202560 Yes
Shared Pool Size
956301312 Yes
Large Pool Size
16777216 Yes
Java Pool Size
33554432 Yes93
Streams Pool Size
0 Yes
Granule Size
16777216 No
Maximum SGA Size
1610612736 No
Startup overhead in Shared Pool 67108864 No
Free SGA Memory Available
0
11 rows selected.
Shared Pool
The Shared Pool is a memory structure that is shared by all system users.
It caches various types of program data. For example, the shared pool stores parsed SQL,
PL/SQL code, system parameters, and data dictionary information.
The shared pool is involved in almost every operation that occurs in the database. For
example, if a user executes a SQL statement, then Oracle Database accesses the shared
pool.
It consists of both fixed and variable structures.
The variable component grows and shrinks depending on the demands placed on memory
size by system users and application programs.
Memory can be allocated to the Shared Pool by the parameter SHARED_POOL_SIZE in the
parameter file. The default value of this parameter is 8MB on 32-bit platforms and 64MB on 64bit platforms. Increasing the value of this parameter increases the amount of memory reserved
for the shared pool.
You can alter the size of the shared pool dynamically with the ALTER SYSTEM SET command. An
example command is shown in the figure below. You must keep in mind that the total memory
allocated to the SGA is set by the SGA_TARGET parameter (and may also be limited by
the SGA_MAX_SIZE if it is set), and since the Shared Pool is part of the SGA, you cannot exceed
the maximum size of the SGA. It is recommended to let Oracle optimize the Shared Pool size.
The Shared Pool stores the most recently executed SQL statements and used data
definitions. This is because some system users and application programs will tend to execute
the same SQL statements often. Saving this information in memory can improve system
performance.
The Shared Pool includes several cache areas described below.
Library Cache
Memory is allocated to the Library Cache whenever an SQL statement is parsed or a program
unit is called. This enables storage of the most recently used SQL and PL/SQL statements.
If the Library Cache is too small, the Library Cache must purge statement definitions in order to
have space to load new SQL and PL/SQL statements. Actual management of this memory
structure is through a Least-Recently-Used (LRU) algorithm. This means that the SQL and
PL/SQL statements that are oldest and least recently used are purged when more storage space
is needed.
The Library Cache is composed of two memory subcomponents:
Shared SQL: This stores/shares the execution plan and parse tree for SQL statements,
as well as PL/SQL statements such as functions, packages, and triggers. If a system user
executes an identical statement, then the statement does not have to be parsed again in
order to execute the statement.
Private SQL Area: With a shared server, each session issuing a SQL statement has a
private SQL area in its PGA.
Each user that submits the same statement has a private SQL area pointing to the same
shared SQL area.
Many private SQL areas in separate PGAs can be associated with the same shared SQL area.
This figure depicts two different client processes issuing the same SQL statement the
parsed solution is already in the Shared SQL Area.
Typical block sizes are 2KB, 4KB, 8KB, 16KB, and 32KB.
The size of blocks in the Database Buffer Cache matches the block size for the database.
The DBORCL database uses an 8KB block size.
This figure shows that the use of non-standard block sizes results in multiple database buffer
cache memory allocations.
Because tablespaces that store oracle tables can use different (non-standard) block sizes, there
can be more than one Database Buffer Cache allocated to match block sizes in the cache with
the block sizes in the non-standard tablespaces.
The size of the Database Buffer Caches can be controlled by the parameters DB_CACHE_SIZE
and DB_nK_CACHE_SIZE to dynamically change the memory allocated to the caches without
restarting the Oracle instance.
You can dynamically change the size of the Database Buffer Cache with the ALTER SYSTEM
command like the one shown here:
ALTER SYSTEM SET DB_CACHE_SIZE = 96M;
You can have the Oracle Server gather statistics about the Database Buffer Cache to help you
size it to achieve an optimal workload for the memory allocation. This information is displayed
from the V$DB_CACHE_ADVICE view. In order for statistics to be gathered, you can
dynamically alter the system by using the ALTER SYSTEM SET DB_CACHE_ADVICE (OFF, ON,
READY) command. However, gathering statistics on system performance always incurs some
overhead that will slow down system performance.
SQL> ALTER SYSTEM SET db_cache_advice = ON;
System altered.
SQL> DESC V$DB_cache_advice;
Name
Null? Type
----------------------------------------- -------- ------------ID
NUMBER
NAME
VARCHAR2(20)
BLOCK_SIZE
NUMBER
ADVICE_STATUS
VARCHAR2(3)
SIZE_FOR_ESTIMATE
NUMBER
SIZE_FACTOR
NUMBER
BUFFERS_FOR_ESTIMATE
NUMBER
ESTD_PHYSICAL_READ_FACTOR
NUMBER
ESTD_PHYSICAL_READS
ESTD_PHYSICAL_READ_TIME
ESTD_PCT_OF_DB_TIME_FOR_READS
ESTD_CLUSTER_READS
ESTD_CLUSTER_READ_TIME
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
The Redo Log Buffer memory object stores images of all changes made to database blocks.
Database blocks typically store several table rows of organizational data. This means that if
a single column value from one row in a block is changed, the block image is stored. Changes
include INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP.
LGWR writes redo sequentially to disk while DBWn performs scattered writes of data blocks
to disk.
Scattered writes tend to be much slower than sequential writes.
Because LGWR enable users to avoid waiting for DBWn to complete its slow writes, the
database delivers better performance.
The Redo Log Buffer as a circular buffer that is reused over and over. As the buffer fills up,
copies of the images are stored to the Redo Log Files that are covered in more detail in a later
module.
Large Pool
The Large Pool is an optional memory structure that primarily relieves the memory burden
placed on the Shared Pool. The Large Pool is used for the following tasks if it is allocated:
Allocating space for session memory requirements from the User Global Area where a
Shared Server is in use.
Transactions that interact with more than one database, e.g., a distributed database
scenario.
Backup and restore operations by the Recovery Manager (RMAN) process.
RMAN uses this only if the BACKUP_DISK_IO = n and BACKUP_TAPE_IO_SLAVE =
TRUE parameters are set.
If the Large Pool is too small, memory allocation for backup will fail and memory will be
allocated from the Shared Pool.
Parallel execution message buffers for parallel server
operations. The PARALLEL_AUTOMATIC_TUNING = TRUE parameter must be set.
The Large Pool size is set with the LARGE_POOL_SIZE parameter this is not a dynamic
parameter. It does not use an LRU list to manage memory.
Java Pool
The Java Pool is an optional memory object, but is required if the database has Oracle Java
installed and in use for Oracle JVM (Java Virtual Machine).
The size is set with the JAVA_POOL_SIZE parameter that defaults to 24MB.
The Java Pool is used for memory allocation to parse Java commands and to store data
associated with Java commands.
Storing Java code and data in the Java Pool is analogous to SQL and PL/SQL code cached in
the Shared Pool.
Streams Pool
This pool stores data and control structures to support the Oracle Streams feature of Oracle
Enterprise Edition.
Oracle Steams manages sharing of data and events in a distributed environment.
It is sized with the parameter STREAMS_POOL_SIZE.
If STEAMS_POOL_SIZE is not set or is zero, the size of the pool grows dynamically.
4.4.
Processes
You need to understand three different types of Processes:
User/Client Process: Starts when a database user requests to connect to an Oracle Server.
Server Process: Establishes the Connection to an Oracle Instance when a User Process
requests connection makes the connection for the User Process.
Background Processes: These start when an Oracle Instance is started up.
This generates a User Process (a memory object) that generates programmatic calls through
your user interface (SQLPlus, Integrated Developer Suite, or application program) that creates a
session and causes the generation of a Server Process that is either dedicated or shared.
A 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.
Allocation of server process in a dedicated environment versus a shared environment is
covered in further detail in the Oracle11g Database Performance Tuning course offered by
Oracle Education.
Others
SMON
The System Monitor (SMON) is responsible for instance recovery by applying entries in the
online redo log files to the data files. It also performs other activities as outlined in the figure
shown below.
If an Oracle Instance fails, all information in memory not written to disk is lost. SMON is
responsible for recovering the instance when the database is started up again. It does the
following:
Rolls forward to recover data that was recorded in a Redo Log File, but that had not yet
been recorded to a datafile by DBWn. SMON reads the Redo Log Files and applies the
changes to the data blocks. This recovers all transactions that were committed because
these were written to the Redo Log Files prior to system failure.
Opens the database to allow system users to logon.
Rolls back uncommitted transactions.
SMON also does limited space management. It combines (coalesces) adjacent areas of free
space in the database's data files for tablespaces that are dictionary managed.
It also de-allocates temporary segments to create free space in the data files.
DBWn (also called DBWR in earlier Oracle Versions)
The Database Writer writes modified blocks from the database buffer cache to the datafiles.
Although one database writer process (DBW0) is sufficient for most systems, you can configure
up to 20 DBWn processes (DBW0 through DBW9 and DBWa through DBWj) in order to improve
write performance for a system that modifies data heavily.
LGWR
The Log Writer (LGWR) writes contents from the Redo Log Buffer to the Redo Log File that is in
use. These are sequential writes since the Redo Log Files record database modifications based
on the actual time that the modification takes place. LGWR actually writes before the DBWn
writes and only confirms that a COMMIT operation has succeeded when the Redo Log Buffer
contents are successfully written to disk. LGWR can also call the DBWn to write contents of the
Database Buffer Cache to disk. The LGWR writes according to the events illustrated in the figure
shown below.
CKPT
The Checkpoint (CPT) process writes information to update the database control files and
headers of datafiles to identify the point in time with regard to the Redo Log Files where
instance recovery is to begin should it be necessary. This is done at a minimum, once
every three seconds.
Think of a checkpoint record as a starting point for recovery. DBWn will have completed writing
all buffers from the Database Buffer Cache to disk prior to the checkpoint, thus those records
will not require recovery. This does the following:
Ensures modified data blocks in memory are regularly written to disk CKPT can call the
DBWn process in order to ensure this and does so when writing a checkpoint record.
Reduces Instance Recovery time by minimizing the amount of work needed for recovery
since only Redo Log File entries processed since the last checkpoint require recovery.
Causes all committed data to be written to data files during database shutdown.
If a Redo Log File fills up and a switch is made to a new Redo Log File (this is covered in more
detail in a later module), the CKPT process also writes checkpoint information into the headers
of the data files.
Checkpoint information written to control files includes the system change number (the SCN is a
number stored in the control file and in the headers of the database files that are used to ensure
that all files in the system are synchronized), location of which Redo Log File is to be used for
recovery, and other information.
CKPT does not write data blocks or redo blocks to disk it calls DBWn and LGWR as necessary.
MMON and MMNL
The Manageability Monitor Process (MMNO) performs tasks related to the Automatic Workload
Repository (AWR) a repository of statistical data in the SYSAUX tablespace (see figure below)
for example, MMON writes when a metric violates its threshold value, taking snapshots, and
capturing statistics value for recently modified SQL objects.
The Manageability Monitor Lite Process (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.
The information stored by these processes is used for performance tuning we survey
performance tuning in a later module.
RECO
The Recoverer Process (RECO) is used to resolve failures of distributed transactions in a
distributed database.
Consider a database that is distributed on two servers one in St. Louis and one in Chicago.
Further, the database may be distributed on servers of two different operating systems, e.g.
LINUX and Windows.
The RECO process of a node automatically connects to other databases involved in an indoubt distributed transaction.
When RECO reestablishes a connection between the databases, it automatically resolves all
in-doubt transactions, removing from each database's pending transaction table any rows
that correspond to the resolved transactions.
ARCn
While the Archiver (ARCn) is an optional background process, we cover it in more detail because
it is almost always used for production systems storing mission critical information. The ARCn
process must be used to recover from loss of a physical disk drive for systems that are "busy"
with lots of transactions being completed.
When a Redo Log File fills up, Oracle switches to the next Redo Log File. The DBA creates
several of these and the details of creating them are covered in a later module. If all Redo Log
Files fill up, then Oracle switches back to the first one and uses them in a round-robin fashion by
overwriting ones that have already been used it should be obvious that the information stored
on the files, once overwritten, is lost forever.
If ARCn is in what is termed ARCHIVELOG mode, then as the Redo Log Files fill up, they are
individually written to Archived Redo Log Files and LGWR does not overwrite a Redo Log File
until archiving has completed. Thus, committed data is not lost forever and can be recovered in
the event of a disk failure. Only the contents of the SGA will be lost if an Instance fails.
In NOARCHIVELOG mode, the Redo Log Files are overwritten and not archived. Recovery can
only be made to the last full backup of the database files. All committed transactions after the
last full backup are lost, and you can see that this could cost the firm a lot of $$$.
When running in ARCHIVELOG mode, the DBA is responsible to ensure that the Archived Redo
Log Files do not consume all available disk space! Usually after two complete backups are
made, any Archived Redo Log Files for prior backups are deleted.
4.5.
Logical Structure
It is helpful to understand how an Oracle database is organized in terms of a logical structure
that is used to organize physical objects.
Tablespace: An Oracle database must always consist of at least two tablespaces (SYSTEM and
SYSAUX), although a typical Oracle database will multiple tablespaces.
A tablespace is a logical storage facility (a logical container) for storing objects such as
tables, indexes, sequences, clusters, and other database objects.
Each tablespace has at least one physical datafile that actually stores the tablespace at the
operating system level. A large tablespace may have more than one datafile allocated for
storing objects assigned to that tablespace.
A tablespace belongs to only one database.
Tablespaces can be brought online and taken offline for purposes of backup and
management, except for the SYSTEM tablespace that must always be online.
Tablespaces can be in either read-only or read-write status.
Datafile: Tablespaces are stored in datafiles which are physical disk objects.
A datafile can only store objects for a single tablespace, but a tablespace may have more
than one datafile this happens when a disk drive device fills up and a tablespace needs to
be expanded, then it is expanded to a new disk drive.
The DBA can change the size of a datafile to make it smaller or later. The file can also grow
in size dynamically as the tablespace grows.
Segment: When logical storage objects are created within a tablespace, for example, an
employee table, a segment is allocated to the object.
Extent: Each object has one segment which is a physical collection of extents.
Extents are simply collections of contiguous disk storage blocks. A logical storage object
such as a table or index always consists of at least one extent ideally the initial extent
allocated to an object will be large enough to store all data that is initially loaded.
As a table or index grows, additional extents are added to the segment.
A DBA can add extents to segments in order to tune performance of the system.
An extent cannot span a datafile.
Block: The Oracle Server manages data at the smallest unit in what is termed a block or data
block. Data are actually stored in blocks.
A physical block is the smallest addressable location on a disk drive for read/write operations.
An Oracle data block consists of one or more physical blocks (operating system blocks) so the
data block, if larger than an operating system block, should be an even multiple of the operating
system block size, e.g., if the Linux operating system block size is 2K or 4K, then the Oracle data
block should be 2K, 4K, 8K, 16K, etc in size. This optimizes I/O.
The data block size is set at the time the database is created and cannot be changed. It is set
with the DB_BLOCK_SIZE parameter. The maximum data block size depends on the operating
system.
Thus, the Oracle database architecture includes both logical and physical structures as follows:
Physical: Control files; Redo Log Files; Datafiles; Operating System Blocks.
Logical: Tablespaces; Segments; Extents; Data Blocks.
4.6.
Processing a query:
Parse:
Search for identical statement in the Shared SQL Area.
Check syntax, object names, and privileges.
Lock objects used during parse.
Create and store execution plan.
Bind: Obtains values for variables.
Execute: Process statement.
Fetch: Return rows to user process.
Processing a DML statement:
Parse: Same as the parse phase used for processing a query.
Bind: Same as the bind phase used for processing a query.
Execute:
If the data and undo blocks are not already in the Database Buffer Cache, the server
process reads them from the data files into the Database Buffer Cache.
The server process places locks on the rows that are to be modified. The undo block is
used to store the before image of the data, so that the DML statements can be rolled
back if necessary.
The data blocks record the new values of the data.
The server process records the before image to the undo block and updates the data
block. Both of these changes are made in the Database Buffer Cache. Any changed
blocks in the Database Buffer Cache are marked as dirty buffers. That is, buffers that
are not the same as the corresponding blocks on the disk.
The processing of a DELETE or INSERT command uses similar steps. The before image
for a DELETE contains the column values in the deleted row, and the before image of an
INSERT contains the row location information.
5.
Certain changes are necessary to the memory structures within Oracle to provide the Shared
Server capability. Let's see what changes within the Oracle infrastructure are necessary to
provide this support.
5.2.
Configuration of shared server involves only few steps. Oracle database has pre-configured
setting to enable shared server. Shared server can be configured by setting values for few
initialization parameters at run time. These parameters can also be initialized in initialization
parameter file. Following section discusses these parameters in detail.
SHARED_SERVERS Initialization Parameter
SHARED_SERVERS is the only parameter necessary to enable a shared server. Its value specifies
that how many shared server are to be started.
Use following SQL statement to enable shared server.
alter system set shared_servers = 5;
This command will start five shared servers; oracle database will also start a dispatcher process.
Remember we did not configure any dispatcher. Oracle database will create dispatcher on its
own.
To configure Shared server at database startup, use following setting in initialization parameter
file.
SHARED_SERVERS=5;
You can query V$SHARED_SERVER view to confirm changes.
MAX_SHARED_SERVERS Initialization Parameter
Oracle database keeps number of shared servers equal to SHARED_SERVERS parameter value.
So SHARED_SERVER defines lower limit of shared server processes. PMON starts as many Shared
servers as needed. But you can restrict upper limit by using MAX_SHARED_SERVERS.
For example, use following setting in parameter file to restrict maximum shared Server to 10;
MAX_SHARED_SERVERS= 2;
SHARED_SERVER_SESSIONS Initialization Parameter
Use this parameter to limit maximum concurrent shares server sessions. Value of this parameter
should be less than SESSION initialization parameter. You may use this parameter to make sure
that resources are always available for few dedicated server sessions.
DISPATCHERS Initialization Parameter
DISPATCHERS parameter is used to create dispatcher processes. For example, use following
setting in parameter file to create Dispatcher.
Use following setting to create 3 dispatchers
DISPATCHERS=(PROTOCOL=TCP)(DISPATCHERS=3)
Query V$DISPATCHER view to find out details about currently running dispatchers.
Client Side Setting for Shared Server
When oracle database has been configured as Shares server, by default all connection will be
entertained by Shared Server. Net service on client can be modified to use a shared Server or
Dedicated server. Use SERVER=SHARED or SERVER=DEDICATED in connect_data section. As
shown in example below
<DBNAME>=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)(HOST=market-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=<DBNAME>)
(SERVER=dedicated)))
You can query V$SESSION view to confirm Dedicated or Shared servers sessions.
5.3.
As we know, every connection to an oracle database has some session specific memory tied to
it. This memory is sometime referred to as the User Global Area (UGA). The UGA will hold
session specific items, bind variable values, and PL/SQL variables. Apart from this the UGA will
also hold the sort area.
In a dedicated server process, the UGA is stored in the Program Global Area (PGA). The PGA is a
private area for each individual process. However, in the case of a Shared server, the UGA is
stored either in the large pool (if it has been configured) or the shared pool.
The rationale for moving the UGA into a shared area is very clear: any shared server process
may be called upon to process a SQL statement of the client, so every shared server process
needs access to each clients session state.
While the shared server process does not affect the total amount of memory used for sessionspecific data, it does move the memory of the individual user server processes into a common
memory space accessible to all processes. Any memory savings that come about by the use of
shared server process is simply through the reduction in the number of processes that you need
to run at any given time.
So, to continue with our shared server series, let's begin with how a user connects through a
shared server connection: When a dedicated server is used, the listener spawns a dedicated
server process for each separate client connection. The listener then gets out of the way and the
client is connected to the server process dedicated to it. In a shared server environment,
however, the listener does not spawn a separate process for each connecting user. Instead, the
listener connects the user to a process known as dispatcher, which assumes the task of
communicating with the clients. The listener, instead of handing off the connection to a
dedicated server process, does so to the most lightly loaded dispatcher, which in turn handles all
communication with the client for the duration of the session.
At least one dispatcher process is already there when a client initiates a connection request. To
the question of how many dispatchers need to be configured, my opinion is that you need one
for each protocol you support, while in practice you may need more than that, because of your
operating system's limitations regarding the number of connections it will support, as well as
the issue of performance. There may be a serious performance degradation if your clients are
busy and you have fewer number of dispatchers configured, although as I will show later,
changing the number of dispatchers is pretty simple. A good starting point will be to base the
number of dispatchers on the number of connections to be made. Later on, you can make
adjustments by monitoring how busy your dispatchers remain. Dispatchers are the key
initialization parameter that needs to be set in order to implement shared server.
system@ORCL-SQL>>show parameter disp
NAME_COL_PLUS_SHOW_PARAM TYPE
-------------------------------------------------------------------------------- ---------VALUE_COL_PLUS_SHOW_PARAM
--------------------------------------------------------------------------------------------------dispatchers string
(PROTOCOL=TCP) (SERVICE=orclXDB)
max_dispatchers integer
I have not configured shared server on my system and as such no values have been set either for
the dispatchers or max_dispatchers initialization parameters. Now, let's configure a few
dispatchers:
That's it pretty straightforward and simple. However things can become complicated when you
force an address with the dispatcher. You may want to do so, for example, to get around firewall
issues or specify a particular port. The Listener attribute of the Dispatcher parameter allows you
to specify which listener you want your dispatcher to register with. By default dispatchers
register on the listener monitoring port 1521 on the local machine, but if your listener is running
on a different machine or you to register with a non default listener you need to use the Listener
attribute to specify that.
Ok, now let's get back to what the dispatcher actually does. For a start, the dispatcher takes the
requests of the clients and places it on a request queue.
The request queue is an area of memory in the System Global Area (SGA). The shared server
process monitors the request queue. When a request is put on the queue, an available sever
process picks it out of the queue and services it. Requests are handled in first in-first out basis
(FIFO) as shared servers become available.
After a request has been serviced it is placed in a response queue. The response queue is an
area of memory within the SGA and it is dispatcher specific. That means that while all the
requests are placed in a single queue, each dispatcher will have it's own response queue. When
a dispatcher finds a response in it's response queue, it sends that response back to the client
that initiated the request. In my next post, I will take up the issues of which data dictionary
views contain what information vis-a vis shared servers etc., large pool configuration and other
sundry items.
To continue with the shared server series, the issues of configuration of memory, and the
management of shared servers using available data dictionary views and initialization
parameters. How much memory should you configure for shared servers? Well, that may be
based upon the memory requirements of a representative session multiplied by the expected
number of user connections you expect to connect simultaneously. Querying data dictionary
views v$session, v$sesstat, v$statname gives us the memory usage of a representative user
session. Here's how I work it out:
system@ORCL-SQL>>SELECT p.NAME,
s.VALUE
FROM
v$sessTat s,
v$sTatName p
WHERE s.sTatIsTic# = p.sTatIsTic#
AND p.NAME IN ('session uga memory',
'session uga memory max')
AND s.sId IN (SELECT sId
FROM
v$Session
WHERE UserName = 'SCOTT');
NAME VALUE
---------------------------------------------------------------- ---------session uga memory 86720
session uga memory max 152184
The session UGA memory is representative of the amount of memory that Scott is using in the
session while uga memory max represents the currently maximum amount of memory that has
been used at any time during Scott's session. If Scott is your representative user, then all you
need to do is to multiply Scott's memory usage by the number of users you expect to
simultaneously connect to the database. For example, if you guesstimate that 35 users may be
connecting at a given time then you can configure about 35*(152184/1024) i.e., about 520 KB of
memory.
Oracle recommends using the large pool instead of the shared pool for configuring shared
servers. The mechanics of using the large pool for configuring shared servers is pretty straight
forward--all you need to do is configure a large pool, if it is there, memory will be allocated out
of it, and otherwise the shared pool will be used. Now, let's have a look at the initialization
parameters that need to be configured, set, or modified while configuring an instance to use
shared server:
Dispatchers
Shared_servers
Shared_server_sessions
Max_shared_servers
Max_dispatchers
Local_listener
Large_pool
Large_pool_size
Dispatcher is the key initialization parameter that needs to be set in order to meaningfully
implement shared servers. Of course, if you have created a shared server database, using a tool
like the database creation assistant (DBCA), then you already have a dispatcher configured to
cater to the TCP/IP protocol, but in practice you may want to keep dispatchers configured to
handle other protocols as well.
The initialization parameter shared server specifies the number of server processes that you
want to create when an instance is started up. If system load decreases, this minimum number
of servers is maintained. Therefore, you should take care not to set this parameter too high at
system startup.
shared_server_session specifies the total number of shared server architecture user sessions to
allow. Setting this parameter enables you to reserve user sessions for dedicated servers.
max_shared_servers, as the name implies, limits the number of shared servers running
simultaneously.
max_dispatchers specifies the maximum number of dispatcher processes allowed to be running
simultaneously. The default is 5 and it applies only if dispatchers have been configured for the
system. The value of max_dispatchers should equal the maximum number of concurrent
sessions divided by the number of connections for each dispatcher. For most systems, a value of
250 connections for each dispatcher provides good performance. For example, if you have 1000
concurrent sessions running, and your dispatcher allows a maximum of 300 connections each,
the number of dispatchers to configure would be ceil(1000/300) i.e. 4.
The initialization parameter local_listener specifies a network name that resolves to an address
or address list of Oracle Net local listeners (that is, listeners that are running on the same
machine as this instance). The address or address list is specified in the tnsnames.ora file or
other address repository as configured for your system.
The initialization parameter large_pool lets you specify the size (in bytes) of the large pool
allocation heap. The large pool allocation heap is used in shared server systems for session
memory, by parallel execution for message buffers, and by backup processes for disk I/O
buffers.
The initialization parameter large_pool_size is an interesting parameter. In case you are using a
shared server connection, Oracle adds about 250k of memory for each session if you have
configured dispatchers. The final derived value also includes a port-specific amount of memory
for backup I/O buffers. So, there is always the potential for the total derived value to be too
large to actually allocate, or it may impact the performance negatively. In such cases it is always
advisable to set large_pool_size to a sufficiently small value so that the database may start.
Ok, once you have created a shared server connection and configured an optimal number of
dispatchers for your system, how do you make the thing work? Well, you do nothing! Once you
have configured shared servers for an instance, new connections begin to use it of it's own
accord. You don't have to make any changes to your Oracle Net files for using shared server. If it
is there it will be used. In fact, in a shared server environment, if you ever require using a
dedicated server connection, one way to do it would be to make a separate entry in the
tnsnames.ora file (assuming that you are using local naming). I demonstrate below an example
of this. While I am manually editing the tnsnames.ora file, I suggest that you use the Net
Configuration Assistant to create a new net service name and then add attribute
(SERVER=DEDICATED) to the list of CONNECT_DATA attributes.
<DBNAME>=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS= (PROTOCOL=TCP) (HOST=<COMPUTER_NAME>) (PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=<DBNAME>) (SERVER=DEDICATED)))
Another less flexible way to do it would be through the sqlnet.ora file. Just set the parameter
USE_DEDICATED_SERVER=ON and you are on your way. However, this approach affects every
session you initiate and will not serve your purpose, if you need to use dedicated server only
occasionally, like say, for example when you are using RMAN. The better approach definitely
would be to create a new net service name just for this purpose.
5.4.
6.
Value
DISPLAY
hostname:display_number.screen_number
Very few tools, such as oidadmin, require the DISPLAY variable.
LD_LIBRARY_PATH
If the calling application is a 32-bit application, ensure that the value contains the
following directory:
$ORACLE_HOME/lib32
If the calling application is a 64-bit application, ensure that the value contains the
following directory:
$ORACLE_HOME/lib
(Solaris
Ensure that the value contains the following directory:
only) LD_LIBRARY_PATH_64 $ORACLE_HOME/lib
(HP-UX only) SHLIB_PATH
MW_HOME
Set the value to the full path of the installation's Middleware home. Do not use a
trailing slash in the definition. The following example shows the full path:
/scratch/Oracle/Middleware
ORACLE_HOME
Setting this is useful if you are working with just one Oracle home. Set to the full
path of the Oracle home. Do not use a trailing slash in the definition. The following
Environment Variable
Value
example shows the full path:
/scratch/Oracle/Middleware/ORACLE_HOME_SOA1
ORACLE_INSTANCE
Optional. Setting this is useful if you have only one Oracle instance in your
environment or if you are working with just that one instance. Set to the full path of
an Oracle instance. Do not use a trailing slash in the definition. The following
example shows the full path of a Web Tier installation:
/scratch/Oracle/Middleware/WebTier/instances/instance1
PATH
Ensure that the value contains the following directories, which contains basic
commands used by all installations:
$ORACLE_COMMON_HOME/bin
$ORACLE_COMMON_HOME/common/bin
When you start to work with specific components, you may want to add additional
directories to your path, as recommended by the component documentation.
JAVA_HOME
CLASSPATH
Value
MW_HOME
Set the value to the full path of the installation's Middleware home. Do not
use a trailing backslash in the definition. The following example shows the
full path:
C:\oracle\Middleware
ORACLE_HOME
Setting this is useful if you are working with just one Oracle home. Set the
value to the full path of the Oracle home. Do not use a trailing backslash in
the definition. The following example shows the full path:
C:\oracle\Middleware\ORACLE_SOA1
ORACLE_INSTANCE
Optional. Setting this is useful if you have only one Oracle instance in your
environment or if you are working with just that one instance. Set the value
to the full path of an Oracle instance. Do not use a trailing backslash in the
definition. The following example shows the full path of a Web Tier
installation:
C:\oracle\Middleware\WebTier\instances\instance1
PATH
Ensure that the value contains the following directory, which contains basic
commands used by all installations:
ORACLE_COMMON_HOME\bin
ORACLE_COMMON_HOME\common\bin
JAVA_HOME
CLASSPATH
Environment Variable
Value
ORACLE_HOME\lib:MW_HOME\jdkn\lib
TEMP
TMP
Memory Tab
Select the check-box to Enable Automatic Memory Management
Drag the bar to allocate the memory. This will automatically allocate memory size
for SGA and PGA depending on the total database memory allocated.
Character Sets Tab. Following three character set options are given in this tab.
Use the default
Use Unicode (AL32UTF8)
Choose from the list of character sets. Select Database Character Set as Unicode
standard UTF-8AL32UTF8 Select this option.
Security Tab Just leave the defaults in this tab.