TopNotchInfo

Kumars

Oracle DBA

1. 1.1. 1.2. 1.3. 1.4.

Database and DBMS Basics ________________________________________________ 5 Database concept _______________________________________________________ 5 Evolution of database and DBMS technology _________________________________ 6 Purpose of Database Systems ______________________________________________ 7 Major database usage requirements ________________________________________ 8

1.4.1. Database Types ________________________________________________________ 11 1.5. 1.6. 1.7. 1.8. Database Models _______________________________________________________ 11 Types of people involved _________________________________________________ 19 Database languages ____________________________________________________ 19 Normalization _________________________________________________________ 21

1.8.1. Objectives of normalization ______________________________________________ 21 1.8.2. Background to normalization: definitions ___________________________________ 22 1.8.3. Normal forms __________________________________________________________ 23 1.8.4. Normalization Example __________________________________________________ 25 1.8.5. Denormalization _______________________________________________________ 32 1.9. ACID Properties ________________________________________________________ 33

1.10. Database design _______________________________________________________ 35 2. 2.1. 2.2. 2.3. 2.4. 2.5. Oracle Basics __________________________________________________________ 37 Oracle History _________________________________________________________ 37 Competitors ___________________________________________________________ 40 Oracle Versions Recent Highlights ________________________________________ 40 Database Objects _______________________________________________________ 47 Data Dictionary ________________________________________________________ 54

2.5.1. Structure of the Data Dictionary ___________________________________________ 54 2.5.2. SYS, Owner of the Data Dictionary _________________________________________ 55 2.5.3. How the Data Dictionary Is Used __________________________________________ 55 2.5.4. How Oracle Database Uses the Data Dictionary ______________________________ 55 2.5.5. Public Synonyms for Data Dictionary Views __________________________________ 55

2.5.6. Cache the Data Dictionary for Fast Access ___________________________________ 56 2.5.7. Other Programs and the Data Dictionary ____________________________________ 56 2.5.8. How to Use the Data Dictionary ___________________________________________ 56 2.5.9. Catalog Views / Data Dictionary Views _____________________________________ 59 2.5.10. 2.6. System Packages ___________________________________________________ 59

Oracle - Export and Import Methods _______________________________________ 60

2.6.1. Native Methods ________________________________________________________ 60 2.6.2. Data-Pump Methods ____________________________________________________ 68 2.6.3. When to Use Data Pump Export/Import Vs Original Export/Import _______________ 79 2.6.4. Changing from Original Export/Import to Oracle Data Pump ____________________ 80 3. 3.1. 3.2. 3.3. 4. 4.1. 4.2. 4.3. Introduction to Oracle DBA _______________________________________________ 87 Whos DBA? ___________________________________________________________ 87 Why a Company needs a DBA _____________________________________________ 88 Roles & Responsibilities of DBA ___________________________________________ 90 Oracle Architecture _____________________________________________________ 94 Primary Architecture Components _________________________________________ 94 Physical Structure Database Files ________________________________________ 97 Memory Structures _____________________________________________________ 98

4.3.1. System Global Area _____________________________________________________ 98 4.3.2. Program Global Area ___________________________________________________ 100 4.3.3. User Global Area ______________________________________________________ 102 4.4. Processes ____________________________________________________________ 112

4.4.1. Client Process: ________________________________________________________ 112 4.4.2. Server Process ________________________________________________________ 113 4.4.3. Background Processes __________________________________________________ 113 4.5. 4.6. 5. Logical Structure ______________________________________________________ 120 SQL Statement Processing _______________________________________________ 122 Oracle Shared Server ___________________________________________________ 123

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.

Understand when to use Oracle Shared Servers _____________________________ 123 Configuring the Oracle Shared Server ______________________________________ 124 Dedicated Servers Vs Shared Servers ______________________________________ 126 Monitoring Shared Servers ______________________________________________ 131 Installation and Configuration of Oracle Database ___________________________ 132 System Requirements __________________________________________________ 132 Environment Variables _________________________________________________ 132 Installation using OUI __________________________________________________ 134 Silent Installation ______________________________________________________ 143 Using DBCA __________________________________________________________ 143 Optimal Flexible Architecture ____________________________________________ 143 Authentication Methods ________________________________________________ 143 Database Startup modes ________________________________________________ 143 PFile vs SPFile _________________________________________________________ 143

6.10. Oracle Managed Files __________________________________________________ 143

1. Database and DBMS Basics

A database is an organized collection of data. The data is typically organized to model relevant aspects of reality (for example, the availability of rooms in hotels), in a way that supports processes requiring this information (for example, finding a hotel with vacancies). The term database is correctly applied to the data and their supporting data structures, and not to the database management system (DBMS). The database data collection with DBMS is called a database system. The term database system implies that the data is managed to some level of quality (measured in terms of accuracy, availability, usability, and resilience) and this in turn often implies the use of a general-purpose database management system (DBMS). A general-purpose DBMS is typically a complex software system that meets many usage requirements to properly maintain its databases which are often large and complex. The utilization of databases is now so widespread that virtually every technology and product relies on databases and DBMSs for its development and commercialization, or even may have DBMS software embedded in it. Also, organizations and companies, from small to large, depend heavily on databases for their operations. Well known DBMSs include Oracle, IBM DB2, Microsoft SQL Server, Microsoft Access, PostgreSQL, MySQL, and SQLite. A database is not generally portable across different DBMS, but different DBMSs can inter-operate to some degree by using standards like SQL and ODBC together to support a single application built over more than one database. A DBMS also needs to provide effective run-time execution to properly support (e.g., in terms of performance, availability, and security) as many database end-users as needed. A way to classify databases involves the type of their contents, for example: bibliographic, document-text, statistical, or multimedia objects. Another way is by their application area, for example: accounting, music compositions, movies, banking, manufacturing, or insurance. The term database may be narrowed to specify particular aspects of organized collection of data and may refer to the logical database, to the physical database as data content in computer data storage or to many other database sub-definitions.

1.1. Database concept

The database concept has evolved since the 1960s to ease increasing difficulties in designing, building, and maintaining complex information systems (typically with many concurrent end-users, and with a large amount of diverse data). It has evolved together with database management systems which enable the effective handling of databases. Though the terms database and DBMS define different entities, they are inseparable: a database's properties are determined by its supporting DBMS. The Oxford English dictionary cites a 1962 technical report as the first to use the term "data-base." With the progress in technology in the areas of processors, computer memory, computer storage and computer networks, the sizes, capabilities, and performance of databases and

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.

1.2. Evolution of database and DBMS technology

The introduction of the term database coincided with the availability of direct-access storage (disks and drums) from the mid-1960s onwards. The term represented a contrast with the tape-based systems of the past, allowing shared interactive use rather than daily batch processing. In the earliest database systems, efficiency was perhaps the primary concern, but it was already recognized that there were other important objectives. One of the key aims was to make the data independent of the logic of application programs, so that the same data could be made available to different applications. The first generation of database systems were navigational,[2] applications typically accessed data by following pointers from one record to another. The two main data models at this time were the hierarchical model, epitomized by IBM's IMS system, and the Codasyl model (Network model), implemented in a number of products such as IDMS. The relational model, first proposed in 1970 by Edgar F. Codd, departed from this tradition by insisting that applications should search for data by content, rather than by following links. This was considered necessary to allow the content of the database to evolve without constant rewriting of applications. Relational systems placed heavy demands on processing resources, and it was not until the mid 1980s that computing hardware became powerful enough to allow them to be widely deployed. By the early 1990s, however, relational systems were dominant for all large-scale data processing applications, and they remain dominant today (2012) except in niche areas. The dominant database language is the standard SQL for the Relational model, which has influenced database languages also for other data models. Because the relational model emphasizes search rather than navigation, it does not make relationships between different entities explicit in the form of pointers, but represents those rather using primary keys and foreign keys. While this is a good basis for a query language, it is less well

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.

1.3. Purpose of Database Systems

1. To see why database management systems are necessary, let's look at a typical file-processing system'' supported by a conventional operating system. The application is a savings bank: 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.
o o

Data in different formats. Difficult to write new application programs. Multiple users Want concurrency for faster response time. Need protection for concurrent updates. E.g. two customers withdrawing funds from the same account at the same time account has $500 in it, and they withdraw $100 and $50. The result could be $350, $400 or $450 if no protection. Security problems Every user of the system should be able to access only the data they are permitted to see. E.g. payroll people only handle employee records, and cannot see customer accounts; tellers only access account data and cannot see payroll data. Difficult to enforce this with application programs. Integrity problems Data may be required to satisfy constraints. E.g. no account balance below $25.00. Again, difficult to enforce or to change constraints with the file-processing approach.

These problems and others led to the development of database management systems.

1.4. Major database usage requirements

The major purpose of a database is to provide the information system (in its broadest sense) that utilizes it with the information the system needs according to its own requirements. A certain broad set of requirements refines this general goal. These database requirements translate to requirements for the respective DBMS, to allow conveniently building a proper database for the given application. If this goal is met by a DBMS, then the designers and builders of the specific database can concentrate on the application's aspects, and not deal with building and maintaining the underlying DBMS. Also, since a DBMS is complex and expensive to build and maintain, it is not economical to build such a new tool (DBMS) for every application. Rather it is desired to provide a flexible tool for handling databases for as many as possible given applications, i.e., a generalpurpose DBMS. Functional requirements Certain general functional requirements need to be met in conjunction with a database. They describe what is needed to be defined in a database for any specific application. Defining the structure of data: Data modeling and Data definition languages The database needs to be based on a data model that is sufficiently rich to describe in the database all the needed respective application's aspects. A data definition language exists to describe the databases within the data model. Such language is typically data model specific.

