You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
Oracle forecasting/predictive analysis is my other area of expertise. In fact, I wrote the first book on the subject entitled, Forecasting Oracle Performance. But this topic is clearly not the focus of this book. However, I will take some key concepts from forecasting, creating a bridge between firefighting and forecasting. This bridge will allow you to naturally switch between these subject areas and also help in communicating the performance issues and possible solutions.
New features and functions are a lot of fun, and they are important. But they are no substitute for pinpoint diagnosis, a solid methodology, and an understanding of Oracle's core algorithms. I find new feature and function type classes very useful in coming up with creative solutions to a well-diagnosed and defined problem. This book is not focused on new features and functions in the traditional sense. Only when a change in Oracle's kernel affects the subject matter of this book will it be mentioned. Otherwise, this book would become very Oracle version-specific, joining many other massive, and of relatively limited value, Oracle books on the market today.
Interesting yet not useful Oracle internals are simply not covered. Just how deep do we go into Oracle internals? This is a question I grapple with daily. Everyone involved with Oracle, from the kernel architect to the businessperson, abstracts Oracle internals in some way. Since each of us has limited time and specific responsibilities, it behooves us to go only as deep as we must and abstract wherever we can. So, I only go as deep into the internals as necessary to clearly diagnose the problem, arrive at solutions, and communicate my work to others (both the technical and the nontechnical). This means I miss out on certain cocktail party conversations, but I can cover a much larger breadth of technology and get the job done.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|