Who needs Scalability Rules?

Looking at the fifty rules divided up this way, summarizing the book becomes easier  but still a bit muddled.  For example I might ask the question, Who exactly is the book’s audience?  Is it application developers?  Certainly, there is a large section of rules designed for them.  Or maybe it's for the operations team, offering advice on how to design systems, networks and data centers, and advice for optimizing and redirecting development efforts?  Or maybe it is a book for managers, as the people and process related rules certainly are targeted towards those folks.  But if that's the case then much of the book is probably too technical for such an audience.

Ok, so let's step back, when or why might you have all these crisscrossing themes and roles?  The answer is that like me, the authors are consultants and in the course of engagements a consultant is often asked to wear many different hats.  So sometimes we're looking at scalability in regards to operational decisions, while at other times we're looking at scalability through the lens of application design decisions. And still other times scalability can best be achieved by focusing on people and processes. I’d add that not only is this a handy reference for consultants, but for any bootstrapping startup as well. Coders these day are expected to be at least a little bit knowledgeable with web operations, and vice-versa.  Especially pushing towards the guiding principles of devops, this book can help engineers take a critical look at their roles within an organization.

Looked at in that light you can really see how this book is truly an opus of knowledge on scaling web sites.  Although the organization is sometimes confusing, it will surely bring insights and enlightenment to all of your teams, whether operations, devs, managers, or business units.

Stumbling onto 800-CEO-Read, and their top books feature, I found Brogan and Smith's work.  Brogan's blog intrigued me enough so I walked down to the Strand here in NYC to pick up a copy.

What I found was an excellent introduction to the nebulous world of social media marketing, where you find all sorts of advice and suggestions on how to engage your target audience.  If you're feeling like an ignoramus on matters of social media, Trust Agents is a great place to start and will give you ideas of how to 'humanize' your digital connections.

The authors illustrate the Trust Agent idea with Comcast Cares for example and how they engaged customers, and what worked so well for them.  Or Gary Vaynerchuk and his game changing Wine Library TV about wine.  He also emphasizes that building relationships online is a lot like building relationships in the real world a la Keith Ferrazzi of Never Eat Alone fame.  Engage in meaningful ways with people, don't market to them. Share valuable tidbits, and the community will reward you tenfold.

A 'trust agent'  lives by six principles:

1. Make your own game - be willing to take risks and break from the crowd
2. Be 'One of Us' - be part of the community by doing your bit and contributing to it
3. The Archimedes Effect - leverage your own strengths wisely
4. Agent Zero - position yourself at the center by connecting people and groups
5. Human Artist - learn how to work with people; help others and be conscientious of etiquette
6. Build an Army - you need allies to help spread your ideas

The book is excellent.  Put it on your holiday list.

Effective MySQL: Optimizing SQL Statements

by Ronald Bradford

No Nonsense, Readable, Practical, and Compact

I like that this book is small; 150 pages means you can carry it easily.  It's also very no nonsense.  It does not dig too deeply into theory unless it directly relates to your day-to-day needs.  And those needs probably cluster heavily around optimizing SQL queries, as those pesky developers are always breaking things

Jokes aside, this new book out on Oracle Press is a very readable volume. Bradford has drawn directly from real-world experience to give you the right bite size morsels you need in your day-to-day MySQL activities.

Highlights

Chapter one, The Five Minute DBA gives you the basic methodology if you don't already know it.  Enable the slow query log, analyze it, and use the explain facility.  Then index as appropriate, or eliminate queries if you can.

Chapter two digs a little deeper into the basics, introducing explain extended, table statistics and storage engines.  You'll also learn how to use show session & global status, as well as session & global variables.  You'll also have your first look at MySQL's data dictionary - INFORMATION_SCHEMA.

Chapter three is where it starts to get meaty.  You probably know that MySQL has b-tree indexes, but did you know that it has b+tree indexes, or hash indexes?

Chapter four digs into indexes further with single & multi-column indexes using them for sorting and joining.  You'll also find out about covering indexes which are multi-column matching the where clause, but also including columns needed in the SELECT predicate.  Do you have duplicate or unused indexes?  You'll learn why they matter to performance and how to eliminate them with tools like mk-duplicate-key-checker.