Manipulating the data: Data manipulation languages and Query languages A database data model needs support by a sufficiently rich data manipulation language to allow all database manipulations and information generation (from the data) as needed by the respective application. Such language is typically data model specific. Protecting the data: Setting database security types and levels The DB needs built-in security means to protect its content (and users) from dangers of unauthorized users (either humans or programs). Protection is also provided from types of unintentional breach. Security types and levels should be defined by the database owners. Describing processes that use the data: Workflow and Business process modeling Manipulating database data often involves processes of several interdependent steps, at different times (e.g., when different people's interactions are involved; e.g., generating an insurance policy). Data manipulation languages are typically intended to describe what is needed in a single such step. Dealing with multiple steps typically requires writing quite complex programs. Most applications are programmed using common programming languages and software development tools. However the area of process description has evolved in the frameworks of workflow and business processes with supporting languages and software packages which considerably simplify the tasks. Traditionally these frameworks have been out of the scope of common DBMSs, but utilization of them has become common-place, and often they are provided as add-on's to DBMSs. Operational requirements Operational requirements are needed to be met by a database in order to effectively support an application when operational. Though it typically may be expected that operational requirements are automatically met by a DBMS, in fact it is not so in most of the cases: To be met substantial work of design and tuning is typically needed by database administrators. This is typically done by specific instructions/operations through special database user interfaces and tools, and thus may be viewed as secondary functional requirements (which are not less important than the primary). Availability A DB should maintain needed levels of availability, i.e., the DB needs to be available in a way that a user's action does not need to wait beyond a certain time range before starting executing upon the DB. Availability also relates to failure and recovery from it (see Recovery from failure and disaster below): Upon failure and during recovery normal availability changes, and special measures are needed to satisfy availability requirements. Performance Users' actions upon the DB should be executed within needed time ranges. Isolation between users

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.

1.5. Database Models

Besides differentiating databases according to function, databases can also be differentiated according to how they model the data. What is a data model? Well, essentially a data model is a "description" of both a container for data and a methodology for storing and retrieving data from that container. Actually, there isn't really a data model "thing". Data models are abstractions, oftentimes mathematical algorithms and concepts. You cannot really touch a data model. But nevertheless, they are very useful. The analysis and design of data models has been the cornerstone of the evolution of databases. As models have advanced so has database efficiency.

Early data models These models were popular in the 1960s, 1970s, but nowadays can be found primarily in old legacy systems. They are characterized primarily by being navigational with strong connections between their logical and physical representations, and deficiencies in data independence. Flat-File The flat-file style of database are ideal for small amounts of data that needs to be human readable or edited by hand. Essentially all they are made up of is a set of strings in one or more files that can be parsed to get the information they store; great for storing simple lists and data values, but can get complicated when you try to replicate more complex data structures. That's not to say that it is impossible to store complex data in a flat-file database; just that doing so can be more costly in time and processing power compared to a relational database. The methods used for storing the more complex data types, are also likely to render the file unreadable and un-editable to anyone looking after the database. The typical flat-file database is split up using a common delimiter. If the data is simple enough, this could be a comma, but more complex strings are usually split up using tabs, new lines or a combination of characters not likely to be found in the record itself. One of the main problems with using flat files for even a semi-active database is the fact that it is very prone to corruption. There is no inherent locking mechanism that detects when a file is being used or modified, and so this has to be done on the script level. Even if care is taken to lock and unlock the file on each access, a busy script can cause a "race condition" and it is possible for a file to be wiped clean by two or more processes that are fighting for the lock; the timing of your file locks will become more and more important as a site gets busy. Before the 1980's, the two most commonly used Database Models were the hierarchical and network systems. Let's take a quick look at these two models and then move on to the more current models. Hierarchical model In the Hierarchical model different record types (representing real-world entities) are embedded in a predefined hierarchical (tree-like) structure. This hierarchy is used as the physical order of records in storage. Record access is done by navigating through the data structure using pointers combined with sequential accessing. This model has been supported primarily by the IBM IMS DBMS, one of the earliest DBMSs. Various limitations of the model have been compensated at later IMS versions by additional logical hierarchies imposed on the base physical hierarchy. As its name implies, the Hierarchical Database Model defines hierarchically-arranged data.

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 Mr. Eric Tachibana Mr. Eric Tachibana Mr. Eric Tachibana Mr. Eric Tachibana Ms. Tonya Lippert Ms. Tonya Lippert Ms. Tonya Lippert Address Course Grade C+ A B A A A A

123 Kensigton Chemistry 102 123 Kensigton Chinese 3 122 Kensigton Data Structures 123 Kensigton English 101 88 West 1st St. Psychology 101 88 West 1st St. Human Cultures

Mrs. Tonya Ducovney 100 Capitol Ln. Psychology 102

88 West 1st St. European Governments A

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.

Inverted file model An inverted file or inverted index of a first file, by a field in this file (the inversion field), is a second file in which this field is the key. A record in the second file includes a key and pointers to records in the first file where the inversion field has the value of the key. This is also the logical structure of contemporary database indexes. The related Inverted file data model utilizes inverted files of primary database files to efficiently directly access needed records in these files. Notable for using this data model is the ADABAS DBMS of Software AG, introduced in 1970. ADABAS has gained 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. Relational model The relational model is a simple model that provides flexibility. It organizes data based on twodimensional arrays known as relations, or tables as related to databases. These relations consist of a heading and a set of zero or more tuples in arbitrary order. The heading is an unordered set of zero or more attributes, or columns of the table. The tuples are a set of unique attributes mapped to values, or the rows of data in the table. Data can be associated across multiple tables with a key. A key is a single, or set of multiple, attribute(s) that is common to both tables. The most common language associated with the relational model is the Structured Query Language (SQL), though it differs in some places. Of course in the 80's the "Relational Database Model" became the rage. The Relational Model developed out of the work done by Dr. E. F. Codd at IBM in the late 1960s who was looking for ways to solve the problems with the existing models. Because he was a mathematician, he naturally built the model on mathematical concepts which he expounded in the famous work called "A Relational Model of Data for Large Shared Databanks". At the core of the relational model is the concept of a table (also called a relation) in which all data is stored. Each table is made up of records (horizontal rows also known as tuples) and fields (vertical columns also known as attributes). It is important to note that how or where the tables of data are stored makes no difference. Each table can be identified by a unique name and that name can be used by the database to find the table behind the scenes. As a user, all you need to know is the table name in order to use it. You do not need to worry about the complexities of how the data is stored on the hard drive. This is quite a bit different from the hierarchical and network models in which the user had to have an understanding of how the data was structured within the database in order to retrieve, insert, update, or delete records from the database.

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 Selena Smith SID-001 213-456-7890 SID-991 310-234-6475

Selena Roberts SID-268 818-934-5069 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.

1.6. Types of people involved

Three types of people are involved with a general-purpose DBMS: 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.7. Database languages

Database languages are dedicated programming languages, tailored and utilized to define a database (i.e., its specific data types and the relationships among them), manipulate its content (e.g., insert new data occurrences, and update or delete existing ones), and query it (i.e., request information: compute and retrieve any information based on its data). Database languages are data-model-specific, i.e., each language assumes and is based on a certain structure of the data (which typically differs among different data models). They typically have commands to instruct execution of the desired operations in the database. Each such command is equivalent to a complex expression (program) in a regular programming language, and thus programming in dedicated (database) languages simplifies the task of handling databases considerably. An expression in a database language is automatically transformed (by a compiler or interpreter, as regular programming languages) to a proper computer program that runs while accessing the database and providing the needed results. The following are notable examples:

SQL for the Relational model A major Relational model language supported by all the relational DBMSs and a standard. SQL was one of the first commercial languages for the relational model. Despite not adhering to the relational model as described by Codd, it has become the most widely used database language.[10][11] Though often described as, and to a great extent is a declarative language, SQL also includes procedural elements. SQL became a standard of the American National Standards Institute (ANSI) in 1986, and of the International Organization for Standards (ISO) in 1987. Since then the standard has been enhanced several times with added features. However, issues of SQL code portability between major RDBMS products still exist due to lack of full compliance with, or different interpretations of the standard. Among the reasons mentioned are the large size, and incomplete specification of the standard, as well as vendor lock-in. OQL for the Object model An object model language standard (by the Object Data Management Group) that has influenced the design of some of the newer query languages like JDOQL and EJB QL, though they cannot be considered as different flavors of OQL. XQuery for the XML model XQuery is an XML based database language (also named XQL). SQL/XML combines XQuery and XML with SQL.

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.

Background to normalization: definitions

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:

functionally dependent on X, and 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.

Normal form Defined by Two versions: E.F. Codd(1970), C.J. Date (2003)

In

Brief definition

1NF

First normal form

1970 [1] and Table faithfully represents a relation and has 2003 [9] no repeating groups No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key

2NF

Second normal form

E.F. Codd

1971

[2]

3NF

Third normal form

Two versions: E.F. Codd(1971), C. Zaniolo (1982)

Every non-prime attribute is non-transitively dependent on every candidate key in the table. [2] 1971 and The attributes that do not contribute to the description of the primary key are removed 1982 [10] from the table. In other words, no transitivity dependency is allowed. Every non-trivial functional dependency in the table is either the dependency of an elementary key attribute or a dependency on a superkey Every non-trivial functional dependency in the table is a dependency on a superkey Every non-trivial multivalued dependency in the table is a dependency on a superkey Every non-trivial join dependency in the table is implied by the superkeys of the table Every constraint on the table is a logical consequence of the table's domain constraints and key constraints Table features no non-trivial join dependencies at all (with reference to generalized join operator)

Elementary EKNF Key Normal Form

C. Zaniolo

1982 [10]

BCNF

BoyceCodd normal form Fourth normal form Fifth normal form

Raymond F. 1974 [11] Boyce and E.F. Codd 1977 [12]

4NF

Ronald Fagin

5NF

Ronald Fagin

1979 [13]

Domain/key DKNF normal form

Ronald Fagin

1981

[14]

6NF

Sixth normal form

C.J. Date, Hugh Darwen, andNikos Lorentzos

2002

[15]

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.) Identify a key for the table (and underline it).

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.

UNF: unnormalised table

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:

Identify repeating attributes. 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.

1NF Tables: Repeating Attributes Removed Project Code PC010 PC045 PC064 Project Title Pensions System Salaries System HR System Project Manager M Phillips H Martin K Lewis Project Budget 24500 17400 12250

Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 PC064 PC064 PC064

Employee No. Employee Name Department No. Department Name Hourly Rate S10001 S10030 S21010 S10010 S10001 S31002 S13210 S31002 S21010 S10034 A Smith L Jones P Lewis B Jones A Smith T Gilbert W Richards T Gilbert P Lewis B James L004 L023 L004 L004 L004 L028 L008 L028 L004 L009 IT Pensions IT IT IT Database Salary Database IT HR 22.00 18.50 21.00 21.75 18.00 25.50 17.00 23.25 17.50 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.

2NF Tables: Partial Key Dependencies Removed Project Code PC010 PC045 PC064 Project Title Pensions System Salaries System HR System Project Manager M Phillips H Martin K Lewis Project Budget 24500 17400 12250

Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 PC064 PC064 PC064

Employee No. S10001 S10030 S21010 S10010 S10001 S31002 S13210 S31002 S21010 S10034

