Book Review: Oracle Database 11g – Underground Advice for Database Administrators

(06/15/2010: This blog post will be edited multiple times to add reviews for the remaining chapters in the book.)

Author: April C. Sims
Publisher: Packt
Target Audience: Oracle Database Administrators

Chapter #1 "When to step away from the keyboard" starts off with an interesting example, cautions the DBAs to be self-restraint but encourages to do the right thing at the end of the day. I liked the idea of listing out a whole bunch of graphical and command line Oracle tools [with brief descriptions] that an Oracle DBA may need in performing some of the day-to-day activities. Also couple of pages were dedicated to list out various tasks performed by Oracle DBAs on a daily, weekly, monthly, quarterly & yearly basis. It was interesting. And finally the chapter concludes with a bunch of useful tips for the administrators to avoid making unwanted errors.

The only thing that probably didn't fit in this chapter is the very brief discussion on staying away from dinosaurs. In my opinion, it is completely off-topic.

Chapter #2 "Maintaining Oracle Standards" is available for download. Get it from this location and read it yourself. You be the judge.

Chapter #3 "Tracking the Bits and Bytes". The first half of the chapter talks about Oracle Data Block and the methods to view the data at the block level, the finest level of granularity that contains the actual data. The author tried and succeeded with a decent follow up that briefly explains how transaction integrity is maintained in Oracle database. The hands on exercise makes the reader sweat a little, but may help understand the material that was presented earlier, better. The key is to focus and try to understand what is happening when running all those scripts and commands. I would like a much simpler example though. Admittedly this is not something that Oracle administrators do everyday, but it does not hurt to gain some insight into Oracle internal workings and to be prepared to leverage this knowledge when disaster strikes.

The second half of the chapter was dedicated for Log Miner, a PL/SQL package utility that can be used to extract the database transactions that have been executed over a period of time. April did a nice job briefly explaining why protecting the [physical] redo, undo and the archive log files is very important -- to keep the data & database transactions from falling into the wrong hands. An example using "Flashback Transaction Blackout" method was shown to demonstrate how to use log miner utility to retrieve the changes that were done to the database few minutes ago.

I am not impressed with the example in page 92 in section Identifying data in undo segments by flashing back to timestamp. There are a bunch of SQL statements in the example with no output from a test environment. I strongly believe that showing the actual output keeps the material interesting and easy to follow.

Also I did not like the idea of pointing to blogs and random web sites, as they may disappear any time without a warning.

To be continued ..
________________
Technorati Tags:
Oracle | Database | RDBMS | DBA | Book | Review | Packt

Read More

Oracle RDBMS : Flushing a Single SQL Statement out of the Object Library Cache

It is well known that the entire shared pool can be flushed with a simple ALTER SYSTEM statement.

SQL> ALTER SYSTEM FLUSH SHARED_POOL;

System altered.

What if the execution plan of a single SQL statement has to be invalidated or flushed out of the shared pool so the subsequent query execution forces a hard parse on that SQL statement. Oracle 11g introduced a new procedure called PURGE in the DBMS_SHARED_POOL package to flush a specific object such as a cursor, package, sequence, trigger, .. out of the object library cache.

The syntax for the PURGE procedure is shown below.

procedure PURGE (
        name VARCHAR2, 
        flag CHAR DEFAULT 'P', 
        heaps NUMBER DEFAULT 1)

Explanation for each of the arguments is documented in detail in $ORACLE_HOME/rdbms/admin/dbmspool.sql file.

If a single SQL statement has to be flushed out of the object library cache, the first step is to find the address of the handle and the hash value of the cursor that has to go away. Name of the object [to be purged] is the concatenation of the ADDRESS and HASH_VALUE columns from the V$SQLAREA view. Here is an example:

SQL> select ADDRESS, HASH_VALUE from V$SQLAREA where SQL_ID like '7yc%';

ADDRESS   HASH_VALUE
---------------- ----------
000000085FD77CF0  808321886

SQL> exec DBMS_SHARED_POOL.PURGE ('000000085FD77CF0, 808321886', 'C');

PL/SQL procedure successfully completed.

