Practical Oracle8i: Building Efficient Databases / Edition 1

Why Another Book?

Since there are so many books about Oracle already on the market, why have I bothered to sit down and add to the pile? In the age of Internet news groups and Web sites, it isn't for the fame. And given the specialized nature and likely circulation of such a tome, it probably isn't for the fortune.

Every now and again, usually while I've been rattling on enthusiastically about some obscure and esoteric feature of the way in which Oracle works, I've been asked, Why don't you write a book about Oracle since you know so much about it? My answer has always been the same: If you write a technical book about Oracle, it will be out of date by the time you've finished writing it, and within a year of publication it will be 20% misleading, inappropriate, or just plain wrong.

I have, however, finally given in to temptation because I've spent too long traveling around the world helping people to get the best out of their databases, and discovering time and again that the single biggest aid to success is to start well by picking the most appropriate features for the job.

This book is my attempt to tell you about some of the more useful things I have discovered while designing or fixing a few of the more thought-provoking databases that I have come across. I'm writing it partly for the challenge, and partly because I enjoy making Oracle work well and want to pass on some of the interesting and entertaining insights I have had. I hope you enjoy reading it and, more important, I hope you get a better feeling for what the Oracle database can do for you.

Who Is It For?

There are four stages to doing a job well:

1. Knowing what can be done
2. Knowing whether it should be done
3. Being able to do it in theory
4. Being able to do it in practice

Many of the books about Oracle currently on the market seem to focus on the finer points of the third and fourth steps. My aim is to help you with the first two, although this entails including practical observations relevant to the third and fourth steps.

This book does not exist to thrill the hard-core specialists by supplying subtle secrets and technical tweaks that will allow them to squeeze an extra half of a percent from their database. This book is here to help everyone get to a stage where they can put together a system that gives response times that are reasonable, considering the investment made in hardware, software, and human effort. Whether you are a manager, designer, database administrator, or programmer, there is something in this book for you. For the manager it gives a wide-ranging view of what Oracle is capable of and what you can expect your team to achieve. For the designer it outlines the possibilities offered by the many features of the relational database management system. For the database administrator it describes how using the right features correctly can make managing the database much easier. For the programmer (who is always keen to know how things really work) it makes it possible to connect the code that he writes to the features he is using, so that he can structure his code in the most appropriate way.

Which Version of Oracle?

A couple of years ago, a collection of information technology directors in the United Kingdom were asked what they perceived to be the biggest problems they had in managing their departments. Somewhere in the top ten was this response: the rate at which Oracle Corporation produces upgrades and new versions of their products. If Oracle keeps moving that fast, how do you pick a target when writing a book about it?

My strategy for tackling problems is the same regardless of the version of Oracle with which I'm working, so when you read this book you don't really have to worry about which version of Oracle you are using. However, I am going to focus as much as I can on Oracle 8.1.5--for the simple reason that it is the latest version (at least it was when I started writing).

It is also worth noting that Oracle 8.1.5 is the first "proper" release for some years to introduce many new features aimed at increasing the range of tasks that the database can handle efficiently and cost-effectively, which means, unfortunately, that it also introduces even more ways of allowing you to mix and match the wrong features.

Inevitably, between the time I started writing and the time this book was published, Oracle 8.1.6 went on general release. In that release, Oracle introduced features that it refers to as the analytic functions. The scope for reducing the programming effort and runtime workload on heavy-duty queries is so dramatic that I have felt compelled to include some details of analytic functions in Chapter 23.

What's in This Book?

Most of the books relating to Oracle seem to fall into one of three groups: the tuning guide, the enhanced manual, and the guide to relational database design. This book falls, I hope, outside all three groups. It works outward from the database engine itself and gives you some good ideas on how to use that engine to implement your application.

This book encourages you to consider just two important principles--how to think when designing an Oracle-based application, and how to ensure that you pick the most appropriate features of Oracle when implementing your system.