Hourly Rate 22.00 18.50 21.00 21.75 18.00 25.50 17.00 23.25 17.50 16.50

Employee No. S10001 S10030 S21010 S10010 S31002 S13210 S10034

Employee Name A Smith L Jones P Lewis B Jones T Gilbert W Richards B James

Department No. L004 L023 L004 L004 L028 L008 L009

Department Name IT Pensions IT IT Database Salary HR

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.

Department Name is more dependent upon Department No than Employee No and therefore was moved to a new table. Department No is the key in this new table and a foreign key in the Employee table.

3NF Tables: Non-Key Dependencies Removed Project Code PC010 PC045 PC064 Project Title Pensions System Salaries System HR System Project Manager M Phillips H Martin K Lewis Project Budget 24500 17400 12250

Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 064 PC064 PC064

Employee No. S10001 S10030 S21010 S10010 S10001 S31002 S13210 S31002 S21010 S10034

Hourly Rate 22.00 18.50 21.00 21.75 18.00 25.50 17.00 23.25 17.50 16.50

Employee No. S10001 S10030 S21010 S10010 S31002 S13210 S10034

Employee Name A Smith L Jones P Lewis B Jones T Gilbert W Richards B James

Department No. * L004 L023 L004 L004 L023 L008 L0009

Department No. L004 L023 L028 L008

Department Name IT Pensions Database Salary

L009

HR

Summary of Normalization Rules That is the complete process. Having started off with an unnormalised table we finished with four normalized tables in 3NF. You will notice that duplication has been removed (apart from the keys needed to establish the links between those tables). The process may look complicated. However, if you follow the rules completely, and do not miss out any steps, then you should arrive at the correct solution. If you omit a rule there is a high probability that you will end up with too few tables or incorrect keys. The following normal forms were discussed in this section: 1. First normal form: A table is in the first normal form if it contains no repeating columns. 2. Second normal form: A table is in the second normal form if it is in the first normal form and contains only columns that are dependent on the whole (primary) key. 3. Third normal form: A table is in the third normal form if it is in the second normal form and all the non-key columns are dependent only on the primary key. If the value of a non-key column is dependent on the value of another non-key column we have a situation known as transitive dependency. This can be resolved by removing the columns dependent on nonkey items to another table. 4. Fourth Form : also called Boyce Codd Normal Form (BCNF) In many-to-many relationships, independent entities cannot be stored in the same table. A relation is in 4NF if it has no multi-valued dependencies. Occasionally, it becomes necessary to stray from them to meet practical business requirements. However, when variations take place, it's extremely important to evaluate any possible ramifications they could have on your system and account for possible inconsistencies. 5. Fifth Form: The very esoteric one that is probably not required to get the most out of your database. The original table must be reconstructed from the tables into which it has been broken down. The rule ensures that you have not created any extraneous columns and all the tables are only as large as they need to be. The rule does exist, but are rarely considered in practical

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 Bob Jane Jane Jane

Blue Red Green Yellow 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.

1.9. ACID Properties

The ACID model is one of the oldest and most important concepts of database theory. It sets forward four goals that every database management system must strive to achieve: atomicity, consistency, isolation and durability. No database that fails to meet any of these four goals can be considered reliable. Lets take a moment to examine each one of these characteristics in detail:

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:

Determine the relationships between the different data elements. Superimpose a logical structure upon the data on the basis of these relationships.

ER Diagram (Entity-relationship model)

A sample Entity-relationship diagram

Database designs also include ER (Entity-relationship model) diagrams. An ER diagram is a diagram that helps to design databases in an efficient way. Attributes in ER diagrams are usually modeled as an oval with the name of the attribute, linked to the entity or relationship that contains the attribute. Within the relational model the final step can generally be broken down into two further steps, that of determining the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information, or objects. This step is not necessary with an Object database.[2] The Design Process 1. Determine the purpose of the database - This helps prepare for the remaining steps. 2. Find and organize the information required - Gather all of the types of information to record in the database, such as product name and order number. 3. Divide the information into tables - Divide information items into major entities or subjects, such as Products or Orders. Each subject then becomes a table. 4. Turn information items into columns - Decide what information needs to stored in each table. Each item becomes a field, and is displayed as a column in the table. For example, an Employees table might include fields such as Last Name and Hire Date. 5. Specify primary keys - Choose each tables primary key. The primary key is a column that is used to uniquely identify each row. An example might be Product ID or Order ID. 6. Set up the table relationships - Look at each table and decide how the data in one table is related to the data in other tables. Add fields to tables or create new tables to clarify the relationships, as necessary. 7. Refine the design - Analyze the design for errors. Create tables and add a few records of sample data. Check if results come from the tables as expected. Make adjustments to the design, as needed. 8. Apply the normalization rules - Apply the data normalization rules to see if tables are structured correctly. Make adjustments to the tables

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; Virtual Column Partitioning; Case sensitive passwords; Online Patching; Parallel Backups on same file using RMAN and many others.

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

2.3.Oracle Versions Recent Highlights 8i Highlights

AutoNumber And Identity Functionality - Implement AutoNumber or Identity column behaviour in Oracle.

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.

11g new features

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 Schema Objects Explained

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.

o Stored procedures and packages

A procedure is a PL/SQL block alike the functions of the 3rd generation languages. You just have to compile them so as to use them later. When a procedure is created, it is compiled and stored in the database in the compiled form. Parameters can be passed to a procedure. A procedure call is a PL/SQL statement by itself. A procedure is a PL/SQL block with a declarative section, an executable section and an exception handling section. o

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 User-defined data types

User defined data types are PL/SQL types that are based on the existing types. Subtypes are used to gives an alternate name to for a type. Eg: declare subtype counter is number; counter a;

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

Schema Object Names and Qualifiers Some schema objects are made up of parts that you can or must name, such as the columns in a table or view, index and table partitions and sub-partitions, integrity constraints on a table, and objects that are stored within a package, including procedures and stored functions. This section provides:

Rules for naming schema objects and schema object location qualifiers Guidelines for naming schema objects and qualifiers

Schema Object Naming Rules Every database object has a name. In a SQL statement, you represent the name of an object with a quoted identifier or a nonquoted identifier.

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. A nonquoted identifier is not surrounded by any punctuation.

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:

Names of databases are limited to 8 bytes. Names of database links can be as long as 128 bytes.

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

Each of the following schema objects has its own namespace:

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 Public database links Tablespaces Profiles Parameter files (PFILEs) and server parameter files (SPFILEs) Because the objects in these namespaces are not contained in schemas, these namespaces span the entire database. Nonquoted identifiers are not case sensitive. Oracle interprets them as uppercase. Quoted identifiers are case sensitive.

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.

2.5.1. Structure of the Data Dictionary

The data dictionary consists of the following: Base Tables: The underlying tables that store information about the associated database. Only Oracle Database should write to and read these tables. Users rarely access them directly because they are normalized, and most of the data is stored in a cryptic format. User-Accessible Views: The views that summarize and display the information stored in the base tables of the data dictionary. These views decode the base table data into useful information, such as user or table names, using joins and WHERE clauses to simplify the information. Most users are given access to the views rather than the base tables.

2.5.2. SYS, Owner of the Data Dictionary

The Oracle Database user SYS owns all base tables and user-accessible views of the data dictionary. No Oracle Database user should ever alter (UPDATE,DELETE, or INSERT) any rows or schema objects contained in the SYS schema, because such activity can compromise data integrity. The security administrator must keep strict control of this central account. Caution: Altering or manipulating the data in data dictionary tables can permanently and detrimentally affect the operation of a database.

2.5.3. How the Data Dictionary Is Used

The data dictionary has three primary uses: Oracle Database accesses the data dictionary to find information about users, schema objects, and storage structures. Oracle Database modifies the data dictionary every time that a data definition language (DDL) statement is issued. Any Oracle Database user can use the data dictionary as a read-only reference for information about the database.

2.5.4. How Oracle Database Uses the Data Dictionary

Data in the base tables of the data dictionary is necessary for Oracle Database to function. Therefore, only Oracle Database should write or change data dictionary information. Oracle Database provides scripts to modify the data dictionary tables when a database is upgraded or downgraded. Caution: No data in any data dictionary table should be altered or deleted by any user. During database operation, Oracle Database reads the data dictionary to ascertain that schema objects exist and that users have proper access to them. Oracle Database also updates the data dictionary continuously to reflect changes in database structures, auditing, grants, and data. For example, if user Kathy creates a table named parts, then new rows are added to the data dictionary that reflect the new table, columns, segment, extents, and the privileges that Kathy has on the table. This new information is then visible the next time the dictionary views are queried.

2.5.5. Public Synonyms for Data Dictionary Views

Oracle Database creates public synonyms for many data dictionary views so users can access them conveniently. The security administrator can also create additional public synonyms for schema

objects that are used systemwide. Users should avoid naming their own schema objects with the same names as those used for public synonyms.

2.5.6. Cache the Data Dictionary for Fast Access

Much of the data dictionary information is kept in the SGA in the dictionary cache, because Oracle Database constantly accesses the data dictionary during database operation to validate user access and to verify the state of schema objects. All information is stored in memory using the least recently used (LRU) algorithm. Parsing information is typically kept in the caches. The COMMENTS columns describing the tables and their columns are not cached unless they are accessed frequently.

2.5.7. Other Programs and the Data Dictionary

Other Oracle Database products can reference existing views and create additional data dictionary tables or views of their own. Application developers who write programs that refer to the data dictionary should refer to the public synonyms rather than the underlying tables: the synonyms are less likely to change between software releases.

2.5.8. How to Use the Data Dictionary

The views of the data dictionary serve as a reference for all database users. Access the data dictionary views with SQL statements. Some views are accessible to all Oracle Database users, and others are intended for database administrators only. The data dictionary is always available when the database is open. It resides in the SYSTEM tablespace, which is always online. The data dictionary consists of sets of views. In many cases, a set consists of three views containing similar information and distinguished from each other by their prefixes, as shown in Table below Table: Data Dictionary View Prefixes Prefix USER ALL DBA Scope User's view (what is in the user's schema) Expanded user's view (what the user can access) Database administrator's view (what is in all users' schemas)

The set of columns is identical across views, with these exceptions: 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. Views with the Prefix USER The views most likely to be of interest to typical database users are those with the prefix USER. These views:

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; Views with the Prefix ALL Views with the prefix ALL refer to the user's overall perspective of the database. These views return information about schema objects to which the user has access through public or explicit grants of privileges and roles, in addition to schema objects that the user owns. For example, the following query returns information about all the objects to which you have access: SELECT owner, object_name, object_type FROM ALL_OBJECTS; Views with the Prefix DBA Views with the prefix DBA show a global view of the entire database. Synonyms are not created for these views, because DBA views should be queried only by administrators. Therefore, to query the DBA views, administrators must prefix the view name with its owner, SYS, as in the following: SELECT owner, object_name, object_type FROM SYS.DBA_OBJECTS; Oracle recommends that you implement data dictionary protection to prevent users having the ANY system privileges from using such privileges on the data dictionary. If you enable dictionary protection (O7_DICTIONARY_ACCESSIBILITY is false), then access to objects in the SYS schema (dictionary objects) is restricted to users with the SYS schema. These users are SYS and those who connect as SYSDBA. The DUAL Table

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. Dynamic Performance Tables Throughout its operation, Oracle Database maintains a set of virtual tables that record current database activity. These tables are called dynamic performance tables. Dynamic performance tables are not true tables, and they should not be accessed by most users. However, database administrators can query and create views on the tables and grant access to those views to other users. These views are sometimes called fixed views because they cannot be altered or removed by the database administrator. SYS owns the dynamic performance tables; their names all begin with V_$. Views are created on these tables, and then public synonyms are created for the views. The synonym names begin with V$. For example, the V$DATAFILE view contains information about the database's datafiles, and the V$FIXED_TABLEview contains information about all of the dynamic performance tables and views in the database. Database Object Metadata The DBMS_METADATA package provides interfaces for extracting complete definitions of database objects. The definitions can be expressed either as XML or as SQL DDL. Two styles of interface are provided:

A flexible, sophisticated interface for programmatic control A simplified interface for ad hoc querying

2.5.9. Catalog Views / Data Dictionary Views

The data dictionary views, also known as catalog views, let you monitor the state of the database in real time:

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.

Shortcuts to View Names If you know the name of the view you want, select its abbreviation. Otherwise, scroll down to see the entire list.
ALL AUD CAT CHA CLU COL DAT DBA DBM DEP DIC ERR EXC FLA GLO HS_ IDE IND MAP NLS OBJ PLA PLU PRO PST PUB QUE REC RES ROL SEQ SES SOU STM SYN SYS TAB TRU TS_ UNI USE V$A V$B V$C V$D V$E V$F V$G V$H V$I V$J V$L V$M V$N V$O V$P V$Q V$R V$S V$T V$U V$V V$W V$X

List of Data Dictionary Views (A-Z) Refer Appendix 1

APPENDIX 1.docx

2.5.10.

System Packages
Oracle List of Supplied packages is in Appendix 2 below:

APPENDIX 2.docx

2.6.

Oracle - Export and Import Methods

These tools are used to transfer data from one oracle database to another oracle database. You Export tool to export data from source database, and Import tool to load data into the target database. When you export tables from source database export tool will extracts the tables and puts it into the dump file. This dump file is transferred to the target database. At the target database the Import tool will copy the data from dump file to the target database. From Ver. 10g Oracle is recommending to use Data Pump Export and Import tools, which are enhanced versions of original Export and Import tools.

2.6.1. Native Methods

The export dump file contains objects in the following order: 1. 2. 3. 4. 5. 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 Invoking Export and Import You can run Export and Import tool in two modes Command Line Mode Interactive Mode

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

Command Line Parameters of Export tool You can control how Export runs by entering the EXP command followed by various arguments. To specify parameters, you use keywords: Format: EXP KEYWORD=value or KEYWORD=(value1,value2,...,valueN) Example: EXP SCOTT/TIGER GRANTS=Y TABLES=(EMP,DEPT,MGR) or TABLES=(T1:P1,T1:P2), if T1 is partitioned table Keyword USERID BUFFER FILE COMPRESS GRANTS INDEXES DIRECT LOG ROWS CONSISTENT FULL OWNER TABLES RECORDLENGTH INCTYPE RECORD TRIGGERS STATISTICS PARFILE Description (Default) username/password size of data buffer output files (EXPDAT.DMP) import into one extent (Y) export grants (Y) export indexes (Y) direct path (N) log file of screen output export data rows (Y) cross-table consistency(N) export entire file (N) list of owner usernames list of table names length of IO record incremental export type track incr. export (Y) export triggers (Y) analyze objects (ESTIMATE) parameter filename

CONSTRAINTS OBJECT_CONSISTENT FEEDBACK FILESIZE FLASHBACK_SCN FLASHBACK_TIME QUERY RESUMABLE RESUMABLE_NAME RESUMABLE_TIMEOUT TTS_FULL_CHECK TABLESPACES TRANSPORT_TABLESPACE TEMPLATE

export constraints (Y) transaction set to read only during object export (N) display progress every x rows (0) maximum size of each dump file SCN used to set session snapshot back to time used to get the SCN closest to the specified time select clause used to export a subset of a table suspend when a space related error is encountered(N) text string used to identify resumable statement wait time for RESUMABLE perform full or partial dependency check for TTS list of tablespaces to export export transportable tablespace metadata (N) template name which invokes iAS mode export

The Export and Import tools support four modes of operation FULL OWNER TABLES TABLESPACE Exports all the objects in all schemas Exports objects only belonging to the given OWNER Exports Individual Tables Export all objects located in a given TABLESPACE

Example of Exporting Full Database The following example shows how to export full database $exp USERID=scott/tiger FULL=y FILE=myfull.dmp In the above command, FILE option specifies the name of the dump file, FULL option specifies that you want to export the full database, USERID option specifies the user account to connect to the database. Note, to perform full export the user should have DBA or EXP_FULL_DATABASE privilege.

Example of Exporting Schemas To export Objects stored in a particular schemas you can run export utility with the following arguments $exp USERID=scott/tiger OWNER=(SCOTT,ALI) FILE=exp_own.dmp The above command will export all the objects stored in SCOTT and ALIs schema.

Exporting Individual Tables To export individual tables give the following command $exp USERID=scott/tiger TABLES=(scott.emp,scott.sales) FILE=exp_tab.dmp This will export scotts emp and sales tables.

Exporting Consistent Image of the tables If you include CONSISTENT=Y option in export command argument then, Export utility will export a consistent image of the table i.e. the changes which are done to the table during export operation will not be exported.

Using Import Utility Objects exported by export utility can only be imported by Import utility. Import utility can run in Interactive mode or command line mode. You can let Import prompt you for parameters by entering the IMP command followed by your username/password: Example: IMP SCOTT/TIGER Or, you can control how Import runs by entering the IMP command followed by various arguments. To specify parameters, you use keywords: Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN) Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N or TABLES=(T1:P1,T1:P2), if T1 is partitioned table

USERID must be the first parameter on the command line. Keyword USERID BUFFER FILE SHOW IGNORE GRANTS INDEXES ROWS LOG FULL FROMUSER TOUSER TABLES Description (Default) username/password size of data buffer input files (EXPDAT.DMP) just list file contents (N) ignore create errors (N) import grants (Y) import indexes (Y) import data rows (Y) log file of screen output import entire file (N) list of owner usernames list of usernames list of table names

Keyword RECORDLENGTH INCTYPE COMMIT PARFILE CONSTRAINTS DESTROY INDEXFILE SKIP_UNUSABLE_INDEXES FEEDBACK TOID_NOVALIDATE FILESIZE STATISTICS RESUMABLE RESUMABLE_NAME RESUMABLE_TIMEOUT COMPILE STREAMS_CONFIGURATION STREAMS_INSTANITATION

Description (Default) length of IO record incremental import type commit array insert (N) parameter filename import constraints (Y) overwrite tablespace data file (N) write table/index info to specified file skip maintenance of unusable indexes (N) display progress every x rows(0) skip validation of specified type ids maximum size of each dump file import precomputed statistics (always) suspend when a space related error is encountered(N) text string used to identify resumable statement wait time for RESUMABLE compile procedures, packages, and functions (Y) import streams general metadata (Y) import streams instantiation metadata (N)

Example Importing Individual Tables To import individual tables from a full database export dump file give the following command $imp scott/tiger FILE=myfullexp.dmp FROMUSER=scott TABLES=(emp,dept) This command will import only emp, dept tables into Scott user and you will get a output similar to as shown below Export file created by EXPORT:V10.00.00 via conventional path import done in WE8DEC character set and AL16UTF16 NCHAR character set . importing SCOTT's objects into SCOTT . . importing table . . importing table "DEPT" "EMP" 4 rows imported 14 rows imported

Import terminated successfully without warnings. 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. Example Importing Tables Using Pattern Matching Suppose you want to import all tables from a dump file whose name matches a particular pattern. To do so, use % wild character in TABLES option. For example, the following command will import all tables whose names starts with alphabet e and those tables whose name contains alphabet d $imp scott/tiger FILE=myfullexp.dmp FROMUSER=scott TABLES=(a%,%d%)

Migration a Database across platforms. The Export and Import utilities are the only method that Oracle supports for moving an existing Oracle database from one hardware platform to another. This includes moving between UNIX and NT systems and also moving between two NT systems running on different platforms. The following steps present a general overview of how to move a database between platforms. o 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; o 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. o Perform a full backup of your new database.

2.6.2. Data-Pump Methods

Oracle Data Pump is a newer, faster and more flexible alternative to the "exp" and "imp" utilities used in previous Oracle versions. In addition to basic import and export functionality data pump provides a PL/SQL API and support for external tables. Getting Started For the examples to work we must first unlock the SCOTT account and create a directory object it can access. The directory object is only a pointer to a physical directory, creating it does not actually create the physical directory on the file system of the database server.
CONN / AS SYSDBA ALTER USER scott IDENTIFIED BY tiger ACCOUNT UNLOCK; CREATE OR REPLACE DIRECTORY test_dir AS '/u01/app/oracle/oradata/'; GRANT READ, WRITE ON DIRECTORY test_dir TO scott;

Existing directories can be queried using the ALL_DIRECTORIES view. Note. Data Pump is a server-based technology, so it typically deals with directory objects pointing to physical directories on the database server. It does not write to the local file system on your client PC. Table Exports/Imports The TABLES parameter is used to specify the tables that are to be exported. The following is an example of the table export and import syntax.
expdp scott/tiger@db10g tables=EMP,DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=expdpEMP_DEPT.log impdp scott/tiger@db10g tables=EMP,DEPT directory=TEST_DIR dumpfile=EMP_DEPT.dmp logfile=impdpEMP_DEPT.log