SQL> select ADDRESS, HASH_VALUE from V$SQLAREA where SQL_ID like '7yc%';

no rows selected

Note to Oracle 10g R2 Customers

The enhanced DBMS_SHARED_POOL package with the PURGE procedure is included in the 10.2.0.4 patchset release.

10.2.0.2 and 10.2.0.3 customers can download and install RDBMS patch 5614566 to get access to these enhancements in DBMS_SHARED_POOL package.

Also see:

• Oracle Support Document ID 457309.1 "How To Flush an Object out the Library Cache [SGA]"
• Oracle Support Document ID 751876.1 "DBMS_SHARED_POOL.PURGE Is Not Working On 10.2.0.4"
• DBMS_SHARED_POOL.PURGE() procedure documentation

(Original post is at:
http://blogs.sun.com/mandalika/entry/oracle_rdbms_flushing_a_single)

Read More

Oracle Database: Say No Thanks! to a New Index

(Original post is at blogs.sun.com at:
http://blogs.sun.com/mandalika/entry/oracle_database_say_i_no)

.. unless you are working with a database that is largely read-only or if the new index is supposed to be fixing a critical performance issue with no side effect(s).

Two topics covered in this blog entry with plenty of simple examples:

1. Why creating new indexes on a heavily modified table may not be a good idea? and
   
2. How to identify unused indexes?

Read on.

Indexes are double-edged swords that may improve the performance of targeted queries, but in some cases they may accidentally degrade the performance of other queries that are not targeted. In any case, exercise caution while adding a new index to the database. After adding a new index, monitor the overall performance of the database, not just the targeted query.

If DML statements that modify data (INSERT, UPDATE, or DELETE) are being executed large number of times on a table, make sure that the addition of a new index on the same table does not negatively affect the performance of those DML operations. Usually this is not a problem if the SQLs being executed are simply retrieving but not adding or modifying the existing data. In all other cases, there is some performance overhead induced by the addition of each new index. For example, if there are 10 indexes created on a table DUMMY, adding a new row of data to the table DUMMY may require updating all 10 indexes behind the scenes by the database management system.

Here is an example demonstrating the performance overhead of a new index on a table.

SQL> CREATE TABLE VIDEO
  2  (BARCODE VARCHAR(10) NOT NULL,
  3  TITLE VARCHAR2(25) NOT NULL,
  4  FORMAT VARCHAR2(10),
  5  PRICE NUMBER,
  6  DATA_OF_RELEASE DATE)
  7  /

Table created.

SQL> insert into VIDEO values ('9301224321', 'AVATAR', 'BLU-RAY', 19.99, '22-APR-2010');

1 row created.

..

SQL> insert into VIDEO values ('3782460017', 'THE SIMPSONS - SEASON 20', 'BLU-RAY', 29.99, '04-JUL-2009');

1 row created.

SQL> select * from VIDEO;

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
9301224321 AVATAR        BLU-RAY   19.99 22-APR-10
7619203043 BEN-HUR        VHS     9.79 12-MAR-63
7305832093 THE MATRIX       DVD    12.29 03-DEC-99
4810218795 MEMENTO        DVD     8.49 02-FEB-02
3782460017 THE SIMPSONS - SEASON 20     BLU-RAY   29.99 04-JUL-09

SQL> select * from USER_INDEXES where TABLE_NAME = 'VIDEO';

no rows selected

SQL> alter session set events '10046 trace name context forever, level 8';

Session altered.

SQL> select * from VIDEO where FORMAT = 'BLU-RAY';

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
9301224321 AVATAR        BLU-RAY   19.99 22-APR-10
3782460017 THE SIMPSONS - SEASON 20     BLU-RAY   29.99 04-JUL-09

SQL> alter session set events '10046 trace name context off';

Session altered.

SQL trace file has the following contents.

SQL ID: 0pu5s70nsdnzv
Plan Hash: 3846322456
SELECT * 
FROM
 VIDEO WHERE FORMAT = :"SYS_B_0"


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0         16          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0         16          0           2

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 28  

Rows     Row Source Operation
-------  ---------------------------------------------------
      2  TABLE ACCESS FULL VIDEO (cr=16 pr=0 pw=0 time=3 us cost=4 size=100 card=2)

Let's create an index and see what happens.

SQL> create index VIDEO_IDX1 on VIDEO (FORMAT);

Index created.

SQL>  alter session set events '10046 trace name context forever, level 8';

Session altered.

SQL> select * from VIDEO where FORMAT = 'BLU-RAY';

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
9301224321 AVATAR        BLU-RAY   19.99 22-APR-10
3782460017 THE SIMPSONS - SEASON 20     BLU-RAY   29.99 04-JUL-09

SQL> alter session set events '10046 trace name context off';

Session altered.

The latest contents of the trace file are as follows. Notice the reduction in buffer gets from 16 to 4. That is, the new index improved the query performance by 75%.

SQL ID: 0pu5s70nsdnzv
Plan Hash: 2773508764
SELECT * 
FROM
 VIDEO WHERE FORMAT = :"SYS_B_0"


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00       0.00          0          4          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00       0.00          0          4          0           2

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 28  (CS90)

Rows     Row Source Operation
-------  ---------------------------------------------------
      2  TABLE ACCESS BY INDEX ROWID VIDEO (cr=4 pr=0 pw=0 time=12 us cost=2 size=100 card=2)
      2   INDEX RANGE SCAN VIDEO_IDX1 (cr=2 pr=0 pw=0 time=10 us cost=1 size=0 card=2)(object id 76899)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
      2   TABLE ACCESS (BY INDEX ROWID) OF 'VIDEO' (TABLE)
      2    INDEX   MODE: ANALYZED (RANGE SCAN) OF 'VIDEO_IDX1' (INDEX)

So far so good. Let's add a new row of data and examine the trace file one more time. From hereafter, keep an eye on the "current" column (logical IOs performed due to an INSERT, UPDATE or DELETE) and notice how it changes with different actions -- adding and removing: indexes, new row(s) of data etc.,

SQL ID: dnb2d8cpdj56p
Plan Hash: 0
INSERT INTO VIDEO 
VALUES
 (:"SYS_B_0", :"SYS_B_1", :"SYS_B_2", :"SYS_B_3", :"SYS_B_4")


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          1          7           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          1          7           1

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 28  (CS90)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=0 us)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  INSERT STATEMENT   MODE: ALL_ROWS
      0   LOAD TABLE CONVENTIONAL OF 'VIDEO'

Now drop the index, re-insert the last row and get the tracing data again.

SQL> drop index VIDEO_IDX1;

Index dropped.

SQL> delete from VIDEO where BARCODE ='4457332907';

1 row deleted.

SQL> commit;

Commit complete.

SQL> alter session set events '10046 trace name context forever, level 8';

Session altered.

SQL> insert into VIDEO values ('4457332907', 'KING OF THE HILL - ALL', 'DVD', 90.00, '01-JAN-2011');

1 row created.

SQL> alter session set events '10046 trace name context off';

Session altered.

The contents of the latest trace file are shown below.

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.01       0.00          0          2          5          1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.01       0.00          0          2          5           1

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 28  (CS90)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=0 us)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  INSERT STATEMENT   MODE: ALL_ROWS
      0   LOAD TABLE CONVENTIONAL OF 'VIDEO'

