Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

2010 | Book

Developing Successful Oracle Applications Read chapter Read first chapter

Expert Oracle Database Architecture

Oracle Database 9i, 10g, and 11g Programming Techniques and Solutions

Author: Thomas Kyte

Editors: Jonathan Gennick, Clay Andres, Steve Anglin, Mark Beckner, Ewan Buckingham, Gary Cornell, Jonathan Hassell, Michelle Lowman, Matthew Moodie, Duncan Parkes, Jeffrey Pepper, Frank Pohlmann, Douglas Pundick, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh, Debra Kelly, Mary Behr, Sharon Terdeman

Publisher: Apress

Part of: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Login to get access
insite
SEARCH

About this book

Now in its second edition, this best-selling book by Tom Kyte of "Ask Tom" fame continues to bring you some of the best thinking on how to apply Oracle Database to produce scalable applications that perform well and deliver correct results. Tom has a simple philosophy: you can treat Oracle as a black box and just stick data into it or you can understand how it works and exploit it as a powerful computing environment. If you choose the latter, then you’ll find that there are few information management problems that you cannot solve quickly and elegantly.

This fully revised second edition covers the developments up to Oracle Database 11g. Each feature is taught in a proof-by-example manner, not only discussing what it is, but also how it works, how to implement software using it, and the common pitfalls associated with it.

Don’t treat Oracle Database as a black-box. Get this book. Get under the hood. Turbo-charge your career.

Fully revised to cover Oracle Database 11g Proof-by-example approach: Let the evidence be your guide Dives deeply into Oracle Database’s most powerful features

Table of Contents

Frontmatter
Chapter 1. Developing Successful Oracle Applications
Abstract
I spend the bulk of my time working with Oracle database software and, more to the point, with people who use this software. Over the last eighteen years, I’ve worked on many projects—successful ones as well as complete failures—and if I were to encapsulate my experiences into a few broad statements, here’s what they would be:
  • An application built around the database—dependent on the database—will succeed or fail based on how it uses the database. As a corollary to this—all applications are built around databases; I can’t think of a single useful application that doesn’t store data persistently somewhere.
  • Applications come, applications go. The data, however, lives forever. It is not about building applications; it really is about the data underneath these applications.
  • A development team needs at its heart a core of database-savvy coders who are responsible for ensuring the database logic is sound and the system is built to perform from day one. Tuning after the fact—tuning after deployment—means you did not build it that way.
Chapter 2. Architecture Overview
Abstract
Oracle is designed to be a very portable database—it is available on every platform of relevance, from Windows to UNIX to mainframes. However, the physical architecture of Oracle looks different on different operating systems. For example, on a UNIX operating system, you’ll see Oracle implemented as many different operating system processes, virtually a process per major function. On UNIX, this is the correct implementation, as it works on a multiprocess foundation. On Windows, however, this architecture would be inappropriate and would not work very well (it would be slow and nonscalable). On the Windows platform, Oracle is implemented as a single process with multiple threads. On IBM mainframe systems, running OS/390 and z/OS, the Oracle operating system-specific architecture exploits multiple OS/390 address spaces, all operating as a single Oracle instance. Up to 255 address spaces can be configured for a single database instance. Moreover, Oracle works together with OS/390 Workload Manager (WLM) to establish the execution priority of specific Oracle workloads relative to each other and relative to all other work in the OS/390 system. Even though the physical mechanisms used to implement Oracle from platform to platform vary, the architecture is sufficiently generalized that you can get a good understanding of how Oracle works on all platforms.
Chapter 3. Files
Abstract
In this chapter, we will examine the eight major file types that make up a database and instance. The files associated with an instance are simply
  • Parameter files: These files tell the Oracle instance where to find the control files, and they also specify certain initialization parameters that define how big certain memory structures are, and so on. We will investigate the two options available for storing database parameter files.
  • Trace files: These are diagnostic files created by a server process, generally in response to some exceptional error condition.
  • Alert files: These are similar to trace files, but they contain information about “expected” events, and they also alert the DBA in a single, centralized file of many database events.
Chapter 4. Memory Structures
Abstract
In this chapter, we’ll look at Oracle’s three major memory structures:
  • System Global Area (SGA): This is a large, shared memory segment that virtually all Oracle processes will access at one point or another.
  • Process Global Area (PGA): This is memory that is private to a single process or thread; it is not accessible from other processes/threads.
  • User Global Area (UGA): This is memory associated with your session. It is located either in the SGA or the PGA, depending whether you are connected to the database using a shared server (it will be in the SGA), or a dedicated server (it will be in the PGA).