Chapter five continues along the same lines, with more coverage of indexes.  Learn to identify when you are using a covering index, fulfilling the entire query by only accessing the index.  You'll also learn about partial indexes, how they can reduce the size of index storage and retrieval while still getting your data for you.

Chapter six covers configuring the server itself, hitting on the system variables such as the innodb buffer pool (innodb_buffer_pool_size) and key buffer (key_buffer_size) as well as the query cache.  You'll also learn how to set the four main session memory settings - sort buffer (sort_buffer_size) and join buffer ( join_buffer_size) as well as the lesser known read buffers (read_buffer_size and read_rnd_buffer_size).

Chapter seven is all about the process of tuning and optimizing MySQL.  Rolling all the previous sections into marching orders, and prescriptive advice, he takes you through step by step how to apply the principles.  You'll get an introduction to mk-query-digest (though strangely without attribution to Baron Schwartz), the great maatkit tool for query analysis and aggregation, as well as the microsecond precision patch, which allows your mysql shell client to display more exact timing data.  For the patch he links back to an article on his own site which seems to be not found.  The author of the high precision mysql timer patch is Stewart Smith.

I personally got the most out of Chapter eight, full of self-described hidden performance tips.  From identifying unused or duplicate indexes, to replacing inefficient data types with better ones, why it's important to use NOT NULL where possible or how to store IP addresses efficiently, this chapter has a lot of goodies.  For those still struggling with SQL statement tuning, there are a few patterns that are described, offering advice on how to rewrite a subquery as an inner join,

What you might not know

• MySQL includes Oracle's index organized tables by a different name
• Too many indexes can dramatically impact INSERT & UPDATE performance
• Many DDL operations can be done online - see oak-online-alter-table (Shlomi Noach)
• Datatypes matter - use enum, int unsigned, timestamp & not null where possible
• Covering indexes are your friend, duplicate & unused indexes are not!
• A replication slave can have different storage engines or indexes from the master. These can support different uses - such as data warehousing or non-transactional requirements.
• While a_string LIKE '%end of my sentence.' won't use an index, you can index reverse_string, then use reverse_string LIKE REVERSE '%end of my sentence.' and MySQL will use this index.  You've simulated an advanced Oracle feature, reverse key indexes!

A few small gripes

If I were to add a few complaints it would be to say that some of the examples were rather simplistic.  In many cases tuning SQL is not as simple as just adding the right index.  For instance there was no good discussion of the dreaded "using temporary, using filesort" that we see a lot in MySQL explains when sorting has to be done, but will not fit in memory.  Or what about tmpdir=/dev/shm, how will that improve things?  What about UNION versus UNION ALL where appropriate.  Why does DISTINCT do a sort?

The book was also missing a discussion of triggers, stored procedures, when or if the query cache can cause problems and so forth.  Also the article link mentioned about chapter seven isn't the only missing link.  I followed links to optimizing sql  statements and it seems to go to a generic holding page.  Also the main link effectivemysql.com/book leads to an outline of an as yet unreleased title on Backup and Recovery.

All in all, well worth your money

However, other than these few gripes the book overall is a very welcome addition to the small family of MySQL books.  Get a copy quick before they're all gone!

What do you do after founding not one, but two companies and watching them fail miserably all by the time you were barely out of college?

Move to the Valley, make shrewd investments in other startups and become insanely rich like Sean Parker? A Bit lofty perhaps. How about try, try again and succeed. Then reinvent yourself as a guru dishing out startup wisdom through your blog and publishing a book that ends up the top of the New York Times Bestseller's list. That's essentially what Eric Ries, author of The Lean Startup did.

True entrepreneurs fail many times before they succeed and continuously find opportunities to reinvent themselves. Ries is one of them. He's taken all that he's learned from his failures, and later successes, from his college years in the 1990s right through the dotcom crash, and packaged them into a guide for startups to consult in their quest for world domination. 

Like any business or management book that wants to capture readers' attention The Lean Startup has ground-breaking ideas or rather something that challenges traditional thinking.

How to be lean and light-footed