For example output files see expdpEMP_DEPT.log and impdpEMP_DEPT.log. The TABLE_EXISTS_ACTION=APPEND parameter allows data to be imported into existing tables. Schema Exports/Imports The OWNER parameter of exp has been replaced by the SCHEMAS parameter which is used to specify the schemas to be exported. The following is an example of the schema export and import syntax.
expdp scott/tiger@db10g schemas=SCOTT directory=TEST_DIR dumpfile=SCOTT.dmp logfile=expdpSCOTT.log

impdp scott/tiger@db10g schemas=SCOTT directory=TEST_DIR dumpfile=SCOTT.dmp logfile=impdpSCOTT.log

For example output files see expdpSCOTT.log and impdpSCOTT.log.

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

For an example output file see expdpDB10G.log.

INCLUDE and EXCLUDE

The INCLUDE and EXCLUDE parameters can be used to limit the export/import to specific objects. When the INCLUDE parameter is used, only those objects specified by it will be included in the export/import. When the EXCLUDEparameter is used, all objects except those specified by it will be included in the export/import. The two parameters are mutually exclusive, so use the parameter that requires the least entries to give you the result you require. The basic syntax for both parameters is the same. INCLUDE=object_type[:name_clause] [, ...] EXCLUDE=object_type[:name_clause] [, ...]

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.

Network Exports/Imports (NETWORK_LINK)

The NETWORK_LINK parameter identifies a database link to be used as the source for a network export/import. The following database link will be used to demonstrate its use. CONN / AS SYSDBA GRANT CREATE DATABASE LINK TO test; CONN test/test CREATE DATABASE LINK remote_scott CONNECT TO scott IDENTIFIED BY tiger USING 'DEV'; In the case of exports, the NETWORK_LINK parameter identifies the database link pointing to the source server. The objects are exported from the source server in the normal manner, but written to a directory object on the local server, rather than one on the source server. Both the local and remote users require the EXP_FULL_DATABASE role granted to them. expdp test/test@db10g tables=SCOTT.EMP network_link=REMOTE_SCOTT directory=TEST_DIR dumpfile=EMP.dmp logfile=expdpEMP.log For imports, the NETWORK_LINK parameter also identifies the database link pointing to the source server. The difference here is the objects are imported directly from the source into the local server without being written to a dump file. Although there is no need for a DUMPFILE parameter, a directory object is still required for the logs associated with the operation. Both the local and remote users require the IMP_FULL_DATABASE role granted to them. impdp test/test@db10g tables=SCOTT.EMP network_link=REMOTE_SCOTT directory=TEST_DIR logfile=impdpSCOTT.log remap_schema=SCOTT:TEST

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

------------------------------ ---------- ---SYS_EXPORT_FULL_01 EXECUTING EXPORT 1

 Data Pump API

Along with the data pump utilities Oracle provide an PL/SQL API. The following is an example of how this API can be used to perform a schema export. SET SERVEROUTPUT ON SIZE 1000000 DECLARE l_dp_handle NUMBER; l_last_job_state VARCHAR2(30) := 'UNDEFINED'; l_job_state VARCHAR2(30) := 'UNDEFINED'; l_sts KU$_STATUS; BEGIN l_dp_handle := DBMS_DATAPUMP.open( operation => 'EXPORT', job_mode => 'SCHEMA', remote_link => NULL, job_name => 'EMP_EXPORT', version => 'LATEST'); DBMS_DATAPUMP.add_file( handle => l_dp_handle, filename => 'SCOTT.dmp', directory => 'TEST_DIR'); DBMS_DATAPUMP.add_file( handle => l_dp_handle, filename => 'SCOTT.log', directory => 'TEST_DIR', filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE); DBMS_DATAPUMP.metadata_filter( handle => l_dp_handle, name => 'SCHEMA_EXPR', value => '= ''SCOTT'''); DBMS_DATAPUMP.start_job(l_dp_handle); DBMS_DATAPUMP.detach(l_dp_handle); END; /

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.

CREATE TABLE emp_xt ORGANIZATION EXTERNAL ( TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY test_dir LOCATION ('emp_xt.dmp') ) AS SELECT * FROM emp;

The data can then be queried using the following. SELECT * FROM emp_xt;

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. All rights reserved.

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

Predicate clause used to export a subset of a table. List of schemas to export (login schema). Frequency (secs) job status is to be monitored where the default (0) will show new status when available. Identifies a list of tables to export - one schema Identifies a list of tablespaces to export. Verify storage segments of all tables (N). List of tablespaces from which metadata will be Version of objects to export where valid keywords are: (COMPATIBLE), LATEST, or any valid database version.

The following commands are valid while in interactive mode. Note: abbreviations are allowed Command Description ----------------------------------------------------------------------------ADD_FILE Add dumpfile to dumpfile set. ADD_FILE=dumpfile-name CONTINUE_CLIENT Return to logging mode. Job will be re-started if idle. EXIT_CLIENT Quit client session and leave job running. HELP Summarize interactive commands. KILL_JOB Detach and delete job. PARALLEL Change the number of active workers for current job. PARALLEL=. START_JOB Start/resume current job. STATUS Frequency (secs) job status is to be monitored where the default (0) will show new status when available. STATUS=[interval] STOP_JOB Orderly shutdown of job execution and exits the client. STOP_JOB=IMMEDIATE performs an immediate shutdown of the Data Pump job.

Oracle 10g Release 2 (10.2) added the following parameters. Keyword Description (Default) ----------------------------------------------------------------------------COMPRESSION Reduce size of dumpfile contents where valid keyword values are: (METADATA_ONLY) and NONE. ENCRYPTION_PASSWORD Password key for creating encrypted column data. SAMPLE Percentage of data to be exported; The following commands are valid while in interactive mode. Note: abbreviations are allowed Command Description -----------------------------------------------------------------------------

FILESIZE commands.

Default filesize (bytes) for subsequent ADD_FILE

Oracle 11g Release 1 (11.1) added the following parameters. Keyword Description (Default) ----------------------------------------------------------------------------DATA_OPTIONS Data layer flags where the only valid value is: XML_CLOBS-write XML datatype in CLOB format ENCRYPTION Encrypt part or all of the dump file where valid keyword values are: ALL, DATA_ONLY, METADATA_ONLY, ENCRYPTED_COLUMNS_ONLY, or NONE. ENCRYPTION_ALGORITHM Specify how encryption should be done where valid keyword values are: (AES128), AES192, and AES256. ENCRYPTION_MODE Method of generating encryption key where valid keyword values are: DUAL, PASSWORD, and (TRANSPARENT). REMAP_DATA Specify a data conversion function, e.g. REMAP_DATA=EMP.EMPNO:REMAPPKG.EMPNO. REUSE_DUMPFILES Overwrite destination dump file if it exists (N). TRANSPORTABLE Specify whether transportable method can be used where valid keyword values are: ALWAYS, (NEVER). The following commands are valid while in interactive mode. Note: abbreviations are allowed Command Description ----------------------------------------------------------------------------REUSE_DUMPFILES Overwrite destination dump file if it exists (N).

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. All rights reserved.

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

Write all the SQL DDL to a specified file. Frequency (secs) job status is to be monitored where the default (0) will show new status when available. STREAMS_CONFIGURATION Enable the loading of Streams metadata TABLE_EXISTS_ACTION Action to take if imported object already exists. Valid keywords: (SKIP), APPEND, REPLACE and TRUNCATE. TABLES Identifies a list of tables to import. TABLESPACES Identifies a list of tablespaces to import. TRANSFORM Metadata transform to apply (Y/N) to specific objects. Valid transform keywords: SEGMENT_ATTRIBUTES and STORAGE. ex. TRANSFORM=SEGMENT_ATTRIBUTES:N:TABLE. TRANSPORT_DATAFILES List of datafiles to be imported by transportable mode. TRANSPORT_FULL_CHECK Verify storage segments of all tables (N). TRANSPORT_TABLESPACES List of tablespaces from which metadata will be loaded. Only valid in NETWORK_LINK mode import operations. VERSION Version of objects to export where valid keywords are: (COMPATIBLE), LATEST, or any valid database version. Only valid for NETWORK_LINK and SQLFILE. The following commands are valid while in interactive mode. Note: abbreviations are allowed Command Description (Default)11g ----------------------------------------------------------------------------CONTINUE_CLIENT Return to logging mode. Job will be re-started if idle. EXIT_CLIENT Quit client session and leave job running. HELP Summarize interactive commands. KILL_JOB Detach and delete job. PARALLEL Change the number of active workers for current job. PARALLEL=. START_JOB Start/resume current job. START_JOB=SKIP_CURRENT will start the job after skipping any action which was in progress when job was stopped. STATUS Frequency (secs) job status is to be monitored where the default (0) will show new status when available. STATUS=[interval] STOP_JOB Orderly shutdown of job execution and exits the client. STOP_JOB=IMMEDIATE performs an immediate shutdown of the Data Pump job.

Oracle 10g Release 2 (10.2) added the following parameter. Keyword Description (Default) ----------------------------------------------------------------------------ENCRYPTION_PASSWORD Password key for accessing encrypted column data. This parameter is not valid for network import jobs.

Oracle 11g Release 1 (11.1) added the following parameters.

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.

2.6.3. When to Use Data Pump Export/Import Vs Original Export/Import

The Data Pump Export (expdp) and Import (impdp) utilities have a similar look and feel to the original Export (exp) and Import (imp) utilities, but they are completely separate. The Data Pump Export and Import utilities, first released in Oracle Database 10g Release 1 (10.1), are high performance replacements for the original Export and Import utilities. When upgrading from Oracle Database 10g Release 1 (10.1) or higher, Oracle recommends the Data Pump Export and Import utilities in most cases because these utilities provide greatly enhanced performance compared to the original Export and Import utilities. Data Pump Export and Import offer the following advantages:

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. Support for the full range of data types.

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).

2.6.4. Changing from Original Export/Import to Oracle Data Pump

Creating Directory Objects In order to use Data Pump, the database administrator must create a directory object and grant privileges to the user on that directory object. If a directory object is not specified, a default directory object called data_pump_dir is provided. The default data_pump_dir is available only to privileged users unless access is granted by the DBA. In the following example, the following SQL statement creates a directory object named dpump_dir1 that is mapped to a directory located at /usr/apps/datafiles. Create a directory. SQL> CREATE DIRECTORY dpump_dir1 AS /usr/apps/datafiles; After a directory is created, you need to grant READ and WRITE permission on the directory to other users. For example, to allow the Oracle database to read and to write to files on behalf of user scott in the directory named by dpump_dir1, you must execute the following command:

SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir1 TO scott; Note that READ or WRITE permission to a directory object means only that the Oracle database will read or write that file on your behalf. You are not given direct access to those files outside of the Oracle database unless you have the appropriate operating system privileges. Similarly, the Oracle database requires permission from the operating system to read and write files in the directories. Once the directory access is granted, the user scott can export his database objects with command arguments: >expdp username/password DIRECTORY=dpump_dir1 dumpfile=scott.dmp

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.

Example import of tables from scotts account to jims account Original Import: > imp username/password FILE=scott.dmp FROMUSER=scott TOUSER=jim TABLES=(*) Data Pump Import: > impdp username/password DIRECTORY=dpump_dir1 TABLES=scott.emp REMAP_SCHEMA=scott:jim

DUMPFILE=scott.dmp

Note how the FROMUSER/TOUSER syntax is replaced by the REMAP_SCHEMA option.

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.

Moving data between versions The Data Pump method for moving data between different database versions is different from the method used by original Export and Import. With original Export, you had to run an older version of Export to produce a dump file that was compatible with an older database version. With Data Pump, you use the current Export version and simply use the VERSION parameter to specify the target database version. You cannot specify versions earlier than Oracle Database 10g (since Data Pump did not exist before 10g). Example: > expdp username/password TABLES=hr.employees VERSION=10.1 DIRECTORY=dpump_dir1 DUMPFILE=emp.dmp

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.

Maximizing the Power of Oracle Data Pump Data Pump works great with default parameters, but once you are comfortable with Data Pump, there are new capabilities that you will want to explore.

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).

For best performance, you should do the following:

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

Even More Advanced Features of Oracle Data Pump Beyond the command-line and performance features of Oracle Data Pump are new capabilities that DBAs will find invaluable. A couple of prominent features are described here. Interactive Command-Line Mode You have much more control in monitoring and controlling Data Pump jobs with interactive command-line mode. Because Data Pump jobs run entirely on the server, you can start an export or import job, detach from it, and later reconnect to the job to monitor its progress. Here are some of the things you can do while in this mode:

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.

Data pump Frequently Asked Questions

Why are directory objects needed? They are needed to ensure data security and integrity. Otherwise, users would be able to read data that they should not have access to and perform unwarranted operations on the server.

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.

Why is Data Pump slower on small jobs? Data Pump was designed for big jobs with lots of data. Each Data Pump job has a master table that has all the information about the job and is needed for restartability. The overhead of creating this master table makes small jobs take longer, but the speed in processing large amounts of data gives Data Pump a significant advantage in medium and larger jobs.

Are original Export and Import going away? Original Export is being deprecated with the Oracle Database 11g release. Original Import will always be supported so that dump files from earlier releases (release 5.0 and later) will be able to be imported. Original and Data Pump dump file formats are not compatible.

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.

Can I use Oracle Enterprise Manager with Data Pump? Yes, OEM supports a fully functional interface to Data Pump.

Can I use gzip with Data Pump? Because Data Pump uses parallel operations to achieve its high performance, you cannot pipe the output of Data Pump export through gzip. Starting in Oracle Database 11g, the COMPRESSION parameter can be used to compress a Data Pump dump file as it is being created. The COMPRESSION parameter is available as part of the Advanced Compression Option for Oracle Database 11g.

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.

3. Introduction to Oracle DBA

3.1. 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: Knowledge of Structured Query Language (SQL) Some database design General understanding of distributed computing architectures (for example, Client/Server, Internet/Intranet, Enterprise) A good understanding of the underlying operating system e.g. Windows Server 2008, Solaris, Linux, AIX, etc. Knowledge about the RDBMS itself e.g. Microsoft SQL Server, Oracle Database, etc.

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 Data Analysts/Query designers Junior DBAs Midlevel DBAs Senior DBAs DBA consultants Manager/Director of Database Administration/Information Technology

3.2.

Why a Company needs a DBA

Why on earth would anyone hire a Database Administrator? Your Windows Admin can install Oracle with just a few clicks It only takes a few more clicks to put a database there and grant permissions. Most of your vendors have simple setup scripts including database deploys Why spend all that money on an Oracle DBA salary? Im glad you asked, I can think of a few reasons DBAs Are Mean Care About Your Data Your developers hopefully care about the data. Your vendors care about their bottom line might even care about your data as well. Your system administrators like things to run smoothly also; no one likes a failure. Your database administrators, however, have a vested interest in keeping your data clean and healthy. A good DBA will say no quite often (or, more accurately, not yet; not deployed like that or no until security is cleaned up) if something is being done without concern for security or performance best practices in mind. Sure we can come across as tough sometimes but when you stop and ask why, it is usually because we care about the data. Maybe its not so altruistic and we just dont like being woken up after hours. Either way, we are going to do all we can to fight silliness at every stage of a databases life. Sometimes it is appreciated and understood. A development manager at one point in my career sent me a note around review time that included this statement, Our developers are very appreciative that, while you can be one tough and principled SOB, you are usually right in the end!! That isnt to gloat, its to say that a DBA who cares to do the job right and wants things right the first time can make a difference in the long run. So Reason 1: A DBA cares about the database. Its a myopic concern. Yes we care about the other facets of an application but it all stems from our desire to make the databases be all they can be. The other roles? They have their primary focus on something else (as they should!) DBAs like Best Practices Im talking about experienced and effective DBAs here. What I mean by the heading is that a database administrator knows what is beneath the set-it-and-forget-it installation options and deployment steps. We read books like Oracle 11g: Internals and Troubleshooting (some of us even read them on personal time!). We study up on the database engine we support. We want to first understand why a best practice exists and then implement the ones that make sense for our organization. We arent going to accept defaults, we arent going to ignore empirical evidence and try the first thing that a search engine shows us in production (hopefully). We may not just accept a hand me down server for that huge production ERP deployment. We might discuss SAN optimization with the storage team. When we look at a backup solution for the enterprise we will ask questions that are relevant to Oracle and the recovery needs we support. We wont let a vendor do something dumb without a lot of whining and attempts to correct.

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.

Roles & Responsibilities of DBA

Responsibilities of Oracle Database Administrator: The following tasks present a prioritized approach for designing, implementing, and maintaining an Oracle Database: Task 1: Evaluate the Database Server Hardware Task 2: Install the Oracle Database Software

Task 3: Plan the Database Task 4: Create and Open the Database Task 5: Back Up the Database Task 6: Enroll System Users Task 7: Implement the Database Design Task 8: Back Up the Fully Functional Database Task 9: Tune Database Performance Task 10: Download and Install Patches Task 11: Roll Out to Additional Hosts Note: When upgrading to a new release, back up your existing production environment, both software and database, before installation. Task 1: Evaluate the Database Server Hardware Evaluate how Oracle Database and its applications can best use the available computer resources. This evaluation should reveal the following information: How many disk drives are available to the Oracle Products? How many, if any, dedicated tape drives are available to Oracle products? How much memory is available to the instances of Oracle Database you will run? Task 2: Install the Oracle Database Software As the database administrator, you install the Oracle Database server software and any frontend tools and database applications that access the database. In some distributed processing installations, the database is controlled by a central computer (database server) and the database tools and applications are executed on remote computers (clients). In this case, you must also install the Oracle Net components necessary to connect the remote machines to the computer that executes Oracle Database. Task 3: Plan the Database As the database administrator, you must plan: The logical storage structure of the database The overall database design A backup strategy for the database It is important to plan how the logical storage structure of the database will affect system performance and various database management operations. For example, before creating any tablespaces for your database, you should know how many datafiles will make up the tablespace, what type of information will be stored in each tablespace, and on which disk drives the datafiles will be physically stored. When planning the overall logical storage of the database structure, take into account the effects that this structure will have when the database is actually created and running. Consider how the logical storage structure of the database will affect: The performance of the computer executing running Oracle Database The performance of the database during data access operations The efficiency of backup and recovery procedures for the database

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:

System Database Administrator (Installation and Configuration)

Data Modeler (Database Design and Modeling) Database Analyst (database analysis) Database Backup Administrator, etc.( Implementing Backups policies ). Network Administrator (using Oracle and system network). Storage Administrator (using Oracle ASM feature).

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.

Primary Architecture Components

The figure shown before details the Oracle architecture. Oracle server: An Oracle server includes an Oracle Instance and an Oracle database. An Oracle database includes several different types of files: Data files, Control files, Redo log files and archive redo log files. The Oracle server also accesses parameter files and password files. This set of files has several purposes. One is to enable system users to process SQL statements. Another is to improve system performance. Still another is to ensure the database can be recovered if there is a software/hardware failure. The database server must manage large amounts of data in a multi-user environment. The server must manage concurrent access to the same data. The server must deliver high performance. This generally means fast response times. Oracle instance: An Oracle Instance consists of two different sets of components: The first component set is the set of background processes (PMON, SMON, RECO, DBW0, LGWR, CKPT, D000 and others). o These will be covered later in detail each background process is a computer program. o These processes perform input/output and monitor other Oracle processes to provide good performance and database reliability. The second component set includes the memory structures that comprise the Oracle instance. o When an instance starts up, a memory structure called the System Global Area (SGA) is allocated. o At this point the background processes also start. o An Oracle Instance provides access to one and only one Oracle database. Oracle database: An Oracle database consists of files. Sometimes these are referred to as operating system files, but they are actually database files that store the database information that a firm or organization needs in order to operate. The redo log files are used to recover the database in the event of application program failures, instance failures and other minor failures. The archived redo log files are used to recover the database if a disk fails. Other files not shown in the figure include: o The required parameter file that is used to specify parameters for configuring an Oracle instance when it starts up. o The optional password file authenticates special users of the database these are termed privileged users and include database administrators. o Alert and Trace Log Files these files store information about errors and actions taken that affect the configuration of the database.

User and server processes: The processes shown in the figure are called user and server processes. These processes are used to manage the execution of SQL statements. A Shared Server Process can share memory and variable processing for multiple user processes. A Dedicated Server Process manages memory and variables for a single user process. This figure from the Oracle Database Administration Guide provides another way of viewing the SGA.

Connecting to an Oracle Instance Creating a Session

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.

Physical Structure Database Files