This time create two indexes and see what happens.

SQL> CREATE INDEX VIDEO_IDX1 ON VIDEO (FORMAT);

Index created.

SQL> CREATE INDEX VIDEO_IDX2 ON VIDEO (TITLE);

Index created.

Trace file contents:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          1          9           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          1          9           1

Notice the two additional logical IOs (look under "current" column). Those additional logical input/output operations are the result of the new indexes. The number goes up as we add more indexes and data to the table VIDEO.

SQL> delete from VIDEO where BARCODE ='4457332907';

1 row deleted.

SQL> commit;

Commit complete.

SQL> create index VIDEO_IDX3 on VIDEO (PRICE, DATA_OF_RELEASE);

Index created.

SQL>  alter session set events '10046 trace name context forever, level 8';

Session altered.

SQL> insert into VIDEO values ('4457332907', 'KING OF THE HILL - ALL', 'DVD', 90.00, '01-JAN-2011');

1 row created.

SQL> alter session set events '10046 trace name context off';

Session altered.


SQL trace:

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          1         11           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          1         11           1

You can try other operations such as UPDATE, DELETE on your own.

Since there are only few rows of data in the table VIDEO, it is hard to notice the real performance impact in these examples. If you really want to see the negative performance impact due to the large number of indexes on a heavily updated table, try adding thousands or millions of rows of data and few more indexes.

Moral of the story: Indexes aren't always cheap - they may have some overhead associated with them. Be aware of those overheads and ensure that the index maintenance overhead do not offset the performance gains resulting from the indexes created on a particular table.

---

Monitoring Index Usage

Now we know the possible disadvantage of having too many indexes on a heavily updated table. One way to reduce the index maintenance overhead is to instrument the indexes so we can monitor their usage from time to time and remove the unused indexes. To start monitoring the index usage, alter the index by specifying the keywords MONITORING USAGE.

SQL> select index_name from user_indexes where table_name = 'VIDEO';

INDEX_NAME
--------------------------------------------------------------------------------
VIDEO_IDX3
VIDEO_IDX1
VIDEO_IDX2

SQL> alter index VIDEO_IDX1 MONITORING USAGE;

Index altered.

SQL> alter index VIDEO_IDX2 MONITORING USAGE;

Index altered.

SQL> alter index VIDEO_IDX3 MONITORING USAGE;

Index altered.

Once the indexes are instrumented, query the V$OBJECT_USAGE view occasionally to see if the instrumented indexes are being used in executing SQL queries.

SQL> select * from VIDEO where BARCODE LIKE '%22%';

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
9301224321 AVATAR        BLU-RAY   19.99 22-APR-10

SQL> select * from VIDEO where FORMAT = 'VHS';

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
7619203043 BEN-HUR        VHS     9.79 12-MAR-63

SQL> select * from VIDEO where PRICE < 20;

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
4810218795 MEMENTO        DVD     8.49 02-FEB-02
7619203043 BEN-HUR        VHS     9.79 12-MAR-63
7305832093 THE MATRIX       DVD    12.29 03-DEC-99
9301224321 AVATAR        BLU-RAY   19.99 22-APR-10

SQL> select * from VIDEO where FORMAT = 'BLU-RAY' AND DATA_OF_RELEASE < '01-JAN-2010';

BARCODE  TITLE        FORMAT   PRICE DATA_OF_RELEASE
--------------- ----------------------------------- --------------- ---------- ---------------
3782460017 THE SIMPSONS - SEASON 20     BLU-RAY   29.99 04-JUL-09


SQL> column INDEX_NAME format A25
SQL> column START_MONITORING format A30

SQL> select INDEX_NAME, USED, START_MONITORING 
  2  from V$OBJECT_USAGE 
  3  where INDEX_NAME LIKE 'VIDEO_IDX%'
  4  /

INDEX_NAME    USED     START_MONITORING
------------------------- --------- ------------------------------
VIDEO_IDX1    YES     04/27/2010 01:10:20
VIDEO_IDX2    NO     04/27/2010 01:10:25
VIDEO_IDX3    YES     04/27/2010 01:10:31

In the above example, the index VIDEO_IDX2 was not in use during the period of index monitoring. If we are convinced that the queries that will be executed are similar to the ones that were executed during the index monitoring period, we can go ahead and remove the index VIDEO_IDX2 to reduce the performance overhead during updates on table VIDEO.

To stop monitoring the index usage, alter the index with the keywords NOMONITORING USAGE.

SQL> alter index VIDEO_IDX1 NOMONITORING USAGE;

Index altered.

Read More

Music : Few Mixed Tunes with GarageBand

(Originally posted on 12/09/2009. This blog posted will be updated as new compositions come along.)

For the past couple of weeks I have had fun playing with Apple's GarageBand. It is a nice piece of software with intuitive user interface and tons of free & ready-to-use music loops. It only took a couple of tries and about 6 hours to produce my first ever mixed tune with software of any kind. The second one just took two hours as my main focus was on only two loops. I'm happy with the output and decided to share it with my family and friends. Hence I uploaded those two tracks to iCompositions, an internet community web site that facilitates sharing each individuals' creative work with the rest of the community at free of cost. Click on the following music player images to listen to those instrumental tracks.