One of  the main themes is that startups can stay lean and light-footed - and in the process avoid millions of dollars in sunk costs on failed ideas - by  discovering what customers want as they are developing the product itself. Ries advocates a Minimum Viable Product, that is when rolling out new products companies can already run and even charge, before they decide whether the blue or the red version is going to sell more. From there on the process of improving and perfecting the product is a continuous one through listening to what customers want, although not through their written feedback but rather through their actions. This favors scientific methods of decision-making over what is viewed as failure prone hunches and guess work. And it makes sense for startups who simple don't have the financial resources to take big risks.

Written in simple down-to-earth prose, The Lean Startup is an easy and quick read with sufficient real world examples. The good thing about books these days is they don't have to end up as dated publications. Since Ries is building a brand around the whole methodology, one can find additional resources and discussions it in his blog (where it all began anyway), and through Lean Startup circles and wikis.

Help! How To Become Slightly Happier and Get a Bit More Done

I've long overcome that sheepish feeling when browsing the Self-help section at the bookstore. Sure, How to Make Friends and Influence People or the Seven Steps to World Domination in your bookcase aren't exactly the sort of titles to suggest a deep intellect but I like to keep an open mind when checking out the latest hardcover secret to happiness and prosperity. Basically I try not to diss a book just because it's got "soup" on the cover.

I will concede that publishers have gone a bit overboard with churning out the number of self-help titles in the last 20 years or so. As with anything that proliferates you're stuck with having to wade through the swamp of well, BS. HELP! How to Become Slightly Happier and Get a Bit More Done by Oliver Burkeman is ideal for those curious enough about self-improvement but too cool to buy into mind-body-soul mantras.

Since 2006 Burkeman has been writing a column in The Guardian, self-mockingly titled, This Column Will Change Your Life. It has garnered a large enough following and accumulated a substantial amount of content to warrant a book version or if you like, a best-of collection.

Approaching the subject with rational skepticism, Burkeman has made it his mission to sort through the best and the worse of self-help literature to tell us what works and what doesn't. He doesn't hesitate to call out the snake oil salesmen nor does he dismiss all self-help advice as hokum because he genuinely believes there is something we can all learn from research in human-happiness, however flawed.

I reckon Burkeman's greatest achievement is his ability to strip down what has been pedaled as new enlightenment by the self-help gurus, into realistic terms with wry humor and wit. I say realistic, because he reminds us that self improvement is a lifelong project for anyone who cares to make the effort, and it would be ridiculous to take a prescriptivist approach. From managing your inbox to procrastinating less, the topics he tackles are easy to relate to; for example, why your friends' Facebook statuses usually make their lives seem more awesome than they actually are or his explanation of the Color of the Bike Shed phenomenon, where the time spent on any item is inversely related to its cost and importance.

Although I sometimes wonder why buy a book when you can read all its contents online, Burkeman's writing has obviously been compelling enough for its publishers to re-release the title with a new so-called mass-market cover (notice the cute belly-up turtle). Even if it doesn't change your life, HELP! will definitely entertain.

Spencer Johnson is a great writer.  His business book classic was a real page turner.  He takes a page from the REWORK book and that's a good thing.

Who Moved My Cheese is a story about mice living in a maze happy and content that they have an unlimited supply of cheese.  Then one day the cheese runs out.  Some approach this new reality by sniffing, and scurrying.  Before long they find new cheese, and more opportunities than they had before.  Some other mice hem and haw, and resist the new reality, pointing fingers, getting angry, but not facing the situation.

Of course these are situations we all face everyday.  Outsourcing changes the job landscape, technologies such as the internet disrupt established industries like newspapers, music, and media.  What's more the recent upheaval in the financial industry had at least some basis in the computerization of trading, and the acceleration of global markets.

The landscape is always changing.  Johnson's book speaks great lessons that we can all understand, and benefit from everyday in business.

Find Who Moved My Cheese on Amazon.

Rework is chock full of ideas

Jason Fried and David Heinemeier Hansson's new book REWORK is one of the best startup business books I've read since Alan Weiss' Million Dollar Consulting. If you're already a fan of their signal vs noise blog, you'd be familiar with their terse style. Sharp and to the point.

