As the book's tittle expresses it involves examples, recipes, different test cases for almost all topics in the chapters. This is great, because just definitions and descriptions are not enough to fully understand the concept (especially) in a performance tuning book.
Book covers the most important performance tuning topics for an Oracle database. You'll find it useful even you're a developer or a dba. It describes the tuning methods with different aspects. Performance tuning is not like many other Oracle database topics becuse there is not a general "true" many times. A tuning method may halve the job duration in a database, where it may double the time for another database. This is the most important fact that you need to know when searching for tuning recommendations. The data type, database structure is very important in evaluating a tuning method. This book is explaining the tuning methods with almost every aspects. In which conditions we should use it or not and why. Here i want to share some highlighted parts of the topic "Index Clusters" which i think will help you see what i mean.
The major benefit of using clusters is in reduced I/O for accessing data from different tables joined together, reducing even the space occupied by the cluster key that is stored once for all the rows of all the tables participating in the cluster, which have the same key value.
An index cluster works as an ordinary index, speeding up access to the rows with a specific cluster key value.
The benefits of using clusters are reduced when we regularly access a single table of the cluster or when we perform more DML operations—insert, update, and delete—than select. The reason for this performance delay is that storing rows from more than one table in the same database block, forces the engine to read a greater block than in the case of a standard table; full table scan performance is affected by the same issue, which causes poor performance in DML operations. This is because by updating an (eventually) small row in a table of the cluster, all the blocks containing the rows for the particular cluster key affected will be read and manipulated.
if the rows for a cluster key value cannot be stored in few (1-2) database blocks, clusters are not a good choice.
Consider introducing clusters in situations where data is almost static and you often query joined together tables.
Due to the particular storage characteristics of a clustered table, we cannot perform a TRUNCATE TABLE statement, because the database blocks are shared among the tables in the cluster. The only way to eliminate the rows is with the DELETE command. If we need to use the TRUNCATE TABLE statement on a table, clustering is not a choice.
I'm sure readers will learn a lot of useful information from this book. You can find more information and TOC here: