a?? Support for indexes and sequences
a?? New command line options
a?? Better multi threading support
a?? New scaleable data builds
a?? Number generators can reference row counts from other tables
a?? Better database performance
a?? Ability to generate only the DDL of a schema
a?? Numerous bug fixes

The new build can be downloaded here

Ia??ve also updated the install, and added some additional walk throughs (in the swingbench section)

More details can be found here

Obviously turning on is achieved with the a??set timing ona?? operation. i.e

SQL > set timing on

SQL > select count(1) from all_objects;

COUNT(1)
----------
68653

Elapsed: 00:00:03.95

SQL>

Which is great but what if want to time mulitiple operations. Use the timing function and simply give the timer a name, in this case statement timer.

SQL> timing start statement_timer
SQL> select count(1) from all_objects;

COUNT(1)
----------
68653

SYS@orcl > /

COUNT(1)
----------
68653

SQL> timing show statement_timer;
timing for: statement_timer
Elapsed: 00:00:30.85
SQL>

Which times anything that went on in between the timer starting and finishing. In this case also my typing of the commands. Its a fantastic utility for timing stages in a batch job including call outs to os operations.

Since my last post here Swingbench,TraceAnalyzer and Datagenerator have had some big updates. So if you interested head over to dominicgiles.com and take a look.

TraceAnalyzer has had some improvements made

New features include

• Support for 10046 traces
  
• Bind parameters
  
• Explain Plans
  
• Wait Events
  
• Formatting of SQL
  

I have a had a few emails stating that on some trace files TraceAnalyzer falls apart... I can't reproduce this on any trace files I have so if you have had this issue and can send me the trace file Im happy to take a look.

Dom.

• Parse trace files.
  
• Profile the data via a bar of the right had side
  of the scroll bar.
  
• Supports dynamic filtering and sorting of the
  data.
  
• Highlight the 5 worst performing pieces of SQL
  (elpased, cpu, physical etc)
  

• highlight concurrent SQL
  
• 
  Explain Plans
  
• 
  Display bind variables
  
• 
  dump sql to flat files
  
• 
  generate load files for swingbench
• create a plugin for SQL*Developer
  

• User definable number of threads
• 
  
• Data insertion directly into the database
  (Oracle)
• 
  
• Ordered generation of data (largest first)
• 
  
• Lots and lots of small bug fixes
• 
  

• CPUs, have we enough. Fast as possible.
• Memory, as much as we can put in the box. Oracle don't charge us for that
• SAN, big as possible.

At this stage the purchase order is usually given the nod and the hardware supplier will ship yet another run of the mill box. Don't get me wrong. Many experienced DBAs have been through this process many times before and realise that not only is the list in the wrong order but its missing some critical components.

• HBAs, need to specify these in proportion to the CPUs and attached storage
• NICs, might need a lot of these i.e public, cluster interconnect, storage, management, backup. And typically in multiples for resillience or performance.
• Backup, are we using the existing backup infrastructure?

I don't blame anyone for this way of thinking, its the way its always been. When discussing a new server the first question that people tend to ask is "So whats this monster packing? 16 CPUs!!!" followed by lots of very macho grunts and hollering. The standard licensing model (not just Oracles) doesn't help. It starts with premise of a CPU describing the power of a server, and to a large degree it does but misses the point of what a database is all about and that's information. Typically that information is held in ones and zeros on a bunch of spinning scrap metal. The real power of a database comes from its ability to aggregate, analyze and process those ones and zeros, turn it into information and push results out to interested parties. Paraphrasing a little "Its all about I/O stupid".

With this in mind I'm constantly surprised by the imbalance of I/O put into servers both disk and network. Its not unusual to see a 4 cpu server running with the latest generation Intel and AMD CPUs but with a single HBA and dual ported NIC. Whilst memory is cheap many of these servers still run 32 bit kernels. This typically means only a small proportion of the database is cached in memory be it in the SGA or file cache (don't me started on file cache). I'd make a rash guess that whilst the size of the memory in a typical database server has increased the average size of the SGA hasn't increased in line with this trend. To make matters worse the typical size of a database has got significantly bigger. This has to lead us to the conclusion that less of the database is cached and as a result a bigger proportion of its is located on disk. As I said this is just a guess but its backed up with real customer engagements. What would be of interest is to have performed an analysis over the last 10 years to see if the wait event for scattered and sequential reads had decreased or increased as a proportion of the total wait event in production databases.

What I'm driving at is the need to move I/O way up the agenda when sizing a server for databases. The number of CPUs needs to be married to the number of I/O channels available. It makes no sense to buy database licenses for a machine that will simply sit and wait on I/O, Its simply wasting money. Equally it makes no sense to stuff a 4 cpu machine full of HBAs for a database application that will perform index lookups on a index that fits comfortably in the cache. Adding HBAs later to an existing server isn't necessarily a simple option either especially for a mission critical application or one that has hard coded paths to disk.

The next obvious question is "well thats well and good but how do I size the ratio of HBAs to CPUs." and in a typically vague fashion I reply "well that depends". The type of application and the type of processor should heavily influence the decision. Certainly the CPU has been winning the race in terms of performance over the last few years and it needs a lot more I/O to keep it busy. But the equation also needs to be balanced with the amount of memory available on the box. A large SGA will certainly reduce the need to visit disk. The best advice I can give is to speak to your hardware supplier and find out what the current state of play is. Also check the latest TPC-C and TPC-H figures show. Whilst these are generally edging towards the extremes of performance it does show what a hardware supplier believed was needed to show their hardware in the best light.

With this in mind Im interested to know what features people would like to see in the next release... Some ideas might be

• Load generated from trace files


• More benchmarks


• more sophisticated clusteroverview

• Sorted out the save, save buttons so they should work as expected.
  
• 
  
  
• Now a Transactions per second option for charbench(if this is useful I'll include it inside of swingbench and minibench)
  
• 
  
  
• Benchmark name now include on window title for swingbench
  
•