Which is why you can pick it up and read it in a few hours.  You'll want to because it's well written and pared down to essentials.  In fact the book reads like their workflow advice, less mass, do it yourself, cut out the fat, concentrate on essentials.  As such they are clearly practicing what they preach, which I like.

This book isn't really for large businesses and corporate success.  It's for startups, and freelancers, and small teams.  It focuses on how and why you should do something yourself before outsourcing it so you can learn what to look for.

Here are some choice quotes from the book:

1. The menus in failing restaurants offer too many dishes.
2. When you impose a deadline you gain clarity.
3. Timeliness is more important than polish
4. Reality never sticks to best-case scenarios.
5. Do less than your competitors to beat them.
6. Share information that's valuable and you'll slowly build a loyal audience.
7. Trade the dream of overnight success for slow, measured growth.
8. Getting back to people quickly is the most important thing you can do in customer service.
9. Optimize for now and worry about the future later.
10. You don't need more hours you need better hours.

In fact I started out with a list of my favorite twenty quotes from the book and cut it down to these ten.  Go get this book, you'll be glad you read it.

Find REWORK on amazon

In search of a good book on Chef itself, I picked up this new title on O'Reilly.  It's one of their new format books, small in size, only 75 pages.

There was some very good material in this book.  Mr. Nelson-Smith's writing style is good, readable, and informative.  The discussion of risks of infrastructure as code was instructive.  With the advent of APIs to build out virtual data centers, the idea of automating every aspect of systems administration, and building infrastructure itself as code is a new one.  So an honest discussion of the risks of such an approach is bold and much needed.  I also liked the introduction to Chef itself, and the discussion of installation.

Chef isn't really the main focus of this book, unfortunately.  The book spends a lot of time introducing us to Agile Development, and specifically test driven development.  While these are lofty goals, and the first time I've seen treatment of the topic in relation to provisioning cloud infrastructure, I did feel too much time was spent on that.  It could have been better spent discussing cloud topics generally, and the chef architecture.  For instance a discussion of chef-solo was missing and the reader is plainly led towards the opscode hosted chef-server, rather than explaining the architecture, pros and cons of managing it yourself, and so forth.

By far my biggest beef with this title was that they waited to discuss the meat of provisioning infrastructure, ie bootstrapping an Amazon EC2 instance with Chef, until five pages from the end of the book!  The other complaint I had is that there were some glaring typos, like the itemized list of steps to setup the opscode platform on pages 16 & 17.

Since there aren't a lot of titles on the market yet covering Chef, you still might want to pickup this one, but I'm more eagerly awaiting Mr. Nelson-Smith's next title and more general introduction to the topic.

Related links:

Risks & Implications of Infrastructure as Code

Chef Download Page - Opscode

Discussion of Extreme Programming

Stephen Nelson-Smith's great blog

Macrowikinomics follows on the success of the best selling Wikinomics.  It hits on a lot of phenomenal success stories, such as the Linux project, which has over a roughly twenty year history, produced 2.7 million lines of code per year and would have cost an estimated 10.8 billion that billion with a b, dollars to create by conventional means.  What's more it's estimated the Linux economy is roughly 50 billion.  With huge companies like Google, and Amazon Web Services built on datacenters driven principally by Linux it's no wonder.

They also draw on the successes of companies like Local Motors who use collaboration and the internet in new and innovative ways.

In total this book speaks to the disruptive power of the internet and new technologies, and offers a lot of hopeful stories and optimism about where they are taking us.  Food for thought.

Puppet is a configuration management tool that can be used to great advantage managing the configurations of a large fleet of servers in an enterprise.

My first thought upon finishing Turnbull & McCune's book was that it could well have been titled Pro Deployments, for it covers a whole host of topics, integrating Puppet with a lot of other related tools.

Some of the advanced topics it covers in depth include:

• integrating Puppet with version control such as git
• setup of the standard dev, test and production environments
• conditional application of generalized configs
• managing nagios & load balancer configs to automatically add new nodes
• capitalizing on puppet forge modules (like rpm packages)
• testing your puppet configs with cucumber
• reporting with the dashboard and the command line

I found it a strong title overall, well written, technical and broad brushed.  Unfortunately I found it sorely lacking in a few areas that I would consider of growing  importance everyday.