[12/09/09] Track #1 Hokum
[12/09/09] Track #2 Thrum
[12/18/09] Track #3 Kabuki Dance
[01/05/10] Track #4 Phantasm
[05/10/10] Track #5 Transgression

Now if only I knew how to play a real instrument ..
________________
Technorati Tags:
Music | GarageBand

Read More

Oracle Database 11g – Underground Advice for Database Administrators

.. review coming soon ..

Meanwhile feel free to explore the Table of Contents and check the freely download-able chapter Chapter 2: Maintaining Oracle Standards

Read More

Oracle 11g R1: Poor Data Pump Performance when Exporting a Partitioned Table

(Originally posted on blogs.sun.com at http://blogs.sun.com/mandalika/entry/oracle_11g_r1_poor_data)

Symptom(s)

Data Pump Export utility, expdp, performs well with non-partitioned tables, but exhibits extreme poor performance when exporting objects from a partitioned table of similar size. In some cases the degradation can be as high as 3X or worse.

SQL traces may show that much of the time is being spent in a SQL statement that is similar to:

UPDATE "schema"."TABLE" mtu 
SET mtu.base_process_order = NVL((SELECT mts1.process_order FROM "schema"."TABLE" mts1 
WHERE ..

Here is an example data export session:

Export: Release 11.1.0.7.0 - 64bit Production on Wednesday, 31 March, 2010 6:56:50

Copyright (c) 2003, 2007, Oracle.  All rights reserved.
;;; 
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SCHMA"."SYS_EXPORT_TABLE_01":  SCHMA/******** DIRECTORY=exp_dir DUMPFILE=SOME_DUMMY_PART_FULL.DMP TABLES=SOME_DUMMY_PART
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 20.56 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P01"  1.143 GB 13788224 rows
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P02"  1.143 GB 13788224 rows
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P03"  1.143 GB 13788224 rows
...
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P32"  151.1 MB 1789216 rows
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P33"  11.37 MB  136046 rows
. . exported "SCHMA"."SOME_DUMMY_PART":"DUMMY_PART_P00"      0 KB       0 rows
Master table "SCHMA"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SCHMA.SYS_EXPORT_TABLE_01 is:
  /DBDUMP/SOME_DUMMY_PART_FULL.DMP
Job "SCHMA"."SYS_EXPORT_TABLE_01" successfully completed at 11:22:36

Solution(s) / Workaround

This is a known issue (that is, a bug) and a solution is readily available. Try any of the following to resolve the issue:

• Apply the 11g database patch 8845859
  
• Upgrade to 11.2.0.2 patchset when it is available, or
  
• Specify "VERSION=10.2.0.3" expdp option as a workaround
  

I ran into this issue and I chose the workaround to make some quick progress. With the string "VERSION=10.2.0.3" appended, export time went down from 265 minutes to 60+ minutes.

Read More

2004-2010 : A Look Back at Sun Published Oracle Benchmarks

(Originally published on blogs.sun.com at:
http://blogs.sun.com/mandalika/entry/2004_2010_a_look_back)

Since Sun Microsystems became a legacy, I got this idea of a reminiscent [farewell] blog post for the company that gave me the much needed break when I was a graduate student back in 2002. As I spend more than 50% of my time benchmarking different Oracle products on Sun hardware, it'd be fitting to fill this blog entry with a recollection of the benchmarks I was actively involved in over the past 6+ years. Without further ado, the list follows.

2004

1.  10,000 user Siebel 7.5.2 PSPP benchmark on a combination of SunFire v440, v890 and E2900 servers. Database: Oracle 9i Benchmark Report Blog: Sun achieves winning Siebel benchmark Blog: Sun and Siebel Kick Some Benchmark Butt Blog: When Good Benchmarks Go Bad

2005

2.  8,000 user Siebel 7.7 PSPP benchmark on a combination of SunFire v490, v890, T2000 and E2900 servers. Database: Oracle 9i Benchmark Report

3.  12,500 user Siebel 7.7 PSPP benchmark on a combination of SunFire v490, v890, T2000 and E2900 servers. Database: Oracle 9i Benchmark Report

2006

4.  10,000 user Siebel Analytics 7.8.4 benchmark on multiple SunFire T2000 servers. Database: Oracle 10g Benchmark Report

2007

5.  10,000 user Siebel 8.0 PSPP benchmark on two T5220 servers. Database: Oracle 10g R2 Benchmark Report Blog: Sun publishes 10,000 user Siebel 8.0 PSPP benchmark on Niagara 2 systems

2008

6.  Oracle E-Business Suite 11i Payroll benchmark for 5,000 employees. Database: Oracle 10g R1 White Paper (didn't qualify as a benchmark since we configured more than 4 payroll threads) Blog: Running Batch Workloads on Sun's CMT Servers

7.  14,000 user Siebel 8.0 PSPP benchmark on a single T5440 server. Database: Oracle 10g R2 Benchmark Report Blog: Siebel 8.0 on Sun SPARC Enterprise T5440 - More Bang for the Buck!! Blog: Siebel on Sun CMT hardware : Best Practices Blueprint: Consolidating Oracle Siebel CRM 8 on a Single Sun SPARC Enterprise Server

8.  10,000 user Siebel 8.0 PSPP benchmark on a single T5240 server. Database: Oracle 10g R2 Benchmark Report Blog: Yet Another Siebel 8.0 PSPP Benchmark on Sun CMT Hardware ..

2009

9.  4,000 user PeopleSoft HR Self-Service 8.9 benchmark on a combination of M3000 and T5120 servers. Database: Oracle 10g R2 Benchmark Report Blog: PeopleSoft HRMS 8.9 Self-Service Benchmark on M3000 & T5120 Servers

10.  28,000 user Oracle Business Intelligence Enterprise Edition (OBIEE) 10.1.3.4 benchmark on a single T5440 server. Database: Oracle 11g R1 Benchmark Report Blog: T5440 Rocks [again] with Oracle Business Intelligence Enterprise Edition Workload Blog: Oracle Business Intelligence on Sun : Few Best Practices

11.  50,000 user Oracle Business Intelligence Enterprise Edition (OBIEE) 10.1.3.4 benchmark on two T5440 servers. Database: Oracle 11g R1 Benchmark Report Blog: Sun achieves the Magic Number 50,000 on T5440 with Oracle Business Intelligence EE 10.1.3.4 Blueprint: Deploying Oracle Business Intelligence Enterprise Edition

12.  PeopleSoft North American Payroll 9.0 240K EE 8-stream benchmark on a single M4000 server with F5100 Flash Array storage. Database: Oracle 11g R1 Benchmark Report Blog: PeopleSoft North American Payroll on Sun Solaris with F5100 Flash Array : A blog Reprise Blog: Oracle PeopleSoft Payroll (NA) Sun SPARC Enterprise M4000 and Sun Storage F5100 World Record Performance Blog: App benchmarks, incorrect conclusions and the Sun Storage F5100 Blueprint: Best Practices for Oracle PeopleSoft Enterprise Payroll for North America using the Sun Storage F5100 Flash Array or Sun Flash Accelerator F20 PCIe Card

2010

13.  PeopleSoft North American Payroll 9.0 240K EE 16-stream benchmark on a single M4000 server with F5100 Flash Array storage. Database: Oracle 11g R1 Benchmark Report Blog: PeopleSoft NA Payroll 240K EE Benchmark with 16 Job Streams : Another Home Run for Sun

14.  6,000 user PeopleSoft Campus Solutions 9.0 benchmark on a combination of X6270 blades and M4000 server. Database: Oracle 11g R1 Benchmark Report Blog: PeopleSoft Campus Solutions 9.0 benchmark on Sun SPARC Enterprise M4000 and X6270 blades

Although challenging and exhilarating, benchmarks aren't always pleasant to work on, and really not for people with weak hearts. While running most of these benchmarks, my blood pressure shot up several times leaving me wonder why do I keep working on time sensitive and/or politically, strategically incorrect benchmarks (apparently not every benchmark finds a home somewhere on the public network). Nevertheless in the best interest of my employer, the showdown must go on.

Read More