Chapter 5. Oracle Processes
Abstract
We’ve reached the last piece of the architecture puzzle. We’ve investigated the database and the set of physical files that constitute a database. In covering the memory used by Oracle, we’ve looked at one half of an instance. The last remaining architectural issue to cover is the set of processes that constitute the other half of the instance.
Chapter 6. Locking and Latching
Abstract
One of the key challenges in developing multiuser, database-driven applications is to maximize concurrent access and, at the same time, ensure that each user is able to read and modify the data in a consistent fashion. The locking mechanisms that allow this to happen are key features of any database, and Oracle excels in providing them. However, Oracle’s implementation of these features is specific to Oracle—just as SQL Server’s implementation is to SQL Server—and it is up to you, the application developer, to ensure that when your application performs data manipulation, it uses these mechanisms correctly. If you fail to do so, your application will behave in an unexpected way, and inevitably the integrity of your data will be compromised (as was demonstrated in Chapter 1 “Developing Successful Oracle Applications”).
Chapter 7. Concurrency and Multi-versioning
Abstract
As stated in the last chapter, one of the key challenges in developing multiuser, database-driven applications is to maximize concurrent access but, at the same time, ensure that each user is able to read and modify the data in a consistent fashion. In this chapter, we’re going to take a detailed look at how Oracle achieves multi-version read consistency and what that means to you, the developer. I will also introduce a new term, write consistency, and use it to describe how Oracle works not only in a read environment with read consistency, but also in a mixed read and write environment.
Chapter 8. Transactions
Abstract
Transactions are one of the features that set databases apart from file systems. In a file system, if you are in the middle of writing a file and the operating system crashes, that file will probably be corrupted, though there are “journaled” file systems and the like that may be able to recover your file to some point in time. However, if you need to keep two files synchronized, such a system won’t help—if you update one file and the system fails before you finish updating the second, your files won’t be synchronized.
Chapter 9. Redo and Undo
Abstract
This chapter describes two of the most important pieces of data in an Oracle database: redo and undo. Redo is the information Oracle records in online (and archived) redo log files in order to “replay” your transaction in the event of a failure. Undo is the information Oracle records in the undo segments in order to reverse, or roll back, your transaction.
Chapter 10. Database Tables
Abstract
In this chapter, we will discuss the various types of database tables and cover when you might want to use each type (i.e., when one type of table is more appropriate than another). We will concentrate on the physical storage characteristics of the tables: how the data is organized and stored.
Chapter 11. Indexes
Abstract
Indexing is a crucial aspect of your application design and development. Too many indexes and the performance of modifications (inserts, updates, merges, and deletes) will suffer. Too few indexes and the performance of DML (including select, inserts, updates, and deletes) will suffer. Finding the right mix is critical to your application’s performance.
Chapter 12. Datatypes
Abstract
Choosing the right datatype seems so easy and straightforward, but many times I see it done incorrectly. The most basic decision—what type you use to store your data in—will have repercussions on your applications and data for years to come. Thus, choosing the appropriate datatype is paramount. It is also hard to change after the fact—in other words, once you implement it, you might be stuck with it for quite a while.
Chapter 13. Partitioning
Abstract
Partitioning, first introduced in Oracle 8.0, is the process of physically breaking a table or index into many smaller, more manageable pieces. As far as the application accessing the database is concerned, there is logically only one table or one index, but physically that table or index may comprise many dozens of physical partitions. Each partition is an independent object that may be manipulated either by itself or as part of the larger object.
Chapter 14. Parallel Execution
Abstract
Parallel execution, a feature of Oracle Enterprise Edition (it is not available in the Standard Edition), was first introduced in Oracle version 7.1.6 in 1994. It is the ability to physically break a large serial task (any DML, or DDL in general) into many smaller bits that may all be processed simultaneously. Parallel executions in Oracle mimic the real-life processes we see all of the time. For example, you would not expect to see a single individual build a house; rather, many people team up to work concurrently to rapidly assemble the house. In that way, certain operations can be divided into smaller tasks and performed concurrently; for instance, the plumbing and electrical wiring can take place concurrently to reduce the total amount of time required for the job as a whole.
Chapter 15. Data Loading and Unloading
Abstract
In this chapter, we will discuss data loading and unloading—in other words, how to get data into and out of an Oracle database. The main focus of the chapter is on the following bulk data loading tools:
  • SQL*Loader (pronounced “sequel loader”): This is still a predominant method for loading data.
  • External tables: This is a feature with Oracle9i and above that permits access to operating system files as if they were database tables and, in Oracle 10g and above, even allows for the creation of operating system files as extracts of tables.
Chapter 16. Data Encryption
Abstract
In this chapter, we will discuss encryption—the process of obfuscating data in such a way that it is only readable by someone or something that possesses a key that can be used to reverse this obfuscation. A definition I found on http://en.wikipedia.org/wiki/Encryption sums it up nicely:
In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
Backmatter
Metadata
Title
Expert Oracle Database Architecture
Author
Thomas Kyte
Editors
Jonathan Gennick
Clay Andres
Steve Anglin
Mark Beckner
Ewan Buckingham
Gary Cornell
Jonathan Hassell
Michelle Lowman
Matthew Moodie
Duncan Parkes
Jeffrey Pepper
Frank Pohlmann
Douglas Pundick
Ben Renow-Clarke
Dominic Shakeshaft
Matt Wade
Tom Welsh
Debra Kelly
Mary Behr
Sharon Terdeman
Copyright Year
2010
Publisher
Apress
Electronic ISBN
978-1-4302-2947-6
Print ISBN
978-1-4302-2946-9
DOI
https://doi.org/10.1007/978-1-4302-2947-6

Premium Partner

    Image Credits