• How can I use puppet for managing cloud hosted servers?
• How does Puppet compare to other solutions such as Chef?
• What parts of Puppet itself needs to be backed up and how do I do that?

I also found the discussion of Puppet in a real-time configuration with Marionette Colective was a bit short on details.

Furthermore I have one rather large and nagging question for real world usage and deployments.  There are often times when troubleshooting production systems where you need to dig into configs, and make a change instantly, for instance on a running MySQL server.   How can I do that in a managed way?  Should I put Puppet into manual mode and only push configs when I ask it to?  How about if I want to manage upgrades of a database carefully such as with Oracle, as those can be quite temperamental - how should that process be managed?  How do I prevent crucial production servers from being restarted accidentally?

It would be nice to see a lengthy discussion of these real-world operational questions, but at least for the time being I'll look to google and various forums for answers.

Link to my full review on Amazon

George Reese's book doesn't have the catchiest title, but the book is superb.  One thing to keep in mind, it is not a nuts and bolts or howto type of book.  Although there is a quick intro to EC2 APIs etc, you're better off looking at the AWS docs, or Jeff Barr's book on the subject.  Reese's book is really all about answering difficult questions involving cloud deployments.

• Will my application scale in the cloud?
• How do I mitigate lower SLAs and unreliable hardware in the Amazon environment?
• What types of security questions should I be asking?
• How will cloud computing change the procurement process?

We've written a lot more on the book.  Take a look:  Review of Cloud Application Architectures at Amazon.com

Jeff Barr's book on AWS is a very readable howto and a quick way to get started with EC2, S3, CloudFront, CloudWatch and SimpleDB.  It is short on theory, but long on all the details of really getting your hands dirty.  Learn how to:

• get started using the APIs to spinup servers
• create a load balancer
• add and remove application servers
• build custom AMIs
• create EBS volumes, attach them to your instances & format them
• snapshot EBS volumes
• use RAID with EBS
• setup CloudWatch to monitor your instances
• setup triggers with CloudWatch to enable AutoScaling

I would have liked to see examples in Chef rather than PHP, but hey you can't have everything!

Review: Host Your Web Site In The Cloud by Jeff Barr

The beauty of reading a book by a publisher not sanctioned by Oracle and by an author who doesn't work for Oracle is that they can openly mention bugs. And there are oh-so-many! This book is a superb introduction to the Cost Based Optimizer, and is not afraid to discuss it's many shortcomings. In so doing it also explains how to patch up those shortcomings by giving the CBO more information, either by creating a histogram here and there, or by using the DBMS_STATS package to insert your own statistics in those specific cases where you need to.

Another interesting thing is how this book illustrates, though accidentally, the challenges of proprietary software systems. Much of this book and the authors time is spent reverse engineering the CBO, Oracle's bread and butter optimizing engine. Source code, and details about its inner workings are not published or available. And of course that's intentional. But what's clear page after page in this book is that for the DBA and system tuner, going about their day to day tasks, they really need inside information about what the optimizer is doing, and so this book goes on a long journal to illuminate much of what the CBO is doing, or in some cases provide very educated guesses and some speculation. In contrast, as we know and hear about often, the Open Source alternative provides free access to source code, though not necessarily to the goods themselves. What this means in a very real way is that a book like this would not need to be written for an alternative open source application, because the internal code would be a proverbial open book. That said it remains difficult to imagine how a company like Oracle might persue a more open strategy given that their bread and butter really is the secrets hidden inside their Cost Based Optimizing engine. At any rate, let's get back to Jonathan's book.

Reading this book was like reading a scientists notebook. I found it:

o of inestimable value, but sometimes difficult to sift through

o very anecdotal in nature, debugging, and constantly demonstrating that the CBO is much more faulty and prone to errors than you might imagine

o may not be easy to say I have a query of type X, and it is behaving funny, how do I lookup information on this?

o his discussion of the evolution of the product is so good I'll quote it:

"A common evolutionary path in the optimizer code seems to be the following: hidden by undocumented parameter and disabled in first release; silently enabled but not costed in second release; enabled and costed in third release."

o has excellent chapter summaries which were particularly good for sifting, and boiling down the previous pages into a few conclusions.

o it will probably be of particular value to Oracle's own CBO development teams

Chapter highlights

CH2 - Tablescans

explains how to gather system stats, how to use dbms_stats to set ind. stats manually, bind variables can make the CBO blind, bind variable peeking may not help, partition exchange may break global stats for table, use CPU costing when possible

CH3 - Selectivity

big problem with IN lists in 8i, fixed in 9i/10g, but still prob. with NOT IN, uses very good example of astrological signs overlapping birth months, and associated CBO cardinality problems, reminds us that the optimizer isn't actually intelligent per se, but merely a piece of software

CH4 BTree Access

cost based on depth, #leaf blocks, and clustering factor, try to use CPU costing (system statistics)

CH5 - Clustering Factor

mainly a measure of the degree of random distribution of your data, very important for costing indx scans, use dbms_stats to correct when necessary, just giving CBO better information, freelists (procID problem) + freelist groups discussion with RAC

CH6 - Selectivity Issues

there is a big problem with string selectivity, Oracle uses only first seven characters, will be even more trouble for urls all starting with "http://", and multibyte charactersets, trouble when you have db ind. apps which use string for date, use histrograms when you have problems, can use the tuning advisor for "offline optimization", Oracle uses transitive closure to transform queries to more easily opt versions, moves predicates around, sometimes runs astray

CH7 - Histograms

height balanced > 255 buckets (outside Oracle called equi-depth),

otherwise frequency histograms, don't use cursor sharing as it forces bind variables, blinds CBO, bind var peeking is only first call, Oracle doesn't use histograms much, expensive to create, use sparingly, dist queries don't pull hist from remote site, don't work well with joins, no impact if you're using bind vars, if using dbms_stats to hack certain stats be careful of rare codepaths

CH8 - Bitmap Indexes

don't stop at just one, avoid updates like the plague as can cause deadlocking, opt assumes 80% data tightly packed, 20% widely scattered

CH9 - Query Transformation

partly rule based, peeling the onion w views to understand complex queries, natural language queries often not the most efficient, therefore this transformation process has huge potential upside for Oracle in overall optimization of app code behind the scenes by db engine, always remember Oracle may rewrite your query, sometimes want to block with hints, tell CBO about uniqueness, not NULL if you know this

CH10 - Join Cardinality

makes sensible guess at best first table, continues from there,

don't hide useful information from the CBO, histograms may help with some difficult queries

CH11 - Nested Loops

fairly straightforward costing based on cardinality of each returned set multiplied together

CH12 - Hash Joins

