I Didn’t Know That 6 – What is Wrong with this Quote?

14 12 2010

December 14, 2010

(Back to the Previous Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 541:

“Oracle speeds are very high with SSD, and SSD is also cheap at only $1k/gig USD…  Companies are now offering solid-state disk replacement for the Oracle data buffer cache to speed up I/O at the physical level…”

“Physical disk I/O is measured in milliseconds, an eternity when compared to faster operations within other server components such as network RAM and CPU speeds.  For many years, Oracle shops have been embracing solid-state disks, RAM disks that operate hundreds of time faster than old-fashioned platter technology from the 1960s.  SSD also has no channel contention, and as prices fall, SSD will eventually displace the ancient magnetic spinning platters of the last century.”

What, if anything, is wrong with the above quote? 

—————–

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review. 

This blog article marks the last of the blog articles that were scheduled as a component part of the “Oracle Tuning the Definitive Reference Second Edition” book review.  Regular readers will probably recognize that I attempt to encourage people to learn from mistakes, whether your own, or those that you encounter in your day to day duties working with Oracle Database.  If the mistakes are yours, it is your choice whether you continue to make the same mistakes year after year, or if you will seek to learn from the assistance provided by others.  The last four book reviews that I posted have all had a “public opinion” portion (in separate blog articles), and I think that approach adds a new dimension to book reviews – I certainly appreciate the feedback that readers have provided.  If you are a senior DBA, or a person who enjoys digging to find the root meaning of what is stated, take a serious look at buying this book and writing a review. 

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

  • rampant-books.com/t_oracle_ssd_disk_i_o.htm
  • praetoriate.com/t_%20oraclerac_ssd_with_rac.htm
  • dba-oracle.com/t_sun_solaris_solid_state_disk_ssd.htm
  • dba-oracle.com/t_flash_disk_drives_ssd_ram_san.htm
  • dba-oracle.com/art_dbazine_2020_p2.htm




I Didn’t Know That 5 – What is Wrong with this Quote?

13 12 2010

December 13, 2010

(Back to the Previous Post in the Series) (Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 539:

“But what is Oracle’s official position on multiple blocksizes?  For Oracle metal-level customers, there is the Oracle Metalink system which provides the official position of Oracle’s own experts.

Metalink Note: 46757.1, titled Notes on Choosing an Optimal Db Blocksize, says that there are some benefits from having larger blocksizes, but only under specific criteria (paraphrased from Metalink):

  • Large blocks give more data transfer per I/O call.
  • Larger blocksizes provide less fragmentation, i.e. row chaining and row migration, of large objects (LOB, BLOB, CLOB).
  • Indexes like big blocks because index height can be lower and more space exists within the index branch nodes.


Metalink goes on to say that multiple blocksizes may benefit shops that have ‘mixed’ blocksize requirements…”

What, if anything, is wrong with the above quote? 

—————–

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:





I Didn’t Know That 4 – What is Wrong with this Quote?

12 12 2010

December 12, 2010

(Back to the Previous Post in the Series) (Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 987:

Row ordering matters!
In some systems where a table is always accessed by the same key sequence, re-ordering the table into the same order as the queries can dramatically reduce I/O and improve SQL performance.

When reorganizing tables to improve SQL performance, keep this in-mind:

  • Only tables that experience multi-block reads (full-table scans) may see an appreciable SQL performance benefit.
  • Some shops will use sorted hash cluster tables to maintain row sequence order (in the same order as the most common indexed retrieval), and you can reorganize a table with an ‘order by’ clause to make the rows in the same sequence as the index.

But it’s not just tables that require periodic maintenance, it’s also indexes.”

What, if anything, is wrong with the above quote? 

—————–

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

  • remote-dba.net/t_oracle_net_reorganize_tables.htm
  • dba-oracle.com/art_disk_io.htm
  • dba-oracle.com/t_table_row_resequencing.htm
  • dba-oracle.com/t_create_table_select_ctas.htm




I Didn’t Know That 3 – What is Wrong with this Quote?

11 12 2010

December 11, 2010

(Back to the Previous Post in the Series) (Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 828:

“When the index can no longer split because the owner block is full, Oracle will spawn a whole new index level, keeping the index tree in perfect logical and phyical balance.  Deletes are a different story.  Physically, Oracle indexes are always balanced because empty blocks stay inside the tree structure after a massive delete. Logically, Oracle indexes are not self-balancing because Oracle does not remove the dead blocks as they become empty.  Figure 16.9 shows an Oracle index before a massive delete…”

What, if anything, is wrong with the above quote?  Please keep in mind that the focus of this blog is on the technical content, and learning from that technical content.  Please stay positive in your responses (before answering, first take a look at page 727 to see if these two sections of the book are related – note that Richard Foote’s PDF file listed below seems to address page 727 of this book).

—————–

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:





I Didn’t Know That 2 – What is Wrong with this Quote?

10 12 2010

December 10, 2010

(Back to the Previous Post in the Series) (Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 988:

“Production DBA’s spend weekends reorganizing their data structures, returning them back into their original, pristine state, in preparation for the return of the end-users on Monday morning.

Rebuilding high-DML indexes in a schedule can be a DBA best practice under certain conditions:

  • You can schedule a job to rebuild and index (and address errors) in just a few minutes.  Because most DBA’s are salaried professionals, the DBA cost is negligible.
  • During a weekly maintenance window when the server sits idle.  Because hardware depreciates rapidly, regardless of use, the cost of rebuilding indexes is essentially zero.”

What, if anything, is wrong with the above quote?  Please keep in mind that the focus of this blog is on the technical content, and learning from that technical content.  Please stay positive in your responses (before answering, first take a look at page 727 to see if we really need to first determine the candidate indexes for a rebuild).

—————–

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:





I Didn’t Know That 1 – What is Wrong with this Quote?

9 12 2010

December 9, 2010

(Forward to the Next Post in the Series)

In the interest of interesting quotes, a quote that I found in the “Oracle Tuning the Definitive Reference Second Edition” book on page 995:

“In the 1970s, Moore’s law was introduced, stating that processor costs were always falling while speed continued to improve.  However, as Oracle professionals, we must understand that Moore’s law does not apply to RAM.  While RAM costs continue to fall every year, the speed of RAM access is constrained by silicon technology and did not improve over at least three decades as shown in Figure 17.1.”

What, if anything, is wrong with the above quote?  While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

  • dba-oracle.com/art_dbazine_oracle_10g_data_warehouse.htm
  • dba-oracle.com/oracle_tips_hardware_oracle_performance.htm
  • dba-oracle.com/t_history_ram.htm

Helpful References:





Wait Events 3 – What is Wrong with this Quote?

9 12 2010

December 9, 2010

(Back to the Previous Post in the Series)

While reading the “Oracle Tuning the Definitive Reference Second Edition” book I found a handful of interesting suggestions regarding Oracle wait events.  Previous articles on this blog have described the contents of 10046 trace files, and leveraged the contents of those files to explain various types of problems and/or unexpected behavior (for example: three part series reading 10046 trace files, EXPLAIN PLAN/AUTOTRACE/TKPROF liesORDERED hint not followedfour part series: Enterprise Edition and Standard Edition perform differently11.2.0.1 ODBC bug, etc.)  Take three minutes to analyze the following quote from page 451 of the book that describes Oracle Database wait events found in 10046 trace files:

“Those Evil Wait Events in the 10046 Trace File

The trace file contains lots of details and it is important to seek out the wait event notes as the wait events are interspersed throughout the 10046 trace file.

WAIT #2: nam='SQL*Net message to client' ela= 10 p1=1111838976 p2=1 p3=0

This wait event record shows that the wait event (nam) is a SQL*Net message to client.  These wait events are the same wait events that can be found in the database in the v$ views like v$session_wait or v$event_name.

The elapsed time (ela) is in microseconds since this database is Oracle 10g, so this wait was a whole 10 microseconds.  This is nothing to worry about because 1 second = 1,000,000 microseconds.  Please note the P1, P2 and P3 variables are specific to each event.”

Keeping in mind that the book is printed after the release of Oracle Database 11.2.0.1 (and possibly 11.2.0.2 for some operating system platforms), what, if anything, is wrong with the above quote?

While my review of the book only provides an in-depth technical review of the first 200 pages of the book, this blog article series will dig into some of the pages that were not specifically included in the review.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.

Other pages found during a Google search of the phrase:

  • dba-oracle.com/t_10046_trace_file_parse_execute.htm







Follow

Get every new post delivered to your Inbox.

Join 141 other followers