Whatever else it may be, though, this book is not a technical book. Or at least it's not a very technical book. I am not planning to go into any great and intricate detail about the internal workings of Oracle. (After all, I don't want the book to be out of date before it's published.) I do, however, take a little time to describe a couple of the central architectural features in some detail. I explain, in a simple way, the very small number of critical mechanisms that are key to the way in which the Oracle database engine works, and then I describe the ways in which these mechanisms can have a significant impact on how you have to design your application.

If you get to the end of this book feeling that it has made sense, then you are on track to avoid most of the traps that cause so many projects to end up overpriced, too complex, and poor performers.

What's Not in This Book?

There are a number of "value-added" modules that come with the Oracle relational database management system. In Oracle 8.1.5 these are known as the intermedia cartridges, and they are little applications that use the "extensible framework" of Oracle to add functionality for handling text, spatial data, time-based data, and visual data. These add-ons are excluded from this book.

I have also ignored the "Web-enabling" features of Oracle 8.1.5, namely the PL/SQL packages that can be called to pass data from Oracle tables to Web pages, the inclusion of Java as an internalized database language, and the Web application server itself. The Web interface is, after all, simply another way to use the database, and Java is just another programming language that can be used to address the database.

The last major omissions are advanced queuing and replication, partly because they are too wide ranging to be covered in a single chapter, and partly because they too fall into the area of the more exotic add-ons that are likely to be of less benefit to the general user.

Looking back at the last three paragraphs, I think they really sum up my approach to application design: The database is much more important than the language or tool that may be talking to it. And that, of course, is precisely why it is necessary for the designers and programmers to understand how the database works. It doesn't matter how wonderful the application is, or how high-tech the language is, or how user-friendly the interface is. If you try to make the database behave in an unsuitable fashion, then you are unlikely to come to the end of the project feeling like a winner.

The Framework of the Book

The book is designed as a series of self-contained essays. Each essay pulls together a number of threads that might otherwise be scattered across several of the Oracle manuals, and presents an entire topic in a fashion that helps you to identify the risks and rewards of using a particular feature of the software.

This means that there is a degree of repetition from time to time. For example, the chapter on partitioning mentions some details of parallel query, and the chapter on parallel query comments on its particular application to partitioned tables.

You may also find that there are apparent contradictions in some of the comments I make and advice that I give. At one point (Chapter 8) I describe the benefits of wasting space to reduce the administrative burden, but at another point (Chapter 13) I make several comments about rebuilding data objects to pack the data and save space. Sometimes such points are not as contradictory as they may at first seem. Sometimes it is simply the case that different demands on resources call for completely different strategies.

You may find that a number of technical issues are addressed in a rather more informal fashion than you might hope. My intention is to give the flavor of how Oracle works without worrying too much about the exact detail of the internal operations. If you are already a highly skilled operative fully conversant with the way Oracle works, please be patient. Many of the omissions and vagaries in the early stages of this book are deliberate.

The book is divided into three main parts:

1. Part 1 (Chapters 1 through 4) is a very high-level view of the Oracle engine, how it should be approached, and why so many projects using Oracle fail to achieve their objectives.
2. Part 2 (Chapters 5 through 18) approaches Oracle from the "static" viewpoint of how the data can be stored, packed, and made visible within the database.
3. Part 3 (Chapters 19 through 24) is biased toward the "processing" side of Oracle, focusing more on the dynamic side of moving data in and around the database.

There are also four appendices:

1. Appendix A is a brief summary of some of the more interesting features of Oracle 8.1.5. It contains a mixed collection of features that I think are useful. In some cases I have made a big fuss about a little feature; in other cases you may decide I have completely ignored a big feature. Just because I don't mention some new features doesn't mean they aren't of any use--it may simply mean that I haven't come across, or imagined, an environment in which they would have a significant impact on the quality, clarity, or performance of a project.
2. Appendix B contains a brief description of the limited number of tuning tasks that should be adequate for most reasonably designed systems.
3. Appendix C provides a few hints on techniques for testing the relevance of features.
4. Appendix D contains a description of the main space management features of an Oracle database.

0201715848P04062001