Oracle executes as optimal (all in memory), onepass (doesn't quite fit so dumped to disk for one pass) and multipass (least attractive sort to disk), avoid scripts writing scripts in prod, best option is to use workarea_size_policy=AUTO, set pga_aggregate_target & use CPU costing

CH 13 - Sorting + Merge Joins

also uses optimal, onepass, & multipass algorithms, need more than 4x dataset size for in memory sort, 8x on 64bit system, increasing sort_area_size will incr. CPU util so on CPU bottlenecked machines sorting to disk (onepass) may improve performance, must always use ORDER BY to guarentee sorted output, Oracle may not need to sort behind the scenes, Oracle very good at avoiding sorts, again try to use workarea_size_policy=AUTO

CH 14 - 10053 Trace

reviews various ways to enable, detailed rundown of trace with comments inline, and highlights; even mentions a VOL 2 + 3 of the book is coming!

Appendix A

be careful when switching from analyze to dbms_stats, in 10g some new hist will appear w/default dbms_stats options, 10g creates job to gather stats

Conclusion

I found this book to be full of gems of information that you won't find anywhere else. If you're at the more technical end of the spectrum, this is a one of a kind Oracle book and a

must-have for your collection. Keep in mind something Jonathan mentions in appendix A: "New features that improve 99% of all known queries may cripple your database because you fall into the remaining 1% of special cases". If these cases are your concern, then this book will surely prove to be one-of-a-kind for you!

View this review on Amazon.com

I have a confession to make. I haven't read an Oracle book cover-to-cover in almost three years. Sure I skim through the latest titles for what I need and of course check out documentation of the latest releases. That's what good docs provide, quick reference when you need to check syntax, or details of a particular parameter, or feature, but have you ever read some documentation, sift through a paragraph, page or two, and say to yourself, that's great, but what about this situation I have right now? Unfortunately documentation doesn't always

speak to your real everyday needs. It is excellent for reference, but doesn't

have a lot of real-world test cases, and practical usage examples. That's where Tom Kyte's new book comes in, and boy is it a killer.

I've read Tom's books before, and always enjoyed them. But his new APress title really stands out as an achievement. Page after page and chapter after chapter he uses straightforward examples pasted right from the SQL*Plus prompt to illustrate, demonstrate, and illuminate concepts that he is explaining. It is this practical hands on, relentless approach that makes this book 700 pages of goodness.

Already an expert at Oracle? You'll become more of one after reading this book. With reviewers like Jonathan Lewis I expected this book to be good from the outset I have to admit. But each chapter delves into a bit more depth around subjects that are central to Oracle programming and administration.

No SCREEN SHOTS!

One of the things I loved about this book most of all is its complete lack of screenshots! But how does one illustrate a concept then, you might ask? These days with graphical interfaces becoming more and more popular even among technical folks, I run into the question of the command line over an over again. How can you be doing sophisticated database administration of the latest servers running Oracle with the command line? Or another question I often get is, can you really do everything with the command line? The answer to both is a resounding yes, in fact you can do much more with the command line. Luckily for us, Tom is of this school too, and page after page of his book are full of real examples and commands that you can try for yourself, with specific instructions on

setting up the environment, using statistics gathering packages, and so on. In an era of computing where GUIs seem to reign like magazines over the best literature of the day, it is refreshing to see some of the best and most technical minds around Oracle still advocate the best tool, command line as the interface

of choice. In fact it is the command line examples, and happily the complete lack of screenshots that indeed makes this book a jewel of a find.

Audience

As a DBA you might wonder why I'm talking so highly of a book more focused towards developers. There are a couple of reasons. First this book is about the Oracle architecture, as it pertains to developers. In order for developers to best take advantage of the enterprise investment in Oracle *** they need to thoroughly understand the architecture, how specific features operate, which features are appropriate, and how to optimize their code for best interaction with them. Of course a DBA who is trying to keep a database operating in tip top shape needs to be aware of when developers are not best using Oracle, to identify,

and bring attention to bottlenecks, and problem areas in the application. Second, it is often a DBAs job to tune an existing database, and the very largest benefits come from tuning application SQL. For instance if a developer has chosen to use a bitmap index on an INSERT/UPDATE intensive table, they're in for serious problems. Or if a developer forgot to index a foreign key column. This book directly spearheads those types of questions, and when necessary does mention a thing or two of direct importance to DBAs as well.

Highlights

Chapter 2 has an excellent example of creating an Oracle database. You simply write one line to your init.ora "db_name=sean" for example, and then from the SQL> prompt issues "startup nomount" and then "create database". Looking at the processes Oracle starts, and the files that are created can do wonders for your understanding of database, instance, and Oracle in general.

Chapter 3 covers files, files, and more files. Spfile replaces a text init.ora allowing parameters to be modified while an instance is running *AND* stored persistently. He covers redolog files, flashback logs, and change tracking file

s, as well as import/export dump files, and lastly datapump files.

Chapter 4 covers memory, and specifically some of the new auto-magic options, how they work, and what to watch out for.

Chapter 5 covers processes.

Chapter 6, 7, and 8 cover lock/latching, multiversioning, and transactions respectively. I mention them all here together because to me these chapters are the real meat of the book. And that's coming from a vegetarian! Seriously these

topics are what I consider to be the most crucial to understanding Oracle, and modern databases in general, and the least understood. They are the darkest corners, but Tom illuminates them for us. You'll learn about optimistic versus pessismistic locking, page level, row level, and block level locking in various modern databases such as SQLServer, Informix, Sybase, DB2 and Oracle. Note Oracle is by far in the lead in this department, never locking more than it needs to, which yields the best concurrency with few situations where users block each other. Readers never block, for instance, because of the way Oracle implements all of this. He mentions latch spinning, which Oracle does to avoid a context switch, that is more expensive, how to detect, and reduce this type of contention. You'll learn about dirty reads, phantom reads, and non-repeatable reads, and about Oracle's Read-committed versus Serializable modes. What's more you'll learn about the implications of these various models on your applications, and what type of assumptions you may have to unlearn if you're coming from developing on another database to Oracle. If I were to make any criticism at all, I might mention that in this area Tom becomes ever so slightly preachy about Oracle's superb implementation of minimal locking, and non-blocking reads. This is in large part due I'm sure to running into so many folks who are used to developing on databases which do indeed dumb you down *BECAUSE* of their implementation, encouraging bad habits with respect to transactions, and auto-commit for instance. One thing is for sure you will learn a heck of a lot from these three chapters, I know I did.

Chapter 9 Redo & Undo describes what each is, how to avoid checkpoint not complete and why you want to, how to *MEASURE* undo so as to reduce it, how to avoid log file waits (are you on RAID5, are your redologs on a buffered filesystem?), and what block cleanouts are.

Chapter 10 covers tables. After reading it I'd say the most important types are normal (HEAP), Index Organized, Temporary, and External Tables. Use ASSM where possible as it will save you in many ways, use DBMS_METADATA to reverse engineer objects you've created to get all the options, don't use TEMP tables to avoid inline views, or complex joins, your performance will probably suffer, and how to handle LONG/LOB data in tables.

Chapter 11 covers indexes, topics ranging from height, compression count, DESC sorted, colocated data, bitmap indexes and why you don't want them in OLTP data

bases, function based indexes and how they're most useful for user defined functions, why indexing foreign keys is important, and choosing the leading edge of an index. Plus when to rebuild or coalesce and why.

Chapter 12 covers datatypes, why never to use CHAR, using the NLS features, the CAST function, the number datatypes and precision versus performance, raw_to_hex, date arithmatic, handling LOB data and why not to use LONG, BFILEs and the new UROWID.

Chapter 13 discusses partitioning. What I like is he starts the chapter with the caveat that partitioning is not the FAST=TRUE option. That says it all. For OLTP databases you will achieve higher availability, and ease of administration of large options, as well as possibly reduced contention on larger objects,

but it is NOT LIKELY that you will receive query performance improvements because of the nature of OLTP. With a datawarehouse, you can use partition elimination on queries that do range or full table scans which can speed up queries dramatically. He discusses range, list, hash, and composite partitioning, local indexing (prefixed & non-prefixed) and global indexing. Why datawarehouses tend to use local, and OLTP databases tend to use global indexes, and even how you

can rebuild your global indexes as you're doing partition maintenance avoiding a costly rebuild of THE ENTIRE INDEX, and associated downtime. He also includes a great auditing example.

Chapter 14 covers parallel execution such as parallel dml, ddl, and so on. Here is where a book like Tom's is invaluable, as he comes straight out with his opinions on a weighty topic. He says these features are most relevant to DBAs doing one-off maintenance and data loading operations. That is because even in

datawarehouses, todays environments often have many many users. The parallel features are designed to allow single session jobs to utilize the entire system resources. He explains that Oracle's real sweet spot in this real is parallel

DDL, such as CREATE INDEX, CREATE TABLE AS SELECT, ALTER INDEX REBUILD, ALTER TABLE MOVE, and so on.

Chapter 15, the final chapter covers loading and unloading data. A significant portion of the chapter covers SQL*Loader for completeness, but he goes on to celebrate the wonders of external tables for loading data into Oracle. In particular there is an option in SQL*Loader to generate the CREATE statement for an

external table that does the SAME load! This is great stuff. External tables provide advantages over SQL*Loader in almost every way, except perhaps loading over a network, concurrent user access, and handling LOB data. External tables can use complex where clauses, merge data, do fast code lookups, insert into multiple tables, and finally provide a simpler learning curve.

Conclusions

Yum. If you love Oracle, you'll want to read this book. If you need to know more about Oracle say, for your job, that's another reason you might read this book. Oracle is fascinating technology, and Tom's passion for understanding every last bit of it makes this book both a necessary read, and a very gratifying

one.

View this review on Amazon.com