As was noted above, an Oracle database consists of physical files. The database itself has: Data files these contain the organization's actual data. Redo log files these contain a chronological record of changes made to the database, and enable recovery when failures occur. Control files these are used to synchronize all database activities and are covered in more detail in a later module.

Other key files as noted above include: Parameter file there are two types of parameter files. o The init.ora file (also called the PFILE) is a static parameter file. It contains parameters that specify how the database instance is to start up. For example, some parameters will specify how to allocate memory to the various parts of the system global area. o The spfile.ora is a dynamic parameter file. It also stores parameters to specify how to startup a database; however, its parameters can be modified while the database is running. Password file specifies which *special* users are authenticated to startup/shut down an Oracle Instance. Archived redo log files these are copies of the redo log files and are necessary for recovery in an online, transaction-processing environment in the event of a disk failure.

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.

4.3.1. System Global Area

The SGA is a read/write memory area that stores information shared by all database processes and by all users of the database (sometimes it is called the Shared Global Area). This information includes both organizational data and control information used by the Oracle Server. The SGA is allocated in memory and virtual memory. The size of the SGA can be established by a DBA by assigning a value to the parameter SGA_MAX_SIZE in the parameter filethis is an optional parameter. The SGA is allocated when an Oracle instance (database) is started up based on values specified in the initialization parameter file (either PFILE or SPFILE). The SGA has the following mandatory memory structures: Database Buffer Cache Redo Log Buffer Java Pool Streams Pool Shared Pool includes two components: o Library Cache o Data Dictionary Cache Other structures (for example, lock and latch management, statistical data) Additional optional memory structures in the SGA include: Large Pool

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.

4.3.2. Program Global Area

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.

4.3.3. User Global Area

The User Global Area is session 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.

Automatic Shared Memory Management Prior to Oracle 10G, a DBA had to manually specify SGA Component sizes through the initialization parameters, such as SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, and LARGE_POOL_SIZE parameters. Automatic Shared Memory Management enables a DBA to specify the total SGA memory available through the SGA_TARGET initialization parameter. The Oracle Database automatically distributes this memory among various subcomponents to ensure most effective memory utilization. The DBORCL database SGA_TARGET is set in the initDBORCL.ora file: sga_target=1610612736 With automatic SGA memory management, the different SGA components are flexibly sized to adapt to the SGA available. Setting a single parameter simplifies the administration task the DBA only specifies the amount of SGA memory available to an instance the DBA can forget about the sizes of individual components. No out of memory errors are generated unless the system has actually run out of memory. No manual tuning effort is needed. The SGA_TARGET initialization parameter reflects the total size of the SGA and includes memory for the following components: Fixed SGA and other internal allocations needed by the Oracle Database instance The log buffer The shared pool The Java pool The buffer cache The keep and recycle buffer caches (if specified) Nonstandard block size buffer caches (if specified) The Streams Pool If SGA_TARGET is set to a value greater than SGA_MAX_SIZE at startup, then the SGA_MAX_SIZE value is bumped up to accommodate SGA_TARGET. When you set a value for SGA_TARGET, Oracle Database 10g automatically sizes the most commonly configured components, including: The shared pool (for SQL and PL/SQL execution) The Java pool (for Java execution state) The large pool (for large allocations such as RMAN backup buffers) The buffer cache There are a few SGA components whose sizes are not automatically adjusted. The DBA must specify the sizes of these components explicitly, if they are needed by an application. Such components are: Keep/Recycle buffer caches (controlled by DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE)

Additional buffer caches for non-standard block sizes (controlled by DB_nK_CACHE_SIZE, n = {2, 4, 8, 16, 32}) Streams Pool (controlled by the new parameter STREAMS_POOL_SIZE)

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.

Data Dictionary Cache The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used. This cache is necessary because the data dictionary is accessed so often. Information accessed includes user account information, data file names, table descriptions, user privileges, and other information. The database server manages the size of the Data Dictionary Cache internally and the size depends on the size of the Shared Pool in which the Data Dictionary Cache resides. If the size is too small, then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance.

Server Result Cache The Server Result Cache holds result sets and not data blocks. The server result cache contains the SQL query result cache and PL/SQL function result cache, which share the same infrastructure. SQL Query Result Cache This cache stores the results of queries and query fragments. Using the cache results for future queries tends to improve performance. For example, suppose an application runs the same SELECT statement repeatedly. If the results are cached, then the database returns them immediately. In this way, the database avoids the expensive operation of rereading blocks and recomputing results. PL/SQL Function Result Cache The PL/SQL Function Result Cache stores function result sets. Without caching, 1000 calls of a function at 1 second per call would take 1000 seconds. With caching, 1000 function calls with the same inputs could take 1 second total. Good candidates for result caching are frequently invoked functions that depend on relatively static data. PL/SQL function code can specify that results be cached. Buffer Caches A number of buffer caches are maintained in memory in order to improve system response time. Database Buffer Cache The Database Buffer Cache is a fairly large memory object that stores the actual data blocks that are retrieved from data files by system queries and other data manipulation language commands. A query causes a Server Process to first look in the Database Buffer Cache to determine if the requested information happens to already be located in memory thus the information would not need to be retrieved from disk and this would speed up performance. If the information is not in the Database Buffer Cache, the Server Process retrieves the information from disk and stores it to the cache. Keep in mind that information read from disk is read a block at a time, not a row at a time, because a database block is the smallest addressable storage space on disk. Database blocks are kept in the Database Buffer Cache according to a Least Recently Used (LRU) algorithm and are aged out of memory if a buffer cache block is not used in order to provide space for the insertion of newly needed database blocks.

The buffers in the cache are organized in two lists: the write list and, the least recently used (LRU) list. The write list holds dirty buffers these are buffers that hold that data that has been modified, but the blocks have not been written back to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed. When an Oracle process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list this causes dirty buffers to age toward the LRU end of the LRU list. When an Oracle user process needs a data row, it searches for the data in the database buffer cache because memory can be searched more quickly than hard disk can be accessed. If the data row is already in the cache (a cache hit), the process reads the data from memory; otherwise a cache miss occurs and data must be read from hard disk into the database buffer cache. Before reading a data block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the LRU end of the list. The search continues until a free buffer is found or until the search reaches the threshold limit of buffers. Each time a user process finds a dirty buffer as it searches the LRU, that buffer is moved to the write list and the search for a free buffer continues. When a user process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list. If an Oracle user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBWn background process to write some of the dirty buffers to disk. This frees up some buffers. The block size for a database is set when a database is created and is determined by the init.ora parameter file parameter named DB_BLOCK_SIZE. 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

SQL> SELECT name, block_size, advice_status FROM v$db_cache_advice; NAME BLOCK_SIZE ADV -------------------- ---------- --DEFAULT 8192 ON <more rows will display> 21 rows selected. SQL> ALTER SYSTEM SET db_cache_advice = OFF; System altered. KEEP Buffer Pool This pool retains blocks in memory (data from tables) that are likely to be reused throughout daily processing. An example might be a table containing user names and passwords or a validation table of some type. The DB_KEEP_CACHE_SIZE parameter sizes the KEEP Buffer Pool. RECYCLE Buffer Pool This pool is used to store table data that is unlikely to be reused throughout daily processing thus the data blocks are quickly removed from memory when not needed. The DB_RECYCLE_CACHE_SIZE parameter sizes the Recycle Buffer Pool. Redo Log Buffer

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.

4.4.1. Client Process:

In order to use Oracle, you must obviously connect to the database. This must occur whether you're using SQLPlus, an Oracle tool such as Designer or Forms, or an application program. The client process is also termed the user process in some Oracle documentation.

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.

4.4.2. Server Process

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.

4.4.3. Background Processes

As is shown here, there are both mandatory and optional background processes that are started whenever an Oracle Instance starts up. These background processes serve all system users. We will cover mandatory process in detail. Mandatory Background Processes Process Monitor Process (PMON) System Monitor Process (SMON) Database Writer Process (DBWn) Log Writer Process (LGWR) Checkpoint Process (CKPT) Manageability Monitor Processes (MMON and MMNL) Recover Process (RECO) Optional Processes Archiver Process (ARCn) Coordinator Job Queue (CJQ0) Dispatcher (number nnn) (Dnnn)

Others

Optional Background Process Definition: ARCn: Archiver One or more archiver processes copy the online redo log files to archival storage when they are full or a log switch occurs. CJQ0: Coordinator Job Queue This is the coordinator of job queue processes for an instance. It monitors the JOB$ table (table of jobs in the job queue) and starts job queue processes (Jnnn) as needed to execute jobs The Jnnn processes execute job requests created by the DBMS_JOBS package. Dnnn: Dispatcher number "nnn", for example, D000 would be the first dispatcher process Dispatchers are optional background processes, present only when the shared server configuration is used. Shared server is discussed in your readings on the topic "Configuring Oracle for the Shared Server". Of these, you will most often use ARCn (archiver) when you automatically archive redo log file information (covered in a later module). PMON The Process Monitor (PMON) is a cleanup type of process that cleans up after failed processes such as the dropping of a user connection due to a network failure or the abnormal termination (ABEND) of a user application program. It does the tasks shown in the figure below.

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.

The initialization parameter DB_WRITER_PROCESSES specifies the number of DBWn processes. The purpose of DBWn is to improve system performance by caching writes of database blocks from the Database Buffer Cache back to datafiles. Blocks that have been modified and that need to be written back to disk are termed "dirty blocks." The DBWn also ensures that there are enough free buffers in the Database Buffer Cache to service Server Processes that may be reading data from datafiles into the Database Buffer Cache. Performance improves because by delaying writing changed database blocks back to disk, a Server Process may find the data that is needed to meet a User Process request already residing in memory! DBWn writes to datafiles when one of these events occurs that is illustrated in the figure below.

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. Obviously a tablespace typically has many segments. A segment cannot span tablespaces but can span data files that belong to a single tablespace.

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.

SQL Statement Processing

SQL Statements are processed differently depending on whether the statement is a query, data manipulation language (DML) to update, insert, or delete a row, or data definition language (DDL) to write information to the data dictionary.

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.

Processing a DDL statement: The execution of DDL (Data Definition Language) statements differs from the execution of DML (Data Manipulation Language) statements and queries, because the success of a DDL statement requires write access to the data dictionary. For these statements, parsing actually includes parsing, data dictionary lookup, and execution. Transaction management, session management, and system management SQL statements are processed using the parse and execute stages. To re-execute them, simply perform another execute.

5.

Oracle Shared Server

