INTRODUCTION: THE BOOK EXPLOSION
A casual scan of the bookshelves at any large
bookstore reveals an interesting trend: There are more and more
Oracle books available today, from an increasing number of
publishers. The number of new titles has exploded just in the last
few years—almost as fast as Oracle releases new database versions!
This huge expansion of new titles also means
that there are lots of opportunities for new writers. Presumably,
these books are all being published because there really is a big
demand for good database books. To exploit these opportunities,
however, some preparation is required. The question is, how should
the aspiring writer get started? What is involved?
In this article we explore one author’s
experience in writing a technical book about Oracle. We will
answer questions such as:
How much time is required?
How difficult is it really?
How do I gain credibility?
Where do I start?
How does the edit process work?
Is it worth the effort?
For Oracle DBAs, designers or developers
interested in writing a book on Oracle (or any other technical
subject), I hope you find my experience useful. Perhaps this
information will save you some time, or alleviate some concerns. I
do not claim to be an expert on publishing books, but I think my
experience could be useful to you if you are considering writing a
HOW MUCH TIME IS REQUIRED?
As the dot-com bubble was starting to burst a
few years ago, it became likely that in the (near) future I would
have some spare time on my hands. It dawned on my one afternoon
that I could use this extra time to do something that I had
considered for some time—write a book on Oracle performance
tuning. I wanted to write a book more for the beginner, as opposed
to the very sophisticated books really intended just for the
I have always enjoyed performance tuning and
other database “mysteries,” and I wanted to show the novice
performance tuner how to get started. I wondered, however, how
much time would be required. Could I keep up with tough editing
I was fortunate enough to have someone who
could help me get started. Don Burleson, editor of Oracle
Internals and author of numerous Oracle books, was kind
enough to offer some suggestions. He estimated that a first book
would require an investment of 360 hours.
Don was very accurate. Here is the breakdown
of my actual time spent writing and editing the book:
240 hours for the
130 hours for the
first set of edits
15 hours for
answering questions during the second edits.
You can see that my total time investment was
385 hours. This time was spread-out over 6 months or so. This
means that I spent about 15 hours each week just working on the
HOW DIFFICULT IS IT, REALLY?
If you were to just look at the number of
hours required, you might get the impression that the whole job is
really pretty simple. Just 15 hours a week—how tough can that be?
Nevertheless, if you were to begin a
book-writing project with the idea that it is going to be easy,
you would be sadly mistaken. That 15 hours per week is a very
tough 15 hours. To my surprise, I discovered that writing a book
is far more difficult than writing technical papers.
Why is it so difficult? For one thing, the
scope of the job is much broader than a single technical article.
For a single article, you can become the subject matter expert
without spending an enormous amount of effort. Now, compare that
to writing about 20 technical papers! That roughly gives you an
idea of the work involved.
Another big hurdle is the need for technical
accuracy and timeliness. The book I wrote was about 400 pages,
which is not really very large for a technical book. Nevertheless,
for each of the 14 chapters, I needed to be technically accurate,
clear, and up to date.
In the Oracle world of fast database
releases, techniques and ideas that are technically accurate in
one database release may be outdated in the next. I discovered
that some processes and techniques that I used had become obsolete
with Oracle 9i. For instance, my method of gathering statistics
using the Analyze command is really on the way out. Thus, I
found it necessary to research and document the newer method
suggested by Oracle. There were other techniques that I had to
research as well.
HOW CAN I GAIN CREDIBILITY?
Publishers are interested in selling lots of
copies of the books they publish. They can more easily do this if
they sign-up an author who is already well known, or at least has
some impressive credentials. These well-known authors are
oftentimes the speakers you see at the large national Oracle
conferences; they draw a huge crowd every time they speak.
Remember the saying, “Nobody except a
blockhead ever wrote, except for money? This is true for
publishers as well as writers. Publishing houses are not in the
business of printing books for charity; they want to maximize the
chances of success. That means either using an established name
(e.g., Kevin Loney, Rich Niemiec, Thomas Kyte), or using an author
who has otherwise proven his or her writing ability. In other
words, the publisher wants someone with credibility.
Probably the easiest way to enhance your
credibility is to write articles for technical journals. Besides
the local user groups, they are numerous technical journals that
are happy to review submissions—even from unknown writers.
Many popular Oracle authors have used this
strategy. For instance, Don Burleson advertises that he has penned
over 100 articles! In contrast, why would a publisher listen
seriously to someone who has not bothered to publish even a single
WHERE DO I START?
Before your book project can start, the
publisher will want to see a detailed proposal for your book idea.
This proposal should include an analysis of the market for your
book, the anticipated competition, plus detailed chapter outlines.
I wrote the original proposal for The Art
and Science of Oracle Performance Tuning in December of 2001.
Although very supportive, the first publisher I contacted already
had contracted for a book on a similar topic. Naturally, they did
not want to compete with their own book.
The second publisher I contacted,
Curlingstone (subsidiary of WROX), was interested in reviewing the
proposal. I emailed the book proposal to Curlingstone, and they
hired a small group of highly respected DBAs to review my
proposal. (At the time, I didn’t know that Curlingstone had
signed-up such a renowned team.).
If your proposal fits the needs of the
publisher, they will offer you a contract. They will possibly want
you to consider certain changes, based on the comments from the
reviewers. In my case, the senior editor wanted me to consider
including material on ways to prevent performance problems.
I agreed to include this whenever possible.
If you think that you will get rich from your
book royalties, think again. As part of your compensation, you will also given a
handful of free copies.
HOW DOES THE EDIT PROCESS WORK?
Once you have completed your draft of the
entire book, you will enter the editing phase, in which you work
with one or more editors assigned by the publisher. I found the
editors a very reasonable and professional group of people. They
did not claim to be super DBAs, but they were certainly very
The publisher will hire a review team who are
experts in the field. They will review each chapter, and make
suggestions on where the manuscript could be improved. You will
then have to review their comments and make appropriate changes.
I found this stage to be very trying, and
much harder than I thought. Consider this: Every paragraph of
every page in your book is subjected to intense scrutiny by a
group of people you probably don’t even know. Although my
reviewers were well qualified, I found it to be no fun to have my
writing subjected to such a rigorous critique.
Of course, the final product was undoubtedly
much better because of this review, but that doesn’t make it any
more fun! (A football player may become a better athlete by
“running the gauntlet,” but he probably doesn’t look forward to
The reviewers will be of varying skill levels
and backgrounds. At times, they may become confused, or you may
believe that their comments are completely wrong. For instance,
the main technical editor suggested that 50% of the OS-specific
material should be Windows. He wanted to substantially trim
down the Unix section and add much new material on Windows.
My experience has been that Unix is a much more important
platform, so I argued against his suggestion. (I ended up adding
several pages on Windows, but not removing any of the Unix
At other times, the reviewers may contradict
each other, and you will have to use your own judgment. I remember
one section toward the end of a chapter. Here is what two
reviewers said about the same section:
Since I was aiming for controversy in the
book, I left this section unchanged. If nothing else, I felt it
would get a good discussion going.
In another chapter, where I talked about
indexing, here is what two other reviewers said:
Once again, my theory was confirmed: If you
get 10 DBAs in a room together, you will get 10 different “right”
ways to do something.
I found the most helpful suggestions to be
comments such as “I don’t understand what you’re saying.” This
type of comment told me that I had not really communicated well. I
almost always took action to modify a section whenever a reviewer
made a comment like this.
Keep in mind that the reviewers’ comments are
mostly suggestions and observations based on their personal
experience. Rarely are technical issues so black and white that
there is really only one correct answer. Of course, you would be
wise to seriously consider most remarks; by doing so, I learned
quite a bit from the reviewers. Naturally, errors in syntax or
usage should always be corrected.
After the first stage of edits, things move
rapidly. I was surprised at how quickly the editors incorporated
and reviewed all the changes. There were actually only a few
remaining technical questions, plus some formatting difficulties.
(Did you ever notice, for example, exactly how the output is
formatted in Sql*Plus for numbers versus text?)
OFF TO THE PRINTERS!
Once all the edits and reviewer questions
have been addressed, there are just a few more minor issues to
handle. You will have the opportunity to write/review a few
preliminary sections, such as the Introduction,
Acknowledgements, and Dedication sections. I found
these to be very simple.
Finally, when you have answered all the
editors’ questions, and the proofreaders have blessed the work, it
will be sent to the printers. There’s really little for you to do
at this point, except relax!
AFTERWORD: WAS IT WORTH THE EFFORT?
Writing a technical book about Oracle
databases is a formidable challenge. I found it to be one of the
most difficult things I have ever done. Ironically, I could not
have done it without the big “dot-com meltdown.” I simply would
not have had the time.
For me, the toughest part in writing The
Art and Science of Oracle Performance Tuning was wading
through the myriads of comments from the technical reviewers.
Facing a huge amount of critical comments can really test your
There really isn’t any other way, however. No
one has all the answers; everyone makes lots of mistakes. This
means that an extensive review process is necessary in order to
build a good product.
Now that it’s all over, I can look back and
smile. I have learned a lot more about Oracle, and some of my
faulty ideas have been corrected. (Not all, though, I still have a
Now, getting back to those reviewer comments
. . .
Chris Lawson is a DBA consultant and author
of The Art and Science of Oracle Performance Tuning (Curlingstone).
He specializes in performance tuning of data warehousing and
financial applications. Chris is also the editor of the online
magazine, The Oracle Magician, available at