Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 1 ■ ■ ■ Developing Successful Oracle Applications 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 18 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, they would be • An application built around the database—dependent on the database—will succeed or fail based on how it uses the database. Additionally, in my experience, all applications are built around databases. I cannot think of a single useful application that does not store data persistently somewhere. • Applications come, applications go. The data, however, lives forever. In the long term, the goal is not about building applications; it really is about using the data underneath these applications. • A development team needs at its heart a core of database-savvy developers 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) typically means you did not give serious thought to these concerns during development. These may seem like surprisingly obvious statements, but I have found that too many people approach the database as if it were a black box—something that they don’t need to know about. Maybe they have a SQL generator that they figure will save them from the hardship of having to learn the SQL language. Maybe they figure they will just use the database like a flat file and do keyed reads. Whatever they figure, I can tell you that thinking along these lines is most certainly misguided: you simply cannot get away with not understanding the database. This chapter will discuss why you need to know about the database, specifically why you need to understand • The database architecture, how it works, and what it looks like. • What concurrency controls are, and what they mean to you. • That performance, scalability, and security are requirements to be designed into your development efforts, not something to hope you achieve by accident. 1
2 CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS • How features are implemented in the database. The way in which a specific database feature is actually implemented may not be the way you might envision. You have to design for how the database works, not how you think it should work. • What features your database already provides for you and why it is generally better to use a provided feature than to build your own. • Why you might want more than a cursory knowledge of SQL. • That the DBA and developer staff members are fighting for the same cause; they’re not two enemy camps trying to outsmart each other at every turn. This may initially seem like a long list of things to learn, but consider this analogy for a second: If you were developing a highly scalable, enterprise application on a brand-new operating system (OS), what would be the first thing you would do? Hopefully, your answer is, “Find out how this new OS works, how things will run on it, and so on.” If you did not do this, your development effort would fail. Consider, for example, Windows versus Linux. Both are operating systems. Each provides largely the same set of services to developers, such as file management, memory management, process management, security, and so on. However, they are very different architecturally. Consequently, if you’re a longtime Windows programmer and you’re asked to develop a new application on the Linux platform, you would have to relearn a couple of things. Memory management is done differently. The way in which you build a server process is considerably different. Under Windows, you develop a single process, a single executable, with many threads. Under Linux, you do not develop a single stand-alone executable; instead, you have many processes working together. In summary, much of what you learned in the Windows environment doesn’t apply to Linux (and vice versa, to be fair). You have to unlearn some old habits to be successful on the new platform. What is true of applications running natively on operating systems is also true of applications that will run on a database: you need to understand that the database is crucial to your success. If you do not understand what your particular database does or how it does it, then your application is likely to fail. If you assume that because your application ran fine on SQL Server, it will necessarily run fine on Oracle then, again, your application is likely to fail. And to be fair, the opposite is true: a scalable, well-developed Oracle application will not necessarily run on SQL Server as is without major architectural changes. Just as Windows and Linux are both operating systems, but fundamentally different, so Oracle and SQL Server (pretty much any database could be noted here) are both databases, but fundamentally different. My Approach Before you read further, I feel I should explain my approach to development. I tend to take a database-centric approach to problems. If I can do it in the database, I will. There are a couple of reasons for this, the first and foremost being that I know if I build functionality in the database, I can deploy it anywhere. I am not aware of any popular server operating system on which Oracle is not available; from Windows, to dozens of UNIX/Linux systems, to the OS/390 mainframe, the same exact Oracle software and options are available. I frequently build and test solutions on my laptop running Oracle9i, Oracle 10g under Linux, or Windows XP using VMware to emulate either environment. I am able to then deploy these solutions on a variety
- Page 2 and 3: Expert Oracle Database Architecture
- Page 4 and 5: Contents Foreword . . . . . . . . .
- Page 6 and 7: ■CONTENTS v Block Buffer Cache .
- Page 8 and 9: ■CONTENTS vii ■CHAPTER 9 Redo a
- Page 10 and 11: ■CONTENTS ix ■CHAPTER 12 Dataty
- Page 12 and 13: Foreword “THINK.” In 1914, Thom
- Page 14 and 15: ■FOREWORD xiii Tom is an aficiona
- Page 16 and 17: About the Technical Reviewers ■JO
- Page 18 and 19: Introduction The inspiration for th
- Page 20 and 21: ■INTRODUCTION xix • Exposure to
- Page 22 and 23: ■INTRODUCTION xxi Chapter 3: File
- Page 24 and 25: ■INTRODUCTION xxiii Next up are t
- Page 26 and 27: Setting Up Your Environment In this
- Page 28 and 29: ■SETTING UP YOUR ENVIRONMENT xxvi
- Page 30 and 31: ■SETTING UP YOUR ENVIRONMENT xxix
- Page 32 and 33: ■SETTING UP YOUR ENVIRONMENT xxxi
- Page 34 and 35: ■SETTING UP YOUR ENVIRONMENT xxxi
- Page 36 and 37: ■SETTING UP YOUR ENVIRONMENT xxxv
- Page 38 and 39: ■SETTING UP YOUR ENVIRONMENT xxxv
- Page 40 and 41: ■SETTING UP YOUR ENVIRONMENT xxxi
- Page 42 and 43: ■SETTING UP YOUR ENVIRONMENT xli
- Page 44 and 45: ■SETTING UP YOUR ENVIRONMENT xlii
- Page 48 and 49: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 50 and 51: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 52 and 53: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 54 and 55: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 56 and 57: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 58 and 59: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 60 and 61: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 62 and 63: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 64 and 65: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 66 and 67: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 68 and 69: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 70 and 71: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 72 and 73: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 74 and 75: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 76 and 77: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 78 and 79: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 80 and 81: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 82 and 83: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 84 and 85: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 86 and 87: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 88 and 89: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 90 and 91: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 92: CHAPTER 1 ■ DEVELOPING SUCCESSFUL
- Page 95 and 96: 50 CHAPTER 2 ■ ARCHITECTURE OVERV
CHAPTER 1<br />
■ ■ ■<br />
Developing Successful<br />
<strong>Oracle</strong> Applications<br />
I spend the bulk of my time working with <strong>Oracle</strong> database software <strong>and</strong>, more to the point,<br />
with people who use this software. Over the last 18 years, I’ve worked on many projects—<br />
successful ones as well as complete failures—<strong>and</strong> if I were to encapsulate my experiences<br />
into a few broad statements, they would be<br />
• An application built around the database—dependent on the database—will succeed<br />
or fail based on how it uses the database. Additionally, in my experience, all applications<br />
are built around databases. I cannot think of a single useful application that does<br />
not store data persistently somewhere.<br />
• Applications come, applications go. The data, however, lives forever. In the long term,<br />
the goal is not about building applications; it really is about using the data underneath<br />
these applications.<br />
• A development team needs at its heart a core of database-savvy developers who are<br />
responsible for ensuring the database logic is sound <strong>and</strong> the system is built to perform<br />
from day one. Tuning after the fact (tuning after deployment) typically means you did<br />
not give serious thought to these concerns during development.<br />
These may seem like surprisingly obvious statements, but I have found that too many<br />
people approach the database as if it were a black box—something that they don’t need to<br />
know about. Maybe they have a SQL generator that they figure will save them from the hardship<br />
of having to learn the SQL language. Maybe they figure they will just use the database<br />
like a flat file <strong>and</strong> do keyed reads. Whatever they figure, I can tell you that thinking along these<br />
lines is most certainly misguided: you simply cannot get away with not underst<strong>and</strong>ing the<br />
database. This chapter will discuss why you need to know about the database, specifically why<br />
you need to underst<strong>and</strong><br />
• The database architecture, how it works, <strong>and</strong> what it looks like.<br />
• What concurrency controls are, <strong>and</strong> what they mean to you.<br />
• That performance, scalability, <strong>and</strong> security are requirements to be designed into your<br />
development efforts, not something to hope you achieve by accident.<br />
1
Change language