Oracle Shared Server is an optional configuration of Oracle Server that allows the server to support a larger number of concurrent connections without increasing physical resource requirements. It does so by sharing resources among groups of users.

5.1. Understand when to use Oracle Shared Servers

Shared Server is suitable for "high think" applications. High think applications are composed of small transactions with natural pauses in the transaction patterns, which make them good candidates for Oracle Shared Server connections. Many web-based applications fit this model. These types of applications are typically form-based and involve submissions of small amounts of information to the database with small result sets returned to the client. As described in the previous section, you manage client connections quite differently when using Oracle Shared Server as opposed to using a dedicated server. To accommodate the change, several modifications take place inside the internal memory structures of the Oracle Server. The way in which the database and listener interact is also affected when using Oracle Shared Server. It is important to understand these changes when configuring and managing the Oracle Shared Server.

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.

Configuring the Oracle Shared Server

You can configure Oracle Shared Server in a number of ways. You can configure it at the time the database is created, you can use the Enterprise Manager (EM) to configure it after the database has been created, or you can manually configure it by editing initialization parameters. We'll discuss the parameters necessary to configure Oracle Shared Server. We'll also give examples of how to configure Shared Server at database creation or after the database is created using EM.

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.

Dedicated Servers Vs Shared Servers

Today an organization can have hundreds or thousands of users connecting to their databases. The traditional dedicated server model maps each user to a dedicated process running on the database server. Each dedicated server process requires memory and as the number of users increase, there is a linear increase in the demand for memory. So, there is a definite possibility that, as the number of users connecting, go up, there will come a point where the system will be unable to connect any more users (the proverbial last straw on the camels back). Besides, if we have lots of clients connecting / disconnecting, thereby generating a lot of churn, a large amount of resourcesCPU and memorywill end up being dedicated to creating a connection and subsequently deleting it. It is precisely these issues that are addressed by the use of a shared server, previously known as multi-threaded server. A shared server process allows a single server process to service several clients, based on the premise that usually in an OLTP environment, a user is more often than not, reading and editing data on the screen than actually executing a DML. What this means is that, there will be chunks of time when the dedicated server process, dedicated to a particular client will be sitting idle. It is this idleness that is exploited by the shared server process in servicing several clients together. Several advantages accrue as a result of using shared server, most notably: 1. Fewer server processes can handle many more clients, thereby immediately reducing memory demand. 2. Less Churn as server processes are no longer created / deleted with connection / disconnection of a client. 3. Server processes are utilized more efficiently, as idle time is drastically cut down. So, although shared servers have certain obvious advantages over dedicated servers, there is some clear trade-offs as well: The use of a shared server is tied to the assumption that the connecting client will use only a small fraction of his/her time executing queries or talking to the database, so that the rest of the time can be used to do work for other clients. The more active a client is, the greater the number of shared server processes have to be created and if the number of clients and their quantum of activity keeps on increasing, then there will come a point where the entire concept of shared server will become meaningless. While shared server does reduce the demand for memory, it is in no way going to improve performance. At best, the drop in performance may not be noticed by the users, if they are using a lot of think time, at worst, it has the potential to become a DBAs nightmare. Shared servers do not support the use of RMAN. So, if you are going to use RMAN, then you have to use a separate dedicated server connection as well. The implementation of shared server is predicated on the fact that to enable one connection to be serviced by two or more processes, session specific memory has to be moved to a commonly accessible location. In this post, I will just touch upon the memory structure required for a shared server:

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:

system@ORCL-SQL>>alter system set dispatchers="(protocol=TCP)(dispatchers=3)(connections=100)" System altered. system@ORCL-SQL>>alter system set dispatchers="(protocol=NMP)(dispatchers=2)(connections=100)"; System altered. system@ORCL-SQL>>alter system set max_dispatchers=10; System altered. system@ORCL-SQL>>column NAME_COL_PLUS_SHOW_PARAM format a40 system@ORCL-SQL>>column VALUE_COL_PLUS_SHOW_PARAM format a40 system@ORCL-SQL>>show parameter disp NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM ---------------------------------------- ----------- --------------------------------------dispatchers string (protocol=TCP)(dispatchers=3)(connection s=100), (protocol=NMP)(dispatchers=2)(co nnections=100) max_dispatchers integer 10 system@ORCL-SQL>>

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.

Monitoring Shared Servers

Now, let's take up the V$ views that return information and statistics about shared server connections and processes, V$SHARED_SERVER: This view returns process name, process address, status and other useful statistics for each shared server process that is currently running as part of the instance. V$DISPATCHER: This view returns information, such as the dispatcher's name, network address, process address, status for each dispatcher process associated with the instance. V$DISPATCHER_RATE: Returns rate statistics for each dispatcher. V$CIRCUIT: Returns a single row for each shared server connection to the instance. A circuit, being a connection through a specific dispatcher and shared server process. This view returns information relating to each shared server circuit to a specific dispatcher, shared server process, and session. V$QUEUE: Returns information for each queue in the instance. Each dispatcher will have one response queue associated with it, and there will always be one common request queue for the instance. Thus, the number of rows returned by V$QUEUE will always equal the number of dispatchers plus one. So, that concludes monitoring on shared servers

6.

Installation and Configuration of Oracle Database

Using the Oracle Universal Installer, we can install the Oracle Database 11g software and create a database.

6.1. System Requirements

Detailed Hardware and Software requirements are listed for different environments in Oracle resources and websites. Following quick link show the information for Oracle 11.1 version. http://www.oracle.com/pls/db111/portal.portal_db?selected=11

6.2. Environment Variables

This section describes the most commonly used Oracle Database and operating system environment variables. You must define some of these environment variables before installing Oracle Database. This section covers the following topics: Table 3-1 Environment Variables for Linux and UNIX
Environment Variable DISPLAY LD_LIBRARY_PATH Value hostname:display_number.screen_number Very few tools, such as oidadmin, require the DISPLAY variable. On Solaris, ensure that the value contains the following directory: $ORACLE_HOME/lib32 On Linux and HP-UX, ensure that the value contains the following directory: $ORACLE_HOME/lib On IBM AIX, ensure that this environment variable is not set. 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

(IBM AIX only) LIBPATH

(Solaris Ensure that the value contains the following directory: only) LD_LIBRARY_PATH_64 $ORACLE_HOME/lib (HP-UX only) SHLIB_PATH MW_HOME Ensure that the value contains the following directory: $ORACLE_HOME/lib32 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 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

ORACLE_HOME

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 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. Ensure that the value contains the following directory: MW_HOME/jdkn Ensure that the value contains the following directories: $ORACLE_HOME/lib:MW_HOME/jdkn/lib

PATH

JAVA_HOME CLASSPATH

Table 3-2 Environment Variables for Windows Environment Variable MW_HOME Value 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 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 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 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 Ensure that the value contains the following directory: MW_HOME\jdkn Ensure that the value contains the following directories:

ORACLE_HOME

ORACLE_INSTANCE

PATH

JAVA_HOME CLASSPATH

Environment Variable

Value ORACLE_HOME\lib:MW_HOME\jdkn\lib

TEMP TMP

Set the value to your temp directory, for example, C:\temp. Set the value to your temp directory, for example, C:\temp.

6.3. Installation using OUI

This is a 16 step Oracle 11g installation guide that covers a typical installation scenario with screenshots. 1. Select installation method Following two installation methods are available: Basic Installation Choose this to perform the full Oracle Database 11g installation with standard configuration options. You can use only filesystem for storage in this option. Advanced Installation This gives your full control over the installation, including the ability to choose Automatic Storage Management. Select this option as shown below.

Fig - Select Installation Method

2. Specify Inventory directory and credentials Enter the following information: Enter the inventory directory: /u01/app/oraInventory Specify operating system group name: oinstall

Fig - Specify Inventory directory and credentials 3. Select Installation Type Following three installation types are available:

Enterprise Edition Select this option. Standard Edition Custom

Fig - Select Installation Type 4. Specify Install Location Enter the following information: Oracle Base: /u01/app/oracle Name: Oracle_Home Path: /u01/app/oarcle/product/11.1.0

Fig - Select Install Location 5. Product-Specific Prerequisite Checks In this screen, the Installer verifies that your environment meets all of the minimum requirements for installing and configuring the products that you have chosen to install. You must manually verify and confirm the items that are flagged with warnings and items that require manual checks. 6. Select Configuration Option Following three configuration options are available: Create a Database Select this option. Configure Automatic Storage Management (ASM) Install Software Only

Fig - Select Configuration Option

7. Select a Database Configuration Following three database configuration options are available.

General Purpose/Transaction Processing Select this option. Data Warehouse Advanced

Fig - Select Database Configuration 8. Specify Database Configuration Enter the following information:

Global Database Name: devdb.example.com . An Oracle database is uniquely identified by a Global Database Name, typically of the form name.domain SID: devdb

9. Specify Database Configuration Details There are four different tabs in this screen as shown below:

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.

Sample Schema Tab Just leave the defaults in this tab.

Fig - Select Database Config Details with Memory Tab 10. Select Database Management Option Following two management options are available:

Use Grid Control for Database Management Management Service: Choose an agent. Use Database Control for Database Management- Select this option. Select the check-box to Enable Email Notifications Outgoing mail (SMTP) Server: Email Address:

Fig - Select Database Management Option 11. Specify Database Storage Option Following two storage options are available:

File System Select this option. Specify Database File location: /u01/app/oracle/oradata/ Automatic Storage Management. ASM simplifies database storage administration and optimizes database layout for I/O performance.

12. Specify Backup and Recovery Option Enable automated backup as shown below. If youve configured ASM, you can choose to store the automated backups on ASM. If not, select File System option.

Fig - Specify Backup and Recovery Options 13. Specify database schema password Enter the password for sys, system, sysman, dbsnmp schemas. You have the option of either using the same passwords or different password for all the accounts in this screen. 14. Privileged Operating System Groups Enter the following information in this screen: Database Administrator (OSDBA) Group: dba Database Operator (OSOPER) Group: dba ASM administrator (OSASM) Group: dba 15. Oracle Configuration Manager Registration You can associate your configuration information with your metalink account as shown below.

Fig - Oracle Configuration Manager Registration 16. Final Summary Screen This will display a summary of all the installation option youve selected so far. Click on Install to complete the installation.

Fig - Installation Summary Screen

6.4. Silent Installation 6.5. Using DBCA 6.6. Optimal Flexible Architecture 6.7. Authentication Methods 6.8. Database Startup modes 6.9. PFile vs SPFile 6.10. Oracle Managed Files