05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

8<br />

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS<br />

We ended up creating a very small index on just the records where the processed flag was<br />

N, which provided quick access to the records of interest.<br />

Was that the end of the story? No, not at all. The developers still had a less than optimal<br />

solution on their h<strong>and</strong>s. We fixed their major problem, caused by their not fully underst<strong>and</strong>ing<br />

the tools they were using, <strong>and</strong> found only after lots of study that the system was not nicely<br />

instrumented. We didn’t yet address the following issues:<br />

• The application was built without a single consideration for scalability. Scalability is<br />

something you have to design for.<br />

• The application itself could not be tuned or touched. Experience has shown that 80 to<br />

90 percent of all tuning is done at the application level, not at the database level.<br />

• The application was performing functionality (the queue table) that the database<br />

already supplied in a highly concurrent <strong>and</strong> scalable fashion. I’m referring to the<br />

Advanced Queuing (AQ) software that is burned into the database, functionality<br />

they were trying to reinvent.<br />

• The developers had no idea what the beans did in the database or where to look for<br />

potential problems.<br />

That was hardly the end of the problems on this project. We then had to figure out<br />

• How to tune SQL without changing the SQL. <strong>Oracle</strong> 10g actually does permit us to<br />

accomplish this magical feat for the first time to a large degree.<br />

• How to measure performance.<br />

• How to see where the bottlenecks are.<br />

• How <strong>and</strong> what to index.<br />

• And so on.<br />

At the end of the week, the developers, who had been insulated from the database, were<br />

amazed at what the database could actually provide for them, how easy it was to get that<br />

information <strong>and</strong>, most important, how big a difference it could make to the performance of<br />

their application. In the end they were successful—just behind schedule by a couple of weeks.<br />

This example is not meant to be a criticism of tools or technologies like EJBs <strong>and</strong><br />

container-managed persistence. Rather, it is a criticism of purposely remaining ignorant of<br />

the database, how it works, <strong>and</strong> how to use it. The technologies used in this case worked<br />

well—after the developers gained some insight into the database itself.<br />

The bottom line is that the database is typically the cornerstone of your application. If it<br />

does not work well, nothing else really matters. If you have a black box <strong>and</strong> it does not work<br />

well, what are you going to do about it? About the only thing you can do is look at it <strong>and</strong> wonder<br />

why it is not doing so well. You cannot fix it; you cannot tune it. You quite simply do not<br />

underst<strong>and</strong> how it works—<strong>and</strong> you made the decision to be in this position. The alternative is<br />

the approach that I advocate: underst<strong>and</strong> your database, know how it works, know what it can<br />

do for you, <strong>and</strong> use it to its fullest potential.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!